Да, это точный противоположный вопрос, чем: Почему люди используют простой английский в качестве заполнителей перевода?
Я все время использовал стандартный способ gettext для перевода, но теперь, когда я делаю фронтенд, я понял, что не только большинство библиотек используют ключи / заполнители, но иногда это рекомендуется (см. i18next ) поверх используя простой английский.
Я мало работал с заполнителями, но мне сложно, потому что:
- вы должны все время придумывать уникальные имена местозаполнителей, вам нужны соглашения
- возможно, вы хотите повторно использовать то же имя заполнителя, чтобы найти существующее, совпадающее с тем, что вы переводите
- лучше ли иметь все переводы для каждого модуля или иметь общие переводы? Я не уверен
В соответствии с документом i18-next рекомендуется использовать заполнители, поскольку:
Хотя это работает и может уменьшить количество файлов для загрузки, оно делает
Управление переводами намного сложнее, так как вам нужно будет обновить
изменения резервных значений в коде и файлах json.
- Я бы не стал использовать простой английский для уменьшения количества загружаемых файлов. Это, очевидно, неправильно.
- JSON? Что не так с PO / POT? Уже так много инструментов для переводчиков.
- Если нужно изменить формулировку, следует пересмотреть все переводы, так что я думаю, что это "хорошо", что это сломает старые переводы, верно?
- Мне кажется, что разработчики могут сосредоточиться на правильном понимании английского текста, а переводчики - на других.
- Я действительно не понимаю, как намного сложнее использовать простой английский. Пример из реальной жизни был бы великолепен.
Я предполагаю, что у обоих методов есть свои плюсы и минусы, но я не вижу плюсов с заполнителями, поэтому мне хотелось бы понять.