Kaip lokalizuoti DI sugeneruotą programėlę

Šiame vadove paaiškinama, kaip DI sugeneruotą programėlę pirmiausia internacionalizuoti, o tada lokalizuoti: raktai, lokalės failai, ištraukimas, žodynai ir automatizavimas, atlaikantis sparčius UI pokyčius. globalize.now — tai DI paremta lokalizacijos infrastruktūra, kuri po kiekvieno push palaiko katalogų ir „Git“ sinchronizaciją, todėl sąranką atliekate vieną kartą, o sinchronizacija vyksta automatiškai — nebereikia rankiniu būdu keistis failais. Kodėl DI pirmiausia kuriamose kodų bazėse dažnai praleidžiamas i18n sluoksnis, skaitykite DI kodas sugadino lokalizaciją — ir niekas jos nepataisė. Pramonės kontekstą skirtingais įrankių raidos etapais rasite 3 lokalizacijos kūrimo etapai (ir kodėl DI viską keičia). Apie tiekėjų pasirinkimo seką netvarkingose saugyklose skaitykite globalize.now ir Lokalise, ir Crowdin, o praktinį globalizacijos vadovą — Kaip globalizuoti savo programėlę naudojant globalize.now.

Ką iš tikrųjų reiškia „lokalizuoti DI sugeneruotą programėlę“?

Lokalizacija (l10n) — tai tai, ką mato naudotojai: tinkama kalba, daugiskaitos formos, datos, valiuta ir jų lokalei pritaikytas išdėstymas.

Internacionalizacija (i18n) — tai, ką pirmiausia atlieka inžinieriai: padaro naudotojams matomą tekstą pasiekiamą per raktus, pakartotinai naudojamą ir saugų versti dideliu mastu.

Dauguma kliūčių, dėl kurių sakoma „dar negalime lokalizuoti“, iš tiesų yra i18n kliūtys. Sutvarkykite architektūrą vieną kartą, ir lokalizacija taps operacine užduotimi, o ne archeologiniu projektu.

Kas turėtų būti i18n architektūros kontroliniame sąraše prieš renkantis įrankius?

Prieš rinkdamiesi vertimų koordinavimo programinę įrangą ar vertimų tiekėją įsitikinkite, kad šie pagrindiniai elementai jau yra — arba suplanuokite juos įdiegti tokia tvarka:

• Vykdymo laiko i18n biblioteka, tinkama jūsų stekui („React“, „Next.js“, „Rails“ ir kt.), su vienu palaikomu UI eilučių naudojimo modeliu.
• Stabilūs vertimo raktai (su vardų sritimis, hierarchiniai), o ne angliški sakiniai kaip identifikatoriai.
• Lokalės išteklių failai (JSON, PO, YAML), saugomi saugykloje arba generuojami CI aplinkoje.
• ICU stiliaus daugiskaitos formos ir kintamieji dinaminėms frazėms, pvz., "{count} items", kad vertėjai galėtų saugiai keisti gramatinę žodžių tvarką.
• Eilučių ištraukimo procesas, kad naujas UI tyliai neapeitų katalogo.

Kaip ištraukti eilutes neprarandant tempo?

DI sugeneruotose saugyklose tie patys užrašai („Save“, „Cancel“, „Learn more“) dažnai kartojasi dešimtyse failų. Ištraukimo etapas turėtų:

1. Aptikti naudotojams matomas literaliąsias reikšmes komponentuose, maršrutuose ir bendruose UI primityvuose, kartu ignoruojant technines eilutes (CSS klases, analitikos ID, URL, nebent jos rodomos naudotojams).
2. Normalizuoti pasikartojimus į vieną raktą su nuorodomis, kad vertėjai matytų vieną reikšmės vienetą.
3. Sugeneruoti šaltinio lokalę (paprastai anglų kalba) kaip kanoninę kiekvieno naujo rakto reikšmę.
4. Perrašyti iškvietimo vietas, kad jos naudotų komandos sutartą i18n API — mechaniškai, kad pakeitimų skirtumai išliktų lengvai peržiūrimi.

Minimalus „React“ stiliaus kodo pavyzdys prieš ir po atrodo taip:

