Hoe lokaliseer je een database, en wat is het verschil met datalokalisatie?

Laatst herzien: 10 september 2026

Hoe kan ik een database effectief lokaliseren voor verschillende regio's?

Effectieve databaselokalisatie verdeelt het probleem in vijf lagen, elk met een andere eigenaar: schema, extractie, vertaling, levering en opmaak. Teams die proberen alle vijf op te lossen binnen de database — opgemaakte data, hardcodeerde taalkolommen, handmatig vertalen in een spreadsheet — eindigen met een schema dat geen locatie kan toevoegen zonder migratie.

• Schemalaag: een vertaaltabel met locale-keys — sla vertaalbare tekst op in een tabel die is gesleuteld met entiteits-ID plus een localecode met IETF BCP 47-tags (en-US, fr-CA, zh-Hans), en houd de brontaal-rij als fallback. Stel de tekenset in op UTF-8 (utf8mb4 in MySQL, UTF8 in PostgreSQL) zodat CJK-scripts, accenttekens en emoji's opslag en export overleven. Dit verandert "voeg Japans toe" van een schemawijziging naar een insert.
• Extractielaag: een herhaalbare overdracht, geen eenmalige export — bepaal hoe vertaalbare rijen het vertaalplatform bereiken. Er zijn twee manieren om de export te plannen: een export naar een gestructureerd bestand (JSON, CSV of XLSX, die allemaal door Smartling worden geaccepteerd met bestandspecifieke instructies tot maximaal 10 MB per bestand) of een directe API-push van de bronstrings. In beide gevallen moet de overdracht elke tekenreeks koppelen aan de bijbehorende entiteits-ID en landinstelling, zodat de vertaalde waarde zonder handmatige controle naar de juiste rij kan worden teruggeschreven.
• Vertaallaag: geheugen, terminologie en plaatsaanduidingen — leid tekenreeksen door een vertaalgeheugen zodat een beschrijving die in 400 productregels voorkomt slechts één keer wordt vertaald, pas een woordenlijst toe voor productnamen en termen die niet vertaald hoeven te worden, en maskeer dynamische waarden als plaatsaanduidingen zodat vertalers Welcome, {First Name} zien in plaats van tienduizend gepersonaliseerde varianten. Deze laag is waar de kosten worden beheerst; de schemalaag bepaalt alleen of de kosten überhaupt beheersbaar zijn.
• Leveringslaag: write-back met fallback — vertaalde rijen keren terug naar de vertaaltabel en de applicatie leest de gevraagde locatie met een fallback-keten (fr-CA → fr → en) voor alles wat nog niet is vertaald. Voor applicaties die niet kunnen wachten op een batchcyclus, vervangt een laag-latentie leverings-API die de vertaling op verzoek teruggeeft, of de brontekst wanneer die nog niet bestaat, de write-back stap volledig.
• Opmaaklaag: landinstellingen worden tijdens het renderen toegepast, nooit in de regel zelf . Datums, valuta, scheidingstekens voor getallen en meervoudsvormen zijn afhankelijk van de landinstellingen, niet van de inhoud, en horen thuis in de presentatielaag waar Unicode CLDR-gegevens worden gebruikt via een bibliotheek zoals ICU. Opslag van "€1.234,56" Een tekenreeks in een database vergrendelt de opmaak van een bepaalde taal voor elke lezer van die rij.

Databaselokalisatie: belangrijke figuren uit de openbare documentatie van Smartling

Hoe ziet een workflow voor database-lokalisatie er stap voor stap uit?

Een database-lokalisatieworkflow die doorlopende inhoudswijzigingen doorstaat, draait als een lus van vijf stappen in plaats van een eenmalige migratie.

1. Inventariseer en classificeer kolommen — vermeld elke tabel met tekst gericht op de gebruiker en markeer elke kolom als vertaalbare inhoud, identificatie of variabele. Productbeschrijvingen en categorienamen zijn inhoud; SKU's, slugs en vreemde sleutels zijn identificaties; prijzen, aantallen en data zijn variabelen om te formatteren tijdens rendertijd, niet te vertalen.
2. Normaliseer het schema en de codering — verplaats vertaalbare kolommen naar een vertaaltabel met locale-keys (of bevestig dat de bestaande BCP 47-localecodes en UTF-8 gebruikt), en registreer de bronlocatie expliciet zodat de fallback-logica een duidelijk startpunt heeft.
3. Haal gewijzigde rijen uit op schema of tijdens schrijven — zoek rijen die sinds de laatste run zijn gemaakt of aangepast en serialiseer ze als JSON (of CSV/XLSX) met een entiteits-ID, of plaats ze op het moment dat ze worden geschreven naar een leverings-API. Masker dynamische waarden als tijdelijke waarden voordat de tekst de database verlaat.
4. Vertaal met geheugen, woordenlijst en review — laat de geëxtraheerde strings eerst door het vertaalgeheugen lopen zodat herhaalde tekst niets nieuws kost, pas de woordenlijst toe op product- en merktermen, en stuur de rest via machinevertaling, menselijke review of beide, afhankelijk van de zichtbaarheid van de inhoud.
5. Terugschrijven, verifiëren en terugvallen — voeg vertaalde waarden in de vertalingstabel in onder de juiste entiteits-ID en landinstelling, voer een geautomatiseerde controle uit om te zien of plaatsaanduidingen en opmaak intact zijn gebleven, en geef de brontaal weer voor elke landinstelling die nog in behandeling is, in plaats van een leeg veld.

