Kust Lovable i18n-reegleid loeb? Knowledge, skillid ja AGENTS.md

Lovable loeb i18n-reegleid kolmest kohast: workspace ja project knowledge'ist, mis on alati kontekstis; skillidest, mis laetakse ainult siis, kui prompt sobib nende kirjeldusega; ning ühendatud hoidla juhisefailidest, kus juurkausta AGENTS.md loetakse sõltumata sellest, kui kaua vestlus on kestnud. Kui panete reeglid vales kohta, väljastab eelmisel nädalal tõlgitud rakendus oma järgmise funktsiooni inglise keeles. globalize.now on tehisintellektil põhinev lokaliseerimise infrastruktuur, seega näeme selle vea tagajärgi paljudes Lovable'i hoidlates; lahendus seisneb enamasti selles, et teate, milline pind millal loetakse.

Miks tõlgitud Lovable'i rakendus libiseb tagasi inglise keelde?

Sest juhis, mis rakenduse mitmekeelseks tegi, ei olnud agendi ees, kui ta kirjutas järgmise komponendi. Lovable lahendab ekraanil oleva prompti. Kui see prompt ütleb „lisa kliendiarvustuste sektsioon“ ja kontekstis pole midagi, mis ütleks „iga kasutajale nähtav string käib läbi <Trans>“, satub pealkiri koodi literaalina, täpselt nagu päris uues projektis.

See ei ole sama probleem mis koodist maha jäävad kataloogid, mis on sünkroonimisviga ja mida käsitleb artikkel miks teie Lovable'i rakenduse tõlked lähevad iga väljastusega katki. Sünkroonimine viib ümbritsetud stringid lokaadifailidesse. See ei saa viia stringi, mida kunagi ei ümbritsetud. Põhiküsimus on, mida Lovable luges hetkel, kui ta koodi kirjutas, ja Lovable'i dokumentatsioon on selles osas erakordselt täpne.

Mida Lovable enne muutmist tegelikult loeb?

Knowledge'i dokumentatsiooni järgi juhivad agenti koos projekti koodiga nii project knowledge, workspace knowledge kui ka Git-hoidla juhisefailid, nt AGENTS.md või CLAUDE.md. Skillid on eraldi ja laetakse nõudmisel.

Need erinevad kolmel i18n-i jaoks olulisel viisil.

Millal neid loetakse. Knowledge lisatakse igale sõnumile. Skill lisatakse ainult siis, kui päring sobib selle kirjeldusega. Juurkausta AGENTS.md loetakse Lovable'i sõnul alati, sõltumata sessiooni pikkusest.

Kui vastupidavad nad pikas vestluses on. Lovable'i dokumentatsioonis on selge hoiatus, et väga pikkades, palju konteksti sisaldavates vestlustes ei pruugita knowledge'i juhiseid alati järjepidevalt järgida. Sama lehekülg väidab juurkausta AGENTS.md kohta vastupidist. See asümmeetria ongi selle postituse olemasolu põhjus.

Kes neid muuta saab. Workspace knowledge'i saavad muuta ainult omanik ja administraator. Project knowledge'i saab muuta igaüks, kellel on projektis muutmisõigus. Hoidla faili muudab see, kes saab push'ida, sealhulgas Lovable'i agent ise.

Iga knowledge'i tase mahutab kuni 10 000 märki. See on osuti jaoks rohkem kui piisav, kuid kogu reeglistiku jaoks liiga vähe, kui tahate sinna panna ka arhitektuurimärkmeid, andmebaasi skeemi ja brändi kõneviisi.

Kuhu i18n-reeglid siis panna?

Hoidlasse, koos lühikese osutiga knowledge'is. Põhjendus tuleneb ülaltoodud tabelist.

Hoidla juurkausta AGENTS.md sisaldab kõiki reegleid. Seda loetakse igal sõnumil sõltumata sessiooni pikkusest, see asub Gitis ja jääb seega alles uue vestluse, uue kaastöölise ja teise agendi peale kolimise korral ning sellel pole märgipiirangut, mis konkureeriks ülejäänud projekti konteksti ruumiga. Kui lovable-i18n skill seadistuse käivitab, kirjutab selle kolmas faas just selle faili: Lingui reeglite ploki <!-- lovable-i18n:rules:start --> ja <!-- lovable-i18n:rules:end --> markerite vahele, mis luuakse, kui faili pole, lisatakse lõppu, kui fail on olemas, ja asendatakse markerite vahel uuesti käivitamisel, nii et midagi ei dubleerita.

