Каковы преимущества и недостатки наличия файлов локализации против жестко закодированных переменных в исходном коде?

Question

Определения:

Файлы:

Хранение фраз локализации в физическом файле, который читается при запуске приложения, а фразы хранятся в памяти для доступа через util-методы. Фразы хранятся в формате ключ-значение. Один файл на язык.

Переменные:

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

Справочная информация:

Приложение представляет собой сервлет Java, и разработчики используют Eclipse в качестве основной IDE.

Некоторые краткие плюсы и минусы:

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

Каковы преимущества и недостатки наличия текста локализации в файлах по сравнению с жестко закодированными переменными в исходном коде? Что ты делаешь и почему?

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

Answer 1

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

Поэтому я бы порекомендовал перейти с опцией отдельных файлов, а не жестко кодировать ее в приложение.

Answer 2

Я думаю, что нет выбора между «Файлами» и «Переменными». Потому что это всегда должны быть «Файлы».

Плюсы:

a) Простота обслуживания - вся локализация в одном файле.

b) При изменении не требуется перекомпиляция.

в) Легко ввести другой язык.

1. Обычно переводчики нетехнические люди.

2. Не нужно менять в несколько мест.

Answer 3

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

Answer 4

Для крупных софтверных компаний процесс локализации традиционно выполняется отдельной группой из команды разработчиков (часто в другой стране). Группа локализации часто работает с двоичными файлами, поэтому требование, чтобы пакеты ресурсов были отдельными артефактами. Одна из целей этого процесса - не дать переводчикам нарушить исходный код; другое - не давать программистам ломать строки.

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

Вопросы, которые я хотел бы задать о вашем процессе перевода:

• Есть ли у вас инструменты для автоматизации извлечения ресурсов и перезаписи файлов?
  • Любая обрезка и вставка строк (особенно строк, которые вы не можете понять), скорее всего, являются вектором ошибок.
  • Могут ли эти инструменты различать строки ресурсов и непереводимые строки?
• Предоставляете ли вы переводчикам стандартный формат файла, с которым у них есть инструменты для работы?
• Есть ли у вас инструменты / процессы для восстановления строк из предыдущих версий?
• Значительно ли увеличивается размер исходного кода, потому что вы добавляете переводы?
  • Когда речь заходит о логике приложения, строки являются беспорядочными, которые вы не хотите видеть, и есть что-то, что нужно сказать для разделения логики и данных представления
• Масштабируется ли этот подход, если вы добавите больше языков?
• Вы вводите какие-либо проблемы с кодировкой, клавиатурой или шрифтами?
  • Нет смысла жестко кодировать строки, если ваши редакторы их ломают
  • Вы можете преодолеть отсутствие поддержки персонажей, используя \uXXXX escape

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

Answer 5

Если у вас будут локализованные версии вашей программы, то, скорее всего, вам понадобится переводчик в какой-то момент. Если у вас нет файлов локализации, вы должны предоставить переводчику доступ ко всем исходным файлам со строковыми ресурсами (вы даже не знаете, какие они есть?), А затем вам нужно будет изменить исходный код вручную, что может привести к ошибке.