Локализацията на динамично приложение като Sprout Social на множество езици е сложно начинание. Преводът на текста, който се появява в приложението, е само половината от историята. Това също включва разработване на нашето приложение по начин, който улеснява извличането и замяната на този текст за преводите. В Sprout разчитаме на доставчици трети страни за преводи. Но все още се нуждаем от инструменти за извличане, групиране и изпращане на заявки за превод до тези доставчици и след това да обслужваме и изобразяваме преводите на крайните потребители.



Години наред инженерният екип на Sprout се справяше с персонализирано решение за локализация, тъй като решенията с отворен код все още се развиваха. Това ни позволи да посрещнем нашите най-големи клиенти на поддържаните от нас езици, но липсваха някои полезни функции. В тази статия ще очертая нашата нова система за локализация, как тя се справя с най-сложните сценарии за локализация и как постепенно въведохме тези промени в организацията за уеб инженеринг.



Нашата стара система

За да разберете нашата нова система за локализация, първо трябва да разберете как работи старата ни система и областите, в които бихме могли да я подобрим.

добър номер

Синтаксис на съобщението

Локализацията на приложението работи чрез абстрахиране на текста, който е видим за крайния потребител, в низови единици, наречени съобщения. Тези съобщения се извличат и предават на преводачите. Като абстрахираме тези низове, можем лесно да ги разменяме в зависимост от предпочитания език на крайния потребител.

Тези съобщения могат да бъдат прости статични низове като „Здравей, свят“ или да имат контейнери като „Здравей, {име}“ или форматиран форматиран текст като „Здравей, свят“. Тъй като тези характеристики трябва да бъдат сериализирани в низове, имате нужда от синтаксис, който както преводачите, така и кодът на приложението разбират, за да преведат правилно и изобразят текста.

Част от това, което направи старата ни система за локализация трудна за използване, беше, че създадохме наш собствен синтаксис и поддържахме домашен „парсер“ за споменатия синтаксис. Този код отнема много време за поддръжка и синтаксисът е доста минимален. Искахме допълнителни функции, които да помогнат за изобразяването на по-сложни съобщения.

Пример: В приложението Sprout се нуждаем от начин за изобразяване на „Имате X публикации“, където X е динамична числова стойност.



Помислете за случая в множествено число „Имате 5 публикации ”. Помислете за единичния случай „Имате 1 пост ”. Помислете за случая „0“. Помислете за езици, които може да имат граматика за случай „1“, като китайски и японски. Помислете за езици, които имат граматика за случая, когато X е „голямо число“, като арабски, полски и руски.

Управление на съобщения

Имаме съобщения, които можем да изпращаме на преводачи и да ги разменяме в нашето приложение. Нашето приложение се нуждае от начин за съхраняване на тези съобщения и обслужването им на нашите крайни потребители.

Нашата стара система съхраняваше всичките ни съобщения в JSON файлове (наричахме „lang файлове“), които се управляваха ръчно. Ние посочихме съобщенията в тези файлове, като използвахме идентификатори в нашия изходен javascript код. Когато потребител искаше приложението на испански, ние обслужвахме нашите испански езикови файлове и след това javascript изобразяваше съответното испанско съобщение, използвайки идентификатора.



От съображения за ефективност се опитахме да обслужваме само потребителските съобщения, които бяха на тази страница, така че имахме отделни lang файлове за различните страници на приложението. Това беше валидна система, но тъй като нашият екип и приложение се мащабираха, това означаваше повече ръчно време на разработчиците за създаване и управление на тези идентификатори и lang файлове.

Екранна снимка на JavaScript, използван преди това за ръчно управление на съобщения и превод в Sprout's codebase.

За да добавят ново съобщение към приложението, разработчиците трябваше ръчно да ги добавят към правилния lang файл с уникален идентификатор, който да препраща към това съобщение. Понякога се сблъскваме с проблеми със сблъсъци на ID и правописни грешки, водещи до липсващ език в приложението. Добавянето на текст към уеб приложението се стори досадно с множество стъпки, които не бяха интуитивни.

