Что еще добавить в i18n ?

всем похуй

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

Типа так: { zero: '0 штук', one: '1 штука', few: '{{ n }} штуки', many: '{{ n }} штук' }

И старались избегать сложных фраз с кучей переменных от которых формы слов зависят. Почему? Да потому что переводчикам сложно и непонятно было, и от этого страдало качество и скорость переводов. Переводчики были внештатные, кроме английского. Языков было штук 30.

Классический вариант я знаю. Тут дело вкуса, и на кого ориентирована библиотека. Технически подкованные люди от классического варианта очень грустят. Ситуация такая же как с html - программеров он напрягает, в отличие от jade и stylus.

Эта библиотека ориентирована на разработчиков, чтобы им было удобно. Для «гуменитариев» и автоматизации потом можно будет сделать конвертор туда-сюда (если понадобится).

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

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

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

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

Вы можете поделиться, какие именно «разновидности» i18n/l10n пришлось использовать? Например:

из 10 000 фраз:
- в 20% надо было втыкать переменную
- в 5% надо было втыкать плюралы
- в 1% надо было несколько форматов даты
- в 0.1% надо было втыкать локализованные числа
- ...

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

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

Примерно в трети были переменные, процентов 15 – плюралы. С датами все просто было – использовали только текстовые название месяцев, что бы никто не запутался в порядке.

Чисел всяких с запятыми и тысячными почти не было, по этому был какой то общий стандарт.

Проблемы с тем стандартом нету, т.к. текст меняется не так часто, как пишется код. Проблемы были исключительно со скоростью перевода – примерно 20-30 переводчиков (под каждый язык обычно свой, за исключением всяких разновидностей испанских и еще чего то) на удаленке, не фулл тайм естественно, проект который пилило около 50-60 разработчиков с небольшим временным перерывом в сутках – куча новых штук \ текстов. Приходилось менеджера-локализатора пинать, что бы он пинал переводчиков. Так что проблема не в библиотеке для кода, а в людских отношениях в этой област, которые так же надо как то автоматизировать, а вот уже таких систем для перевода и двусторонней связи с переводчиков, комментариев к переводам и приоритетам и т.п. я не знаю, на том проекте своё пилилось.

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

А что там за переводы такие?

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