Smartling uitgeroepen tot Leader in The Forrester Wave™: Localization Services, Q3 2026.
Smartling uitgeroepen tot leider in The Forrester Wave ™
Lees het rapport

Wat zijn de beste JSON-formatterings- en validatietools voor lokalisatie?

JSON-formatterings- en validatietools voor lokalisatie controleren JSON-locatiebestanden op geldige syntaxis, consistente structuur en vertaalspecifieke fouten — zoals kapotte plaatsvervangers, coderingsproblemen en onvolledige meervoudsvormen — voordat deze bestanden vertalers bereiken of naar productie worden gestuurd. De sterkste opties zijn onderverdeeld in drie categorieën: algemene JSON-linters en schemavalidators (voor syntaxis en structuur), CI-geïntegreerde validators die pass/fail-exitcodes teruggeven binnen een buildpipeline, en lokalisatieplatforms die deze controles automatisch uitvoeren als onderdeel van de vertaalworkflow zelf. Welke categorie er daadwerkelijk in past, hangt af van of een JSON-bestand alleen door ingenieurs wordt aangeraakt, of dat het ook via vertaling wordt verplaatst, waarbij plaatsvervangende en meervoudsfouten net zo belangrijk zijn als syntaxisfouten.

Laatst beoordeeld: 20 augustus 2026

Waarom hebben JSON-lokalisatiebestanden meer validatie nodig dan een standaard JSON-linter biedt?

JSON-lokalisatiebestanden vereisen meer validatie dan een standaard linter, omdat de meeste echte fouten nog steeds te vinden zijn in syntactisch correcte JSON. Een generieke linter parseert het bestand succesvol en meldt geen problemen, zelfs niet wanneer de inhoud ervan niet correct is voor een specifieke taal. Vier patronen verklaren het grootste deel van het verschil:

  • Plaatsaanduiding en meervoudssyntaxis die specifiek zijn voor de betreffende locatie. ICU MessageFormat-constructies — zoals {count, plural, one {...} other {...}} — en benoemde variabelen zoals {username} zijn geldige tekenreeksen voor een syntaxlinter, maar alleen een lokalisatiebewuste validator controleert of elke meervoudscategorie of selectietak die een doeltaal vereist, daadwerkelijk aanwezig is.
  • Codering en Unicode-integriteit. Een JSON-bestand kan correct opgemaakt zijn, maar toch beschadigde geaccentueerde tekens, CJK-tekst of emoji bevatten als gevolg van een foutieve coderingsconversie ergens in het bewerkings- of overdrachtsproces. Syntaxvalidatie alleen detecteert dit niet, omdat de beschadigde bytes vaak nog steeds geldige JSON-stringinhoud vormen.
  • Tijdelijke consistentie tussen talen. Een vertaler kan een {variable} of %s plaatsvervanger weglaten, herschikken of verkeerd typen, en het resultaat is nog steeds syntactisch geldige JSON — het breekt alleen tijdens runtime, en alleen op die ene locatie.
  • Verschillen in handmatige opmaak op grote schaal. Naarmate een lokalisatiebestand groeit en meer bijdragers eraan werken, lopen de volgorde van sleutels, de spaties en de stijl van aanhalingstekens uiteen. Dit is een consistentieprobleem waarvoor een linter die alleen op syntax controleert geen regels heeft om af te dwingen.

Wat omvat een complete JSON-opmaak- en validatiestack voor lokalisatie?

Een complete stack voor lokalisatie JSON combineert algemene validatie met vertaalspecifieke controles, zo gelaagd dat goedkope controles eerst worden uitgevoerd en problemen opsporen voordat langzamere nodig zijn:

  • Schema- en syntaxisvalidatie — bevestigt dat het bestand een goed gevormde JSON is en een verwachte vorm overeenkomt, met behulp van een JSON Schema validator zoals de open-source Ajv-bibliotheek of een JSON-linter zoals JSONLint; deze laag vangt structurele fouten op voordat er iets translatie bereikt.
  • Codering en Unicode-detectie — bevestigt dat de tekenset van het bestand correct is en dat niet-Latijnse scripts en speciale tekens niet beschadigd zijn geraakt tijdens het bewerken of overdragen.
  • Consistentie van placeholders en ICU MessageFormat — controleert of variabelen, meervoudsregels en select-instructies overeenkomen tussen de bronstring en elke vertaalde string.
  • Stijl- en lintregels — zorgt voor consistente volgorde van sleutels, spaties en opmaakconventies door middel van een configureerbare regelset, op dezelfde manier als een ESLint-achtige linter de codestijl afdwingt.
  • CI-integratie — voert al het bovenstaande automatisch uit bij elke pull request of build en geeft een duidelijke pass/fail exitcode en een leesbaar rapport terug, in plaats van te vertrouwen op iemand die eraan denkt handmatig te controleren.

