Hoe JEX Backoffice in drie weken meertalig werd - A job well done

Kun je in het kort omschrijven wat jouw werkzaamheden zijn?
Als Full-Stack Developer ben ik voornamelijk bezig met code schrijven. Dat zijn stukken code voor front- en back-end, nieuwe functies, het oplossen van systeemfouten of het aanpassen van de database bijvoorbeeld. Daarnaast denk ik mee over hoe nieuwe eigenschappen van programma’s geïmplementeerd kunnen worden, hoe breed dat is en wat daarbij komt kijken. Daar lever ik input voor.

Ook denk ik na over of bepaalde aanpassingen wel echt nuttig zijn. Dat is niet mijn hoofdtaak, maar als we een systeem aan het rechttrekken zijn en ik of een andere Developer zegt “dit of dat is niet handig”, dan wordt er wel opnieuw nagedacht over hoe iets moet gebeuren.

Front-end en back-end… wat is dat precies?
Front-end is wat voorop het scherm gebeurt, dus wat je ziet. Alles wat je daar ziet is verbonden aan data die uitkomen bij de back-end. Back-end is dus de verbinding met de database áchter de schermen. De back-end van JEX staat in verbinding met AFAS. Hier wordt onder andere de authenticatie van gegevens van cliënten geregeld. Bijvoorbeeld met de AFAS pocket-app: tijdens het inloggen komt data binnen via de back-end (achterkant), maar de front-end (voorkant) laat alles wat ingevoerd wordt en wat opgeslagen is zien.  

Als je front-end code schrijft zie je dus meteen op het scherm wat jouw aanpassingen zijn. Als je iets heel simpels doet, bijvoorbeeld een knop toevoegen, zie je meteen de kleur of de hoeken van die knop. Dat vind ik ook het leukst, want bij de back-end zie je dat juist helemaal niet. Dan zie je alleen de code voor de functionaliteit van de knop. Je ziet dan dus wel iets in de database erbij komen of verdwijnen, maar je ziet niet wat de gebruiker ziet. 

En hoe ging dat dan bij het meertalig maken van de website?
Zo’n drie á vier weken geleden kwam het ter sprake, maar daarvoor was het meertalig maken van de website al een wens. Toen hebben we het idee uitgewerkt en verfijnd tijdens een zogenaamde “refinement sessie”. We hebben besproken wat er zo’n beetje bij zou komen kijken en elk idee een cijfer gegeven voor de moeilijkheidsgraad. We gaven het een vijf als team, maar ik vond dat de moeilijkheid wel een acht was. Toen hebben we het voor de volgende sprint ingepland.  

Een vijf! Dat is niet super hoog, toch?  
We hebben een standaardscore van minimaal 3 punten voor het developen van een nieuwe eigenschap. Dus een 5 is iets moeilijker. Ik dacht dat het 8 zou worden, dus een stuk moeilijker. En ik denk dat 8 wel een goede inschatting was, want we becijferen in principe op complexiteit. Een 5 is dus wel haalbaar, maar als je de tijd meerekent is het eigenlijk wel meer dan 5.

Als ik de code heb geschreven voor de nieuwe eigenschap wordt die in een PR (Pull Request) gezet. Mijn collega’s moeten die code daar controleren. Dan kunnen ze precies zien welke code ik heb aangepast en verwijderd. En daarin waren er meer dan 200 files aangepast, dus het schrijven was heel veel werk, maar zij moesten dus ook heel veel controleren.  

Zou het makkelijker geweest zijn als je aan het begin de website al in het Nederlands en Engels gemaakt had?
Ja het zou wel iets makkelijker zijn, maar het maakt ook niet zoveel uit. Alle tijd die ik er nu in heb gestopt zou je dan ook gebruiken, misschien iets minder. Nu was het vooral veel werk, omdat we al een hele applicatie hadden. Die moesten we in een keer helemaal meertalig maken. Als ik nu een Pull Request van een collega voorbij zie komen die minder bekend is met de implementatie hiervan, controleer ik extra goed of de vertaling goed gedaan is. Maar dat gaat tot nu toe zeker goed. 

En stel het moest in het Pools. Zou het dan wel moeilijker zijn?
Nee, met de letterlijke tekst heb je eigenlijk helemaal niks te maken. Je moet één keer een script runnen, maar dat bestaat nu dus al. In het geval van de wens voor een Poolse vertaling krijg je een bestand voor de Poolse vertalingen: de code “pl.json”. Die stuur je naar het vertaalbureau, die krijg je vertaald terug en stop je weer in het systeem. Het vertalen gebeurt dus automatisch nu.  

Stel een woord is toch niet helemaal goed vertaald, is dat dan ook makkelijk om te veranderen?  
Ja, want in onze code wordt per woord of zin verwezen naar dezelfde ‘key’, dezelfde basis. Je hoeft in de code dus niks aan te passen, maar alleen in de vertaalbestanden (“en.json” naar “pl.json”) en dan wordt alles automatisch veranderd. Behalve als het gaat om dynamische keys of dynamische data. Wat ga je de gebruiker laten zien als je niet weet wat voor data je binnenkrijgt? Daar zijn vaak wel mooie, technische en soms complexe oplossingen voor.

Het doel was ook om te zorgen dat het makkelijk is om nieuwe talen toe te voegen. We gaan namelijk ook accounts maken voor zzp’ers en ET-medewerkers, dat kunnen dus inderdaad medewerkers uit Polen zijn. Als zij in de toekomst een account krijgen, moet de website natuurlijk ook in het Pools vertaald kunnen worden.  

Zijn er ook plannen voor andere talen? 
Voorlopig nog niet. Tenminste, niet dat ik weet. Misschien kan deze functie ook ooit voor JEX.nl komen. Als dat zo is dan gaan ze het waarschijnlijk op dezelfde manier doen. Dat is aan de ene kant gewoon repetitief werk wat best saai is, maar juist de moeilijkere dingen zijn heel leuk vind ik. Áls JEX.nl uiteindelijk ook meertalig wordt, word ik daar waarschijnlijk ook weer in betrokken. En dat is in zijn geheel heel mooi, vooral omdat ik Junior Software Developer ben. Dat is typisch JEX.