Разработчик всё равно должен передать все «селекторы» из кода, просто дальнейшая логика работы по построению сообщения сброшена на «локализаторов/переводчиков/UX-writerов». Гибкость Fluent усложняет оценку затрат на переводы и тестирование/контроль качества.
Для всяких энтузиастов и опенсорса это хорошее решение, но в мире коммерческих переводов, где цена зависит от объема текста — маловероятно что переводчики будут заморачиваться с логикой без дополнительных капиталовложений. Почему переводчик на русский должен писать целую пачку сообщений с учётом комбинаций числа и рода, в то время когда в английском это была лишь пара строк?
(Переведут «Сообщений: X» и хватит :) )
gettext довольно строго регламентирует plural, изначально требуя все формы, необходимые с учётом языка. Хотя это и дубово — это фиксированный и заранее известный объем работы для переводчиков и QA. А вот креатив с Fluent уже не так прост и предсказуем.
Да, можно форматировать дату на любой локали, которая поддерживается ОС независимо от текущей. Это никак не относится к gettext, обычно это стандартная библиотека.
Не обязательно локаль браузера/ОС соответствует локали сайта/продукта, и получается мешанина из, например, английского текста и китайской даты.
Эмм… я не писал о том что нужно обязательно использовать текущую локаль браузера/ОС. Обычно ОС поддерживает вполне солидный набор локалей, можно выбрать наиболее подходящую, не обязательно текущую/по умолчанию.
При взаимодействии с другими программами в GNU/Linux например скорее всего они (другие программы) будут использовать текущую локаль системы и для консистентности продукт должен работать так-же
Ну тогда по технической части мелкие неточности, кроме уже указанных
Идентификатор сообщения: исходная строка
Обычно да, но есть ещё msgctx точнее было бы написать контекст + исходная строка
не умеет работать с форматированием дат и чисел
Fluent активно использует стандартизованные библиотеки и алгоритмы CLDR, ICU
В большинстве случаев форматированием дат и чисел уже занимаются функции ОС/браузера/окружения, которые как раз и используют ICU(CLDR) и gettext этому никак не мешает. В том же JavaScript этим обычно занимается Intl, и он существует независимо от Fluent.
Шаблоны сообщений: необходимы (.pot)
Но ведь .ftl и есть тот самый шаблон. Непосредственно для переводчиков сам .pot не нужен — после генерации и обновления .po файлов его можно удалить, его не хранят.
Технически он есть, вот такой временный генерируемый файл. Но после настройки сборки о существовании .pot или .mo можно забыть и работать только с обновляемыми .po
Не раскрыта тема устаревших переводов, .po может их хранить/накапливать и «воскрешать» в случае необходимости — вот такая «память переводов» из коробки :)
Это к gettext лишь косвенно относится (там нет форматтера аргументов, используется стандартный) и зависит от языка программы — в Python прекрасно работают ключи.
В gettext использует три формата файлов — *.po, *.pot и *.mo. Это влияет на внедрение gettext в производственный цикл, добавляя этапы вроде извлечения и компиляции сообщений.
По факту .po и .pot это один и тот-же формат, .pot и .mo автоматически генерируемые, их не нужно хранить в репозитории. Компиляция это ещё и проверка синтаксиса, а автоматическое извлечение сообщений — это наиболее полезная функция в gettext.
xgettext + msgmerge это как-раз то, что избавляет от головной боли при работе с большим числом сообщений. Пока Fluent сам по себе не предлагает решения этих проблем, с каждым id нужно возиться вручную.
P.S. Fluent гораздо лучше .po в качестве формата, но xgettext отнюдь не так плох, и исторически хорошо себя зарекомендовал как достаточно простое и удобное решение, для большинства случаев вполне достаточное. Лучшее враг хорошего :)
Алгоритм быстрого возведения в степень можно написать по-разному :)
Например, множитель возводится в квадрат и в зависимости от того, выставлен ли бит умножает результат, работает от младшего бита к старшему, например 2^10 r=1 (результат), m=2(множитель)
10 в двоичной это 1010, идя по битам от младшего к старшему 0101
0 m=2, r=1
1 m=4, r=r*m=4
0 m=16, r=4
1 m=256, r=r*m=1024
Т.е. 2^10 = 2^2*2^8
В двоичном виде степень меняется так:
0,10,010,1010
В приведённом алгоритме же порядок прохода битов от старшего к младшему, множитель не меняется, а сам результат возводится в квадрат, если бит 1 то ещё и домножается на множитель.
1 m=2, r=r*r*m=2
0 m=2, r=r*r=4
1 m=2, r=r*r*m=32
0 m=2, r=r*r=1024
Т.е. 2^10=(((2)^2)^2*2)^2
В двоичном виде степень меняется так:
1,10,101,1010
Всё верно, возведение в квадрат это дописать к степени в двоичном виде 0 справа, а если там должна быть единица то ещё домножить.
Однако я ожидал увидеть там немного другую реализацию — без нахождения старшего бита :).
Я про них и писал :), но не всегда можно получить нулевую ставку.
Кроме того бесплатный 100% match как правило означает что на контекст переводчик тупо забивает, что и было изначальной проблемой.
Не понимаю, откуда взялось «принудительно заставлять обновлять»?
1 Я писал про fuzzy, которым можно «закрыть» изменения старым переводом
2 Потом этот fuzzy всё равно переводчики будут смотреть, и возможно даже что-то переведут
3 Скрывать любые пусть даже мелкие правки от переводчиков нет смысла
На практике конфликты достаточно редки и повторное использование вполне оправдано, при генерации в .po файле можно перечислить все файлы с указанием строк, где msgid использовался и это помогает определить — допустимо ли повторное использование или нужно разделить по контексту.
Автоматически раздавая всем вхождениям уникальный контекст получаем 100500 «OK» и «Cancel» на перевод и перевод каждого нового «OK» оплачивается отдельно :)
Вопрос ответственности.
Могут как заменить, так и не заменить — это вполне в компетенции переводчиков. Я категорически против того, чтобы эту ответственность забирать у переводчиков — менять текст и решать, что переводчикам об этом знать не обязательно(ведь русский перевод же не изменится).
Фактически разработчик меняя текст берёт на себя ответственность за использование старых переводов, а в его ли это компетенции?
Это лучше чем было, перенос части языкозависимой логики формирования текстов на сторону переводчиков требует или полноценной поддержки инструментами для перевода (CAT вроде Trados или MemoQ) или знаний со стороны переводчика.
Увы, ICU MessageFormat не удалось этого добиться за более чем десяток лет своего существования, но может Fluent повезёт больше…
Что это «последствия классического подхода gettext» на мой взгляд неудачная формулировка (gettext имеет стандартное решение этой проблемы), так как и в Fluent это точно так-же решается передачей различного контекста (id или параметра). Да, если его уже передавали — то в Fluent это решится лишь переводом, а если нет — последствия аналогичны.
Увы, тот факт что русский перевод не меняется — совершенно не означает что переводы на другие языки тоже меняться не будут — особенно в случае новомодной замены his на them. Точно так же никто не гарантирует того, что опечатка никак не повлияла на переводы.
gettext хорошо решает задачу сбора строк в перевод по исходному коду проекта, изменение, добавление, удаление. Fluent же вообще к этим задачам не относится, поэтому их нельзя сравнивать целиком.
Как формат Fluent гораздо мощнее .po
P.S. В .po даже есть msgid_plural, но его не называли «Концепцией асимметричной локализации — ключевой инновацией»
Для всяких энтузиастов и опенсорса это хорошее решение, но в мире коммерческих переводов, где цена зависит от объема текста — маловероятно что переводчики будут заморачиваться с логикой без дополнительных капиталовложений. Почему переводчик на русский должен писать целую пачку сообщений с учётом комбинаций числа и рода, в то время когда в английском это была лишь пара строк?
(Переведут «Сообщений: X» и хватит :) )
gettext довольно строго регламентирует plural, изначально требуя все формы, необходимые с учётом языка. Хотя это и дубово — это фиксированный и заранее известный объем работы для переводчиков и QA. А вот креатив с Fluent уже не так прост и предсказуем.
hbc0017 не работает
P.S. Для Python gettext — стандартная библиотека.
Эмм… я не писал о том что нужно обязательно использовать текущую локаль браузера/ОС. Обычно ОС поддерживает вполне солидный набор локалей, можно выбрать наиболее подходящую, не обязательно текущую/по умолчанию.
При взаимодействии с другими программами в GNU/Linux например скорее всего они (другие программы) будут использовать текущую локаль системы и для консистентности продукт должен работать так-же
Официальная позиция разработчиков Fluent вполне ожидаема — и маркетинг им не чужд.
Обычно да, но есть ещё msgctx точнее было бы написать контекст + исходная строка
В большинстве случаев форматированием дат и чисел уже занимаются функции ОС/браузера/окружения, которые как раз и используют ICU(CLDR) и gettext этому никак не мешает. В том же JavaScript этим обычно занимается Intl, и он существует независимо от Fluent.
Но ведь .ftl и есть тот самый шаблон. Непосредственно для переводчиков сам .pot не нужен — после генерации и обновления .po файлов его можно удалить, его не хранят.
Технически он есть, вот такой временный генерируемый файл. Но после настройки сборки о существовании .pot или .mo можно забыть и работать только с обновляемыми .po
Не раскрыта тема устаревших переводов, .po может их хранить/накапливать и «воскрешать» в случае необходимости — вот такая «память переводов» из коробки :)
Ну как же www.gnu.org/software/gettext/manual/html_node/Modifying-Comments.html#Modifying-Comments
Вот перечень поддерживаемых типов файлов/языков для xgettext
C, C++, ObjectiveC, PO, Shell, Python, Lisp, EmacsLisp, librep, Scheme, Smalltalk, Java, JavaProperties, C#, awk, YCP, Tcl, Perl, PHP, GCC-source, NXStringTable, RST, Glade, Lua, JavaScript, Vala, Desktop
Это к gettext лишь косвенно относится (там нет форматтера аргументов, используется стандартный) и зависит от языка программы — в Python прекрасно работают ключи.
По факту .po и .pot это один и тот-же формат, .pot и .mo автоматически генерируемые, их не нужно хранить в репозитории. Компиляция это ещё и проверка синтаксиса, а автоматическое извлечение сообщений — это наиболее полезная функция в gettext.
xgettext + msgmerge это как-раз то, что избавляет от головной боли при работе с большим числом сообщений. Пока Fluent сам по себе не предлагает решения этих проблем, с каждым id нужно возиться вручную.
P.S. Fluent гораздо лучше .po в качестве формата, но xgettext отнюдь не так плох, и исторически хорошо себя зарекомендовал как достаточно простое и удобное решение, для большинства случаев вполне достаточное. Лучшее враг хорошего :)
Например, множитель возводится в квадрат и в зависимости от того, выставлен ли бит умножает результат, работает от младшего бита к старшему, например 2^10 r=1 (результат), m=2(множитель)
10 в двоичной это 1010, идя по битам от младшего к старшему 0101
0 m=2, r=1
1 m=4, r=r*m=4
0 m=16, r=4
1 m=256, r=r*m=1024
Т.е. 2^10 = 2^2*2^8
В двоичном виде степень меняется так:
0,10,010,1010
В приведённом алгоритме же порядок прохода битов от старшего к младшему, множитель не меняется, а сам результат возводится в квадрат, если бит 1 то ещё и домножается на множитель.
1 m=2, r=r*r*m=2
0 m=2, r=r*r=4
1 m=2, r=r*r*m=32
0 m=2, r=r*r=1024
Т.е. 2^10=(((2)^2)^2*2)^2
В двоичном виде степень меняется так:
1,10,101,1010
Всё верно, возведение в квадрат это дописать к степени в двоичном виде 0 справа, а если там должна быть единица то ещё домножить.
Однако я ожидал увидеть там немного другую реализацию — без нахождения старшего бита :).
Кроме того бесплатный 100% match как правило означает что на контекст переводчик тупо забивает, что и было изначальной проблемой.
1 Я писал про fuzzy, которым можно «закрыть» изменения старым переводом
2 Потом этот fuzzy всё равно переводчики будут смотреть, и возможно даже что-то переведут
3 Скрывать любые пусть даже мелкие правки от переводчиков нет смысла
Автоматически раздавая всем вхождениям уникальный контекст получаем 100500 «OK» и «Cancel» на перевод и перевод каждого нового «OK» оплачивается отдельно :)
Могут как заменить, так и не заменить — это вполне в компетенции переводчиков. Я категорически против того, чтобы эту ответственность забирать у переводчиков — менять текст и решать, что переводчикам об этом знать не обязательно(ведь русский перевод же не изменится).
Фактически разработчик меняя текст берёт на себя ответственность за использование старых переводов, а в его ли это компетенции?
Увы, ICU MessageFormat не удалось этого добиться за более чем десяток лет своего существования, но может Fluent повезёт больше…
Как формат Fluent гораздо мощнее .po
P.S. В .po даже есть msgid_plural, но его не называли «Концепцией асимметричной локализации — ключевой инновацией»