Kuidas lokaliseerida tehisintellekti loodud rakendust

Selles juhendis selgitatakse, kuidas tehisintellekti loodud rakendus esmalt rahvusvahelistada ja seejärel lokaliseerida: võtmed, lokaalifailid, ekstraktsioon, sõnastikud ja automatiseerimine, mis peab vastu kiiretele kasutajaliidese muudatustele. globalize.now on tehisintellektil põhinev lokaliseerimisinfrastruktuur, mis hoiab need kataloogid iga push’i järel Gitiga kooskõlas, nii et seadistate kõik ühe korra, sünkroonite automaatselt iga push’i järel ja väldite käsitsi failide edasi-tagasi liigutamist. Kui soovite teada, miks AI-first-koodibaasid i18n-kihi sageli vahele jätavad, lugege artiklit AI-kood lõhkus lokaliseerimise – ja keegi ei parandanud seda. Tööriistade eri ajastute tausta kohta lugege Lokaliseerimise arenduse 3 etappi (ja miks AI muudab kõike). Kui hoidlad on endiselt korrastamata, lugege globalize.now vs Lokalise vs Crowdin ning praktilist globaliseerimise juhendit Kuidas oma rakendust globalize.now abil globaliseerida.

---

Mida tähendab „tehisintellekti loodud rakenduse lokaliseerimine“ tegelikult?

Lokaliseerimine (l10n) on see, mida kasutajad näevad: õige keel, mitmus, kuupäevad, valuuta ja paigutus nende lokaadi jaoks.

Rahvusvahelistamine (i18n) on see, mida insenerid teevad esmalt: muudavad kasutajale nähtava teksti adresseeritavaks, korduvkasutatavaks ja suuremahuliseks tõlkimiseks turvaliseks.

Enamik „me ei saa veel lokaliseerida“ takistusi on tegelikult i18n-i takistused. Parandage arhitektuur üks kord ja lokaliseerimisest saab operatiivne ülesanne, mitte arheoloogiline projekt.

---

Mis peaks i18n-i arhitektuuri kontrollnimekirjas enne tööriistade valimist olema?

Enne tõlgete koordineerimise tarkvara või tõlkevendor’i valimist veenduge, et järgmised ehitusplokid on olemas – või kavandage nende kasutuselevõtt selles järjekorras:

• Käitusaegne i18n-i teek, mis sobib teie stack’iga (React, Next.js, Rails jne) ja pakub kasutajaliidese stringidele ühtset toetatud mustrit.
• Stabiilsed tõlkevõtmed (nimeruumidega, hierarhilised), mitte ingliskeelsed laused ID-dena.
• Lokaali ressursifailid (JSON, PO, YAML), mis on hoidlasse commit’itud või CI-s genereeritud.
• ICU-stiilis mitmused ja muutujad dünaamiliste fraaside, näiteks "{count} items", jaoks, et tõlkijad saaksid grammatikat turvaliselt ümber järjestada.
• Stringide ekstraktsioonitorustik, et uus kasutajaliides ei läheks kataloogist märkamatult mööda.

---

Kuidas stringe ekstraktida ilma arenduskiirust kaotamata?

AI abil loodud hoidlates korduvad samad sildid („Salvesta“, „Tühista“, „Loe lähemalt“) sageli kümnetes failides. Ekstraktsioon peaks:

1. Tuvastama kasutajale nähtavad literaalid komponentides, marsruutides ja jagatud kasutajaliidese primitiivides – jättes tehnilised stringid (CSS-klassid, analüütika ID-d, URL-id, välja arvatud juhul, kui need on kasutajale nähtavad) kõrvale.
2. Normaliseerima duplikaadid üheks võtmeksi koos viidetega, et tõlkijad näeksid ühtset tähendusüksust.
3. Väljastama lähtekoha lokaali (tavaliselt inglise keeles) iga uue võtme kanoonilise väärtusena.
4. Kirjutama väljakutsed ümber, et kasutada teie tiimis kokkulepitud i18n-i API-t – mehaaniliselt, nii et diff jääks ülevaadatavaks.

Reacti-laadse koodi minimaalne enne/pärast näide näeb välja selline:

<button>Submit order</button>

Pärast ekstraktsiooni ja võtmete lisamist:

<button>{t("checkout.submit_order")}</button>

// locales/en.json
{
  "checkout.submit_order": "Submit order"
}

---

Miks on sõnastikud ja stiilijuhendid olulised enne keelte arvu suurendamist?

Masintõlge on kiire. Samuti on lihtne panna iga ekraan kõlama nagu eri toode, kui te piiranguid ei määratle. Enne paljudesse keeltesse skaleerimist pange kirja:

• Bränditerminid, mida ei tohi tõlkida (tootenimi, funktsioonide nimed).
• Eelistatud tõlked riskantsetele sõnadele („kontakt“, „prooviperiood“, „arveldus“, „tööruum“).
• Toon: formaalne vs. vestluslik ning teietamine vs. neutraalne pöördumine.

Viige see sõnastik oma koordineerimisstack’i või MT-profiili, et automaatsed mustandid jääksid kooskõlla otsustega, mille teie tiim on juba teinud.

