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