Комментарии 41
А это выглядит похожим на нормальное.
Увы, ICU MessageFormat не удалось этого добиться за более чем десяток лет своего существования, но может Fluent повезёт больше…
transChoise
уже признан устаревшим с версии 4.2
.
Но программист должен передавать количество параметром в trans
.
А документацию-то ещё не поправили...
Да и новая реализация не радует: если я правильно ее понял, то числительное с которым будет согласование, обязано называться %count%
. А это тоже должен переводчик решать.
Это хорошо что только одно перечисление. Как программист я хочу разбивать целое на куски. Вместо того чтобы городить лапшку из нескольких кусков и многомерную матрицу всех вариантов.
Как программисту, вам вообще не надо этим заниматься.
Разбиение текста на куски неспециалистом может привести к тому, что отдельные куски станут непереводимы. Или они будут переводимы, но будут идти в неправильном порядке.
Кстати, обратная проблема тоже существует. Так, на stackoverflow фраза "about", как выяснилось, имеет три разных перевода...
Это невозможно. Как минимум надо передать переменные в систему перевода.
Ну так передайте их. Переменные и id сообщения. И на этом ответственность программиста заканчивается — в этом и вся прелесть предложенного решения.
Предложенный.
Переводчик на русский: нам нужен пол пользователя.
Программист: ок.
Переводчик на японский: а нам нужен ещё и возраст.
Программист: ок.
Классический.
Переводчик на русский: нам нужен пол пользователя.
Программист: ок.
Переводчик на русский: нет, нам нужен choice по полу пользователя.
Программист: но выбор уже занят количеством.
Переводчик на русский: придумай что-нибудь, пол реально нужен.
Программист: ну хорошо, сделаю три разных сообщения.
Переводчик на японский: а мне нужен возраст.
Программист: да вы издеваетесь! Это мне что, мега-матрицу придётся делать?
Переводчик на японский: но возраст-то нужен.
Программист: ну ладно, уговорили…
Переводчик на русский: эй, почему слетел перевод? Почему столько новых дубликатов у уже переведенных строк?
В этом и прелесть: если нет ресурсов/специалистов, переводим «в лоб». Если есть спец на конкретную локаль — у него полная свобода действий в оптимизации строки под нужды его языка, не нужно лишний раз дёргать разработчика.
Могут как заменить, так и не заменить — это вполне в компетенции переводчиков. Я категорически против того, чтобы эту ответственность забирать у переводчиков — менять текст и решать, что переводчикам об этом знать не обязательно(ведь русский перевод же не изменится).
Фактически разработчик меняя текст берёт на себя ответственность за использование старых переводов, а в его ли это компетенции?
Вот, вспомнил ещё последствия классического подхода gettext: на stackoverflow фраза "about", как выяснилось, имеет три разных перевода. Без доработок со стороны программистов её нормально перевести было невозможно.
Доработки со стороны программистов всё равно останутся, передавать переводчикам контекст всё равно придётся, число, пол и т.д.
В предложенном подходе заменившие контексты идентификаторы назначаются всем сообщениям изначально.
Автоматически раздавая всем вхождениям уникальный контекст получаем 100500 «OK» и «Cancel» на перевод и перевод каждого нового «OK» оплачивается отдельно :)
Автоматически раздавая всем вхождениям уникальный контекст получаем 100500 «OK» и «Cancel» на перевод и перевод каждого нового «OK» оплачивается отдельно :)
Эм, нормальные перводчики/агентства используют для повторов другую ставку при определённом совпадении (вплоть до 0-20% при 100% match).
в .po файле можно перечислить все файлы с указанием строк, где msgid использовался
Очень полезная для переводчика инфа :-)
Как формат Fluent гораздо мощнее .po
P.S. В .po даже есть msgid_plural, но его не называли «Концепцией асимметричной локализации — ключевой инновацией»
Fluent 1.0: гибкая система локализации