Ar vertimų pull request'ai sugadina Lovable GitHub sinchronizaciją?

Ne, vertimų pull request'as nesugadina Lovable GitHub sinchronizacijos, jei jis suliejamas į vienintelę šaką, kurią sinchronizuoja Lovable. Lovable vienu metu redaguoja vieną šaką ir pritraukia sulietus commit'us atgal į projektą, todėl vertimų pull request'as yra tiesiog dar vienas commit'as, atkeliaujantis į tą šaką. globalize.now yra dirbtiniu intelektu grįsta lokalizavimo infrastruktūra, kuri pateikia vertimus kaip pull request'ą jūsų saugyklai, todėl abi sistemos susitinka tik įprastame Git suliejime ir niekur kitur. Atvejai, kai kas nors nueina ne taip, yra konkretūs ir aprašyti dokumentacijoje, o šiame įraše juos aptarsime.

Kaip iš tikrųjų veikia Lovable GitHub sinchronizacija?

Ji dvikryptė ir vienos šakos. Lovable dokumentacijoje nurodyta, kad vienu metu redaguojama ir sinchronizuojama viena šaka, pagal numatytuosius nustatymus — saugyklos numatytoji šaka, dažniausiai main. Pakeitimai, kuriuos atliekate Lovable, commit'inami į tą šaką. Commit'ai, nusiųsti į tą šaką GitHub'e, pritraukiami atgal į Lovable.

Dvi detalės svarbios viskam, kas rašo į jūsų saugyklą ne per Lovable.

Pritraukimas priklauso nuo pranešimo. Lovable gauna push pranešimą iš GitHub ir atnaujina projektą. Pagal tą pačią dokumentaciją, jei pranešimas nepasiekia, to push'o commit'ai Lovable nepasirodo. Dokumentuotas sprendimas — nusiųsti dar vieną commit'ą, kad būtų sukurtas naujas pranešimas. Jei suliejote vertimų pull request'ą, o redaktorius vis dar rodo anglų kalbą, pirmiausia patikrinkite būtent tai.

Sinchronizuojamą šaką galima pakeisti. Projekto GitHub nustatymuose yra šakos parinkiklis. Ten sukurta šaka atsišakoja nuo šiuo metu aktyvios šakos, o ne automatiškai nuo main. Kai perjungiate, Lovable redaguoja ir sinchronizuoja jau tą šaką. Viskas, kas po to sulieta į main, redaktoriui lieka nematoma, kol nebus sulieta į šaką, kurioje dirba Lovable.

Jei iš šio skyriaus įsimintumėte tik vieną sakinį: vertimų pull request'as turi patekti į šaką, kurią rodo parinkiklis.

Kas nutinka, kai GitHub atmeta Lovable push'ą?

Lovable pakeitimą padeda į šaką, vadinamą lovable-sync, užuot jį praradęs. Pagal Lovable dokumentaciją, taip nutinka, kai GitHub atmeta push'ą dėl konfliktų ar šakos apsaugos taisyklių, o tada lovable-sync sulieti į apsaugotą šaką reikia pagal įprastą peržiūros procesą.

Susijusi apsauga: jei šaka, kurią sinchronizuoja Lovable, ištrinama GitHub'e, Lovable perjungia projektą į naują šaką, pavadintą lovable-fallback. O pačios saugyklos ištrynimas nutraukia ryšį ir sinchronizacija sustoja, tuo tarpu pervadinimas to nepadaro.

Nė viena iš šių taisyklių nėra specifinė vertimams. Taip turi elgtis bet kuris antras rašytojas aplink Lovable, o vertimų pull request'as yra mandagus antras rašytojas: jis atkeliauja kaip peržiūrimas pull request'as ir niekada nesiunčia push'o tiesiai į apsaugotą šaką.

Kur vertimų pull request'as telpa šiame procese?

Tarp Lovable commit'ų ir jūsų merge mygtuko. Srautas atrodo taip Lovable projekte, kuriame jau įdiegtas lovable-i18n skill, o instrukcijų taisyklės Lovable žinių bazėje užtikrina, kad nauji tekstai būtų apgaubti.

1. Lovable parašo funkciją ir naujus tekstus apgaubia Lingui makrokomandomis, o pakeitimą commit'ina į sinchronizuojamą šaką.
2. GitHub workflow ištraukia apgaubtus tekstus į PO katalogus kataloge src/locales/ ir commit'ina sinchronizaciją atgal. Lovable neturi terminalo, todėl ištraukimas turi vykti GitHub'e, o ne redaktoriuje.
3. Konvertavimas vyksta vieną kartą ir programėlėje: prijungiate saugyklą, o globalize.now vieną kartą konvertuoja kodo bazę ir pateikia katalogą kaip pull request'ą. Po to push užduotys išverčia naujus katalogo vienetus ir išverstus katalogus taip pat pateikia kaip pull request'us.
4. Pull request'ą suliejate į sinchronizuojamą šaką. Lovable pritraukia merge commit'ą, ir programėlė jau rodo naują kalbą.

