Lokalize for Windows and OSX with spellcheck

New Lokalize builds for WIndows 7+ and OSX 10.9+ with spellcheck available (both 64-bit):

win mirror 1 win mirror 2
osx mirror 1 osx mirror 2

Lokalize will use spell dictionaries installed with LibreOffice 5 (please install it in default location), also on OSX few system-shipped dictionaries will be used for spellcheck, but for glossary stemming feature you still need to install LibreOffice with at least English dictionaries.

If windows build fails to start saying msvcp140.dll is missing then install this microsoft vc2015 redistributable

Unfortunatelly full open source OpenDocument translation toolchain (get .odt -> extract strings into .xlf -> translate it -> merge translation back into .odt) is unusable at the moment because of bug #3239.

Qt's DOM whitespace specifics

So I've just finished writing xliffmerge scipt that is direct analog of msgmerge@gettext and pomerge@translate-toolkit, but specially for XLIFF, i.e. it leverages all the advantages XLIFF brings, like saving information about each template update, specifying tha phase in which each unit was modified last time, and so on.

I was surprised to find out that translate-toolkit parses XML files into its own internal representation, which means they loose everything they don't support.

So to do it in a nice way, I chose to work directly with DOM representation of XLIFF file (using QDomDocument and friends). In Lokalize XliffStorage class is just a wrapper around QDomDocument.

I enabled preserving the whitespace, but in some cases it added additional whitespace, which means it modified user-editable text. The cases were clear: when no character data is between tags, it 'formats' them: inserts newline character + indent spaces. To override this behaviour I just added insertion of empty text nodes between tags. You can see the code in the end of xliffmerge.py (fixWhiteSpace*())

Lokalize screencast time

I did quite a few things during the last week.

In particular I finished implementation of storing XLIFF inline markup in translation memory and made autosubstitution mechanism more robust. Also I added support for binary units and displaying alternate translations (stored in xliff or from external file -- esp. useful for gettext po files which don't support storing alternate translations in the same file).

A screencast

Lokalize enforces workflow

Last week I added workflow phases support to Lokalize (XLIFF only). A person defines his/her role in the project [settings], and then corresponding phase is created automatically when file first changes (an old phase opened by same person is reused if found).

You may list phases, create them manually as well as add notes to them.


Also I added xliff extended states support. I did this in a smart way - there is still two-state button, which selects extended state depending on kind of the current phase (needs-translation/translated for translation phase, needs-translation-review/signed-off for review phase),
with drop-down menu to select specific state manually.

So what for translator is ok (translated), for reviewer is not (i.e. rendered in italics), and needs to be signed-off.



This allows us to achieve something interesting: we now able to see in which phase (and hence by whom) the translation unit was modified last time. This info is shown in Metadata toolview (previously known as 'Message Context').

First results implementing OpenDocument translation workflow

This is how OpenDocument translation workflow will look like in KDE 4.3: Screencast

Don't try to do it yourself right now ;) This requires the latest (unreleased) versions of translate-toolkit trunk and kdelibs trunk.

Implications of achieving this
I plugged kross nicely into Lokalize: I introduced 'project kinds' -- each has it's own set of scripts, so that you have 'Merge into ODF' for OpenDocument translation, and 'Widget Text Capture' for GUI/KDE projects.

These actions, as well as few others (see kde l10n svn and kde ru l10n svn for their plug example) are written in python. I plan to create a separate scripting API docs for Lokalize, but for now you can just rgrep Q_SCRIPTABLE KDE/kdesdk/lokalize to get list of available methods.

This mechanism will make implementing business-logic easy. Examples are action to send your translation to project's editor (translation team leader) and action to commit your work to [svn] repository if you have write access to it.

Thanks
I want to say thanks to Sebastian Sauer for giving me the green light for kross-extending commits, and Wynand Winterbach for commiting the patch to translate-toolkit.
Once I've got the thanks section, I'd also like to mention NLNet Foundation which funds my current efforts and KDevelop team, which makes those efforts efficient (today I opened whole kdelibs in KDevelop, and it took 15 minutes and 0 crashes to scan it completely ;) )

Comment your translations

It it sometimes useful to leave a note for an individual translation (for example when you're unsure about some term). Since some time ago scripty (a daemon which updates KDE translation files to reflect the current state) started to preserve comments in GETTEXT PO files. XLIFF standard supports notes too. So this week I was addding notes support to Lokalize.

Notes mechanism may also be used for bookmarking, as Lokalize now allows quick searching including notes (I added 'options' button to set additional filtering critera). Check this out on the video.


I wrote a simple python-based action to merge translated XLIFF file back to .odt document. Next week I'll be writing patches for traslate-toolkit to support on-the-fly conversion and filling <file origin""> attribute, and now I'm preparing a patch for Kross to help me make organizing project-specific scripts easy.

I also added UI reflection of 'recovered from autosave' state. You'll need kdelibs>=4.2.1 for autosave to work properly though.

Compiling Lokalize from trunk under KDE 4.2

XLIFF markup editing in Lokalize

Please correct me if I'm wrong, but today Lokalize became the first open source tool to support XLIFF inline markup editing.

I tried the latest svn trunk revision of virtaal, but it didn't display markup and mangled my test XLIFF file. AFAIK inline markup editing in proprietary world is only supported by Java Heartsome l10n Suite.

But this of course would mean nothing w/o Translate-Toolkit's (same laboratory as Virtaal's) odf2xliff converter, which will be integrated into Localize thanks to KDE's kross technology ;)

Obligatory screencast.

My plans also include support for inserting markuped text from other entries and translation memory (Lokalize will have to match tag id's for that).