Нашето ново решение

Знаейки тези недостатъци, уеб инженерите от цялата продуктова организация създадоха работна група за локализация, за да разработят решение. Срещахме се редовно, за да размишляваме. След задълбочен процес на проучване решихме да мигрираме приложението Sprout от нашата домашна система за локализация, за да използваме FormatJS реагират-вм библиотека и изграждане на инфраструктура около нея за управление на нашите съобщения. React-intl беше най-богатата на функции и популярна библиотека за локализация с отворен код в екосистемата на javascript и интегрирана добре в нашата кодова база.

ангел номер 909 в смисъл

Синтаксис на съобщението

Искахме по-стабилно решение и не искахме да създаваме нещо от нулата. Ние приехме Синтаксис на съобщението на ICU , стандартизиран синтаксис, който се използва в приложения на Java, PHP и C и улавя сложността на съобщенията на динамичните приложения. The реагират-вм библиотеката също така поддържа анализиране и изобразяване на съобщения за синтаксис на ICU съобщения.

Паралелен пример за това как синтаксисът на съобщението на ICU улавя множествени случаи. Отляво е съобщението на английски, преди да бъде преведено на руски. Вдясно е съобщението, преведено на руски. Забележете как, когато преводачите преобразуват това съобщение на други езици, те могат да добавят и премахват малки и големи букви, ако е необходимо, за да поддържат правилно езика. Руският превод на това съобщение добавя „няколко“ и „много“ случаи.

Това е пример за това как синтаксисът на съобщението на ICU улавя множествено число. Това е съобщението на английски и руски. Забележете как, когато преводачите преобразуват това съобщение на други езици, те могат да добавят и премахват малки и големи букви, ако е необходимо, за да поддържат правилно езика. Руският превод на това съобщение добавя „няколко“ и „много“ случаи.

Синтаксисът на съобщенията на ICU е тестван в битка от много приложения на безброй езици. Можем да се доверим, че може да подкрепи нашите сложни нужди на клиентите и че има много решения и/или образователни ресурси за всякакви въпроси относно локализацията, с които се сблъскахме.

Управление на съобщения

Ние разработихме система, използвайки инструменти, предоставени от FormatJS, която ще автоматизира процеса на добавяне, премахване и съхраняване на съобщения. Това включваше някои философски промени в начина, по който подходихме към съхраняването и реферирането на съобщения.

Основна промяна от старата ни система, която FormatJS насърчава, беше използването на нашия UI код като източник на истина за съобщенията. В предишната ни система източникът на съобщенията и използването на съобщенията бяха на две различни места, което означаваше, че трябваше да ги поддържаме синхронизирани. Нашата нова система запазва източниците на съобщения с останалата част от кода на потребителския интерфейс. Просто трябва да изпълним скрипт, който ще извлече всички съобщения от UI файловете, за да генерира нашите lang файлове, и съдържанието на съобщението става уникалните идентификатори с помощта на хеш функция.

Екранна снимка на JavaScript, използван преди това за автоматично управление на съобщения и превод в Sprout's codebase.

Тази промяна локализира съобщенията с кода на потребителския интерфейс и има няколко предимства:

  • По-четливо: Няма повече идентификатори, които са предназначени за роботи в нашия UI код. Сега можем да четем съобщенията на английски в кода на потребителския интерфейс и да разбираме какъв текст ще види потребителят.
  • Неръчни идентификатори: Тези идентификатори, които са били използвани само от машини, сега се генерират от машини и по дефиниция са уникални за всяко съобщение.
  • Няма ръчно управлявани lang файлове: Разработчиците не трябва да пипат тези lang файлове. Нашите скриптове управляват добавянето и изтриването на съобщенията.

Как сме мигрирали?

Но как мигрирахме целия ни уеб инженерен екип и кодова база към тази нова система? Разделихме това на четири основни етапа: пилотиране на новата система, обучение на нашия екип, отказ от старата система и мигриране към нашето ново решение.

