Kas iš tikrųjų nutinka, kai Lovable programėlę pritaikote kelioms kalboms

Paprašote Lovable pridėti naują kainodaros skiltį. Lovable sugeneruoja komponentą, prijungia jį ir išleidžia. Jūsų angliška sąsaja atnaujinta. messages.po katalogai vis dar nurodo į tai, kas buvo anksčiau. Prancūzų naudotojai mato seną tekstą. Vokiečių naudotojai mato anglišką. Niekas to nepastebi, kol apie problemą nepraneša tikras naudotojas.

Tai ne Lovable klaida. Tai struktūrinis neatitikimas. Lovable optimizuotas greitam sąsajos išleidimui. i18n reikalauja sekti kiekvieną naudotojui matomą eilutę kiekviename lokalės kataloge su kiekvienu pakeitimu. Šie du tikslai tiesiogiai konfliktuoja.

Ištraukimo problema yra nuolatinė, o ne vienkartinė. Kiekvienas Lovable vykdomas raginimas gali sukurti naujų eilučių. Kiekviena iteracija keičia esamą turinį. Nėra natūralaus kontrolinio taško, kuriame galėtumėte pasakyti: „Ištraukimas baigtas.“

Kodėl akivaizdūs sprendimai nepasiteisina

Ar vienkartinis ištraukimas išsprendžia problemą?

Ne. Po pradinio Lovable kūrimo galite paleisti eilučių ištraukimo procesą ir sukurti tvarkingus PO katalogus. Tai veiks iki kito raginimo. Po jo turėsite rankiniu būdu lyginti pakeitimus dešimtyse komponentų ir katalogų. Jei vienos eilutės nepastebėsite savo ispanų messages.po kataloge, ispanakalbiai naudotojai išversto puslapio viduryje matys anglišką tekstą — tai vadinama mišrių kalbų sąsaja ir yra viena labiausiai pasitikėjimą griaunančių patirčių, kurias galite išleisti.

Ar vykdymo metu veikiantys vertimo įrankiai yra pakankamai geri?

Vykdymo metu veikiantys vertėjai, tokie kaip Weglot ar „JavaScript“ įterpiami vertimo valdikliai, sprendžia kitą problemą. Jie išverčia turinį puslapiui įsikėlus, todėl naudotojai dalį sekundės mato originalo kalbą, kol pasirodo vertimas. Be prastos naudotojo patirties, tai sukuria išmatuojamą kaupiamąjį išdėstymo poslinkį (Cumulative Layout Shift) — vieną iš „Core Web Vitals“ rodiklių, kurį „Google“ naudoja puslapiams reitinguoti. Nematomą priežiūros problemą iškeičiate į matomą našumo problemą.

O gal tiesiog paprašyti Lovable atnaujinti lokalės failus?

Jei paprašysite, Lovable gali rašyti į PO katalogus. Problema ta, kad turite nepamiršti to paprašyti dėl kiekvienos eilutės, kiekvieno raginimo ir kiekvienos lokalės. Kognityvinė našta didėja su kiekviena pridėta kalba. Padauginkite ją iš keturių lokalių ir kiekvienas sąsajos raginimas taps keturių žingsnių koordinavimo užduotimi. Būtent tokia trintis sunaikina greitį, dėl kurio Lovable apskritai verta naudoti.

Kaip iš tikrųjų sugenda Lovable i18n ciklas

Šis modelis pakankamai nuoseklus, kad būtų lengvai atpažįstamas:

  1. Pradinis nustatymas — Pridedate kelių kalbų palaikymą. Viskas veikia. Viskas išversta. Esate patenkinti.
  2. Pirmieji leidimai — Nepamirštate rankiniu būdu atnaujinti PO katalogų. Tai erzina, bet įmanoma.
  3. Spartos etapas — Pradedate leisti pakeitimus greičiau. PO katalogai ima atsilikti. Sakote sau, kad juos pasivysite.
  4. Mišrių kalbų produkcija — Neanglakalbių rinkų naudotojai pradeda matyti dalį angliško teksto. Atkeliauja pagalbos užklausos. Visą leidimo ciklą praleidžiate vien ieškodami eilučių.
  5. Refaktorizavimo mokestis — Kiekviena nauja funkcija dabar turi paslėptą i18n kainą, kurios angliškoje versijoje nebuvo. Leidimų sparta mažėja.

Refaktorizavimo mokestis yra ta dalis, apie kurią niekas nekalba rašydamas vadovus „štai kaip Lovable programėlę pritaikyti kelioms kalboms“. Vadovuose rodomas pradinis nustatymas. Juose nerodoma, kas nutinka dvyliktame leidime.

