Globalizáció: mi ez, i18n és többnyelvűség az alkalmazásokban

Mi a globalizáció (i18n) és miért van rá szükség?

Globalizáció (rövidítve i18n — 18 betű az «i» és «n» között) — az alkalmazás architekturális felkészítése bármely nyelvvel és régióval való munkára. Az i18n kulcsszabálya: egyetlen szöveges sztring sem lehet hardcoded a forráskódban. Ehelyett a sztringek erőforrásfájlokba kerülnek, és a kód kulcsokon keresztül hivatkozik rájuk. Új nyelv hozzáadásakor elég egy fordítási fájlt hozzáadni — a kód változatlan marad. Ez különbözteti meg az i18n-t a lokalizációtól (l10n), ahol magukat a sztringeket fordítják.

Üzleti érv — a globalizáció növeli a piacot. A Common Sense Advisory (2023) szerint a felhasználók több mint 70%-a szívesebben vásárol az anyanyelvén elérhető alkalmazásokban. A 10 nyelvre történő lokalizáció 80%-kal növeli a potenciális közönséget. i18n nélkül minden új nyelvre való bővítés kódmódosítást igényel, ami lelassítja a piacra lépést és 5–10-szeresére növeli a költségeket. A helyes i18n architektúra lehetővé teszi 40+ nyelv támogatását minimális költséggel.

Az i18n összetevői magukban foglalják: sztringek kiszervezése (String externalization), többes számú alakok (pluralization 1/2/5+ esetén), dátumok és számok formázása (DateFormatter/SimpleDateFormat), RTL nyelvek támogatása (Right-to-Left), locale szabályok szerinti rendezés (Collator), regionális szimbólumok (ezres elválasztók, tizedes jelek). Az IT Sectr-nél az i18n-t az architektúra szakaszban építjük be, nem utólag — ez akár 60% időt takarít meg a későbbi lokalizáció során.

Nemzetköziesítés iOS-ben: NSLocalizedString és XLIFF

NSLocalizedString — a fordítással való munkához használt fő Swift makró. Formátum: NSLocalizedString(«key», comment: «leírás a fordítónak»). A makró automatikusan behelyettesíti a sztringet a Localizable.strings-ből az eszköz aktuális locale-ja szerint (NSLocale.preferredLanguages). Ha a kulcshoz nem található fordítás, maga a kulcs vagy a development language értéke (általában en) kerül visszaadásra. Az Apple értelmes kulcsok használatát javasolja, nem angol sztringek kulcsként való használatát.

// Localizable.strings (en)
// "welcome_title" = "Üdvözöljük!";
// Localizable.strings (ru)
// "welcome_title" = "Üdvözöljük!";

// Swift kód — egységes minden nyelvhez
titleLabel.text = NSLocalizedString(
    "welcome_title",
    comment: "Üdvözlőképernyő címe"
)

// Többes számok a Localizable.stringsdict segítségével
// 
// <dict>
//     <key>items_count</key>
//     <dict>
//         <key>NSStringLocalizedFormatKey</key>
//         <string>%#@items@</string>
//         <key>items</key>
//         <dict>
//             <key>one</key>
//             <string>%d termék</string>
//             <key>few</key>
//             <string>%d termék</string>
//             <key>many</key>
//             <string>%d termék</string>
//         </dict>
//     </dict>
// </dict>

// Többes számok használata
let items = 5
let label = String.localizedStringWithFormat(
    NSLocalizedString("items_count", comment: ""), items
)

XLIFF — fordítások cseréjére szolgáló formátum a fejlesztők és fordítók között. Az Xcode XLIFF fájlt exportál (Editor → Export for Localization), amely az összes fordítandó sztringet tartalmazza. A fordító CAT eszközökben (Trados, memoQ, Smartcat) dolgozik az XLIFF-fel. Fordítás után az XLIFF visszaimportálásra kerül az Xcode-ba (Editor → Import Localizations). Az XLIFF automatikusan frissíti az összes .lproj könyvtárat. Ez a szabványos munkafolyamat az iOS alkalmazások lokalizációjához éles környezetben.

SwiftUI és i18n

A SwiftUI a Text inicializátoron keresztül dolgozik az NSLocalizedString-gel. A SwiftUI-ben a szöveg automatikusan nemzetköziesített: a Text(«welcome_title») ugyanúgy keresi a fordítást a Localizable.strings-ben, mint az NSLocalizedString. A többes számú alakokhoz használja a Text(«%d items», count: items) parancsot. A SwiftUI támogatja a dátumformázást a Text(date, style: .date) segítségével — automatikusan a Locale.current-et használja. Az Apple a SwiftUI-t ajánlja új projektekhez, mivel a nemzetköziesítés átláthatóbb benne.

Nemzetköziesítés Android-ben: strings.xml és RTL

Android i18n az erőforrásrendszerre épül. A sztringek a res/values/strings.xml fájlba kerülnek az alapértelmezett nyelvhez (általában angol). Minden nyelvhez külön könyvtár jön létre: res/values-ru/strings.xml (orosz), res/values-de/strings.xml (német), res/values-fr/strings.xml (francia). Az Android automatikusan kiválasztja a sztringeket az eszköz rendszernyelvének megfelelően (Locale.getDefault()). Ha nincs pontos locale, az alapverzió (values/strings.xml) kerül használatra.

// res/values/strings.xml (angol, alapértelmezett)
<resources>
    <string name="welcome_title">Welcome!</string>
    <string name="items_count">%d item(s)</string>
