Java EE i18n и структура проекта по умолчанию - PullRequest
Новая
       24

Java EE i18n и структура проекта по умолчанию

5 голосов
/ 27 марта 2011

Я Питон Джанго Девел

Я хочу немного попробовать Java.

В django я делал перевод следующим образом: 

from django.utils.translation import ugettext_lazy as _

и затем, если перевод указан в .po файле в файле locale / en / django.po 

_("hello world")

Вопрос 1: есть ли подобное в Java?

Я нашел такие:

но ни один из них не является тем, что я ищу

Я сделал как в примере 

import java.util.ResourceBundle;
import java.util.MissingResourceException;

public class i18n {
    private static ResourceBundle myResources = ResourceBundle.getBundle("messages");

    public static String _ (String originalStr) {
        try {
            return myResources.getString(originalStr);
        } catch (MissingResourceException e) {
            return originalStr;
        }
    }

}

и позже 

import static i18n._;

Вопрос 2: а куда поместить файл messages.properties?

  • Я хотел бы иметь отдельный каталог локали с этими файлами.

  • переводы из всего пакета и подпакетов

    • локали / messages_en_US.properties
    • локали / messages_en_UK.properties
  • и так далее ...

Вопрос 3: Эта часть с отслеживанием исключений, кажется, не работает, вы знаете, почему?

Вопрос 4. Существует ли стандарт JavaEE для i18n?

Я думал, что в java EE должен быть стандартизированный макет каталога приложений, i18 и содержимое каталога war, но в течение нескольких дней дурачиться с java я считаю очень хаотичным. Поэтому каждый пример открытого исходного кода, который я могу найти в Интернете, совершенно другой. Начиная с проекта Google Wave Protocol, заканчивая примерами небольших приложений.

Вопрос 5: Существуют ли философия кодирования JavaEE или лучшие практики?

Я нашел Стратегия для веб-приложений , но разработчики, похоже, не заботятся об этом. Размещение тестов, тоже самое. У всех они есть в разных местах. Логика, как sql запросов в шаблонах, WTF ...

1 Ответ

11 голосов
/ 27 марта 2011

Нет единственного правильного места для размещения файлов ресурсов;Обычно это решение для разработчика приложения.Размещение всех файлов в одном стандартном месте может не иметь смысла во всех архитектурах, поэтому в спецификации не добавляются ненужные ограничения.

На то, как вы должны загружать и ссылаться на пакеты ресурсов, может влиять то, какие платформы вы используете.Например, в приложении JSTL вы можете использовать тег bundle ;в приложении JSF вы можете использовать тег loadBundle .Другие технологии представления будут определять свои собственные механизмы.

В общем ...

ResourceBundle.getBundle загружает ресурсы из пути к классам, поэтому, если вы хотите использовать каталог,он или один из его родителей должны быть на пути к классу приложения.В WAR пакеты должны находиться в файле JAR в каталоге WEB-INF/lib или в каталоге WEB-INF/classes.

Итак, для набора пакетов ... 

 /WEB-INF/classes/locale/messages.properties
 /WEB-INF/classes/locale/messages_fr.properties
 /WEB-INF/classes/locale/messages_de.properties

... вы бы загрузили пакет, получив запрос Locale и вызвав: 

ResourceBundle.getBundle("locale.messages", locale);

Неправильно назначить пакет одной статической переменной:

//BUG! this loads the properties file for the server default locale only!
private static ResourceBundle myResources = ResourceBundle.getBundle("messages");

Вы должны получить языковой стандарт пользователя из запроса .Статическое назначение будет уместным только в клиентском приложении (например, в среде IDE).

Обратите внимание, что обычно рекомендуется предоставить корневой messages.properties базовый файл в качестве запасного варианта для неподдерживаемых локалей.

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

...