Internationalisering (i18n): voordelen, best practices en implementatietips

Wat is i18n?

Internationalisering (i18n) is het proces van het ontwerpen van software zodat deze kan worden aangepast aan verschillende talen en regio's zonder uw code te wijzigen. De bijnaam "i18n" komt van het feit dat er 18 letters tussen de "i" en de "n" staan bij internationalisering.

Zie i18n als het leggen van de basis voor:

• Lokalisatie (l10n): Het vertalen en aanpassen van uw content voor een specifieke markt.
• Globalisering (g11n): Coördinatie van productgereedheid en -activiteiten in verschillende markten.
  
  

In de praktijk gaat het er bij i18n om dat je ervoor zorgt dat je app het volgende aankan:

• Tekst in elke taal
• Datums, tijden, getallen en valuta's in het juiste formaat
• Regels voor meervoudsvormen die overeenkomen met de lokale grammatica
• Lay-outs die van rechts naar links worden geschreven (zoals Arabisch of Hebreeuws)

Waarom i18n belangrijk is

Vooraf investeren in i18n levert tastbare voordelen op voor uw engineering- en productteams:

• Lagere lokalisatiekosten: Het extraheren en vervangen van tekenreeksen is eenvoudiger wanneer vertaallogica vanaf het begin is ingebouwd.
• Snellere ontwikkeling: Gedeelde infrastructuur voor het beheren van strings vermindert toekomstig dubbel werk.
• Betere UX: Gebruikers zien content in hun taal, opgemaakt op een manier die natuurlijk aanvoelt.
• Schaalbaarheid: Apps kunnen in nieuwe markten worden gelanceerd met minder codewijzigingen.

i18n-implementatiepatronen in moderne apps

Hieronder staan enkele veelvoorkomende patronen voor het implementeren van i18n in apps van productiekwaliteit. We lopen door React (frontend), iOS en Android.

Ongeacht het platform komen vertalingen meestal uit een vertaalbeheersysteem (TMS) zoals Smartling als JSON of bronbestanden. Deze bestanden worden vervolgens tijdens runtime door uw app geladen via een i18n-framework of native lokalisatie-API, zodat de juiste tekenreeksen worden weergegeven voor de taal of landinstelling van de gebruiker.

Frontend (reageren)

Moderne React-apps gebruiken meestal een speciale i18n-bibliotheek. Twee van de meest populaire zijn i18next en FormatJS, die beide framework-agnostisch zijn. In React zijn hun respectievelijke implementaties react-i18next (function en hook-based) en react-intl (component- en hook-based, gebouwd op ICU MessageFormat). Beide integreren netjes met bedrijfspijplijnen en verwerken meervoudsvorming, variabelen en landinstellingsbewuste opmaak.

1. Reageer met i18next + react-i18next

i18next is een van de meest populaire JavaScript i18n-bibliotheken, en in combinatie met de react-i18next-bindingen geeft het React-apps een krachtige, hook-vriendelijke API voor het laden en renderen van vertalingen.

In het onderstaande voorbeeld doorlopen we een veelvoorkomend i18n-patroon voor ondernemingen. We definiëren vertaalbestanden, initialiseren i18next bij het invoerpunt van de app en renderen vervolgens vertalingen in componenten. Deze aanpak werkt in verschillende frameworks, integreert netjes met de meeste vertaalbeheersystemen (TMS) en schaalt goed mee met uw app, of u nu statische tekenreeksen weergeeft of dynamische, variabele-gestuurde berichten zoals tellingen.

Voorbeeld i18n patroon: i18next + reacti18next

U ontvangt waarschijnlijk inhoud als JSON-bestanden van uw vertaalbeheersysteem. Het onderstaande voorbeeld van een JSON-bestand laat zien hoe vertalingen worden opgeslagen voor Engels. Elke invoer heeft een unieke sleutel en meervoudsvormen worden afzonderlijk gedefinieerd, zodat de bibliotheek de juiste kan kiezen op basis van de telling die u doorgeeft. Uw TMS genereert een overeenkomend bestand voor elke ondersteunde taal.

{

  "welcome": "Welcome",

  "visits_one": "Je hebt {{count}} keer bezocht.",

  "visits_other": "Je hebt {{count} keer bezocht."

}

Vervolgens ziet u een voorbeeld van hoe u i18next kunt configureren, zodat het weet welke talen uw app ondersteunt, waar de vertalingen te vinden zijn en wat te doen als er een vertaling ontbreekt. Dit installatiebestand wordt één keer uitgevoerd wanneer uw app wordt gestart (vaak in het invoerpuntbestand zoals index.js of main.tsx) zodat vertalingen klaar zijn voordat een gebruikersinterface wordt weergegeven. Door de configuratie op één plek te centraliseren, blijft uw lokalisatielogica consistent in uw app.

