Локализация Альтернативой Resx файл

Question

Почему я не хочу использовать Resx файлы:

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

• Я не люблю указывать «messageId» при написании сообщений, это больше усилий, и это раздражает поток, поскольку я не вижу, что на самом деле скажет сообщение журнала, и мне нужно будет открыть другое для редактирования сообщения
• Иногда я использую встроенный код, потому что я Не хотите создавать новые переменные для простых шагов (e. г. Log.Info("Iterated {i+1} times");). Использование переменных или делать простые расчеты инлайн делает весь код иногда более четко, чем создавать дополнительные строки кода

То, что я мог себе представить, вместо того, чтобы:

Внешнее приложение, которое ползает скомпилированный ехе для всех строк, давая вы можете игнорировать/добавлять строки, которые нужно перевести. Он также может создавать XML или Json-файл для всех языков. Он заменил бы все строки хэшем/id так, чтобы поиск строк для всех языков по-прежнему возможен.

Является ли я единственным, кто недоволен обычно используемым решением Resx/centralized db? Могу ли я пропустить точки, почему это не будет хорошей идеей?

Answer 1

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

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

Кстати, если вы хотите хороших локализаций для строк, таких как Log.Info("Iterated {i+1} times");, вам нужно найти способ управления множественными формами правильно. Некоторые языки имеют разные грамматические правила для разных номеров (см. Обзор Unicode Language Plural Rules). Я просто боюсь, что что-то легко сделать в коде, это не значит, что это легко локализовать.

Подводя итог: если вы хотите создать свой собственный формат ресурсов, поговорите со своими переводчиками. Спросите, с какими форматами они могут справиться. Подумайте о связанных с переводом ограничениях, связанных с вашим форматом, например, если есть какие-либо символы, которые переводчики не должны использовать, потому что они разбивают ваши строки? Апоптопы и кавычки являются главными кандидатами здесь, потому что они часто используются в качестве разделителей строк в файлах ресурсов или < и &, если вы решите пойти по пути XML. Подумайте о преобразовании в XLIFF и обратно: большинство условий перевода могут обрабатывать XLIFF.