Globalizace: co to je, i18n a vícejazyčnost v aplikacích

Co je globalizace (i18n) a proč je potřeba?

Globalizace (zkráceně i18n — 18 písmen mezi «i» a «n») — architektonická příprava aplikace pro práci s libovolným jazykem a regionem. Klíčové pravidlo i18n: žádný textový řetězec by neměl být pevně zakódován (hardcoded) ve zdrojovém kódu. Místo toho jsou řetězce vyčleněny do zdrojových souborů a kód k nim přistupuje pomocí klíčů. Při přidávání nového jazyka stačí přidat překladový soubor — kód zůstává nezměněn. To odlišuje i18n od lokalizace (l10n), kde se překládají samotné řetězce.

Obchodní argument — globalizace zvyšuje trh. Podle Common Sense Advisory (2023) více než 70 % uživatelů preferuje nákupy v aplikacích ve svém rodném jazyce. Lokalizace do 10 jazyků zvyšuje potenciální publikum o 80 %. Bez i18n každé rozšíření o nový jazyk vyžaduje úpravy kódu, což zpomaluje vstup na trh a zvyšuje náklady 5–10krát. Správná architektura i18n umožňuje podporovat 40+ jazyků s minimálními náklady.

Komponenty i18n zahrnují: externalizaci řetězců (String externalization), pluralizaci (pluralization pro 1/2/5+), formátování dat a čísel (DateFormatter/SimpleDateFormat), podporu RTL jazyků (Right-to-Left), řazení podle pravidel locale (Collator), regionální symboly (oddělovače tisíců, desetinné znaky). V IT Sectr pokládáme i18n do fáze architektury, nepřidáváme dodatečně — to šetří až 60 % času při následné lokalizaci.

Internacionalizace v iOS: NSLocalizedString a XLIFF

NSLocalizedString — hlavní Swift makro pro práci s překlady. Formát: NSLocalizedString(«key», comment: «popis pro překladatele»). Makro automaticky dosadí řetězec z Localizable.strings pro aktuální locale zařízení (NSLocale.preferredLanguages). Pokud překlad pro klíč není nalezen, vrátí se samotný klíč nebo hodnota v development language (obvykle en). Apple doporučuje používat smysluplné klíče, nikoli anglické řetězce jako klíče.

// Localizable.strings (en)
// "welcome_title" = "Vítejte!";
// Localizable.strings (ru)
// "welcome_title" = "Vítejte!";

// Swift kód — jednotný pro všechny jazyky
titleLabel.text = NSLocalizedString(
    "welcome_title",
    comment: "Název uvítací obrazovky"
)

// Pluralizace přes Localizable.stringsdict
// 
// <dict>
//     <key>items_count</key>
//     <dict>
//         <key>NSStringLocalizedFormatKey</key>
//         <string>%#@items@</string>
//         <key>items</key>
//         <dict>
//             <key>one</key>
//             <string>%d produkt</string>
//             <key>few</key>
//             <string>%d produkty</string>
//             <key>many</key>
//             <string>%d produktů</string>
//         </dict>
//     </dict>
// </dict>

// Použití pluralizace
let items = 5
let label = String.localizedStringWithFormat(
    NSLocalizedString("items_count", comment: ""), items
)

XLIFF — formát výměny překladů mezi vývojáři a překladateli. Xcode exportuje XLIFF soubor (Editor → Export for Localization), který obsahuje všechny řetězce k překladu. Překladatel pracuje s XLIFF v CAT nástrojích (Trados, memoQ, Smartcat). Po překladu je XLIFF importován zpět do Xcodu (Editor → Import Localizations). XLIFF automaticky aktualizuje všechny .lproj adresáře. Toto je standardní pracovní postup lokalizace iOS aplikací v produkci.

SwiftUI a i18n

SwiftUI pracuje s NSLocalizedString přes inicializátor Text. Text ve SwiftUI je automaticky internacionalizován: Text(«welcome_title») hledá překlad v Localizable.strings stejně jako NSLocalizedString. Pro pluralizaci použijte Text(«%d items», count: items). SwiftUI podporuje formátování dat pomocí Text(date, style: .date) — automaticky používá Locale.current. Apple doporučuje SwiftUI pro nové projekty, protože internacionalizace je v něm transparentnější.

Internacionalizace v Androidu: strings.xml a RTL

Android i18n je postaven na zdrojovém systému. Řetězce jsou vyčleněny do res/values/strings.xml pro výchozí jazyk (obvykle angličtinu). Pro každý jazyk se vytvoří samostatný adresář: res/values-ru/strings.xml (ruština), res/values-de/strings.xml (němčina), res/values-fr/strings.xml (francouzština). Android automaticky vybírá řetězce na základě systémového jazyka zařízení (Locale.getDefault()). Pokud není přesné locale k dispozici, použije se základní verze (values/strings.xml).

// res/values/strings.xml (angličtina, výchozí)
<resources>
    <string name="welcome_title">Welcome!</string>
    <string name="items_count">%d item(s)</string>
