Globalization: cos'è, i18n e multilinguismo nelle app

Cos'è Globalization (i18n) e a cosa serve?

Globalization (abbreviato i18n — 18 lettere tra "i" e "n") è la preparazione architetturale di un'applicazione a funzionare con qualsiasi lingua e regione. La regola chiave di i18n: nessuna stringa di testo deve essere hardcodata nel codice sorgente. Invece, le stringhe vengono estratte in file di risorse e il codice vi accede tramite chiavi. Quando si aggiunge una nuova lingua, basta aggiungere un file di traduzione — il codice rimane invariato. Questo distingue i18n dalla localizzazione (l10n), dove le stringhe stesse vengono tradotte.

Argomento di business — la globalizzazione espande il mercato. Secondo Common Sense Advisory (2023), oltre il 70% degli utenti preferisce acquistare in app nella propria lingua madre. La localizzazione in 10 lingue aumenta il pubblico potenziale dell'80%. Senza i18n, ogni espansione in una nuova lingua richiede modifiche al codice, rallentando il time-to-market e aumentando i costi di 5–10 volte. Una corretta architettura i18n consente di supportare 40+ lingue con costi minimi.

Componenti di i18n includono: esternalizzazione delle stringhe, pluralizzazione (per 1/2/5+), formattazione di date e numeri (DateFormatter/SimpleDateFormat), supporto per lingue RTL (Right-to-Left), ordinamento secondo regole della locale (Collator), simboli regionali (separatori delle migliaia, decimali). In IT Sectr, implementiamo i18n in fase di architettura, non dopo — questo fa risparmiare fino al 60% di tempo nella successiva localizzazione.

Internazionalizzazione in iOS: NSLocalizedString e XLIFF

NSLocalizedString è la macro Swift principale per lavorare con le traduzioni. Formato: NSLocalizedString("key", comment: "descrizione per il traduttore"). La macro sostituisce automaticamente la stringa da Localizable.strings per la locale corrente del dispositivo (NSLocale.preferredLanguages). Se non viene trovata alcuna traduzione per la chiave, viene restituita la chiave stessa o il valore nella lingua di sviluppo (di solito en). Apple raccomanda di usare chiavi significative invece di stringhe inglesi come chiavi.

// Localizable.strings (en)
// "welcome_title" = "Welcome!";
// Localizable.strings (ru)
// "welcome_title" = "Benvenuto!";

// Codice Swift — unificato per tutte le lingue
titleLabel.text = NSLocalizedString(
    "welcome_title",
    comment: "Titolo schermata di benvenuto"
)

// Plurali tramite Localizable.stringsdict
// 
// <dict>
//     <key>items_count</key>
//     <dict>
//         <key>NSStringLocalizedFormatKey</key>
//         <string>%#@items@</string>
//         <key>items</key>
//         <dict>
//             <key>one</key>
//             <string>%d prodotto</string>
//             <key>few</key>
//             <string>%d prodotti</string>
//             <key>many</key>
//             <string>%d prodotti</string>
//         </dict>
//     </dict>
// </dict>

// Uso dei plurali
let items = 5
let label = String.localizedStringWithFormat(
    NSLocalizedString("items_count", comment: ""), items
)

XLIFF — formato di scambio di traduzioni tra sviluppatori e traduttori. Xcode esporta un file XLIFF (Editor → Export for Localization) contenente tutte le stringhe da tradurre. Il traduttore lavora con XLIFF in strumenti CAT (Trados, memoQ, Smartcat). Dopo la traduzione, XLIFF viene reimportato in Xcode (Editor → Import Localizations). XLIFF aggiorna automaticamente tutte le directory .lproj. Questo è il flusso di lavoro standard di localizzazione per le app iOS in produzione.

SwiftUI e i18n

SwiftUI funziona con NSLocalizedString tramite l'inizializzatore Text. Il testo in SwiftUI è automaticamente internazionalizzato: Text("welcome_title") cerca la traduzione in Localizable.strings proprio come NSLocalizedString. Per i plurali, usate Text("%d items", count: items). SwiftUI supporta la formattazione delle date tramite Text(date, style: .date) — usa automaticamente Locale.current. Apple raccomanda SwiftUI per i nuovi progetti poiché l'internazionalizzazione è più trasparente.

Internazionalizzazione in Android: strings.xml e RTL

Android i18n si basa sul sistema di risorse. Le stringhe sono inserite in res/values/strings.xml per la lingua predefinita (di solito inglese). Per ogni lingua viene creata una directory separata: res/values-ru/strings.xml (russo), res/values-de/strings.xml (tedesco), res/values-fr/strings.xml (francese). Android seleziona automaticamente le stringhe in base alla lingua di sistema del dispositivo (Locale.getDefault()). Se non viene trovata una locale esatta, viene usata la base (values/strings.xml).

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