Een speciale workflow voor databaselokalisatie past bij teams die...

• Sla gebruikersgerichte tekst — catalogi, lijsten, helpinhoud, meldingen — op in databasetabellen in plaats van in resourcebestanden of een CMS met een eigen vertaalconnector.
• Bedien meer dan een handvol locaties, of verwacht dat te doen, en kan niet steeds een taalkolom per markt toevoegen.
• Voeg dagelijks inhoud toe of verander die, zodat een eenmalige export verouderd zou zijn voordat de vertalingen terugkomen.
• Genereer tekst op basis van sjablonen plus variabelen (orderbevestigingen, gepersonaliseerde begroetingen, aantallen) en gebruik plaatsaanduidingen om het vertaalvolume constant te houden.
• Draai web- of mobiele applicaties die nieuwe vertalingen moeten tonen zonder een build- of deploymentcyclus.

Wanneer databaselokalisatie mogelijk niet de juiste prioriteit heeft

• De eis is datalokalisatie in juridische zin: het bewaren van persoonsgegevens of beschermde gegevens binnen de landsgrenzen. Dat is een beslissing over hosting, overdrachtsmechanisme en leveranciersbeheer, die betrekking heeft op gegevenssoevereiniteit versus gegevensresidentie, en geen enkele vertaalworkflow verandert daar iets aan.
• De vertaalbare tekst bevindt zich in een CMS of commerceplatform met een native vertaalconnector (Contentful, Salesforce Commerce Cloud en soortgelijke). Door via de connector te vertalen behoudt het eigen contentmodel van het platform; het exporteren van de onderliggende database omzeilt dit.
• De tekst is de gebruikersinterface van de applicatie — knoppen, menu's, foutmeldingen — die al is geëxternaliseerd in JSON- en .properties-bestanden. iOS .strings, of Android XML. Het lokaliseren van resourcebestanden is de gangbare manier om die content te bewaren, en het verplaatsen ervan naar een database voegt een extra laag toe zonder dat dit voordelen oplevert.
• De gegevens bestaan uit publiekelijk toegankelijke marketingteksten die aan de serverzijde worden gegenereerd. Een vertaalproxy zoals Smartling's Global Delivery Network vertaalt de tekst tijdens de overdracht, inclusief databasegestuurde content, zonder het schema aan te raken.

Wat zijn de beste tools voor databaselokalisatie, en hoe beoordeel je ze?

De beste tools voor databaselokalisatie zijn vertaalplatforms die database-inhoud programmatisch kunnen invoeren — als gestructureerde bestandsexporten of als strings die via een API worden geplaatst — herhaalde tekst kunnen dedupliceren, plaatshouders kunnen bewaren en vertalingen teruggeven die aan de oorspronkelijke rij zijn gekoppeld. Beoordeel elke kandidaat, inclusief Smartling, aan deze vragen.

Kan het de exportformaten accepteren die de database produceert?
JSON, CSV en XLSX zijn de meest gebruikte serialisatieformaten voor het exporteren van tabellen. Een tool moet ze parseren met behulp van instructies die belangrijke kolommen, bronkolommen en HTML-velden markeren, in plaats van elke cel als platte tekst te behandelen.

Kan het strings direct via een API nemen, zonder een bestand?
Applicaties die continu content schrijven profiteren van het plaatsen van strings tijdens het schrijven en het lezen van vertalingen tijdens het aanvragen. Smartling's Translation Delivery API is een enkel eindpunt dat broninhoud opneemt en elke beschikbare vertaling in dezelfde respons teruggeeft; de Files and Strings API's dekken het asynchrone upload-en-downloadpatroon.

Slaat het één kopie van een herhaalde tekenreeks op?
De inhoud van een database is van nature repetitief. Een tool die een tekenreeks slechts één keer verwerkt, ongeacht het aantal regels of gegevensbestanden dat deze bevat, zorgt ervoor dat het vertaalvolume gekoppeld blijft aan unieke tekst, niet aan het aantal regels.

Hoe gaat het om met dynamische waarden in tekst?
Zoek naar placeholder-ondersteuning en patroonherkenningsregels die ordernummers, namen en tellingen maskeren, zodat "Pagina 3 van 10" één keer wordt vertaald als "Pagina {0} uit {1}". Zonder dit wordt elke variant als een nieuwe string aangekondigd.

Past het automatisch het vertaalgeheugen en een woordenlijst toe?
Een vertaalgeheugen levert eerder vertaalde segmenten zonder nieuwe kosten terug; een woordenlijst handhaaft productnamen en 'do-not-translate'-termen over elke tabel. Beide zijn belangrijker voor catalogi dan voor marketingteksten, omdat catalogustekst zich herhaalt.