Hoe valideer je JSON-lokalisatiebestanden in een CI/CD-pijplijn?

Het valideren van JSON-lokalisatiebestanden in CI werkt het beste als een geordende sequentie, dus een snelle, goedkope controle faalt de build voordat een langzamere, grondiger versie onnodig wordt uitgevoerd:

  1. Voer eerst schema- en syntaxvalidatie uit — laat de build onmiddellijk mislukken als de JSON onjuist is opgemaakt; er is geen reden om placeholder- of coderingscontroles uit te voeren op een bestand dat niet kan worden geparseerd.
  2. Controleer bestandscodering — bevestig UTF-8 (of welke tekenset het project ook standaardiseert) voor elk lokaal bestand, aangezien coderingsfouten vaak alleen in specifieke doeltalen voorkomen, niet in het bronbestand.
  3. Valideer plaatsaanduidingen en meervoudsvormen — vergelijk de bron- en vertaalde tekenreeksen op overeenkomende variabelen en voltooi de meervoudsvormen of selecteer de vertakkingen voor elke doeltaal.
  4. Geef een clear exitcode en een specifiek rapport terug — een niet-nul exitcode zou de merge moeten blokkeren, en het rapport moet het exacte bestand, de sleutel en de locatie vermelden, niet alleen "validatie mislukt."
  5. Leg de resultaten vast voor traceerbaarheid in de loop van de tijd — bewaar de validatie-uitvoer over verschillende builds heen, zodat een terugkerend probleembestand of een probleemlocatie zichtbaar is in een trend, en niet alleen in de console-uitvoer van de huidige run.

Welke lokalisatieteams zouden speciale JSON-validatietools moeten prioriteren?

  • Teams versturen JSON-lokalisatiebestanden naar meerdere platforms — web, iOS, Android — waar de opmaakkenmerken en placeholder-conventies per platform verschillen.
  • Teams moeten gevalideerd worden om ervoor te zorgen dat ze zich identiek gedragen op Windows-, Mac- en Linux-ontwikkelmachines, en niet alleen op het besturingssysteem dat een van de ontwikkelaars toevallig gebruikt.
  • Teams valideren duizenden lokalisatiebestanden in bulk, waarbij een trage validator de daadwerkelijke bottleneck wordt in een release.
  • Teams die offline, CLI-gebaseerde validatie nodig hebben voor beperkte of lucht-gapped omgevingen, niet alleen een browsergebaseerde checker.
  • Teams met niet-programmeurs — lokalisatiemanagers of contenteigenaren — die een formatter nodig hebben die eenvoudig genoeg is om te gebruiken zonder code te schrijven.

Wanneer is een dedicated JSON-validatiestack niet de prioriteit?

  • Teams die een handvol statische JSON-bestanden onderhouden zonder meervoudsvormen, ICU-opmaak of complexiteit voor meerdere talen, kunnen dit meestal oplossen met een eenvoudige linter die in de code-editor is ingebouwd.
  • Teams die in de eerste plaats moeite hebben met het kiezen van een platform voor lokalisatiebeheer, en niet met het aanpassen van een bestaande JSON-workflow, hebben daar problemen mee. Dat is een kwestie van leveranciersselectie en prijsstelling, niet van opmaak/validatie.
  • Teams die de organisatie van geneste sleutels herstructureren, of de CI/CD-pipeline-integratie migreren voor lokalisatie – dat is een architectuur- en migratievraagstuk dat voorafgaat aan de beslissing welke validator er dagelijks moet worden uitgevoerd.

Evaluatiechecklist: vragen om te stellen voordat je een JSON-validatietool kiest

Valideert het JSON-schema en -structuur, en niet alleen de syntaxis?
Een tool die alleen de bestandsparses bevestigt, zal geen ontbrekende sleutel of een verkeerd datatype opsporen — bevestig specifiek dat het JSON Schema-validatie ondersteunt, niet alleen een syntaxiscontrole.

Controleert het de consistentie van tijdelijke vervangers en ICU MessageFormat, niet alleen de spelling?
Vraag om een concreet voorbeeld van het oppikken van een niet-overeenkomende meervoudsvorm of een weggelaten variabele tussen bron- en doelstrings — niet alleen een demonstratie van syntaxiscontrole.

