Globalisering: vad är det, i18n och flerspråkighet i appar

Vad är globalisering (i18n) och varför behövs det?

Globalisering (förkortat i18n — 18 bokstäver mellan «i» och «n») — arkitektonisk förberedelse av appen för att fungera med vilket språk och region som helst. Huvudregeln för i18n: ingen textsträng får vara hårdkodad (hardcoded) i källkoden. Istället extraheras strängarna till resursfiler och koden kommer åt dem via nycklar. När ett nytt språk läggs till räcker det att lägga till en översättningsfil — koden förblir oförändrad. Detta skiljer i18n från lokalisering (l10n), där själva strängarna översätts.

Affärsargument — globalisering ökar marknaden. Enligt Common Sense Advisory (2023) föredrar över 70 % av användarna att handla i appar på sitt modersmål. Lokalisering till 10 språk ökar den potentiella publiken med 80 %. Utan i18n kräver varje utökning till ett nytt språk kodändringar, vilket saktar ner marknadsinträdet och ökar kostnaden 5–10 gånger. Rätt i18n-arkitektur gör det möjligt att stödja 40+ språk med minimala kostnader.

i18n-komponenter inkluderar: externisering av strängar (String externalization), pluralformer (pluralization för 1/2/5+), formatering av datum och tal (DateFormatter/SimpleDateFormat), stöd för RTL-språk (Right-to-Left), sortering enligt locale-regler (Collator), regionala symboler (tusentalsavskiljare, decimaltecken). Hos IT Sectr bygger vi in i18n i arkitekturfasen, inte i efterhand — detta sparar upp till 60 % tid vid senare lokalisering.

Internationalisering i iOS: NSLocalizedString och XLIFF

NSLocalizedString — det huvudsakliga Swift-makrot för att arbeta med översättningar. Format: NSLocalizedString(«key», comment: «beskrivning för översättaren»). Makrot ersätter automatiskt strängen från Localizable.strings för enhetens aktuella locale (NSLocale.preferredLanguages). Om ingen översättning hittas för nyckeln returneras själva nyckeln eller värdet på utvecklingsspråket (vanligtvis en). Apple rekommenderar att använda meningsfulla nycklar, inte engelska strängar som nycklar.

// Localizable.strings (en)
// "welcome_title" = "Välkommen!";
// Localizable.strings (ru)
// "welcome_title" = "Välkommen!";

// Swift-kod — enhetlig för alla språk
titleLabel.text = NSLocalizedString(
    "welcome_title",
    comment: "Titel på välkomstskärmen"
)

// Pluralformer via 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 produkter</string>
//             <key>many</key>
//             <string>%d produkter</string>
//         </dict>
//     </dict>
// </dict>

// Användning av pluralformer
let items = 5
let label = String.localizedStringWithFormat(
    NSLocalizedString("items_count", comment: ""), items
)

XLIFF — format för utbyte av översättningar mellan utvecklare och översättare. Xcode exporterar en XLIFF-fil (Editor → Export for Localization) som innehåller alla strängar som ska översättas. Översättaren arbetar med XLIFF i CAT-verktyg (Trados, memoQ, Smartcat). Efter översättning importeras XLIFF tillbaka till Xcode (Editor → Import Localizations). XLIFF uppdaterar automatiskt alla .lproj-kataloger. Detta är standardarbetsflödet för lokalisering av iOS-appar i produktion.

SwiftUI och i18n

SwiftUI arbetar med NSLocalizedString via Text-initieraren. Text i SwiftUI är automatiskt internationaliserad: Text(«welcome_title») söker efter översättning i Localizable.strings precis som NSLocalizedString. För pluralformer använd Text(«%d items», count: items). SwiftUI stöder datumformatering via Text(date, style: .date) — det använder automatiskt Locale.current. Apple rekommenderar SwiftUI för nya projekt eftersom internationalisering är mer transparent i det.

Internationalisering i Android: strings.xml och RTL

Android i18n bygger på resurssystemet. Strängar extraheras till res/values/strings.xml för standardspråket (vanligtvis engelska). För varje språk skapas en separat katalog: res/values-ru/strings.xml (ryska), res/values-de/strings.xml (tyska), res/values-fr/strings.xml (franska). Android väljer automatiskt strängar baserat på enhetens systemspråk (Locale.getDefault()). Om det inte finns någon exakt locale används basversionen (values/strings.xml).

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

