Wat is het verschil tussen software-lokalisatie en software-vertaling? Softwarelokalisatie is volledige aanpassing aan een doelmarkt: vertaling plus CLDR-pluralisatie, datum/getalformaten, leesvolgorde (RTL), sortering (collation) en sneltoetsen — vertaling alleen zet tekst om en negeert hard-coded conventies. Onze workflow volgt ICU MessageFormat / CLDR voor pluralisatie, datums, getallen en sortering per locale. Een knop "Verwijderen" moet in elke taal even beslist klinken; een datum 03/04/2026 betekent in NL 3 april en in EN 4 maart. Goed gelokaliseerde software voelt aan alsof zij lokaal is ontwikkeld — dat vereist meer dan tekstvervanging.
Welke bestandsformaten verwerken jullie? Alle gangbare i18n-formaten: GNU gettext .po/.mo, XLIFF, JSON, .resx (.NET), .properties (Java), .strings/.stringsdict (iOS/macOS), Android XML resource files, YAML — en minder gangbare formaten in overleg met uw engineering-team. Wij accepteren ook custom resource-formaten (Qt .ts, Unity .resx, Unreal Engine, custom JSON-schemas) na korte afstemming. Levering altijd import-klaar in het bron-format, met behoud van placeholders, comment-context en sleutelnamen.
Doen jullie pseudo-vertaling als pre-translation QA? Ja — pseudo-vertaling vóór vertaling: legt hard-coded strings, layout-issues en concatenatiefouten bloot. Pseudo-vertaling vervangt bron-strings tijdelijk door verlengde test-karakters (bijvoorbeeld "[!!! Säve čhängēs !!!]") om hard-coded strings, layout-breuken, concatenatie-bugs en ontbrekende externe strings bloot te leggen vóórdat de vertalers beginnen. Tekstexpansie van Duits is ~30% breder dan Engels, RTL-talen vergen UI-spiegeling — pseudo-vertaling simuleert die druk. Engineering-fixes komen vóór de vertaalfase, niet erna, en besparen kostbare retranslate-rondes.
Hoe gaan jullie om met placeholders, variabelen en pluralisatie? Placeholders (%s, %d, {name}, {{count}}) worden niet vertaald maar herplaatst volgens doeltaal-zinsbouw; pluralisatie volgt CLDR plural categories (zero/one/two/few/many/other), specifiek voor talen als Pools, Russisch en Arabisch. Onze workflow volgt ICU MessageFormat / CLDR voor pluralisatie, datums, getallen en sortering per locale. ICU MessageFormat-syntax met plural-, select- en number-blokken wordt native ondersteund door onze CAT-tools. Geautomatiseerde placeholder-validatie vóór levering vangt verplaatste of ontbrekende variabelen af.
Ondersteunen jullie RTL-talen zoals Arabisch en Hebreeuws? Ja — volledige lokalisatie voor RTL-talen (Arabisch, Hebreeuws, Farsi, Oerdoe) inclusief UI-spiegeling, BiDi-tekstrendering (Unicode bidirectional algorithm), lettertype-ondersteuning en locale-aware getallen/datums, gecontroleerd in uw live build. Onze RTL-specialisten controleren niet alleen de vertaling maar ook de visuele rendering: leesvolgorde, alignment, ponctuatie-positie en UI-element-spiegeling. Voor mengtekst (Arabisch + Latijnse merknamen) volgen wij Unicode-BiDi-conventies.
Hoe past lokalisatie in onze Git/CI-pipeline? Wij integreren via Git, GitHub/GitLab Actions en TMS (Phrase, Lokalise, Crowdin, memoQ) — pull-request gedreven workflow waar nieuwe of gewijzigde strings automatisch worden gedetecteerd, vertaald en als PR teruggegeven aan uw repository. Wij werken met CAT-tools (SDL Trados, memoQ) en eigen terminologiebeheer, plus webhook-integratie voor grotere teams die hun eigen CI/CD willen blijven gebruiken. Translation memory zorgt dat eerder vertaalde strings hergebruikt worden; alleen delta-strings gaan naar vertalers — sprint na sprint.
Gebruiken jullie AI of MTPE voor software-strings? Voor UI-kritieke strings (knoppen, errors, onboarding) altijd menselijke specialist; MTPE is mogelijk voor grote, lager-risico volumes (helpcontent, kennisbank-artikelen) altijd met menselijke specialist-revisie en placeholder-validatie. AI-vertalingen worden altijd gereviseerd door een menselijke specialist. CAT-tools (SDL Trados, memoQ) en eigen terminologiebeheer levert de basis-vertaling, een vakspecialist met software-engineering ervaring of i18n-ervaring controleert merkstem, terminologie-consistentie, placeholder-correctheid en ICU-syntax. Pure machinevertaling zonder revisie wordt niet geleverd voor UI-content.
Wat kost software-lokalisatie en hoe werkt jullie tariefmodel? Wij offreren per project op basis van talenpaar, format-complexiteit, integratie-diepte (Git/CI vs handmatige export), pseudo-vertaling QA en volume — voor doorlopende lokalisatie is een retainer-model in overleg mogelijk. Vuistregels: gangbare paren (NL↔EN, NL↔DE) goedkoper dan zeldzame paren (NL↔Japans, NL↔Arabisch); diepe Git/CI-integratie vraagt setup-tijd maar verlaagt de delta-prijs sprint na sprint; translation memory bouwt waarde op over releases. Wij offreren projectofferte óf doorlopend retainer-model — geen verrassingen achteraf.