RTL-ondersteuning: software bouwen die werkt in het Arabisch en Hebreeuws

RTL-ondersteuning (right-to-left, van rechts naar links) betekent dat een interface correct leest in talen als het Arabisch en het Hebreeuws, waar tekst van rechts naar links loopt in plaats van van links naar rechts. De fout die bijna elk team maakt, is dit behandelen als een instelling voor tekstuitlijning. Dat is het niet. RTL keert de hele lay-out om: de navigatie, de iconen, de formuliervelden en de richting waarin het oog van de gebruiker over het scherm beweegt. Doe het verkeerd en de software oogt niet vreemd. Ze oogt kapot, en gebruikers van RTL-talen zien dat binnen de eerste seconden.

Voor een Nederlands of Vlaams bedrijf is het Arabisch trouwens geen verre taal. Het is de taal van grote gemeenschappen in Nederland en Vlaanderen, en van exportmarkten in de Golfregio en het Midden-Oosten. We hebben het gemarkeerd als een van de twee schriftfamilies die een zwakke internationalisatie (i18n) het snelst blootleggen, naast de CJK-schriften, binnen meertalige softwareontwikkeling. Hieronder staat wat RTL echt vereist: het spiegelen van de lay-out, het CSS-mechanisme dat het onderhoudbaar maakt, de omgang met bidirectionele tekst, en een testaanpak die de bugs vindt voordat een echte gebruiker dat doet.

Wat RTL echt omkeert

dir="rtl" op een pagina zetten keert meer om dan de meeste teams verwachten, en elk van deze punten moet kloppen, niet alleen de tekst in de paragrafen:

• Navigatie en menu's. Een navigatie links wordt een navigatie rechts. Broodkruimels, tabs en de pijltjes van dropdowns keren allemaal om.
• Iconen die een richting impliceren. De pijlen voor "terug" en "volgende", de chevrons en de voortgangsindicatoren wijzen de andere kant op, want "vooruit" in een RTL-interface wijst visueel naar links.
• Lay-out van formulieren. De labels, de uitlijning van velden en de tabvolgorde door een formulier met meerdere velden spiegelen allemaal, anders leest een formulier in isolatie goed maar springt de tab in de verkeerde volgorde door de velden.
• Voortgangs- en stapindicatoren. Een aanmeldflow van vijf stappen die zich van links naar rechts vult in het Nederlands, moet zich van rechts naar links vullen in het Arabisch, anders houdt de visuele metafoor op te kloppen.

Sla een van deze punten over en je krijgt een hybride interface: Arabische tekst die zit in een lay-out die voor het Nederlands is getekend. Ze leest als onaf, omdat ze dat is.

CSS logical properties: het mechanisme dat RTL onderhoudbaar maakt

De oude aanpak van RTL was een aparte stylesheet waarin elke left was vervangen door right, met de hand onderhouden, eeuwig uit de pas lopend met de hoofdlay-out. Moderne CSS lost dit netjes op met logical properties, die de positie beschrijven ten opzichte van de tekstrichting in plaats van ten opzichte van een fysieke kant.

margin-inline-start en margin-inline-end vervangen margin-left en margin-right. padding-inline-start vervangt een hardcoded padding-left. Zo geschreven keert de browser de lay-out automatisch om op basis van het dir-attribuut van de pagina, en bedient één stylesheet beide richtingen correct. Op de oude manier geschreven, met fysieke waarden links en rechts, keert er niets om, en belandt de Arabische tekst links uitgelijnd in een rechts uitgelijnde interface, met de padding aan de verkeerde kant.

Dit is de beslissing die het zwaarst weegt in RTL-ondersteuning. Een codebase die vanaf het begin op logical properties is gebouwd, ondersteunt RTL als een simpele configuratie. Een codebase die op hardcoded waarden links en rechts is gebouwd, vraagt een handmatige audit van elk component voordat dat lukt.

Wanneer Arabische tekst een Latijnse productcode tegenkomt

Echte content blijft zelden in één richting. Een Arabische zin met een productcode (SKU), een telefoonnummer of een Engelse merknaam moet de RTL-tekst van rechts naar links tonen terwijl de ingebedde Latijnse tekens en cijfers nog steeds van links naar rechts lezen, op hun plek, zonder de omringende zin door elkaar te gooien.

