Почему люди используют простой английский в качестве заполнителей перевода?

Question

Это может быть глупый вопрос, но здесь идет.

Я видел несколько проектов, использующих некоторую библиотеку переводов (например, gettext), работающую с простыми английскими заполнителями. Так, например:

_("Please enter your name");

вместо абстрактных заполнителей (что всегда было моим инстинктивным предпочтением)

_("error_please_enter_name");

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

Разве это не ужасно громоздко? Почему это отраслевой стандарт?

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

Answer 1

Да, вы должны изменить существующие файлы перевода, и это хорошая вещь .

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

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

Answer 2

1. Основной язык уже существует: вам не нужно переводить его.
2. Переводчики имеют лучший контекст с реальным предложением, чем расплывчатые заполнители.
3. Заполнители - это всего лишь ключи, все еще можно изменить исходный язык, создав для него перевод. Потому что, когда перевод не существует, он использует заполнитель в качестве переведенного текста.

Answer 3

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

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

Answer 4

Мне нравится ваш второй подход.При переводе текстов у вас всегда возникает проблема омонимов .Как «open» может означать состояние окна, но также и глагол для выполнения действия.На других языках эти омонимы могут не существовать.Вот почему вы должны иметь возможность добавлять , что означает к вашим местозаполнителям.Лучший подход - поместить это значение в вашу текстовую библиотеку.Если это невозможно на платформе, которую вы используете, возможно, было бы неплохо определить «язык разработки».Этот язык добавит значение в текстовые записи, такие как «action_open» и «state_open».Вы, конечно, должны приложить дополнительные усилия, переводя этот язык на простой английский (или язык, для которого вы разрабатываете).Я применил эту философию в некоторых крупных проектах , и в долгосрочной перспективе это экономит некоторое время (и головные боли).

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

_(i18n("Please enter your name", "error_please_enter_name"));

Где:

i18n(text, meaning)

Answer 5

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

Answer 6

Довольно старый вопрос, но еще одна причина, которую я еще не видел в ответах:

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

Придерживайтесь вашего примера: текст «Пожалуйста, введите ваше имя» может появиться в другом контексте в другом шаблоне (что разработчик наиболеескорее всего не в курсе и не должно быть).Например, это может быть использовано не как ошибка, а как подсказка, похожая на заполнитель поля ввода.

Если вы используете

_("Please enter your name");

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

Однако, если вы использовали

_("error_please_enter_name");

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

_("prompt_please_enter_name");

, который затем должен быть переведен снова.

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

Кто-нибудь согласен / не согласен?

Answer 7

Существует запасная иерархия, от самой конкретной локали до нелокализованной версии в исходном коде.

Таким образом, у французов во Франции может быть следующий запасной маршрут:

1. fr_FR
2. фр
3. нелокализованной. Исходный код.

В результате, наличие правильных английских предложений в исходном коде гарантирует, что, если конкретный перевод не предусмотрен на шаге (1) или (2), вы, по крайней мере, получите правильное понятное предложение, чем мусор случайного программиста типа « ERROR_FILE_NOT_FOUND».

Плюс, что вы делаете, если это строка формата: «Извините, но% s не существует»? Хуже того: «Записано% s записей в% s, общий размер:% d»?

Answer 8

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