Lokalizace dynamické aplikace, jako je Sprout Social, do více jazyků je složitý úkol. Překlad textu, který se objeví v aplikaci, je jen jedna polovina příběhu. Zahrnuje také vývoj naší aplikace způsobem, který usnadňuje extrahování a výměnu tohoto textu za překlady. Ve společnosti Sprout se při překladech opíráme o dodavatele třetích stran. Stále však potřebujeme nástroje k extrahování, seskupování a odesílání požadavků na překlad těmto dodavatelům a poté k poskytování a vykreslování překladů koncovým uživatelům.



Po celá léta si tým inženýrů Sprout vystačil s řešením vlastní lokalizace, protože řešení s otevřeným zdrojovým kódem stále dozrávala. Umožnilo nám to vyhovět našim největším zákazníkům v podporovaných jazycích, ale postrádalo některé užitečné funkce. V tomto článku nastíním náš nový lokalizační systém, jak se vypořádává s nejsložitějšími lokalizačními scénáři a jak jsme tyto změny postupně zaváděli v rámci organizace webového inženýrství.



Náš starý systém

Chcete-li porozumět našemu novému lokalizačnímu systému, musíte nejprve porozumět tomu, jak náš starý systém fungoval, a oblasti, kde bychom jej mohli vylepšit.

Syntaxe zprávy

Lokalizace aplikace funguje tak, že abstrahuje text, který je viditelný pro koncového uživatele, do řetězcových jednotek, nazývaných zprávy. Tyto zprávy jsou extrahovány a odeslány překladatelům. Abstrahováním těchto řetězců je můžeme snadno zaměnit v závislosti na preferovaném jazyce koncového uživatele.


duchovní číslo 1212

Tyto zprávy mohou být jednoduché statické řetězce jako „Ahoj, světe“, nebo mohou obsahovat zástupné symboly jako „Dobrý den, {jméno}“ nebo formátovaný text jako „Ahoj, světe“. Vzhledem k tomu, že tyto funkce musí být serializovány do řetězců, potřebujete syntaxi, které rozumí překladatelé i kód aplikace, aby správně přeložil a vykreslil text.

Část toho, co znesnadnilo použití našeho starého lokalizačního systému, bylo to, že jsme si vytvořili vlastní syntaxi a udržovali domácí „analyzátor“ pro uvedenou syntaxi. Údržba tohoto kódu byla časově náročná a syntaxe byla docela minimální. Chtěli jsme další funkce, které pomohou vykreslovat složitější zprávy.

Příklad: V aplikaci Sprout potřebujeme způsob vykreslení „Máte X příspěvků“, kde X je dynamická číselná hodnota.



Zvažte pád v množném čísle: „Máte 5 příspěvky “. Zvažte ojedinělý případ: „Máte 1 pošta “. Zvažte případ „0“. Zvažte jazyky, které mohou mít gramatiku pro případ „1“, jako je čínština a japonština. Zvažte jazyky, které mají gramatiku pro případ, kdy X je „velké číslo“, jako je arabština, polština a ruština.

Správa zpráv

Máme zprávy, které můžeme poslat překladatelům a vyměnit je v naší aplikaci. Naše aplikace potřebuje způsob ukládání těchto zpráv a jejich poskytování našim koncovým uživatelům.

Náš starý systém ukládal všechny naše zprávy do souborů JSON (nazývali jsme „soubory lang“), které byly spravovány ručně. Na zprávy v těchto souborech jsme odkazovali pomocí ID v našem zdrojovém kódu javascript. Když uživatel chtěl aplikaci ve španělštině, poskytli bychom naše soubory ve španělštině a potom by javascript vykreslil odpovídající španělskou zprávu pomocí ID.



Z důvodů výkonu jsme se pokusili obsluhovat pouze uživatelské zprávy, které byly na této stránce, takže jsme měli samostatné jazykové soubory pro různé stránky aplikace. Toto byl platný systém, ale jak se náš tým a aplikace škálovaly, znamenalo to pro vývojáře více manuálního času při vytváření a správě těchto ID a souborů lang.


význam 15

  Snímek obrazovky JavaScriptu dříve používaného k ruční správě zpráv a překladu ve Sprout's codebase.

Chcete-li do aplikace přidat novou zprávu, museli ji vývojáři ručně přidat do správného jazykového souboru s jedinečným ID, aby na ni odkazovali. Občas jsme narazili na problémy s kolizemi ID a překlepy v ID, které vedly k chybějícímu jazyku v aplikaci. Přidávání textu do webové aplikace bylo zdlouhavé s mnoha kroky, které nebyly intuitivní.