// res/values-ru/strings.xml (russo)
<resources>
    <string name="welcome_title">Benvenuto!</string>
    <plurals name="items_count">
        <item quantity="one">%d articolo</item>
        <item quantity="few">%d articoli</item>
        <item quantity="many">%d articoli</item>
    </plurals>
</resources>

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

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

// Supporto RTL nel codice
textView.textDirection = View.TEXT_DIRECTION_LOCALE
// Manifest: supportsRtl="true"

RTL (Right-to-Left) — supporto per lingue in cui il testo si legge da destra a sinistra (arabo, ebraico, urdu, farsi). Android supporta RTL tramite gli attributi android:layoutDirection e android:textDirection. Nel manifesto, specificate android:supportsRtl="true" — e Android rispecchierà automaticamente il layout. NavDrawer, icone avanti/indietro, allineamento del testo devono funzionare in entrambe le direzioni. Nel codice, usate View.LAYOUT_DIRECTION_LOCALE e Gravity.START/END invece di LEFT/RIGHT.

Risorse localizzate

Android Resource Qualifiers consentono di localizzare non solo le stringhe ma anche immagini (res/drawable-ru/), layout (res/layout-ru/), animazioni, colori. Per arabo ed ebraico sono necessari layout separati con elementi speculari — usate res/layout-ar/ (arabo). Android supporta anche varianti regionali: values-rUS, values-rGB, values-de-DE. I qualificatori possono essere combinati: values-ldrtl-ru — russo per display RTL.

Formati regionali: date, numeri, valuta in iOS e Android

Date e ora — uno degli aspetti chiave di i18n. Regioni diverse usano formati diversi: Russia — DD.MM.AAAA, USA — MM/DD/AAAA, Giappone — AAAA.MM.DD. Usare un formato fisso (yyyy-MM-dd) per la visualizzazione all'utente è un errore. In iOS, usate DateFormatter con Locale(identifier: locale), in Android — DateFormat.getDateInstance(DateFormat.SHORT, locale). Per assistenti vocali e ricerca AI, le date devono essere in ISO 8601 internamente.

Numeri e valuta — regioni diverse hanno separatori diversi: 1,234.56 (USA) vs 1.234,56 (Russia), 1 234,56 (Francia). iOS: NumberFormatter con .locale = locale. Android: DecimalFormat con DecimalFormatSymbols(locale). Per le valute: formato ¥1,234 (Giappone) vs $1,234.56 (USA) vs 1 234,56 ₽ (Russia). Non concatenate mai valuta e numero manualmente — usate NumberFormatter.currencyCode e .currencySymbol.

Ordinamento (Collation) — l'ordinamento alfabetico differisce tra le lingue. In spagnolo, "ch" viene dopo "c". In svedese, "ä" è alla fine dell'alfabeto. In tedesco, "ß" viene ordinato come "ss". iOS: LocalizedComparison (String.localizedCompare). Android: Collator.getInstance(locale). Non usate mai compareTo() per stringhe visualizzate all'utente — usa l'ordine Unicode Code Point, che non considera le regole regionali.

Migliori pratiche di internazionalizzazione delle app mobili

Principi architetturali — iniziate i18n dal primo commit. Ogni stringa nel codice deve passare attraverso una funzione wrapper (tr("key")) che non esiste fino a quando i18n non è configurato — questo obbliga lo sviluppatore a esternalizzare le stringhe immediatamente. Non usate stringhe inglesi come chiavi — quando la formulazione inglese cambia, tutte le traduzioni devono essere aggiornate. Usate chiavi significative: "profile.title", "settings.language.label".

Pseudolocalizzazione — una tecnica di test di i18n prima della traduzione effettiva. Sostituite ogni lettera latina con caratteri diacritici (á, é, ñ, ü) per verificare la codifica, aggiungete un prefisso [XXX] per verificare il troncamento delle stringhe. Xcode: schemi di esecuzione — pseudo-lingua "Double-Length Pseudolanguage". Android: Opzioni sviluppatore — Forza direzione layout RTL, scala font di sistema fino al 200%. La pseudolocalizzazione trova l'80% dei problemi di i18n senza coinvolgere un traduttore.

Checklist i18n di IT Sectr — prima del rilascio verifichiamo: (1) nessuna stringa hardcodata nel codice (eccezione: log), (2) plurali funzionano correttamente per tutte le lingue, (3) date/numeri sono formattati tramite Locale API, (4) il layout viene visualizzato correttamente sulle lingue RTL, (5) le stringhe non vengono troncate alla scala massima, (6) la pseudolocalizzazione non ha rivelato errori, (7) tutte le lingue dichiarate negli store hanno un set completo di traduzioni.