Lost in translation: Upleveling van het lokalisatiesysteem van Sprout Social

Het lokaliseren van een dynamische applicatie zoals Sprout Social in meerdere talen is een complexe onderneming. Het vertalen van de tekst die in de applicatie verschijnt, is slechts de helft van het verhaal. Het omvat ook het ontwikkelen van onze applicatie op een manier die het gemakkelijk maakt om die tekst te extraheren en uit te wisselen voor de vertalingen. Bij Sprout vertrouwen we op externe leveranciers voor vertalingen. Maar we hebben nog steeds tools nodig om vertaalverzoeken te extraheren, te bundelen en in te dienen bij die leveranciers en vervolgens de vertalingen aan eindgebruikers te leveren en weer te geven.

Het technische team van Sprout kon jarenlang rondkomen met een op maat gemaakte lokalisatieoplossing, aangezien open source-oplossingen nog in ontwikkeling waren. Het stelde ons in staat om onze grootste klanten in onze ondersteunde talen te bedienen, maar miste een aantal handige functies. In dit artikel zal ik ons ​​nieuwe lokalisatiesysteem schetsen, hoe het de meest gecompliceerde lokalisatiescenario's aanpakt en hoe we die veranderingen stapsgewijs hebben ingevoerd in de webengineeringorganisatie.

Ons oude systeem

Om ons nieuwe lokalisatiesysteem te begrijpen, moet u eerst begrijpen hoe ons oude systeem werkte en op welke gebieden we het zouden kunnen verbeteren.

Bericht syntaxis

Toepassingslokalisatie werkt door de tekst die zichtbaar is voor de eindgebruiker te abstraheren in tekenreekseenheden, berichten genoemd. Deze berichten worden geëxtraheerd en voorgelegd aan vertalers. Door deze strings te abstraheren, kunnen we ze eenvoudig verwisselen, afhankelijk van de voorkeurstaal van de eindgebruiker.

Deze berichten kunnen eenvoudige statische tekenreeksen zijn, zoals 'Hallo, wereld' of tijdelijke aanduidingen hebben, zoals 'Hallo, {naam}' of rich text-opmaak, zoals 'Hallo, wereld'. Aangezien deze functies moeten worden geserialiseerd in tekenreeksen, hebt u een syntaxis nodig die zowel de vertalers als de toepassingscode begrijpen om de tekst correct te vertalen en weer te geven.

Een deel van wat ons oude lokalisatiesysteem moeilijk te gebruiken maakte, was dat we onze eigen syntaxis bedachten en een zelfgemaakte 'parser' voor die syntaxis onderhouden. Deze code was tijdrovend om te onderhouden en de syntaxis was vrij minimaal. We wilden extra functies om complexere berichten weer te geven.

Voorbeeld: in de Sprout-toepassing hebben we een manier nodig om 'Je hebt X berichten' weer te geven, waarbij X een dynamische numerieke waarde is.

Overweeg het meervoud: 'Je hebt 5 posten ”. Beschouw het enkelvoudige geval: 'Je hebt 1 na ”. Beschouw het '0' geval. Overweeg talen die een grammatica kunnen hebben voor hoofdlettergebruik '1', zoals Chinees en Japans. Overweeg talen die een grammatica hebben voor het geval waarin X een 'groot getal' is, zoals Arabisch, Pools en Russisch.

Beheer van berichten

We hebben berichten die we naar vertalers kunnen sturen en in onze applicatie kunnen uitwisselen. Onze applicatie heeft een manier nodig om deze berichten op te slaan en aan onze eindgebruikers te leveren.

Ons oude systeem bewaarde al onze berichten in JSON-bestanden (we noemden 'lang-bestanden'), die handmatig werden beheerd. We hebben naar de berichten in deze bestanden verwezen door ID's te gebruiken in onze javascript-broncode. Wanneer een gebruiker de applicatie in het Spaans wilde, zouden we onze Spaanse taalbestanden aanbieden en vervolgens zou het javascript het overeenkomstige Spaanse bericht weergeven met behulp van de ID.

Om prestatieredenen probeerden we alleen de gebruikersberichten op die pagina weer te geven, dus hadden we aparte lang-bestanden voor de verschillende pagina's van de applicatie. Dit was een geldig systeem, maar naarmate ons team en onze applicatie groter werden, betekende dit dat er meer tijd voor handmatige ontwikkelaars nodig was om deze ID's en langbestanden te maken en te beheren.