Naše nové řešení

S vědomím těchto nedostatků vytvořili weboví inženýři z celé produktové organizace pracovní skupinu pro lokalizaci, aby vyvinula řešení. Pravidelně jsme se scházeli k brainstormingu. Po procesu hloubkového výzkumu jsme se rozhodli migrovat aplikaci Sprout z našeho domácího lokalizačního systému na FormatJS. reagovat-intl knihovnu a vybudovat kolem ní infrastrukturu pro správu našich zpráv. React-intl byla nejbohatší a nejoblíbenější open source lokalizační knihovna v ekosystému javascript a dobře integrovaná do naší kódové základny.

Syntaxe zprávy

Chtěli jsme robustnější řešení a nechtěli jsme vytvářet něco od začátku. Přijali jsme Syntaxe zprávy ICU , standardizovaná syntaxe, která se používá v aplikacích Java, PHP a C a zachycuje složitost zpráv dynamických aplikací. The reagovat-intl knihovna také podporuje analýzu a vykreslování zpráv syntaxe ICU.

  Příklad vedle sebe, jak syntaxe zprávy ICU zachycuje množné číslo. Vlevo je zpráva v angličtině, než bude přeložena do ruštiny. Vpravo je zpráva přeložená do ruštiny. Všimněte si, že když překladatelé převedou tuto zprávu do jiných jazyků, mohou podle potřeby přidávat a odebírat případy, aby správně podporovali daný jazyk. Ruský překlad této zprávy přidává „málo“ a „mnoho“ případů.

Toto je příklad toho, jak syntaxe zprávy ICU zachycuje množné číslo. Toto je zpráva v angličtině a ruštině. Všimněte si, že když překladatelé převedou tuto zprávu do jiných jazyků, mohou podle potřeby přidávat a odebírat případy, aby správně podporovali daný jazyk. Ruský překlad této zprávy přidává „málo“ a „mnoho“ případů.

Syntaxe zpráv ICU byla testována mnoha aplikacemi v bezpočtu jazyků. Mohli jsme se spolehnout, že dokáže podpořit naše sofistikované potřeby zákazníků a že existuje mnoho řešení a/nebo vzdělávacích zdrojů pro jakékoli otázky týkající se lokalizace, na které jsme narazili.

Správa zpráv

Vyvinuli jsme systém využívající nástroje od FormatJS, které by automatizovaly proces přidávání, odebírání a ukládání zpráv. To zahrnovalo některé filozofické změny v tom, jak jsme přistupovali k ukládání zpráv a odkazování.


číslo znamená 111

Hlavní změnou od našeho starého systému, kterou FormatJS podporuje, bylo použití našeho kódu uživatelského rozhraní jako zdroje pravdy pro zprávy. V našem předchozím systému byly zdroje zpráv a použití zpráv na dvou různých místech, což znamenalo, že jsme je museli synchronizovat. Náš nový systém uchovává zdroje zpráv se zbytkem kódu uživatelského rozhraní. Potřebujeme jednoduše spustit skript, který bude extrahovat všechny zprávy ze souborů uživatelského rozhraní, abychom vygenerovali naše jazykové soubory, a obsah zprávy se pomocí hashovací funkce stane jedinečnými ID.

  Snímek obrazovky JavaScriptu dříve používaného k automatické správě zpráv a překladu ve Sprout's codebase.

Tato změna umístí zprávy do kódu uživatelského rozhraní a měla několik výhod:

  • Čtivější: Už žádná ID, která jsou navržena pro roboty v našem kódu uživatelského rozhraní. Nyní můžeme číst anglické zprávy v kódu uživatelského rozhraní a pochopit, jaký text uživatel uvidí.
  • Nemanuální ID: Tato ID, která byla používána pouze stroji, jsou nyní generována stroji a podle definice jsou jedinečná pro každou zprávu.
  • Žádné ručně spravované jazykové soubory: Vývojáři by se těchto jazykových souborů neměli dotýkat. Naše skripty řídí přidávání a mazání zpráv.

Jak jsme se stěhovali?

Ale jak jsme do tohoto nového systému migrovali celý náš tým webových inženýrů a kódovou základnu? Rozdělili jsme to do čtyř milníků: pilotování nového systému, vzdělávání našeho týmu, zavržení starého systému a migrace na naše nové řešení.

