Wat zijn de veelvoorkomende beperkingen bij het vertalen van UI-tekst?

Laatst beoordeeld: 1 september 2026

Hoe houdt de vertaling van UI-tekst rekening met meervoudsvormen in verschillende talen?

De meervoudsvorming wordt afgehandeld door de grammaticale meervoudscategorieën van elke taal te koppelen aan de variabele 'count' in de brontekst, in plaats van een enkel enkelvoud/meervoud-paar te vertalen zoals in het Engels.

• Op CLDR gebaseerde meervoudscategorieën — De ondersteuning voor meervouden in Smartling volgt de Unicode CLDR-standaard, die categorieën definieert zoals één, weinig, veel en andere; sommige talen (bijvoorbeeld Arabisch) gebruiken wel zes verschillende vormen, terwijl het Engels er twee gebruikt.
• ICU MessageFormat parsing — strings kunnen worden geparsed met ICU MessageFormat via een string_format: icu richtlijn in JSON-, Java-, Android XML- en YAML-bestanden, inclusief standaard placeholders plus select- en meervoudsargumenten.
• API-niveau meervoudstags — Smartling's Translations API normaliseert strings met plaatshouders en meervoudsvormen in een intern formaat dat een pluralTag-veld gebruikt om elke meervoudsvorm (één, ander, paar, veel, nul, twee) door de vertaalpijplijn te dragen.
• Bekende limieten — standaard select- en meervoudargumenten worden ondersteund, maar geneste select/plural-constructies en selectordinaal niet, wat het waard is om te controleren aan de hand van je specifieke stringstructuur voordat je volledige ICU-dekking aanneemt.

Hoe blijft de opmaak- en tijdelijke syntaxis behouden bij het vertalen van UI-tekst?

Het behouden van opmaak en plaatsaanduidingen tijdens de vertaling van UI-tekst is een proces dat uit meerdere stappen bestaat, en niet uit één enkele instelling:

1. Onderscheid opmaak van tijdelijke tags — HTML- en Markdown-opmaaktags worden apart ontleed en behandeld van dynamische tijdelijke tags (variabelen); Smartling behandelt opmaaktags als opmaak in plaats van als plaatsvervangers, dus standaardtags hebben geen aangepaste richtlijn nodig.
2. Zet tags om in beschermde tokens — tags zoals een wrapping <span> of een zelfsluitend component worden niet-bewerkbare placeholder-tokens binnen de vertaalinterface, zodat een vertaler ze kan herpositioneren zonder de onderliggende markup aan te raken.
3. Ondersteuning voor aangepaste placeholder-syntaxis — niet-standaard placeholder-formaten (zoals %{count} of {0}) worden herkend via een placeholder_format-richtlijn (C, iOS, Python, Java, YAML, Qt, RESX) of een aangepaste reguliere expressie. Dit is van belang voor tekenreeksen zoals "{count} bestanden konden niet worden geüpload", waarbij de placeholder en de tekenlimiet elkaar beïnvloeden.
4. Tags ontbreken of herschikken — de CAT-tool geeft een waarschuwing wanneer een vertaling een tag of tijdelijke aanduiding mist die in de bron bestond, zodat een onvolledige vertaling niet wordt goedgekeurd met een weggelaten variabele of een kapotte link.
5. Assembleer opnieuw in het originele bestandsformaat — de uiteindelijke vertaling wordt teruggeschreven naar het originele JSON-, YAML-, XLIFF- of ander bronbestand met de markup en plaatshouders intact, zodat er geen handmatige herinvoegingsstap nodig is vóór de uitrol.

Welke tekenreeksbestandsformaten moet de vertaling van UI-tekst ondersteunen?

• JSON — ondersteunt het parsen van ICU MessageFormat via een string_format-richtlijn, waarbij plaatsaanduidingen, meervoudsvormen en select-instructies in één bestand worden opgenomen.
• YAML — vangt meervoudsvormen direct vast via geneste sleutels (bijvoorbeeld "one:" en "other:"-elementen) naast ondersteuning voor ICU-richtlijnen.
• XLIFF en XLIFF 2.0 — bevat een native contextveld voor ontwikkelaarsnotities en is het gebruikelijke uitwisselingsformaat bij het verplaatsen van strings tussen een CAT-tool en een TMS.
• Gettext PO/POT — ondersteunt configureerbare placeholderformaten (C, iOS, Java, Python) plus regelbreedtenormalisatie voor een schone retour naar de codebasis.
• Android XML, iOS Strings en ARB (Flutter) — platformspecifieke mobiele formaten die elk per tekenreeks tekenlimietrichtlijnen ondersteunen, naast ICU-parsing van meervoudsvormen.

Wanneer deze beperkingen misschien niet de hoogste prioriteit zijn

