GLeBaTi Dec 11 2018 at 13:33

.NET — локализация без боли. (N)gettext + poedit

2 min

10K

.NET*C#*Language localisation*

Tutorial

+18

Comments 28

Leopotam Dec 11 2018 at 14:25

Что произойдет со старой записью, когда поменяется английский текст-ключ в исходниках? Просто все потеряется и нужно будет заново выполнять локализацию? А если там просто фикс синтаксиса?

GLeBaTi Dec 11 2018 at 14:47

Каждый ключ в *.po-файле ссылается на конкретный файл.
gettext генерирует новый *.po-файл и делает какой-то умный merge со старым.
Я пробовал менять несколько букв, изменять положение строки и т.п. Весь перевод остался, просто подсвечиваются измененные перед сохранением.

Leopotam Dec 11 2018 at 14:50

Т.е. неконтролируемая магия. Ясно-понятно. Проще по-старинке — через гуглодоки, ключи и без явной зависимости от внешнего софта и бинарных форматов.

GLeBaTi Dec 11 2018 at 14:54

Контролируемая. Вам в редакторе подсветятся все изменения. Это как git merge делать.
На среднем проекте у меня пока не возникало проблем. Интересно было бы услышать мнение людей использующих gettext в больших проектах

yajohn Dec 11 2018 at 14:55

Да, потеряется, но не все, а только один перевод. Костыль — псевдоперевод с английского на английский. Что иногда оправдано само по себе, поскольку исходники пишет программист, а переводит — профессиональный переводчик.

immaculate Dec 12 2018 at 04:31

Такие строки никуда не исчезают, а помечаются утилитами gettext флагом fuzzy. Потом можно отредактировать строку с учетом изменений, и снять флаг fuzzy.

В нормальных инструментах для перевода (poEdit не пользовался около 10-12 лет, так что не помню, есть ли в нем это) есть еще память переводов, глоссарий, подсказки, и многое другое.

Например, сейчас пользуюсь Weblate для перевода нескольких проектов. Изумительная вещь, и переводчикам ничего объяснять не приходится.

lowercase Dec 11 2018 at 14:51

А как поведет себя либа с омонимами? Ну то есть, например, есть у меня в исходном тексте два места в которых слово draw используется. Но в одном оно означает рисовать, а в другом — тянуть карты. Она позволит нормально в обоих местах перевести или тут будет коллизия?

GLeBaTi Dec 11 2018 at 14:53

Можно указывать контекст:
T._p(«Context», «draw»);

kmosolov Dec 11 2018 at 15:01

Вроде есть же еще понятие контекста? Я так понял что через `T._p(` можно использовать.

GLeBaTi Dec 11 2018 at 15:11

да, поправил

lowercase Dec 11 2018 at 15:02

А, то есть, текст, который указывается в T._() — это сам ключ? Я подумал, что это одновременно, и ключ, и дефолтный текст.

UFO just landed and posted this here

GLeBaTi Dec 11 2018 at 15:06

Вы правильно подумали. Это дефолтный текст если не создан словарь en_US например

mayorovp Dec 11 2018 at 15:22

Как-то тут обошли вниманием кучу острых углов, которые могут испортить всю локализацию...

Первое — омонимы и просто многозначные слова, уже упомянутые выше. Добавлю сюда также просто любые слишком короткие строки.

Вот свежий пример из локализации Stack overflow: слово "about" может быть переведено как "о компании", "о сайте", "об участнике" и еще кучей разных способов. Просто потому что прямой перевод — просто предлог "о" — слишком мал для ссылки или заголовка.

Второе — локализуемые сообщения никогда нельзя собирать конкатенацией. Только string.Format, и переводить надо форматную строку целиком.

Третье — надо не забывать про согласование с числительными и оставлять переводчику достаточно инструментов для этих целей.

vp1000 Dec 11 2018 at 17:07

Сам уже много лет пользуюсь локализацией gettext + poEdit для Windows приложений. Хоть и не .net.
1. Это не проблема. Всегда считаем что есть перевод с английского на английский и другие необходимые языки. Короткие слова и омонимы просто писать в виде развернутого ключа. Например «About company» а в переводе уже указывать нужный вариант.
2. Это действительно может быть проблемой. Сборку строк нужно производить не командой не format, а например записью в поток std::stringstream частей, каждая из которых переводится отдельно.
3. Вот переводчики самая большая проблема. Они не могу понять как пользоваться poEdit. Что нельзя нарушать форматирование строк. Что можно менять, а что нельзя. Приходится садиться и править текст вместе с переводчиком, а потом тестировать результат и править еще раз.
Изменения в коде править легко. poEdit подсвечивает все изменения и может предлагать варианты из готового словаря.

mayorovp Dec 11 2018 at 17:14

Сборку строк нужно производить не командой не format, а например записью в поток std::stringstream частей, каждая из которых переводится отдельно.

Нет, нельзя так делать! Никакого "переводится отдельно"! У переводчика должна быть возможность задать формат для подставляемых значений, переставить части местами, или даже продублировать любую из них. Ничего из этого std::stringstream не дает.

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

Или вы не предоставили достаточных инструментов, из-за чего переводчикам теперь приходится подбирать структуру предложения под шаблон?

