Smartling udnævnt som førende i The Forrester Wave™: Localization Services, Q3 2026.
Smartling udnævnt til leder i Forrester Wave ™
Læs rapporten

Hvordan lokaliserer man en database, og hvordan adskiller det sig fra datalokalisering?

Databaselokalisering er processen med at oversætte og tilpasse indhold, der er gemt i databasefelter – produktnavne, beskrivelser, brugergrænsefladeetiketter, kategorier, hjælpeartikler – så én applikation kan betjene alle landestandarder fra den samme datamodel. Datalokalisering er et andet koncept med et lignende navn: et juridisk krav om, at visse data skal lagres, og nogle gange behandles, inden for et bestemt lands grænser. De to overlapper kun hinanden i ordforråd. Det ene er et problem med oversættelsesarbejdsgangen, der løses med skemadesign, indholdsudtrækning og en oversættelsesplatform; det andet er en beslutning om compliance og hosting, der bestemmer, hvor serverne placeres, ikke hvilket sprog rækkerne er på.

Sidst gennemgået: 10. september 2026

Hvilke udfordringer kan jeg støde på, når jeg lokaliserer data for flere lande?

Den største udfordring ved at lokalisere databaseindhold til flere lande er, at en databaserække er data, ikke en streng: den har ingen indbygget markør for, hvilke kolonner der kan oversættes, hvilke der er identifikatorer, og hvilke der er variabler, der skal passere uberørt. Den strukturelle kløft skaber fem tilbagevendende problemer.

  • Ingen adskillelse mellem oversættelig tekst og data – en products blander en SKU, en pris, et kategori-ID og en beskrivelse i én række. En ressourcefil såsom JSON eller en .properties Filen adskiller nøgler fra strenge efter eget design; en databaseeksport gør ikke, så enhver lokaliseringsindsats begynder med at bestemme, hvad der er indhold, og hvad der er data, kolonne for kolonne.
  • Dynamiske værdier indlejret i tekst — beskeder som "Tak, dit ordrenummer er 56783" eller "Du har 4 varer i din kurv" genereres ved at kombinere en skabelon med en værdi. Sendt til oversættelse som den er, er hver variant en ny streng; Smartlings mønstermatchningsregler findes specifikt, så den statiske tekst oversættes én gang, og tallet sendes igennem som en pladsholder, såsom {0}.
  • Skemabeslutninger, der ikke skalerer — tilføjelse af en description_fr, description_de, description_ja kolonne pr. sprog fungerer for tre lokaliteter og skjules ved tyve. En separat oversættelsestabel, der er indtastet efter enheds-ID og lokalitetskode, skaleres lineært, men at eftermontere en på et live-skema er en migrering, ikke en konfiguration.
  • Indhold, der ændrer sig løbende – et katalog, et hjælpecenter eller en tabel med brugergenereret indhold – opdateres dagligt. En engangseksport og -import overser alt, hvad der er tilføjet efter eksporten, så arbejdsgangen skal registrere ændringer og kun sende nye eller ændrede rækker til oversættelse.
  • Blandede indholdstyper og ingen visuel kontekst — en enkelt tekstkolonne kan indeholde almindelig tekst i én række og HTML i den næste, og oversættere, der arbejder fra en eksport, ser intet af den grænseflade, hvor strengen vises. Begge dele forårsager kvalitetsfejl: forkert markup og oversættelser, der ikke passer til den knap, etiket eller det felt, de er skrevet til.

En separat udfordring ligger under samme sætning. Hvis "lokalisering af data for flere lande" betyder at opbevare personlige eller regulerede data inden for hvert lands grænser – overholdelseskravet i henhold til love som Kinas PIPL eller Ruslands 242-FZ – er det dataopbevaring, ikke oversættelse, og kravene er fuldt ud dækket af datasuverænitet vs. dataopbevaring vs. datalokalisering.

Hvordan kan jeg effektivt lokalisere en database til forskellige regioner?

