Один сегмент - два разных перевода, Проблема перевода одного сегмента в разных файлах в OmegaT |
Здравствуйте, гость ( Вход | Регистрация )
Один сегмент - два разных перевода, Проблема перевода одного сегмента в разных файлах в OmegaT |
iReset |
17.8.2012, 9:50
Сообщение
#1
|
Участник Группа: Участник Сообщений: 178 Регистрация: 6.6.2012 Пользователь №: 3414 Спасибо сказали: 23 раз(а) Репутация: 2 |
Никто не сталкивался с такой ситуацией, когда один и тот же сегмент в OmegaT должен переводиться по разному в разных местах документации?
Например, в классе QPainterPath есть класс Element. Слово Element является отдельным сегментом и, естественно, не должно переводиться. А в классе QRegExp есть таблица, в которой есть заголовок Element. И вот он должен переводиться на Элемент. Какие есть варианты? |
|
|
iReset |
18.8.2012, 21:22
Сообщение
#2
|
Участник Группа: Участник Сообщений: 178 Регистрация: 6.6.2012 Пользователь №: 3414 Спасибо сказали: 23 раз(а) Репутация: 2 |
Только что проверил - и из ГПИ, и из консольного режима перевод корректно подставлен - в 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 сегмент непереведенным. А вопрос все-таки остается открытым. |
|
|
Текстовая версия | Сейчас: 25.11.2024, 16:01 |