Sprendimas: i18n, prijungtas prie jūsų Git išsiuntimo ciklo

Teisingas architektūrinis sprendimas — visiškai pašalinti rankinius veiksmus. Jei vertimai atnaujinami automatiškai su kiekvienu išsiuntimu, priežiūros problema išnyksta. Negalite pamiršti paleisti ištraukimo, jei jis paleidžiamas pats.

Darbo eiga atrodo taip:

  1. Prijunkite Lovable projektą prie GitHub. Pokalbio įvesties lauke pasirinkite meniu „+“, tada „GitHub“, tada „Connect project“.
  2. Pridėkite lovable-i18n įgūdį prie savo darbo srities. Lovable darbo srityje atidarykite „Skills“, pasirinkite „Add“, tada „Import from GitHub“ ir įklijuokite https://github.com/globalize-now/globalize-skills/tree/main/skills/lovable-i18n. Patvirtinkite. Tai atliekama kartą vienai darbo sričiai; reikia darbo srities savininko arba administratoriaus teisių.
  3. Paprašykite Lovable viską nustatyti. Į Lovable pokalbį įklijuokite: Set up i18n for my project using the lovable-i18n skill.. Lovable aptiks jūsų steką (Vite SPA arba TanStack Start), užduos vieną klausimą — šaltinio kalba, tikslinės kalbos, ar lokalė turi būti URL, ar pridėti GitHub Action — ir numatytosioms reikšmėms atsakykite go. Jis įdiegs Lingui, sukurs PO katalogus ties src/locales/{locale}/messages.po, apgaubs eilutes <Trans> makrokomandomis ir pridės kalbų perjungiklį.
  4. Peržiūrėkite ir suliekite. Lovable sinchronizuos pakeitimus su GitHub; peržiūrėkite skirtumą ir suliekite jį su numatytąja šaka.
  5. Prijunkite saugyklą prie globalize.now. Prisijunkite, prijunkite saugyklą, suteikite leidimą GitHub programėlei, pasirinkite savo Lovable saugyklą ir numatytąją šaką, tada pasirinkite kalbas (daugiau nei 50, įskaitant RTL).
  6. Toliau kurkite su Lovable. Kiekvienas išsiuntimas paskatins globalize.now sukurti vertimo PR su atnaujintais PO katalogais; jį suliekite ir programėlė bus išleista išversta.

Svarbiausia savybė: po nustatymo prijungimo ir sinchronizavimo veiksmai iš jūsų nieko nebereikalauja. Jums nereikia vykdyti komandos, tikrinti skydelio ar tvirtinti vertimų eilės. Naujos eilutės Lovable sugeneruotuose komponentuose aptinkamos išsiuntimo metu, išverčiamos ir grąžinamos kaip PR dar prieš jums suliejant šaką. Išsamus nustatymas pateiktas Lovable integracijos puslapyje.

Ką tai reiškia jūsų Lovable darbo eigai

Jums nereikia nustoti naudoti Lovable. Architektūra sukurta darant prielaidą, kad jūsų sąsaja nuolat keisis — būtent tai ir yra esmė. Lovable generuoja sąsają ir vykdo lovable-i18n įgūdį, o globalize.now tvarko sinchronizavimą.

Lovable generuoja komponentus ir pritaiko įgūdį, kai jums reikia i18n. globalize.now stebi rezultatą su kiekvienu išsiuntimu. Jūsų naudotojai visada mato visą išverstą sąsają, nesvarbu, kaip greitai leidžiate pakeitimus.

globalize.now vibe coderių puslapyje rasite daugiau informacijos apie tai, kaip nustatymas veikia būtent su DI kuriamomis programėlėmis. Jei jau naudojate Lovable sukurtą Next.js arba React programėlę, kūrėjams skirtame puslapyje aprašytas techninis integravimo kelias.

Komandoms, jau valdančioms kelis Lovable projektus, globalize.now kainodara pagal darbo sritį reiškia, kad nemokate už kalbą ar eilučių ištraukimą — sinchronizavimo kaina nesikeičia programėlei augant.

Priežiūros našta yra reali ir didėja. Pridėkite lovable-i18n įgūdį Lovable aplinkoje (darbo srityje atidarykite „Skills“, pasirinkite „Add“, tada „Import from GitHub“). Žr. Lovable integracijos vadovą arba globalize.now.

globalize.now paverčia užkoduotą programos tekstą į vertimui paruoštus lokalės failus ir juos atnaujina, kai jūs diegiate naujus pakeitimus.

Išbandyti globalize.now nemokamai