Starting the Actual Translation

Start your translation with the graphic user interface (GUI), preferably using Lokalize. First translate the files in messages/frameworks because its contents are spread over most KDE applications, providing the text of their standard menus. The files desktop_frameworks.pot and desktop_l10n.pot which are responsible for the stuff in the Application launcher menu. Then go to the applications in messages/kde-workspace. 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/frameworks. 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/frameworks/ 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.)

    Note

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