Een praktische lokalisatieworkflow: organiseer vertaalsleutels, bepaal duidelijk eigenaarschap, behandel meervoudsvormen en voer QA uit zodat web- en native-UI niet faalt.
Onbeheerde lokalisatie faalt meestal eerst op kleine, irritante manieren en later op kostbare manieren. Een label dat gisteren paste, loopt vandaag over. Een ontbrekende sleutel verschijnt als een ruwe identifier. Een meervoud dat in het Engels goed klonk, wordt fout of zelfs onbeleefd in een andere taal.
De meeste teams repareren onder druk dezelfde problemen:\n\n- Afgeknotte knoppen, geknipte koppen of tekst die iconen overlapt\n- Ontbrekende sleutels die terugvallen naar Engels of de sleutenaam tonen\n- Verkeerde meervoudsvormen (bijvoorbeeld "1 items") en gebroken grammatica in talen met geslachtvormen\n- Inconsistente woordkeuze voor hetzelfde concept op verschillende schermen\n- Last-minute hotfixes omdat één scherm zonder vertalingen is opgeleverd\n Web- en native-schermen falen vaak op verschillende manieren. Op het web kunnen flexibele layouts problemen verbergen totdat een specifieke viewport of browser ze blootlegt. Tekst kan onverwacht doorlopen, knoppen naar beneden duwen of een grid breken. In native apps is de ruimte strikter. Een lange vertaling kan belangrijke elementen van het scherm duwen, botsen met toegankelijkheidslettergroottes of worden afgekapt omdat een component niet automatisch schaalt.
Een degelijke lokalisatieworkflow voorkomt het meeste hiervan door sleutels stabiel te maken, vertalingen controleerbaar en UI-controles routineus. Het helpt je updates te leveren met minder verrassingen. Wat het niet kan oplossen is onduidelijke brontekst. Als de originele copy vaag is (zoals "Open" of "Apply" zonder context), blijft de vertaling een gok.
Een simpele definitie van succes is niet "alles is vertaald." Het is:
Voorbeeld: als een winkelwagenscherm "{count} item(s)" toont, leiden onbeheerde strings tot ongemakkelijke meervouden en gebroken ruimteverdeling. Een beheerde aanpak dwingt correcte meervoudsregels af en ontdekt de knop die in het Duits 30% groeit vóór release.
Een lokalisatieworkflow valt het snelst uit elkaar wanneer niemand één vraag kan beantwoorden: “Welke tekst is de echte?” Kies één enkele bron van waarheid voor strings en maak dat uitermate duidelijk. Die bron kan een bestand in de repo zijn, een vertaalplatform of een interne tabel, maar het moet één plek zijn die elke discussie beslecht.
Definieer rollen op basis van beslissingen, niet functietitels. Iemand moet betekenis en toon goedkeuren (vaak Product of Marketing). Iemand moet sleutels stabiel en bruikbaar in code houden (vaak Engineering). Iemand moet UI-constraints beschermen (vaak Design), vooral wanneer web en native anders reageren.
Een verdeling die de meeste conflicten voorkomt:\n\n- Key creator: de persoon die het scherm uitrolt maakt nieuwe sleutels wanneer de UI nieuwe tekst nodig heeft.\n- Wording approver: een PM of copy-eigenaar keurt de brontaal goed.\n- Translation editor: vertalers mogen vertalingen aanpassen, maar mogen sleutels niet hernoemen.\n- Key changes: alleen de sleutel-eigenaar mag sleutels deprecaten of samenvoegen, met een notitie waarom.
Stel reactietijdverwachtingen zodat releases niet vastlopen. Bijvoorbeeld: nieuwe sleutelverzoeken binnen 1 werkdag bevestigen, goedkeuring van brontekst binnen 2 dagen, en kritieke fixes (gebroken UI, foutieve juridische tekst) binnen enkele uren.
Concreet voorbeeld: je team bouwt een nieuwe “Reset password”-flow voor web en native. De ontwikkelaar voegt sleutels toe, de PM keurt de Engelse tekst goed en vertalers vullen de andere talen in. Als een vertaler opmerkt dat “Reset” beter “Change” moet zijn, passen ze de vertaling aan, maar blijft de sleutel hetzelfde. Als de PM tekst wil hergebruiken, maakt alleen de sleutel-eigenaar die structurele wijziging zodat niets stilletjes breekt.
Een goede lokalisatieworkflow begint met één regel: sleutels zijn identifiers, geen Engelse zinnen. Behandel ze als onderdeelnummers. Als je later de bewoording verandert, moet de sleutel meestal hetzelfde blijven.
Maak een nieuwe sleutel wanneer de betekenis anders is. Hergebruik een sleutel wanneer de betekenis hetzelfde is, zelfs als het scherm anders is. “Opslaan” op een profielscherm en “Opslaan” in instellingen kunnen een sleutel delen als ze beide “wijzigingen bewaren” betekenen. Maar “Opslaan” in de zin van “bookmarken” moet een andere sleutel zijn, omdat vertalers mogelijk een ander werkwoord nodig hebben.
Scheid korte UI-labels van langere content. Een knoplabel, een helptekst en een foutmelding vertalen vaak anders en hebben verschillende lengtelimieten. Ze als aparte sleutels houden maakt het makkelijker de toon en interpunctie aan te passen zonder andere schermen te breken.
Streef naar hergebruik tussen web en native, maar forceer het niet wanneer platforms andere bewoording nodig hebben. Een native permissieprompt heeft vaak helderdere, formelere tekst nodig dan een webtooltip. Gebruik in dat geval platform-specifieke sleutels zodat elke UI natuurlijker leest.
Een praktisch patroon is sleutels te groeperen per feature en UI-type, en dan hergebruik binnen die grenzen toe te passen:\n\n- Hergebruik binnen dezelfde feature als de betekenis identiek is\n- Splits sleutels per UI-type (label vs help vs error vs system prompt)\n- Gebruik platformvarianten alleen als de bewoording moet verschillen\n- Houd sleutels stabiel en wijzig alleen de weergegeven tekst\n- Voeg contextnotities toe (waar het verschijnt, karakterlimieten)
Bijvoorbeeld: dezelfde “Delete customer”-actie kan bestaan in een web adminpaneel en een native veldapp. Je kunt de kernactie-label hergebruiken, maar een aparte sleutel voor native bevestiging houden als die sterkere waarschuwingen of kortere regels nodig heeft.
Een goed naamgevingssysteem maakt lokalisatie in de beste zin saai. Mensen vinden snel strings, vertalers krijgen context en sleutels blijven stabiel zelfs als copy verandert.
Gebruik een leesbare conventie die vier vragen beantwoordt: waar is het, wat is het, waarvoor is het, en is het een variant. Een simpel patroon dat werkt over web en native heen is:
\u003cproduct_or_domain\u003e.\u003cscreen_or_flow\u003e.\u003ccomponent\u003e.\u003cpurpose\u003e[.\u003cvariant\u003e]
Bijvoorbeeld, in een klantenportaal: portal.login.button.submit of portal.orders.empty_state.title. Dit houdt sleutels gegroepeerd per scherm of flow en toch makkelijk te doorzoeken per component.
Slechte sleutels zijn of te vaag of te veel gebonden aan de huidige Engelse tekst:\n\n- Goed: portal.profile.field.email.label\n- Fout: emailText (geen scope, geen intentie)\n- Fout: please_enter_your_email (breekt als copy verandert)\n- Goed: portal.checkout.error.payment_failed\n- Fout: error_12
Varianten moeten expliciet zijn, niet geforceerd met interpunctie of gemixte casing. Als je een korter label nodig hebt voor een strakke mobiele header, voeg een variant-suffix toe: ...title.short vs ...title.long. Als je case-verschillen nodig hebt, geef dan de voorkeur aan aparte sleutels zoals ...button.save en ...button.save_titlecase alleen wanneer het platform tekst niet veilig kan transformeren.
Plaatsholders hebben ook regels nodig zodat vertalers niet gokken.
{user_name}, {count}, {date}\n- Nooit concatenateren: bouw geen strings als "Hello " + name\n- Houd eenheden binnen de string wanneer taalafhankelijk: {count} items niet {count} + " items"\n- Definieer toegestane formaten: ISO-datums, valuta of platform-specifieke datumformattering\n- Voeg een korte notitie toe voor lastige strings (bijv. of {count} nul kan zijn)Meervoudsafhandeling is waar workflows meestal als eerste breken. Veel teams gaan ervan uit dat elke taal slechts "enkelvoud" en "meervoud" heeft, en ontdekken vervolgens dat de UI fout klinkt of last-minute fixes nodig heeft.
Talen kunnen meerdere meervoudscategorieën hebben. Het Engels gebruikt voornamelijk one en other, maar talen als Russisch, Pools, Arabisch en Tsjechisch gebruiken vormen als few, many of zero. Als je vroeg een enkel patroon hardcodeert, moet je later strings herschrijven voor web en native.
Kies één standaard voor meervoudsstrings en houd je er overal aan (web, iOS, Android, server-gerenderde tekst). Een praktische aanpak is één sleutel op te slaan met meervoudsvormen in plaats van aparte sleutels per vorm. Baseer de set vormen op CLDR-categorieën zodat het overeenkomt met echte taalkundige regels.
Een regel die herwerk voorkomt: bouw nooit UI-zinnen uit stukjes zoals "You have " + count + " messages". Woordvolgorde kan veranderen en sommige talen vereisen verschillende uitgangen of naamvallen afhankelijk van het nummer.
Voor een teller van berichten definieer je één stabiele sleutel en geef je het aantal als parameter. Bied vervolgens de vormen die vertalers voor elke taal nodig hebben.
inbox.message_count)\n- Ondersteun CLDR-vormen (zero, one, two, few, many, other)\n- Gebruik altijd placeholders (voorbeeld: {count}) binnen de volledige zin\n- Voeg vertalersnotities toe wanneer de betekenis onduidelijk is (is het "messages" of "unread messages"?)Soms zijn meervoudsregels niet genoeg. Als je UI een persoon aanspreekt ("Welcome, Alex") of verwijst naar rollen ("assigned to him/her"), hebben sommige talen verschillende woorden nodig op basis van geslacht. Andere talen veranderen uitgangen afhankelijk van grammaticale naamval (bijv. na bepaalde voorzetsels).
Maak in die gevallen aparte strings voor wezenlijk verschillende grammatica, niet alleen voor stijl. Het doel is minder sleutels, maar ook minder verrassingen tijdens QA wanneer een "correcte" vertaling toch vreemd leest in context.
Een vertaling kan correct zijn en toch de UI breken. Web en native apps renderen tekst verschillend, dus je workflow moet opmaakregels en layoutchecks bevatten, niet alleen vertaalde strings.
Standaardiseer hoe je nummers, geld en datums toont. Vermijd bouwen met concatenatie zoals "$" + amount of het hardcoden van een datumformat in een label. Gebruik locale-aware formatters zodat scheidingstekens en volgorde overeenkomen (1,000.50 vs 1 000,50; dag-maand-jaar vs maand-dag-jaar). Tijdzones zijn een veelgemaakte valkuil: bewaar timestamps in UTC, formatteer in de lokale zone van de gebruiker en wees duidelijk wanneer een tijd in een specifieke zone staat (zoals een afhaaltijd van een winkel).
Tekstrichting is een andere stille breker. Als je RTL-talen ondersteunt, plan dan gespiegeld ontwerp en interpunctie die lijkt te "verplaatsen." Iconen die richting impliceren (pijlen, terugknoppen, voortgangsstappen) moeten vaak omgekeerd worden. Maak een snelle RTL-check onderdeel van de review, zelfs als je nog niet volledig RTL ondersteunt.
Op mobiel kunnen lettertypen en spacing meer verschuiven dan op het web. Een string die op het web past, kan in SwiftUI of Kotlin ongelijkmatig wrappen. Bepaal een veilige minimumlettergrootte, laat labels wrappen waar dat zinvol is en definieer fallback-lettertypen voor scripts die je standaardlettertype niet dekt.
Toegankelijkheid heeft ook gelokaliseerde checks nodig. Schermlezers kunnen nummers, afkortingen en gemixte-taaltekst op verrassende manieren uitspreken.
Layout-guardrails die de meeste problemen voorkomen:\n\n- Ontwerp voor tekstexpansie (30–50%) en vermijd knoppen met vaste breedte.\n- Houd dynamische waarden (aantallen, prijzen, datums) als aparte geformatteerde tokens.\n- Gebruik platform-native datum- en nummerformatters, geen custom patronen.\n- Test één RTL-locale en één "lange tekst"-locale vóór release.\n- Voer schermlezerchecks uit op kernflows (login, checkout, instellingen).
Voorbeeld: een label "Total: $1,234.50" kan moeten worden "1 234,50 €" met het symbool achter de waarde, andere spatiëring en een schermlezer-vriendelijke pauze tussen "Total" en het bedrag.
Een lokalisatieworkflow moet eerder beginnen dan de meeste teams verwachten: terwijl het scherm nog wordt ontworpen. Als je wacht tot de UI "klaar" is, haast je vertalingen, lever je geknipte tekst of hardcodeer je strings "voor nu."
Begin door een vertaalsleutel toe te voegen tijdens het ontwerpen van elk label, knop en bericht. Schrijf de standaardtekst in je basistaal en voeg korte context toe zoals waar het verschijnt en wat de gebruiker wil doen. Een sleutel als checkout.pay_button is alleen nuttig als vertalers weten of het een werkwoord is ("Pay") of een label ("Payment").
Implementeer de UI met placeholders en de standaardtaal als fallback. Houd variabelen expliciet (zoals {name} of {count}) en vermijd het aan elkaar plakken van zinnen. Dat is een van de snelste manieren om grammatica over talen heen te breken.
Bij het versturen van strings voor vertaling, voeg toe wat vertalers nodig hebben om nauwkeurig te zijn: een screenshot per scherm (of een korte video als de tekst verandert), karakterlimieten voor krappe plekken (tabs, knoppen, badges), notities voor toon en terminologie, en een lijst met dynamische placeholders en hun betekenis.
Wanneer vertalingen terugkomen, merge ze vroeg en bouw zowel web- als native-versies. Doe snelle UI-checks op de risicovolle schermen: login, onboarding, checkout en instellingen. Let op geknipte tekst, overlappende elementen, ontbrekende sleutels en verkeerde meervoudsvormen.
Tenslotte, releasen en monitoren. Volg ontbrekende keys, fallback-naar-standaard evenementen en schermen waar tekst vaak overloopt.
Nauwkeurige vertalingen beginnen vóórdat één woord vertaald is. Als vertalers alleen een sleutel en een Engelse zin zien, gokken ze. Zo krijg je de juiste woorden op de verkeerde plek en een UI die vreemd of onbeleefd aanvoelt.
Een eenvoudig "contextpakket" haalt het meeste giswerk weg. Voor elke string voeg toe waar het verschijnt (scherm en component), wat de gebruiker probeert te doen en de toon (vriendelijk, formeel, dringend). Geef ook aan of het een knoplabel, foutmelding, menu-item of helptekst is. Die categorieën vertalen vaak anders.
Als ruimte schaars is, zeg dat van tevoren. Web en native schermen breken op verschillende manieren, dus definieer limieten waar dat telt: korte knoplabels, tabtitels, toastmeldingen en alles binnen een vaste kaart. Als een string op één regel moet blijven, geef dat aan. Als regeleinden toegestaan zijn, zeg waar ze veilig zijn.
Markeer "niet vertalen" onderdelen duidelijk. Productnamen, plan-namen, kortingscodes, API-velden en placeholders zoals {name} moeten intact blijven. Zonder richtlijn kunnen vertalers ze lokaliseren en raakt je app incoherent.
Een praktisch pakket per string:\n\n- Screenshot of schermnaam (bijv. "Checkout - Payment method")\n- Type en intentie (knop die betaling bevestigt)\n- Toonopmerking (kalm, geruststellend)\n- Beperkingen (max 18 tekens, enkele regel)\n- Beschermde tokens (productnamen, integraties, {amount})
Behandel juridische tekst en supportcontent als aparte stromen. Juridische copy heeft vaak goedkeuringsvereisten en langzamere updates, dus houd die gescheiden van product-UI-strings en versieer ze zorgvuldig. Supportartikelen en hulpsnippets hebben meestal langere vertalingen nodig en kunnen in een ander systeem of bestandenset leven.
Voorbeeld: een "Continue"-knop op mobiel heeft misschien een strengere limiet dan web. Als vertalers dat weten, kiezen ze in talen die uitzetten een korter werkwoord in plaats van een late UI-herontwerp.
UI-breuken door lokalisatie lijken zelden in eerste instantie op een "bug." Ze lijken op een ontbrekend label, een knop die in twee regels wrappend, of een placeholder die de verkeerde waarde toont. Een goede workflow bevat QA-stappen die die problemen vóór gebruikers zichtbaar maken.
Begin met pseudo-localisatie in development builds. Vervang echte strings door langere, geaccentueerde versies (zoals "[!!! Šéttïñĝš !!!]") en vergroot lengte met 30–50%. Dit legt snel truncatie, overlap en hardcoded strings bloot op zowel web als native schermen.
Voeg automatische checks toe aan elke build. Die vangen saaie fouten die mensen missen bij het reviewen van honderden regels:\n\n- Ontbrekende sleutels in een locale (fallbacks verbergen problemen tot later)\n- Ongebruikte sleutels (een teken dat je afdrijft en dode tekst shipt)\n- Placeholder-mismatches ("Hello, {name}" vs "Hello, {username}")\n- Ongeldige meervoudsvormen voor een locale (zero, one, few, many)\n- Verboden patronen zoals ruwe HTML in mobiele strings
Gebruik daarna een duidelijke handmatige goedkeuring. Product verifieert betekenis en toon voor sleutelschermen, terwijl QA layout en interactie controleert.
Houd de testmatrix klein maar strikt. Test niet alles. Test wat het eerst breekt: login/signup, wachtwoord-reset, checkout of betaalbevestiging, instellingen en profielbewerking, notificaties en empty states, en elk scherm met tabellen, badges of kleine knoppen.
Bij het rapporteren van issues, maak fixes makkelijk door specifiek te zijn. Voeg locale, apparaat- en OS-versie (of browser en breedte), verwachte tekst, daadwerkelijke tekst en een screenshot van het gebied toe. Als het meervoud of placeholders betreft, plak de exacte sleutel en de gerenderde string.
De meeste lokalisatiebugs zijn geen "vertaalfouten." Het zijn workflowproblemen die zich voordoen als gebroken UI, ontbrekende tekst of verwarrende berichten.
Een veelval is sleutels hernoemen wanneer je alleen de bewoording wilt veranderen. Sleutels moeten stabiele IDs zijn, geen tekst zelf. Als je checkout.button.pay verandert naar checkout.button.pay_now, worden alle oude vertalingen "ontbrekend" en verlies je geschiedenis. Houd de sleutel, werk de standaardtaal bij en voeg context toe als de betekenis verandert.
Een ander veelvoorkomend probleem is strings hardcoden op één platform. Het webteam gebruikt sleutels, maar het mobiele team plakt snel Engelse tekst erin voor een snelle fix. Een maand later zien gebruikers Engelstalige alerts op iOS. Maak "geen hardcoded user-facing strings" een gedeelde regel voor web en native.
Placeholders veroorzaken subtiele fouten wanneer je woordvolgorde aanneemt. Het Engels werkt met "{count} items", maar andere talen hebben mogelijk een andere volgorde of extra woorden nodig. Gebruik benoemde placeholders (geen positionele) en houd ze consistent over platforms.
Fouten die je vroeg wilt vangen:\n\n- Sleutels als copy behandelen en zo bestaande vertalingen breken. Houd sleutels stabiel.\n- Eén sleutel hergebruiken voor twee betekenissen. Splits sleutels bij verschillende intentie.\n- Gemengde placeholder-stijlen (sommige benoemd, sommige genummerd). Standaardiseer één stijl.\n- Alleen in het Engels testen. Controleer altijd minstens één lange-tekst-locale en één compacte-locale.\n- Uitbrengen zonder fallbackplan. Definieer wat gebeurt wanneer een sleutel ontbreekt.
Testen in slechts één "lange taal" is niet genoeg. Duits zet vaak uit, terwijl Chinees ruimteproblemen kan verbergen. Doe een snelle check op beide en test ook meervoud-edgecases zoals 0, 1 en 2.
Stem fallbackgedrag af vóór release. Bijvoorbeeld: als Frans ontbreekt, val terug op Engels, log ontbrekende keys en blokkeer de release alleen als kritieke schermen gaten hebben.
Een lokalisatieworkflow blijft gezond als de checks klein en herhaalbaar zijn. Het doel is simpel: minder verrassende strings, minder gebroken layouts, minder last-minute vertaalhaasten.
Voordat je een UI-wijziging merge, doe een snelle controle op de gebruikelijke "oeps"-issues:\n\n- Nieuwe sleutels volgen je naamgevingsregels en leven in de juiste namespace (scherm of feature).\n- Placeholders komen exact overeen tussen talen (zelfde variabelen, zelfde betekenis).\n- Meervoudsvormen zijn compleet voor de talen die je ondersteunt (niet alleen Engels enkelvoud/meervoud).\n- Er zitten geen hardcoded teksten meer in de UI (inclusief fout- en empty states).\n- Nieuwe of gewijzigde tekst heeft basiscontext vastgelegd (screenshot of duidelijke notitie).
Voordat je shipt, voer een korte release-QA uit gericht op de plekken waar lokalisatie het eerst breekt. Houd het time-boxed maar consequent: top-user-flows op elk platform dat je uitbrengt, één RTL-spotcheck, lange-tekstschermen (instellingen, juridische teksten, onboarding, tabellen, smalle knoppen) en datum-/nummer-/valutaformattering in een paar locales.
Stel een cadans in die bij je team past. Veel teams updaten vertalingen wekelijks en bevriezen strings 1–2 dagen vóór een release. Het punt is last-minute copy-aanpassingen en finale QA niet te mixen.
Volgende stappen met snel rendement: leg je conventies vast (sleutelnaamgeving, placeholders, meervoudsregels, eigenaarschap) en voer één pilotpagina end-to-end uit en pas aan op basis van wat breekt.
Als je bouwt over backend, web UI en native mobiel in één platform zoals AppMaster, is het makkelijker sleutels en placeholders consistent te houden omdat dezelfde schermen en logica één conventie kunnen delen. Dat stabiele conventiegevoel is wat lokalisatie routineus in plaats van fragiel maakt.
What’s the simplest way to stop localization from breaking my UI?Begin met één stabiele plek waar strings worden bewaard, één afgesproken regel voor sleutelnaamgeving en de regel dat sleutels niet veranderen alleen omdat de Engelse tekst verandert. Voeg vervolgens een kleine QA-routine toe die ontbrekende sleutels, overloop en meervoudsproblemen oppikt vóór release.
What does “single source of truth” mean for translations?Kies één systeem dat altijd doorslaggevend is bij conflicten, zoals vertaalbestanden in de repo of een export van een vertaalplatform. Maak duidelijk dat iedereen via die bron content bewerkt en dat de code die bron alleen consumeert.
Who should own keys, wording, and translations?Neem besluiten op basis van verantwoordelijkheid, niet op functietitel: één persoon keurt betekenis en toon in de basistaal goed, één persoon beheert sleutelstructuur en deprecated keys, en vertalers mogen alleen vertaalde waarden aanpassen. Dat voorkomt stille sleutelwijzigingen en last-minute copy-wijzigingen die builds breken.
When should I reuse a translation key vs create a new one?Maak een nieuwe sleutel wanneer de betekenis verandert, zelfs als de Engelse tekst op elkaar lijkt. Hergebruik een sleutel als de betekenis werkelijk identiek is op verschillende schermen; dat houdt vertalingen consistent en vermindert onderhoud.
How should I name and organize translation keys so they stay stable?Gebruik sleutels als identifiers, niet als Engelse zinnen, en voeg scope toe zoals feature, scherm/flow, component en doel. Een sleutel als portal.checkout.button.pay blijft nuttig, ook als de knoptekst later verandert.
What’s the right way to handle plurals across languages?Meervoudsafhandeling faalt vaak omdat veel talen meer hebben dan enkel enkelvoud en meervoud. Bewaar één sleutel per concept met de juiste meervoudscategorieën en houd {count} binnen de volledige zin zodat vertalers woorden veilig kunnen herschikken.
How do I avoid placeholder bugs like wrong names or broken grammar?Bouw geen zinnen door stukken aan elkaar te plakken zoals "Hello " + name, want woordvolgorde en uitgangen veranderen per taal. Gebruik consistente, benoemde placeholders zoals {user_name} en documenteer wat elke placeholder betekent.
How do I prevent truncated buttons and overlapping text on web and mobile?Reken op tekstuitbreiding van 30–50% en ontwerp componenten die kunnen wrappen of groeien waar dat logisch is. Test vervolgens één "lange tekst"-taal en toegankelijkheidslettergroottes op zowel web als native om knippen en overlapping vroeg te vinden.
What QA steps catch localization issues before users do?Pseudo-localiseer in development om hardcoded strings en layoutfouten te vinden, voeg build-checks toe voor ontbrekende keys, ongebruikte keys, placeholder-mismatches en ongeldige meervoudsregels. Houd handmatige reviews gericht op flows die het eerst breken, zoals login, checkout en instellingen.
What should we do when a translation key is missing right before release?Val terug op je basistaal en log ontbrekende keys zodat je snel gaten kunt dichten zonder elke release te blokkeren. Voor kritieke schermen of juridische tekst is het veiliger om release te blokkeren als vertalingen ontbreken of verouderd zijn.
21 jan 2026
8 min
20 jan 20268 min
20 jan 20267 minExperimenteer met AppMaster met gratis abonnement.
Als je er klaar voor bent, kun je het juiste abonnement kiezen.
