Milestone: l10n
Jun. 9th, 2016 01:49 amЯ впервые сделал локализованное (двуязычное) приложение со всем обвесом на платформе CloudWall + jQuery.my. Типа, майлстоун. Покажу черех месяцок вместе с проектом, который сейчас на приложении делается.
К проблеме я присматривался давно, и всё никак не находилось полностью подходящего решения. Я несколько раз попробовал поприкручивать сторонние, плюнул слюной и нагородил своё.
Причин появления велосипедика несколько.
1. «Статическая» локализация это нэ
jQuery.my app, в общем случае, это набор вложенных друг в друга приложений, каждое из которых «сидит» на своём поддереве данных, модифицируя его в зависимости от действий юзера или других событий. Как правило, верхние уровни приложения мало что знают о подробностях работы глубоких уровней, и наоборот. Они могут даже вообще не знать о существовании друг друга.
Более того, при доставке пользователю система может менять код приложения – например, обрезать или подменять ветви, ответственные за недоступный данному конкретному юзеру функционал. Так как приложения – JSON-документы, такие штуки делаются особенно легко и это супер-удобная вообще-то фича платформы.
Естественно, словари локализации должны по умолчанию отрезаться/подменяться вместе с самими компонентами.
2. Полная локализация во время инициализации – это нэ
Иногда приложение вообще при старте не знает, какие внутри него будут исполняться компоненты – горячая замена кода же – но локализация вновь вставленных компонентов должна всё равно работать. Вообще, в идеале, пользователь должен иметь возможность поменять локаль во время работы приложения – и увидеть изменения без рестарта.
3. Тридцать лет и три года
Ну и русский язык же. То-есть, мы можем записать для инглиша "User is {1} year old", например. А в русском, по-хорошему, нам нужно склонять. 15 лет, 21 год, 33 года, вот это всё. Строковым шаблончиком не отделаться никак.
То-есть, у нас должны быть где-то строки, где-то шаблоны (такие, например), а где-то – вовсе функции. Которым надо что-то передавать и не давать повалить/изуродовать приложение, если они поломались.
4. Компоновка
Вообще говоря, локаль должна иметь возможность влиять на компоновку и пропорции интерфейса. То-есть, кнопки «Сохр.» и «Закр.» вместо Save и Close – это хороший пример, когда CSS и локаль живут отдельными независимыми жизнями и между ними бетонная стена. Так быть не должно.
----
В результате, по итогам нескольких итераций в течение двух недель, у меня образовалась идиома из двух строчек кода и очень компактный формат для исходных строк/шаблонов/функций. То-есть, раз получилась идиома и формат более-менее приколотился, надо это всё вносить в платформу.
Это вторая фича, которая войдёт в jQuery.my 1.3 как новая. А первая – поддержка ARIA-кодов, да.
К проблеме я присматривался давно, и всё никак не находилось полностью подходящего решения. Я несколько раз попробовал поприкручивать сторонние, плюнул слюной и нагородил своё.
Причин появления велосипедика несколько.
1. «Статическая» локализация это нэ
jQuery.my app, в общем случае, это набор вложенных друг в друга приложений, каждое из которых «сидит» на своём поддереве данных, модифицируя его в зависимости от действий юзера или других событий. Как правило, верхние уровни приложения мало что знают о подробностях работы глубоких уровней, и наоборот. Они могут даже вообще не знать о существовании друг друга.
Более того, при доставке пользователю система может менять код приложения – например, обрезать или подменять ветви, ответственные за недоступный данному конкретному юзеру функционал. Так как приложения – JSON-документы, такие штуки делаются особенно легко и это супер-удобная вообще-то фича платформы.
Естественно, словари локализации должны по умолчанию отрезаться/подменяться вместе с самими компонентами.
2. Полная локализация во время инициализации – это нэ
Иногда приложение вообще при старте не знает, какие внутри него будут исполняться компоненты – горячая замена кода же – но локализация вновь вставленных компонентов должна всё равно работать. Вообще, в идеале, пользователь должен иметь возможность поменять локаль во время работы приложения – и увидеть изменения без рестарта.
3. Тридцать лет и три года
Ну и русский язык же. То-есть, мы можем записать для инглиша "User is {1} year old", например. А в русском, по-хорошему, нам нужно склонять. 15 лет, 21 год, 33 года, вот это всё. Строковым шаблончиком не отделаться никак.
То-есть, у нас должны быть где-то строки, где-то шаблоны (такие, например), а где-то – вовсе функции. Которым надо что-то передавать и не давать повалить/изуродовать приложение, если они поломались.
4. Компоновка
Вообще говоря, локаль должна иметь возможность влиять на компоновку и пропорции интерфейса. То-есть, кнопки «Сохр.» и «Закр.» вместо Save и Close – это хороший пример, когда CSS и локаль живут отдельными независимыми жизнями и между ними бетонная стена. Так быть не должно.
----
В результате, по итогам нескольких итераций в течение двух недель, у меня образовалась идиома из двух строчек кода и очень компактный формат для исходных строк/шаблонов/функций. То-есть, раз получилась идиома и формат более-менее приколотился, надо это всё вносить в платформу.
Это вторая фича, которая войдёт в jQuery.my 1.3 как новая. А первая – поддержка ARIA-кодов, да.