Start your translation with the graphic user interface (GUI), preferably using KBabel set to "UTF-8" (8bit Unicode Transfer Format). First translate the file kdelibs.pot
because its contents are spread over most KDE applications, providing the text of their standard menus. Continue with desktop_kdelibs.pot
and desktop_l10n.pot
which are responsible for the stuff in the K menu. Then go to the applications in kdebase. 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 kdelibs.pot
, the template file for all translations of kdelibs. (You can do this for example using
WebSVN
and download the latest revision.)
Save this file as kdelibs.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 kdelibs.po
, test your work with msgfmt --statistics --check-header kdelibs.po.
Most of the above things (from correct transformation of .pot to .po files to the syntax check) are done automatically by KBabel. Since it also handles Unicode while many text editors do not it is now the recommended tool for KDE GUI translation. Apart from the fact that in recent versions it has probably more useful features than any other free translation program in this area.
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/$LANG/). 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 procede 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 entry.desktop file to l10n/$LANG/messages/ 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.)
In the rare case that your language would not have a code according to RFC 3066, e.g. if your language is a small regional language, you are recommend to register it at IANA according to the procedure described in RFC 3066, especially section 3. If for any reason, you do not want to register your language at IANA, you must use a language name staring with x- (the letter x and a dash).
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 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. (The list server will not accept many commands and the web site does not allow CGI yet.) Anyway, if you are interested, contact the webmaster of the i18n-server. 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. You will find the basic information on the documentation site of the i18n server. This HOWTO only provides a short overview to let you know where the journey will be going.
An overview of the progress GUI translation teams are making is provided on the Status table of KDE Translations for the trunk branch. Based on its data the decision is made which languages will be part of a KDE release and which will be not. The official rule for release versions says around 90% of kdelibs.pot, 100% of desktop_kdelibs.pot and desktop_l10n.pot and around 75% of kdebase should be translated in order to get into a release. (See the Essential Statistic.) But, usually, it is up to the team coordinators to decide when their language is "ready for release" and to report it as such to the people in charge of the release.