Usually program messages and documentation are written in English. Using a framework made of a set of tools and libraries, it is possible to have your favorite applications speak your native non-English language. This process of adapting an application to a specific language is known as localization. The localization process includes translating the program's interfaces and documentation to the various languages users need and, in some countries or regions, making the inputs and outputs conform to particular conventions. &kbabel; is a tool which will assist you in the localization process to make an application's interface speak many languages. Every internationalization-aware program makes available for translation one or more message-catalog files. The extension of these files is .pot. POT is an acronym for Portable Object Template. Each translator takes a copy of one of these POT templates and begins to fill in the blanks: each message is translated into the language desired. The file containing the translated text is referred to as a PO (Portable Object) file. Once all the messages have been translated, the PO file is compiled into a machine-readable binary format, known as a MO (Machine Object) file. These files, which will be stored with a .mo extension (or a .gmo extension to show that they were processed by &GNU; gettext), act as a database to minimize the time taken by the applications to look up each translated message. This suggests a question: do I need to know what is inside a PO file even though I have &kbabel;? The answer is, undoubtedly, yes. There are situations when a message catalog can become corrupted and needs to be manually fixed. Most of these problems are the so-hated CVS or SVN conflicts which occur when a translating process is coordinated by a version management system, like CVS or Subversion (SVN). &kbabel; cannot help you much if a problem like this arises so a text editor and some knowledge of PO-files are needed. Let's see how a PO file is made. PO files consist of pairs of messages—a msgid and a msgstr. The msgid is the text in English and the msgstr is the text translated into the appropriate language. The text that accompanies each msgid and msgstr is enclosed within C-like double quotes. An example, taken from a PO file for &noatun;, is msgid "Open a Playlist" Empty lines and those starting with # are ignored. Lines starting with a # represent comments and are a useful way of providing a note detailing which file this message is going to be used in and, in the case of the application writers, to provide additional comments to help translation. &kbabel; displays these comment lines for every message. In many cases the first msgid-msgstr pair in PO file is a fake entry (acting as PO file header) that contains various information about the translated PO file, such as the application name, translating date, translator name and so on. An useful feature is called plural forms. English uses only singular and one plural form of nouns, ⪚ 1 file and 10 files. This leads many developers to an idea that the world is that simple and they can use messages like Do you want to delete %1 file(s)?, where %1 denotes a number of files to be deleted. But this is fundamentally wrong and for many languages such a kind of translation will not work. For Slovak translation you need 3 different forms of the message. This number is different for different languages and even when it is the same, ⪚ Czech uses 3 forms as well, the rule to decide which form to use can be very different. Plural forms in PO files are here to help. &kde; developers have chosen a different implementation for the plural forms than &GNU; gettext and they have introduced their own format and handling for them. It is planned to use &GNU; gettext's plural forms in &kde; version 4. Here is a screenshot of &kbabel;. Screenshot of &kbabel; Screenshot of &kbabel; For convenience &kbabel; has toolbars to speed up many operations and, for busy users, there are many keyboard shortcuts. The main window is divided into four parts. The upper-left edit box is read-only and contains the current msgid field from the opened PO-file and its English text. The bottom-left edit box contains the msgstr field related to the msgid shown and here you can edit the translated text. The top-right part of the window is a comments panel where you can view the comments added for entry currently being edited. It can be used: to find out how the current message is treated by the application (c-formatted or simple) in some cases, to read helpful comments added by the application's developer to assist the translators in their work—for example, there may be technical hints (used to great effect in the LyX project) when you need to know which file a message is from because you want to report a spelling mistake in the original English string. The editor window (in the bottom right) is the most sophisticated part of &kbabel;'s main window. Its size can be adjusted using the splitter line between it and the comment panel (the panel in the top right). The editor window has two tabbed panels—one storing search information, the other context information. The context information tab contain a scrolled view which shows the previous and next 4 entries associated with the current entry—essentially it's a small 'snapshot' of the PO file. While translating, it is very common for message strings to be related to subsequent and previous messages, so the context panel is useful for looking at the nearby messages to get a hint as to how the current message can best be translated. Dialog interface translation is a good example, or widgets with their associated text and "what's this" message. Each msgid entry can be in three states: untranslated there is no translated text currently associated with the msgstr fuzzy msgmerge has tried to match a translated string by looking in rest of PO-file entries. This does not work perfectly and you must edit the translated text to fit the current English text. translated the msgid is the completed translated form of the msgstr The state of the current entry is indicated by two LEDs. Depending on your configuration these can either be in the status bar or above the translated string edit box. Both have a customizable color (to reflect your visual requirements or taste). Please read the Preferences section to see how you can adjust these settings. 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 Go 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 Highlight background and/or Mark whitespaces with points 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 ToolsRough Translation and &kbabel; will present the following dialog: Rough translation 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, &ie; 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 Move Up and Move Down 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 Start to automatically translate messages. You can follow the progress bar and in case, there is always the Stop 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 Tools Validation. Then the check is performed for all messages in the file and faulty ones are marked as errors. Check Syntax 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. Check Arguments Incorrect translations can crash the application. The most dangerous parts of translation are arguments, ⪚ for printf-like functions. This check compares the number and types of the arguments in msgid and msgstr. They must match. Check Accelerators &GUI; text commonly contain accelerators, &ie; letters which can be used for fast access to &GUI; elements by keyboard. They are denoted by special character, ⪚ & 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. Look for Translated Context Info 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. Check Plural Forms 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. Check Equations 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, ⪚ 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 ToolsSpelling submenu. You can use a number of modes for spell checking: Spell check... 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 . Check All... Spellcheck all messages in the file. Check from Cursor Position... Start spellchecking at the position in the current message and progress towards the end of the file. Check Current... Spellcheck the current message only. Check Selected Text... 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 Edit: Insert Next Tag 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. Edit Insert Tag 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. Tools Diff Show Diff will show the differences found. To see the current text without the mixture of original text and differences, use Tools Diff Show Original Text . You can turn automatic lookup of difference on and off by choosing Tools Diff Diff Mode . 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: Translation Database 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. Tree of the old files 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. Manually chosen file If the previous possibility does not work, correctly, you can always set the difference file manually by choosing ToolsDiff Open File for Diff. The difference lookup is not always accurate, because the PO-file does not contain any reference to the original message. Because plural forms are quite a complicated issue, we devote a special section for their support in &kbabel;. This section handles about &kde; plural forms (to be precise of &kde; version 3). From &kbabel; version 1.11 (KDE 3.5) on, &kbabel; should be able to read, edit and save the &GNU; gettext plural forms too. Every language to which &kde; is translated must have set a correct number of plural forms. This is done by translating a specific entry in tdelibs.po. The number is set by selecting the name of a language, which uses the same number and rules for finding the right plural form. The up-to-date list of possible values can be found in the tdelibs source code, in the file tdecore/tdelocale.cpp. &GNU; gettext allows to define the number and type of plural forms by a formula and to set this formula independently for each PO file. &kde; can only define the number and type of plural forms one time in tdelibs. &kde; plural forms are denoted by comment _n: (including a trailing space) containing the %n argument. This argument is then used in the message itself and it controls which plural form of your language should be used depending on the rules for your language. The translation of a plural form message has to have a special format. It must contain the correct number of translations (one for each plural form) separated by an end of the line \n, without any _n: sequence (without the space either). For example, _n: Selected 1 file\nSelected %n files translated to Slovak would be: Vybraný %n súbor\n Vybrané %n súbory\n Vybraných %n súborov To check if your translation contains the correct number of plural forms, use the Tools Validation Check Plural Forms (KDE only) menu.