Projects/Summer of Code/2007/Projects/KAider/Introduction

KAider was renamed to Lokalize. See also official documentation @ docs.kde.org. See also Compilation and setup instructions

New Translator's Intro

When you start Lokalize with no arguments, you see two big multiline edits and a bunch of 'views'. They can be stacked (like tabs), shown separately or be hidden at all.

Translation file consists of many english-target pairs (these pairs are called 'messages'). They correspond to one separate string in user interface or one paragraph in documentation. KDE uses gettext .po file format.

The purpose of first multiline edit is to display original part of the pair. The purpose of second multiline edit is to display translation.

You can navigate through 'messages' via Catalog Tree view or using PgDown and PgUp. By the way. It is important that you get used to using keyboard instead of menu and toolbars, because this will increase you productivity. For example, use Alt+<underscored letter in the tab name> to switch between views when they are stacked into tabs, or Alt+Q to imitate pressing of 'Query' butten when WebQueries view is open.

Project development history

I've started the project in January when my exams have finished and worked heavily on it almost two weeks. During this time I incorporated kbabel code dealing with translation file representation, parsing and saving (improving, refactoring, cleaning and fixing it along the way). I enjoyed using KTextEdit, QUndoStack and KFind for implementing basic editing functions.

Then I had to stop developing it in favor of university and real life :)

My summer exams have finished on 20 of June and I have been back on the project again for full-time since then.

Original Diff

I began with nice support for data generated with msgmerge --previous option. When, during the merge (after change/update of material being translated), slightly changed 'original' string is encountered, gettext uses old translation, but marks it as 'fuzzy'. If the option is specified, it also saves previous string in comment field.

So when Lokalize encounters this previous string in the translations (.po) file, it displays word-by-word difference betwen old and new strings. This enables translator to easily see what has changed and make the appropriate change in the translation.

Project View

I've implemented basic framework for translation projects. Currently it displays file tree with statistics like percentage of translated messages and last translator. It allows to open selected file in the current or in the new Lokalize window (tip: use middle mouse button to open file in new window).

Project file defines dir with translations, templates, glossary filename and list of webquery scripts. All paths contained in it are relative. Whenever Lokalize opens file and there is no project loaded, it will search for project file in file parent directories (up to 4).

Operations on multiple files

Currently Lokalize supports only searching in multiple files. Select items you are interested in, choose "find in files" from context menu. The first match will be displayed in usual Lokalize window. Proceed with F3 (find next). If you press F3 and there are no matches left in the current file, the search will continue in the next file and so on. Ctrl+F in Lokalize editor window resets multiple files searching state.

Merge Mode

It is one of things that are easy to implement but save tremendous amount of time for editors, particularly when two translators were working simultaneously on the same file.

Lokalize allows quick navigation through messages that differ and (again) displays word-by-word difference.

Open base file, then drop its changed version onto mergeview, and use ctrl+alt+pgdown/pgup to navigate through changed entries.

Glossary

Have you ever become tired of typing the same long text sequence several times just because it would take more time to find its translation for copy-paste?

Now you will only have to find the (frequent) word sequence in the Glossary view and insert it by pressing a shortcut.

Also, Lokalize has handy glossary editor with explicit search over the whole glossary

WebQuery

The list of scripts is defined project-wise and local clientprogram-wise. See example script that works with google-translate and project file for it in l10n-kde4/ru directory

Translation Memory

Just drop your <lang>/messages folder onto TM View and wait ~5 minutes. Translation suggestions will be shown automatically on the msg entry switch. use ctrl+1, ctrl+2, ... to paste them.

Performance

My measurings (ps aux) show that Lokalize consumes 20 to 35 mb of ram (kdelibs.po + project is loaded and all other views are shown).

Remember that project and glossary can be shared between Lokalize windows.

The speed of .po files parsing is 1mb per second on my 1.8Ghz Athlon XP (512 mb ram).