Pull to refresh

Comments 10

Под локализацией здесь и далее будем понимать процесс адаптации приложения под разные языки и регионы

Если именно «под разные», то это интернационализация. Локализация всегда под конкретный язык/культуру.
текущий язык пользователя

Скорее текущую локаль (Язык+регион) — форматы даты/времени зависят не только от языка, а ещё и от региона.
Конкретно привязку к React, увы, оценить не могу.

Кроме первого пункта «Поддержка ICU грамматики», парсер которой скрыт в недрах @eo-locale/core, и в npm ссылки на гитхаб нету, остальное есть в стандартном Intl (ну и коленка + 10 минут комментатора ниже :) ).

Я не понимаю почему это важно, поскольку мне не известны профессиональные CAT утилиты, нормально обрабатывающие ICU формат. Ни SDL Trados, ни MemoQ этим похвастаться не могут, колупаться среди непереводимых select и plural не приносит переводчикам радости. В теории ICU форматтер это круто и гибко, но на практике несколько простых текстов для plural или select без разметки переводить проще и быстрее.

Пока переводчик это коллега — программист и текстов мало — всё хорошо. Когда проект станет больше, например, несколько десятков тысяч слов которые нужно будет переводить на десятки языков работа с ICU грамматикой будет источником проблем.
Парсер вот тут github.com/eo-locale/core/tree/master/src/parser

Про то, что остальное просто использование Intl в статье указано прямо)

У нас не несколько простых текстов, много мультиязычных проектов. Используем в работе сервис lokalise.com переводы из него можно экспортировать в том числе и в ICU.
Собственно переводчики там работают с интерфейсом сервиса, им не нужно знать в каком формате будет экспортироваться текст.

select ни разу не приходилось использовать.

При использовании ICU грамматики вы пишете код для plural один раз и потом можете добавлять/убирать сколько угодно языков. Вам не нужно думать о plural rules для конкретного языка. Если приведете пример кода, который на Ваш взгляд форматирует plural более удобным способом, мне будет интересно взглянуть)

Понравились определения, кажется от w3c: интернационализация — подготовка приложения к работе с разными локалями, а локализация — собственно создание новой локали.

Очень круто, но ни одну из объявленных выше задач не решает

Мимопроходил. Два года назад был опыт с Интернационализацией (i18n) и Локализацией (L10n) интерфейса Ideco UTM. (Вылилось в презентацию в Екатеринбурге: https://www.youtube.com/watch?v=UIUXbzk273s).


tl;dr; Стоит выделить основные задачи:


  1. Как работать разработчику с кодом приложения на нескольких языков? (Удобство программирования i18n-ого приложения)
  2. Как быть бедному переводчику? (Удобство локализации. Большой проект рано или поздно покажет, что большой JSON с переводами — далеко не конечное решение)
  3. Что делать с переводами, когда мы обновили приложение?

Мы использовали gettext, который отвечает на эти вопросы так:


  1. есть функция gettext, которой разработчик передает строки на СВОЁМ английском языке (при большом желании и на русском).
  2. AST-Парсер автоматически извлекает все строки в файл, который отдаем переводчик переводит текст
  3. Переводчик может, например с poedit, перевести строки в удобном приложении, которое ещё и проверит, что он все строки правильно написал

Плюсы:


  • удобно писать проект, если нашли отлаженный AST-gettext экстрактор
  • удобно переводить переводчику
  • с помощью gettext Утилит можно мержить переводы, отслеживать какие строки появились, какие пропали, какие вернулись
  • Есть хорошая вероятность, что все идеи будут работать в другом языке X (Изначально C)

Минус:



p.s. это был один из последних серьезных проектов на фронте. Не знают, что сейчас поменялось. Так как вижу новые библиотеки интернационализации — ничего хорошего нового. Задачу локализации очень легко недооценить, несмотря на весь опыт gettext до сих пор 0.20.1 (https://www.gnu.org/software/gettext/), уж не знаю почему разработчики не считают эту версию законченной

Спасибо за комментарий, обязательно гляну доклад.

В свою очередь попробую ответить на поставленные вопросы:

  1. Собственно разработчик работает с ключами, не зная ничего о конкретном языке или значении внутри ключа. С этим есть некоторые недостатки, но пока не вижу решения лучше.
  2. Как уже писал выше, для переводов есть достаточно классные сервисы, которые предоставляют переводчикам удобный интерфейс. Очевидно, что не нужно заставлять переводчиков редактировать json файл или вникать в синтаксис грамматики.
  3. Собственно так как переводы живут в отдельном сервисе, то всё что нужно это скачивать их перед каждой выкладкой на продакшн.
Sign up to leave a comment.

Articles