Project knowledge sisaldab kaherealist osutit. Näiteks selline:

Localization
- This app is localized with Lingui. Every user-visible string is wrapped
  (<Trans>, t``, msg``) and new strings are appended to src/locales/*/messages.po.
- The full rules are in AGENTS.md at the repo root. Follow them on every edit.

Osuti on olemas just selle juhtumi jaoks, mille eest dokumentatsioon hoiatab. Kui pikk vestlus on teadmiste ploki mõju lahjendanud, on agendil ikka hoidlas olev fail; kui hoidla faili mingil põhjusel kontekstis pole, nimetab osuti piirangu ära. Kaks kohta, üks reegel.

Workspace knowledge'i kasutage ainult siis, kui kõik projektid kasutavad sama teeki. Workspace knowledge kehtib kõigile tööruumi projektidele ja seda on täpselt üks. Kui pooled teie projektidest kasutavad Linguit ja pooled midagi muud, on Lingui reegel tööruumi tasandil pooltele projektidele vale ning Lovable'il soovitatakse konflikti korral niikuinii eelistada project knowledge'it. Jätke workspace knowledge'i need reeglid, mis kehtivad kõikjal: nupud lausekirjas (ainult esimene sõna suure algustähega), ilma console.log, ingliskeelsed koodikommentaarid.

Skill ei ole reeglite koduks. See üllatab inimesi, kes on skilli äsja importinud. Skill laetakse siis, kui prompt sobib selle kirjeldusega, seega on lovable-i18n kontekstis, kui palute i18n-i seadistamist, ja puudub, kui palute makselehte. See on teadlik lahendus; skill, mis laetaks igal sõnumil, oleks lihtsalt knowledge. Skilli ülesanne on kirjutada püsivad reeglid ühe korra hoidlasse ja siis teelt kõrvale astuda.

Mida ütlevad AGENTS.md reeglid?

Need annavad vastused küsimustele, mille puhul agent eksib, kui talle öeldakse lihtsalt „kasuta i18n-i“. Skilli kirjutatud plokk koosneb kuuest osast.

Milline makro. Otsustusloend: tekst, mis muutub koos arvuga, kasutab <Plural> või ICU mitmust; JSX-tekst kasutab <Trans>; atribuudiväärtused ja sündmuste käsitlejate stringid, nt toast'id, kasutavad useLingui() tagastatud t; mooduli skoobi konstandid kasutavad msg ja lahendatakse komponendi sees. Reegel ütleb ka, millisest import-teest igaüks pärineb, sest vale t import seob globaalse instantsi, mida rakendus kunagi ei lae.

Interpolatsioon. Ainult lihtmuutuja saab ekstraheeritud sõnumis oma nimega koha. Iga muu avaldis ekstraheeritakse kujul {0}, millega tõlkija midagi peale hakata ei saa, seetõttu nõuab reegel selle nimetamiseks ph() kasutamist.

Mitmus. other on alati nõutav, kategooriad on CLDR-i omad ja kahe stringi vaheline kolmekohaline tingimusavaldis on keelatud, sest see kirjutab ingliskeelsed mitmusereeglid komponenti sisse. Kui soovite tausta, siis artikkel mis on ICU MessageFormat selgitab süntaksit, milleks mitmusevormid kompileeritakse.

Arvud ja kuupäevad. i18n.number() ja i18n.date(), mitte kunagi toFixed() ega väärtusele külge liidetud valuutasümbol. Lovable'i enda workspace knowledge'i näide sisaldab lokaliseerimise jaotist, mis määrab kuupäevavormingu ja Euroopa arvuvormingu; see on hea mõte, kuid tegemist on vormindamise, mitte makrosse pakkimise reegliga. Rakendus võib seda eeskujulikult järgida ja ikkagi väljastada kõik pealkirjad inglise keeles.

Tõlkijate kommentaarid. Lühikesed stringid, millel on mitu tähendust, paljad tegevussildid ja valdkonnaterminid saavad comment=, mis kirjeldab, kus string esineb. context= on reserveeritud juhuks, kus sama tekst vajab eri kohtades erinevat tõlget.

Kataloogi hooldus. Iga uus string ümbritsetakse ja lisatakse igasse src/locales/*/messages.po tühja msgstr-ga, nii et Lingui kasutab allikatekstile tagasilangemist, kuni tõlge saabub. Agent ei käivita kunagi lingui extract, sest Lovable'is pole terminali; selle teeb pärast sünkroonimist GitHub Action. Ja ta ei muuda kunagi olemasolevate kirjete #. ja #: kommentaaridridu, sest ekstraheerimine genereerib need uuesti.

