Informeu -Vos Del Vostre Nombre D'Àngel
Perdut en la traducció: sistema de localització d'Upleveling Sprout Social
Localitzar una aplicació dinàmica com Sprout Social en diversos idiomes és una tasca complexa. Traduir el text que apareix a l'aplicació és només la meitat de la història. També implica desenvolupar la nostra aplicació de manera que sigui fàcil d'extreure i intercanviar aquest text per les traduccions. A Sprout, ens recolzem en proveïdors de tercers per fer traduccions. Però encara necessitem eines per extreure, agrupar i enviar sol·licituds de traducció a aquests proveïdors i després servir i renderitzar les traduccions als usuaris finals.
Durant anys, l'equip d'enginyeria de Sprout es va comportar amb una solució de localització personalitzada, ja que les solucions de codi obert encara estaven madurant. Ens va permetre acollir els nostres clients més grans en els nostres idiomes compatibles, però no tenia algunes funcions útils. En aquest article, descriuré el nostre nou sistema de localització, com aborda els escenaris de localització més complicats i com hem introduït aquests canvis a l'organització d'enginyeria web.
El nostre vell sistema
Per entendre el nostre nou sistema de localització, primer heu d'entendre com funcionava el nostre sistema antic i les àrees on podríem millorar-lo.
Sintaxi del missatge
La localització d'aplicacions funciona abstraint el text que és visible per a l'usuari final en unitats de cadena, anomenades missatges. Aquests missatges s'extreuen i s'envien als traductors. Abstraint aquestes cadenes, podem canviar-les fàcilment en funció de l'idioma preferit de l'usuari final.
Aquests missatges poden ser simples cadenes estàtiques com 'Hola, món' o tenir marcadors de posició com 'Hola, {nom}' o format de text enriquit com 'Hola, món'. Com que aquestes característiques s'han de serialitzar en cadenes, necessiteu una sintaxi que tant els traductors com el codi de l'aplicació entenguin per traduir i representar correctament el text.
Una part del que va fer que el nostre antic sistema de localització fos difícil d'utilitzar va ser que vam crear la nostra pròpia sintaxi i vam mantenir un 'analitzador' casolà per a aquesta sintaxi. El manteniment d'aquest codi va costar molt de temps i la sintaxi era bastant mínima. Volíem funcions addicionals per ajudar a representar missatges més complexos.
Exemple: a l'aplicació Sprout, necessitem una manera de representar 'Tens X publicacions' on X és un valor numèric dinàmic.
Considereu el cas plural, 'Teniu 5 publicacions ”. Considereu el cas singular, 'Teniu 1 publicació ”. Considereu el cas '0'. Penseu en idiomes que poden tenir una gramàtica per al cas '1', com el xinès i el japonès. Penseu en idiomes que tenen una gramàtica per al cas quan X és un 'número gran' com l'àrab, el polonès i el rus.
Gestió de missatges
Tenim missatges que podem enviar als traductors i canviar-los a la nostra aplicació. La nostra aplicació necessita una manera d'emmagatzemar aquests missatges i servir-los als nostres usuaris finals.
El nostre sistema antic emmagatzemava tots els nostres missatges en fitxers JSON (els anomenem 'fitxers de llenguatge'), que es gestionaven manualment. Hem fet referència als missatges d'aquests fitxers utilitzant identificadors al nostre codi font javascript. Quan un usuari volgués l'aplicació en espanyol, serviríem els nostres fitxers en llengua espanyola i, a continuació, el javascript mostrava el missatge espanyol corresponent mitjançant l'ID.
Per motius de rendiment, vam intentar servir només els missatges d'usuari que hi havia a aquesta pàgina, de manera que teníem fitxers lang separats per a les diferents pàgines de l'aplicació. Aquest era un sistema vàlid, però a mesura que el nostre equip i aplicació s'escalava, va suposar més temps per als desenvolupadors manuals per crear i gestionar aquests identificadors i fitxers lang.
Per afegir un missatge nou a l'aplicació, els desenvolupadors havien d'afegir-los manualment al fitxer lang correcte amb un identificador únic per fer referència a aquest missatge. De vegades, ens trobaríem amb problemes de col·lisions d'identificació i errors tipogràfics d'identificació que provocaven la falta de llenguatge a l'aplicació. Afegir text a l'aplicació web va resultar tediós amb nombrosos passos que no eren intuïtius.
La nostra nova solució
Coneixent aquestes deficiències, els enginyers web de tota l'organització del producte van crear un grup de treball de localització per desenvolupar una solució. Ens reunim regularment per fer una pluja d'idees. Després d'un procés de recerca en profunditat, vam decidir migrar l'aplicació Sprout del nostre sistema de localització casolà per utilitzar FormatJS. reaccionar-intl biblioteca i construir una infraestructura al seu voltant per gestionar els nostres missatges. React-intl era la biblioteca de localització de codi obert més popular i rica en funcions de l'ecosistema javascript i s'integrava bé a la nostra base de codi.
Sintaxi del missatge
Volíem una solució més robusta i no volíem crear res des de zero. Vam adoptar el Sintaxi del missatge de la UCI , una sintaxi estandarditzada que s'utilitza a les aplicacions Java, PHP i C, i captura la complexitat dels missatges dinàmics de les aplicacions. El reaccionar-intl La biblioteca també admet l'anàlisi i la representació de missatges de sintaxi de missatges de la UCI.
Aquest és un exemple de com la sintaxi dels missatges de la UCI captura casos plurals. Aquest és el missatge en anglès i rus. Observeu com quan els traductors converteixen aquest missatge a altres idiomes, poden afegir i eliminar casos segons sigui necessari per donar suport a l'idioma correctament. La traducció russa d'aquest missatge afegeix 'pocs' i 'molts' casos.
La sintaxi dels missatges de la UCI ha estat provada per moltes aplicacions en innombrables idiomes. Podríem confiar que podria donar resposta a les necessitats sofisticades dels nostres clients i que hi havia moltes solucions i/o recursos educatius per a qualsevol pregunta de localització que ens trobéssim.
Gestió de missatges
Vam desenvolupar un sistema amb eines proporcionades per FormatJS que automatitzarien el procés d'afegir, eliminar i emmagatzemar missatges. Això va implicar alguns canvis filosòfics en la manera com vam abordar l'emmagatzematge i la referència de missatges.
Un canvi important respecte al nostre sistema antic que FormatJS anima va ser utilitzar el nostre codi d'IU com a font de veritat per als missatges. En el nostre sistema anterior, la font dels missatges i l'ús dels missatges es trobaven en dos llocs diferents, la qual cosa significava que havíem de mantenir-los sincronitzats. El nostre nou sistema manté les fonts de missatges amb la resta del codi de la IU. Simplement hem d'executar un script que extreu tots els missatges dels fitxers de la interfície d'usuari per generar els nostres fitxers lang, i el contingut del missatge es converteix en els ID únics amb l'ajuda d'una funció hash.
Aquest canvi col·loca els missatges amb el codi d'IU i tenia diversos avantatges:
- Més llegible: Ja no hi ha identificacions dissenyades per a robots al nostre codi d'IU. Ara podem llegir els missatges en anglès al codi de la IU i entendre quin text veurà l'usuari.
- No manual IDs: Aquests identificadors que només eren utilitzats per les màquines ara els generen les màquines i, per definició, són únics per missatge.
- No hi ha fitxers d'idioma gestionats manualment: Els desenvolupadors no haurien de tocar aquests fitxers lang. Els nostres scripts gestionen l'addició i la supressió dels missatges.
Com hem migrat?
Però, com hem migrat tot el nostre equip d'enginyeria web i la base de codi a aquest nou sistema? Vam dividir-ho en quatre fites: pilotar el nou sistema, educar el nostre equip, deixar l'antic sistema en desús i migrar a la nostra nova solució.
Pilotant el nou sistema
El grup de treball va pilotar el nou sistema en seccions específiques de l'aplicació per tenir una idea de les seves millors pràctiques i l'abast complet de la migració. Això va fer que el nou sistema s'hagi configurat al costat del client (poly-fills, etc.) i al costat de construcció de l'aplicació. Això ens va permetre repetir l'experiència del desenvolupador i mitigar el risc.
Educació
Vam agafar el que vam aprendre del pilot i el vam utilitzar per educar a tot l'equip d'enginyeria web. Hem desenvolupat una PMF i altra documentació educativa i presentacions per ajudar els desenvolupadors a utilitzar la nova biblioteca. És fàcil infravalorar aquest pas, però aquesta part d'una migració és extremadament important. No importa el bo que sigui el vostre nou sistema: la gent ha de saber com i per què l'ha d'utilitzar.
També vam desenvolupar un programa d'ambaixadors on cada equip de funcions web de Sprout tenia un ambaixador de localització designat, que era responsable d'ajudar a educar el seu equip sobre el nou sistema i d'informar els problemes o els problemes al grup de treball.
Això ens va permetre delegar les responsabilitats educatives i identificar qüestions específiques dels equips individuals.
Obsolet el sistema antic
Després de sentir-nos segurs de l'experiència del desenvolupador, del coneixement compartit i del potencial d'escala del nou sistema, vam deixar el sistema antic. Vam crear unes regles d'eslint personalitzades i vam utilitzar l'eina d'eslint, esplint , per bloquejar l'ús del sistema antic mentre es permeten els usos existents. A partir d'aquest moment, s'esperava que els enginyers web utilitzessin el nou sistema a l'hora d'escriure codi nou.
Migrant al nostre nou sistema
Amb la confiança en el nostre nou sistema i un nombre fix d'usos antics, vam començar a migrar.
Molts usos tenien equivalents un a un en el nou sistema. Quan existeixen aquests equivalents, vam poder automatitzar la migració escrivint un codi-mod utilitzant jscodeshift . Vam poder executar de manera iterativa el codi-mod en seccions de la base de codi, aprenent i solucionant problemes a mesura que anàvem. Hi havia prou pocs casos d'extrem que no es podien modificar fàcilment en codi perquè ens sentim còmodes arreglant-los manualment.
Desenrotllar
Per què vam optar per un enfocament tan iteratiu en lloc d'intentar migrar-ho tot alhora? L'ús d'un enfocament iteratiu forma part de la cultura d'enginyeria de Sprout i creiem en l'aprenentatge i la millora constants.
número que significa 11
En abordar la migració d'aquesta manera, vam poder aprendre a mesura que anàvem, ajustant i solucionant problemes en temps real. També podríem revertir els canvis si la migració comencés a bloquejar el desenvolupament d'aplicacions. El nostre enfocament iteratiu ens va permetre avançar mentre treballàvem en altres iniciatives i ens va permetre marcar canvis importants amb un grup més reduït abans de desplegar-los a tothom. Els mateixos principis de desenvolupament de funcions per a una aplicació s'apliquen al desenvolupament d'eines de desenvolupadors interns.
Aprenentatges i per emportar
Reimaginar el nostre sistema de localització va ser una tasca massiva a tota l'organització d'enginyeria web. El meu consell a altres persones que s'enfronten a projectes o reptes similars seria:
- Utilitzeu estàndards àmpliament adoptats: Per què crear una sintaxi de missatge personalitzada quan els enginyers que han passat anys pensant en aquest espai problemàtic ja han desenvolupat la sintaxi de missatges de la UCI?
- Penseu en col·locar elements relacionats: Farà que afegir-los, canviar-los i suprimir-los sigui molt més fàcil.
- Abraça un llançament iteratiu: Dissenyeu el desplegament del vostre canvi d'una manera que us permeti aprendre a mesura que avanceu. No pots anticipar-ho tot, així que crea un espai per al recurs al teu pla.
- Comparteix els teus aprenentatges: L'educació és la meitat d'un desplegament. No importa el bo que sigui el vostre nou sistema si la gent no sap com utilitzar-lo o per què és millor.
Per obtenir més informació sobre la cultura d'enginyeria de Sprout, consulteu el nostre pàgina de carreres avui.
Comparteix Amb Els Teus Amics:
