The KDE Translation HOWTO ¶

경고

이 문서는 여러가지 요인(버전관리 시스템을 CVS 대신 SVN 으로 쓰는 경우, 새로운 i10n 모듈의 사용, 새 이름이나 새로운 쓰기 관습 등)으로 버전이 일치하지 않는 경우가 있습니다. 이곳에 있는 문서 내용의 번역을 어떻게 해야 하는지 모르겠다면 i18n-doc 메일링 리스트에 요청하시기 바랍니다.

GUI 환경에서 번역을 시작하면 K바벨을 UTF-8로 설정해놓고 사용하는 것이 더 좋습니다. 먼저 kdelibs.pot 파일을 번역합니다. 왜냐하면 그 내용이 KDE 응용프로그램 전반에 걸쳐 퍼져있으며, 표준 메뉴의 텍스트를 제공하기 때문입니다. K 메뉴에서 stuff에 대한 응답을 하는 desktop_kdelibs.pot 와 desktop_l10n.pot 를 계속하십시오. 그 다음 kdebase에 있는 응용프로그램으로 가십시오. 이것을 어떻게 해야 할지에 대한 전체적인 설명을 3장. GUI 번역에서 찾을 수 있을것입니다. 그러나 다음 목록에 있는 중요한 단계들을 잘 보는것이 문제가 생기지 않을 것입니다.

여기엔 번역과는 관련 없지만, 번역팀 팀장에 의해 결정되어야 하는 몇가지가 있습니다. 만약 동시에 새로운 언어가 새 국가에 대한 여러가지 내용 표시한다면, 가장 중요한 한가지는 기본 "지역화" 주제에 대한 관심입니다. 이러한 경우, 그 나라에서 통용되어 사용되는 국가, 날짜 형식, 시간, 숫자, 주소와 함께 국기와 다른 몇가지 설정을 KDE와 함께 공급할 수 있다면 이것이 정확합니다. 이 정보는 kdebase 패키지의 "l10n" 디렉터리에 저장되고 KDE 전역에서 사용됩니다만 제어센터의 데스크탑 부분에서는 특별히 쓰이지 않습니다.

주의 팁 주의 kdebase/l10n 안의 디렉터리들은 국가에 대한 것이지, 언어에 대한 것이 아닙니다. 따라서 코드들은 다른 의미를 가지고 있습니다. (심지어 예를 들어 프랑스어와 프랑스가 같은 코드인 fr을 공유합니다.) 국가에 대한 코드는 ISO 3166에 지정되어 있습니다. (위키피디아의 ISO 3166의 2문자 코드에 관한 기사를 보십시오.)

여러분의 국가에 대한 필요에 대해 KDE 지역화를 위해서, 여러분은 다음과 같은 것들을 해야 합니다.

• svn.kde.org로부터 kdebase/l10n 디렉터리를 확인하십시오. 그리고 kdebase/l10n 으로 이동하십시오.
• svn mkdir xx (주의: xx 는 국가코드를 의미하는 것이지 언어를 의미하는 것이 아닙니다.)
• cd xx
• cp /path/to/my_entry.desktop entry.desktop (이것은 필수적입니다. 그렇지 않으면 국기에 대한 이미지를 사용할 수 없을 것입니다.)
• cp /path/to/my_flag.png flag.png
• cd ..
• svn add xx/entry.desktop xx/flag.png
• svn commit xx
  
  

더 많은 정보를 보시려면 kdebase l10n 디렉터리에서 README 파일을 보십시오. KDE의 "l10n"에 대한 노력은 Hans Petter Bieker가 해주고 있습니다.

이 부분은 실제 번역, 팀작업, 인프라 스트럭쳐 등 몇몇 번역팀에서 입증된 도움이 될만한 힌트와 팁의 모음입니다. 여러 부분들에 대해 이 참고들을 실행하려 한다면 주의깊게 보길 바랍니다.

이 부분의 많은 것들은 한 방법 혹은 다른 방법으로 일관성을 갖고 실행되어야 합니다. 이것은 가능한 통일되게 보여야 하는 데스크탑 시스템에 대한 주요 고려대상입니다. 동일하게 모든 프로그램들은 GUI와 문서 번역에서 같은 번역 용어를 사용해야 합니다. 동시에 KDE와 같은 프로젝트에서 작성자와 번역자에 대한 최대 도전 중의 하나는 이 통일성의 한 종류를 이루는 것입니다.

이 부분에서 언급되어야 하는 무엇인가를 생각했지만, 찾지 못했다면 kde-i18n-doc 메일링 리스트에 요청해 주십시오.

자유 소프트웨어의 사람들 대부분이 아무런 댓가 없이 작업을 잘 해줍니다. 게다가, 그들은 작업의 몇몇 지식을 보기를 좋아합니다. KDE 번역에서 당신의 작업이 다음의 방법으로 알려질 수 있습니다.

• www.kde.org/credits.html 에 있는 KDE 인증 페이지에서
• 번역된 프로그램의 도움말->정보 대화상자에서
• 번역된 문서의 "인증" 부분에서
  
  

인증 페이지에 대한 고려와 함께 SVN 웹 모듈(www/credits/contributors)에서 파일로부터 HTML 페이지에 대한 내용을 얻을 수 있는 스크립트를 통해 이름들이 얻어지고 있습니다. 따라서 HTML 페이지뿐만 아니라 배포 파일들을 해야 합니다. 자세한 사항에 대해서는 같은 모듈안에 있는 README에서 얻을 수 있습니다. 번역자들의 이름을 등록하는 것은 각각의 언어 팀장의 작업입니다.

도움말 메뉴에서 "정보" 상자에 대한 고려와 함께 번역자의 이름과 이메일 주소를 각각의 PO 파일에서 다음의 문자열을 채움을써 얻고 있습니다.

#: _translatorinfo.cpp:1
msgid ""
"_: NAME OF TRANSLATORS\n"
"Your names"
msgstr ""

#: _translatorinfo.cpp:3
msgid ""
"_: EMAIL OF TRANSLATORS\n"
"Your emails"
msgstr ""

만약 번역자가 여려명이면, 공백없이 콤마로 구분하여 만들어 주십시오. (예: 번역자1,번역자2,번역자3) 이메일 주소도 마찬가지의 방법으로 해주십시오. 이메일 주소를 모른다면 영역을 비워두십시오. (예: 주소1,,주소3) 다음과 같이 쓸 수 있습니다.

#: _translatorinfo.cpp:1
msgid ""
"_: NAME OF TRANSLATORS\n"
"Your names"
msgstr "Translator One,Translator Two,Translator Three"

#: _translatorinfo.cpp:3
msgid ""
"_: EMAIL OF TRANSLATORS\n"
"Your emails"
msgstr "translator.one@some.domain,,translator.three@another.domain"

