Как мне структурировать файлы свойств комплекта ресурсов, которые используются jsps? - PullRequest
3 голосов
/ 08 декабря 2008

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

Мой вопрос: как эти файлы свойств должны быть структурированы? Я знаю, что они должны быть в classpath для веб-приложения, но вместо того, чтобы хранить их непосредственно в WEB-INF / классах, я бы предпочел скопировать их туда на этапе сборки. Это оставляет мне большую гибкость в том, как хранить файлы в Subversion. Поскольку они тесно связаны с jsps, будет ли хорошей идеей создать новый каталог верхнего уровня (например, ресурсы) и отразить структуру jsp в этой папке? Это даст мне такую ​​структуру, как

resources/jsp/index.properties
resources/jsp/index_cy.properties

Это кажется разумным подходом, и его можно расширять для файлов свойств и для классов, если они необходимы:

resources/com/mycompany/myapp/CustomObject.properties
resources/com/mycompany/myapp/CustomObject_cy.properties

Процесс сборки может затем скопировать все эти файлы в классы WEB-INF /, готовые для упаковки в файл war.

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

Edit: было отмечено, что этот подход может привести к множеству дублированных строк в различных файлах свойств. Хотя это и правда, в jsps будет столько же дублированных строк, сколько в настоящее время существует. Лучше ли иметь четкое отображение из jsp в файлы свойств, за счет некоторого дублирования в файлах свойств?

Ответы [ 3 ]

2 голосов
/ 08 декабря 2008

Было отмечено, что это подход может привести к большому количеству дублированные строки в различных файлы свойств. Хотя это правда, это будет только столько же дублированных Строки, как в настоящее время существуют в JSPs. Это лучше иметь четкое отображение из JSP в файлы свойств, в стоимость некоторого дублирования в файлы свойств?

Да, это всегда лучше. Хотя можно «повторно использовать» строку в разных местах / JSP на английском языке, это может быть невозможно на других языках. Повторное использование локализованных строк может также создать нежелательные и хитрые зависимости между компонентами, которые иначе не связаны. Переводчики также должны знать об использовании текстов, которые они переводят в вашем приложении.

2 голосов
/ 08 декабря 2008

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

Да, я думаю, что это так.

Я считаю, что Maven создает следующую структуру каталогов:

src
  +- main
  |    |- java
  |    |- resources
  +- test
       |- java
       |- resources

Что дает вам хорошее четкое разделение между вашим кодом и модульными тестами, а затем между Java-кодом и ресурсами, такими как файлы свойств и т. Д.

0 голосов
/ 08 декабря 2008

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

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

Я бы структурировал файлы ресурсов отдельно и попытался бы найти организацию, которая по своей сути имеет смысл, например UiLabels.properties, ErrorMessages.properties.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...