Comments 10
Под локализацией здесь и далее будем понимать процесс адаптации приложения под разные языки и регионы
Если именно «под разные», то это интернационализация. Локализация всегда под конкретный язык/культуру.
текущий язык пользователя
Скорее текущую локаль (Язык+регион) — форматы даты/времени зависят не только от языка, а ещё и от региона.
Кроме первого пункта «Поддержка ICU грамматики», парсер которой скрыт в недрах @eo-locale/core, и в npm ссылки на гитхаб нету, остальное есть в стандартном Intl (ну и коленка + 10 минут комментатора ниже :) ).
Я не понимаю почему это важно, поскольку мне не известны профессиональные CAT утилиты, нормально обрабатывающие ICU формат. Ни SDL Trados, ни MemoQ этим похвастаться не могут, колупаться среди непереводимых select и plural не приносит переводчикам радости. В теории ICU форматтер это круто и гибко, но на практике несколько простых текстов для plural или select без разметки переводить проще и быстрее.
Пока переводчик это коллега — программист и текстов мало — всё хорошо. Когда проект станет больше, например, несколько десятков тысяч слов которые нужно будет переводить на десятки языков работа с ICU грамматикой будет источником проблем.
Про то, что остальное просто использование Intl в статье указано прямо)
У нас не несколько простых текстов, много мультиязычных проектов. Используем в работе сервис lokalise.com переводы из него можно экспортировать в том числе и в ICU.
Собственно переводчики там работают с интерфейсом сервиса, им не нужно знать в каком формате будет экспортироваться текст.
select ни разу не приходилось использовать.
При использовании ICU грамматики вы пишете код для plural один раз и потом можете добавлять/убирать сколько угодно языков. Вам не нужно думать о plural rules для конкретного языка. Если приведете пример кода, который на Ваш взгляд форматирует plural более удобным способом, мне будет интересно взглянуть)
Понравились определения, кажется от w3c: интернационализация — подготовка приложения к работе с разными локалями, а локализация — собственно создание новой локали.
Мимопроходил. Два года назад был опыт с Интернационализацией (i18n) и Локализацией (L10n) интерфейса Ideco UTM. (Вылилось в презентацию в Екатеринбурге: https://www.youtube.com/watch?v=UIUXbzk273s).
tl;dr; Стоит выделить основные задачи:
- Как работать разработчику с кодом приложения на нескольких языков? (Удобство программирования i18n-ого приложения)
- Как быть бедному переводчику? (Удобство локализации. Большой проект рано или поздно покажет, что большой JSON с переводами — далеко не конечное решение)
- Что делать с переводами, когда мы обновили приложение?
Мы использовали gettext, который отвечает на эти вопросы так:
- есть функция gettext, которой разработчик передает строки на СВОЁМ английском языке (при большом желании и на русском).
- AST-Парсер автоматически извлекает все строки в файл, который отдаем переводчик переводит текст
- Переводчик может, например с poedit, перевести строки в удобном приложении, которое ещё и проверит, что он все строки правильно написал
Плюсы:
- удобно писать проект, если нашли отлаженный AST-gettext экстрактор
- удобно переводить переводчику
- с помощью gettext Утилит можно мержить переводы, отслеживать какие строки появились, какие пропали, какие вернулись
- Есть хорошая вероятность, что все идеи будут работать в другом языке X (Изначально C)
Минус:
- не удобно для больших строк/абзацев/текстов. Для статики, мне нравится идея из HuGo (https://gohugo.io/content-management/multilingual/#translation-by-filename)
p.s. это был один из последних серьезных проектов на фронте. Не знают, что сейчас поменялось. Так как вижу новые библиотеки интернационализации — ничего хорошего нового. Задачу локализации очень легко недооценить, несмотря на весь опыт gettext до сих пор 0.20.1 (https://www.gnu.org/software/gettext/), уж не знаю почему разработчики не считают эту версию законченной
В свою очередь попробую ответить на поставленные вопросы:
- Собственно разработчик работает с ключами, не зная ничего о конкретном языке или значении внутри ключа. С этим есть некоторые недостатки, но пока не вижу решения лучше.
- Как уже писал выше, для переводов есть достаточно классные сервисы, которые предоставляют переводчикам удобный интерфейс. Очевидно, что не нужно заставлять переводчиков редактировать json файл или вникать в синтаксис грамматики.
- Собственно так как переводы живут в отдельном сервисе, то всё что нужно это скачивать их перед каждой выкладкой на продакшн.
Локализация React приложении