번역된 문서의 인증 부분에 있는 정보에 대해서는 각 step-by-step 설명을 보십시오.

3장의 내용

• POT 파일들과 PO 파일들
• GUI 번역에 대한 할 일(To-do) 목록
• Step by Step: The Translation of POTs and POs
• Peculiarities and Difficulties
• Using Specialized Programs for GUI Translation
  • KBabel
  • (X)Emacs in PO Mode

당신의 작업을 확인하고 전달하기

• 문법 검사 : msgfmt --statistics --check
• 빠진 변수나 다른 문제에 대해 확인
• 컴파일, 내용과 단축키 검사
• 당신의 작업을 SVN에 전달하기
• SVN 충돌
  
  

이 장은 KDE와 KDE의 응용프로그램의 그래픽 사용자 인터페이스의 번역을 다룹니다. 여기서 실제로 번역되는 것에 대한 배경 정보(예를 들어, pot와 po 파일)에 대해서는 gettext 정보 페이지를 읽으십시오. (주의: KDE 온라인 도움말은 이러한 종류의 문서를 제공받는 가장 편리한 방법입니다.) 특별히 독일어 원본으로부터 이 부분의 첫번째 버전을 제작해 주신데 대해 Christopher Kuhi 에게 감사드립니다.

번역에 대한 템플릿을 제공하기 위해, 프로그램의 영어 메뉴와 대화상자 텍스트가 .pot 확장자를 갖는 텍스트 파일에 저장되어 있습니다. (.po는 "Portable Object(이식가능한 객체)"를 뜻하며 .pot는 "PO Template"에 대한 약자입니다.) POT와 PO가 어떻게 생겼는지 예제를 보기 위해 여러분은 디렉터리 구조에 대한 다음의 지역 정보를 읽고 난 후 웹SVN에 방문해보는 수고를 해보길 바랍니다.

표준 템플릿이나 "POT 파일"로부터 번역팀은 그들의 각각의 언어에 대해 단순히 텍스트 에디터나 특별한 PO 번역 프로그램에 anyfile.pot 를 불러오고 다른 디렉터리에 anyfile.po 로서 저장하는 것으로 PO 파일을 생산합니다. 만약 예를 들어 사용자가 "독일어"나 "아이슬란드" 를 표준 언어로 선택했다면, 주어진 파일에 대해 파일 내의 문자열을 번역한 후, 이 PO 파일들은 메뉴와 대화상자 텍스트를 포함할 것입니다. 정확하게 하기 위해, 컴파일 하는 동안 PO로부터 MO("Machine Objects", 장치 객체)파일을 만드는 즉석 단계가 있습니다. 그러나 이것은 번역자가 일반적으로 걱정을 필요로 하는 것이 아닙니다. 적어도 PO 파일을 작업하는 것보다는 길지 않은 정확한 형식 의 작업입니다. 3장의 처음 설명 부분을 보십시오.

모든 원본 문서로 알려진, 영문 PO를 각 프로그램 패키지의 하위 폴더에서 찾을 수 있습니다. POT 파일들과 모든 번역들은 l10n 으로 불려지고 각 패키지를 나타내는 분할된 KDE 디렉터리에서 찾을 수 있습니다. 포함된 것들은

• l10n/templates/ 폴더 안의 POT 파일들
• 각 디렉터리에 지정된 언어 PO 파일들
  • l10n/$LANG/messages/(package-name)/ (예를 들어 독일어 파일에 대해서 l10n/de/messages/kdebase/konqueror.po)
  • 디렉터리 l10n/$LANG/docs/(package-name)/(appfolder)/index.docbook에 지정된 언어 문서(예를 들어, l10n/de/docs/kdeutils/kdiff/index.docbook)
    
    
($LANG 은 이미 언급되었듯이 RFC 3066을 따르는 코드 표기법인, "de", "fr", "ru", 등등의 언어 코드에 대한 약어입니다.)

어떤 프로그램이 아직 번역되지 않았는지 알아내는 방법엔 크게 두가지가 있다:

• KDE 국제화 상태표에서 알아내는 방법.
• 특정 언어에 대한 PO파일들과 POT파일들을 비교하는 방법. : 즉, 어떤 프로그램이 "l10n/$LANG/messages/(package-name)"에 PO파일을 갖고 있지 않다면, 그 프로그램은 아직 번역이 안 되었을 가능성이 매우 높다. (그런데, 이 비교작업은 KBabel의 "Catalog Manager"가 자동으로 하는 것이기도 하다.) 그럼에도 불구하고, 번역에 뛰어들기 전에 팀 코디네이터에게 누군가 이 프로그램의 번역을 하고 있는지 물어보고 번역자가 없다는 걸 확인하는 것이 좋다. 팀의 할 일 목록과 "패키지 메인테이너" (kdeutils, kdemultimedia같은 전체 KDE 패키지 번역을 담당하는 사람들) 시스템도 중복 번역작업을 막는 데에 큰 도움이 될 것이다.
  
  

KDE 프로그램은 계속 개선되고 있다. 이러한 신속한 개발의 단점이라면 GUI 텍스트 대개가 계속 변하고 있다는 것이고, 따라서 번역도 그에 맞춰 계속 변해야 한다는 것이다. 이미 번역이 된 프로그램 중 어떤 것이 새로운 작업이 필요한 지 알기 위해는 작업 디렉토리를 업데이트해 보거나, KDE GUI 번역 통계를 봐야 한다.

위에 언급한 통계 페이지는 정보가 서브버전 브랜치, 번역 팀, 패키지 이렇게 세 레벨로 구성되어 있다. 패키지 레벨에서는 각 .po파일의 "퍼지"의 양에 대한 세세한 정보를 얻을 수 있다. "퍼지"가 있는 .po파일은 번역작업을 더 해야하는 파일들이다. "퍼지"(Fuzzy)란 번역에 대한 물음표 같은 것이다.

The above mentioned statistics page organizes the information at three levels: SVN branch, translation team and package. At the package level you will find detailed information about the amount of fuzzies in each .po file. The .po files with fuzzies are the ones in need of a revision. "Fuzzy" is like a kind of question mark for the translations. These are sections which have been marked by an automatic checking routine (in msgmerge) as "suspicious" which means something to the effect of: "Please check this translation again because the original has changed".

An overview of how the language teams are doing is provided on the Translation statistics by team for HEAD branch. Based on the data on essential packages the decision is made which languages will be part of a KDE release and which are not. (Normally, 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.)

General material on the subject can be found in the Info pages for the Gettext package. For a basic understanding of what is expected in KDE translation it follows a description of how the handling of POTs and POs looked like before it was done with specialized programs like KBabel:

• If there is no translation for a given program (i.e. there are no PO files with the same name in the appropriate folder "l10n/$LANG/messages/(package-name)/") -- and only if this is the case! -- then a POT file is loaded into an text editor and saved with the ".po" ending in the folder where it was missing. This results in a file with a name like "l10n/$LANG/messages/(package-name)/(program-name).po". For instance: if you are sure that Kate was not translated to your language yet, you load the recent l10n/templates/messages/kdebase/kate.pot and save it as l10n/$LANG/messages/kdebase/kate.po . Then you can start translating. From now on you do all your work for the given program with the PO file. Most of the work consists of updating, improving, and unifying earlier translations (i.e. POs which are already there).
• After you have filled out (or updated) the header (who, when, etc. as well as deleting the first "fuzzy" tag, see below) you fill in the empty strings with new translations. In POs that were already translated at an earlier time you check the "fuzzy" translations and correct them if necessary. Either way, remove the "fuzzy" tag at the beginning of the line after you finished working on it.
  
  

Nowadays, most of these steps are done automatically by specialized programs like KBabel ? from choosing the POT files and saving them as POs, through header updates and removing fuzzy entries to syntax checks.

A sample header could look like this:

If you are working with a text editor do not remove the initial "msgid / msgstr". Otherwise, the compilation will terminate with a parse error. On the other hand, you should remove the "fuzzy" which is initially there.

The entries for Content-Type and the Transfer-Encoding are not relevant at the moment. But the charset should be set to UTF-8 in this case, i.e. 8bit Unicode Transfer Format.

The actual translation would look as follows. The original line:

...you would translate like this (assuming you were translating it to German):

And from the incorrect:

...you would produce the correct translation:

After the corrections have been done you need to delete the "fuzzy" tag. Otherwise, the corrected string will just be ignored during compilation.

Finally there might be lines at the end of the file beginning with "#~" like this:

These lines have been commented out, usually because they are no longer used by the program and should be deleted from time to time in the interest of disk space and bandwidth. Once more, KBabel, for instance, does this automatically.

For any other questions on this topic you are once more advised to look at the Info pages for the GNU gettext package (see the KDE on-line help).

This document is missing a discussion about the KDE-specific handling of plural, which differs from the standard Gettext way of handling plurals. For information on the latter you still have to refer to the respective threads in the translators mailing list, mainly plural handling and plural handling again.

We already mentioned that the characters "#" and "~" have special meaning. A few other things to watch out for are the following:

• The "&" character in one of the examples above is used to mark an "accelerator key", ie a letter which in combination with Alt or Alt Gr (on PC keyboards) will execute the command; i.e. Alt Gr + S for "Show &Status Bar". You have to make sure that the same letter is not marked twice within one menu. There is a semi-automatic test for finding existing duplicates ("accelerator clashes"). See Compilation, Context and Accelerator Checks.
• Some PO files contain so-called "context information" to let translators know whether, for instance, "home" means the user directory, a key on the keyboard or the beginning of a line. Such context information always begins with the letter combination "_:". The important thing is: These strings must not show up in the translations. In other words: Do not translate or copy this stuff into the "msgstr" part of the PO file. If you do, your whole file will not work anymore. The same as above applies to "_n:", which denotes strings handling plural cases. You do not need to translate "_n:". For the correct handling see the following example:
  
  
  

There are several packages to assist you with practical GUI translation. They automatically search fuzzy or untranslated strings, present you with possible or comparable translations for a given string, and perform syntax, spell and other checks to ensure that the files will work correctly. At the moment, KBabel is the only one that can really be recommended, however, especially since it is the only one that handles Unicode encoded files without problems.

Developed by Matthias Kiefer and maintained by Stanislav Visnovsky. The recommended package for GUI translation for the time being.

As of version 1.0 its contents and capabilities can be described as follows:

• General Features:
  + User friendly, easy to understand and widely configurable

  user interface, fully KDE2/3 conform.

  + Every part of KBabel comes with extensive context ("What's

  this") help that make every function easy to understand and to handle.

  + Adds capability to Konqueror and KDE file dialogs to preview

  PO files and show their properties.
• PO-File Editor:
• + Capability to open multiple files (or multiple views of the

  same file)

  + Full editing functionality, accessible through the graphic

  user interface as well as through user definable keyboard shortcuts

  + Powerful spell checking functionality + Capability to show diffs to older messages + Full navigation capabilities (such as go to next fuzzy or

  untranslated string)

  + Capability to save and read files in Unicode encoding (UTF-8) + Unlimited undo capability + Syntax highlighting + Automatic file header updates + Automatic change of "fuzzy" status of translated messages + Support for easy insertion of tags and URLs + A plugin framework for dictionaries, such as po compendium

  files (as for example provided on i18n.kde.org/po_overview/ ) , for consistency checks or translation suggestions

  + A "rough translation" function to initialize untranslated

  messages with suggestion from a dictionary

  + Automatic syntax check with msgfmt when saving and if an

  error occurred easy navigation to messages, which contain errors

  + Full Drag & Drop - support + Configurable fonts for message editor + Various methods to "see" whitespace at end of lines + Various methods to check consistency of translated messages,

  like comparing printf and Qt arguments in msgid and msgstr

  + Quick overview over context in the po file + Showing source code by references in message comments
• Catalog Manager:
• + File manager view for directories of the l10n module (or

  similarly structured) directories), showing the present status of all PO files: if they are in need of a revision or not, how many fuzzies and untranslated strings are included etc. This view is always automatically updated and reflects all changes done to the files, including changes by programs other than KBabel.

  + Various file open mechanisms for editing in KBabel: use Drag

  & Drop, double click, keyboard or context menu

  + "Mark files" function (e.g. to identify POs that are in the

  responsibility of other translators)

  + Powerful navigation using PO file statistics + Automatic comparisons and statistics of POT and PO files for

  a quick overview which and how many files are translated (or not) and which files may be obsolete

  + Syntax check (msgfmt --statistics) for existing files to

  control if the translated files will compile and, accordingly, work when distributed

  + Free configurable commands, that can be executed from the

  Catalog Manager's context menu.

  + Search/Replace functions in multiple files at once. + Spellchecking of multiple files at once.
  
  

Both the KBabel Editor and the Catalog Manager come with extensive "What's this" help that makes every function easy to understand and use. You can get the package from the kdesdk module of SVN or from its home page at i18n.kde.org/tools/kbabel

For ways to set this PO mode up with GNU Emacs, see the comments in the file po-mode.el that comes with the GNU gettext package. It also works with XEmacs if you set it up like this:

