Wanneer vertalingen je tekenlimieten in de app store breken
Je schreef een strakke appnaam van 28 tekens, een pakkende subtitel van 29 tekens en een keywordveld dat alle 100 tekens gebruikt. Toen lokaliseerde je de vermelding en begon App Store Connect velden te weigeren — de Duitse subtitel is 41 tekens, de Franse 36. De Engelse versie was nooit het probleem. Elke taal krijgt zijn eigen kopie van elk veld, en elke kopie moet zelfstandig binnen dezelfde limiet passen.
Dit is het overzicht van wat die limieten zijn, waarom vertaling erover heen schiet, en hoe je een vermelding leesbaar houdt in elke taal in plaats van woorden doormidden te hakken.
De tekenlimieten, beide stores
Elk getal hieronder geldt per taal. Als je lokaliseert naar Frans, Duits, Japans enzovoort, heeft elke taal zijn eigen kopie van elk veld, en wordt elke kopie bij het indienen tegen dezelfde limiet getoetst.
Twee dingen zijn het vermelden waard. Het keywordveld van de App Store is een verborgen, met komma's gescheiden slot van 100 tekens — niet zichtbaar op de productpagina, maar het bepaalt een groot deel van je indexering, dus telt elk teken. En de krapste velden — de naam en subtitel van 30 tekens — zijn precies degene waar vertaling het hardst toeslaat.
Waarom de vertaalde versie over de limiet gaat
Dezelfde betekenis kost in verschillende talen een ander aantal tekens. Vertaald vanuit het Engels is de ruwe richting consistent genoeg om op te plannen:
- Duits: vaak +30-40%. Samengestelde zelfstandige naamwoorden smelten meerdere Engelse woorden samen tot één lang woord, en er is geen korter synoniem om op terug te vallen. Dit is de taal die een veld van 30 tekens het vaakst breekt.
- Frans, Spaans, Italiaans, Portugees: ongeveer +15-25%. Consistente, gematigde uitbreiding. Een naam die comfortabel op 24 tekens zit in het Engels, komt uit rond of net over de 30.
- Chinees, Japans, Koreaans: vaak zo'n 50% korter in tekenaantal. CJK-schriften bevatten meer betekenis per teken, dus de veldlimiet is zelden de beperkende factor — leesbaarheid en woordkeuze zijn dat wel.
- Arabisch, Hebreeuws en andere RTL-schriften: reken op uitbreiding van +15-30% plus een richtingswissel. Deze hebben een menselijke reviewslag nodig, nooit ruwe machinevertaling — bidirectionele tekst en niet-Latijnse keywordvelden zijn waar geautomatiseerde output stilletjes misgaat.
Zie dit als planningsmarges, geen garanties. Het gaat om de richting: als een veld dicht bij zijn limiet zit in het Engels, ga ervan uit dat de Europese vertalingen erover heen gaan en de CJK-versies juist korter uitvallen. Bouw een paar tekens speling in de Engelse brontekst en de uitbreiding heeft ergens naartoe.
Hoe het eruitziet als de limiet wordt overschreden
Zowel Apple als Google handhaven de limieten bij het indienen. In de praktijk kom je één van twee faalmodi tegen. Het storeformulier weigert de extra tekens ronduit — je kunt fysiek niet verder typen dan de limiet, dus een geplakte vertaling wordt stilzwijgend afgekapt op de grens, midden in een woord. Of het veld accepteert de tekst en de vermelding wordt bij de review afgewezen. Hoe dan ook eindigt de vertaalde naam of subtitel afgekapt, verkeerd gespeld door de afkapping, of ontbreekt hij helemaal in die markt.
Niets daarvan is zichtbaar vanuit de Engelse vermelding. Het komt per taal naar boven, één taal tegelijk, meestal nadat je dacht dat de vermelding klaar was.
De oplossing: transcreëer, kap niet af
Een Duitse subtitel afkappen bij teken 30 levert een gebroken half woord op dat voor een moedertaalspreker als machinaal verminkt leest. De juiste aanpak is om de naam en subtitel per taal te herschrijven zodat ze dezelfde intentie overbrengen binnen de limiet.
- Kort eerst de bron in. Een Engelse subtitel van 22 tekens overleeft een uitbreiding van 35%; eentje van 29 tekens niet. Speling in het Engels is de goedkoopste oplossing.
- Transcreëer de krappe velden. Kies voor naam en subtitel een korter synoniem of laat een opvulwoord weg in de doeltaal in plaats van woord-voor-woord te vertalen. Het doel is een zin die past en natuurlijk leest, geen letterlijke match.
- Geef RTL- en niet-Latijnse velden een menselijke check. Arabisch, Hebreeuws en niet-Latijnse keywordlijsten zijn de plekken waar machinevertaling fouten maakt die je niet ziet als je het schrift niet leest.
- Controleer het aantal tekens in het doelschrift, niet het Engelse. Tekenaantal is wat de store meet, en dat verschilt per taal — dus het moet na vertaling gemeten worden, per veld.
Waar Mokbi helpt
Mokbi vertaalt je hele vermelding — naam, subtitel, keywords, beschrijving — in 50 talen, en toont het tekenaantal per taal voor elk veld terwijl je bezig bent. De overschrijdingen komen daar direct in de editor naar boven, voordat je iets plakt in App Store Connect of Play Console, zodat je de Duitse subtitel van 41 tekens opvangt terwijl je hem nog kunt inkorten in plaats van na een afwijzing.
Dat is een eerste slag, geen laatste. Het brengt elk veld binnen de limieten en markeert de velden die zijn uitgebreid, wat het meeste werk is. Maar je belangrijkste markten verdienen nog altijd een menselijke blik — een moedertaalspreker die bevestigt dat de getranscreëerde naam goed klinkt en dat de RTL-velden correct zijn. De tool haalt het giswerk weg over welke velden zijn gebroken; een mens bevestigt dat de belangrijkste velden goed lezen.