Pilotování nového systému

Pracovní skupina testovala nový systém ve specifických částech aplikace, aby získala představu o jeho osvědčených postupech a plném rozsahu migrace. Díky tomu byl nový systém nastaven na straně klienta (poly-filly atd.) a na straně sestavení aplikace. To nám umožnilo opakovat vývojářské zkušenosti a zmírnit riziko.

Vzdělání

Vzali jsme to, co jsme se naučili z pilotního projektu, a použili jsme to ke vzdělávání celého týmu webových inženýrů. Vyvinuli jsme FAQ a další vzdělávací dokumentaci a prezentace, abychom pomohli vývojářům používat novou knihovnu. Je snadné tento krok podcenit, ale tato část migrace je nesmírně důležitá. Nezáleží na tom, jak dobrý je váš nový systém – lidé potřebují vědět, jak a proč by ho měli používat.

Vyvinuli jsme také ambasadorský program, kde každý tým webových funkcí ve Sprout měl jmenovaného lokalizačního ambasadora, který byl zodpovědný za pomoc při vzdělávání jejich týmu o novém systému a hlášení problémů nebo bolestivých bodů pracovní skupině.

To nám umožnilo delegovat odpovědnost za vzdělávání a identifikovat problémy specifické pro jednotlivé týmy.

Zavržení starého systému

Poté, co jsme si byli jisti vývojářskými zkušenostmi, sdílenými znalostmi a škálovatelným potenciálem nového systému, starý systém jsme zavrhli. Vytvořili jsme některá vlastní pravidla eslint a použili jsme nástroj na linting, esplint , zablokovat používání starého systému a zároveň povolit stávající použití. Od této chvíle se od webových inženýrů očekávalo, že budou nový systém používat při psaní nového kódu.

Migrace na náš nový systém

S důvěrou v náš nový systém a pevným počtem starých použití jsme začali s migrací.

Mnoho použití mělo v novém systému ekvivalenty jedna ku jedné. Tam, kde tyto ekvivalenty existují, jsme byli schopni automatizovat migraci napsáním kódového modu pomocí jscodeshift . Byli jsme schopni iterativně spouštět kódový mod po částech kódové základny, učit se a opravovat problémy za pochodu. Zůstalo jen málo okrajových případů, které nebylo možné snadno kódově modifikovat, takže jsme se cítili pohodlně při jejich ruční opravě.


557 andělské číslo

Zavedení

Proč jsme se rozhodli pro takový iterativní přístup, místo abychom se snažili migrovat vše najednou? Používání iterativního přístupu je součástí kultury společnosti Sprout Engineering a věříme v neustálé učení a zlepšování.

Tím, že jsme k migraci přistupovali tímto způsobem, jsme se mohli učit za pochodu, upravovat a opravovat problémy v reálném čase. Mohli bychom také vrátit změny, pokud by migrace začala blokovat vývoj aplikací. Náš iterativní přístup nám umožnil pokročit při práci na jiných iniciativách a umožnil nám označit hlavní změny v menší skupině, než je zpřístupníme všem. Stejné principy vývoje funkcí pro aplikaci platí pro vývoj interních vývojářských nástrojů.

Učení a věci s sebou

Přepracování našeho lokalizačního systému bylo obrovským počinem napříč celou organizací webového inženýrství. Moje rada pro ostatní, kteří čelí podobným projektům nebo výzvám, by byla:

  • Používejte široce přijímané standardy: Proč vytvářet vlastní syntaxi zpráv, když inženýři, kteří strávili roky přemýšlením o tomto problémovém prostoru, již vyvinuli syntaxi zpráv ICU?
  • Zvažte umístění souvisejících položek: Jejich přidávání, změna a mazání bude mnohem jednodušší.
  • Přijměte iterativní zavádění: Navrhněte zavádění své změny způsobem, který vám umožní učit se za pochodu. Nemůžete předvídat všechno, takže si ve svém plánu zapracujte prostor pro využití.
  • Podělte se o své poznatky: Vzdělávání je polovina zavedení. Nezáleží na tom, jak dobrý je váš nový systém, pokud lidé nevědí, jak jej používat nebo proč je lepší.

Další informace o kultuře inženýrství společnosti Sprout najdete na naší stránce kariérní stránka dnes.

Sdílej Se Svými Přáteli: