Bringing a New Language to KDE

First Things First...

Before doing anything else, get on the mailing list for translators and documenters (either via the web page or by sending a mail with "subscribe" in the subject and the body to kde-i18n-doc-request@kde.org). This mailing list is being archived with the others at lists.kde.org. (See the corresponding part of the appendix for more details.)

Second: Take a look at the list of languages and coordinators in KDE.

What follows depends on whether your language is listed on that page or not.

  • If your language is listed, simply write to the coordinator(s) of your language team and ask him, her, or them how to proceed.

  • If your language is not listed, post a message to the kde-i18n-doc mailing list asking if anybody is already working on your language or would be willing to join your effort.

Taking a Look at Available Resources and SVN

  • Read this Translation HOWTO entirely, especially the section on GUI translation in KDE.

  • Find out how to install KDE and then just do it. Although you can theoretically do your translation work for KDE under an older version than the one the translation is meant for, it is better and recommended to have the needed version on your computer for at least testing purposes. Check out the HOWTO section for assisting documentation on this subject.

  • Make sure you have the GNU gettext package installed and start to get familiar with it. You have to install version of gettext >= 0.17. At least have a good look at its Info pages. (Remember: the KDE on-line help provides a very convenient way to read this kind of documentation.)

  • Take a closer look at the programs, scripts and statistical aids which will help you with translation. You will need programs and tools that can handle the UTF-8 encoding, at least for the GUI translation. The recommended tool for making translation is Lokalize.

  • In case you have never heard of SVN (in full: Subversion): it is a version control system for directories and files. In the case of KDE (as for many other open source projects), it is used so that files and directories may be created, modified and removed by different users over the Internet. In KDE, the name "SVN" or "KDE SVN" primarily refers to a server called "svn.kde.org" where the translations for KDE are stored. People with a SVN account have a local client setup on their own computer corresponding to this SVN server which creates local working copies of the source tree on the remote machine. This local SVN client also allows them to merge e.g. new translations back into the remote source tree system.

    If your team reaches the essential requirements or there is the need in committing files by yourself, you should apply for commit account. Please see the tutorial for how exactly to do it correctly.

    It is suggested that only the team leaders have commit accounts, but, of course, it can be more than one if your team needs them.

    If you do not know SVN, or if you do not know it well, probably you want to read the handbook about SVN, which is available online: Version Control with Subversion, it might be part of the documentation of SVN packages that you have or are going to install on your system. (The book is also available as "hardcopy" in bookshops). Of course, as you will only use SVN and as you plan neither to program nor to administer SVN, you do not need to read and understand all chapters of the book.

    The main commands of the svn client are:

    • svn checkout (for getting something from the remote system to your local repository),
    • svn update (if you just want to refresh already existing stuff on your local system),
    • svn add (to add new files and directories as being),
    • svn remove (to remove new files and directories as being),
    • svn copy (to copy files),
    • svn move (to move files)
    • and last but not least, svn commit (to "register" your work back in the remote system. This is a process named "committing").

    Among other graphical front-ends we mention kdesvn. There is also the svn Dolphin plugin (part of the dolphin-plugins project), which gives some SVN functionality, for example in Konqueror and Dolphin.

Translation sources of GUI strings

The translation of a GUI string can have 4 different sources:

Qt

As Frameworks, Plasma Workspace and all Applications are build upon the Qt libraries, you need the Qt translations for your language to have a fully localized GUI. Therefore go to Qt Localization and check if your language is already translated.

Frameworks
Frameworks are addon libraries to Qt which provide a wide variety of commonly needed functionality. These libraries with their translations are used in Plasma Workspace and all Applications.
Plasma Workspace
Applications and application libraries
Any other folders that are not Frameworks nor Plasma in l10n-kf5/$LANGUAGE/messages/

Starting the Actual Translation

Start your translation with the graphic user interface (GUI), preferably using Lokalize. First translate the files in the kcoreaddons, kio and kxmlgui frameworks because its contents are spread over most KDE applications, providing the text of their standard menus. Then start translating the applications you most use :). You will find a thorough explanation of how to do this in the section on GUI translation. But it will not hurt to see the important steps being listed here as well:

  • Download the template files in messages/$project$. You can do this for example using WebSVN and download the latest revision.)

  • Save these files with the extension .po to a local directory on your computer. (All translated GUI files end in ".po" whereas the originals end in ".pot" which means ".po template".)

  • Start translating. (Taking a look at the GUI section of this HOWTO and at the work of other translators could be useful now and then.)

  • When you are finished with translating some files, test your work with msgfmt --statistics --check-header filename.po.

Most of the above things (from correct transformation of .pot to .po files to the syntax check) are done automatically by Lokalize. Since in recent versions it has probably more useful features than any other free translation program in this area it is now the recommended tool for KDE GUI translation.

  • When you are ready to send your first files, write a short email to the kde-i18n-doc mailing list without attaching the files. Somebody will answer that you can send him the files, so that he can process them. This person will create a new directory for your language (l10n-kf5/$LANGUAGE/).

    This person will also create subdirectories for PO files (and, if already necessary, for documentation) and commit your first translation to the KDE code via SVN). After this, committing the translations, creating new directories and so on will be your own responsibility (i.e. the responsibility of the language team coordinator). After your language is in KDE SVN, you should probably ask the kde-i18n-doc mailing list how to proceed for being listed on the team page (if you are not listed yet) and how to create a "component" for your language in KDE Bugs, KDE's bug database.

    Furthermore you need to check if an kf5_entry.desktop file in l10n-kf5/$LANGUAGE/messages/kconfigwidgets/ has been created by the person having made the first commit of the new language. If the file is still missing, you will have to create it. This entry.desktop needs only to contain the following two lines:

    [KCM Locale]
