Kas tõlke pull requestid rikuvad Lovable'i GitHubi sünkroonimist?

Ei, tõlke pull request ei riku Lovable'i GitHubi sünkroonimist, kui see liitub ühte harusse, mida Lovable sünkroonib. Lovable muudab korraga ühte haru ja tõmbab liidetud commitid projekti tagasi, seega on tõlke pull request lihtsalt veel üks commit, mis sinna harusse saabub. globalize.now on tehisintellektil põhinev lokaliseerimise infrastruktuur, mis toimetab tõlked kätte pull requestina teie hoidla vastu, mis tähendab, et need kaks süsteemi kohtuvad tavalise Giti merge'i juures ja mitte kusagil mujal. Valesti võivad minna vaid konkreetsed ja dokumenteeritud juhtumid ning selles postituses käime need läbi.

Kuidas Lovable'i GitHubi sünkroonimine tegelikult töötab?

See on kahesuunaline ja ühe haruga. Lovable'i dokumentatsiooni järgi muudab ja sünkroonib ta korraga ühte haru, vaikimisi hoidla vaikeharu, tavaliselt main. Lovable'is tehtud muudatused commititakse sellesse harusse. GitHubis sellesse harusse push'itud commitid tõmmatakse Lovable'i tagasi.

Kaks detaili on olulised kõige jaoks, mis kirjutab teie hoidlasse väljastpoolt Lovable'it.

Tõmbamine sõltub teavitusest. Lovable saab GitHubilt push-teavituse ja uuendab projekti. Sama dokumentatsiooni järgi ei ilmu selle push'i commitid Lovable'is, kui teavitus kohale ei jõua. Dokumenteeritud lahendus on push'ida veel üks commit, et käivituks uus teavitus. Kui liitsite tõlke pull requesti ja redaktor näitab ikka inglise keelt, kontrollige esimesena just seda.

Sünkroonitavat haru saab vahetada. Projekti GitHubi seaded sisaldavad haru valijat. Seal loodud haru hargneb praegu aktiivsest harust, mitte automaatselt harust main. Kui olete vahetanud, muudab ja sünkroonib Lovable edaspidi seda haru. Kõik, mis pärast seda harusse main liidetakse, on redaktorile nähtamatu, kuni see liidetakse harusse, millel Lovable parajasti on.

Kui sellest jaotisest ühe lause meelde jätate, siis see: tõlke pull request peab maanduma harusse, mida valija näitab.

Mis juhtub, kui GitHub lükkab Lovable'i push'i tagasi?

Lovable parkib muudatuse harusse nimega lovable-sync, selle asemel et seda kaotada. Lovable'i dokumentatsiooni järgi juhtub see siis, kui GitHub lükkab push'i tagasi konfliktide või haru kaitsereeglite tõttu, ning seejärel liidate lovable-sync oma kaitstud harusse tavapärase review protsessi kaudu.

Sellega seotud turvavõrk: kui haru, mida Lovable sünkroonib, GitHubis kustutatakse, lülitab Lovable projekti uuele harule nimega lovable-fallback. Hoidla enda kustutamine katkestab ühenduse ja sünkroonimine peatub, ümbernimetamine seevastu mitte.

Midagi sellest ei ole tõlgetele omane. Just nii peabki Lovable'i ümber käituma teine kirjutaja ja tõlke pull request on viisakas teine kirjutaja: ta saabub ülevaadatava pull requestina ega push'i kunagi otse kaitstud harusse.

Kuhu tõlke pull request sobitub?

Lovable'i commitide ja teie merge-nupu vahele. Voog näeb välja selline Lovable'i projektis, kuhu on juba paigaldatud lovable-i18n skill ning mille Lovable'i knowledge'i juhendreeglid hoiavad uued stringid ümbritsetuna.

1. Lovable kirjutab funktsiooni ja mähib uued stringid Lingui makrodesse. Ta commitib sünkroonitavasse harusse.
2. GitHubi workflow ekstraheerib mähitud stringid PO kataloogidesse asukohas src/locales/ ja commitib sünkroonimise tagasi. Lovable'il pole terminali, seega peab ekstraktsioon käima GitHubis, mitte redaktoris.
3. Konverteerimine on ühekordne ja toimub rakenduses: ühendate hoidla ning globalize.now konverteerib koodibaasi ühe korra, toimetades kataloogi kätte pull requestina. Pärast seda tõlgivad push-tööd uued kataloogiüksused ja toimetavad tõlgitud kataloogid samuti pull requestidena.
4. Liidate pull requesti sünkroonitavasse harusse. Lovable tõmbab merge commiti sisse ja rakendus kuvab nüüd uut keelt.