Om een ​​nieuw bericht aan de applicatie toe te voegen, moesten ontwikkelaars deze handmatig toevoegen aan het juiste lang-bestand met een uniek ID om naar dat bericht te verwijzen. Soms kwamen we problemen tegen met ID-botsingen en ID-typefouten, wat leidde tot het ontbreken van lang in de applicatie. Het toevoegen van tekst aan de webapplicatie voelde vervelend met talloze stappen die niet intuïtief waren.

Onze nieuwe oplossing

Omdat ze deze tekortkomingen kenden, hebben webengineers uit de hele productorganisatie een lokalisatiewerkgroep opgericht om een ​​oplossing te ontwikkelen. We kwamen regelmatig bij elkaar om te brainstormen. Na een diepgaand onderzoeksproces hebben we besloten om de Sprout-applicatie te migreren van ons zelfgemaakte lokalisatiesysteem om FormatJS's te gebruiken reageren-intl bibliotheek en bouw er een infrastructuur omheen voor het beheer van onze berichten. React-intl was de meest feature-rijke en populaire open source-lokalisatiebibliotheek in het javascript-ecosysteem en goed geïntegreerd in onze codebase.

Bericht syntaxis

We wilden een robuustere oplossing en wilden niet iets helemaal opnieuw creëren. Wij hebben de Syntaxis van ICU-berichten , een gestandaardiseerde syntaxis die wordt gebruikt in Java-, PHP- en C-toepassingen en die de complexiteit van dynamische toepassingsberichten vastlegt. De reageren-intl bibliotheek ondersteunt ook het ontleden en weergeven van ICU-berichtensyntaxisberichten.

Dit is een voorbeeld van hoe ICU-berichtensyntaxis meerdere gevallen vastlegt. Dit is het bericht in het Engels en Russisch. Merk op hoe wanneer de vertalers dit bericht in andere talen omzetten, ze hoofdletters en kleine letters kunnen toevoegen en verwijderen als dat nodig is om de taal goed te ondersteunen. De Russische vertaling van dit bericht voegt 'weinig' en 'veel' gevallen toe.

De ICU-berichtensyntaxis is getest door veel toepassingen in talloze talen. We konden erop vertrouwen dat het onze geavanceerde klantbehoeften kon ondersteunen en dat er veel oplossingen en/of leermiddelen waren voor alle lokalisatievragen die we tegenkwamen.

Beheer van berichten

We hebben een systeem ontwikkeld met behulp van tooling van FormatJS dat het proces van het toevoegen, verwijderen en opslaan van berichten zou automatiseren. Dit bracht enkele filosofische veranderingen met zich mee in de manier waarop we het opslaan van berichten en het verwijzen naar berichten benaderden.

Een grote verandering ten opzichte van ons oude systeem die door FormatJS wordt aangemoedigd, was het gebruik van onze UI-code als bron van waarheid voor berichten. In ons vorige systeem bevonden de bron van de berichten en het gebruik van de berichten zich op twee verschillende plaatsen, wat betekende dat we ze gesynchroniseerd moesten houden. Ons nieuwe systeem houdt de berichtbronnen bij de rest van de UI-code. We hoeven alleen maar een script uit te voeren dat alle berichten uit de UI-bestanden haalt om onze lang-bestanden te genereren, en de inhoud van het bericht wordt de unieke ID's met behulp van een hash-functie.

Deze wijziging plaatst de berichten bij de UI-code en heeft verschillende voordelen:

• Beter leesbaar: Geen ID's meer die zijn ontworpen voor robots in onze UI-code. Nu kunnen we de Engelse berichten in de UI-code lezen en begrijpen welke tekst de gebruiker te zien krijgt.
• Niet-handmatige ID's: Deze ID's die alleen door machines werden gebruikt, worden nu door machines gegenereerd en zijn per definitie uniek per bericht.
• Geen handmatig beheerde langbestanden: Ontwikkelaars zouden deze langbestanden niet hoeven aan te raken. Onze scripts beheren het toevoegen en verwijderen van de berichten.

Hoe zijn we gemigreerd?

Maar hoe hebben we ons hele webengineeringteam en onze codebase naar dit nieuwe systeem gemigreerd? We hebben dit opgesplitst in vier mijlpalen: het testen van het nieuwe systeem, het opleiden van ons team, het afschaffen van het oude systeem en de migratie naar onze nieuwe oplossing.

---

de 845 snapchat betekenis

---

Piloten van het nieuwe systeem

De werkgroep testte het nieuwe systeem in specifieke delen van de applicatie om een ​​idee te krijgen van de best practices en het volledige migratiebereik. Hierdoor werd het nieuwe systeem opgezet aan de clientzijde (polyfills, enz.) en aan de bouwzijde van de applicatie. Dit stelde ons in staat om de ontwikkelaarservaring te herhalen en risico's te beperken.