i18next importeren uit 'i18next';

importeer { initReactI18next } uit 'react-i18next';

import en from './locales/en/translation.json';

Importeer FR uit './locales/fr/translation.json';

const locale = 'fr'; in productie dynamisch oplossen

i18volgende

  .use(initReactI18next)

  .init({

    lng: locale,

    fallbackLng: 'en',

    Bronnen: {

      en: { translation: en },

      fr: { vertaling: fr }

    },

    interpolatie: { escapeValue: false }

  });

standaard exporteren i18next;

Zodra i18next is geïnitialiseerd, kunt u het overal in uw app gebruiken. In het onderstaande voorbeeld haalt de useTranslation-hook de t-functie op, die een sleutel en optionele variabelen nodig heeft om de juiste tekenreeks weer te geven. Wanneer u de telling als variabele doorgeeft, selecteert i18next automatisch de juiste meervoudsvorm op basis van het vertaalbestand.

importeer { useTranslation } uit 'react-i18next';

import './i18n';

exporteer standaardfunctie App() {

  const { t } = useTranslation();

  aantal cons = 3;

  retour (

    <>

      <h1>{t('welcome')}</h1>

      <p>{t('bezoeken', { count })}</p>

    </>

  );

}

2. Reageer met FOrmatJS + react-intl

react-intl maakt deel uit van het FormatJS-ecosysteem en biedt een componentgebaseerde benadering van i18n in React. Het is gebouwd op de ICU MessageFormat-standaard, dus u krijgt ingebouwde meervoudsvorming, datum-/getalnotatie en locale-fallback.

In het onderstaande voorbeeld stellen we vertaalbestanden in, verpakken we de app in een IntlProvider en renderen we gelokaliseerde tekst met behulp van FormattedMessage. Deze aanpak is zeer geschikt voor teams die een declaratieve, componentgestuurde stijl willen voor het omgaan met i18n in React.

Voorbeeld i18n patroon: FormatJS + react-intl

Het onderstaande JSON-bestand bevat vertalingen met behulp van ICU MessageFormat-syntaxis, die meervoudige logica in de tekenreeks zelf plaatst. Dit houdt alle taalregels op één plek en stelt vertalers in staat om de grammatica volledig te controleren zonder tussenkomst van de ontwikkelaar. Uw TMS beheert deze bestanden per landinstelling.