1. Copy po-mode.el (not the compiled .elc file) from the gettext package to a directory that's visible to XEmacs (e.g. /usr/X11R6/lib/xemacs/site-lisp/);
2. make the following entry at the beginning of the .emacs or, depending on your distribution, .xemacs-options file in your home directory: (autoload 'po-mode "po-mode")
3. and make the following new entry to Options -> Customize -> Variable -> auto-mode-alist: "\\.potx?\\'\\|\\.po\\." (with the quotes) in the upper line and po-mode in the lower line (without any quotes).
   
   

The functionality is about as follows:

• All important navigation features (go to next fuzzy, untranslated etc.)
• Automatic insertion of (some) header data
• Validation (checking if everything is formatted okay)
• Lots of useful shortcuts for navigation, removing fuzzies etc.
• Searching auxiliary-files for translations of a given string into other languages
• Looking up strings in the sources
  
  

As always with Emacs, it takes some time to get used to it. (For instance, the buffer with the original text is kind of read-only and you have always to open a new buffer where you can work on your translation.) But for people who are used to Emacs or are willing to learn its ways, this mode can be a big help. Another factor might be that Emacs is apparently still one of the best ways to edit DocBook SGML which is also the format of KDE documentation. A very good introduction to working with Emacs in general and working with the SGML module in particular can be found as an Acrobat PDF file at www.snee.com/bob/sgmlfree/index.html

For what is needed to make Emacs work with Unicode files see http://www.cs.uu.nl/~otfried/Mule/.

(Most info in the Emacs section thanks to Matthias Kiefer.)

Please, never commit a PO file to the SVN source tree without at least validating its syntax. Please also do the other checks described in this section. And do not forget about your spell checker.

msgfmt --statistics --check /path/to/translated/files is the absolute minimum check you have to do on every file that you are about to send to your coordinator or to commit directly to SVN. What it does is give you either the number of (un)translated strings or the location and the nature of any formatting errors in your translated files. -- "msgfmt" (in case you are wondering) is part of the GNU gettext package.

Some specialized programs like KBabel will assist you with this. KBabel even contains an automated syntax check (among others) that saves you a lot of the work.

msgfmt --statistics --check is also automatically run by a daily script on the i18n server over all PO files. So far, its output has been forwarded manually to the translation teams by the i18n coordinator. In the near future, the output will be directed to the KDE bug tracking system. You can spare yourself a lot of administrative work if you keep this from happening. And you can do this very easily ? you guessed it ? by testing all your PO files yourself before committing them.

Apart from syntax checks you also have to ensure that there are no problems in the following areas:

• Context information: As pointed out before, PO files may contain comments on the exact meaning of a string (e.g. if "home" stands for the user directory, a key on the keyboard or the beginning of a line). This context information must not show up in your translation.
• Arguments: Many strings show variables (%1, %2, %3...) which will be replaced with actual contents on runtime of the program. The variables of the original string must all show up in the translation (although not necessarily in the same order).
• Equations: have to be balanced in the translation just the same as in the original.
  
  

Again, KBabel provides automatic validation routines for all these possible issues. In recent versions, it also allows spell checking of your files.

To be able to check the translated packages in the context of the program interface, you have to generate the "(G)MO" files we mentioned above. This is accomplished by compiling the sub-folder of the l10n package appropriate to the translated language:

• Change to the directory "l10n" and create a file named inst-apps and add the language(s) that you want to compile (one per line, see the subdirs file as example of the needed format.)
• Then just compile with ./scripts/autogen.sh && ./configure && make && make install.
  
  

If you are using unsermake instead of automake, then replace make by unsermake, so the full command becomes: ./scripts/autogen.sh & ./configure && unsermake && unsermake install

In case there are any error you may want to try ./configure & & make -k; make -k docs; make -k install. With the -k parameter files and directories that do not compile are skipped. For more on this subject, see the info in the HOWTO section.

After this it should be possible to choose your language and to see your translation in the program interface (assuming you compiled the program also). Now you can start your context checks: Go through all menus and dialogs and check if all your translations make sense in their real environment. Make ready for some big surprises. Then correct your PO file, recompile and check again.

These context checks are often neglected due to tight release schedules. But everybody who has seen how unprofessional and even ridiculous a whole program can look if it has a lot of out-of-context information in its menus will agree that these checks are among the most important things in the whole translation process.

Another test that can only be done after the translated program has been compiled is the check for "accelerator clashes".

As pointed out earlier, the "&" character in PO files is used to mark "accelerator keys" (a letter which in combination with Alt or Alt Gr (on PC keyboards) will execute a command). Program authors and Translators have to make sure that no accelerator key shows up twice in the same menu (e.g. that there's not something like "&Save" and "&Save as" but maybe "&Save" and "Save &as" ). In other words: you have to prevent "accelerator clashes".

Accelerator clashes can be checked via KBabel as well.

After having checked their work, most translators will sent their completed translations to their language coordinator. The coordinator will usually check again and then commit their files to the main SVN server at svn.kde.org.

The necessary information on SVN and its graphical frontends is given in the section Taking a Look at Available Resources and SVN, including some hints about the commands and parameters needed.

You cannot commit a file if the SVN server has a more recent revision of the same file. In that case, you will probably need to use svn update to get the new version. SVN will merge it for you. You should check the result, as SVN merges only tet files; it has not any idea about the syntax of a PO file. In some cases, you will get conflict, which you will need to fix (technically this is called "resolve").

One thing to watch out for are version conflicts. When you update files by SVN, SVN will try to merge changes, if there are changes on both your local version of a file and the version of the SVN verver of that file. SVN only merges text lines and this works normally well. But not always...

One kind of problems could be that the resulting file is not a valid PO file, as SVN has not any idea about the syntax of PO files, as for SVN, PO files are just a text files.

Another, more serious kind of problems is called a conflict. In that case, SVN gives up the merging, telling that it could not merge, as both the local change and the change of the server are on the same lines of a file. SVN remember that a conflict has happened and will refuse to commit the file until you have told SVN that the conflict was fixed.

In case of conflicts in text files, SVN tries to be helpful and puts special marks (lines with <, = and > characters) to help the user to see what are the conflicting change. It is your task as user to resolve (i.e. fix) the conflict. In the case of binary files, SVN cannot offer such a service, to avoid to corrupt the file.

For example:

The example above come from the time KDE used CVS and is embeded in an email. But it could happen with SVN too, in a very similar way.

Probably you wonder now how to solve such a problem. Normally you can try to solve it by using your normal tool, e.g. KBabel. But sometimes, this is not possible and you need to use a text editor, e.g. Kate. An easy way of removing a conflict is to revert the file by the command svn revert. Another is to use one of the auxilary file screated by the update with have file names starting by the file name of the conflicting file. You can simply copy the version that you find correct instead of the file with a conflict.

When you have fixed the conflict, you need to tell SVN that you have fixed the conflict, so that SVN will allow you to commit the file. This can be done easily by svn resolved. (If you have chosen to revert the file, this step is not necessary, as SVN has already done it implicitely.)

Conflicts might appear often with PO files automatically merged by Scripty. Here a good solution is to keep working on the local version (so copy the corresponding file over). (Scripty will again work during the next European night and morning.)

Table of Contents

General Requirements for Doc Translation POT and PO Files Used for Documentation To-do Lists for Doc Translation Step by Step: The Translation of Documentation Files Peculiarities and Difficulties Checking and Committing Your Work

The bulk of information on KDE documentation is of course being provided by the KDE documentation team, especially their coordinator Lauri Watts. Please have a look at their web pages at http://i18n.kde.org/doc/.

The documentation and online-help for KDE programs are written now entirely in XML? (eXtensible Markup Language) DocBook. DocBook is a widely used standard for technical documentation.

A major advantage of DocBook is the capability of the conversion from one markup to another one, for example to HTML or PostScript. If you ever happened to work with a markup language like HTML or LaTex then DocBook will be no problem. If not, you will probably need to get at least a basic understanding of these markup languages. Further information is provided in the next sections.

The software requirements are about as follows:

• You are going to need KBabel by Matthias Kiefer just as for GUI translation. This program is part of the kdesdk module in SVN. This package can be downloaded from the same source as the other parts of KDE. KBabel supports UTF-8 as required for the documentation and online help.
• For localized screen shots, you should make yourself familiar with a program like KSnapshot (from the KDE package kdegraphics) or XV.
• It is also extremely advisable to have a program around for checking the syntax of the finished doc translation. For this task, you will need the XML? parser meinproc by Stephan Kulow. This parser is part of the kdelibs core module.
• Finally you are going to need po2xml. It takes a po-file and produces from this source the complete XML? document. This program belongs like KBabel to kdesdk.
  
  

These programs are a big help in the translation process (especially when searching and correcting fuzzies and untranslated strings). They ease up the comparison between older translations, check for formal correctness and the work flow in general. And if you use this tools and give the authors feedback, they are going to improve even more.

This is meant as a short overview of the peculiarities of those file formats in the process of doc translation -- basically, you already know them from the part on GUI translation.

The files that have to be translated are in Unicode UTF-8 format with the extension .pot and .po. But this is only for the convenience of translators. Originally, the English documentation is included in DocBook files (see above). Once the documentation author commits a documentation to the SVN, the program xml2pot extracts the translatable strings from the file. It then writes those strings to a POT file. Basically, the resulting POTs do not differ too much from what you already know from the GUI files.

The next paragraph is outdated. The update_xml must be run by hand to create the translated DocBook documentation file.

The English POT file is the common ground for the translation teams which produce for each POT file one PO for their language. These localized PO files provide the translated strings, from which the program po2xml produces the translated DocBook file. po2xml is regularly run on the i18n.kde.org server. If a KDE user eventually has set the standard language in KDE to for example "German" or "Icelandic" and opens the KDE help center, this translated DocBook files are processed by the help ioslave from Stephan Kulow and the resulting HTML files are shown on screen. The automatic generation of the translated DocBook files by po2xml require the PO files to be syntactically correct.

You can find the English DocBook documentation in subdirectories of the source code for the corresponding package. The POT files and the translated PO files and DocBook files for all languages are located in the KDE package named kde-i18n. For the package "EXAMPLE" you will find

• the POT files in the directory l10n/templates/docmessages/(EXAMPLE)
• the translated PO files in the directory l10n/$LANGUAGE/docmessages/(EXAMPLE)/
• the English documentation files in the directory l10n/documentation/(EXAMPLE)/doc/ (you need this file to generate the translated DocBook file)
• the translated documentation (in DocBook format) in the directory l10n/$LANGUAGE/docs/(EXAMPLE)
  
  

Claudiu Costin has built scripts for a daily documentation statistic. This page gives an overview of the existing documentation for your language and the status (i.e. outdated, current...). This statistics does currently contain only documentation that was at least at some time completely translated ? simply because this statistic does compare DocBook files. These files are generated by po2xml only if the corresponding PO file contains no fuzzies and untranslated strings.

If you have the l10n sources for your language on your computer then the Catalog Manager of KBabel contains considerably more information.

Another important point is to not duplicate the work of somebody else. It may be useful to split the work so that for each package one person (and only one) is responsible. Usually, it is the job of your language coordinator to organize this part. So you should better not start to work before you have checked with your language coordinator.

There is another item to check for: Before translating you should contact the author of the English original documentation to make sure there is not going to be a major new revision in the near future. By doing this you make sure your work is not obsolete.

In the following we assume that you are somewhat familiar with the structure and syntax of DocBook files. For further information on this format please have a look at the pages of the documentation team.

Generally speaking, you should just install KBabel and translate the PO file as already explained in the GUI section of this HOWTO. (Additionally you need the current version of the directories l10n/templates/docmessages/, l10n/$LANGUAGE/docmessages/, l10n/$LANGUAGE/docs/ and l10n/documentation/(PACKAGE)/doc/ from SVN):

Since things keep changing (standards, formats, etc.) it is important to join the translators mailing list and to watch out for the announcements there.

• If you start KBabel for the first time it will ask you for some user information that you should supply correctly. From this information the headers of the PO files are automatically generated. Remember to set Settings->Configure KBabel... Preferences->Save->Encoding: Default: to UTF-8 (8bit Unicode Transfer Format). Additionally, you should enter the path to your PO files for the Catalog Manager (see next item) and probably also activate Preferences->Edit the Show surrounding quotes on the Appearance tab because otherwise you cannot see spaces at line ends.
• First thing after you launch KBabel you should start the Catalog Manager with Tools->Catalog Manager.... The Catalog Manager shows you what documents exactly require work (fuzzies, untranslated strings and programs). For this to work you need a current copy of the directories l10n/templates/docmessages/ and l10n/$LANGUAGE/docmessages/. Also you have to enter the path to these files in the KBabel settings.
• If the Catalog Manager shows no translation for your program (i.e. there is no corresponding PO file in l10n/$LANGUAGE/docmessages/(PACKAGE) -- and only in this case -- on double click the POT file is loaded into the editor and saved with the extension PO in this same directory where this file is missing i.e. l10n/$LANGUAGE/docmessages/(PACKAGE)/(PROGRAM).po. KBabel takes automatically care of this, if you load the file from the Catalog Manager and save it afterwards. You just need to make sure that you put the right path names in Settings->Configure KBabel... in the dialog at Catalog Manager. From now on you are only working with the PO file for this program. The main part of your work will be to change and keep current already translated documents (i.e. existing PO files).
• Then you have to translate untranslated strings and check the already translated strings that are marked as "fuzzy". To simplify correction of fuzzies KBabel provides the "diff mode". In this mode (for corrections this mode should always be switched on) new and deleted parts of the msgid are highlighted. For this to work KBabel keeps a translation database where it automatically stores translated msgids and msgstrs. As soon as you change the msgstr the "fuzzy" mark will disappear. If you decide that the msgstr is without changes correct you need to delete the "fuzzy" mark yourself by pressing Ctrl+U. This is important because a DocBook file can only be generated, if the PO file is 100% translated.
  
  

If the documentation directory of the program contains screen shots you should produce a localized (e.g. with a translated GUI) version. KSnapshot is a useful tool for this purpose, but any application is fine as long as it can produce screen shots and save them as PNG file.

You should use the KDE standard design for the screen shot. Unfamiliar looking screens may confuse the users.

It is important to save the localized picture under the same name as the original one in the translated DocBook directory corresponding to the applications English documentation DocBook directory (not the directory of the PO file).

Screen shots are not allowed to be in GIF format. They must be in PNG format. More information on this topic can be found here.

For more information about PO files and their translation see the respective section in the GUI chapter.

First, the answers to some frequently asked questions and a piece of advice:

• Line breaks have no influence on the formatting of the generated DocBook. You can insert a line break wherever you find it suitable for your needs. It is important, however, to have a space at the end of the line. For example:

would otherwise become:

In addition to the role of "#" and "~" (explained above) there are a few more peculiarities:

• There are two msgids which are dedicated to documentation translation. They are somewhat special in that they do not have corresponding strings in the English original documentation. These are CREDIT_FOR_TRANSLATORS and ROLES_OF_TRANSLATORS. As you probably guessed this is the place where you put in your name and your email address. It is important that these msgstrs have a special markup to make them fit into the context (You can find some background about this special msgids and possibilities to add paragraphs that do not exist in the English documentation here.) So here is an example of a document which has two different translators:

and

There are two items to check if you finished translating a documentation, namely spelling of the words and syntax of the XML? markup.

• You could use the spell checker which is built into KBabel (Tools->Spelling->Spell check...). This spell checker can be configured through the Preferences dialog (Settings->Configure KBabel...).
• To check the XML? syntax you have to generate the translated XML? documentation (DocBook) from the PO file. After that you can check the XML? syntax of this docbook file with an XML? parser. You have at least two possibilities to choose from, depending on whether you have only one documentation file or the necessary part of the whole source tree of the documentation for your language:
  + If you have at least the necessary part (the part where the

  PO file in question resides) of the source tree of the package l10n for your language and the doc part of the source tree of the package for the translated program (the part where the English docbook file in question resides), you could use the script update_xml. You also need to have po2xml in your path, as it is called by this script. The script generates the docbook files from the corresponding PO files for that language. The script takes the language to compile as first command line parameter, so if your language directory is named NN, you type update_xml NN to start the script. The script updates all files it can find in your language tree. If you only want to update a certain package or program, you can add it as second parameter to update_xml. For example, to update the German translation package kdemultimedia:

or the German translation application aktion:

update_xml automatically calls the XML? parser meinproc with the option --check, which makes it validate the generated XML? document. If the parsing process fails, it will tell you the line numbers and error messages.

If meinproc fails then update_xml will automatically remove the file with errors. That is for safety to ensure that the DocBook files for every language compile. Sometimes this feature prevents you from finding errors, since the error messages print the corresponding line numbers in the docbook file and you are not able to check the context because this file is automatically deleted. Therefore the option --nodelete was recently added by Stephan. But keep in mind not to check this file with errors into the SVN tree or else your language will fail to compile until this file is removed or corrected.

+ If you do not have the above requirements you may call po2xml

like this:

Now that you generated the docbook file for your language you can check that the syntax is correct and all used entities (i.e. &kapp; etc.) can be resolved correctly.

It is not enough that the docbook file can be displayed more or less correctly by the KDE help center, because the parser there is optimized for speed and does not check the correctness of the XML? document. It is very generous in ignoring markup errors and the like. Instead use the XML? parser meinproc from Stephan Kulow. The calling syntax is meinproc --check translated.docbook If the parsing process fails it will tell you the line numbers and error messages. You can use this application for generating HTML files, too. Just call meinproc translated.docbook and you will find a bunch of HTML files in the current directory. The file index.html is the starting point for browsing the documentation.

As for proof-reading: Each language team needs to have a certain procedure for error checking. In the German team for instance we decided on proof-reading the documentation by a different team member because the translator tends to overlook the own spelling errors.

Generating HTML files: The program meinproc not only checks the syntax but additionally generates HTML files in the directory of the corresponding docbook file.

Usually, the coordinator for you language will take care of proof-reading and afterwards committing the translated files to SVN. So please check with him or her about the team policy in this regard.

You should always keep in mind that once your documentation is published on the KDE web server, it will be distributed worldwide and may be read by millions of people. So your translation will substantially influence how users experience KDE.

Table of Contents

Handling Translation Bugs

This entire chapter about KDE Bugs is outdated.

Translations (and to some extent documentation) are becoming part of the KDE bug tracking system these days. This means translation coordinators will be receiving:

1. All sorts of reports on what their users think are bad or wrong translations
2. Bug reports, wishlist stuff, and any sort of feedback on all KDE programs in native languages of the users that need a translation to English. (Do not panic: the users are asked to send these reports in English and certainly most of them will do so.)
   
   

The KDE bug tracking system is thoroughly described at bugs.kde.org. The description is in fact so thorough that it may even look somewhat intimidating at first. Basically, the procedure to submit, work on, and get rid of bugs is the following (partly quoted from bugs.kde.org/Developer.html where you can find a lot of additional info):

Initially, a bug report is sent by email to submit@bugs.kde.org. This report will then be given a number, acknowledged to the sender, and forwarded to kde-bugs-dist. If the submitter named the package that contains the bug the maintainer of that package will also get a copy. In our case the "package" would be the respective translation ("i18n-$LANG") and the coordinator listed in the "Maintainers" file of the "bugs" module in CVS would receive a copy of the report. For instance, if a user complains about a problem with German translations, the bug tracking system looks for the line:

in the Maintainers file and processes the report accordingly.

The subject line of the resulting mail will have the bug number added as "bug#nnn", and the reply-to will be set to include both the submitter of the report and "nnn@bugs.kde.org."

Translators who receive a bug report from the tracking system should, of course, fix the problem and then send a reply to the report where the "to" field of their reply says "nnn-done@bugs.kde.org" or "nnn-close@bugs.kde.org" instead of just "nnn@bugs". The address of the original submitter of the bug report will be also included in the "to" field automatically (because the bug system also included it in the "reply-to" field).

The person closing the bug and the person who submitted it will each get a notification about the change in status of the report.

If translators wish to reply to a bug report without marking the bug as closed they may simply reply to the message without any editing of the "to" field. Their reply will then go to "nnn@bugs" and to the original submitter of the bug report. The bug tracking system will file the reply with the rest of the logs for that bug report and forward it to kde-bugs-dist. The bug will not be marked as closed in this case.

Do not use the "reply to all recipients" or "followup" feature of your mail program unless you intend to edit down the recipients substantially. In particular, do not send a followup message both to "nnn@bugs.kde.org" and to "submit@bugs.kde.org", because the bug system will then get two copies of it and each one will be forwarded to kde-bugs-dist separately.

Table of Contents

Web Sites for Internal Use Web Sites for KDE Users

This area is pretty much in the responsibility of the individual teams. It is not a "must" for any team to maintain a web site. But it is highly recommended. To be more specific: it is even recommendable to have two web sites: one for internal use of the translation team and one for the KDE users the individual team is translating for. As a matter of course, both sites will be created in the language of the respective team. And both sites can also be just one if the team prefers it that way.

As already stated in the intro of this HOWTO, you can get the web space for an internal team site from the KDE project. It will be located at i18n.kde.org/teams/$LANG/ and be maintained via a CVS server that is separate from the main SVN server. Any active translator can get an account for this one, not only team coordinators.

In order to get some web space or an CVS account on the i18n server just send your request to Claudiu Costin, together with the login name and an encrypted password for your new account. For a description on how to create such a password please see the SVN tutorial (as the way to create a password for CVS is the same way than creating it for SVN).

Normally you would use this kind of space for internal announcements, to-do lists, overviews of who is doing what, Howtos, style guides, lists of standard translations and a lot of other things related to the "infrastructure" of your team. In most cases, together with a mailing list such a team site pretty much is your "infrastructure".

If you ever went to a Linux fair or a KDE user meeting in your own country, you probably know that there is real demand for information on KDE in people's own language. Strangely, this area is often neglected, though. So far, very few teams have up-to-date translations of the KDE web site or real informative KDE user sites of their own. There are exceptions, of course. The French team, for instance, even has a press book and does a lot of public relations for KDE, not only by maintaining a web site.

At the moment, there are two points under consideration:

• To provide the translation teams with separate snapshots of the original KDE web sites in order to make translation easier
• To create separate entries for "user web sites" (as opposed to "team web sites") on the team page
  
  

Suggestions as to what else we can do for the visibility and effective creation of localized web sites are very welcome.

Table of Contents

The i18n Server SVN WebSVN... Mailing Lists, IRC, and On-line Fora Web and FTP Sites Statistics HOWTOs and Info Sites Specialized Programs and Modules

Dictionaries and Tools for Consistency Checking

The following is mainly a reference section of the most important of the resources that have been described throughout this HOWTO ? a reference of the files that are to be translated, of statistics about the present status of these files and of many other useful things we all need in the process of KDE translation. But there are also some additional items that have not been mentioned so far.

Chances are that you know the i18n server already, simply because it is the home of this document. If you do not, you should do a look around as soon as possible since many of the resources for translators are located there, including now a "tools" page: a listing of specialized programs for translators and documenters which are available on the server. Every feedback and contribution to the material (tools, scripts, Howtos) is highly welcome as stated in the original announcement. The people in charge for the i18n server are Claudiu Costin (technical side, managing the web server, CVS, and the scripts) and Thomas Diehl (contents).

You can also have a web site for your team on this server (e.g. for internal todo lists, lists of who is responsible for what, internal translation HOWTOs, styleguides and so on). The advantage to having it here compared to having it on private sites on the outside is that everybody in your team has access to it via an extra CVS system, separate from the main KDE SVN. That means: no problems accessing the data if someone is on vacation or simply drops out.

If you are interested in getting an account, just write to Claudiu and send him a user name and an encrypted password. For a description on how to create such a password please see the SVN tutorial (the way to create a password is the same then for SVN)

The necessary information on SVN and their graphic frontends is provided in the section Taking a Look at Available Resources and SVN.

The use of WebSVN should be pretty much self-evident.

These are the main resources in this area:

• The mailing list for translators and documenters (kde-i18n-doc@kde.org), archived with plenty of other KDE lists at lists.kde.org. Main platform for discussions, problem reports and announcements regarding KDE translation and documentation. Quite naturally, this is the most up-to-date resource of information for you. Another list that often provides useful information or has answers to questions about technical difficulties is the main developer list at kde-devel@kde.org (get in by sending a mail with "subscribe" in the subject to kde-devel-request@kde.org). There is also a specialized list for technical issues of DocBook at kde-docbook@kde.org (subscription procedure is similar to the one just mentioned).
• The KDE chat rooms at irc.kde.org which often lend the opportunity to "talk directly" (sort of) to the developers. It can also be used, of course, for translator meetings.
• The most popular web forum is KDE Dot News in Slashdot style (or Squishdot style respectively). Also, as pointed out already, setting up a web forum can provide a very effective platform for discussing translation terms and for user feedback. One of the main advantages compared to mailing lists (even to those with an archive function) is that you can pretty easily get an overview of what already has been discussed. The downside is that these fora cost a lot of on-line time which make it less attractive for people with dial-up connections who have to pay by the byte or the minute.
  
  

There are several different flavors:

• The original KDE web sites:
  + The most important one is www.kde.org, of course, the virtual

  center of all information on KDE

  + Grouped around this center is the "family" of specialized web

  servers like developer.kde.org (info and documentation for programmers), i18n.kde.org (well, you know), lists.kde.org (searchable archives of most KDE mailing lists), bugs.kde.org (web interface for the bug reporting and tracking system), devel-home.kde.org (home pages for several KDE apps), koffice.org (for the KDE office suite), www.kdevelop.org (home of the KDE programming environment), and kde.themes.org (info and showroom for KDE designs).
• Localized and translated KDE web sites:
  + Those for internal use of the translation teams (with to-do

  lists, translation term lists, Howtos, style guides and so on) such as i18n.kde.org/teams/fr/. Remember: you can get such a site on the i18n server for your translation team. Just send a mail to the i18n coordinator.

  + And user sites such as the ones at www.kde.org/international/

  which are mostly translations of www.kde.org and its "family".
  
  

The links given in this section are mostly obsolete. Most still exist, but with other URLs.

The following pages show the status of the translations. Normally, they are updated on a daily basis. Most of the underlying scripts are (re-)written and maintained by Claudiu Costin.

• The Status table of KDE Translations for the HEAD branch gives an overview of how the language teams are doing (in percentages translated of the core packages by each team). It provides the main basis to decide which languages will be part of a KDE release and which are not.
• The i18n-status-table shows which program GUIs are already translated and which are not.
• The so-called "Highscore lists" tell you which of your already translated GUI files are in need of a revision. (Untranslated PO files do not show up here, these can only be seen in the i18n-status-table.) In the Highscore lists, doubtful translations are marked as "fuzzy", untranslated strings are marked as, well, "untranslated". Usually, a string becomes "doubtful" by changes in the original. There are several versions of these Highscore lists: the "all-in-one" files as text only and HTML (the latter with extensive linking and "jump-to-your-language" capabilities) and the "split-up" files that show the same information for the individual language teams. The latter are probably preferable for most people since they are much smaller in size.
• The documentation statistics show listings of existing documentation from the individual language teams and make an educated guess as to whether translations (if any) are up-to-date or not.
  
  

The following seem particularly useful in the process of KDE translations:

• Version Control with Subversion
• The overview of compiling KDE from CVS sources at developer.kde.org
• The KDE Compilation FAQ
• The KDE Unicode Howto by Wolfram Diestel
• Various information on the i18n server, especially lots of useful stuff on DocBook in general and KDE documentation in particular by the editorial and doc translation teams in the main documentation directory. Not on i18n.kde.org but equally useful in this context are the scripts and pages by Frederik Fouvry and the KDE DocBook Markup Reference Handbook by Lauri Watts.
  
  

The following tools can make your life as a KDE translator a lot easier. Do not worry if you do not understand the feature listings in the respective chapters of this HOWTO on first sight. You will understand them as soon as you know how GUI and doc translation really work.

Apart from just using your favorite editor you have basically the following three options:

• KBabel by Matthias Kiefer (full support for Unicode): the recommended program for GUI translation at the moment
• and the GNU Emacs PO module (po-mode.el) that comes with the GNU gettext package (Unicode support only with additional packages)
  
  

Features and advantages to using these specialized programs are listed in the appropriate section on GUI translation.

This part changed considerably, since the switch to PO format for the Doc Translation, there is no real alternative to KBabel.

• Like for GUI translation KBabel is the recommended program for Doc Translation, too.
  
  

If you know of something that should be listed here, do not forget to tell me...

• kdedict by Matthias Kiefer: cgi script to store standard translations in a database and make it available via the web (there's also a demo available).
• kbabeldict by Andreas Rizzi which is part of the KBabel package: creates compendium files and provides a convenient interface for searching them
• Flexicon by Logi Ragnarsson: a database of words, each with an assigned language and description.
• An index of on-line dictionaries and a lot of other resources can be found at www.yourdictionary.com.
• Finally a tip: in the German team they are not using their mailing list but a web forum for discussing difficult translations (one term per thread) which has the advantages: (1) that everybody can jump in without the need to subscribe to a mailing list (2) and everything is pretty well documented and easy to find for translators to come. -- The program they are using is Discus, and the German forum is at www.dtp-service.com/discus_d/, check it out. Of course, there are zillions of other programs of that sort.
  
  

Table of Contents

Overview Directories of the l10n Module How To Translate?

There are two active l10n modules in KDE SVN (and also all the released ones). The two modules are:

• trunk/l10n for the unstable development branch
• branches/stable/l10n for the stable branch
  
  

The generic directory overview of a l10n module is:

• the templates directory: the place where the translation templates are stored.
• the language directories (e.g. fr, de, en_GB) where the translations are stored.
• the scripts directory: here are scripts needed for the l10n module, however most the scripts are not necessarily usable by translators.
• the documentation directory: the place where the original English documentation is refered.
  
  

l10n/templates/messages l10n/templates/docmessages l10n/templates/webmessages l10n/$lang/messages l10n/$lang/docmessages l10n/$lang/docs l10n/$lang/webmessages l10n/$lang/internal l10n/documentation l10n/scripts

The files that are to be translated by the individual languages teams are stored in the following locations:

• The original GUI translation templates are located in l10n/templates/messages.
• The already translated GUI files (the POs) are located in l10n/language/messages. For the procedure on how to make a PO file from POT file please read the section on GUI translation.
• The translated documentation files are located in l10n/language/docs. (The same goes for downloading these files as for POs.) For more info on this whole subject please read the section on doc translation.
  
  

You can get files via SVN or WebSVN.

KDE is not using CVS anymore but uses SVN. However i18n.kde.org still uses it, so here is a quick overview of CVS (Concurrent Version System).

If you know SVN already, you will soon notice that many basic commands are the same, as SVN client's commands are modeled after CVS client's ones. The very big difference is that directories are not versioned and always exist, as soon as they are created. Also there is no move and no copy.

Whatever you do or do not know SVN yet, you could take a look at the CVS Info pages. (You can type info:cvs in Konqueror or using KHelpcenter.) Do not panic if the CVS Info pages should look overwhelming at first. Basically, you are going to need only a few commands and parameters: checkout (for getting something from the remote system to your local repository) and its -l parameter (for non-recursive checkouts), update (if you just want to refresh already existing stuff on your local system) and its -dP parameters (for smart directory handling), add or import (for telling the remote system that there will be something new), commit (to get the new stuff from your local repository to the remote source tree), remove (to delete something on the remote server) ? that's about all. A good description of the basic commands can be found in the CVS section of the KDE Developer's HOWTO

There are also some graphic frontends for CVS around that could make things a lot easier for you, such as LinCVS or Cervisia (part of the kdesdk module of KDE). And in case you really get interested in this subject there's now The CVS Book ? Open Source Development with CVS.

The following acknowledgements are the ones of the first author of this document: Thomas Diehl.

The errors in this document are mine, of course. What is usable is mostly due to people in the KDE project who explained this stuff to me. I would like to thank all of them here. Special credit goes to:

• Juraj Bednar, i18n coordinator (and sometimes co-coordinator;) who introduced me to KDE translation with incredible patience and an often even more incredible sense of humor
• Tobias Burnus, former webmaster of i18n.kde.org and original author of all the statistic pages and archives most translators can hardly live without: thanks for a lot of assistance with all the technical issues in this area
• Matthias Kiefer, Developer of KBabel, kdedict, documentation guru of the German team, main source for Emacs settings, and always lending a helpful hand with translation issues
• Christopher Kuhi who produced most of the chapter on GUI translation from a German HOWTO on this subject (and is going to be checking everything for grammar and spelling mistakes
• Stephan Kulow, grandmaster of the CVS, maker of the groundwork for almost all things having to do with KDE translation, spiritus rector for both the i18n and the documentation teams and mediator between techs and non-techs: thanks for all his good advice with the many problems that I (as a non-programmer) always have with KDE programming issues
• Frank Schte rewrote the part on doc translation after the transition to the PO format for translation of documentation.