Pange tähele, mis puudub: ei mingit import-sammu Lovable'is, ei mingit eksporti veebipaneelist ja ei mingit vidinat, mis laadiks tõlkeid runtime'is. Tõlgitud failid on tavalised failid teie hoidlas, just see on argument, miks Lovable'i rakendust lokaliseerida ilma paneelita, ning täpsed ühendamise sammud on Lovable'i integratsiooni lehel.

Kas Lovable ja tõlke pull request võivad konflikti sattuda?

Jah, tavapärases Giti mõttes, ja see on haruldane, kui hoiate pull requestid lühiajalistena. Konflikti tekkimiseks peavad mõlemad kirjutajad muutma harunemise ja liitmise vahel sama faili samu ridu.

Ainus realistlik kattumine on PO kataloog. Kui Lovable lisab uue stringi, lisab ta igasse src/locales/*/messages.po faili lõppu uue sõnumi tühja tõlkega, nii et rakendus kasutab varuvariandina lähteteksti. Tõlke pull request täidab tõlgitud teksti nendele sõnumitele, mis olid kataloogis juba pull requesti avamise ajal. Kui Lovable lisab uusi sõnumeid faili lõppu, samal ajal kui pull request muudab sama faili varasemaid kirjeid, liidab Git mõlemad probleemideta. Kui mõlemad puudutavad sama kirjet, saate konfliktimarkeri.

Kolm harjumust hoiavad selle akna väikese.

Liitke tõlke pull requestid samal päeval, kui need avatakse. Pull request, mis seisab nädala, kui Lovable vahepeal kümme funktsiooni välja annab, on ainus viis, kuidas see mürarikkaks läheb.

Ärge kunagi muutke käsitsi kataloogikirjete viitekommentaare. Ekstraktsiooni workflow genereerib read #. ja #: uuesti, seega hoidke konflikti lahendades alles tõlgitud tekstiga kirje ja laske järgmisel ekstraktsiooni käivitusel kommentaarid ümber kirjutada.

Ajakohastage aegunud haru enne liitmist. Kui pull requesti haru on maha jäänud, uuendage seda esmalt:

git fetch origin
git checkout <translation-branch>
git merge origin/<synced-branch>

Lahendage kõik, mille Git märgib, push'ige ja liitke. Kuna kataloogid on tekst ja iga sõnum on oma plokk, on konflikt, mida lahendate, peaaegu alati üks kirje, mitte kogu fail.

Mida muudab haru kaitse?

See lisab ülevaatuse, ja ülevaatus ongi juba kasutatav mudel. Pull requestina toimetatud tõlge läbib kõik nõutavad kontrollid ja heakskiidud, mis teie harul on. Lovable'i enda push'id, mille kaitstud haru tagasi lükkab, saabuvad harusse lovable-sync, mille liidate sama ülevaatuse kaudu. Need kaks rada on eraldi ja ükski ei blokeeri teist.

Kui kaitsete vaikeharu ja lubate Lovable'il seda ka muuta, arvestage, et peate perioodiliselt liitma lovable-sync. See on Lovable'i dokumenteeritud käitumine, mitte tõlkeprobleem. Kui see häirib, on valikud lõdvendada kaitsereeglit Lovable'i autori jaoks või vahetada projekti seadetes sünkroonitav haru spetsiaalse eraldi haru vastu. Mõlemal juhul suunake tõlke pull request harusse, mida Lovable sünkroonib.

Miks seda küsimust käitusaegsete tõlkevidinatega ei tekkinud?

Sest need ei kirjutanud kunagi teie hoidlasse. Lovalingo, mis sulges 31. augustil 2026, tõlkis renderdatud lehe brauseris, seega polnud hoidlas lokaadifaile ega liidetavaid pull requeste. Tiimid, kes liikusid migratsioonijuhendi abil hoidlasse salvestatud kataloogide peale, kohtavad Lovable'i GitHubi sünkroonimist esimest korda kahe kirjutajaga süsteemina.

See on kompromiss ja see on õige: tõlgitud tekst on teie oma, versioonitud ja indekseeritav, mitte renderdamise ajal renditud. See eeldab küll, et teate, millisel harul Lovable on. Lovable'i rakenduse tõlgituna hoidmise teise poole kohta, kui kataloogid jäävad koodist maha, vaadake artiklit miks tõlked lähevad iga väljalaskega katki. Kui teie rakendus hoiab sisu andmebaasis, asub see kiht hoidlast väljas; seda käsitleb andmebaasi sisu lokaliseerimine Lovable'i rakenduses.

Hoidke mõlemad kirjutajad ühel harul

Kontrollige oma projekti GitHubi seadetes haru valijat, liitke tõlke pull requestid sellesse harusse ning käsitlege lovable-sync tegemist vajava ülesandena, mitte veana. Kui ehitate Lovable'is ja soovite, et tõlketöö tehtaks teie eest, mitte ei peaks seda ise hooldama, on vibe coderite leht ülevaade ja hinnastus on eraldi lehel.