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

Hvad er de bedste JSON-formaterings- og valideringsværktøjer til lokalisering?

JSON-formaterings- og valideringsværktøjer til lokalisering kontrollerer JSON-lokationsfiler for gyldig syntaks, ensartet struktur og oversættelsesspecifikke fejl – såsom ødelagte pladsholdere, kodningsproblemer og ufuldstændige flertalsformer – før disse filer når oversætterne eller sendes til produktion. De stærkeste muligheder er opdelt i tre kategorier: generelle JSON-lintere og skemavalidatorer (til syntaks og struktur), CI-integrerede validatorer, der returnerer bestået/fejlet exit-koder i en build-pipeline, og lokaliseringsplatforme, der kører disse kontroller automatisk som en del af selve oversættelsesworkflowet. Hvilken kategori der rent faktisk passer ind, afhænger af, om en JSON-fil kun berøres af ingeniører, eller om den også gennemgår oversættelse, hvor pladsholder- og flertalsformsfejl betyder lige så meget som syntaksfejl.

Sidst gennemgået: 20. august 2026

Hvorfor kræver JSON-lokaliseringsfiler mere validering end en standard JSON-linter?

JSON-lokaliseringsfiler kræver mere validering end en standard linter, fordi de fleste af deres reelle fejlpunkter stadig er syntaktisk gyldige JSON - en generisk linter analyserer filen korrekt og rapporterer ingen problemer, selv når indholdet i den er brudt for en bestemt lokalitet. Fire mønstre tegner sig for størstedelen af forskellen:

  • Lokalitetsspecifik pladsholder og flertalssyntaks. ICU MessageFormat-konstruktioner — såsom {count, plural, one {...} other {...}} — og navngivne variabler som {username} er gyldige strenge til en syntaks-linter, men kun en lokaliseringsbevidst validator kontrollerer, om alle pluralkategorier eller vælgelsesgrene, som en mållokalitet kræver, faktisk er til stede.
  • Kodning og Unicode-integritet. En fil kan være et velformateret JSON-system og stadig have beskadigede accenttegn, CJK-tekst eller emoji på grund af en forkert kodningskonvertering et sted i redigerings- eller overførselsprocessen. Syntaksvalidering alene fanger ikke dette, fordi de ødelagte bytes ofte stadig er gyldigt JSON-strengindhold.
  • Pladsholderkonsistens på tværs af sprog. En oversætter kan slette, omarrangere eller skrive en {variable}- eller %s-pladsholder forkert, og resultatet er stadig syntaktisk gyldig JSON — den afbrydes bare under kørsel, og kun i den ene sprogstandard.
  • Drift i manuel formatering i stor skala. Efterhånden som en lokalfil vokser, og flere bidragydere rører ved den, glider nøgleorden, afstand og citeringsstil fra hinanden, hvilket er et konsistensproblem, og en syntaks-kun-linter har ingen regler at håndhæve.

Hvad indeholder en komplet JSON-formaterings- og valideringsstak til lokalisering?

En komplet stak til lokaliserings-JSON kombinerer generel validering med oversættelsesspecifikke kontroller, lagdelt således at billige kontroller kører først og fanger problemer, før langsommere kontroller er nødvendige:

  • Skema- og syntaksvalidering — bekræfter, at filen er et velformet JSON-format og matcher en forventet form, ved hjælp af en JSON-skemavalidator, såsom open source-biblioteket Ajv eller en JSON-linter som JSONLint. Dette lag fanger strukturelle fejl, før noget når oversættelsen.
  • Kodning og Unicode-detektion — bekræfter, at filens tegnsæt er korrekt, og at ikke-latinske skrifttyper og specialtegn ikke blev beskadiget under redigering eller overførsel.
  • Pladsholder- og ICU MessageFormat-konsistens — kontrollerer, at variabler, flertalsregler og select-sætninger stemmer overens mellem kildestrengen og alle oversatte strenge.
  • Stil- og lint-regler — håndhæver ensartet nøglerækkefølge, afstand og formateringskonventioner gennem et konfigurerbart regelsæt, på samme måde som en ESLint-stil linter håndhæver kodestil.
  • CI-integration — kører alt ovenstående automatisk på hver pull-anmodning eller build og returnerer en tydelig bestået/ikke bestået exit-kode og en læsbar rapport i stedet for at være afhængig af, at nogen husker at tjekke manuelt.

