Kā lokalizēt ar MI ģenerētu lietotni

Šis ceļvedis paskaidro, kā internacionalizēt un pēc tam lokalizēt ar MI ģenerētu lietotni: atslēgas, lokalizācijas failus, izgūšanu, glosārijus un automatizāciju, kas iztur strauju UI mainību. globalize.now ir MI darbināta lokalizācijas infrastruktūra, kas šos katalogus saglabā sinhronizētus ar Git ikvienā push, tāpēc jūs to iestatāt vienreiz, sinhronizācija notiek automātiski pie katra push, un jums nav jāveic manuāla failu apmaiņa. Lai uzzinātu, kāpēc MI orientētas kodubāzes bieži izlaiž i18n slāni, lasiet AI Code Broke Localization — And Nobody Fixed It. Lai iegūtu nozares kontekstu par dažādiem rīku attīstības posmiem, skatiet 3 Stages of Localization Development (And Why AI Changes Everything). Ja repozitorijs vēl ir nesakārtots un jādomā par rīku secību, lasiet globalize.now vs Lokalise vs Crowdin un praktisko globalizācijas ceļvedi How to Globalize Your App with globalize.now.

Ko īsti nozīmē „lokalizēt ar MI ģenerētu lietotni“?

Lokalizācija (l10n) ir tas, ko redz lietotāji: pareiza valoda, daudzskaitļa formas, datumi, valūta un izkārtojums atbilstoši viņu lokalei.

Internacionalizācija (i18n) ir tas, ko izstrādātāji dara vispirms: padara lietotājam redzamo tekstu adresējamu, atkārtoti izmantojamu un droši tulkojamu lielā mērogā.

Lielākā daļa „mēs vēl nevaram lokalizēt“ šķēršļu patiesībā ir i18n šķēršļi. Sakārtojiet arhitektūru vienreiz, un lokalizācija kļūst par operatīvu uzdevumu, nevis par arheoloģijas projektu.

Kam jābūt i18n arhitektūras kontrolsarakstā, pirms izvēlaties rīkus?

Pirms izvēlaties tulkošanas koordinācijas programmatūru vai tulkošanas pakalpojumu sniedzēju, pārliecinieties, ka šie pamatelementi jau pastāv — vai plānojiet tos ieviest šādā secībā:

• Izpildlaika i18n bibliotēka, kas atbilst jūsu tehnoloģiju kopai (React, Next.js, Rails u.c.), ar vienu atbalstītu paraugu UI tekstiem.
• Stabilas tulkošanas atslēgas (nodalītas nosaukumtelpās, hierarhiskas) nevis angļu teikumi kā identifikatori.
• Lokalizācijas resursu faili (JSON, PO, YAML), kas iekļauti repozitorijā vai ģenerēti CI procesā.
• ICU stila daudzskaitļa formas un mainīgie dinamiskām frāzēm, piemēram, "{count} items", lai tulkotāji varētu droši mainīt gramatisko struktūru.
• Tekstu izgūšanas process, lai jauns UI kluso klusi neapietu katalogu.

Kā izgūt tekstus, nezaudējot izstrādes tempu?

Ar MI ģenerētos repozitorijos parasti atkārtojas vienas un tās pašas etiķetes („Saglabāt“, „Atcelt“, „Uzzināt vairāk“) desmitos failu. Izgūšanas procesam vajadzētu:

1. Atrast lietotājam redzamos burtiskos tekstus komponentēs, maršrutos un koplietotajos UI pamatelementos — ignorējot tehniskos tekstus (CSS klases, analītikas ID, URL adreses, ja vien tās nav redzamas lietotājam).
2. Normalizēt dublikātus vienā atslēgā ar atsaucēm, lai tulkotāji redz vienu nozīmes vienību.
3. Izveidot avota lokali (parasti angļu valodā) kā kanonisko vērtību katrai jaunai atslēgai.
4. Pārrakstīt izsaukuma vietas, lai izmantotu jūsu komandas saskaņoto i18n API — mehāniski, lai izmaiņas paliek pārskatāmas.

Minimāls piemērs pirms/pēc React stila kodā izskatās šādi:

<button>Submit order</button>

Pēc izgūšanas un atslēgu piešķiršanas:

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

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