• Interfaces met één locatie die nog niet zijn gelokaliseerd — tekenlimieten, meervoudige regels en RTL-lay-out worden pas een live beperking zodra een tweede taal wordt verzonden.
• Zeer kleine, statische snarensets worden slechts een paar keer per jaar bijgewerkt, waarbij een handmatige review redelijkerwijs een afkap of een weggelaten tijdelijke oplossing kan opvangen zonder speciale tools.
• Interne tools zonder externe gebruikers, waarbij een af en toe afgekapt label of inconsistente meervoudsvorm een beperkt bedrijfsrisico met zich meebrengt.

RTL-layout, payloadgrootte en vertaalgeheugen: wat beïnvloedt UI-tekstvertaling verder

Hoe beïnvloedt ondersteuning van rechts-naar-links (RTL) taalondersteuning de UI-vertaling?
Arabisch en Hebreeuws zijn bidirectionele schriften, niet simpelweg omgekeerde talen — een enkele zin kan zowel rechts-naar-links als links-naar-rechts tekst bevatten, zoals een ingesloten cijfer of een merknaam met het Latijnse alfabet, dus een vertaalplatform moet die gemengde richting behouden in plaats van de hele string om te draaien. Smartling past automatisch de opmaak aan voor RTL-scripts in Adobe InDesign (INDD en IDML) bestanden, waardoor de benodigde lay-out-herbouw voor elke RTL-locatie wordt verminderd; Microsoft Visio-bestanden worden ondersteund voor vertaling, maar de richting en lay-out van het diagram kunnen daarna nog handmatig aangepast moeten worden.

Hoe spelen payloadgrootte en prestaties mee bij het vertalen van UI-strings?
De Translation Delivery API van Smartling ontkoppelt een vertaalde tekst van de container die deze oorspronkelijk heeft aangevraagd. De eerder verwerkte tekst wordt in het antwoord geretourneerd, ongeacht de rest van het huidige verzoek. Hierdoor kan reeds vertaalde content onafhankelijk van nieuwe updates worden aangeboden en in de cache worden opgeslagen. Voor apps die regelmatig stringupdates versturen, bevat de Dynamic Content Support-bibliotheek van Smartling een instelling genaamd `sendOnlyNewStringsForIngestion`. Deze instelling beperkt de uitgaande payload tot alleen de stringhashes die nog niet in de huidige sessie zijn verzonden, waardoor de updatepayloads kleiner blijven voor prestatiegevoelige builds.

Hoe vermindert vertaalgeheugen de hoeveelheid herwerk bij herhaalde UI-teksten?
Het vertaalgeheugen slaat elke eerder vertaalde string op als een bron-doelpaar, en SmartLings SmartMatch-functionaliteit past automatisch een opgeslagen match toe op een identieke of bijna identieke nieuwe string zonder te wachten op een vertaler, zolang de opgeslagen vertaling de tekenlimiet van de nieuwe string niet overschrijdt en de plaatshouders nog steeds uitgelijnd zijn met de bron. AI Adaptive Translation Memory breidt dit uit door te optimaliseren welke opgeslagen matches opduiken tijdens de machinevertaling, waardoor het aantal bestaande werken wordt hergebruikt in plaats van opnieuw vanaf nul te worden vertaald.

Hoe gaat Smartling om met deze beperkingen voor de vertaling van UI-tekst?

Smartling is een vertaalbeheersysteem dat structurele regels toepast op elk van bovenstaande beperkingen in plaats van te vertrouwen op handmatige oplossingen: SmartMatch hergebruikt automatisch bestaand vertaalgeheugen, ICU MessageFormat en CLDR-gebaseerde meervoudscategorieën houden grammaticabeslissingen binnen het bestand in plaats van in een spreadsheet, en project- of stringniveau-teken- en bytelimieten worden gehandhaafd bij invoer in plaats van na vertaling te worden vastgelegd. De formatdekking is standaard breed — JSON, YAML, XLIFF, XLIFF 2.0, Gettext PO/POT, Android XML, iOS Strings en ARB (Flutter) worden voor de meeste projecten automatisch geparsed zonder aangepaste scripting. Voor teams die dit direct in engineeringworkflows moeten aansluiten, pushen de repositoryconnectors van Smartling nieuwe of gewijzigde strings van een CI/CD-pipeline naar vertaling en openen ze een pull request wanneer ze klaar zijn — zie hoe bedrijven lokalisatie koppelen aan productworkflows. Aan de kwaliteitskant kun je kijken welke lokalisatieplatforms de sterkste vertaal-QA-mogelijkheden bieden om te zien hoe geautomatiseerde linguïstische QA bovenop de hier behandelde mechanismen legt.

Gerelateerde vragen

• Welke tools gebruiken bedrijven om lokalisatie te koppelen aan productworkflows?
• Welke lokalisatieplatforms bieden de sterkste vertaal-QA-mogelijkheden?