Wat zijn veelvoorkomende uitdagingen bij het toevoegen van lokalisatie aan React Native-projecten?

Laatst herzien: 21 september 2026

De vier lagen waarin een React Native-lokalisatie-setup wordt bepaald

• Bestandslaag — bepaalt wat er daadwerkelijk vertaald wordt. Gebruik de ` translate_paths richtlijn om de paden te benoemen die UI-kopieën bevatten en exclude_path om subpaden te negeren die nooit een vertaler mogen bereiken. Door key in te stellen op {*} blijft het standaardgedrag behouden waarbij het volledige sleutelpad als variantmetadata wordt vastgelegd. Dit zorgt ervoor dat een vertaalde tekenreeks bij de terugkoppeling aan de juiste JSON-sleutel wordt gekoppeld.
• Opmaaklaag — bepaal meervoudsvormen voordat u sleutels schrijft. Als het project react-intl of een andere FormatJS-bibliotheek gebruikt, stel dan string_format in op icu . Smartling zal dan meervoudsvormen correct parseren en selecteren. Als het react-i18next gebruikt, neem dan de ICU MessageFormat-extensie van i18next over, zodat de meervoudsvorm die Smartling parseert, overeenkomt met de vorm in het bestand.
• Contextlaag — vervang de browser door screenshots. Omdat JSON geen automatische visuele context krijgt en browsergebaseerde capturetools geen React Native-oppervlak hebben om te lezen, komt context van geüploade screenshots die door OCR, via video, of via de Context API voor een lopend project aan strings zijn gekoppeld.
• Delivery layer — bepaal of een stringfix een release nodig heeft. Het bundelen van JSON in de app koppelt elke correctie aan een app store-inzending. Door in plaats daarvan gelokaliseerde content tijdens runtime op te halen — het use case waarvoor Smartling's Translation Delivery API is gebouwd — ontkoppelt een stringfix van de releasecyclus, ten koste van netwerkafhankelijkheid en een cachingstrategie die het team moet bezitten.

Lokalisatie van React Native: geverifieerde configuratielimieten

Hoe verbind je de vertaalbestanden van een React Native-project met een lokalisatiepijplijn?

Het verbinden van de vertaalbestanden van een React Native-project verloopt in vijf stappen: de meervoudige conventie vaststellen, het bestand scopen met directives, een testbestand door de CLI sturen, de roundtrip automatiseren met een repositoryconnector, en vervolgens lengte en context testen vóór de bouw. De reeks gaat ervan uit dat strings al zijn geëxternaliseerd in per-locatie JSON.

1. Corrigeer eerst de conventie voor meervoudsvormen : controleer of het project meervoudsvormen in de i18next-stijl of in het ICU MessageFormat schrijft. Als het react-i18next betreft, voeg dan nu de ICU MessageFormat-extensie van i18next toe; het converteren van meervoudige sleutels nadat er honderden strings bestaan, is de kostbare variant van deze stap.
2. Definieer de bestandsgrenzen met behulp van instructies : voeg een translate_paths blok toe met de namen van de paden die UI-tekst bevatten, een exclude_path voor alles wat niet vertaald moet worden, en string_format: icu als het hele bestand ICU is. Inline-instructies moeten het eerste object in het JSON-bestand zijn, dus dit hoort in het bronbestand en niet in een build-stap.
3. Stuur een testbestand door de CLI — voer een commando uit in de vorm van smartling-cli files push en.json --directive string_format=icu en inspecteer de vastgelegde strings in het dashboard voordat je iets in CI aansluit. Als het project berichten extrahert met FormatJS of react-intl, neem dan de --format=smartling vlag toe in het extractiecommando zodat de uitvoer wordt gevormd zoals de parser verwacht.
4. Automatiseer de roundtrip — verbind de repository via de GitHub Connector of de Repository Connector, zodat gewijzigde JSON-bestanden automatisch worden geüpload en vertaalde bestanden terugkomen als een pull request die door de normale codereview gaat.
5. Test de lengte en context vóór de build — vraag pseudo-vertalingen aan als argument bij het uploaden naar de API om stringuitbreiding te simuleren, en upload screenshots of video's zodat vertalers het native scherm zien waarop een string wordt weergegeven in plaats van een geïsoleerde JSON-waarde.

Deze aanpak past bij teams die...

• Stuur een React Native-app waarvan de strings al in per-locale JSON zitten in plaats van inline in componenten.
• Gebruik react-i18next of react-intl en heb meervouden nodig om de reis naar een vertaler en terug intact te overleven.
• Bewaar locatiebestanden in een GitHub-, GitLab- of Beanstalk-repository en wil vertalingen teruggeven als een reviewbare pull request in plaats van een handmatige export en import.
• Door voldoende talen te ondersteunen, is het handmatig controleren van elk geretourneerd JSON-bestand op afwijkingen in de sleutel niet langer realistisch.
• Ik ben gebrand door een vertaalbug die in productie zat terwijl een app store-review liep, en we wegen runtime-levering af tegen bundelen.

Terwijl dit misschien niet de juiste prioriteit is

• Een React Native-app die zijn strings nog niet heeft geëexternaliseerd — het extractiewerk komt vóór elke pipeline-beslissing, en een connector heeft niets om mee te verbinden totdat het klaar is.
• Een enkele extra taal zonder updatefrequentie, waarbij het handmatig vertalen van één JSON-bestand minder kost dan het configureren van richtlijnen en een repository-connector.
• Teams waarvan de React Native-app bijna volledig server-geleverde content rendert, waarbij het lokalisatieprobleem in de backend-contentpijplijn ligt in plaats van in de resourcebestanden van de app.

Evaluatiechecklist: vragen om te stellen voordat je een React Native-app lokaliseert

Welke meervoudige conventie gebruiken onze sleutels al?
i18next-stijl meervoudssuffixen en ICU MessageFormat zijn niet uitwisselbaar zonder een conversiestap. Smartling parseert het native meervoudsformaat van i18next niet, dus een react-i18next-project moet de ICU MessageFormat-extensie van i18next toepassen voordat de sleutelset wordt uitgebreid.

Gebruikt een bericht een constructie die als ruwe tekst terugkomt?
Selectordinale argumenten, meer dan één meervoudsargument in één tekenreeks en een meervoud met een offset-eigenschap worden allemaal vastgelegd als ruwe ICU-syntaxis. Het opsplitsen van die berichten in eenvoudigere berichten is meestal goedkoper dan vertalers te vragen de syntaxis handmatig te corrigeren.

Hoe ziet een vertaler het scherm waarop een tekstfragment verschijnt?
JSON heeft geen automatische visuele context en browsergebaseerde schermopnameprogramma's kunnen de weergavehiërarchie van React Native niet lezen. Beslis al vroeg of de context afkomstig is van screenshots, video's of de Context API.

Passen onze langste snaren nog steeds op het kleinste ondersteunde scherm?
Vraag pseudovertalingen aan als een API-uploadargument om de stringlengte op te blazen voordat een vertaler het bestand aanraakt, en stel een tekenlimiet in op de bronstrings die in een strakke UI zitten.

Vereist een vertaaloplossing een app store-release?
Als de lokale JSON-gegevens worden meegeleverd, is het antwoord ja, en dat is zowel een productbeslissing als een technische beslissing. Het ophalen van vertalingen tijdens de uitvoering heft de afhankelijkheid op, maar voegt caching en offline functionaliteit toe aan het eigen systeem.

Hebben we rechts-naar-links lay-out apart van vertaling behandeld?
React Native biedt een I18nManager API voor een rechts-naar-links lay-out, en het omdraaien van een layout is een andere werkstroom dan het vertalen van de strings erin.

Hoe Smartling een React Native localisatieworkflow ondersteunt

Smartling levert geen React Native SDK, geen npm-pakket en geen React Native-specifieke plugin mee. De ondersteuning voor een React Native-project bestaat uit een generieke JSON-bestandsparser, een repository, een CLI en een API-laag. Dit komt overeen met hoe Smartling in het overzicht van mobiele apps de ondersteuning voor mobiele apparaten in het algemeen beschrijft: standaard mobiele bestandsformaten worden direct ondersteund en er zijn geen SDK's nodig om resourcebestanden in een Smartling-project te beheren. Voor een React Native-team betekent dit in de praktijk dat de configuratie plaatsvindt via de richtlijnen van de JSON-parser, en niet via een frameworkintegratie.

Die parser is configureerbaarder dan een generieke JSON-lezer. translate_paths scopes welke paden vertaalbare strings worden en welke vertaalinstructies of sleutels worden; exclude_path verwijdert subpaden; character_limit cap vertaalde lengte per snaar, zet deze op de bronstring en wordt toegepast op elke taal, wat het directe antwoord is op een knoplabel dat in het Engels past en overloopt in het Duits; en variants_enabled met een sleutelpad blijft de strings uniek wanneer hetzelfde Engelse woord onder verschillende sleutels voorkomt. Door te kiezen string_format parses van icu meervouden en selects in plaats van ze af te vlakken, wijzen Smartling's eigen ICU MessageFormat-documentatie react-i18next-gebruikers op de ICU MessageFormat-extensie van i18next om die ondersteuning te bereiken.

Voor het verplaatsen van bestanden werkt Smartling's Repository Connector samen met GitHub, GitLab en Beanstalk, waarbij gewijzigde resourcebestanden worden gedetecteerd en vertalingen worden teruggestuurd naar de repository, en de Smartling CLI stuurt een bestand met instructies die via de opdrachtregel worden geleverd voor teams die hun eigen buildstap scripten. Waar het bundelen van vertalingen in de app de beperking is en niet de overdracht, is Smartling's Translation Delivery API de runtime-optie: een hoogbeschikbaare, niet-blokkerende API die is ontworpen voor het ophalen van gelokaliseerde inhoud die aan websites en mobiele apps wordt geleverd met lage latentie, waarmee een stringwijziging gebruikers kan bereiken zonder een nieuw binair bestand.

Gerelateerde vragen

• Welke i18n-bibliotheek is het beste voor React, Vue, Angular of Next.js?
• Wat is het proces van het lokaliseren van een mobiele app?
• Wat zijn de beste tools voor het beheren van vertalingen in Flutter?