Antwoord.

De eerste golf van automatiseringstests had vrijwel geen betrekking op lokalisatie (i18n) controle, aangezien de belangrijkste markten gericht waren op een Engelstalige interface. Echter, naarmate applicaties globaliseerden, zijn de eisen voor de kwaliteit van lokalisatie gestegen: de interface moet correct worden weergegeven in alle ondersteunde talen, en tekstuele bronnen en geformatteerde strings moeten correct worden geladen op basis van de geselecteerde localisatie.

Het belangrijkste probleem is dat handmatige controle zeer kostbaar is, terwijl automatische tests moeilijk zijn vanwege de variabiliteit van formaten, context en taal-specifieke kenmerken (bijvoorbeeld van rechts naar links of grammaticale bijzonderheden). Het kan ontbreken aan de vertaling van een fragment, opmaakfouten, of schendingen van de lay-out.

Oplossingen omvatten het werken met testdata voor elke localisatie, het gebruik van snapshot-tests, het vergelijken van UI-elementen met referenties, het implementeren van controlehulpmiddelen op basis van "sleutel-waarde" voor resource-bestanden, geautomatiseerde extractie en vergelijking van strings via API's en regelmatig linten van resource-bestanden.

Belangrijke kenmerken:

Controle van de aanwezigheid en correcte weergave van alle ondersteunde talen.
Vergelijking van referentievertalingen met de huidige weergave in de interface.
Validators voor de lengte en opmaak van teksten om schendingen van de lay-out te voorkomen.

Misleidende vragen.

Is het mogelijk om een universele test te maken die elke localisatie met één script valideert?

Deels ja, maar nuances in talen (gevallen, geslacht, invoerrichting) vereisen vaak handmatige aanpassingen of aanvullende voorwaarden in dergelijke tests. 100% universaliteit is niet mogelijk.

Als het vertaalbestand beschikbaar is en succesvol is geladen, betekent dit dan dat de i18n-test is doorstaan?

Nee. Het bestand kan onjuist zijn gelinkt aan de applicatiezijde, er kan een fout zijn in de sleutel, de context van het gebruik van de vertaling kan zijn geschonden, er kunnen onopgemerkte speciale tekens zijn, enzovoort.

Heeft het zin om lokalisatietests te automatiseren voor talen met < 1% gebruikers?

Ja, als de zakelijke kritikaliteit zelfs voor één gebruiker groot is, bijvoorbeeld bij het voldoen aan contractuele verplichtingen of voor markten met speciale vereisten. Automatisering bespaart aanzienlijk op middelen in vergelijking met handmatige controles.

Typische fouten en anti-patronen

Alleen controleren op de aanwezigheid van het bestand, en niet op de werkelijke weergave in de UI.
Strikte vergelijking van strings zonder rekening te houden met de grammaticale en opmaak bijzonderheden van de taal.
Blind kopiëren van tests van de ene localisatie naar de andere zonder aanpassing.

Voorbeeld uit het leven

Negatieve case

Het team heeft autotests geïmplementeerd om sleutels in het .po-bestand te vergelijken met de oorspronkelijke Engelse tekst, in de veronderstelling dat dit voldoende was. UI-tests werden niet geschreven — in de release van de Arabische versie bleek dat alle tekst buiten de knoppen viel, en sommige zinnen helemaal niet werden vertaald vanwege onjuiste sleutels.

Voordelen:

Snelle implementatie van automatisering voor i18n.

Nadelen:

Laag niveau van dekking van echte gebruikersscenario's.
Aanzienlijke UX-fouten bleven onopgemerkt.

Positieve case

Er is een combinatie van linten van bronnen en autotests gerealiseerd, die de interface door alle talen lieten draaien, screenshots maakten en deze vergeleken met de referent lay-out. Bij het ontdekken van de vermenging van RTL/LTR elementen, vond het team de onderliggende oorzaak en loste deze op voordat de release plaatsvond.