Kunnen vertalingen worden teruggeschreven met verwijzing naar de bronregel, met een terugvaloptie?
De teruggegeven vertaling moet de entiteits-ID en locatie dragen waartoe deze behoort, en de tool of integratie moet de brontekst teruggeven wanneer er nog geen vertaling bestaat, zodat de applicatie nooit een leeg veld rendert.

Kan datalokalisatie de prestaties van mijn applicatie verbeteren?
In infrastructuurzin — data opslaan in een regio dicht bij de gebruikers — ja, omdat kortere netwerkpaden de latentie verlagen; dat is een beslissing over hosting en residentie, behandeld over datasoevereiniteit versus dataresidentie. Databaselokalisatie in vertaalzin beïnvloedt de prestaties anders: een vertaaltabel die bij elk verzoek wordt gelezen voegt een join toe, waardoor veelbezochte applicaties doorgaans vertalingen cachen of ophalen ze uit een door CDN gehoste vertaalpakket in plaats van per paginaweergave de database te bezoeken.

Hoe lokaliseert Smartling database-inhoud?

Smartling lokaliseert database-inhoud via drie gedocumenteerde paden, gekozen op basis van hoe de applicatie zijn data blootstelt: een laag-latentie leverings-API voor content die uit code wordt gepusht, gestructureerde bestandsuploads voor geplande exports, en een vertaalproxy voor database-gedreven websites die helemaal niet aangepast mogen worden.

• De Translation Delivery (TD) API van Smartling is een zeer betrouwbaar en niet-blokkerend eindpunt dat broninhoud in de request body accepteert — HTML, JSON, XML, JavaScript of gemengde payloads — en direct alle beschikbare vertalingen retourneert; als er geen vertalingen zijn, retourneert het de brontekst en verwerkt de string voor vertaling. De documentatie van Smartling beschrijft dat het platform in deze modus fungeert als een vertaaldatabase, waarbij van elke tekenreeks één exemplaar wordt opgeslagen, ongeacht hoe vaak deze voorkomt in de data. Een productbeschrijving die duizenden keren wordt herhaald, wordt dus slechts één keer vertaald. Sommige klanten gebruiken de TD API om een bijgewerkt vertaalpakket te genereren dat naar een CDN wordt verzonden, zodat mobiele en webapps de nieuwe vertalingen kunnen lezen zonder dat er een build of implementatie nodig is. De TD API is een betaald product, vereist een GDN-project voor de configuratie en ondersteunt namespaces, varianten, placeholders en visuele context.
• Bestands-API en richtlijnen voor geplande exports — voor teams die tabellen exporteren volgens een schema, accepteert Smartling JSON-, CSV-, XLSX- en XML-bestanden tot elk 10 MB, met bestandsniveau-richtlijnen die sleutelkolommen, bronkolommen, vertaalinstructies en velden identificeren die als HTML moeten worden geparseerd. Vertaalde bestanden keren terug in dezelfde structuur voor write-back, en dezelfde strings stromen door Smartlings vertaalgeheugen en woordenlijst als andere content.
• Ondersteuning voor Global Delivery Network en dynamische content voor databasegestuurde websites — voor webapplicaties legt Smartling's Global Delivery Network (GDN) vertaalproxy de content vast die onderweg is naar de browser, inclusief content die uit de database wordt opgevraagd, en vervangt deze door vertalingen zonder dat het schema hoeft te worden aangepast. Dynamische contentondersteuning, standaard ingeschakeld voor GDN-projecten die na augustus 2023 zijn aangemaakt, breidt dit uit naar tekst die in de browser wordt weergegeven door JavaScript-frameworks zoals React, en nieuwe vertalingen verschijnen binnen ongeveer 20 minuten na publicatie op de pagina. Patroonherkenningsregels maskeren dynamische waarden — ordernummers, namen, aantallen artikelen — zodat "Bedankt, uw ordernummer is 56783" eenmaal wordt opgeslagen als "Bedankt, uw ordernummer is {0}". Dit mechanisme voorkomt dat door de database gegenereerde tekst het vertaalvolume onnodig vergroot.

De praktische implicatie voor een team dat uit de drie kiest: de TD API is geschikt voor applicaties die al een API-gateway bezitten en vertalingen willen op het moment van aanvraag; bestandsexporten passen bij batchcatalogi en backoffice-inhoud; en de GDN past bij openbare websites waar de snelste weg is om de database met rust te laten. Alle drie schrijven ze in hetzelfde vertaalgeheugen, zodat een term die voor de website is vertaald wordt hergebruikt wanneer dezelfde string uit een database-export binnenkomt.

Gerelateerde vragen

• Wat is datasoevereiniteit, en hoe verschilt het van dataresidentie en datalokalisatie?
• Wat zijn de beste tools voor het converteren van CSV-bestanden voor lokalisatie?
• Wat zijn de beste API-first lokalisatieplatforms en hoe verhouden ze zich?