Atkreipkite dėmesį, ko čia nėra: nėra importavimo žingsnio Lovable, eksporto iš žiniatinklio skydelio ir valdiklio, kuris vykdymo metu įkeltų vertimus. Išversti failai yra paprasti failai jūsų saugykloje — tai ir yra argumentas už Lovable programėlės lokalizavimą be skydelio, o tikslūs prijungimo žingsniai aprašyti Lovable integracijos puslapyje.

Ar Lovable ir vertimų pull request'as gali konfliktuoti?

Taip, įprasta Git prasme, tačiau tai reta, kai pull request'ai gyvuoja neilgai. Konfliktui reikia, kad abu rašytojai tarp atsišakojimo ir suliejimo pakeistų tas pačias to paties failo eilutes.

Vienintelis realistiškas persidengimas yra PO katalogas. Kai Lovable prideda naują eilutę, jis į kiekvieną src/locales/*/messages.po prideda naują įrašą su tuščiu vertimu, todėl programėlė naudoja šaltinio tekstą. Vertimų pull request'as užpildo išverstą tekstą įrašams, kurie jau buvo kataloge, kai jis buvo atidarytas. Jei Lovable prideda naujus įrašus failo gale, o pull request'as redaguoja ankstesnius to paties failo įrašus, Git sulieja abu be jokių problemų. Jei abu liečia tą patį įrašą, gausite konflikto žymę.

Trys įpročiai padeda išlaikyti tą langą mažą.

Vertimų pull request'us sulieskite tą pačią dieną, kai jie atidaromi. Savaitę stovintis pull request'as, kol Lovable pristato dešimt funkcijų, yra vienintelė priežastis, dėl kurios tai tampa chaotiška.

Niekada neredaguokite rankomis katalogo įrašų nuorodų komentarų. Ištraukimo workflow iš naujo sugeneruoja #. ir #: eilutes, todėl sprendžiant konfliktą palikite įrašą su išverstu tekstu, o komentarus leiskite perrašyti kitam ištraukimo paleidimui.

Pasenusią šaką atnaujinkite prieš sulieję. Jei pull request'o šaka atsiliko, pirmiausia ją atnaujinkite:

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

Išspręskite visus Git pažymėtus konfliktus, nusiųskite pakeitimus ir sulieskite. Kadangi katalogai yra tekstiniai, o kiekvienas pranešimas — atskiras blokas, išsprendžiamas konfliktas beveik visada apima vieną įrašą, o ne visą failą.

Ką pakeičia šakos apsauga?

Ji prideda peržiūrą, o peržiūra jau ir taip yra naudojamas modelis. Vertimas, pateiktas kaip pull request'as, praeina visas privalomas patikras ir patvirtinimus, kuriuos turi jūsų šaka. Lovable pakeitimai, kuriuos apsaugota šaka atmeta, patenka į lovable-sync, kurį suliejate per tą pačią peržiūrą. Šie du keliai yra atskiri ir vienas kito neblokuoja.

Jei apsaugote numatytąją šaką ir kartu leidžiate Lovable ją redaguoti, tikėkitės periodiškai sulieti lovable-sync; tai dokumentuotas Lovable elgesys, o ne vertimų problema. Jei tai vargina, galite arba sušvelninti apsaugos taisyklę Lovable autoriui, arba projekto nustatymuose perjungti sinchronizuojamą šaką į atskirą. Abiem atvejais vertimų pull request'ą nukreipkite į tą šaką, kurią sinchronizuoja Lovable.

Kodėl šio klausimo nebuvo naudojant vertimo įskiepius, veikiančius vykdymo metu?

Todėl, kad jie niekada nerašė į jūsų saugyklą. Lovalingo, kuris nustos veikti 2026 m. rugpjūčio 31 d., vertė atvaizduotą puslapį naršyklėje, todėl saugykloje nebuvo lokalės failų ir nebuvo pull request'ų, kuriuos reikėtų sulieti. Komandos, kurios per migracijos vadovą perėjo prie commit'intų katalogų, su Lovable GitHub sinchronizacija pirmą kartą susiduria kaip su dviejų rašytojų sistema.

Tai kompromisas, ir jis teisingas: išverstas tekstas yra jūsų, versijuojamas ir indeksuojamas, o ne nuomojamas atvaizdavimo metu. Tiesa, reikia žinoti, kurioje šakoje dirba Lovable. Apie kitą Lovable programėlės vertimo palaikymo pusę — kai katalogai atsilieka nuo kodo — skaitykite kodėl vertimai genda kaskart, kai išleidžiate naują versiją. Jei jūsų programėlė turinį saugo ir duomenų bazėje, tas sluoksnis yra už saugyklos ribų; jį aptaria duomenų bazės turinio lokalizavimas Lovable programėlėje.

Laikykite abu pakeitimų autorius vienoje šakoje

Patikrinkite šakos parinkiklį projekto GitHub nustatymuose, vertimų pull request'us sulieskite į tą šaką, o lovable-sync vertinkite kaip užduotį, o ne kaip klaidą. Jei kuriate su Lovable ir norite, kad vertimo darbus tvarkytų kiti, o ne jūs patys, apžvalgą rasite vibe coders puslapyje, o kainos pateiktos atskirame puslapyje.