Up till now OmegaT users who translated .docx documents infested with nasty tags needed to turn to a third-party solution to clean the files. There are a few very good and not so good ones out there: Continue reading
OmegaT is just an excellent translation tool, but there’s still some room for improvement when it comes to using it for revising translated materials. I really hope that in future what I’m about to present in this post will become completely obsolete, but for now it might be welcomed by people who needed to mark segments with different status markers.
A big shout-out goes to Marc Prior for coming up with the idea and backing up the development.
OmegaT has a great safety feature: it automatically backs up project memory files (i. e.
project_save.tmx) on every project (re)load, plus it creates another backup file on every save (if the project was changed since the last load or save). Those backup files can be used in an extremely rare case when something happens to the main project memory and all of the work seems to be lost. It happened to me once when I was only starting to use OmegaT as my main tool, and was I glad this backup feature was thought of!
But this very feature can become a tiny problem, especially in ongoing projects where
project_save.tmx keeps on growing bigger and bigger. While creating backups is great and very helpful, there’s no routine to remove old backup files. It isn’t uncommon in some of the projects that I work at that
project_save.tmx is a few MB’s, but
omegat folder where that file is located, is over 100 MB’s or more, and only because of all the backups. With modern disk sizes it’s not a big deal, and it doesn’t degrade OmegaT’s performance a bit, but sometimes there’s a need to make a project slim again (like when you’re going to send it to your colleague or client, or copy it to cloud storage or another computer, or you’re obsessed with keeping everything trim and slim and tidy).
So, anyway, after all these numerous words here’s what I’m getting at. At Sourceforge.net (download link) there’s this script that removes all the backups of
project_save.tmx (including the ones created in team projects before performing sync), everything in target folder (as usually in the projects that need this cleaning, source files are changed, but old target files sometimes just keep on piling up), and also three TMX files created in the root of the project every time target files are produced.
About a year ago I put together the original version of this script, but this new version downloadable from Sourceforge.net contains a few improvements and can easily be localised if you care to be warned about file deletion in your language.
Use it to your heart’s content and your own risk, and I’ll be very thankful for any questions, suggestions or comments.
DISCLAIMER: If you lose your work without any hope to recover because all backups have been deleted by this script, it ain’t my fault. You should backup regularly and not hope that OmegaT will do it for you.
But as of now,
Today I’m sharing a new take on fixing bloated SVN-based OmegaT team projects.
This post is about a script that exports OmegaT project to an XLS document with a separate worksheet for each source file. Continue reading
One of the complains OmegaT gets is impossibility to split and merge segments without editing projects’ or global segmentation rules. There were a few attempts to address the issue, but they required a third-party utility that would edit
segmentation.conf. One of the most recent attempt was Dimitry Prihodko’s Merge utility. If I understood it right, Dimitry asked Yu Tang to rework his thingy, and Yu Tang came up with a Groovy script that did all the merging using only OmegaT internals. It wasn’t limited to any OS or dependent on other tools (so much for hard Pascal coding, Dimitry). There was only a minor issue that the script couldn’t be used to split segments. And that’s what I’ve added and what I’m sharing here. Continue reading
Sometime ago my monkey approach to programming led me to creating a GUI for QA rules checking script. That was fun, the result was sometimes even usable, but since I don’t really know how to program, I got stuck with developing it. Ok, a rule or two was added now and then, but that doesn’t really count. But then all of a sudden the spellcheck script in OmegaT got drastically improved, and that meant I could mimic some new ideas. That’s exactly what I did, and here’s the new “QA – Check Rules” script:
This script is variation of the one published before that exports all notes in the current project. The only difference is that this one allows you to select which notes will get exported based on the first line of the note. The resultant HTML table will consist of four columns: Source, Target, Filtered Notes (adjustable heading name), and Reply.
Say, you want to be able to export only the notes that start with
<query>, as you’ve been using this word (
<query>) to mark your questions to the client. In order to do so, go to line 14 and specify which mark-word was used. Note: The mark-word used to filter notes should be found in the very beginning of the very first line of the note, otherwise it’ll be ignored. In line 15 you can specify the column heading.
Here’s a new script that lets you export OmegaT project notes to a HTML table. It may help you to discuss different translation issues with the client/editor/your spiritual guru or review your own translation if you use notes for yourself.
When the script is invoked, it will create a file named
/script_output subfolder of the current project root (the subfolder will be created if it doesn’t exist, and PROJECTNAME is the actual name, of course).
I’m back with another little script that might be pretty handy for those who need to work on the same material in different CAT tools, or for translation agencies who use OmegaT as their main CAT application but farm out the work to translators using their CAT tools of choice. As a matter of fact, the script was requested by translation agency Velior for this very reason.
When the script is invoked, it writes out a file named
PROJECTNAME.xlf (PROJECTNAME is the actual name of the project, not this loudly yelled word, of course), and the file is located in
script_output subfolder of the current project. It exports both translated (they get “final” state in the resultant XLF file) and untranslated segments, and for untranslated segments the source is copied to the target, and such segments get “needs-translation” state. OmegaT segmentation and tags are preserved. Tags get enveloped in <ph id=”x”> and </ph>, so that they are treated as tags in other CAT tools. Continue reading