Объединение tmx-файлов, Маленькое руководство по объединению файлов с помощью TMXMerger Опции

[Novak]

На страничке ресурсов программы OmegaT есть ссылка для скачивания java-сценария TMXMerger, предназначенного для объединения tmx-файлов.
Синтаксис у этого сценария очень простой:

TMXMerger-1.0.jar <исходный файл 1> <исходный файл 2> <результирующий файл>

Например, при

TMXMerger-1.0.jar source_1.tmx source_2.tmx project_save.tmx

Объединяются два файла source_1.tmx и source_2.tmx
В результирующем файле будут записаны все пары переводов, что были в первом и втором файле.
Если встретились разные переводы одного сегмента в исходных файлах, то все варианты будут записаны в результирующем файле. Получится запись примерно такого вида:

<tu>
         <tuv lang="EN-US">
            <seg>How to Build the ODBC Plugin on Windows</seg>
         </tuv>
         <tuv lang="RU-RU">
            <seg>Как собрать ODBC плагин под Windows</seg>
         </tuv>
         <tuv lang="RU-RU">
            <seg>Как собрать QMYSQL плагин под Windows</seg>
         </tuv>         
</tu>

После этого нужно вычистить этот файл от лишний дублирующих записей.
С этим справляется сама OmegaT. Если создать проект со всеми необходимыми файлами для перевода и подложить в него наш объединённый tmx-файл, то остаётся только запустить генерацию переведённых файлов, и лишние записи из нашего исходного файла перевода будут удалены. При этом сохраняется первая запись из встреченных.
Потому при объединении файл, который был передан первым в скрипт TMXMerger имеет больший приоритет в плане дублирования записей.

Мне кажется, что стоит ещё немного поэкспериментировать, в эту тему писать результаты этих опытов. После этого дополнить это руководство и выложить в вики и траке.

Сообщение отредактировал Novak - 14.1.2009, 8:29

Причина редактирования: Немного дополнил

[Litkevich Yuriy]

Потому при объединении файл, который был передан первым в скрипт TMXMerger имеет больший приоритет в плане дублирования записей.

я к такому же выводу пришел, но не эксперементально.

я как-то упоминал программу Olifant из Okapi Framework
Открыл в ней наш объедененный файл project_save.tmx (7820 кБ), отсортировал сегменты по оригинальным, увидел две пустые строчки и удалил их, затем экспотировал в TMX, получил файл весом 6641 кБ, т.е. олифант что-то выкинул. Но я не разбирался - слишком много сегментов аж глаза разбегаются.

Можно в Олифанте находить дубликаты (автоматически с проставлением флажков), затем сортировать по наличию флажков и смотреть какой сегмент удалить.

Омега всякий раз при сохранении меняет сегменты местами из-за чего в хранилище отправляется много информации (около 3 МБ). Можно в этом олифанте перед фиксацией правки сортировать ПП, а потом уже фиксировать правку.

[alex977]

При этом сохраняется первая запись из встреченных.
Потому при объединении файл, который был передан первым в скрипт TMXMerger имеет больший приоритет в плане дублирования записей.

Вручную обрабатывать - глаза потерять можно.
В неявном приоритете первой записи уже заложено, что такой способ использовать нельзя.
Нужно что-нибудь более автоматизированное. Хотя бы для работы только с вариантами перевода.
Смотрю Olifant.

[Novak]

Вручную обрабатывать - глаза потерять можно.

Всмысле вручную? Я вручную потом бегло просматриваю. Последние тмх файлы делаю первыми, чтоб были приоритетнее. В остальном дальше автоматизировать нечего...

[Litkevich Yuriy]

Последние тмх файлы делаю первыми, чтоб были приоритетнее. В остальном дальше автоматизировать нечего...

в смысле последние?

[alex977]

Всмысле вручную?

В том смысле, что если использовать только tmxmerge и редактировать результирующий файл руками - это совсем никуда не годится. Вообще.

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

Я вручную потом бегло просматриваю.

Опять-таки - все сегменты? А если их будет под 200 000?

Сообщение отредактировал alex977 - 15.1.2009, 17:04

[Litkevich Yuriy]

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

я собрался делать подобную штуку, но забросил - времени нет. Идея:
Есть программа "Х", запускаем ее и импортируем TMX в нее. Программа сохраняет все сегменты в БД, там же хранятся связи сегментов друг с другом. При импортировании следующего файла программа ищет сегмент, например анлийский, в БД если есть такой же, но нет связи с неким новым (например, новый вариант перевода), то добавляет новый вариант и связывает его с соответствующим сегментом плюс ставит флажек "новый связанный сегмент". После импорта всего TMX'а, программа показывает пользователю сегменты у которых появились новые связи, ну и связанные сегменты тоже, помечая новый цветом. Т.е. получается QTreeView.

Пользователю предоставляется специальный столбец "Верно" с флажком (QCheckBox) в этом столбце отмечается какой из связанных сегментов считать верным.

Далее импортируются остальные TMX'ы и процедура выбора верных повторяется.

По завершении обработки из БД экспортируются данные в TMX, но только те сегменты, которые либо единственные, либо имеют флажек "Верно".

Я пока сделал только набросок базы в FireBird, и собрался делать проксимодель для TMX'ов, чтобы сразу смотреть TMX'ы в QTreeView, ну и еще несколько экспериментов провел.

[alex977]

Я тоже немного думал обо всем об этом.

Только немного с другой точки зрения.

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

Мысль была такая - в программе, где идет перевод, в каждый сегмент записывается дата изменения. В программе объединения tmx-файлов назначается базовый файл (общий файл предыдущего поколения) и файлы с изменениями. Все сегменты которые уже есть в базовом файле и не изменились в файлах с изменениями - игнорируются. Работа идет только с сегментами, которых нет или дата изменения которых позже, чем в в базовом файле предыдущего поколения.

На выходе получаем новый базовый файл.

Но дальше мыслей дело пока не пошло. :-(

Сообщение отредактировал alex977 - 15.1.2009, 18:18

[Novak]

в смысле последние?

Последние обновлённые файлы переводов из наших проектов делаю первыми при передаче. Таким образом должны переводы исправляться.
Имхо, Алекс прав, дальше будет всё меньше тех сегментов, что обновляются. Это будет касаться только исправлений. Потому ни о каких 200000 речь не идёт. И тмх файл я вручную не правлю. Говорю же, Омега берёт идущий первым вариант перевода, остальные выбрасывает.

У нас есть свн, потому восстановить какой-либо перевод не составит труда, так что пока у нас приемлемая в плане траты усилий схема работы.
Не нужно бояться ошибок, они будут, от них никуда не деться. Главное - их исправлять. Так что всё будет хорошо)

[alex977]

Вопрос.

У себя в файле tmx (вручную) я исправил ошибку. К примеру, заметил слово "фукнция" и исправил на "функция". После объединения файла ошибка опять появилась. :-(

Проблему я вижу в том, что если мною был отредактирован какой-то сегмент, а у кого-то он остался в старом варианте, то нельзя предугадать - попадет в объединенный файл исправленный вариант перевода или же останется исходный, а все исправления будут отброшены. Разумеется, можно восстановить из версий, но из-за одного сегмента...

Может быть тогда вообще не трогать сегменты где уже есть перевод - даже если есть ошибки/опечатки?