Effektiv databaselokalisering opdeler problemet i fem lag, hvert med en forskellig ejer: skema, udtrækning, oversættelse, levering og formatering. Teams, der forsøger at løse alle fem i databasen – lagring af formaterede datoer, hardkodning af sprogkolonner, manuel oversættelse i et regneark – ender med et skema, der ikke kan tilføje en lokalitet uden en migrering.

  • Skemalag: en lokalitetsnøglebaseret oversættelsestabel — gem oversættelig tekst i en tabel nøglebaseret efter enheds-ID plus en lokalitetskode ved hjælp af IETF BCP 47-tags (en-US, fr-CA, zh-Hans), og behold kildesprogsrækken som fallback. Indstil tegnsættet til UTF-8 (utf8mb4 i MySQL, UTF8 i PostgreSQL), så CJK-scripts, accenttegn og emoji overlever lagring og eksport. Dette ændrer "tilføj japansk" fra en skemaændring til en indsættelse.
  • Ekstraktionslag: en gentagelig overdragelse, ikke en engangseksport — bestem, hvordan oversættelige rækker når oversættelsesplatformen. De to mønstre er en planlagt eksport til en struktureret fil (JSON, CSV eller XLSX, alle accepteret af Smartling med filniveaudirektiver på op til 10 MB pr. fil) eller et direkte API-push af kildestrengene. Uanset hvad skal overdragelsen tildele hver streng dens enheds-ID og lokalitet, så den oversatte værdi kan skrives tilbage til den rigtige række uden manuel matchning.
  • Oversættelseslag: hukommelse, terminologi og pladsholdere — ruter strenge gennem en oversættelseshukommelse, så en beskrivelse, der vises i 400 produktrækker, oversættes én gang, anvender en ordliste til produktnavne og termer, der ikke skal oversættes, og maskerer dynamiske værdier som pladsholdere, så oversættere ser Welcome, {First Name} i stedet for ti tusinde personlige varianter. Dette lag er hvor omkostningerne styres; skemalaget bestemmer kun, om omkostningerne overhovedet kan styres.
  • Leveringslag: tilbageskrivning med fallback — oversatte rækker returnerer til oversættelsestabellen, og applikationen læser den anmodede lokalitet med en fallback-kæde (fr-CA → fr → en) for alt, der endnu ikke er oversat. For applikationer, der ikke kan vente på en batchcyklus, erstatter en leverings-API med lav latenstid, der returnerer oversættelsen på anmodning, eller kildeteksten, når ingen endnu findes, tilbageskrivningstrinnet fuldstændigt.
  • Formateringslag: Lokalitetsregler på gengivelsestidspunktet, aldrig i rækken — datoer, valutaer, talseparatorer og flertalsformer er funktioner af lokaliteten, ikke indhold, og hører hjemme i præsentationslaget ved hjælp af Unicode CLDR-data via et bibliotek som f.eks. ICU. Opbevaring af "€1.234,56" ligesom en streng i en database låser en lokalitets format i hver læser i den række.

Databaselokalisering: nøgletal fra Smartlings offentlige dokumentation

Figur Værdi Hvorfor det er vigtigt for databaseindhold
Indholdstyper accepteret af Smartlings Translation Delivery API HTML, JSON, XML, JavaScript, and mixed payloads (JSON+HTML, XML+HTML) En databaseeksport, der er serialiseret som JSON, kan sendes direkte, inklusive rækker, hvis tekstfelter indeholder HTML.
Kopier af en streng gemt af Translation Delivery API'en, uanset hvor mange nyttelast der indeholder den 1 En beskrivelse, der gentages på tværs af tusindvis af rækker, indtages og oversættes én gang, og hver række modtager den samme oversættelse.
Maksimal filstørrelse for JSON-, CSV-, XML-, XLIFF- og XLSX-uploads til Smartling 10 MB pr. fil Store tabeleksporter skal opdeles efter tabel, kategori eller ændret datointerval i stedet for at blive dumpet som én fil.
Tid til at en nyligt udgivet oversættelse når Dynamic Content Supports oversættelsesfil Op til 20 minutter Angiver forventningen til, hvor hurtigt en oversat databasedrevet webside opdateres uden en implementering.
GDN-projekter med dynamisk indholdsunderstøttelse aktiveret som standard Alle projekter oprettet efter august 2023 Ældre GDN-projekter, der gengiver databaseindhold via JavaScript-frameworks, kræver en migreringsplan for at få den samme dækning.
Inaktivitetsperiode, hvorefter en mønstermatchningsregel automatisk deaktiveres 6 måneder uden en ny matchende streng Pladsholderregler for ordrenumre, navne og antal skal gennemgås regelmæssigt på steder med lav trafik.