{

  "welcome": "Welcome",

Vervolgens ziet u een voorbeeld van het inpakken van uw app in het onderdeel IntlProvider . Dit is een eenmalige installatie, meestal gedaan in een root component zoals Root.tsx of index.jsx. Het maakt de actieve landinstelling en de bijbehorende berichten beschikbaar in uw app, zodat elk onderdeel ze kan gebruiken zonder extra import.

importeer { IntlProvider } van 'react-intl';

import en from './locales/en.json';

Importeren van fr uit './locales/fr.json';

const MESSAGES = { en, fr };

const locale = 'fr';

exporteer standaardfunctie Root() {

  retour (

    <IntlProvider locale={locale} messages={MESSAGES[locale]}>

      <App />

    </IntlProvider>

  );

}

Lees ten slotte hieronder om te zien hoe de component FormattedMessage een vertaling opzoekt aan de hand van de ID en automatisch meervoud afhandelt. Het enige dat u hoeft door te geven, is de telling en de bibliotheek past de juiste taalregels van uw JSON-bestand toe.

importeer { FormattedMessage } van 'react-intl';

exporteer standaardfunctie App() {

  aantal cons = 3;

  retour (

    <>

      <h1><FormattedMessage id="welcome" defaultMessage="Welcome" /></h1>

      <p><FormattedMessage id="visits" values={{ count }} /></p>

    </>

  );

}

Een paar extra tips voor productiegebruik:

• Lokale bron: Bepaal in echte apps de landinstelling centraal (bijvoorbeeld via een URL zoals /fr/*, het profiel van de gebruiker of een door de server opgegeven instelling) en geef deze door aan <IntlProvider>.
• Organisatie van berichten: Splits berichtbestanden op voor schaal per domein of functie (bijv. auth.json, dashboard.json) en voeg ze samen voor de actieve landinstelling.
• Terugval: defaultMessage is uw vangnet tijdens de implementatie: houd het in uw brontaal.
• Asynchroon laden (optioneel): Voor grote bundels importeert u dynamisch berichtbestanden per landinstelling (code-split) voordat u <IntlProvider> rendert.

Ios

iOS biedt je standaard solide lokalisatietools, maar netjes schalen naar veel landinstellingen vereist een doordachte implementatie van i18n best practices. Anders kunt u zonder een duidelijke structuur eindigen met dubbele sleutels, inconsistente opmaak en vertaalbestanden die een hoofdpijn worden om te onderhouden. De sleutel is om in een vroeg stadium een paar structurele beslissingen te nemen, zodat uw lokalisatie georganiseerd blijft en gemakkelijk kan worden uitgebreid als er nieuwe markten worden toegevoegd.

Tip 1: Organiseer resources op een manier die schaalbaar is

Een goede plek om te beginnen is met String Catalogs (.xcstrings) in Xcode 15 en hoger, of .strings/.stringsdict bestanden als u een oudere opstelling gebruikt. Deze werken goed met een TMS, die u meestal vertalingen in XLIFF-formaat stuurt. U kunt die rechtstreeks in uw catalogus importeren en het systeem zal het zware werk van het samenvoegen en beheren aankunnen.

U zult het waarschijnlijk gemakkelijker vinden om dingen netjes te houden als u catalogi organiseert op functie of module. Kleinere, gerichte bestanden maken het eenvoudiger om sleutels te vinden, wijzigingen te beoordelen en werk over te dragen aan vertalers. Hier is een voorbeeld van hoe u ze zou willen ordenen:

Hulpbronnen

  i18n/

    Auth.xcstrings

    Afrekenen.xcstrings

    Profiel.xcstrings

Tip 2: Behandel meervoud in de catalogus, niet in code

Meervoud is een andere plaats waar structuur loont. Het is beter om alle meervoudsregels in de catalogus te definiëren in plaats van in Swift, zodat uw code alleen variabelen doorgeeft en automatisch de juiste zin voor elke taal wordt gekozen. Zo zou dat eruit kunnen zien in de catalogus:

Sleutel: unread_messages

Formaat: Meervoud

Eén: "%d ongelezen bericht"

Andere: "%d ongelezen berichten"

En hier is hoe u het in Swift kunt gebruiken:

laat unreadCount = 3

let format = Tekenreeks(gelokaliseerd: "unread_messages")

let message = String.localizedStringWithFormat(formaat, ongelezenAantal)

"3 ongelezen berichten"

Op deze manier hoeft u geen grammatica in code te coderen en kunnen vertalers de details voor elke taal goed krijgen.

Tip 3: Centraliseer de opmaak voor getallen, datums en valuta's

U wilt ook de getal-, datum- en valutanotatie centraliseren, zodat elk onderdeel van de app consistent aanvoelt. Een gedeeld hulpprogramma of dienst kan daarbij helpen. Hier is een eenvoudig voorbeeld met behulp van de moderne FormatStyle-API van Swift :

Laat prijs = 19,99

let display = price.formatted(.currency(code: "EUR"))

"€ 19,99" of "19,99 €", afhankelijk van de locatie

Door uw tekenreeksbronnen georganiseerd te houden, meervoudsvorming in de catalogus te verwerken en al uw landinstellingsbewuste opmaak te centraliseren, stelt u uw iOS-app in om te groeien zonder extra onderhoudswerk te creëren. Als die praktijken eenmaal zijn ingevoerd, wordt het proces voor het toevoegen van nieuwe talen veel voorspelbaarder en veel minder stressvol. Laten we nu eens kijken naar Android, dat zijn eigen ingebouwde lokalisatietools biedt.

Android

Het bronnensysteem van Android is al ontworpen met het oog op lokalisatie, maar het vergt enige planning om het in vele talen te onderhouden. Als je alles in één groot bestand bewaart of grammaticaregels in code verspreidt, kan het snel rommelig worden. Geef in plaats daarvan prioriteit aan een bestandsgesegmenteerde organisatie, definieer alle grammaticaregels in XML en zorg ervoor dat uw opmaak en lay-outs werken voor elk schrijfsysteem dat u wilt ondersteunen.

Tip 1: Houd bronnen geordend op functie

Voor de meeste teams zullen vertalingen afkomstig zijn van een TMS als XLIFF-bestanden. U importeert deze in de res/values-mappen voor elke landinstelling, en Android zorgt ervoor dat de juiste tekenreeksen worden afgestemd op de taal van de gebruiker.

Het opsplitsen van uw bronnen in afzonderlijke bestanden per functie is een eenvoudige manier om het leven gemakkelijker te maken. Kleinere bestanden maken het sneller om wijzigingen te beoordelen en helpen samenvoegingsconflicten te voorkomen.

app/src/main/res/

  values/strings_auth.xml

  values/strings_checkout.xml

  values/plurals_checkout.xml

Tip 2: Definieer grammaticaregels in bronnen, niet in code

Net als in iOS is meervoud een van die dingen die je het beste kunt regelen in bronnen, zodat vertalers het per taal kunnen aanpassen zonder dat je de code hoeft te wijzigen. Hier is een voorbeeld van een meervoudsbron in het Engels:

<plurals name="checkout_cart_items_count">

    <item quantity="one">%1$d item</item>

    <item quantity="andere">%1$d items</item>

</plurals>

En hier is hoe je het zou gebruiken in Kotlin:

val msg = resources.getQuantityString(

    R.plurals.checkout_cart_items_count, tellen, tellen

)

Op deze manier blijft onze code schoon en kiest Android automatisch het juiste formulier op basis van de landinstelling.

Tip 3: Gebruik opmaak met behoud van landinstellingen 

Voor lay-outs is het een goede gewoonte om begin en einde te gebruiken in plaats van links en rechts , zodat ze zich aanpassen voor talen die van rechts naar links worden geschreven, zoals Arabisch of Hebreeuws:

<LinearLayout

    android:paddingStart="16dp"

    android:paddingEnd="16dp"

    android:layout_width="match_parent"

    android:layout_height="wrap_content">

</LinearLayout>

En wanneer u getallen of valuta's opmaakt, geeft u de huidige landinstelling van de app door, zodat alles er consistent uitziet:

val appLocale = LocaleListCompat.getAdjustedDefault()[0] ?: Locale.getDefault()

val price = NumberFormat.getCurrencyInstance(appLocale).format(1234.56)

"$ 1,234.56" of "1 234,56 €"

Uiteindelijk gaat het er bij het goed krijgen van Android i18n vooral om dat het platform het zware werk doet. Door alle tekst in bronnen te bewaren, die bronnen te structureren met landspecifieke mappen en vanaf de eerste dag RTL en locale-aware opmaak in te bouwen, vermijdt u de veelvoorkomende valkuilen die lokalisatie broos maken. Veel van deze principes komen overeen met de best practices van iOS, maar dankzij het resourcekwalificatiesysteem van Android kun je vaak nieuwe talen ondersteunen door simpelweg de juiste bestanden toe te voegen. Als het goed wordt gedaan, wordt opschalen naar nieuwe locaties een voorspelbaar proces met weinig moeite.

Veelvoorkomende i18n-valkuilen

Helaas lopen zelfs goed gebouwde systemen soms tegen vermijdbare problemen aan. De onderstaande tabel geeft een overzicht van enkele van de meest voorkomende misstappen, waarom ze problemen veroorzaken en hoe u ze kunt voorkomen. Beschouw dit als een snelle referentie die u kunt gebruiken om uw eigen instellingen te controleren voordat u deze verzendt.

Voorbereiden op lokalisatie op schaal

Zodra uw app is ingesteld voor internationalisering, is de volgende stap om lokalisatie zo efficiënt en onderhoudsarm mogelijk te maken. Een paar automatiseringstools en workflows kunnen u van "we kunnen vertalen" naar "we kunnen snel nieuwe talen uitrollen, zonder extra ontwikkelingsbelasting". Overwegen:

• Het gebruik van een Translation Management System (TMS) met een API op bedrijfsniveau, zoals Smartling, om vertaalbestanden te synchroniseren en revisieworkflows te beheren.
• Het automatiseren van stringextractie en -levering met behulp van uw CI/CD-pijplijn.
• Het gebruik van AI-tools (zoals de AI Hub van Smartling) voor snelle, first-pass vertalingen met ingebouwde kwaliteitscontroles zoals fallback-afhandeling en beperking van hallucinaties.

Laatste gedachten

Internationalisering is een fundamentele praktijk voor elk product dat wereldwijd gaat, en hoe eerder u het implementeert, hoe minder hoofdpijn u later zult hebben. Combineer solide i18n-werkwijzen met vertaalautomatisering en testworkflows, en uw team is goed uitgerust om sneller en met meer vertrouwen internationaal voorbereide software te leveren.

Wil je dieper gaan? Bekijk Smartling's Global Ready Conference webinar over i18n strategie in het tijdperk van AI.