This article is only available in Dutch 🇳🇱
Van machine learning in apps en mobiele gateways tot de Metaverse: onze Technisch Strateeg Ennio heeft door de jaren heen als spreker al veel onderwerpen behandeld op Appdevcon. Vorige week was hij, samen met zo’n dertig Move-collega’s, weer aanwezig op het event, dat bekendstaat als grootste mobile-conferentie van West-Europa. Om te consumeren, maar ook om te inspireren. Dit jaar ging zijn talk over meertaligheid in apps. In dit artikel lees je zijn drie belangrijkste takeaways - gericht op de hele breedte van het diverse Appdevcon-publiek.
Voor we de diepte induiken: waarom dit onderwerp?
‘Regelmatig leveren klanten Excelsheets met appteksten aan. Dat vraagt om veel kopiëren en plakken. Naast foutgevoelig is deze werkwijze onoverzichtelijk, omdat je zo geen duidelijke versiegeschiedenis bijhoudt. Ook kan een minimale tekstuele wijziging een gigantische impact hebben op appdesigns en de UI. Iedere Developer krijgt hier in zijn carrière vroeg of laat mee te maken. Maar gelukkig zijn er veel dingen die je kan doen om het jezelf makkelijker te maken!’
Takeaway #1: Begin direct met nadenken over meertaligheid
‘Bij de opzet van een project loont het om rekening te houden met het feit dat je in de toekomst mogelijk met meertaligheid gaat werken. Of het nou voor iOS, Android of Flutter is, maak het project klaar om er meerdere talen in te hangen. Dat levert je later heel veel winst op. Doe je dat niet, dan moet je over twee jaar waarschijnlijk een groot deel van je huidige code weggooien en opnieuw bouwen. Veel startende Developers zetten appteksten ‘hard’ in de code, op de volgende manier: ‘label.text = “xxx”’. In de ideale situatie werk je met localization files: tekstbestanden waar alle appteksten in verzameld zijn. Die teksten hebben elk hun eigen property of key. Neem een About-pagina. In plaats van “label.text = “Over deze app””, wil je daar de property aboutpage.title hebben staan. Op die manier is alle apptekst veel makkelijker te traceren, wat een toekomstig vertaalproces enorm versnelt.’
Takeaway #2: Houd rekening met de UX & UI
‘Dit punt is enerzijds heel praktisch. Zo zijn sommige woorden of zinnen in verschillende talen veel langer of korter. Daar wil je rekening mee houden als je bijvoorbeeld buttons maakt. Door dit soort items dynamisch te bouwen en te zorgen dat ze meeschalen, maak je ze bruikbaar voor zowel één als drie regels tekst. Nauw samenwerken met Designers in jouw eigen ontwikkeltool helpt hier ook enorm bij. Zo kunnen beide partijen snel zien wat er gebeurt als je wijzigingen doorvoert. Ik ben groot voorstander van de dynamische auto-layout. Een competentie die een ontwikkelaar wel in de vingers moet hebben om dat goed op te zetten.
Het kan ook zijn dat de apptekst zélf dynamisch is. Denk bijvoorbeeld aan vertalingen van geldbedragen waarbij de valuta verandert. Zo’n vertaald bedrag staat niet klaar in een tekstbestand, omdat het aan koersen en calculaties onderhevig is. Die data moet dus op het moment zelf worden opgehaald uit een backendsysteem. Zo’n item krijgt een variabele binnen een key, dat noemen we formatteren. Vervolgens moet je ook rekening houden met de loading states die de gebruiker te zien krijgt in dit geval. Ga je het nog niet berekende bedrag verbergen? Of zet je een prijs neer in de wetenschap dat die binnen twee seconden mogelijk verandert? Vanuit de UI kies je vaak voor de mooiere oplossingen. Bijvoorbeeld door het totaalbedrag nog niet te tonen en een spinner neer te zetten.
Naast deze praktische aspecten, is er ook een cultureel aspect. Vertalen is geen één-op-één-handeling. Je wilt elk vertaald woord de juiste lading, connotatie en daardoor de juiste beleving meegeven. Afhankelijk van de branche waarin je werkzaam bent, zijn specialistische vertalingen door iemand met vakkennis van belang. Voor Developers iets minder relevant, maar toch belangrijk om rekening mee te houden.’
Take-away #3: Onderzoek het gebruik van tools
‘Tools kunnen, afhankelijk van je situatie, enorm helpen bij het vergemakkelijken van het proces. Je moet goed begrijpen hoe de situatie bij je klant of opdrachtgever eruitziet en wat hij of zij wil. Bij grote e-commerce-apps komt de data waarschijnlijk niet uit een language tool, maar uit een commerce- of productmanagementsysteem. Dan heb je, los van titeltjes en zaken als FAQ’s, te maken met weinig teksten die echt ín de app zitten. Je kunt je afvragen of het optuigen van zo’n tool - met alle kosten van dien - in zo’n geval de moeite waard is.
Loont het wel om met een tool te werken? Dan profiteer je van inzicht in versiebeheer, testpreviews waarbij je van tevoren al kunt zien hoe je vertaling in de app getoond wordt en vooral heel veel gemak. Met tools doe je één keer de implementatie. Je zorgt dat je het binnenhaalt en je moet ervoor zorgen dat de app iets doet om de nieuwe taal op te halen aan de achterkant als je van taal verandert. De klant beheert de tekst en is dan verantwoordelijk voor hoe de teksten eruit zien. Ook kun je met tools in één oogopslag zien of je alle vertalingen hebt gehad en voeg je in no time een nieuwe taal toe. Op het vlak van internationalisering, schaalbaarheid en het verkennen van nieuwe markten is dat natuurlijk ontzettend interessant. Maar begin klein. Zorg dat je set-up met language files zo goed is dat je met tools kan gaan werken. Zo houd je het makkelijk beheerbaar voor jezelf.’