---

Kuidas peaks automatiseeritud kontroll tõlke kvaliteeditagamise tsüklit toetama?

Kui võtmed liiguvad lokaalifailidesse, on tänapäevane tsükkel järgmine: MT-mustand → linteri kontrollid (pikkus, kohatäited, keelatud terminid) → suure mõjuga pindade automaatsed regressioonikontrollid → avaldamine → mõõtmine. Automatiseerimine säästab aega; linter aitab vältida katkiste kohatäidetega versiooni avaldamist.

CLI-laadsed tööriistad annavad kiire tagasiside selle kohta, kui palju tööd hoidlas veel teha on, näiteks nii:

✔ Scanned 312 files
✔ Found 1,284 user-visible literals
✔ Proposed 920 translation keys (364 duplicates merged)
✔ Wrote locales/en.json

Next: sync translation-ready keys to your coordination tool or run an MT batch with glossary v1

---

Millised agendi prompt’id hoiavad lokaliseerimise refaktorid ülevaadatavana?

Need prompt’id eeldavad, et töötate testide ja koodiülevaatusega hoidlas. Need on kirjutatud selleks, et tulemuseks oleksid usaldusväärsed diff’id, mitte märkamatud ulatuslikud refaktorid.

Kuidas kasutajaliidese stringid enne refaktoreerimist inventeerida?

You are analyzing a TypeScript React codebase for localization readiness.

Task: List every pattern where user-visible English might appear (JSX text, string props that render to the DOM, template literals interpolated into UI, aria-label/title/placeholder, toasts, empty states). Exclude className values, internal IDs, and URLs that are not shown to users.

Output: a table with columns: file path, line range, example string, recommended next step (extract key / ignore / needs product decision).

Kuidas turvaliselt kasutusele võtta minimaalne tüübitud t() API?

Add a minimal i18n helper used across the app: a typed t(key, vars?) function backed by JSON locale files in /locales. Do not translate yet—only wire English as the source locale.

Constraints:
- Keys use dot namespaces: "section.component.purpose"
- Support ICU-style pluralization for keys that need counts
- Add a dev-only warning when t() is called with a missing key

Show the file tree you created and example usage in two existing components.

Kuidas literaalid mehaaniliselt nimeruumidega võtmeteks ekstraktida?

Refactor the following files to replace user-visible string literals with t("…") keys.

Rules:
- Prefer stable semantic keys, not English sentences as keys
- Deduplicate identical UI strings to one key
- Keep string interpolation correct using ICU message patterns
- Do not change layout/styling except where required by the refactor

After edits, print a JSON object mapping each new key to its English source string for translators.

Kuidas koostada sõnastiku CSV, mida tõlkijad saavad usaldada?

From locales/en.json and the product marketing pages in this repo, propose a glossary CSV with columns: term_en, part_of_speech, definition_for_translators, do_not_translate (true/false), allowed_synonyms, notes_for_de.

Flag terms that are legally sensitive (pricing, trials, refunds) and terms that are ambiguous in software ("session", "organization", "member").

Milline CI-kaitse takistab uue hardcoded inglise keele jõudmist koodibaasi?

Add a CI script that fails if new user-visible English literals appear in JSX outside of tests/fixtures.

Implementation guidance:
- Use the repo's existing package manager and test runner
- Provide a small allowlist file for exceptions (brand strings, intentional English)
- Print actionable file/line references on failure

Include README notes for how engineers should add exceptions responsibly.

---

Kas peate need prompt’id endiselt käsitsi kleepima?

Üha vähem. Kui see juhend esimest korda kirjutati, oli prompt’ide agendile kleepimine praktiline viis töövoo käivitamiseks. Sellest ajast alates on tööriistad liikunud agendi enda sisse: kodeerimisagendid saavad nüüd lokaliseerimist otse MCP-serveri kaudu kutsuda, nii et ekstraktsioon, võtmete loomine ja tõlkesünkroonimine muutuvad prompt’ide asemel tööriistakutseteks, mida agent ise teeb. Seadistamise kohta lugege globalize.now MCP tutvustusest ja selle arhitektuurilise muutuse tähenduse kohta artiklist Lokaliseerimisest saab agendi skill, mitte SDK.

Ülaltoodud prompt’id on endiselt kasulikud ülevaatuse kontrollnimekirjadena – need kirjeldavad, mida hea agendipõhine i18n-i refaktor peab tegema, olenemata sellest, kas need kleebib sisse inimene või kodeerib need agendi skill. Hinnake iga automatiseeritud refaktorit sama mõõdupuu järgi: ülevaadatavad diff’id, stabiilsed võtmed, ICU-ga turvaline interpolatsioon ja CI-kaitse, mis regressioonid peatab.

---

Millist pikaajalist piirangut peaksite AI abil loodud toodete lokaliseerimisel meeles pidama?

Lokaliseerimine ei ole üks sprint – see on leping teie tulevase minaga. Kui investeerite võtmetesse, kataloogidesse ja automatiseerimisse ühe korra, muutub iga uus AI abil loodud ekraan üle maailma avaldamiseks odavamaks.