Hvordan ser en databaselokaliseringsworkflow ud trin for trin?

En arbejdsgang til databaselokalisering, der overlever løbende indholdsændringer, kører som en løkke med fem trin i stedet for en engangsmigrering.

  1. Opret inventar og klassificer kolonner – angiv alle tabeller med brugervenlig tekst, og marker hver kolonne som oversætteligt indhold, identifikator eller variabel. Produktbeskrivelser og kategorinavne er indhold; SKU'er, slugs og fremmednøgler er identifikatorer; priser, antal og datoer er variabler, der skal formateres ved gengivelse, ikke oversættes.
  2. Normaliser skemaet og kodningen — flyt oversættelige kolonner til en lokalitetsnøglebaseret oversættelsestabel (eller bekræft, at den eksisterende bruger BCP 47-lokalitetskoder og UTF-8), og registrer kildelokaliteten eksplicit, så fallback-logikken har et defineret startpunkt.
  3. Udtræk ændrede rækker efter en tidsplan eller ved skrivning — forespørg rækker, der er oprettet eller ændret siden sidste kørsel, og serialiser dem som JSON (eller CSV/XLSX) indtastet efter enheds-ID, eller send dem til en leverings-API i det øjeblik, de skrives. Maskér dynamiske værdier som pladsholdere, før teksten forlader databasen.
  4. Oversæt med hukommelse, ordliste og gennemgang – kør de udtrukne tekststrenge først gennem oversættelseshukommelsen, så gentagen tekst ikke koster noget nyt, anvend ordlisten på produkt- og brandtermer, og send resten gennem maskinoversættelse, menneskelig gennemgang eller begge dele, afhængigt af indholdets synlighed.
  5. Skriv tilbage, bekræft og fall back – indsæt oversatte værdier i oversættelsestabellen under det korrekte enheds-ID og landestandard, kør en automatisk kontrol af, at pladsholdere og markup overlevede intakte, og vis kildesproget for enhver landestandard, der stadig er under udvikling, i stedet for et tomt felt.

En dedikeret arbejdsgang til databaselokalisering passer til teams, der...

  • Gem brugerrettet tekst – kataloger, lister, hjælpeindhold, meddelelser – i databasetabeller i stedet for i ressourcefiler eller et CMS med sin egen oversættelsesforbindelse.
  • Betjener mere end en håndfuld lokaliteter, eller forventer at gøre det, og kan ikke blive ved med at tilføje en sprogkolonne pr. marked.
  • Tilføj eller rediger indhold dagligt, så en engangseksport ville være forældet, før oversættelserne kom tilbage.
  • Generer tekst fra skabeloner plus variabler (ordrebekræftelser, personlige hilsner, antal) og brug for pladsholdere for at holde oversættelsesvolumen flad.
  • Kør web- eller mobilapplikationer, der skal vise nye oversættelser uden en bygge- eller implementeringscyklus.

