Лучшая практика для ключевых значений в файлах перевода

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

Метод 1: Используйте полные английские слова или предложения:

Name => Name
Please enter your email address => Please enter your email address

Способ 2: Используйте ключевые слова, описывающие ситуацию:

NAME => Name
ENTER_EMAIL => Please enter your email address

Я лично предпочитаю метод # 1, потому что он прямо показывает смысл сообщения. Если перевод отсутствует, вы можете вернуться к ключу, и это не вызовет никаких проблем. Тем не менее, этот метод является громоздким, когда перевод часто меняется, потому что все файлы необходимо обновить. Кроме того, для более длинных текстов эти клавиши становятся очень большими. Это решается с помощью таких клавиш, как ENTER_EMAIL, но фраза полностью выходит за рамки контекста. Список ключей абстрактного перевода будет огромным, вам нужны метаданные для всех ключей, объясняющих их использование, и столкновения могут происходить намного проще.

Есть ли лучшее из обоих миров или третий метод? Как вы используете ключи перевода в своем приложении? В нашем случае это приложение, основанное на php, но я думаю, что проблема выше, достаточно общая, чтобы говорить о i18n в целом.

Ответ 1

Это вопрос, которому также сталкиваются разработчики iOS/OSX. И для них есть даже стандартный стандартный инструмент под названием genstrings, который предполагает метод 1. Но, конечно, разработчикам Apple не нужно использовать этот инструмент - т.

В то время как защитная сетка, которую вы получаете с методом 1, хороша (например, вы можете отобразить ключ, если вы как-то забыли локализовать строку), это имеет недостаток, что это может привести к конфликтующим клавишам. Иногда один идентичный фрагмент текста дисплея должен быть локализован двумя разными способами из-за правил грамматики или различий в контексте. Например, французский перевод для "E-mail" будет "E-mail" , если это заголовок диалога и "Envoyer un e-mail", если это кнопка (по-французски слово "E-mail" является только существительным и не может использоваться как глагол, в отличие от английского, где он и существительное, и глагол). С помощью метода 2 у вас могут быть ключи EMAIL_TITLE и EMAIL_BUTTON для решения этой проблемы, и в качестве бонуса это даст подсказку переводчикам, чтобы помочь им правильно перевести.

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

Поэтому я рекомендую метод 2!

Ответ 2

Почему бы не использовать оба мира? Я использую метод # 1 для коротких строк и метод # 2 для длинных строк, которые являются полными предложениями. Я не боюсь смешивать оба файла в одном файле.

Например, в следующей строке текст может измениться, если в новой версии приложения изменяется пользовательский интерфейс:

"screen description" = "Tap the plus button to add a new item. Tap an item for more options or to edit its details.";

Итак, здесь имеет смысл применить метод # 2. Однако для простых строк, как в следующем примере, метод # 1 более полезен:

"Preferences" = "Preferences";

В целом, когда люди пытаются стандартизировать вещи, это часто кажется мне ограничивающим. Лично я предпочитаю более "анархический" подход, когда действуют несколько методов (не только как в этом методе # 1, так и в отношении потока # 2, но также, например, когда команда разработчиков сражается за стиль кодирования).