// res/values-ru/strings.xml (ryska)
<resources>
    <string name="welcome_title">Välkommen!</string>
    <plurals name="items_count">
        <item quantity="one">%d produkt</item>
        <item quantity="few">%d produkter</item>
        <item quantity="many">%d produkter</item>
    </plurals>
</resources>

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

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

// RTL-stöd i kod
textView.textDirection = View.TEXT_DIRECTION_LOCALE
// Manifest: supportsRtl="true"

RTL (Right-to-Left) — stöd för språk där text läses från höger till vänster (arabiska, hebreiska, urdu, persiska). Android stöder RTL via attributen android:layoutDirection och android:textDirection. I manifestet anger du android:supportsRtl="true" — och Android speglar automatiskt layouten. NavDrawer, bakåt/framåt-ikoner, textjustering måste fungera i båda riktningarna. I koden använder du View.LAYOUT_DIRECTION_LOCALE och Gravity.START/END istället för LEFT/RIGHT.

Lokaliserade resurser

Android Resource Qualifiers gör det möjligt att lokalisera inte bara strängar utan även bilder (res/drawable-ru/), layouter (res/layout-ru/), animationer, färger. För arabiska och hebreiska behövs separata layouter med spegelvänd placering av element — använd res/layout-ar/ (arabiska). Android stöder även regionala varianter: values-rUS, values-rGB, values-de-DE. Qualifiers kombineras: values-ldrtl-ru — ryska för RTL-skärmar.

Regionala format: datum, tal, valuta i iOS och Android

Datum och tid — en av de viktigaste aspekterna av i18n. Olika regioner använder olika format: Ryssland — DD.MM.ÅÅÅÅ, USA — MM/DD/ÅÅÅÅ, Japan — ÅÅÅÅ.MM.DD. Att använda ett fast format (yyyy-MM-dd) för visning för användaren är ett misstag. I iOS använder du DateFormatter med Locale(identifier: locale), i Android — DateFormat.getDateInstance(DateFormat.SHORT, locale). För röstassistenter och AI-sökning bör datum vara i ISO 8601 i intern representation.

Tal och valuta — olika regioner har olika avskiljare: 1,234.56 (USA) vs 1.234,56 (Ryssland), 1 234,56 (Frankrike). iOS: NumberFormatter med .locale = locale. Android: DecimalFormat med DecimalFormatSymbols(locale). För valutor: format ¥1,234 (Japan) vs $1,234.56 (USA) vs 1 234,56 ₽ (Ryssland). Sammanfoga aldrig valuta och tal manuellt — använd NumberFormatter.currencyCode och .currencySymbol.

Sortering (Collation) — alfabetisk sortering skiljer sig mellan olika språk. På spanska kommer «ch» efter «c». På svenska finns «ä» i slutet av alfabetet. På tyska sorteras «ß» som «ss». iOS: LocalizedComparison (String.localizedCompare). Android: Collator.getInstance(locale). Använd aldrig compareTo() för strängar som visas för användaren — den använder Unicode Code Point order som inte tar hänsyn till regionala regler.

Bästa praxis för internationalisering av mobilappar

Arkitektoniska principer — börja med i18n från första commit. Varje sträng i koden bör gå igenom en wrapper-funktion (tr("key")) som inte finns innan i18n har konfigurerats — detta tvingar utvecklaren att omedelbart extrahera strängar. Använd inte engelska strängar som nycklar — när formuleringen på engelska ändras måste alla översättningar uppdateras. Använd meningsfulla nycklar: «profile.title», «settings.language.label».

Pseudolokalisering — teknik för att testa i18n före själva översättningen. Ersätt varje latinsk bokstav med diakritiska tecken (á, é, ñ, ü) för att kontrollera kodningen, lägg till prefix [XXX] för att kontrollera trunkering av strängar. Xcode: startscheman — pseudospråk «Double-Length Pseudolanguage». Android: Developer Options — Force RTL layout direction, System font scale upp till 200 %. Pseudolokalisering hittar 80 % av i18n-problemen utan översättarens medverkan.

IT Sectr i18n-checklista — före lansering kontrollerar vi: (1) inga hårdkodade strängar i koden (undantag: loggar), (2) pluralformer fungerar korrekt för alla språk, (3) datum/tal formateras via Locale API, (4) layout visas korrekt på RTL-språk, (5) strängar trunkeras inte vid maximal skalning, (6) pseudolokalisering har inte hittat fel, (7) alla språk som deklarerats i butikerna har en fullständig uppsättning översättningar.