Kāpēc glosāriji un stila ceļveži ir svarīgi, pirms paplašināt valodu skaitu?

Mašīntulkošana ir ātra. Taču bez skaidriem ierobežojumiem viegli var gadīties, ka katrs ekrāns izklausās pēc cita produkta. Pirms paplašināšanās uz vairākām valodām, pierakstiet:

• Zīmola terminus, kurus nedrīkst tulkot (produkta nosaukums, funkciju nosaukumi).
• Vēlamos tulkojumus augsta riska vārdiem („kontakti“, „izmēģinājums“, „norēķini“, „darbvieta“).
• Toni: formāls pret sarunvalodas stilu, un otrā persona pret neitrālu izteiksmi.

Ievadiet šo glosāriju savā koordinācijas rīkā vai MT profilā, lai automātiski ģenerētie melnraksti atbilstu jūsu komandas jau pieņemtajiem lēmumiem.

Kā automatizētajām pārbaudēm vajadzētu balstīt tulkošanas kvalitātes kontroles ciklu?

Kad atslēgas nonāk lokalizācijas failos, mūsdienīgs cikls izskatās šādi: MT melnraksts → linter pārbaudes (garums, aizvietotāji, aizliegti termini) → automatizētas regresijas pārbaudes svarīgākajās vietnēs → publicēšana → mērīšana. Automatizācija ietaupa laiku; linter pasargā jūs no bojātu aizvietotāju publiskošanas.

CLI stila rīki var sniegt ātru atgriezenisko saiti par to, cik daudz darba vēl palicis repozitorijā, līdzīgi kā:

✔ 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

Kādi aģenta uzvednes teksti nodrošina, ka lokalizācijas refaktorizācija paliek pārskatāma?

Šīs uzvednes pieņem, ka strādājat repozitorijā ar testiem un koda pārskatīšanu. Tās izveidotas, lai radītu izmaiņas, kurām varat uzticēties — nevis klusas, plaša mēroga refaktorizācijas.

Kā veikt UI tekstu inventarizāciju pirms refaktorizācijas?

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).

Kā droši ieviest minimālu, tipizētu 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.

Kā mehāniski izgūt burtiskos tekstus nosaukumtelpās sadalītās atslēgās?

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.

Kā izveidot glosārija CSV failu, kuram tulkotāji var uzticēties?

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").

Kāda CI aizsardzība novērš jaunu burtisku angļu tekstu nokļūšanu kodā?

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.

Vai šīs uzvednes joprojām jāievieto manuāli?

Arvien retāk. Kad šis ceļvedis tika sarakstīts pirmoreiz, uzvednu iekopēšana aģentā bija praktiskais veids, kā palaist šo ciklu. Kopš tā laika rīki ir pārcēlušies uz pašu aģentu: kodēšanas aģenti tagad var izsaukt lokalizāciju tieši caur MCP serveri, tāpēc izgūšana, atslēgu piešķiršana un tulkojumu sinhronizācija kļūst par rīku izsaukumiem, ko veic aģents, nevis uzvednēm, kuras iekopējat jūs. Skatiet Introducing the globalize.now MCP par iestatīšanu un Localization is becoming an agent skill, not an SDK par to, kāpēc šī pāreja ir arhitektūriski svarīga.

Iepriekš minētās uzvednes joprojām ir noderīgas kā pārskatīšanas kontrolsaraksti — tās apraksta, kas jādara labai, aģenta virzītai i18n refaktorizācijai, neatkarīgi no tā, vai cilvēks tās iekopē vai aģenta prasme tās iekodē. Vērtējiet jebkuru automatizētu refaktorizāciju pēc tā paša standarta: pārskatāmas izmaiņas, stabilas atslēgas, ICU droša interpolācija un CI aizsardzība, kas novērš regresijas.

Kāds ilgtermiņa ierobežojums jāatceras, lokalizējot ar MI būvētus produktus?

Lokalizācija nav vienreizējs sprints — tas ir līgums ar jūsu nākotnes „es“. Ja vienreiz ieguldāt atslēgās, katalogos un automatizācijā, katrs jauns MI ģenerētais ekrāns kļūst lētāk publicējams visā pasaulē.