Vai tulkojumu pull request pieprasījumi bojā Lovable GitHub sinhronizāciju?

Nē, tulkojumu pull request nesabojā Lovable GitHub sinhronizāciju, ja vien tas tiek sapludināts tajā vienā zarā, ko Lovable sinhronizē. Lovable vienlaikus rediģē vienu zaru un ievelk projektā sapludinātos commit, tāpēc tulkojumu pull request ir vienkārši vēl viens commit, kas nonāk šajā zarā. globalize.now ir ar mākslīgo intelektu darbināta lokalizācijas infrastruktūra, kas tulkojumus piegādā kā pull request jūsu repozitorijam, tāpēc abas sistēmas sastopas parastā Git merge un nekur citur. Gadījumi, kad kaut kas noiet greizi, ir konkrēti un dokumentēti, un šajā rakstā tie ir izskatīti.

Kā faktiski darbojas Lovable GitHub sinhronizācija?

Tā ir divvirzienu un vienzaru. Lovable dokumentācijā teikts, ka tas rediģē un sinhronizē vienu zaru vienlaikus — pēc noklusējuma repozitorija galveno zaru, parasti main. Izmaiņas, ko veicat Lovable, tiek saglabātas kā commit šajā zarā. Commit, kas šajā zarā tiek nosūtīti uz GitHub, tiek ievilkti atpakaļ Lovable.

Divas detaļas ir svarīgas jebkam, kas raksta jūsu repozitorijā ārpus Lovable.

Ievilkšana ir atkarīga no paziņojuma. Lovable saņem push paziņojumu no GitHub un atjaunina projektu. Saskaņā ar to pašu dokumentāciju, ja šis paziņojums nekad nenonāk, šī push commit Lovable neparādās. Dokumentētais risinājums ir push vēl vienu commit, lai tiktu iedarbināts jauns paziņojums. Ja esat sapludinājis tulkojumu pull request, bet redaktorā joprojām redzams angļu teksts, vispirms pārbaudiet šo.

Sinhronizēto zaru var mainīt. Projekta GitHub iestatījumos ir zaru atlasītājs. Tur izveidots zars atzarojas no tā zara, kas šobrīd ir aktīvs, nevis automātiski no main. Pēc pārslēgšanās Lovable rediģē un sinhronizē šo zaru. Viss, kas pēc tam sapludināts main, redaktoram ir neredzams, līdz tiek sapludināts zarā, kurā atrodas Lovable.

Ja no šīs sadaļas atceraties tikai vienu teikumu: tulkojumu pull request jānonāk zarā, ko rāda atlasītājs.

Kas notiek, kad GitHub noraida Lovable push?

Lovable novieto izmaiņas zarā ar nosaukumu lovable-sync, nevis tās zaudē. Saskaņā ar Lovable dokumentāciju tas notiek, kad GitHub noraida push konfliktu vai zara aizsardzības noteikumu dēļ, un tad lovable-sync jāsapludina savā aizsargātajā zarā, izmantojot ierasto pārskatīšanas procesu.

Vēl viens drošības tīkls: ja zars, ko Lovable sinhronizē, tiek izdzēsts GitHub, Lovable pārslēdz projektu uz jaunu zaru ar nosaukumu lovable-fallback. Savukārt paša repozitorija dzēšana pārtrauc savienojumu un sinhronizāciju, bet pārdēvēšana — nē.

Nekas no tā nav raksturīgs tikai tulkojumiem. Tā ir paredzamā uzvedība otram rakstītājam ap Lovable, un tulkojumu pull request ir pieklājīgs otrais rakstītājs: tas nonāk kā pārskatāms pull request un nekad neraksta tieši aizsargātā zarā.

Kur iederas tulkojumu pull request?

Starp Lovable commit un jūsu merge pogu. Plūsma izskatās šādi Lovable projektā, kurā jau ir instalēta lovable-i18n prasme un instrukciju noteikumi Lovable zināšanās nodrošina, ka jaunie teksti tiek ietīti.

1. Lovable uzraksta funkciju un apvieno jaunos tekstus Lingui makro. Tas veic commit sinhronizētajā zarā.
2. GitHub darbplūsma izvelk ietītos tekstus PO katalogos zem src/locales/ un veic sinhronizācijas commit atpakaļ. Lovable nav termināļa, tāpēc ekstrakcijai jānotiek GitHub, nevis redaktorā.
3. Konvertēšana ir vienreizēja un notiek lietotnē: jūs pievienojat repozitoriju, un globalize.now vienreiz konvertē kodubāzi, piegādājot katalogu kā pull request. Pēc tam push darbi tulko jaunās kataloga vienības un arī tulkotos katalogus piegādā kā pull request.
4. Jūs sapludināt pull request sinhronizētajā zarā. Lovable ievelk merge commit, un lietotne tagad attēlo jauno valodu.

