Обычно на многих платформах я записываю свои строковые ресурсы в файл .resx или .xml, а затем получаю их, используя какой-то платформо-зависимый подход.
То есть на iOS я их получаю NSBundle.MainBundle, а с помощью Context.Resourcesна Android.
Каковы преимущества этого подхода и почему он не имеет прямого доступа в коде, например:
В кроссплатформенном проекте любая платформа может получить к нему доступ напрямую, без интеграции.
Во время строительства не возникает никаких проблем относительно того, правильно ли построены ресурсы.
- Кодер может использовать такие функции, как многоязыковая обработка
Короче говоря: по какой причине строковые ресурсы структурированы таким образом?
[Редактировать]
Допустим, мой файл является частью «основного» проекта, совместно используемого другим проектом. (Подумайте о PCL, кросс-платформенной структуре файлов проекта.)
И предположим, что мой файл просто полностью похож на файл .resx / .xml и выглядит примерно так (я не профессионал в xml, извините!): Параметры Paramètres
Итак, это в основном пользовательский xml, где вы указываете на ключ / язык, чтобы получить правильную строку.
Файл будет частью приложения так же, как вы добавляете любой доступный файл в приложение и систему для доступа к строковым ресурсам, закодированным с использованием PCL. Это добавит накладные расходы к приложениям?
источник
Ответы:
Локализация и интернационализация,
Сохранение внешних строк позволяет им изменять (читай: переведено) без необходимости перекомпиляции (самое большее, просто повторная ссылка, и, в лучшем случае, просто добавление в новую папку).
источник
Если у вас есть файл, содержащий только строковые ресурсы, вы можете передать файл ресурсов агентству переводов или что-то в этом роде и получить перевод. Я полагаю, вы можете себе представить, насколько это может быть сложно, если бы вам пришлось отдавать много кодовых файлов непрофессионалу, чтобы сделать какой-то перевод (в дополнение к тому, что, возможно, он не хочет выдавать свой код кому-либо).
источник
В дополнение к интернационализации / локализации разделение текстовых строк таким образом также позволяет корректору вносить исправления в написанные / грамматические / пунктуации исправления
messages.${LOCALE}, без необходимости прикасаться к файлу с истинным исходным кодом. Вы можете отключить изменения кода, но примите такие текстовые исправления. Если вы принимаете одновременные изменения как кода, так и сообщений, их разделение облегчает объединение исправлений, при условии, что изменения кода не переопределяют любые сообщения, которые существовали на момент проверки корректораmessages.en_US.Кроме того, в зависимости от того, как это реализовано, может даже не потребоваться повторная привязка приложения. Код может просто получить строку 138
messages.${LOCALE}для конкретного сообщения, причем номер строки определяется во время выполнения.источник
Именно так ваш язык / платформа решил реализовать локализацию строк. Для всех подходов к локализации нужны какие-то внешние файлы ресурсов для получения переводов. Основная проблема в том, как вы поддерживаете эти ресурсы.
Похоже, вам нужно поддерживать эти файлы ресурсов вручную , что может быть довольно обременительным. Это также усложняет совместное использование повторяющихся строк. И необходимость делать это, когда вы в настоящее время отправляете только один язык, является еще большим бременем.
Распространенной альтернативой является подход GNU Gettext, заключающийся в разметке переводимых строк в исходном коде и автоматическом извлечении этих строк в стандартные PO-файлы, которые прекрасно работают на кросс-платформенном и кросс-языковом языках. С точки зрения разработчика, он превосходит ручное обслуживание файлов ресурсов XML в любой день.
источник