Gettext: Это хорошая идея, чтобы идентификатор сообщения был английским текстом? - PullRequest
39 голосов
/ 19 октября 2008

Мы готовимся перевести наш веб-сайт PHP на различные языки, и поддержка gettext в PHP выглядит как путь.

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

gettext («Привет!»)

Но разве это хорошая идея? Допустим, кто-то в маркетинге хочет изменить текст на «Привет, вы все!». Тогда вам не нужно обновлять все языковые файлы, потому что эта строка - которая фактически является идентификатором сообщения - изменилась?

Лучше ли иметь какой-нибудь общий идентификатор, такой как "hello.message", и файл перевода на английский язык?

Ответы [ 10 ]

39 голосов
/ 24 февраля 2009

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

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

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

20 голосов
/ 19 октября 2008

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

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

17 голосов
/ 09 февраля 2009

Я категорически не согласен с ответом Ричарда Харрисона, о котором он заявляет, что это «единственный путь». Уважаемый спрашивающий, не верьте ответу, в котором говорится, что это единственный путь, потому что «единственный путь» не существует.

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

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

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

  • читаемый код
  • текст в вашем коде очень близок, если не совпадает с тем, что отображается в вашем представлении
  • если вы хотите изменить текст на английском языке, вы не изменяете протостроку, а перевод
  • если вы хотите перевести одно и то же дважды, просто напишите немного другую протостроку или просто добавьте «версию для того и того», и у вас все еще есть отлично читаемый код
11 голосов
/ 19 октября 2008

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

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

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

6 голосов
/ 31 июля 2009

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

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

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

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

Бывший инженер по локализации

4 голосов
/ 16 октября 2017

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

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

Плюсы

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

Против

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

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

Плюсы

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

  • Гораздо проще отправлять тексты на английском языке для корректуры и т. Д. Как правило, копирайтерам не стоит разрешать напрямую изменять ваш код:)

Против

  • Более сложная настройка проекта.
  • Труднее использовать% d,% s и т. Д.
3 голосов
/ 19 октября 2008

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

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

2 голосов
/ 30 января 2016

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

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

_(id, backup_text, context)

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

контекст необязательный

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

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

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

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

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

текст резервной копии может быть почти любым, даже может быть "[ABOUT_ME @ HOMEPAGE text не удалось загрузить, пожалуйста, свяжитесь с example@example.com]"

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

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

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

1 голос
/ 19 октября 2008

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

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

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

0 голосов
/ 20 декабря 2012

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

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

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

...