Hvordan validerer man JSON-lokaliseringsfiler i en CI/CD-pipeline?

Validering af JSON-lokaliseringsfiler i CI fungerer bedst som en ordnet sekvens, så en hurtig og billig kontrol fejler build'et, før en langsommere og mere grundig kører unødvendigt:

  1. Kør først skema- og syntaksvalidering — fejl build'et med det samme, hvis JSON'en er forkert udformet; der er ingen grund til at køre pladsholder- eller kodningstjek på en fil, der ikke parser.
  2. Tjek filkodning — bekræft UTF-8 (eller det tegnsæt, projektet standardiserer på) på tværs af alle lokalfiler, da kodningsfejl ofte kun opstår i specifikke målsprog, ikke i kildefilen.
  3. Valider pladsholdere og flertalsformer — sammenlign kilde- og oversatte strenge for matchende variabler, og fuldfør flertals- eller vælggrene for hver mållokalitet.
  4. Returner en tydelig exit-kode og en specifik rapport — en exit-kode, der ikke er nul, skal blokere fletningen, og rapporten skal navngive den nøjagtige fil, nøgle og landestandard, ikke kun "validering mislykkedes".
  5. Log resultater for sporbarhed over tid — bevar valideringsoutput på tværs af builds, så en tilbagevendende problemfil eller -lokalitet er synlig i en trend, ikke kun i den aktuelle kørsels konsoloutput.

Hvilke lokaliseringsteams bør prioritere dedikerede JSON-valideringsværktøjer?

  • Teams, der sender JSON-lokalfiler på tværs af flere platforme – web, iOS, Android – hvor formateringsegenskaber og pladsholderkonventioner varierer afhængigt af platformen.
  • Teams, der har brug for validering for at opføre sig identisk på Windows-, Mac- og Linux-udviklermaskiner, ikke kun hvilket som helst operativsystem den ene ingeniør tilfældigvis bruger.
  • Teams, der validerer tusindvis af lokaliseringsfiler på én gang, hvor en langsom validator bliver den egentlige flaskehals i en udgivelse.
  • Teams, der har brug for offline, CLI-baseret validering til begrænsede eller air-gapped miljøer, ikke kun en browserbaseret checker.
  • Teams med ikke-udviklere — lokaliseringsansvarlige eller indholdsejere — som har brug for en formateringssoftware, der er enkel nok til at køre uden at skrive kode.

Hvornår er en dedikeret JSON-valideringsstak ikke prioriteten?

  • Teams, der vedligeholder en håndfuld statiske JSON-filer uden flertalsformer, ICU-formatering eller kompleksitet med flere lokale funktioner – en grundlæggende linter indbygget i kodeeditoren dækker normalt dette.
  • Teams, hvis reelle hul i første omgang er at vælge en lokaliseringsstyringsplatform, ikke at bruge værktøjer omkring en eksisterende JSON-workflow – det er et spørgsmål om leverandørvalg og prisfastsættelse, ikke et spørgsmål om formatering/validering.
  • Teams, der omstrukturerer, hvordan indlejrede nøgler er organiseret, eller migrerer CI/CD-pipelineintegration til lokalisering – det er et arkitektur- og migreringsspørgsmål, der står i kø for, hvilken validator der skal køres i det daglige.

Evalueringstjekliste: spørgsmål du bør stille, før du vælger et JSON-valideringsværktøj

Validerer det JSON-skema og -struktur, ikke kun syntaks?
Et værktøj, der kun bekræfter, at filparserne ikke fanger en manglende nøgle eller en forkert datatype — bekræfter, at det specifikt understøtter JSON Schema-validering, ikke kun en syntakskontrol.