Dit wordt geregeld door het Unicode Bidirectional Algorithm (UAX #9), dat de visuele volgorde van tekst met gemengde richtingen bepaalt uit de eigenschappen van de onderliggende tekens. Meestal werkt het vanzelf. Het breekt op twee voorspelbare plekken: cijfers en leestekens aan de rand van een tekstsegment, waar het algoritme moet raden welke richting een gedeeld teken als een streepje of een schuine streep "bezit", en dynamisch ingevoegde content, zoals een productnaam die uit een database wordt gehaald en in een vertaalde zin wordt geïnterpoleerd, waar de omringende markup zijn richting niet aangeeft. De oplossing is in beide gevallen expliciet: Unicode-isolatietekens (U+2066–U+2069) of de HTML-elementen dir en bdi markeren waar tekst van de ene richting in de andere is ingebed, in plaats van het algoritme te laten raden.

Sla deze stap over en je krijgt het RTL-equivalent van mojibake: een telefoonnummer dat achterstevoren wordt weergegeven, of een zin waar een productcode aan de verkeerde kant van de omringende woorden verschijnt. De vergelijking is niet alleen beeldspraak, want beide storingen komen uit dezelfde laag: zie Unicode en tekencodering voor de bytekant van het probleem.

Welke iconen spiegelen, en welke juist niet

Niet elk icoon keert om, en het in beide richtingen fout doen leest als een bug.

Wel spiegelen: pijlen voor terug en vooruit, chevrons, de knoppen "volgende" en "vorige", voortgangsbalken, en elk icoon dat een links-rechtsvolgorde of een bewegingsrichting weergeeft.

Niet spiegelen: klokken, de afspeelknop van een mediaspeler, een vinkje, cijfers, logo's, en foto's van mensen of objecten. Een gespiegelde wijzerplaat of een omgekeerd afspeeldriehoekje ziet eruit als een weergavefout, niet als een lokalisatiekeuze, want die iconen stellen een object uit de echte wereld voor, geen richtingmetafoor.

Zo geformuleerd klinkt het onderscheid simpel. In de praktijk vraagt het een bewuste doorloop van elk icoon in de interface, waarbij je ze stuk voor stuk indeelt, want een globale "keer alles om"-transformatie zit er in beide richtingen naast.

RTL testen voordat echte gebruikers de bugs vinden

RTL-bugs verschuilen zich voor een QA-ronde die alleen in het Nederlands loopt, want niets in de zichtbare lay-out oogt onaf zolang echte RTL-content de pagina niet heeft gevuld. Drie controles vangen wat een vluchtige blik mist:

1. Test met echte Arabische of Hebreeuwse content, geen lorem ipsum of vulblokken. Vultekst is uniform in lengte en richting en legt dus nooit de bidi-randgevallen bloot, en ook het probleem van tekstexpansie niet: het W3C meet dat korte interfacelabels tot 300% kunnen uitzetten bij vertaling vanuit het Engels, en dat zelfs alledaagse woorden regelmatig langer zijn dan hun bron (W3C, Text size in translation). Het Nederlands begint al langer dan het Engels, en een knop die op de millimeter is uitgemeten voor "Opslaan" overleeft zijn Arabische equivalent niet zonder een test met echte content.
2. Draai een pseudo-lokalisatieronde in geforceerde RTL-modus. De meeste moderne frameworks kunnen de richting van een pagina omkeren zonder dat er een vertaling klaarligt, wat lay-outbreuken snel naar boven haalt (iconen die de verkeerde kant op wijzen, scheve formulieren, overflow), nog voordat vertaalde content klaar is om mee te testen.
3. Neem minstens één testgeval met gemengde richtingen op. Een formulierveld, een zoekresultaat of een melding die RTL-tekst combineert met een productcode, een e-mailadres of een bedrag uit je multivaluta-ondersteuning in Latijnse tekens. Dat is precies waar het bidirectionele algoritme hulp nodig heeft, en waar de aansluitingsbugs zich verschuilen. Een bedrag in Marokkaanse dirham dat achterstevoren in een Arabische zin verschijnt, blijft een verkeerd bedrag.

We draaien pseudo-lokalisatie plus minstens één RTL-locale en één CJK-locale op elke meertalige build, precies om deze reden: RTL-bugs kosten weinig om te fixen tijdens de ontwikkeling en veel om te fixen nadat een klant meldt dat de app er "kapot uitziet" in het Arabisch.

Veelgestelde vragen over RTL-ondersteuning

Wat betekent RTL in software?

RTL staat voor right-to-left, van rechts naar links, en verwijst naar talen als het Arabisch en het Hebreeuws die in die richting lezen. RTL-ondersteuning betekent dat de hele interface, niet alleen de tekst, correct spiegelt: navigatie, iconen, formulieren en de lay-outrichting keren samen om.

Welke talen hebben RTL-ondersteuning nodig?

Het Arabisch en het Hebreeuws zijn de twee grote RTL-schriften in commerciële software; het Perzisch (Farsi) en het Urdu gebruiken ook het Arabische schrift en lezen van rechts naar links. Alle andere grote wereldtalen, waaronder het Chinees, het Japans en het Koreaans, lezen van links naar rechts ondanks andere eigenaardigheden in de lay-out.

Kan ik niet gewoon mijn CSS omkeren door links en rechts te wisselen?

Dat kan, maar dan ontstaat een tweede stylesheet die bij elke update van de hoofdlay-out uit de pas gaat lopen. Met CSS logical properties (margin-inline-start in plaats van margin-left) bedient één stylesheet beide richtingen automatisch, op basis van de aangegeven richting van de pagina.

Waarom toont Arabische tekst soms cijfers of Engelse woorden in de verkeerde volgorde?

Dat is een bug in de bidirectionele tekst: content met gemengde richtingen (Arabische tekst met daarin een Latijnse productcode, een telefoonnummer of een merknaam) heeft expliciete richtingsmarkeringen nodig zodat het Unicode Bidirectional Algorithm die correct weergeeft. Zonder die markeringen moet het algoritme raden, en het raadt soms verkeerd op de grens tussen de schriften.

Hoe test je RTL-ondersteuning correct?

Met echte Arabische of Hebreeuwse content in plaats van vultekst, een geforceerde RTL-ronde met pseudo-lokalisatie om lay-outbreuken vroeg te vangen, en minstens één testgeval dat RTL-tekst mengt met Latijnse cijfers of productcodes. We bouwen dit testen in elk meertalig project in; vraag een vaste prijsofferte aan en RTL-ondersteuning wordt vanaf het begin meegenomen.

Bouw het meteen goed

Vertel ons welke schriften en richtingen jouw software moet ondersteunen. We nemen RTL mee vanaf de eerste commit, niet als een reparatie achteraf, en antwoorden met een vaste prijs en een opleverdatum.

Vraag een vaste prijsofferte aan →