ingumsky Dec 11 2018 at 17:25

Вот переводчики самая большая проблема. Они не могу понять как пользоваться poEdit. Что нельзя нарушать форматирование строк. Что можно менять, а что нельзя. Приходится садиться и править текст вместе с переводчиком, а потом тестировать результат и править еще раз.

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

vp1000 Dec 12 2018 at 10:01

И не наговариваю. Переводчики на необходимые в работе языки у нас штатные сотрудники. Для выполнения наших задач от них требуется главным образом знание терминологии в конкретной технической области. Из-за загруженности переводчиков работой, им не до изучения новых технологий локализации, работа с которыми составляет 1% от их основной деятельности. Поэтому и приходится заниматься переводом совместно с переводчиком.

ingumsky Dec 12 2018 at 14:25

У вас противоречие — переводчики загружены вашей работой, но у них нет времени научиться использованию вашей технологии локализации. Так не бывает. Тем более, что gettext — распространённая технология, не требующая особой подготовки. Либо у вас переводчики — совсем не фонтан, либо вы «не умеете их готовить». Хорошие переводчики — прекрасно обучаемые специалисты, владеющие большим спектром технологий и разнообразным ПО, причём им неважно, какое именно ПО использует заказчик — перестроиться не составит проблемы. Многие способны частично автоматизировать свою работу, написав для этого скрипты и т.п. Это я вам говорю, как человек, который работает в области перевода и локализации 15 лет.
PS Минус не мой.

vp1000 Dec 12 2018 at 17:26

Переводчики загружены не моей работой, а работой компании. Переводом контрактов, переписки с заказчиками, тех. документации и пр. Локализация ПО для них разовая и не основная работа. Из за этого и проблемы.

ingumsky Dec 13 2018 at 00:00

ОК, так понятнее. Тогда, если позволите, мой совет:
Организуйте правильно работу с локализацией, займитесь этим всерьёз. Есть ощущение, что сейчас вы разгребаете проблемы, вызванные неправильной организацией. Я не знаю точно, как процесс организован у вас, поэтому рекомендации будут достаточно общими — давайте на перевод законченные строки, желательно с контекстом, чтобы переводчик смог понять и передать всё правильно. Не старайтесь добиться «атомарных значений» фрагментов — чем крупнее фрагмент для перевода, тем более точным и соответствующим оригиналу будет перевод. Не забывайте о том, что в разных языках могут быть различные правила грамматики (дополнительные времена, падежи, словоформы, формы множественного числа и части речи) и разные правила типографики, поэтому, с одной стороны, обеспечьте переводчику возможность «манёвра», с другой, оставьте порядок следования слов на усмотрение переводчика. Ну и, разумеется, не забывайте о том, что в разных языках одна и та же фраза может значительно отличаться по длине, поэтому должен быть запас по ограничению символов.

Johan Dec 11 2018 at 19:54

Боюсь, вам не удастся угадать все случаи, когда одно и то же английское слово переводится по разному в зависимости от контекста. К тому же, использование развёрнутого ключа, в моём понимании, уже стремится к тем самым идентификаторам, от которых хотел избавиться автор.
Переводы частей отдельно, возможно, и являются причиной проблем с переводчиками. Языки не всегда подчиняются законам, которые кажутся логичными. Законченный текст должен переводится целиком без всяких склеек.

gdt Dec 12 2018 at 03:21

Вам, наверное, никогда не приходилось иметь дела с арабским языком.

vp1000 Dec 12 2018 at 10:06

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

gdt Dec 12 2018 at 10:12

Проблема арабского языка — в написании справа налево. А когда в дело вступает форматирование (я имею ввиду подстановку цифр, дат, денежных значений и т. д.) — становится совсем невесело.
Лично я не против вашего подхода, но на мой взгляд он менее универсальный, конечно это не смертельно, если вы не планируете расширять список используемых языков.

vp1000 Dec 12 2018 at 10:36

Оборудование, в состав которого входит обсуждаемое ПО, поставлялось в том числе и в ОАЭ с английским языком интерфейса. Требований по локализации заказчик не выдвигал. Поэтому с этими проблемами и не столкнулся.

immaculate Dec 12 2018 at 04:25

В gettext (вообще, не знаю насчет данной конкретной реализации) естественно есть инструменты для согласования числительных (ngettext) и для добавления контекста к строке для переводчика. В более развитых редакторах, чем упоминаемый poedit, есть также дополнительные средства, в частности, к строкам можно прикреплять скриншоты приложения, чтобы переводчики видели, где именно используется строка.

alex1t Dec 12 2018 at 12:27

Тоже работаем с NGetText. В принципе всё устраивает. Работа с числительными там кстати есть — формат gettext это поддерживает. В коде вместе с текстом передается число (n) — для которого мы хотим получить форму. В целевом языке перевода (*.po-файле) задаётся правило для числительных, которое по сути по формуле вычисляет «категорию» числительной формы. Например в английском — всего две категории (day/days), а в русском уже 3 (2 дня/ 5 дней/ 21 день). В файле перевода соответственно и пишутся по 3 варианта фразы с разными словоформами множественного числа + одна словоформа единственного числа