Onderwijs

We hebben wat we van de pilot hebben geleerd, gebruikt om het hele webengineeringteam op te leiden. We hebben een FAQ en andere educatieve documentatie en presentaties ontwikkeld om ontwikkelaars te helpen bij het gebruik van de nieuwe bibliotheek. Het is gemakkelijk om deze stap te onderschatten, maar dit deel van een migratie is buitengewoon belangrijk. Het maakt niet uit hoe goed je nieuwe systeem is, mensen moeten weten hoe en waarom ze het moeten gebruiken.

We hebben ook een ambassadeursprogramma ontwikkeld waarbij elk webfunctieteam bij Sprout een aangestelde lokalisatieambassadeur had, die verantwoordelijk was voor het onderwijzen van hun team over het nieuwe systeem en het rapporteren van problemen of knelpunten aan de werkgroep.

Hierdoor konden we de onderwijsverantwoordelijkheden delegeren en problemen identificeren die specifiek zijn voor individuele teams.

Afschaffen van het oude systeem

Nadat we vertrouwen hadden in de ontwikkelaarservaring, de gedeelde kennis en het schaalpotentieel van het nieuwe systeem, hebben we het oude systeem afgeschaft. We hebben enkele aangepaste eslint-regels gemaakt en de linting-tool gebruikt, spant , om het gebruik van het oude systeem te blokkeren terwijl bestaand gebruik wordt toegestaan. Vanaf dat moment werd van webengineers verwacht dat ze het nieuwe systeem gebruikten bij het schrijven van nieuwe code.

Migreren naar ons nieuwe systeem

Met vertrouwen in ons nieuwe systeem en een vast aantal oude verbruiken zijn we gaan migreren.

Veel toepassingen hadden een-op-een-equivalenten in het nieuwe systeem. Waar deze equivalenten bestaan, konden we de migratie automatiseren door een code-mod te schrijven met behulp van jscodeshift . We waren in staat om de code-mod iteratief uit te voeren over secties van de codebase, terwijl we problemen leerden en oplossen. Er waren nog maar weinig randgevallen over die niet gemakkelijk konden worden gecodeerd, zodat we ons comfortabel voelden om ze handmatig te repareren.

Uitrollen

Waarom hebben we gekozen voor zo'n iteratieve aanpak in plaats van alles in één keer te migreren? Het gebruik van een iteratieve aanpak maakt deel uit van de engineeringcultuur van Sprout en we geloven in voortdurend leren en verbeteren.

Door de migratie op deze manier te benaderen, konden we gaandeweg leren en problemen in realtime aanpassen en oplossen. We kunnen de wijzigingen ook ongedaan maken als de migratie de ontwikkeling van applicaties begint te blokkeren. Dankzij onze iteratieve aanpak konden we vooruitgang boeken terwijl we aan andere initiatieven werkten, en konden we grote veranderingen met een kleinere groep markeren voordat we het voor iedereen uitrolden. Dezelfde principes van feature-ontwikkeling voor een applicatie zijn van toepassing op de ontwikkeling van interne ontwikkelaarstools.

Lessen en afhaalmaaltijden

Het opnieuw uitvinden van ons lokalisatiesysteem was een enorme onderneming voor de hele webengineeringorganisatie. Mijn advies aan anderen die met soortgelijke projecten of uitdagingen worden geconfronteerd, zou zijn:

• Gebruik algemeen aanvaarde normen: Waarom zou u een aangepaste berichtensyntaxis maken als ingenieurs die jarenlang over deze probleemruimte hebben nagedacht, al ICU-berichtensyntaxis hebben ontwikkeld?
• Overweeg om gerelateerde items te verzamelen: Het maakt het veel gemakkelijker om ze toe te voegen, te wijzigen en te verwijderen.
• Omarm een ​​iteratieve uitrol: Ontwerp de uitrol van uw verandering op een manier die u in staat stelt om gaandeweg te leren. Je kunt niet op alles anticiperen, dus bouw ruimte in voor verhaal in je plan.
• Deel uw lessen: Onderwijs is de helft van een uitrol. Het maakt niet uit hoe goed je nieuwe systeem is als mensen niet weten hoe ze het moeten gebruiken of waarom het beter is.

Voor meer informatie over de ingenieurscultuur van Sprout, bekijk onze carrière pagina Vandaag.

Deel Het Met Je Vrienden: