Een praktische Vue 3 i18n-workflow voor grote apps: naamgeving van sleutels, meervouden, QA-checks en releasestappen om ontbrekende vertalingen in productie te voorkomen.
Zodra je app een paar honderd strings heeft, is het eerste dat meestal stukgaat niet Vue I18n. Het is consistentie. Mensen voegen sleutels toe in verschillende stijlen, dupliceren hetzelfde idee onder andere namen en niemand weet zeker welke berichten veilig verwijderd kunnen worden.
Ontbrekende vertalingen worden ook minder zeldzaam. Ze verschijnen in normale gebruikerspaden, vooral op minder gebruikte schermen zoals instellingen, foutmeldingen, lege toestanden en notificaties.
Als een vertaling ontbreekt, zien gebruikers meestal één van drie fouten: een lege UI (een knop zonder label), ruwe sleutels (zoals checkout.pay_now) of een vreemde fallback waarbij een deel van de pagina van taal verandert. Geen van die gevallen voelt als een klein foutje. Ze laten de app kapot lijken.
Daarom is een Vue 3 i18n-workflow belangrijker dan de specifieke bibliotheek. De bibliotheek doet wat je vraagt. Op schaal zijn teams het vaak niet eens over wat “klaar” betekent.
Een veelvoorkomend voorbeeld: een ontwikkelaar levert een nieuwe "Invite teammate"-flow met 40 nieuwe strings. Het Engelse bestand wordt bijgewerkt, maar het Franse niet. In staging ziet alles er goed uit omdat de tester Engels gebruikt. In productie zien Franse gebruikers een mix van vertaalde en onvertaalde UI, en support krijgt screenshots van ruwe sleutels.
De oplossing is definiëren wat “klaar” betekent voor vertaalde UI. Het kan niet alleen zijn: "strings toegevoegd". Een praktische definitie van klaar bevat meestal: sleutels volgen naamgevingsregels, localisaties builden zonder missing-key-waarschuwingen, meervouden en variabelen renderen correct met echte data, minstens één niet-standaard locale is gecontroleerd en copy-wijzigingen worden gevolgd zodat oude sleutels niet blijven liggen.
Bij 500+ sleutels win je door lokalisatie te behandelen als een releaseproces, niet als een last-minute file edit.
Na een paar honderd strings is vertaalwerk niet het rommelige deel. Consistentie is dat wel. Een kleine set regels maakt je Vue 3 i18n-workflow voorspelbaar, zelfs wanneer meerdere mensen elke week aan copy sleutelen.
Begin met bepalen wat een “concept” is en houd één enkele bron van waarheid aan. Als hetzelfde UI-idee op vijf plaatsen verschijnt (bijvoorbeeld “Save changes”), wil je één sleutel, geen vijf variaties zoals save, saveChanges, save_update en saveBtn. Gedupliceerde sleutels drijven in betekenis uiteen en gebruikers voelen die inconsistentie.
Bepaal vervolgens waar formattering hoort te leven. Teams splitsen dit vaak per ongeluk: sommige berichten bevatten interpunctie en hoofdletters, andere vertrouwen op code om dat toe te voegen. Kies één aanpak en houd je eraan.
Een praktisch uitgangspunt:
Definieer daarna eigenaarschap. Bepaal wie nieuwe sleutels kan toevoegen, wie de basis-taalkopie reviewt en wie andere locales goedkeurt. Zonder dit worden strings gehaast toegevoegd en nooit nagekeken.
Tot slot, kies en documenteer een fallback-strategie. Als een sleutel ontbreekt, wat zien gebruikers dan: de sleutelnaam, de default-locale tekst of een veilige generieke boodschap? In productie geven veel teams de voorkeur aan terugvallen op de default-locale plus logging, zodat gebruikers niet worden geblokkeerd terwijl je toch een signaal krijgt dat er iets mis is.
Als je Vue 3-apps bouwt met een generator zoals AppMaster (Vue3 web UI plus real backend code), gelden deze regels nog steeds. Behandel vertalingen als productcontent, niet als "gewoon dev-tekst", en je voorkomt de meeste late verrassingen.
Na een paar honderd strings is consistentie de grootste multiplier. Kies één sleutelstijl (de meeste teams gebruiken dot paths zoals billing.invoice.title) en maak het een regel. Het mixen van dots, slashes, snake_case en willekeurige hoofdletters maakt zoeken en reviewen traag.
Gebruik stabiele sleutels die copy-wijzigingen overleven. Een sleutel als "Please enter your email" breekt zodra marketing de zin aanpast. Geef de voorkeur aan intent-gebaseerde namen zoals auth.email.required of auth.email.invalid.
Groepeer sleutels eerst op productgebied of UI-oppervlak en daarna op doel. Denk in dezelfde bakken als je app al heeft: auth, billing, settings, support, dashboard. Dit maakt locale-bestanden makkelijker door te nemen en reduceert duplicaten wanneer twee schermen hetzelfde idee nodig hebben.
Binnen elk domein, houd een kleine set patronen voor veelvoorkomende UI-onderdelen:
*.actions.save, *.actions.cancel*.fields.email.label, *.fields.password.label*.fields.email.hint*.errors.required, *.errors.invalidFormat*.notices.saved, *.notices.failedDynamische berichten moeten zeggen wat verandert, niet hoe. Noem het bericht op intentie en gebruik parameters voor de variabele delen. Bijvoorbeeld, billing.invoice.dueInDays met {days} is duidelijker dan billing.invoice.dueIn3Days.
Voorbeeld (werkt goed in een Vue 3 i18n-workflow): orders.summary.itemsCount met {count} voor het aantal, en orders.summary.total met {amount} voor geld. Wanneer iemand de sleutel in code leest, moet duidelijk zijn waar het hoort en waarom het bestaat, zelfs als de uiteindelijke copy later verandert.
Meervoudige teksten breken stilletjes als je elke taal als Engels behandelt. Bepaal vroeg wanneer je ICU message-syntax gebruikt en wanneer een eenvoudige placeholder genoeg is.
Gebruik simpele vervangingen voor labels en korte UI-tekst die niet verandert met aantallen (bijvoorbeeld, "Welcome, {name}"). Schakel over naar ICU voor alles wat op aantal gebaseerd is, omdat dat alle vormen op één plek houdt en de regels expliciet maakt.
{
"notifications.count": "{count, plural, =0 {No notifications} one {# notification} other {# notifications}}"
}
Schrijf aantalberichten zo dat ze makkelijk te vertalen zijn. Geef de voorkeur aan een volledige zin en houd de nummer-placeholder (#) dicht bij het zelfstandig naamwoord. Vermijd slimme shortcuts zoals hetzelfde sleutel hergebruiken voor “1 item” en “2 items” in code. Vertalers moeten het hele bericht zien, niet raden hoe het aan elkaar geplakt wordt.
Plan minstens voor =0, one en other, en documenteer wat je verwacht voor 0. Sommige producten willen “0 items”, anderen willen “No items”. Kies één stijl en houd je eraan zodat de UI consistent aanvoelt.
Let ook op talen met meer meervoudcategorieën dan je verwacht. Veel talen volgen niet simpelweg "one vs many". Als je later een nieuwe locale toevoegt, kan een bericht dat alleen one en other heeft grammaticaal verkeerd zijn, zelfs als het rendert.
Test meervouden vóór release met echte aantallen in de UI, niet alleen door naar JSON te kijken. Een snelle controle die de meeste problemen vangt is 0, 1, 2, 5 en 21.
Als je een Vue3 webapp bouwt (bijvoorbeeld binnen AppMaster), voer deze test uit op het daadwerkelijke scherm waar de tekst verschijnt. Lay-outproblemen, afgeknotte tekst en ongemakkelijke zinnen verschijnen daar eerst.
Na een paar honderd strings wordt één grote en.json een bottleneck. Mensen bewerken hetzelfde bestand, merge-conflicten groeien en je verliest het overzicht waar copy zich bevindt. Een goede structuur houdt je Vue 3 i18n-workflow stabiel, zelfs als het product blijft veranderen.
Voor 2 tot 5 locales is splitsen per feature meestal voldoende. Houd dezelfde bestandsindeling in elke locale zodat het toevoegen van een sleutel een voorspelbare bewerking is.
locales/en/common.json, locales/en/auth.json, locales/en/billing.jsonlocales/es/common.json, locales/es/auth.json, locales/es/billing.jsonlocales/index.ts (laadt en merge't berichten)Voor 20+ locales schaal je hetzelfde idee op maar maak je drift moeilijker. Behandel Engels als bron van waarheid en dwing af dat elke locale dezelfde mappen en bestandsnamen weerspiegelt. Als een nieuw domein verschijnt (bijvoorbeeld notifications), moet het bestaan voor elke locale, zelfs als de tekst tijdelijk is.
Splitsen per domein vermindert merge-conflicten omdat twee mensen strings aan verschillende bestanden kunnen toevoegen zonder elkaar in de weg te zitten. Domeinen moeten overeenkomen met hoe je app is opgebouwd: common, navigation, errors, settings, reports, plus feature-mappen voor grotere gebieden.
Binnen elk bestand, houd dezelfde sleutelstructuur over alle locales: dezelfde nesting, dezelfde sleutelnaam, andere tekst. Vermijd “creatieve” sleutels per taal, zelfs als een frase moeilijk te vertalen is. Als Engels billing.invoice.status.paid nodig heeft, moet elke locale exact die sleutel hebben.
Centraliseer alleen wat echt overal herhaald wordt: button-labels, generieke validatiefouten en globale navigatie. Houd feature-specifieke copy dicht bij het feature-domein, zelfs als het herbruikbaar lijkt. “Save” hoort in common. “Save payment method” hoort in billing.
Lange helpteksten, onboarding-stappen en e-mailtemplates worden snel rommelig. Een paar regels helpen:
help of onboarding) en vermijd diepe nesting.Deze setup maakt het makkelijker om wijzigingen te reviewen, geleidelijk te vertalen en verrassende hiaten net voor release te vermijden.
Een stabiele Vue 3 i18n-workflow draait minder om tools en meer om elk keer dezelfde kleine stappen herhalen. Nieuwe UI-tekst mag niet in productie komen zonder een sleutel, een default-bericht en een duidelijke vertaalstatus.
Begin met het toevoegen van de sleutel aan je basislocale (vaak en). Schrijf de default-tekst als echte copy, geen placeholder. Dit geeft product en QA iets leesbaars om te reviewen en voorkomt “mystery strings” later.
Wanneer je de sleutel in een component gebruikt, voeg dan vanaf dag één params en meervoudslogica toe zodat vertalers de volledige vorm van het bericht zien.
// simple param
$t('billing.invoiceDue', { date: formattedDate })
// plural
$t('files.selected', count, { count })
Als vertalingen nog niet klaar zijn, laat sleutels dan niet ontbreken. Voeg placeholder-vertalingen toe in andere locales of markeer ze als pending op een consistente manier (bijvoorbeeld, prefix de waarde met TODO:). Het belangrijke is dat de app voorspelbaar rendert en dat reviewers onafgewerkte copy kunnen vinden.
Voer vóór het mergen snelle geautomatiseerde checks uit. Houd ze saai en strikt: ontbrekende sleutels over locales, ongebruikte sleutels, placeholder-mismatch (ontbrekende {count}, {date} of verkeerde accolades), ongeldige meervoudsvormen voor ondersteunde talen en per ongeluk overschrijven. Dit alles kan de build laten falen.
Doe tenslotte een korte UI-check in minstens één niet-basislocale. Kies een taal met langere teksten (vaak Duits of Frans) om overflow, afgeknotte knoppen en onhandige regelafbrekingen te vinden. Als je Vue 3 UI gegenereerd is of samen met andere delen van een product wordt onderhouden (bijvoorbeeld een Vue3 webapp geproduceerd door AppMaster), blijft deze stap belangrijk omdat layouts veranderen als features evolueren.
Behandel deze stappen als jouw definitie van klaar voor elke feature die tekst toevoegt.
De snelste manier om lokalisatie pijnlijk te maken is i18n-sleutels behandelen als “gewoon strings”. Na een paar honderd sleutels veranderen kleine gewoonten in productiefouten.
Typfouten en verschillen in hoofdletters zijn klassieke oorzaken van ontbrekende tekst: checkout.title op de ene plek, Checkout.title op een andere. Het ziet er goed uit in code review, en dan verscheept je fallback-taal stilletjes.
Een ander veelvoorkomend probleem is één sleutel hergebruiken voor verschillende betekenissen. “Open” kan “Open ticket” betekenen op een supportscherm en “Open now” op een winkelpagina. Als je één sleutel hergebruikt, staat één van die schermen verkeerd in andere talen en gaan vertalers raden.
Een eenvoudige regel helpt: één sleutel = één betekenis. Als de betekenis verandert, maak dan een nieuwe sleutel, ook al is de Engelse tekst hetzelfde.
Teams hardcoden vaak interpunctie, spacing of stukjes HTML in vertalingen. Dat werkt totdat een taal andere interpunctie nodig heeft, of je UI markup anders ontduwt of rendert. Houd markup-beslissingen in templates en houd berichten gefocust op tekst.
Mobiel is waar problemen zich verbergen. Een label dat in het Engels past, kan in het Duits over drie regels doorlopen of in het Thais overflowen. Als je maar één schermgrootte test, mis je dat.
Let op herhalende fouten: Engelse woordvolgorde aannemen bij het invoegen van variabelen (namen, aantallen, datums), berichten opbouwen door stukken te concateneren in plaats van één bericht te gebruiken, niet testen met lange waarden (productnamen, adressen, foutdetails), verschepen met stille fallback ingeschakeld zodat ontbrekende sleutels er in het Engels "ok" uitzien en copy plakken terwijl alleen de Engelse waarde wordt aangepast.
Als je een Vue 3 i18n-workflow wilt die rustig blijft bij 500+ sleutels, behandel sleutels dan als onderdeel van je API: stabiel, specifiek en getest zoals alles andere.
Ontbrekende vertalingen zijn makkelijk te missen omdat de app nog steeds “werkt”. Hij valt alleen terug op de sleutel, de verkeerde locale of een lege string. Behandel vertaaldekking als tests: je wilt snelle feedback voordat iets in productie komt.
Begin met checks die de build laten falen, niet checks die waarschuwingen printen die niemand leest.
$t('...') en t('...') gebruik en verifieer dat elke gebruikte sleutel in de basislocale bestaat.Houd de uitzonderingslijst kort en in handen van het team, niet van “wat er door CI heen komt”.
Zelfs met CI wil je een vangnet in staging omdat echte gebruikerspaden strings triggeren die je vergat dynamisch te maken.
Schakel missing-translation-logging in staging aan en voeg voldoende context toe om snel te repareren: locale, route, componentnaam (indien beschikbaar) en de ontbrekende sleutel. Maak het luidruchtig. Als het makkelijk te negeren is, wordt het genegeerd.
Voeg een pseudo-locale toe en gebruik die voor een korte UI-check. Eén eenvoudige aanpak is elke string transformeren (maak het langer en voeg markers toe) zodat lay-outproblemen opvallen, bijvoorbeeld: [!!! 𝗧𝗲𝘅𝘁 𝗲𝗵𝗼𝗲𝗳𝗲𝗻𝗱 !!!]. Dit vangt afgeknipte knoppen, gebroken tabelheaders en ontbrekende spacing voordat je verscheept.
Doe tenslotte een korte pre-release spotcheck van je belangrijkste flows in 2-3 locales: aanmelden, afrekenen/betaling, kerninstellingen en de nieuwe feature die je uitrolt. Hier vind je bugs zoals “het is vertaald maar de placeholder is fout”.
Een nieuwe taal toevoegen wordt rommelig als je het ziet als “copy-werk” in plaats van een kleine productrelease. De makkelijkste manier om je Vue 3 i18n-workflow stabiel te houden is de app te laten builden zelfs als een locale incompleet is, maar toch hiaten duidelijk te maken voordat gebruikers ze zien.
Wanneer je een nieuwe locale toevoegt, begin met het genereren van dezelfde bestandsstructuur als je bronlocale (vaak en). Vertaal niet eerst, structureer eerst.
Vertalingen komen vaak laat, dus beslis op voorhand wat “gedeeltelijk” betekent voor je product. Als een feature klantgericht is, overweeg een feature-flag zodat feature en strings samen uitrollen. Als je zonder volledige vertalingen moet verschepen, geef dan de voorkeur aan een duidelijke fallback (zoals Engels) boven lege labels, maar maak het duidelijk in staging.
Copy-updates zijn waar teams sleutels breken. Als je formulering verandert, houd de sleutel stabiel. Sleutels moeten intent beschrijven, niet de exacte zin. Bewaar het hernoemen van sleutels voor wanneer de betekenis verandert, en doe dat dan met een gecontroleerde migratie.
Om “zombie strings” te vermijden, depreceer sleutels met opzet: markeer sleutels als deprecated met een datum en vervanger, houd ze één release-cyclus, en verwijder ze pas nadat je hebt bevestigd dat er geen referenties meer zijn.
Bewaar vertaalnotities dicht bij de sleutel. Als je JSON-formaat geen comments ondersteunt, bewaar notities in een klein begeleidend document of aangrenzend metadata-bestand (bijvoorbeeld, “gebruikt op checkout success screen”). Dit is vooral nuttig wanneer je Vue 3 webapp gegenereerd is met een tool zoals AppMaster en meerdere mensen aan copy en UI werken.
In één sprint levert je team drie dingen tegelijk: een nieuwe Settings-pagina, een Billing-scherm en drie e-mailtemplates (receipt, payment failed, trial ending). Dat zijn ongeveer 60 nieuwe strings en hier begint rommelige i18n meestal.
Het team stemt af om sleutels te groeperen per feature, dan per oppervlak. Er wordt een nieuw bestand gemaakt voor elk feature en sleutels volgen overal hetzelfde patroon: feature.area.element.
// settings
"settings.profile.title": "Profile",
"settings.security.mfa.enable": "Enable two-factor authentication",
// billing
"billing.plan.current": "Current plan",
"billing.invoice.count": "{count} invoice | {count} invoices",
// email
"email.receipt.subject": "Your receipt",
"email.payment_failed.cta": "Update payment method"
Voor de vertaalwerkzaamheden worden meervoudige strings getest met echte waarden, niet gokken. Voor billing.invoice.count controleert QA 0, 1, 2 en 5 met seeded data (of een simpele dev-toggle). Dit vangt ongemakkelijke gevallen vroeg, zoals "0 invoice".
QA draait daarna een gefocust pad dat vaak ontbrekende sleutels onthult: open Settings en Billing en klik elke tab eens, trigger elke e-mailtemplate in staging met testaccounts, draai de app met een niet-standaard locale actief en laat de build falen als er missing-translation-waarschuwingen in de logs verschijnen.
In deze sprint vindt QA twee ontbrekende sleutels: één label op het Billing-scherm en één e-mailonderwerp. Het team repareert ze vóór release.
Bij de beslissing om te blokkeren of fallback toe te staan, gebruiken ze een eenvoudige regel: klantgerichte schermen en transactionele e-mails blokkeren de release; laag-risico admin-tekst kan tijdelijk terugvallen naar de default-taal, maar alleen met een ticket en een duidelijke deadline.
Een Vue 3 i18n-workflow blijft stabiel als je vertalingen als code behandelt: voeg ze steeds op dezelfde manier toe, test ze en houd score bij.
Kies een paar eenvoudige cijfers en review die regelmatig: missing-key-rate in je testrun, onvertaalde string-aantal in niet-standaard locales en ongebruikte sleutel-aantal (strings die nergens meer verschijnen). Volg ze per release als je kunt, zodat je trends ziet in plaats van incidentele fouten.
Schrijf de exacte stappen op voor het toevoegen van een string, bijwerken van vertalingen en verifiëren van het resultaat. Houd het kort en voeg voorbeelden van sleutelnaamgeving en meervoudsgebruik toe. Nieuwe bijdragers moeten het kunnen volgen zonder te vragen.
Als je interne tools bouwt, kan AppMaster (appmaster.io) een praktische manier zijn om UI-copy en vertaalsleutels consistent te houden in een Vue3 webapp en bijbehorende mobiele apps, aangezien alles op één plek wordt beheerd.
Plan elke sprint één kleine i18n-health taak: verwijder dode sleutels, repareer inconsistente placeholders en review recente misses. Kleine opruimacties verslaan spoedzoektochten naar vertalingen in productie.
27 jan 2026
7 min
26 jan 20268 min
21 jan 20267 minExperimenteer met AppMaster met gratis abonnement.
Als je er klaar voor bent, kun je het juiste abonnement kiezen.
