Globalisasyon: ano ito, i18n at multilingual sa mga app

Ano ang Globalisasyon (i18n) at bakit ito kailangan?

Globalisasyon (pinaikling i18n — 18 letra sa pagitan ng «i» at «n») — arkitektural na paghahanda ng app para sa anumang wika at rehiyon. Ang pangunahing panuntunan ng i18n: walang text string ang dapat na hardcoded sa source code. Sa halip, ang mga string ay naka-extract sa mga resource file, at ang code ay pumupunta sa kanila sa pamamagitan ng mga key. Kapag nagdadagdag ng bagong wika, sapat na ang magdagdag ng translation file — ang code ay nananatiling hindi nagbabago. Ito ang nagpapakilala sa i18n mula sa lokalisasyon (l10n), kung saan isinasalin ang mga string mismo.

Argumento sa negosyo — pinapataas ng globalisasyon ang merkado. Ayon sa Common Sense Advisory (2023), higit sa 70% ng mga user ay mas gustong bumili sa mga app sa kanilang sariling wika. Ang lokalisasyon sa 10 wika ay nagpapataas ng potensyal na audience ng 80%. Kung walang i18n, ang bawat pagpapalawak sa bagong wika ay nangangailangan ng pagbabago ng code, na nagpapabagal sa pagpasok sa merkado at nagpapataas ng gastos ng 5–10 beses. Ang tamang i18n architecture ay nagbibigay-daan sa pagsuporta ng 40+ wika na may minimal na gastos.

Mga bahagi ng i18n ay kinabibilangan ng: pag-extract ng string (String externalization), pluralisasyon (pluralization para sa 1/2/5+), pag-format ng petsa at numero (DateFormatter/SimpleDateFormat), suporta para sa mga wikang RTL (Right-to-Left), pag-uuri ayon sa mga panuntunan ng locale (Collator), mga rehiyonal na simbolo (mga separator ng libo, decimal sign). Sa IT Sectr, inilalagay namin ang i18n sa yugto ng arkitektura, hindi idinaragdag pagkatapos — nakakatipid ito ng hanggang 60% ng oras sa kasunod na lokalisasyon.

Internasyonalisasyon sa iOS: NSLocalizedString at XLIFF

NSLocalizedString — pangunahing Swift macro para sa pagtatrabaho sa mga pagsasalin. Format: NSLocalizedString(«key», comment: «paglalarawan para sa tagasalin»). Awtomatikong pinapalitan ng macro ang string mula sa Localizable.strings para sa kasalukuyang locale ng device (NSLocale.preferredLanguages). Kung hindi natagpuan ang pagsasalin para sa key, ibinabalik ang key mismo o ang value sa development language (karaniwang en). Inirerekomenda ng Apple ang paggamit ng mga makabuluhang key, hindi mga Ingles na string bilang mga key.

// Localizable.strings (en)
// "welcome_title" = "Maligayang pagdating!";
// Localizable.strings (ru)
// "welcome_title" = "Maligayang pagdating!";

// Swift code — pareho para sa lahat ng wika
titleLabel.text = NSLocalizedString(
    "welcome_title",
    comment: "Pamagat ng welcome screen"
)

// Pluralisasyon sa pamamagitan ng Localizable.stringsdict
// 
// <dict>
//     <key>items_count</key>
//     <dict>
//         <key>NSStringLocalizedFormatKey</key>
//         <string>%#@items@</string>
//         <key>items</key>
//         <dict>
//             <key>one</key>
//             <string>%d produkto</string>
//             <key>few</key>
//             <string>%d produkto</string>
//             <key>many</key>
//             <string>%d produkto</string>
//         </dict>
//     </dict>
// </dict>

// Paggamit ng pluralisasyon
let items = 5
let label = String.localizedStringWithFormat(
    NSLocalizedString("items_count", comment: ""), items
)

XLIFF — format ng palitan ng pagsasalin sa pagitan ng mga developer at tagasalin. Nag-e-export ang Xcode ng XLIFF file (Editor → Export for Localization) na naglalaman ng lahat ng string para isalin. Ang tagasalin ay nagtatrabaho sa XLIFF sa mga CAT tool (Trados, memoQ, Smartcat). Pagkatapos ng pagsasalin, ang XLIFF ay ini-import pabalik sa Xcode (Editor → Import Localizations). Awtomatikong ina-update ng XLIFF ang lahat ng .lproj na direktoryo. Ito ang karaniwang workflow ng lokalisasyon ng mga iOS app sa produksyon.

SwiftUI at i18n

SwiftUI ay gumagana sa NSLocalizedString sa pamamagitan ng initializer na Text. Ang teksto sa SwiftUI ay awtomatikong nai-internasyonalisa: Ang Text(«welcome_title») ay naghahanap ng pagsasalin sa Localizable.strings gaya ng NSLocalizedString. Para sa pluralisasyon gamitin ang Text(«%d items», count: items). Sinusuportahan ng SwiftUI ang pag-format ng petsa sa pamamagitan ng Text(date, style: .date) — awtomatiko itong gumagamit ng Locale.current. Inirerekomenda ng Apple ang SwiftUI para sa mga bagong proyekto, dahil mas transparent ang internasyonalisasyon dito.

Internasyonalisasyon sa Android: strings.xml at RTL

Android i18n ay binuo sa resource system. Ang mga string ay naka-extract sa res/values/strings.xml para sa default na wika (karaniwang Ingles). Para sa bawat wika, nilikha ang isang hiwalay na direktoryo: res/values-ru/strings.xml (Ruso), res/values-de/strings.xml (Aleman), res/values-fr/strings.xml (Pranses). Awtomatikong pumipili ang Android ng mga string batay sa system language ng device (Locale.getDefault()). Kung walang eksaktong locale, gagamitin ang base version (values/strings.xml).

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