Just see viimane jaotis muudabki reeglid Lovable'ile omaseks. Cursori või Claude Code'i reeglifail võib lõppeda sõnadega „käivita linter“. Lovable'i reeglifail ei saa, seega peab see ütlema, mida käsitsi teha ja mida jätta CI hooleks.

Mis jõustab reegli, kui Lovable ei saa midagi käivitada?

GitHubi töövoog ja ainult GitHubi töövoog. Lovable'il pole terminali, seega puudub lint-samm hetke vahel, kui agent kirjutab literaali, ja hetke vahel, kui muudatus teie hoidlasse sünkroonitakse. See ongi struktuurne erinevus IDE-agentidest, kus lint-reegel CI-s paneb ehituse sisse kirjutatud stringi tõttu ebaõnnestuma.

Kui nõustute seadistuse käigus, lisab skill GitHub Actionsi töövoo, mis jookseb vaikeharule tehtavatel push'idel (kuhu Lovable'i sünkroonimine jõuab), ekstraheerib makrodesse pakitud stringid kataloogidesse ja commit'ib kataloogi sünkroonimise tagasi. Kui GitHubi rakendusel puudub workflows õigus, palub skill teil faili GitHubis käsitsi lisada. See sulgeb ringi kõige jaoks, mille agent makrosse pakkis. Stringi puhul, mida agent ei pakkinud, ei aita see midagi, sest ekstraheerimine näeb ainult makrosid.

Ausalt öeldes on olukord selline: AGENTS.md reeglid vähendavad pakkimata literaali esinemise sagedust, knowledge'i osuti toetab neid pikkades vestlustes ja GitHubi diff on koht, kus ülejäänu kinni püüate. Kui soovite, et ülejäänu püüaks kinni masin, lisage eslint-plugin-i18next reegel no-literal-string samasse töövoogu sammuna. See jookseb hoidlas, mis on ainus koht, kus Lovable'i projekt üldse midagi käivitada saab.

Mis juhtub stringidega, mis makrosse pakitakse?

Need vajavad tõlkimist ja just see on osa, mida tasub automatiseerida, mitte uuesti promptida. Konverteerimine on ühekordne ja toimub rakenduses: ühendage hoidla ja globalize.now konverteerib koodibaasi ühe korra, esitades kataloogi pull requestina, mille te üle vaatate. Pärast seda tõlgivad push-käivitatavad tööd uued kataloogiüksused nende saabudes, nii et teisipäeval Lovable'i kirjutatud <Trans> tõlked on kolmapäevaks pull requestis. Ei mingit juhtpaneeli sammu, eksporti ega kinnitusjärjekorda; pikem põhjendus selle lähenemise kohta on artiklis Lovable'i rakenduse lokaliseerimine ilma juhtpaneelita ning täpne seadistustee, sealhulgas GitHubi ühendus ja globalize'i konnektor, on Lovable'i integratsiooni lehel.

Üks ajalooline märkus, sest see selgitab, miks see probleem tundub mõnele Lovable'i arendajale uus. Lovalingo tõlkis Lovable'i rakendusi käitusajal brauseris, nii et äsja genereeritud ingliskeelne komponent tõlgiti laadimisel lihtsalt uuesti ja probleem ei tulnud kunagi nähtavale. See suleti 31. augustil 2026 ja rakendused, mis migratsioonijuhendi abil commit'itud kataloogidele üle läksid, puutuvad selle algpõhjuse küsimusega kokku esimest korda. Kataloogimudel on õige kompromiss, sest tõlgitud märgistus on teie oma ja indekseeritav, kuid see eeldab, et agent kirjutab tõlgitavat koodi, ja selleks tuleb talle öelda, kus reeglid asuvad.

Pange reeglid sinna, kust Lovable neid loeb

Käivitage skill üks kord, et AGENTS.md sisaldaks kogu plokki, kleepige kaherealine osuti project knowledge'i ning laske GitHubi töövool teha ekstraheerimine, milleks redaktor võimeline pole. Kui ehitate Lovable'is ja soovite, et kõik, mis kataloogi jõuab, saaks tõlgitud, mitte ei vajaks hooldamist, siis vibe-koodijate leht annab ülevaate ja hinnakiri asub eraldi lehel.