Интернационализация JSP

[dimaby1]

Здравствуйте, я использую spring mvc. Интересует такой вопрос : как организовывает в своих приложениях интернационализацию (i18n) в jsp. В интернете есть множество информации, как организовать в своем спринг приложении поддержку многих языков - и как это делается в коде и как в jsp (ReloadableResourceBundleMessageSource и т.п.). Там нет ничего

Comments

[magicprinc]

В данной теме понимаю мало, но просто для информации

любопытный проект от автора log4j, logback

http://cal10n.qos.ch/

Compiler Assisted Localization, abbreviated as CAL10N (pronounced as "calion") is a java library for writing localized (internationalized) messages using resource bundles you are already familiar with, but with much greater comfort.

* java compiler verifies message keys used in source code

* tooling to detect errors in message keys

* native2ascii tool made superfluous, as you can directly encode bundles in the most convenient charset, per locale.

* good performance (300 nanoseconds per key look-up)

* automatic reloading of resource bundles upon change

The three-page user manual goes into the details, wherein supposedly the devil resides.

Если поддержки jsp нет и вы её приделаете, то всё сообщество скажет вам спасибо! ;-)

Ceki Gülcü - IMHO очень открытый чел, не сноб как некоторые и открыт для патчей

[dimaby1]

Спасибо, конечно за информацию. CAL10N штука неплохая, но у меня проблема немного в другом - мне нужно перевести уже готовые jsp. А тут плагин CAL10N для эклипса судя по всему ничего нового не предоставляет, так что конкретно мне от него пользы немного.

[magicprinc]

"А кроме этого нужно не забыть (вот это больше всего напрягает) прописать в property-файле значения для констант hello и press.here."

поэтому про CAL10N написал - не забыть

[dimaby1]

Проблема опять же в том, что
1. то что мы используем несуществующий енум в jsp мы узнаем не на этапе сборки приложения, а во время выполнения этой jsp
2. все равно нет ни автоматического экстрактинга строк из jsp (хотя я, честно сказать, не уверен что его вообще можно грамотно реализовать) ни каких-то всплывающих подсказок или визардов для jsp

[kefirfromperm]

В идее выделяешь строчечку и жмешь интернационализировать. Все готово.

[bbseva]

Если правильно настроен спринг, т.е. IDE правильно может разрезолвить бандл с языковыми ключами, то будет светить красным, если ключа не будет в файле. Так во всяком случае работает IDEA. Тогда собственно можно пофисксать предложенными IDE средствами (alt+1 или как там в eclipse), система вставит проперти в файл.

[dimaby1]

Да, это верно для редактора кода - тут все ОК.
Для jsp эклипс такого не умеет.

[bbseva]

Ну не розжига ради, эклипс vs idea как жигули vs mercedes. На распродаже можно купить задешево. Хотя я думаю, что наверняка что-то недонастроено.

[dima_san]

Как, говорите, можно в мерседесе настроить массовую интернационализацию _хотя_бы_ на уровне файла (не говоря о бОльших объёмах)?

[lomka]

Могу поделиться решением вопроса i19, при помощи пользовательского тэга.

1. Создаётся пользовательский тэг, в который передаётся его содержимое.
2. Обработчик тэга - записывает это содержимое, как ключ, в таблицу.
3. Данные из таблицы - выводятся на отдельную страничку, в которой переводятся.
4. При рендеринге страницы - в тело тэга подставляются переведённые значения.
5. Естественно, мапа "ключ - перевод" - кешируется.

В коде это выглядит примерно так: Чтобы просматривать свои заказы - нужно войти в систему !

Если текст большой - вместо текста, как ключ, используется аттрибут тэга "id"
здесь большой текстТакой подход - позволяет изолировать процесс программирования, от процесса перевода

[dimaby1]

Согласен, подход хороший - наверное в будущем такое и внедрю

[lomka]

И когда переводчики намучаются с хранением и
поиском по овер 900 проперти файлов, существующим в аттачах к письмам, они, таки, попросят сделать
им редактор проперти файлов.
(если, конечно, раньше, Вы сами не запаритесь рассылать им их вручную, и вести учёт, по 10 локалям)

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

Но, по-любому, успехов Вам.

Знание, полученное на своих ошибках - всяко крепче,
чем знание, полученное на чужих)

[dimaby1]

Не совсем понимаю в чем проблема с проперти-файлами. У нас их по одному на локаль.
Я думал, что проперти-файлы это устоявшийся стандарт. Да и инструменты для редактирования без эклипса тоже вроде есть. И эргономичность у них будет повыше самописного велосипеда.
Опыт штука классная - кроме сайта на джаве, у нас есть 2 десктопных продукта, один тянется года с 2007, другой еще раньше, в которых интернационализация сделана через getText. Переводы getText хранит в текстовых файлах, которые вроде бы не заколебалось периодически высылать переводчикам. И да, в этих продуктах у нас те-же 10 локалей.