Name=Add_here_the_name_of_your_language_in_American_English

    The syntax of the language code in KDE is nearly like the one described in RFC 3066, especially section 2.3, except that KDE uses a underscore character (_) rather than a dash (-) (e.g. KDE uses en_GB for British English while RFC 3066 would use en-GB). Most often using RFC 3066 means using the 2 letter code for languages from ISO 639-1, e.g. de for German, fr for French. (See Wikipedia's article about ISO 639.)

  • Gather a team of co-translators (if you have not already), distribute the tasks and start building an effective "infrastructure" for your work. First of all []{#mailinglists}make up a mailing list and a web site for internal use by your language team. You can get both from KDE although it will be somewhat basic stuff. If you are interested, contact the kde-i18n-doc mailing list. After organizing these things, you may want to take a look now and then into the "practical hints" section of this HOWTO.

  • If GUI translation is well under way and everything else in your team seems pretty much organized, you should start documentation translation. This HOWTO only provides a short overview to let you know where the journey will be going.

Where to Go From Here: Some Practical Hints

This section is a collection of hints and tips that proved helpful in real world translation, team work, building an infrastructure and so on for several language teams. For the most part, it is up to you if you want to make use of these recommendations.

Many things in this section have to do with "consistency" in one way or another. This is a main consideration for a desktop system that is trying to keep its look and feel as unified as possible. Similarly, all programs should use the same translation terms in GUI and doc translation. At the same time, achieving this kind of consistency is one of the biggest challenges for writers and translators in projects like KDE.

As always: if you think something should be mentioned in this section but you cannot find it yet, please ask the kde-i18n-doc mailing list. (Even better: send a patch against the DocBook version of this document at kde-doc-english mailing list.)

  • Do not work in isolation. Be as responsive as possible to your team and to the rest of KDE. If you know that you will not be reachable for a while please let others know via your team site or your team mailing list. If you do not have enough time for coordination any more please find another coordinator or a co-coordinator. Do not cling to the "title". Your work will usually only succeed as a team effort. Just as KDE as a whole.

  • If your team has more than one coordinator it is often a good idea to let people know who is mainly responsible for which areas (for examples: PO files, docs, web site, user feedback, bug reports) or who is generally the main contact. And please: if there are some unsolvable discussions inside your team about organizational questions, keep them internal or apply to KDE e.V. Community Working Group for the referee.

  • "Do not work in isolation" also means: Talk to your co-translators about what your translation should look like and what your target groups are. If your translation is for "ordinary users", including business people, it will look very different from a translation that is made for computer specialists. (Normally, KDE is not considered to be something that is "made only for geeks".) In any case: try to develop a style guide for your team.

  • Find standard translations for standard elements and stick to them. The archived PO translations (also known as "compendium files") at https://l10n.kde.org/team-infos.php?teamcode=<$LANGUAGE> will be very helpful in this respect, as will specialized translation programs like Lokalize that either allow you to search these files or provide comparable means to help you with consistency checking. Also make good use of word lists and dictionaries and mailing lists. You can also use search and compare facilities of the KDE site itself.

  • Develop a system of "mutual proofreading" to make sure that everybody involved sticks to the rules. This can be somewhat delicate at times (so do not be too argumentative;), but since this also provides your best means of correcting spelling mistakes and stupid errors you will have to set up such a mechanism anyway, at least in the long run. In this sense, you can find very useful the collection of scripts called Pology. Please refer to the documentation inside the scripts to learn more.

  • It may be a good idea to have the same person do the GUI translation and the translation of the on-line help (i.e. the documentation) of a given program. If this is not possible, the person who does the final proofreading of the documentation, the screenshots and so on should be allowed to make corrections to the PO files as well, ensuring that GUI and on-line help are "speaking the same language". It is extremely confusing to the users if the terms in the documentation are different from the terms in the actual menus of the same program.

  • Never commit a file to SVN without doing appropriate syntax checks as pointed out in the respective sections on GUI and doc translation. Again, the use of specialized programs (like Lokalize and Pology for POs of the GUI and Doc Translation) is highly recommended since they provide mechanisms for syntax and other checks.

Getting Credit for Your Work

Most people in free software do very good work without any payment. Nevertheless, they would like to see some acknowledgment of that work. In KDE translation your work can be acknowledged in the following ways:

  • In the Help->About box of the translated program

  • In the "credits" section of translated documentation

With regard to the "About" box in the help menu: The name(s) and email address(es) of translators are getting there by filling in the following strings in the respective PO file:

#: rc.cpp:43
msgctxt "NAME OF TRANSLATORS"
msgid "Your names"
msgstr ""

#: rc.cpp:44
msgctxt "EMAIL OF TRANSLATORS"
msgid "Your emails"
msgstr ""

If there is more than one translator make up a comma separated list without spaces (translator1,translator2,translator3). Same goes for the mail addresses. If you do not know an address leave the field empty (address1,,address3). It then would look as follows:

#: rc.cpp:43
msgctxt "NAME OF TRANSLATORS"
msgid "Your names"
msgstr "Translator One,Translator Two,Translator Three"

#: rc.cpp:44
msgctxt "EMAIL OF TRANSLATORS"
msgid "Your emails"
msgstr "translator.one@some.domain,,translator.three@another.domain"

For info on the credit section of translated documentation please see the respective step-by-step instruction.

Article contributed by , , and 1999-2002 Thomas Diehl thd@kde.org under the GFDL-1.2-or-later license.