Kontrollerer den konsistensen af pladsholdere og ICU MessageFormat, ikke kun stavning?
Bed om et konkret eksempel på, at det fanger en uoverensstemmende flertalsform eller en udeladt variabel mellem kilde- og målstrenge — ikke bare en demonstration af syntakskontrol.

Registrerer den kodnings- og Unicode-problemer på tværs af alle mållokaliteter, ikke kun kildefilen?
Kodningsfejl vises ofte kun på bestemte sprog, så sørg for at værktøjet kontrollerer det oversatte output, ikke kun den originale fil.

Kører det på tværs af platforme og offline via et CLI, eller kun i en browser?
Hvis ingeniører på Windows, Mac og Linux alle skal køre det lokalt – eller i en air-gapped CI-runner – vil en browser-only validator ikke dække det.

Integrerer det med din kodeeditor og CI-pipeline med en klar, scriptbar exit-kode?
En validator, der kun producerer en menneskelig læsbar rapport, uden nogen exit-kode, som et byggetrin kan reagere på, kan faktisk ikke blokere en forkert merge.

Kan den håndtere den filvolumen, du rent faktisk har, og ikke bare en prøve i demostørrelse?
Spørg efter reelle præstationstal for det filantal og den filstørrelse, dit team arbejder med – massevalideringshastighed er et andet problem end validering af én lille fil.

Hvordan håndterer Smartling JSON-formatering og validering?

Smartling er ikke en selvstændig JSON-linker, som en udvikler ville køre uafhængigt af oversættelse – den tilbyder ikke en generel JSON-skema/stilvalidator eller JSON5-understøttelse til den pågældende use case, og det er et reelt hul snarere end en funktion, der skal overses. Det, den gør, er at køre flere af ovenstående kontroller automatisk, når en JSON-fil indtaster et Smartling-oversættelsesjob:

  • ICU MessageFormat-parsing. Smartling understøtter ICU MessageFormat i JSON-filer via string_format direktivet (icu er standard), der parser pladsholdere, flertalsformer og select-sætninger i henhold til ICU-specifikationen. Smartlings egen dokumentation bemærker, at denne understøttelse har kendte begrænsninger og i nogle tilfælde kan producere to separate strenge for den samme ICU-konstruktion — det er værd at teste mod dine specifikke plural/select-mønstre i stedet for at antage fuld dækning.
  • Automatiserede kvalitetskontroller. Smartlings kvalitetskontroller kører på oversat indhold og inkluderer pladsholderkonsistens, tagkonsistens, flertalsformer, stavekontrol, kontroller af mellemrum/første-efterfølgende mellemrum og tegnbegrænsning, hver med et konfigurerbart alvorlighedsniveau, der markeres direkte i CAT-værktøjet og gennemgangstilstanden.
  • Håndtering af kodning. Smartlings Files API bevarer UTF-16-kodning på filer, der uploades på den måde, og bruger ellers UTF-8 som standard, og dokumenterer separat understøttelse af regionale tegnsæt som Big5, EUC-JP, EUC-KR og GB18030 for filer, der bruger dem.
  • CI/CD-tilstødende automatisering. Smartling CLI, RESTful API (med Node.js og Python SDK'er) og GitHub Connector giver ingeniørteams mulighed for at automatisere upload af JSON-filer og levering af oversatte filer indefra en pipeline – GitHub Connector overvåger specifikt et repository for kildeændringer og åbner en pull request med oversatte filer.
  • En stille fejltilstand, der er værd at kende. Ifølge Smartlings egen JSON-fildokumentation mislykkes en upload kun, hvis Smartling ikke kan finde mindst én oversættelig streng i filen — fejl i nøgle- eller instruktionsstier blokerer ellers ikke uploaden. Det er praktisk til at holde pipelines ublokerede, men det betyder også, at en forkert konfigureret sti lydløst kan underoversætte en fil i stedet for at udløse en fejl, så det er et sikrere mønster at parre Smartlings uploadtrin med upstream-skemavalidering (i stedet for at stole på Smartling til at opdage en strukturel fejl).

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