Интернационализация и локализация в приложении AJAX

Ответ 1

ваш подход действительно меня интересует, потому что это подход, который мы использовали в прошлом. У меня есть кое-какие знания, которые делают это так. Вот некоторые мысли - надеюсь, что они будут полезны!

Примечание. Я только что написал это и понял, что большая часть контента относится к подходу с одной страницей, а не к локализации! Сожалею. Здесь вы узнаете, что вы можете пригодиться, но если вас интересует только часть локализации, перейдите к Загрузить данные приложения в формате JSON из раздела REST url!

Приложение AJAX работает с одной HTML-страницей, созданной на стороне сервера с i18n
1 страница веб-приложений - то есть: состоящий из одной страницы, где контент обновляется AJAX - по моему опыту очень интересно создавать. Простое и гибкое взаимодействие с интерфейсом может помочь вам только здесь. Как только вы перейдете на более сложные интерфейсы, вы можете в конечном итоге полагаться на постоянно увеличивающийся пул плагинов. Это действительно зависит от того, что делает ваше приложение, поэтому я не могу слишком сильно прокомментировать это.



ОДНАКО, по моему опыту, основной проблемой, с которой я столкнулся с одностраничными приложениями с интерфейсами XHR-driven, является управление памятью. Работа с памятью браузера вокруг динамически создаваемых объектов намного лучше, чем была, и это хорошая проблема для обеспечения того, чтобы ваш собственный код и ваши сторонние плагины имели хорошее использование памяти. Я обнаружил, что это не всегда так. Если ожидается, что ваше приложение будет иметь короткие сеансовые сеансы, тогда отлично - это не должно быть проблемой. Если вы думаете, что люди потратят некоторое время - может быть, весь день или на несколько дней - на ваше приложение, то вы определенно захотите серьезно подумать об этом. По моему опыту, независимо от того, насколько хороши производители браузера сказать управление памятью или насколько хорошо вы чувствуете, что ваш код/​​сторонний код находится в управлении памятью, он все еще не идеален. Мы по-прежнему испытываем некоторое ухудшение в наших одностраничных приложениях.

В результате мы перешли к гибриду, в котором мы разделили приложение на логические области и установили настройку по 1 странице для каждой области. Таким образом, браузер получает облегчение разгрузки всей страницы каждый раз и снова, и поэтому может хорошо проясняться. Это для нас было гораздо лучшим решением. Сказав это, это действительно зависит от вас, что делает ваше приложение и как долго вы ожидаете, что пользователи будут взаимодействовать с ним за один сеанс. Это также хорошо в редких случаях, когда проблема с одной частью приложения калечит всю страницу. Это, безусловно, худший сценарий, но я бы предпочел перезагрузить одну область приложения, чем все приложение.

HTML-страница импортирует JQuery и плагины
Любить это. Я относительно новичок в jQuery (перейдя по пути ExtJS), но я слышал, что есть несколько отличных плагинов для jQuery, и за ним стоит хорошее твердое сообщество.

Использование XHR для загрузки созданных сервером шаблонов i18n HTML по мере необходимости
Также хороший подход. При этом стоит подумать о том, что видит ваш пользователь, пока браузер выполняет эту работу. Вы хотите дать им что-то посмотреть, пока вы загружаете контент в фоновом режиме. Я уверен, вы уже об этом подумали. Тем не менее, я не могу подчеркнуть достаточно в этом подходе, однако, это восстановление ошибок и обратная связь. Если что-то пошло не так, и страница не загружается должным образом, а у пользователя остается искалеченное приложение - это не очень хороший интерфейс! Всегда стоит потратить много времени, учитывая то, что пользователь должен знать о том, что (если что-либо) пошло не так, и хороших четких инструкциях о том, как оправиться от него. Некоторые пользователи параноики и имеют тенденцию проходить через цикл:
Что-то пошло не так → Это была моя ошибка → Я сломал ее, теперь я чувствую себя виноватым и обвиняемым → Ненавижу использовать эту вещь.
Или вы получаете абсолютно тефлоновые плечи пользователей, которые думают так:
Что-то пошло не так → Не по моей вине → Эта штука мусор → Ненавижу использовать эту штуку. это не единственные типы пользователей, которые вы получаете, но в основном: все, что вы можете сделать, чтобы отвлечь пользователя от" Я ненавижу использование этой вещи". конечной точки, тем лучше! Еще раз, я уверен, вы уже это считали!

Загружает данные приложения в формате JSON с URL-адресов REST
Еще раз, хороший подход. Мы использовали его сами. Он чувствует отличный, чтобы данные были отделены от интерфейса. В ваших комментариях вы говорите:
" Поскольку эти данные получены из базы данных, на нем не выполняется i18n "
В прошлом мы пишем систему фильтрации данных, в соответствии с которой операции выполняются на необработанных данных, чтобы сделать ее удобной и иногда более безопасной, прежде чем отправлять ее клиенту. Большинство серверных платформ довольно хорошо разбираются в деталях, таких как локаль, из информации о сеансе, поэтому это может быть, где вы применяете изменения локализации.

Если вы пишете расширяемую систему, это может быть приятно чтобы открыть своего рода систему перехватчика/крюка, в результате чего расширения также получают трещину при изменении данных в определенных точках. Мир - это ваш выбор вставки моллюсков, так сказать.

Последнее: User "travel"
Это, скорее, примечание об одностраничном подходе к приложениям. Если вы берете маршрут с одной страницей, это поможет вам решить, как разделять области. Пользователи приложений не любят делать то, что они уже сделали, и считают, что им не нужно делать больше одного раза. Если ваш пользователь "путешествует" через вашу систему интерфейса и что-то пойдет не так, требуя обновления страницы для восстановления (сценарий с худшим случаем снова!), и поэтому им придется "путешествовать", тот же интерфейс снова, чтобы добраться до места, где они хотят быть, это будет очень утомительно для них. Например, в одном из наших одностраничных приложений пользователь путешествовал по функциональности через систему меню стиля просмотра данных. Если что-то пошло не так, что требуется обновление страницы, им пришлось снова пройти через ту же систему меню, чтобы добраться до того же места. Решение состояло в том, чтобы переместить области, представляющие интерес, для разделения одностраничных областей, и на них выходят точки выхода из меню. Таким образом, если произошла неустранимая ошибка, требующая обновления страницы, обновление сохраняло их в своей области интересов.

Извините, если я вафли. Я новичок в stackoverflow - пожалуйста, простите меня, если я сделал это неправильно!

Ответ 2

Найдено это решение:
http://github.com/eligrey/l10n.js/
Но он не использует шаблоны...
В любом случае, это может быть полезно для кого-то.