Почему строковые ресурсы обычно хранятся вне кода, а не внутри кода?

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

То есть на iOS я их получаю NSBundle.MainBundle, а с помощью Context.Resourcesна Android.

Каковы преимущества этого подхода и почему он не имеет прямого доступа в коде, например:

1. В кроссплатформенном проекте любая платформа может получить к нему доступ напрямую, без интеграции.

2. Во время строительства не возникает никаких проблем относительно того, правильно ли построены ресурсы.

3. Кодер может использовать такие функции, как многоязыковая обработка

Короче говоря: по какой причине строковые ресурсы структурированы таким образом?

[Редактировать]

Допустим, мой файл является частью «основного» проекта, совместно используемого другим проектом. (Подумайте о PCL, кросс-платформенной структуре файлов проекта.)

И предположим, что мой файл просто полностью похож на файл .resx / .xml и выглядит примерно так (я не профессионал в xml, извините!): Параметры Paramètres

Итак, это в основном пользовательский xml, где вы указываете на ключ / язык, чтобы получить правильную строку.

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

Локализация и интернационализация,

Сохранение внешних строк позволяет им изменять (читай: переведено) без необходимости перекомпиляции (самое большее, просто повторная ссылка, и, в лучшем случае, просто добавление в новую папку).

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

В дополнение к интернационализации / локализации разделение текстовых строк таким образом также позволяет корректору вносить исправления в написанные / грамматические / пунктуации исправления messages.${LOCALE}, без необходимости прикасаться к файлу с истинным исходным кодом. Вы можете отключить изменения кода, но примите такие текстовые исправления. Если вы принимаете одновременные изменения как кода, так и сообщений, их разделение облегчает объединение исправлений, при условии, что изменения кода не переопределяют любые сообщения, которые существовали на момент проверки корректора messages.en_US.

Кроме того, в зависимости от того, как это реализовано, может даже не потребоваться повторная привязка приложения. Код может просто получить строку 138 messages.${LOCALE}для конкретного сообщения, причем номер строки определяется во время выполнения.

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

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

Распространенной альтернативой является подход GNU Gettext, заключающийся в разметке переводимых строк в исходном коде и автоматическом извлечении этих строк в стандартные PO-файлы, которые прекрасно работают на кросс-платформенном и кросс-языковом языках. С точки зрения разработчика, он превосходит ручное обслуживание файлов ресурсов XML в любой день.