</resources>

// res/values-ru/strings.xml (ruština)
<resources>
    <string name="welcome_title">Vítejte!</string>
    <plurals name="items_count">
        <item quantity="one">%d produkt</item>
        <item quantity="few">%d produkty</item>
        <item quantity="many">%d produktů</item>
    </plurals>
</resources>

// Kotlin kód
textView.text = getString(R.string.welcome_title)

// Pluralizace
val items = 5
textView.text = resources.getQuantityString(
    R.plurals.items_count, items, items
)

// Podpora RTL v kódu
textView.textDirection = View.TEXT_DIRECTION_LOCALE
// Manifest: supportsRtl="true"

RTL (Right-to-Left) — podpora jazyků, kde se text čte zprava doleva (arabština, hebrejština, urdu, perština). Android podporuje RTL prostřednictvím atributů android:layoutDirection a android:textDirection. V manifestu nastavte android:supportsRtl="true" — a Android automaticky zrcadlí rozvržení. NavDrawer, ikony zpět/vpřed, zarovnání textu by měly fungovat v obou směrech. V kódu používejte View.LAYOUT_DIRECTION_LOCALE a Gravity.START/END místo LEFT/RIGHT.

Lokalizované zdroje

Android Resource Qualifiers umožňují lokalizovat nejen řetězce, ale také obrázky (res/drawable-ru/), rozvržení (res/layout-ru/), animace, barvy. Pro arabštinu a hebrejštinu jsou potřeba samostatná rozvržení se zrcadlovým uspořádáním prvků — použijte res/layout-ar/ (arabština). Android také podporuje regionální varianty: values-rUS, values-rGB, values-de-DE. Qualifiers se kombinují: values-ldrtl-ru — ruština pro RTL displeje.

Regionální formáty: data, čísla, měny v iOS a Androidu

Datum a čas — jeden z klíčových aspektů i18n. Různé regiony používají různé formáty: Rusko — DD.MM.RRRR, USA — MM/DD/RRRR, Japonsko — RRRR.MM.DD. Použití pevného formátu (yyyy-MM-dd) pro zobrazení uživateli je chyba. V iOS použijte DateFormatter s Locale(identifier: locale), v Androidu — DateFormat.getDateInstance(DateFormat.SHORT, locale). Pro hlasové asistenty a AI vyhledávání by data měla být v ISO 8601 ve vnitřní reprezentaci.

Čísla a měny — v různých regionech různé oddělovače: 1,234.56 (USA) vs 1.234,56 (Rusko), 1 234,56 (Francie). iOS: NumberFormatter s .locale = locale. Android: DecimalFormat s DecimalFormatSymbols(locale). Pro měny: formát ¥1,234 (Japonsko) vs $1,234.56 (USA) vs 1 234,56 ₽ (Rusko). Nikdy neslučujte měnu a číslo ručně — používejte NumberFormatter.currencyCode a .currencySymbol.

Řazení (Collation) — abecední řazení se v různých jazycích liší. Ve španělštině «ch» následuje po «c». Ve švédštině je «ä» na konci abecedy. V němčině se «ß» řadí jako «ss». iOS: LocalizedComparison (String.localizedCompare). Android: Collator.getInstance(locale). Nikdy nepoužívejte compareTo() pro řetězce zobrazované uživateli — používá Unicode Code Point order, který nezohledňuje regionální pravidla.

Nejlepší postupy internacionalizace mobilních aplikací

Architektonické principy — začněte s i18n od prvního commitu. Každý řetězec v kódu by měl projít přes obalovou funkci (tr("key")), která neexistuje před nastavením i18n — to donutí vývojáře řetězce okamžitě vyčlenit. Nepoužívejte anglické řetězce jako klíče — při změně formulace v angličtině byste museli aktualizovat všechny překlady. Používejte smysluplné klíče: «profile.title», «settings.language.label».

Pseudolokalizace — technika testování i18n před skutečným překladem. Nahraďte každé latinské písmeno diakritickými znaky (á, é, ñ, ü) pro kontrolu kódování, přidejte prefix [XXX] pro kontrolu ořezávání řetězců. Xcode: schémata spouštění — pseudojazyk «Double-Length Pseudolanguage». Android: Developer Options — Force RTL layout direction, System font scale až 200 %. Pseudolokalizace najde 80 % problémů i18n bez účasti překladatele.

Kontrolní seznam IT Sectr i18n — před vydáním kontrolujeme: (1) v kódu nejsou hardcoded řetězce (výjimka: logy), (2) pluralizace funguje správně pro všechny jazyky, (3) data/čísla jsou formátována přes Locale API, (4) rozvržení se správně zobrazuje v RTL jazycích, (5) řetězce se neořezávají při maximálním škálování, (6) pseudolokalizace neodhalila chyby, (7) všechny jazyky deklarované v obchodech mají kompletní sadu překladů.