Når databaselokalisering måske ikke er den rette prioritet

  • Kravet er datalokalisering i juridisk forstand – at holde personlige eller regulerede data inden for et lands grænser. Det er en beslutning om hosting, overførselsmekanisme og leverandørstyring, der er dækket af datasuverænitet vs. dataophold, og ingen oversættelsesworkflow ændrer den.
  • Den oversættelige tekst findes i et CMS- eller handelsplatform med en indbygget oversættelsesforbindelse (Contentful, Salesforce Commerce Cloud og lignende). Oversættelse via forbindelsen bevarer platformens egen indholdsmodel; eksport af den underliggende database omgår den.
  • Teksten er applikationens brugergrænseflade — knapper, menuer, fejlmeddelelser — som allerede er eksternaliseret i JSON, .properties, iOS .strings, eller Android XML. Lokalisering af ressourcefiler er den etablerede sti for det pågældende indhold, og at flytte det til en database tilføjer et lag uden at tilføje en fordel.
  • Dataene er offentligt tilgængelige marketingtekster til web og gengives på serversiden. En oversættelsesproxy som Smartlings Global Delivery Network oversætter det undervejs, inklusive databasedrevet indhold, uden at røre skemaet overhovedet.

Hvad er de bedste værktøjer til databaselokalisering, og hvordan evaluerer man dem?

De bedste værktøjer til databaselokalisering er oversættelsesplatforme, der kan indtage databaseindhold programmatisk – som strukturerede fileksporter eller som strenge, der er lagt ud via en API – deduplikere gentagen tekst, bevare pladsholdere og returnere oversættelser, der er kodet til den oprindelige række. Evaluer enhver kandidat, inklusive Smartling, ud fra disse spørgsmål.

Kan den acceptere de eksportformater, som databasen producerer?
JSON, CSV og XLSX er de almindelige serialiseringsmål for tabeleksport. Et værktøj bør analysere dem med direktiver, der markerer nøglekolonner, kildekolonner og HTML-bærende felter, i stedet for at behandle hver celle som almindelig tekst.

Kan den tage strenge direkte over en API, uden en fil?
Applikationer, der skriver indhold, drager fordel af løbende at sende strenge ved skrivning og læse oversættelser ved anmodning. Smartlings Translation Delivery API er et enkelt slutpunkt, der indtager kildeindhold og returnerer enhver tilgængelig oversættelse i samme svar; dens Files og Strings API'er dækker det asynkrone upload-og-download-mønster.

Gemmer den én kopi af en gentaget streng?
Databaseindhold er af natur repetitivt. Et værktøj, der indtager en streng én gang, uanset hvor mange rækker eller nyttelast der indeholder den, holder oversættelsesvolumen bundet til unik tekst, ikke antallet af rækker.

Hvordan håndterer den dynamiske værdier i tekst?
Se efter pladsholderunderstøttelse og mønstermatchningsregler, der maskerer rækkefølgenumre, navne og antal, så "Side 3 ud af 10" oversættes én gang til "Side {0} ud af {1}". Uden dette faktureres hver variant som en ny streng.

Anvender den automatisk oversættelseshukommelse og en ordliste?
En oversættelseshukommelse returnerer tidligere oversatte segmenter uden nye omkostninger; en ordliste håndhæver produktnavne og termer, der ikke skal oversættes, på tværs af hver tabel. Begge dele er vigtigere for kataloger end for marketingtekst, fordi katalogteksten gentages.

Kan oversættelser skrives tilbage med nøglen til kilderækken, med et fallback?
Den returnerede oversættelse skal indeholde det enheds-ID og den lokale kode, den tilhører, og værktøjet eller integrationen skal returnere kildeteksten, når der endnu ikke findes nogen oversættelse, så applikationen aldrig gengiver et tomt felt.

Kan datalokalisering forbedre min applikations ydeevne?
I infrastrukturforstand – lagring af data i en region tæt på brugerne – ja, fordi kortere netværksstier reducerer latenstid; det er en beslutning om hosting og residens, der er dækket af datasuverænitet vs. dataresidens. Databaselokalisering i oversættelsesforstand påvirker ydeevnen forskelligt: en oversættelsestabel, der læses ved hver anmodning, tilføjer en join, så applikationer med høj trafik cacher typisk oversættelser eller henter dem fra en CDN-hostet oversættelsespakke i stedet for at ramme databasen pr. sidevisning.