</resources>

// res/values-ru/strings.xml (orosz)
<resources>
    <string name="welcome_title">Üdvözöljük!</string>
    <plurals name="items_count">
        <item quantity="one">%d termék</item>
        <item quantity="few">%d termék</item>
        <item quantity="many">%d termék</item>
    </plurals>
</resources>

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

// Többes számok
val items = 5
textView.text = resources.getQuantityString(
    R.plurals.items_count, items, items
)

// RTL támogatás a kódban
textView.textDirection = View.TEXT_DIRECTION_LOCALE
// Manifest: supportsRtl="true"

RTL (Right-to-Left) — a jobbról balra olvasandó nyelvek támogatása (arab, héber, urdu, perzsa). Az Android az android:layoutDirection és android:textDirection attribútumokon keresztül támogatja az RTL-t. A manifestben állítsa be az android:supportsRtl="true" értéket — és az Android automatikusan tükrözi a layout-ot. A NavDrawer, a vissza/előre ikonok, a szövegigazítás mindkét irányban működnie kell. A kódban a LEFT/RIGHT helyett használja a View.LAYOUT_DIRECTION_LOCALE és Gravity.START/END értékeket.

Lokalizált erőforrások

Az Android Resource Qualifiers lehetővé teszi nemcsak a sztringek, hanem a képek (res/drawable-ru/), layout-ok (res/layout-ru/), animációk, színek lokalizációját is. Az arabhoz és héberhez külön layout-ok szükségesek az elemek tükrözött elrendezésével — használja a res/layout-ar/ (arab) könyvtárat. Az Android regionális változatokat is támogat: values-rUS, values-rGB, values-de-DE. A Qualifiers kombinálható: values-ldrtl-ru — orosz RTL kijelzőkhöz.

Regionális formátumok: dátumok, számok, pénznemek iOS-ben és Android-ben

Dátum és idő — az i18n egyik kulcsfontosságú aspektusa. Különböző régiók különböző formátumokat használnak: Oroszország — ÉÉ.HH.NNNN, USA — HH/ÉÉ/NNNN, Japán — NNNN.HH.ÉÉ. Fix formátum (yyyy-MM-dd) használata a felhasználó számára történő megjelenítéshez hiba. iOS-ben a DateFormatter használata Locale(identifier: locale) paraméterrel, Android-ben a DateFormat.getDateInstance(DateFormat.SHORT, locale). Hangasszisztensek és AI-keresés esetén a dátumoknak belső reprezentációban ISO 8601 formátumban kell lenniük.

Számok és pénznemek — különböző régiókban különböző elválasztók: 1,234.56 (USA) vs 1.234,56 (Oroszország), 1 234,56 (Franciaország). iOS: NumberFormatter .locale = locale paraméterrel. Android: DecimalFormat DecimalFormatSymbols(locale) paraméterrel. Pénznemek esetén: formátum ¥1,234 (Japán) vs $1,234.56 (USA) vs 1 234,56 ₽ (Oroszország). Soha ne fűzze össze manuálisan a pénznemet és a számot — használja a NumberFormatter.currencyCode és .currencySymbol tulajdonságokat.

Rendezés (Collation) — a betűrendes rendezés nyelvenként eltérő. Spanyolban a «ch» a «c» után következik. Svédben az «ä» az ábécé végén található. Németben a «ß» úgy rendeződik, mint az «ss». iOS: LocalizedComparison (String.localizedCompare). Android: Collator.getInstance(locale). Soha ne használja a compareTo() függvényt a felhasználónak megjelenített sztringekhez — Unicode Code Point order-t használ, amely nem veszi figyelembe a regionális szabályokat.

A mobilalkalmazások nemzetköziesítésének legjobb gyakorlatai

Architekturális alapelvek — kezdje az i18n-t az első commit-től. A kódban minden sztringnek át kell mennie egy wrapper függvényen (tr("key")), amely az i18n beállításáig nem létezik — ez arra kényszeríti a fejlesztőt, hogy azonnal kiszervezze a sztringeket. Ne használjon angol sztringeket kulcsként — ha az angol megfogalmazás megváltozik, az összes fordítást frissíteni kell. Használjon értelmes kulcsokat: «profile.title», «settings.language.label».

Ál-lokalizáció — az i18n tesztelésének technikája a tényleges fordítás előtt. Cseréljen ki minden latin betűt diakritikus jelekkel (á, é, ñ, ü) a kódolás ellenőrzéséhez, adjon hozzá [XXX] előtagot a sztringek levágásának ellenőrzéséhez. Xcode: indítási sémák — «Double-Length Pseudolanguage» ál-nyelv. Android: Developer Options — Force RTL layout direction, System font scale 200%-ig. Az ál-lokalizáció a fordító részvétele nélkül találja meg az i18n problémák 80%-át.

IT Sectr i18n ellenőrzőlista — kiadás előtt ellenőrizzük: (1) nincs hardcoded sztring a kódban (kivétel: logok), (2) a többes számú alakok minden nyelven helyesen működnek, (3) a dátumok/számok Locale API-n keresztül formázódnak, (4) a layout helyesen jelenik meg RTL nyelveken, (5) a sztringek nem vágódnak le maximális skálázásnál, (6) az ál-lokalizáció nem talált hibákat, (7) az áruházakban deklarált összes nyelv rendelkezik teljes fordítási készlettel.