27 jun 2025·8 min
Hoe een webapp bouwen om lokalisatie en vertalingen te beheren
Plan een webapp die vertaalworkflows, locale-data, reviews, QA-controles en releases beheert. Inclusief datamodel, UX en integraties.
Plan een webapp die vertaalworkflows, locale-data, reviews, QA-controles en releases beheert. Inclusief datamodel, UX en integraties.
Lokalisatiebeheer is het dagelijkse werk om de tekst van je product (en soms afbeeldingen, datums, valuta en formatteringsregels) vertaald, beoordeeld, goedgekeurd en verzonden te krijgen—zonder de build te breken of gebruikers te verwarren.
Voor een productteam is het doel niet "alles vertalen." Het is om elke taalversie accuraat, consistent en up-to-date te houden naarmate het product verandert.
De meeste teams beginnen goedbedoeld en eindigen met een puinhoop:
Een nuttige lokalisatiebeheertool ondersteunt meerdere rollen:
Je bouwt een MVP die strings centraliseert, status per locale bijhoudt en basis review en export ondersteunt. Een uitgebreider systeem voegt automatisering (sync, QA-checks), rijkere context en tools zoals een glossary en translation memory toe.
Voordat je tabellen of schermen ontwerpt, bepaal waarvoor je lokalisatiebeheer-webapp verantwoordelijk is. Een strakke scope maakt de eerste versie bruikbaar—en voorkomt dat je later alles moet herbouwen.
Vertalingen leven zelden op één plek. Schrijf op wat je vanaf dag één moet ondersteunen:
Deze lijst voorkomt een "one workflow fits all"-benadering. Marketingteksten hebben bijvoorbeeld vaak goedkeuring nodig, terwijl UI-strings snelle iteratie vereisen.
Kies 1–2 formaten voor de MVP en breid later uit. Veelvoorkomende opties zijn JSON, YAML, PO en CSV. Een praktische MVP-keuze is JSON of YAML (voor app-strings), en CSV alleen als je al op spreadsheet-imports vertrouwt.
Wees expliciet over vereisten zoals meervoudsvormen, geneste keys en opmerkingen. Deze details beïnvloeden je locale-bestandsbeheer en toekomstige import/export betrouwbaarheid.
Definieer een bron-taal (vaak en) en stel fallback-gedrag in:
Bepaal ook wat "klaar" betekent per locale: 100% vertaald, beoordeeld of verzonden.
Voor de MVP richt je je op het vertaalreviewproces en basis i18n-workflow: strings aanmaken/bewerken, werk toewijzen, review en export.
Plan latere toevoegingen—screenshots/context, glossary, translation memory basics en integratie van machinevertaling—maar bouw ze niet voordat je je kernworkflow met echte content hebt gevalideerd.
Een vertaalapp slaagt of faalt op zijn datamodel. Als de onderliggende entiteiten en velden helder zijn, wordt alles daarna—UI, workflow, integraties—eenvoudiger.
De meeste teams dekken 80% van hun behoeften met een kleine set tabellen/collecties:
en, en-GB, pt-BR).checkout.pay_button).Modelleer relaties expliciet: een Project heeft veel Locales; een Key behoort tot een Project; een Translation behoort tot een Key en een Locale.
Voeg een status toe aan elke vertaling zodat het systeem mensen kan sturen:
draft → in_review → approvedblocked voor strings die nog niet mogen worden uitgegeven (juridische review, ontbrekende context, enz.)Houd statuswijzigingen bij als events (of in een history-tabel) zodat je later kunt antwoorden op "wie heeft dit goedgekeurd en wanneer?".
Vertalingen hebben meer nodig dan platte tekst. Leg vast:
{name}, %d) en of ze exact moeten overeenkomen met de bronBewaar minimaal: created_by, updated_by, tijdstempels en een korte change_reason. Dit versnelt reviews en bouwt vertrouwen wanneer teams vergelijken wat in de app staat versus wat er is uitgebracht.
Opslagkeuzes vormen de rest: bewerkings-UX, import/export-snelheid, diffing en hoe zeker je kunt zijn bij het uitrollen.
Rij-per-key (één DB-rij per string key per locale) is uitstekend voor dashboards en workflows. Je kunt eenvoudig filteren op "ontbrekende Franse vertalingen" of "moet reviewed worden", eigenaren toewijzen en voortgang berekenen. Het nadeel: het reconstrueren van een locale-bestand voor export vereist groeperen en ordenen, en je hebt extra velden voor bestands-paden en namespaces nodig.
Document-per-bestand (sla elk locale-bestand op als JSON/YAML-document) sluit netjes aan op hoe repositories werken. Het is sneller om te exporteren en makkelijker om formattering identiek te houden. Maar zoeken en filteren wordt lastiger tenzij je ook een index van keys, statussen en metadata bijhoudt.
Veel teams gebruiken een hybride aanpak: rij-per-key als bron van waarheid, plus gegenereerde file-snapshots voor export.
Bewaar revisiegeschiedenis op vertalingseenheid (key + locale). Elke wijziging moet vastleggen: vorige waarde, nieuwe waarde, auteur, tijdstempel en commentaar. Dit maakt reviews en rollbacks eenvoudig.
Houd daarnaast release-snapshots bij: "wat precies is uitgebracht in v1.8". Een snapshot kan een tag zijn die verwijst naar een consistente set goedgekeurde revisies over locales. Dit voorkomt dat late bewerkingen stilletjes een uitgebracht build aanpassen.
Behandel "meervoud" niet als een enkele boolean. Gebruik ICU MessageFormat of CLDR-categorieën (bijv. one, few, many, other) zodat talen zoals Pools of Arabisch niet in Engelse regels worden gedwongen.
Voor gender en andere varianten, modelleer ze als varianten van dezelfde key (of message) in plaats van aparte ad-hoc keys, zodat vertalers de volledige context zien.
Implementeer full-text search over key, source text, translation en developer notes. Combineer dat met filters die aansluiten op echt werk: status (nieuw/vertaald/gereviewd), tags, bestand/namespace en missing/empty.
Indexeer deze velden vroeg — zoeken is de feature die mensen honderden keren per dag gebruiken.
Een lokalisatiebeheertool begint vaak eenvoudig: upload een bestand, bewerk strings, download het weer. Het wordt complexer wanneer je meerdere producten, veel locales, frequente releases en een constante stroom automatisering (sync, QA, MT, reviews) toevoegt.
De makkelijkste manier om flexibel te blijven, is zorgen voor scheiding van verantwoordelijkheden vanaf het begin.
Een veel voorkomende, schaalbare setup is API + web UI + background jobs + database:
Deze scheiding helpt je later meer workers toe te voegen voor zware taken zonder de hele app opnieuw te schrijven.
Als je sneller wilt bewegen voor de eerste werkende versie, kan een rapid-prototyping platform zoals Koder.ai helpen bij het scaffolden van de web UI (React), API (Go) en PostgreSQL-schema vanuit een gestructureerd spec en een paar iteraties in chat—en daarna de broncode exporteren wanneer je klaar bent om het repo en de deployment te beheren.
Houd je API gecentreerd op een paar kernresources:
checkout.button.pay).Ontwerp endpoints zodat ze zowel menselijke bewerkingen als automatisering ondersteunen. Bijvoorbeeld: lijst keys moet filters accepteren zoals "missing in locale", "changed since" of "needs review".
Behandel automatisering als asynchroon werk. Een queue regelt doorgaans:
Maak jobs idempotent (veilig om te herhalen) en leg job-logs per project vast zodat teams mislukkingen zelf kunnen onderzoeken.
Ook kleine teams kunnen grote datasets creëren. Voeg paginering toe voor lijsten (keys, geschiedenis, jobs), cache veelgebruikte reads (project locale-stats) en pas rate limits toe om import/export endpoints en publieke tokens te beschermen.
Dit zijn saaie details die voorkomen dat je vertaalbeheersysteem vertraagt juist wanneer adoptie groeit.
Als je app bronstrings en vertaalgeschiedenis opslaat, is toegang niet optioneel—het is hoe je per ongeluk bewerkingen voorkomt en beslissingen traceerbaar houdt.
Een eenvoudige set rollen dekt de meeste teams:
Behandel elke actie als een permissie zodat je later kunt uitbreiden. Veelvoorkomende regels:
Dit sluit goed aan op een vertaalbeheersysteem en blijft flexibel voor ingehuurde krachten.
Als je bedrijf al Google Workspace, Azure AD of Okta gebruikt, vermindert single sign-on (SSO) wachtwoordrisico en maakt offboarding direct. E-mail/wachtwoord werkt voor kleine teams—vereis dan sterke wachtwoorden en resetflows.
Gebruik veilige, kortdurende sessies (HTTP-only cookies), CSRF-bescherming, rate limiting en 2FA waar mogelijk.
Registreer wie wat wanneer heeft veranderd: bewerkingen, goedkeuringen, locale-wijzigingen, exports en permissiewijzigingen. Koppel de log aan "undo" via versiegeschiedenis zodat rollbacks veilig en snel zijn (zie /blog/plan-storage-and-versioning).
Je UI is waar lokalisatiewerk daadwerkelijk gebeurt, dus prioriteer schermen die heen-en-weer-communicatie verminderen en status in één oogopslag duidelijk maken.
Begin met een dashboard dat snel drie vragen beantwoordt: wat is klaar, wat ontbreekt en wat is geblokkeerd.
Toon voortgang per locale (percentage vertaald, percentage gereviewd), plus een duidelijke telling van "ontbrekende strings". Voeg een review-queue-widget toe die items markeert die wachten op goedkeuring en een "recent gewijzigd"-feed zodat reviewers risicovolle edits kunnen zien.
Filters zijn belangrijker dan grafieken: locale, productgebied, status, toegewezen persoon en "gewijzigd sinds laatste release".
Een goede editor is side-by-side: bron links, doel rechts, met context altijd zichtbaar.
Context kan de key, screenshottekst (als je dat hebt), karakterlimieten en placeholders (bijv. {name}, %d) omvatten. Voeg geschiedenis en opmerkingen toe in hetzelfde scherm zodat vertalers niet naar een apart discussiescherm hoeven.
Maak de statusworkflow één klik: Draft → In review → Approved.
Lokalisatiewerk bestaat vaak uit "veel kleine wijzigingen." Voeg bulk-selectie toe met acties zoals toewijzen aan gebruiker/team, status wijzigen en export/import voor een locale of module.
Houd bulkacties afgeschermd op basis van rollen.
Zware vertalers zitten uren in de editor. Ondersteun volledige toetsenbordnavigatie, zichtbare focus-staten en sneltoetsen zoals:
Ondersteun ook screenreaders en hoogcontrastmodus—toegankelijkheid verhoogt de snelheid voor iedereen.
Een lokalisatiebeheertool slaagt of faalt op workflow. Als mensen niet weten wat ze vervolgens moeten vertalen, wie verantwoordelijk is of waarom een string geblokkeerd is, ontstaan vertragingen en inconsistente kwaliteit.
Begin met een duidelijke eenheid van werk: een set keys voor een locale in een specifieke versie. Laat projectmanagers (of leads) werk toewijzen op locale, bestand/module en prioriteit, met een optionele deadline.
Maak toewijzingen zichtbaar in een "Mijn werk"-inbox die drie vragen beantwoordt: wat is toegewezen, wat is te laat en wat wacht op anderen. Voor grotere teams voeg je workload-signalen toe (aantal items, woordenaantal schatting, laatste activiteit) zodat toewijzingen eerlijk en voorspelbaar zijn.
Bouw een simpele statuspipeline, bijvoorbeeld: Untranslated → In progress → Ready for review → Approved.
Review moet meer zijn dan een binaire check. Ondersteun inline comments, suggested edits en approve/reject met reden. Wanneer reviewers afkeuren, bewaar de geschiedenis—overschrijven niet.
Dit maakt je reviewproces auditbaar en vermindert herhaalde fouten.
Brontekst verandert. Wanneer dat gebeurt, markeer bestaande vertalingen als Needs update en toon een diff of "wat is er veranderd"-overzicht. Bewaar de oudere vertaling als referentie, maar voorkom dat deze zonder expliciete beslissing opnieuw wordt goedgekeurd.
Meld op gebeurtenissen die voortgang blokkeren: nieuwe toewijzing, review aangevraagd, afkeuring, naderende deadline en bronwijziging die goedgekeurde strings raakt.
Maak meldingen actiegericht met diepe links zoals /projects/{id}/locales/{locale}/tasks zodat mensen issues in één klik kunnen oplossen.
Handmatig bestandengeweld is waar lokalisatieprojecten beginnen te ontsporen: vertalers werken op verouderde strings, developers vergeten updates te pullen en releases worden met half-af locales verzonden.
Een goede lokalisatiebeheertool behandelt import/export als een herhaalbare pijplijn, niet als een eenmalige taak.
Ondersteun de paden die teams daadwerkelijk gebruiken:
Bij export, sta filters toe op project, branch, locale en status (bijv. "only approved"). Dat voorkomt dat deels gereviewde strings in productie lekken.
Sync werkt alleen als keys consistent blijven. Beslis vroeg hoe strings worden gegenereerd:
checkout.button.pay_now), bescherm ze tegen per ongeluk hernoemen.Je app moet detecteren wanneer een bronstring is gewijzigd maar de key niet, en vertalingen markeren als needs review in plaats van ze te overschrijven.
Voeg webhooks toe zodat sync automatisch gebeurt:
main → importeer bijgewerkte source strings.Webhooks moeten idempotent zijn (veilig om te herhalen) en duidelijke logs produceren: wat is veranderd, wat is overgeslagen en waarom.
Als je dit implementeert, documenteer de eenvoudigste end-to-end setup (repo-toegang + webhook + PR-export) en link vanaf de UI naar de relevante docs-tekst.
Lokalisatie QA is waar een vertaalbeheersysteem ophoudt een eenvoudige editor te zijn en begint productiefouten te voorkomen.
Het doel is issues te vinden voordat strings worden verzonden—vooral diegenen die alleen in een specifieke locale-bestand voorkomen.
Begin met checks die de UI kunnen breken of formattering kunnen laten crashen:
{count} aanwezig in Engels maar ontbrekend in Frans, of meervoudsvormen inconsistent).% in printf-stijl strings, malformed ICU messages).Behandel deze standaard als "release-blokkerend", met een duidelijke foutmelding en een verwijzing naar de exacte key en locale.
Deze breken niet altijd de app, maar schaden kwaliteit en merkconsistentie:
Tekst kan correct zijn en er toch slecht uitzien. Voeg een mogelijkheid toe om screenshot-context per key aan te vragen (of een screenshot aan een key te koppelen), zodat reviewers kunnen controleren op afkapping, regelbreuken en toon in de echte UI.
Genereer voor elke release een QA-samenvatting per locale: fouten, waarschuwingen, onvertaalde strings en grootste probleemgevallen.
Maak het eenvoudig om te exporteren of intern te delen zodat het team één "go/no-go"-zicht heeft.
Een glossary, translation memory (TM) en machine translation (MT) kunnen lokalisatie aanzienlijk versnellen—maar alleen als je ze als hulpmiddelen en niet als "publicatieklare" content behandelt.
Een glossary is een gecureerde lijst termen met goedgekeurde vertalingen per locale (productnamen, UI-concepten, juridische frasen).
Sla items op als term + locale + goedgekeurde vertaling + notities + status.
Om afdwinging te ondersteunen:
TM hergebruikt eerder goedgekeurde vertalingen. Houd het simpel:
Behandel TM als een suggestiesysteem: gebruikers kunnen matches accepteren, bewerken of weigeren, en alleen geaccepteerde vertalingen moeten terugvloeien naar TM.
MT is nuttig voor drafts en achterstanden, maar het mag niet standaard het definitieve resultaat zijn.
Maak MT opt-in per project en per job, en laat MT-gevulde strings door de normale reviewflow lopen.
Verschillende teams hebben verschillende beperkingen. Sta admins toe providers te selecteren (of MT helemaal uit te schakelen), gebruikslimieten in te stellen en te bepalen welke data wordt verzonden (bijv. uitsluiten van gevoelige keys).
Log verzoeken voor kostenzichtbaarheid en auditing en documenteer opties in de integratie-instellingen.
Een lokalisatie-app moet niet alleen "vertalingen opslaan"—hij moet helpen ze veilig uit te rollen.
Het kernidee is een release: een bevroren snapshot van goedgekeurde strings voor een specifieke build, zodat wat gedeployed wordt voorspelbaar en reproduceerbaar is.
Behandel een release als een onveranderlijke bundel:
Zo kun je beantwoorden: "Wat hebben we in v2.8.1 voor fr-FR verzonden?" zonder te hoeven gokken.
De meeste teams willen vertalingen valideren voordat gebruikers ze zien. Modelleer exports per omgeving:
Maak het export-endpoint expliciet (bijv. /api/exports/production?release=123) om per ongeluk lekken van ongereviewde tekst te voorkomen.
Rollback is het makkelijkst wanneer releases onveranderlijk zijn. Als een release problemen introduceert (kapotte placeholders, foute terminologie), moet je kunnen:
Vermijd "in-place productie bewerken"—dat breekt audittrails en maakt incidenten lastiger te analyseren.
Deze "snapshot + rollback"-mentaliteit sluit goed aan bij moderne buildplatforms. Bijvoorbeeld, Koder.ai bevat snapshots en rollback als kernworkflow voor gegenereerde en gehoste applicaties, wat een nuttig denkmodel is bij het ontwerpen van onveranderlijke lokalisatie-releases.
Na deployment voer je een klein operationeel checklist uit:
Als je releasegeschiedenis in de UI toont, voeg dan een eenvoudige "diff vs vorige release"-weergave toe zodat teams risicovolle wijzigingen snel kunnen zien.
Beveiliging en zichtbaarheid zijn het verschil tussen een nuttige lokalisatietool en een tool waar teams op vertrouwen. Zodra je workflow draait, vergrendel je het en begin je het te meten.
Volg het principe van minste privilege: vertalers mogen geen projectinstellingen wijzigen en reviewers mogen geen toegang hebben tot billing of admin-only exports. Maak rollen expliciet en auditbaar.
Bewaar secrets veilig. Houd database-credentials, webhook signing keys en derdepartijstokens in een secrets manager of versleutelde omgevingsvariabelen—nooit in het repo. Roteer sleutels periodiek en wanneer iemand vertrekt.
Backups zijn geen optie. Maak geautomatiseerde backups van je database en object storage (locale-bestanden, attachments), test restores en definieer retentie. Een "backup die niet kan worden hersteld" is slechts extra opslag.
Als strings gebruikersinhoud kunnen bevatten (supporttickets, namen, adressen), vermijd het opslaan daarvan in het vertaalsysteem. Gebruik liever placeholders of referenties en verwijder gevoelige waarden uit logs.
Als je dergelijke tekst toch moet verwerken, definieer retentieregels en toegangsrestricties.
Volg een paar metrics die de gezondheid van de workflow weerspiegelen:
Een eenvoudig dashboard plus CSV-export is meestal al voldoende.
Zodra de basis staat, overweeg:
Als je dit als product wilt aanbieden, voeg dan een duidelijke upgrade-route en call-to-action toe.
Als je snel de workflow met echte gebruikers wilt valideren, kun je de MVP op Koder.ai prototypen: beschrijf rollen, statusflow en import/export-formaten in de planningmodus, iterereer op de React UI en Go API via chat en exporteer daarna de codebase om te hardenen voor productie.
Een lokalisatiebeheertool centraliseert je teksten en regelt de workflow daaromheen — vertaling, review, goedkeuring en export — zodat teams updates kunnen uitrollen zonder ontbrekende keys, ontbrekende placeholders of onduidelijke status.
Begin met het vastleggen van:
pt-BR → pt → en)Een scherp afgebakde scope voorkomt dat “één workflow past op alles” en houdt de MVP bruikbaar.
De meeste teams dekken de kernworkflow met:
Sla metadata op die productiefouten en review-churn voorkomt:
Dat hangt af van je prioriteiten:
Een veelgebruikte aanpak is hybride: row-per-key als bron van waarheid, plus gegenereerde bestands-snapshots voor exports.
Gebruik twee lagen:
Dat voorkomt dat late bewerkingen stilletjes veranderen wat al is verzonden en maakt incidenten eenvoudiger te analyseren.
Begin met rollen die het echte werk weerspiegelen:
Richt de API rond een paar resources:
Projects, Locales, Keys, TranslationsMaak list-endpoints filterbaar voor praktische taken, zoals:
Draai langdurig werk asynchroon:
Maak jobs idempotent (veilig om te herhalen) en sla logs per project op zodat teams fouten zelf kunnen diagnosticeren zonder in serverlogs te duiken.
Prioriteer checks die gebroken UI voorkomen:
{count}, %d) en dekking van meervoudsvormenBehandel deze standaard als release-blokkerend en voeg zachtere waarschuwingen toe voor woordenlijstconsistentie en spatiëring/hoofdletters zodat teams kwaliteit kunnen verbeteren zonder alles te blokkeren.
draft → in_review → approved)Als deze entiteiten helder zijn, worden UI, permissies en integraties veel eenvoudiger om te bouwen en te onderhouden.
created_by, updated_by, tijdstempels, change reason)Dit is het verschil tussen “een teksteditor” en een systeem dat teams vertrouwen.
Definieer permissies per actie (bron bewerken, goedkeuren, exporteren, locales beheren) zodat je het systeem later kunt uitbreiden zonder workflows te breken.
Dat ondersteunt zowel handmatige UI-bewerkingen als automatisering via CLI/CI.