Now you have an idea how to translate a PO-file. In this section we will follow the standard way of translating a new PO-file using the advanced features of KBabel. We assume you have already opened a template POT-file and saved it as a PO file.
KBabel allows you to easily navigate through the file according to the state of their translation. The untranslated/fuzzy status was introduced already. A message can be marked as erroneous as a result of validation checking or validation done by msgfmt. And, of course, KBabel supports browsing the history of visited messages with Forward/Back, like in Konqueror.
All commands for navigation are in menu.
Page Up | Move to the previous message |
Page Down | Move to the next message |
Ctrl+Page Up | Move to the previous fuzzy message |
Ctrl+Page Down | Move to the next fuzzy message |
Alt+Page Up | Move to the previous untranslated message |
Alt+Page Down | Move to the next untranslated message |
Shift+Page Up | Move to the previous error message |
Shift+Page Down | Move to the next error message |
Ctrl+Shift+Page Up | Move to the previous fuzzy or untranslated message |
Ctrl+Shift+Page Down | Move to the next fuzzy or untranslated message |
Clever editing means that the editor will help you easily edit the translation while taking into account specials of the PO format. It will correctly “escape” as necessary.
It also supports more than
one mode for inserting end of the line. This is very useful because of the way
gettext handles end of the lines. It simply ignores them. (You can imagine that
all the text in msgstr is a single line.) If you want insert a “real” end of the
line, you need to insert \n
. But most of translators
do not realize, that a new line in msgstr does not
add any space between the lines. This can be easily solved by adding a space
at the end of every line. But you can easily forget, so clever editing does this automatically
for you.
The table below summarizes clever editing features.
Tab | Insert \t |
" | Insert \" |
Enter | If the last character before cursor is not a space, insert one space. Then start a new line. |
Ctrl+Enter | Start a new line without any additional logic |
Shift+Enter | Insert \n and start a new line |
If you want to see where spaces are, you can turn on and/or in preferences dialog on tab Edit Appearance.
As the first step when starting a new translation, KBabel provides a function for automatic filling of the messages translations by the older translations. Choose -> and KBabel will present the following dialog:
In the dialog, you should specify what to translate and choose the sources for the old translations.
At the top of the What to translate frame are three checkboxes (Untranslated entries, Fuzzy entries , Translated entries) for specifying the kind of messages you want to translate. Untranslated and fuzzy entries are natural choices for automatic translation, but you can change already translated messages as well.
The exact matching for msgids will always be used for rough translation. However, you can add more strategies, that is, Allow fuzzy translation (slow) and Allow single word translation. Both of these additional strategies must be supported by the sources used (see below). There is no specification, what does “fuzzy translation” mean, but the purpose is quite obvious. “Single word translation” is suitable for only some of the languages. KBabel will try to translate each word in msgid separately and then put the translated words (or phrases) in the same order in msgstr .
As a source for rough translation, any dictionary module available can be used. There is a list of Don't use modules and Use modules. Modules are used in the order in the Use list. First module is asked for translation. If it is not found, next module in the list is asked and so on. You can use the buttons with arrows for moving modules between the lists. Don't forget to change the order to suit your needs by and buttons.
Normally KBabel will mark every roughly translated message as fuzzy, because it assumes that any automatic translation needs to be reviewed by a translator. If you are 100% sure that the automatic translation will be correct, or you will review all the translation anyway. Mark changed entries as fuzzy allows you to turn off this automatic fuzzy marking, but you will need to confirm this.
If you have set all the options to suit your needs, push to automatically translate messages. You can follow the progress bar and in case, there is always the button.
Everyone makes mistakes. So KBabel supports a number of checks for typical problems in translations. These checks (not syntax check) can be basically performed in two ways.
Checks can be done at each change of the translated text. These are called automatic checks and they can be turned on in the KBabel configuration dialog. Automatic checking of syntax is possible at each saving of the file.
The automatic checks can slow down KBabel. If you have a slower computer, you can turn off the automatic checks and use only the second possibility. You can invoke every kind of check from the ->. Then the check is performed for all messages in the file and faulty ones are marked as errors.
This invokes msgfmt to check validity of the PO file as seen by GNU gettext package. It will show the result of the command and mark error msgstrs.
Incorrect translations can crash the application. The most dangerous parts of translation are arguments, for example, for printf-like functions. This check compares the number and types of the arguments in msgid and msgstr. They must match.
GUI text commonly contain accelerators, that is, letters which can be used for fast access to GUI elements by keyboard. They are denoted by special character, for example, & in KDE. Typical requirement of the translation is that translated text should contain accelerator as well. This check will notice this problem for you. The accelerator character can be specified in Preferences on Misc tab.
You will probably need this only for KDE translation. Some of the text are too common
and they need to be translated differently in different contexts. In KDE the context
is described at the beginning of msgid after the special sequence
:_
. But if some translators are not aware of this convention
and they try to translate context information as well. This check will try to find these.
If the check founds translated context information, you should remove it.
If the msgid is specified as a “plural form”,
the translation has to contain the correct number of translations separated by
\n
. The correct number depends on the language of
translation and is specified on Identity tab in
Preferences dialog. This is implemented only for KDE at the moment.
Equations are special format of msgid typically
used in .desktop
files.
And because your translations will be merged back to these files, msgstr
must use this special format as well. This means that the translation must start (up to the
first occurrence of =
with the same text as the original message, for example,
Name=
.
As always, it is very important to spell-check your translation before using your result. This way you can find typos and other problems in your translation. KBabel uses the standard KDE library for spellchecking and its standard settings can be found in the project setting dialog. Spell checking itself can be found in -> submenu. You can use a number of modes for spell checking:
This is a generic invocation of a dialog where you can choose the spellchecking mode and set the default mode. This is invoked by pressing Ctrl+I.
Spellcheck all messages in the file.
Start spellchecking at the position in the current message and progress towards the end of the file.
Spellcheck the current message only.
If there is a selected text in msgstr editor, this option is available and will spellcheck this text only.
Markup languages are used more and more in GUI. KDE project also uses PO-files for translating DocBook documentation files (which is also a markup language). KBabel contains quite a lot of functionality to support this trend.
Here, we will describe only functions related to tags used for markup itself. The other problem introduced by using markup languages is translation of longer texts. This issue is addressed by the diff feature described in the following section.
The current version of KBabel is capable to find out which tags are used in msgid and provide an easy access to them using following actions from the :
This inserts next tag found in msgid to the translation. KBabel finds the tag to be inserted by counting the number of tags from the beginning of the translation.
This submenu contains all different markup tags found in original english string. By selecting a tag you can insert it at the current position of cursor in translated text. translation.
As explained already, current applications, trying to be user friendly, contain a lot of longer descriptive texts, including markup. If a developer changes a part of the text, the GNU gettext system will, in the best case, retain the old translation and mark it as fuzzy. (In the worst case you will lose the translation completely, depending on the size of the text changes). This works OK, if a msgid is short, because then you can find the changes quickly. But if the text is long enough, you will struggle to find out what has been changed (For example, it can be only an article change by proof-reading team.)
To help, KBabel can be asked to lookup the original msgid and to show the difference. The changes are graphically displayed in the Original String window. The exact method can be set in the KBabel configuration dialog. ->-> will show the differences found. To see the current text without the mixture of original text and differences, use ->->.
You can turn automatic lookup of difference on and off by choosing ->->. When the diff mode is on, difference searching starts when you go to another message.
As always, you can use different sources for finding the old version of the text, all being set in in KBabel configuration dialog:
You can use Translation Database for difference lookup. We strongly recommend to turn on the automatic storing of the newly translated messages into Translation Database in Translation Database configuration dialog. This mode can be turned on by Use messages from Translation Database.
This will be used only if searching in Translation Database is turned off. By setting Base folder for diff files you can navigate KBabel, which file to use for difference. It takes the relative path of the opened file and uses this relative path in the folder specified here. If there is a corresponding file, it will be used. To use this mode, you should make a copy of old files before each update.
If the previous possibility does not work, correctly, you can always set the difference file manually by choosing ->->.
The difference lookup is not always accurate, because the PO-file does not contain any reference to the original message.
Would you like to comment or contribute an update to this page?
Send feedback to the TDE Development Team