When you start KAider 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 pairs english-target strings (these pair 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> to switch between views when they are stacked into tabs, or Alt+Q to imitate pressing of 'Query' butten when WebQueries view is open.
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.
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 KAider 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.
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 KAider 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 KAider opens file and there is no project loaded, it will search for project file in file parent directories (up to 4).
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.
KAider 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.
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) sequence in the Glossary view and insert it by pressing a shortcut.
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
My measurings (ps aux) show that KAider consumes 20 to 30 mb of ram (kdelibs.po + project is loaded and all other views are shown).
Remember that project and glossary can be shared between KAider windows
The speed of parsing .po file is 1mb per second on my 1.8Ghz Athlon XP (512 mb ram).