Один сегмент - два разных перевода, Проблема перевода одного сегмента в разных файлах в OmegaT Опции

[iReset]

Никто не сталкивался с такой ситуацией, когда один и тот же сегмент в OmegaT должен переводиться по разному в разных местах документации?
Например, в классе QPainterPath есть класс Element. Слово Element является отдельным сегментом и, естественно, не должно переводиться. А в классе QRegExp есть таблица, в которой есть заголовок Element. И вот он должен переводиться на Элемент.
Какие есть варианты?

[alex977]

В OmegaT есть такой пункт в контекстном меню - Альтернативный перевод.
Если нужно какой-то сегмент перевести по другому - выбираешь и пишешь новый вариант.
В файле ПП создаётся секция с альтернативой и получается два варианта перевода в одной ПП:

Раскрывающийся текст

<!-- Default translations -->
<tu>
<tuv lang="EN-US">
<seg>Element</seg>
</tuv>
<tuv lang="RU-RU" changeid="Alex977" changedate="20120817T162505Z">
<seg>Элемент</seg>
</tuv>
</tu>

<!-- Alternative translations -->
<tu>
<prop type="file">qpainterpath.html</prop>
<prop type="prev">qpainterpath-element.html</prop>
<prop type="next">enum</prop>
<tuv lang="EN-US">
<seg>Element</seg>
</tuv>
<tuv lang="RU-RU" changeid="Alex977" changedate="20120817T162550Z">
<seg>Element</seg>
</tuv>
</tu>

Вот как это отработает qtmxtools я затрудняюсь ответить. Скорее всего порежет альтернативу.

[iReset]

В файле ПП создаётся секция с альтернативой и получается два варианта перевода в одной ПП:

Это, конечно, здорово, но вопрос в том, как поведёт себя OmegaT при переводе в консольном режиме. Она ведь не будет смотреть на альтернативные переводы. Она ведь оба сегмента переведёт одинаково. И вот тут как быть? Предварительно изменять оригинал на что-то другое? Например Element, который должен быть переведён, можно изменить на Element_qtrtt и уже этот сегмент переводить как Элемент.
Конечно, касательно конкретно этого случая я понимаю, что проблема не стоящая, тут можно оставить сегмент не переведённым. Мне просто интересно, это единичный случай, или такое уже встречалось? Ну и потенциально, конечно, хорошо бы найти решение на случай будущих коллизий.

Вот как это отработает qtmxtools я затрудняюсь ответить. Скорее всего порежет альтернативу.

Если так, то, я думаю, можно доработать qtmxtools. Не очень бы хотелось терять примечания и альтернативы.

[alex977]

Это, конечно, здорово, но вопрос в том, как поведёт себя OmegaT при переводе в консольном режиме. Она ведь не будет смотреть на альтернативные переводы. Она ведь оба сегмента переведёт одинаково. И вот тут как быть?

Только что проверил - и из ГПИ, и из консольного режима перевод корректно подставлен - в qpainterpath.html - Element, в qregexp.html - Элемент.
Так что на уровне OmegaT никаких проблем [пока] не выявлено.

[iReset]

Только что проверил - и из ГПИ, и из консольного режима перевод корректно подставлен - в qpainterpath.html - Element, в qregexp.html - Элемент.

Насколько я понимаю, ты говоришь именно про альтернативный перевод.
Действительно, я был не совсем прав. OmegaT корректно подставляет альтернативный перевод. Вот только есть другая проблема. Альтернативный перевод привязывается к имени файла, включая относительный путь от каталога source. А нигде, насколько я знаю (если поправите и скажете, где, буду благодарен), не оговаривались принципы размещения переводимых файлов в каталоге source переводчиками.
Например, кто-то будет переводить одну версию и все файлы будут лежать в корне. Для этой ситуации для альтернативного перевода должно быть записано, например, "qpainterpath.html".
Другой переводчик будет переводить сразу несколько версий и расположит каждую из версий в каталоге вида "435". Для этой ситуации путь будет "435/qpainterpath.html".
У меня версии лежат в каталогах вида "4.3.5". У меня путь должен быть "4.3.5/qpainterpath.html".
Для всех этих трех случаев необходимо делать свой альтернативный перевод. Более того, альтернативный перевод надо будет делать для каждой версии переводимой документации. А к сожалению, эти сегменты не показываются как непереведённые и обратить внимание на то, что в новой версии для каких-то сегментов надо сделать альтернативный перевод, будет сложно.

Кроме того, глянул, как с таким переводом поступает qtmxtools. К сожалению, она про них вообще не знает, а при патче ПП подставляет последний вариант перевода. У меня им как раз оказался альтернативный. Т.е. при слиянии методом --patch альтернативный перевод стал основным.
Конечно, при слиянии, вероятно, применяется --merge. Но и в этом случае пропадает информация об альтернативных переводах. К сожалению, в этой части qtmxtools требует доработки.
Видимо, я все же оставлю в qregexp.html сегмент непереведенным.

А вопрос все-таки остается открытым.

[alex977]

Один вариант придумал.
0) все исходники располагаем в source без подкаталогов (дополнительное условие для всех переводчиков)
1) перед получением diff-а переводчик вырезает весь альтернативный перевод в отдельный файл и прилагает его вместе с diff
2) после получения общей ПП тот, кто объединяет добавляет эти альтернативные переводы и проверяет наличие дублей в них
3) общая ПП с объединенными альтернативными переводами
4) получаем и выкладываем документацию на основе этой ПП

В крайнем случае можно и без п. 0 - главное чтобы вместе с diff были альтернативные переводы в отдельном файле.

Слияние с помощью qtmxtools не использую - вручную добавляю содержимое diff, а потом вручную же просматриваю и удаляю дубли

Сообщение отредактировал alex977 - 19.8.2012, 14:45

[iReset]

Один вариант придумал.
0) все исходники располагаем в source без подкаталогов (дополнительное условие для всех переводчиков)
1) перед получением diff-а переводчик вырезает весь альтернативный перевод в отдельный файл и прилагает его вместе с diff
2) после получения общей ПП тот, кто объединяет добавляет эти альтернативные переводы и проверяет наличие дублей в них
3) общая ПП с объединенными альтернативными переводами
4) получаем и выкладываем документацию на основе этой ПП

В крайнем случае можно и без п. 0 - главное чтобы вместе с diff были альтернативные переводы в отдельном файле.

Хорошо. Хотя ограничения "все исходники в одном каталоге" и дополнительный геморрой для объединяющего оптимизма не добавляют. Ну да с эти можно постепенно разобраться.

Слияние с помощью qtmxtools не использую - вручную добавляю содержимое diff, а потом вручную же просматриваю и удаляю дубли

Возникли два вопроса:
1. А как вручную, если не секрет? Совсем вручную? Или с в помощью каких-то средств все-таки?
2. Почему не используешь qtmxtools? Чего-то в нем не хватает? Со своей стороны скажу два недостатка, которые мне известны. Во-первых, в Windows в режиме merge вместо русского в консоли крякозябры. Во-вторых, потеря дополнительной информации при слиянии.

[alex977]

Просто в копию своей ПП добавляю содержимое diff, а потом в Okapi Olifant просматриваю и удаляю ненужные сегменты с одинаковыми оригиналами.

[Litkevich Yuriy]

В OmegaT есть такой пункт в контекстном меню - Альтернативный перевод.

А с какой версии это появилось?

PS
всем привет

[alex977]

А с какой версии это появилось?

Привет!
С 2.5.0 - OmegaT latest version 2.5.0 released