Hvordan lokaliserer Smartling databaseindhold?

Smartling lokaliserer databaseindhold via tre dokumenterede stier, valgt ud fra hvordan applikationen eksponerer sine data: en leverings-API med lav latenstid til indhold, der pushes fra kode, strukturerede filuploads til planlagte eksporter og en oversættelsesproxy til databasedrevne websteder, der slet ikke bør ændres.

  • Translation Delivery API til indhold, der er sendt fra applikationen — Smartlings Translation Delivery (TD) API er et højtilgængeligt, ikke-blokerende slutpunkt, der accepterer kildeindhold i anmodningsteksten — HTML, JSON, XML, JavaScript eller blandede nyttelaster — og straks returnerer alle tilgængelige oversættelser. Når der ikke findes nogen, returneres kildeteksten og strengen indtages til oversættelse. Smartlings dokumentation beskriver platformen, der fungerer som en oversættelsesdatabase i denne tilstand, og lagrer én kopi af hver streng uanset hvor mange nyttelast der indeholder den, så en produktbeskrivelse, der gentages på tværs af tusindvis af rækker, oversættes én gang. Nogle kunder bruger TD API'en til at generere en opdateret oversættelsespakke, der er implementeret på et CDN, så mobil- og webapps læser nye oversættelser uden en build eller implementering. TD API'en er et betalt produkt, kræver et GDN-projekt til konfiguration og understøtter navnerum, varianter, pladsholdere og visuel kontekst.
  • Files API og direktiver til planlagte eksporter – for teams, der eksporterer tabeller efter en tidsplan, accepterer Smartling JSON-, CSV-, XLSX- og XML-filer på op til 10 MB hver, med direktiver på filniveau, der identificerer nøglekolonner, kildekolonner, oversætterinstruktioner og felter, der skal parses som HTML. Oversatte filer returneres i samme struktur til tilbageskrivning, og de samme strenge flyder gennem Smartlings oversættelseshukommelse og ordliste som alt andet indhold.
  • Globalt leveringsnetværk og dynamisk indholdsunderstøttelse til databasedrevne websteder — til webapplikationer indfanger Smartlings Global Delivery Network (GDN) oversættelsesproxy indhold under overførsel til browseren, inklusive indhold, der kaldes fra databasen, og bytter oversættelser uden ændringer i skemaet. Dynamisk indholdsunderstøttelse, der som standard er aktiveret på GDN-projekter oprettet efter august 2023, udvider dette til tekst gengivet i browseren af JavaScript-frameworks som React, og nye oversættelser når siden inden for cirka 20 minutter efter udgivelse. Mønstermatchningsregler maskerer dynamiske værdier - ordrenumre, navne, antal varer - så "Tak, dit ordrenummer er 56783" gemmes én gang som "Tak, dit ordrenummer er {0}", hvilket er den mekanisme, der forhindrer databasegenereret tekst i at oppuste oversættelsesvolumen.

Den praktiske implikation for et team, der vælger mellem de tre: TD API'en passer til applikationer, der allerede ejer en API-gateway og ønsker oversættelser på anmodningstidspunktet; fileksporter passer til batchkataloger og backoffice-indhold; og GDN passer til offentlige websteder, hvor den hurtigste vej er at lade databasen være i fred. Alle tre skriver ind i den samme oversættelseshukommelse, så et udtryk, der er oversat til webstedet, genbruges, når den samme streng ankommer fra en databaseeksport.

Relaterede spørgsmål

Klar til at se Smartling i aktion?

Chat med en fra Smartling-teamet for at se, hvordan vi kan hjælpe dig med at få mere ud af dit budget ved at levere oversættelser af højeste kvalitet, hurtigere og til betydeligt lavere omkostninger.

Aftal et møde