Пилотиране на новата система

Работната група пилотира новата система в конкретни раздели на приложението, за да добие представа за нейните най-добри практики и пълния обхват на миграция. Това накара новата система да бъде настроена от страна на клиента (поли-пълнежи и т.н.) и от страната на компилацията на приложението. Това ни позволи да повторим опита на разработчиците и да намалим риска.

1212 значение в любовта

образование

Взехме наученото от пилота и го използвахме, за да обучим целия екип на уеб инженеринга. Разработихме ЧЗВ и друга образователна документация и презентации в помощ на разработчиците, използващи новата библиотека. Лесно е да подцените тази стъпка, но тази част от миграцията е изключително важна. Няма значение колко добра е вашата нова система - хората трябва да знаят как и защо трябва да я използват.

Ние също така разработихме програма за посланици, при която всеки екип за уеб функции в Sprout имаше назначен посланик за локализация, който отговаряше за подпомагането на обучението на техния екип относно новата система и докладването на проблеми или болезнени точки на работната група.

Това ни позволи да делегираме образователните отговорности и да идентифицираме проблеми, специфични за отделните екипи.

Отхвърляне на старата система

След като се почувствахме уверени в опита на разработчиците, споделените знания и потенциала за мащабиране на новата система, отхвърлихме старата система. Създадохме някои персонализирани правила за eslint и използвахме инструмента за linting, шина , за да блокирате използването на старата система, като същевременно позволявате съществуващи употреби. От този момент нататък се очаква уеб инженерите да използват новата система, когато пишат нов код.

Мигриране към нашата нова система

С доверие в нашата нова система и фиксиран брой стари употреби, започнахме мигрирането.

Много употреби имаха еквиваленти едно към едно в новата система. Там, където съществуват тези еквиваленти, ние успяхме да автоматизираме миграцията, като написахме кодова модификация, използвайки jscodeshift . Успяхме итеративно да изпълняваме кодовия мод върху секции от кодовата база, като изучавахме и коригирахме проблемите, докато вървяхме. Имаше достатъчно малко останали крайни случаи, които не можеха лесно да бъдат кодирани, така че се чувствахме комфортно да ги коригираме ръчно.

Разточвам, разстилам

Защо избрахме такъв итеративен подход, вместо да се опитаме да мигрираме всичко наведнъж? Използването на итеративен подход е част от инженерната култура на Sprout и ние вярваме в постоянното учене и подобряване.

Подхождайки към миграцията по този начин, успяхме да се учим в движение, коригирайки и коригирайки проблеми в реално време. Можем също така да отменим промените, ако миграцията започне да блокира разработването на приложения. Нашият итеративен подход ни позволи да постигнем напредък, докато работим по други инициативи, и ни даде възможност да маркираме основни промени с по-малка група, преди да ги разпространим на всички. Същите принципи за разработване на функции за приложение се прилагат и за разработването на вътрешни инструменти за разработчици.

Поуки и изводи

Преосмислянето на нашата система за локализация беше мащабно начинание в цялата организация за уеб инженеринг. Моят съвет към другите, изправени пред подобни проекти или предизвикателства, е да:

  • Използвайте широко разпространени стандарти: Защо да създавате персонализиран синтаксис на съобщение, когато инженери, които са прекарали години в мислене върху това проблемно пространство, вече са разработили синтаксис на ICU съобщение?
  • Помислете за съвместно разполагане на свързани елементи: Това ще направи добавянето, промяната и изтриването им много по-лесно.
  • Прегърнете итеративно внедряване: Проектирайте внедряването на вашата промяна по начин, който ви позволява да се учите, докато вървите. Не можете да предвидите всичко, така че вградете място за прибягване в плана си.
  • Споделете вашето обучение: Образованието е половината от внедряването. Няма значение колко добра е вашата нова система, ако хората не знаят как да я използват или защо е по-добра.

За повече информация относно инженерната култура на Sprout вижте нашата страница за кариери днес.

Споделете С Приятелите Си: