Ответ 1

Я использую значащие идентификаторы, такие как "welcome_back_1", которые были бы "welcome back, %1" и т.д. У меня всегда есть английский как мой "базовый" язык, поэтому в худшем случае, когда конкретный язык не имеет сообщения ID, я возвращаюсь на английский язык.

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

Ответ 2

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

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

Тем не менее, я в настоящее время оцениваю, следует ли переносить этот способ ввода I18N в новый проект, поэтому хорошо слышать некоторые мысли о том, почему это может быть не очень хорошая идея.

Ответ 3

Я категорически не согласен с ответом Ричарда Харрисона, о котором он заявляет, что это "единственный способ". Дорогой вопросник, не верьте ответам, в которых говорится, что это единственный способ, потому что "единственный способ" не существует.

Вот еще один способ, которым ИМХО имеет несколько преимуществ по сравнению с Ричардсом:

• Начните с использования прото-версии английской строки в качестве оригинала.
• Не показывать эти прото-строки, но создавать файл перевода для английского языка без изменений
• Скопируйте прото струны к переводу для начала

Преимущества:

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

Ответ 4

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

Также, если текст на английском изменяется, возможно, другие обновления необходимо обновить?

На практике мы также используем Pure ID, а не английский текст, но это означает, что мы должны делать много дополнительной работы по умолчанию на английском языке.

Ответ 5

Одним словом, не делайте этого.

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

Определите мнемонические идентификаторы для ваших строк и рассматривайте английский как просто другой язык.

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

Инженер по локализации Ex

Ответ 6

Разве вы уже не ответили на свой вопрос?:)

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

Ответ 7

Есть много, чтобы рассмотреть и ответить не так просто.

Использование простого английского языка

Pros

• Легко писать и читать код
• В большинстве случаев он работает даже без выполнения функций перевода в коде

против

• Приглашенные программисты должны быть также хорошими копирайтерами:)
• Вам нужно полностью писать правильные точные тексты на английском языке, даже в том случае, если первый язык, который вам нужно запустить, - это что-то другое (т.е. мы запускаем проекты на чешском языке, и мы локализуем их позже EN).
• Во многих случаях вам нужно использовать контексты. Если вы не можете сделать это от begginig, то много работы добавить их позже. Объяснение: на английском языке одно слово может иметь много разных звуков - и вам нужно использовать контексты для их дифференциации - и это не всегда так просто (порядок = порядок сортировки, или это может быть заказ на поставку).
• В этом процессе может быть очень сложно исправить английский. Исправления исходных строк очень часто приводят к потере уже переведенных фраз. Очень сложно распустить перевод на 3 разных языка только потому, что вы исправили английский.

Использование клавиш

Pros

• Вы можете использовать функции платформы локализации даже для английского языка. То есть мы используем прекрасную платформу Кроудин. Существует много удобных инструментов - или, скорее, полный рабочий процесс - для управления переводом: голосование за разные переводы, историю переводов, глоссарии (что помогает поддерживать согласованность перевода/языка), проверку, утверждение и т.д. Использование ключей делает этот процесс более плавный.

• Гораздо проще отправлять английские тексты для корректуры и т.д. Обычно не рекомендуется копировать сценаристы непосредственно для изменения вашего кода:)

против

• Более сложная настройка проекта.
• Сложнее использовать% d,% s и т.д.

Ответ 8

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

Ваша проблема аналогична, за исключением того, что вы также несете ответственность за обновление всех ссылок...

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

Ответ 9

В дополнение к рассмотренным выше соображениям есть много случаев, когда вы хотите, чтобы "ключ" (msgid) отличался от исходного текста (на английском языке). Например, в представлении HTML я могу сказать [yyyy], где место назначения и метка этого якоря-тега зависят от локали пользователя. Например. это может быть ссылка на социальную сеть, а в США это будет Facebook, но в Китае это будет Weibo. Таким образом, MsgIds могут быть чем-то вроде socialSiteUrl и socialSiteLabel.

Я использую микс.

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

Ответ 10

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

Это заставляет меня чувствовать, что правильным ответом является использование измененной версии gettext, где вы помещаете строки, подобные этому

_(id, backup_text, context)

_('ABOUT_ME', 'About Me', 'HOMEPAGE')

контекст необязателен

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

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

Идентификатор также должен быть доступен для чтения, что приводит к проблеме синонимов и использования дубликатов (даже в виде ids), мы могли бы префикс идентификаторов типа "HOMEPAGE_ABOUT_ME" или "MAIL_LETTER", но

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

поэтому я также добавил контекстную переменную в конце

резервный текст может быть почти любым, даже может быть "[О__ME @HOMEPAGE текст не загружен, пожалуйста, свяжитесь с [email protected]]"

Он не будет работать с текущими программами редактирования текста, такими как "poedit", но я думаю, что вы можете определять имена пользовательских переменных для переводов, как просто "t()", без подчеркивания в начале.

Я знаю, что gettext также поддерживает контексты, но не очень хорошо документирован или широко используется.

P.S. Я не уверен в наилучшем переменном порядке для обеспечения хорошего и расширяемого кода, поэтому предложения приветствуются.