<button>Submit order</button>

Po ištraukimo ir raktų priskyrimo:

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

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

Kodėl prieš plečiant kalbų skaičių svarbūs žodynai ir stiliaus vadovai?

Mašininis vertimas yra greitas. Tačiau neapibrėžus apribojimų, nesunku pasiekti, kad kiekvienas ekranas skambėtų lyg kitas produktas. Prieš pradėdami versti į daug kalbų, užrašykite:

• Prekės ženklo terminus, kurių negalima versti (produkto pavadinimas, funkcijų pavadinimai).
• Pageidaujamus rizikingų žodžių vertimus („contact“, „trial“, „billing“, „workspace“).
• Toną: formalus ar pokalbiškas, kreipinys antruoju asmeniu ar neutralus.

Perduokite šį žodyną į savo koordinavimo steką arba MT profilį, kad automatiniai juodraščiai išliktų suderinti su jūsų komandos jau priimtais sprendimais.

Kaip automatiniai patikrinimai turėtų tapti vertimų QA ciklo pagrindu?

Kai raktai patenka į lokalės failus, šiuolaikinis ciklas atrodo taip: MT juodraštis → linterio patikros (ilgis, vietaženkliai, draudžiami terminai) → automatinės regresijos patikros svarbiausiuose paviršiuose → leidimas → matavimas. Automatizavimas taupo laiką, o linteris apsaugo nuo sugadintų vietaženklių išleidimo.

CLI tipo įrankiai gali greitai parodyti, kiek darbo dar liko saugykloje, panašiai kaip:

✔ 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

Kokios agento užklausos padeda išlaikyti lokalizacijos refaktoringą lengvai peržiūrimą?

Šios užklausos skirtos darbui saugykloje, kurioje naudojami testai ir kodo peržiūra. Jos suformuluotos taip, kad gautumėte patikimus pakeitimų skirtumus, o ne tylius plataus masto refaktoringus.

Kaip prieš refaktoringą inventorizuoti UI eilutes?

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

Kaip saugiai įdiegti minimalią tipizuotą 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.

Kaip mechaniškai ištraukti literaliąsias reikšmes į raktus su vardų sritimis?

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.

Kaip parengti žodyno CSV, kuriuo vertėjai galėtų pasitikėti?

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

Kokia CI apsaugos priemonė neleidžia į kodą patekti naujai anglų kalba įrašytai eilutei?

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.

Ar vis dar reikia šias užklausas įklijuoti rankiniu būdu?

Vis dažniau — ne. Kai šis vadovas buvo parašytas pirmą kartą, praktinis būdas vykdyti ciklą buvo kopijuoti ir įklijuoti užklausas į agentą. Nuo tada įrankiai persikėlė į patį agentą: kodavimo agentai dabar gali tiesiogiai iškviesti lokalizaciją per MCP serverį, todėl ištraukimas, raktų priskyrimas ir vertimų sinchronizacija tampa agento atliekamais įrankių iškvietimais, o ne jūsų įklijuojamomis užklausomis. Sąranką rasite Pristatome globalize.now MCP, o paaiškinimą, kodėl šis pokytis svarbus architektūriškai, — Lokalizacija tampa agento įgūdžiu, o ne SDK.

Pirmiau pateiktos užklausos išlieka naudingos kaip peržiūros kontroliniai sąrašai — jos aprašo, ką turi atlikti geras agento valdomas i18n refaktoringas, nesvarbu, ar jas įklijuoja žmogus, ar įkūnija agento įgūdis. Bet kurį automatinį refaktoringą vertinkite pagal tą pačią kartelę: lengvai peržiūrimi pakeitimų skirtumai, stabilūs raktai, su ICU suderinamas interpoliavimas ir CI apsaugos priemonė, stabdanti regresijas.

Kokį ilgalaikį apribojimą turėtumėte prisiminti lokalizuodami DI sukurtus produktus?

Lokalizacija nėra vieno sprinto užduotis — tai susitarimas su būsimu savimi. Jei vieną kartą investuosite į raktus, katalogus ir automatizavimą, kiekvieną naują DI sugeneruotą ekraną bus pigiau išleisti visame pasaulyje.