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

Question

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

Метод 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 в целом.

Answer 1

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

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

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

Так что я рекомендую метод 2!

Answer 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, но также, например, когда команда разработчиков сражается за стиль кодирования).