Projects/Summer of Code/2007/Projects/KAider/Introduction: Difference between revisions

From KDE TechBase
No edit summary
Line 1: Line 1:
KAider was renamed to Lokalize. See also [http://docs.kde.org/development/en/kdesdk/lokalize/index.html official documentation @ docs.kde.org]
==New Translator's Intro==
==New Translator's Intro==
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.
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 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.
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 first multiline edit is to display original part of the pair.
Line 23: Line 25:
If the option is specified, it also saves previous string in comment field.
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,
So when Lokalize encounters this previous string in the translations (.po) file,
it displays word-by-word difference betwen old and new strings.
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.
This enables translator to easily see what has changed and make the appropriate change in the translation.
Line 30: Line 32:
I've implemented basic framework for translation projects.
I've implemented basic framework for translation projects.
Currently it displays file tree with statistics like percentage of translated messages and last translator.
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
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).
(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.  
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).
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===
===Operations on multiple files===
Currently Kaider supports only searching in multiple files.
Currently Lokalize supports only searching in multiple files.
Select items you are interested in, choose "find in files" from context menu.
Select items you are interested in, choose "find in files" from context menu.
The first match will be displayed in usual KAider 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.
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 KAider editor window resets multiple files searching state.
Ctrl+F in Lokalize editor window resets multiple files searching state.


==Merge Mode==
==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.
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.
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.
Open base file, then drop its changed version onto mergeview, and use ctrl+alt+pgdown/pgup to navigate through changed entries.
Line 55: Line 57:
Now you will only have to find the (frequent) word sequence in the Glossary view and insert it by pressing a shortcut.
Now you will only have to find the (frequent) word sequence in the Glossary view and insert it by pressing a shortcut.


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


==WebQuery==
==WebQuery==
Line 66: Line 68:


==Performance==
==Performance==
My measurings (ps aux) show that KAider consumes 20 to 35 mb of ram
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).
(kdelibs.po + project is loaded and all other views are shown).


Remember that project and glossary can be shared between KAider windows.
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).
The speed of .po files parsing is 1mb per second on my 1.8Ghz Athlon XP (512 mb ram).

Revision as of 08:35, 1 April 2008

KAider was renamed to Lokalize. See also official documentation @ docs.kde.org

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).