Ievērojiet, kas šeit nav: nav importa soļa Lovable, nav eksporta no tīmekļa informācijas paneļa un nav logrīka, kas ielādē tulkojumus izpildlaikā. Tulkotie faili ir parasti faili jūsu repozitorijā, un tas ir arguments aiz Lovable lietotnes lokalizēšanas bez informācijas paneļa, bet precīzi savienošanas soļi ir Lovable integrācijas lapā.

Vai Lovable un tulkojumu pull request var konfliktēt?

Jā, parastā Git izpratnē, un tas ir reti, ja pull request ir īslaicīgi. Konfliktam abiem rakstītājiem starp zarošanu un sapludināšanu jāizmaina vienas un tās pašas viena un tā paša faila rindas.

Vienīgā reālā pārklāšanās ir PO katalogs. Kad Lovable pievieno tekstu, tas katrā src/locales/*/messages.po pievieno jaunu ziņojumu ar tukšu tulkojumu, tāpēc lietotne izmanto avota tekstu. Tulkojumu pull request aizpilda tulkoto tekstu ziņojumiem, kas katalogā jau bija, kad tas tika atvērts. Ja Lovable pievieno jaunus ziņojumus faila beigās, kamēr pull request rediģē ierakstus tā paša faila iepriekšējā daļā, Git sapludina abus bez iebildumiem. Ja abi skar vienu ierakstu, parādās konflikta atzīme.

Trīs ieradumi palīdz šo logu saglabāt šauru.

Sapludiniet tulkojumu pull request tajā pašā dienā, kad tie tiek atvērti. Tikai tad, ja pull request nedēļu stāv neskarts, kamēr Lovable izlaiž desmit funkcijas, situācija kļūst juceklīga.

Nekad nerediģējiet kataloga ierakstu atsauču komentārus ar roku. Ekstrakcijas darbplūsma pārģenerē #. un #: rindas, tāpēc, risinot konfliktu, paturiet ierakstu ar tulkoto tekstu un ļaujiet nākamajai ekstrakcijai komentārus pārrakstīt.

Pirms sapludināšanas atjauniniet novecojušu zaru. Ja pull request zars ir atpalicis, vispirms to atjauniniet:

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

Atrisiniet visu, ko Git atzīmē, veiciet push un sapludiniet. Tā kā katalogi ir teksts un katrs ziņojums ir bloks, konflikts, ko risināt, gandrīz vienmēr ir viens ieraksts, nevis viss fails.

Ko maina zara aizsardzība?

Tā pievieno pārskatīšanu, bet pārskatīšana jau ir pieņemtais darba modelis. Tulkojums, kas piegādāts kā pull request, iziet cauri visām obligātajām pārbaudēm un apstiprinājumiem, kas noteikti jūsu zaram. Lovable paša veiktie push, ko aizsargātais zars noraida, nonāk lovable-sync, ko sapludināt tajā pašā pārskatīšanas procesā. Abi ceļi ir atsevišķi, un neviens nebloķē otru.

Ja aizsargājat noklusējuma zaru un vienlaikus ļaujat Lovable to rediģēt, sagaidiet, ka lovable-sync periodiski būs jāsapludina; tā ir Lovable dokumentētā uzvedība, nevis tulkošanas problēma. Ja tas traucē, varat atslābināt aizsardzības noteikumu Lovable autoram vai pārslēgt sinhronizēto zaru uz atsevišķu zaru projekta iestatījumos. Abos gadījumos tulkojumu pull request mērķējiet uz to zaru, ko Lovable sinhronizē.

Kāpēc šī jautājuma nebija ar izpildlaika tulkošanas logrīkiem?

Tāpēc, ka tie nekad nerakstīja jūsu repozitorijā. Lovalingo, kas tika slēgts 2026. gada 31. augustā, tulkoja renderēto lapu pārlūkā, tāpēc repozitorijā nebija locale failu un nebija pull request, ko sapludināt. Komandas, kas pārgāja uz commit veiktiem katalogiem, izmantojot migrācijas ceļvedi, pirmoreiz sastopas ar Lovable GitHub sinhronizāciju kā divu rakstītāju sistēmu.

Tāds ir kompromiss, un tas ir pareizais: tulkotais teksts pieder jums, ir versionēts un indeksējams, nevis īrēts renderēšanas brīdī. Tas gan prasa zināt, kurā zarā atrodas Lovable. Par otru Lovable lietotnes tulkojumu uzturēšanas pusi, kur katalogi atpaliek no koda, skatiet kāpēc tulkojumi salūst katru reizi, kad izlaižat versiju. Ja jūsu lietotne saturu glabā arī datubāzē, šis slānis atrodas ārpus repozitorija; to aptver datubāzes satura lokalizēšana Lovable lietotnē.

Turiet abus rakstītājus vienā zarā

Pārbaudiet zaru atlasītāju sava projekta GitHub iestatījumos, sapludiniet tulkojumu pull request šajā zarā un uztveriet lovable-sync kā uzdevumu, nevis kļūdu. Ja veidojat ar Lovable un vēlaties, lai tulkošanas darbs tiktu paveikts jūsu vietā, nevis jums pašiem tas būtu jāuztur, vibe coders lapa ir pārskats, bet cenas ir atsevišķā lapā.