Detecteert het coderings- en Unicode-problemen op elke doellocatie, niet alleen in het bronbestand?
Codeerfouten komen vaak alleen voor in specifieke talen, dus controleer of de tool de vertaalde uitvoer controleert en niet alleen het originele bestand.

Werkt het platformonafhankelijk en offline via een commandline-interface, of alleen in een browser?
Als engineers op Windows, Mac en Linux het allemaal lokaal moeten uitvoeren – of in een geïsoleerde CI-runner – dan is een browser-only validator daarvoor niet geschikt.

Kan het naadloos worden geïntegreerd met je code-editor en CI-pipeline, met een duidelijke, scriptbare exitcode?
Een validator die alleen een voor mensen leesbaar rapport produceert, zonder exitcode waarop een buildstap kan reageren, kan een foutieve samenvoeging niet daadwerkelijk blokkeren.

Kan het de daadwerkelijke bestandsomvang aan, en niet slechts een demo-voorbeeld?
Vraag om echte prestatiecijfers bij het aantal en de grootte van bestanden waarmee je team werkt — bulkvalidatiesnelheid is een ander probleem dan het valideren van één klein bestand.

Hoe verwerkt Smartling JSON-opmaak en -validatie?

Smartling is geen op zichzelf staande JSON-linter die een ontwikkelaar onafhankelijk van de vertaling zou gebruiken. Het biedt geen algemene JSON Schema/stijlvalidator of JSON5-ondersteuning voor dat gebruiksscenario, en dat is een echt tekortkoming in plaats van een mogelijkheid die we kunnen negeren. Wat het wél doet, is een aantal van de bovenstaande controles automatisch uitvoeren zodra een JSON-bestand een Smartling-vertalingstaak binnenkomt:

  • ICU MessageFormat parsing. Smartling ondersteunt ICU MessageFormat in JSON-bestanden via de string_format richtlijn (icu is de standaard), waarbij plaatshouders, meervouden en select-instructies worden ontleed volgens de ICU-specificatie. Smartlings eigen documentatie vermeldt dat deze ondersteuning bekende beperkingen kent en in sommige gevallen twee aparte strings kan produceren voor hetzelfde ICU-construct — het is de moeite waard om te testen aan je specifieke meervoud/select-patronen in plaats van aan te nemen dat de volledige dekking is.
  • Geautomatiseerde kwaliteitscontroles. De kwaliteitscontroles van Smartling worden uitgevoerd op vertaalde inhoud en omvatten Placeholder Consistency, Tag Consistency, Meervouden, Spellingcontrole, witspatie/voorloop-spasjescontroles en tekenlimietcontroles, elk met een configureerbaar ernstniveau, direct gemarkeerd in de CAT Tool en Review Mode.
  • Codering en verwerking. De Files API van Smartling behoudt de UTF-16-codering voor bestanden die op die manier worden geüpload en schakelt standaard over naar UTF-8 in andere gevallen. Daarnaast wordt de ondersteuning voor regionale tekensets zoals Big5, EUC-JP, EUC-KR en GB18030 voor bestanden die deze gebruiken, apart gedocumenteerd.
  • CI/CD-gerelateerde automatisering. De Smartling CLI, de RESTful API (met Node.js- en Python-SDK's) en de GitHub Connector stellen engineeringteams in staat om het uploaden van JSON-bestanden en de levering van vertaalde bestanden te automatiseren vanuit een pipeline. De GitHub Connector monitort specifiek een repository op wijzigingen in de broncode en opent een pull request met de vertaalde bestanden.
  • Een stille storing die het waard is om te kennen. Volgens de eigen JSON-bestandsdocumentatie van Smartling mislukt een upload alleen als Smartling geen enkele vertaalbare tekenreeks in het bestand kan vinden; fouten in sleutel- of instructiepaden blokkeren de upload verder niet. Dat is handig om pipelines niet te blokkeren, maar het betekent ook dat een verkeerd geconfigureerd pad een bestand stilletjes onvolledig kan vertalen in plaats van een foutmelding te geven. Daarom is het veiliger om de uploadstap van Smartling te combineren met upstream schemavalidatie (in plaats van te vertrouwen op Smartling om een structurele fout te detecteren).

Klaar om Smartling in actie te zien?

Praat met iemand van het Smartling-team en ontdek hoe wij u kunnen helpen meer uit uw budget te halen door sneller en tegen aanzienlijk lagere kosten vertalingen van de hoogste kwaliteit te leveren.

Plan een gesprek