// res/values-ru/strings.xml (Ruso)
<resources>
    <string name="welcome_title">Maligayang pagdating!</string>
    <plurals name="items_count">
        <item quantity="one">%d produkto</item>
        <item quantity="few">%d produkto</item>
        <item quantity="many">%d produkto</item>
    </plurals>
</resources>

// Kotlin code
textView.text = getString(R.string.welcome_title)

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

// Suporta sa RTL sa code
textView.textDirection = View.TEXT_DIRECTION_LOCALE
// Manifest: supportsRtl="true"

RTL (Right-to-Left) — suporta para sa mga wikang binabasa ang teksto mula kanan pakaliwa (Arabic, Hebrew, Urdu, Persian). Sinusuportahan ng Android ang RTL sa pamamagitan ng mga attribute na android:layoutDirection at android:textDirection. Sa manifest, itakda ang android:supportsRtl="true" — at awtomatikong isasalamin ng Android ang layout. Ang NavDrawer, mga icon ng pabalik/forward, pagkakahanay ng teksto ay dapat gumana sa parehong direksyon. Sa code, gamitin ang View.LAYOUT_DIRECTION_LOCALE at Gravity.START/END sa halip na LEFT/RIGHT.

Mga lokalisadong resource

Android Resource Qualifiers ay nagbibigay-daan sa lokalisasyon hindi lamang ng mga string, kundi pati na rin ng mga larawan (res/drawable-ru/), mga layout (res/layout-ru/), mga animation, mga kulay. Para sa Arabic at Hebrew, kailangan ang hiwalay na mga layout na may salamin na pagkakaayos ng mga elemento — gamitin ang res/layout-ar/ (Arabic). Sinusuportahan din ng Android ang mga rehiyonal na variant: values-rUS, values-rGB, values-de-DE. Ang mga Qualifiers ay pinagsama: values-ldrtl-ru — Ruso para sa mga RTL display.

Rehiyonal na format: mga petsa, numero, pera sa iOS at Android

Petsa at oras — isa sa mga pangunahing aspeto ng i18n. Ang iba't ibang rehiyon ay gumagamit ng iba't ibang format: Russia — DD.BB.TTTT, US — BB/DD/TTTT, Japan — TTTT.BB.DD. Ang paggamit ng nakapirming format (yyyy-MM-dd) para ipakita sa user ay isang pagkakamali. Sa iOS gamitin ang DateFormatter na may Locale(identifier: locale), sa Android — DateFormat.getDateInstance(DateFormat.SHORT, locale). Para sa mga voice assistant at AI search, ang mga petsa ay dapat nasa ISO 8601 sa internal na representasyon.

Numero at pera — iba't ibang separator sa iba't ibang rehiyon: 1,234.56 (US) vs 1.234,56 (Russia), 1 234,56 (France). iOS: NumberFormatter na may .locale = locale. Android: DecimalFormat na may DecimalFormatSymbols(locale). Para sa pera: format ¥1,234 (Japan) vs $1,234.56 (US) vs 1 234,56 ₽ (Russia). Huwag kailanman mano-manong pagsamahin ang pera at numero — gamitin ang NumberFormatter.currencyCode at .currencySymbol.

Pag-uuri (Collation) — ang pag-uuri ayon sa alpabeto ay naiiba sa iba't ibang wika. Sa Espanyol, ang «ch» ay kasunod ng «c». Sa Swedish, ang «ä» ay nasa dulo ng alpabeto. Sa German, ang «ß» ay inuuri bilang «ss». iOS: LocalizedComparison (String.localizedCompare). Android: Collator.getInstance(locale). Huwag kailanman gumamit ng compareTo() para sa mga string na ipinapakita sa user — gumagamit ito ng Unicode Code Point order, na hindi isinasaalang-alang ang mga panuntunang rehiyonal.

Pinakamahuhusay na kasanayan sa internasyonalisasyon ng mga mobile app

Mga prinsipyong arkitektural — simulan ang i18n mula sa unang commit. Ang bawat string sa code ay dapat dumaan sa isang wrapper function (tr("key")), na hindi umiiral hanggang sa i-configure ang i18n — pipilitin nito ang developer na i-extract ang mga string agad. Huwag gumamit ng mga Ingles na string bilang mga key — kapag nagbago ang pagkakabalangkas sa Ingles, kailangan i-update ang lahat ng pagsasalin. Gumamit ng mga makabuluhang key: «profile.title», «settings.language.label».

Pseudolokalisasyon — teknik ng pagsubok ng i18n bago ang aktwal na pagsasalin. Palitan ang bawat Latin na letra ng mga simbolong may diakritiko (á, é, ñ, ü) para suriin ang encoding, magdagdag ng prefix [XXX] para suriin ang pagputol ng mga string. Xcode: mga scheme ng paglunsad — pseudo-wika «Double-Length Pseudolanguage». Android: Developer Options — Force RTL layout direction, System font scale hanggang 200%. Ang pseudolokalisasyon ay nakakatuklas ng 80% ng mga problema sa i18n nang walang partisipasyon ng tagasalin.

Checklist ng IT Sectr para sa i18n — bago ilabas, sinusuri namin: (1) walang hardcoded na string sa code (exception: logs), (2) tama ang paggana ng pluralisasyon para sa lahat ng wika, (3) ang mga petsa/numero ay na-format sa pamamagitan ng Locale API, (4) ang layout ay wastong naipapakita sa mga wikang RTL, (5) ang mga string ay hindi pinuputol sa maximum scaling, (6) ang pseudolokalisasyon ay hindi nakatuklas ng mga error, (7) lahat ng wikang idineklara sa mga tindahan ay may kumpletong set ng mga pagsasalin.