· KLDP.org · KLDP.net · KLDP Wiki · KLDP BBS ·
KDE Translation Howto

The KDE Translation HOWTO


Thomas Diehl

Nicolas Goutte Rewrite of the doc-translation part: Frank Schütte Update of the GUI-translation part: Arash Zeini Revision 2.0.08 (2005-09-13)

조성재 번역 (jachin)

Copyright © 1999-2002 Thomas Diehl

Copyright © 2005 Nicolas Goutte

번역자들의 Howto는 번역팀 관리자, 새로운 번역자, 그리고 KDE 번역에 대해 관심이 있는 분들을 위해 쓰여졌습니다. 이 문서는 새로운 언어를 KDE에 도입하는 방법과 더불어 그래픽 인터페이스, 온라인 도움말을 비롯한 KDE 관련 텍스트들이 실제 어떻게 번역되고 있는지를 개략적으로 설명합니다. 번역을 실제로 하는 과정에서 요긴하게 사용할 자원들에 대해서도 상세하게 살펴봅니다. KDE 소스를 컴파일 하는 방법, SVN를 사용하는 방법 등 여타 중요한 내용은 문서 전체에 걸쳐 참고할 책이나 주소를 적어 놓았습니다.

이 문서의 현재 HTML 버전은 i18n.kde.org/translation-howto 에서 볼 수 있으며, 이외에도 여러가지 형식으로 다운로드 받으실 수 있습니다. http://i18n.kde.org/sitedoc.html 을 참고하세요. 이 문서에 대한 커멘트나 교정, 덧붙일 내용이 있으면 kde-i18n-doc 메일링 리스트에 보내주세요. (역자주 : 현재 개인적으로 번역하고 있으니, 위키에서는 개인적으로 고쳐주시면 되겠습니다.)

1. 소개


경고

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

추상적으로 이 Howto 문서는 KDE 번역에 관심이 있는 분들을 위한 것입니다. 문서를 번역하는 작업에 대해 특별한 허가나 능력이 필요한 것은 아닙니다. 프로그램을 제작하는 것과는 대조적으로 문서 번역 프로젝트는 프로그래머가 아닌 일반인들도 참여할 수 있는 것입니다.

새로운 언어로 KDE 번역을 하기 위한 것들, GUI 환경의 번역, 온라인 문서등의 번역등을 이 문서에서 다룹니다. KDE 웹 사이트, 버그 리포트와 사용자 입력에 대한 번역은 별도로 다룹니다. 또한 KDE 지역화에 대한 영역도 일반 OS 번역에 대해 다루는 www.li18nux.org 에서 찾으실 수 있으실 것입니다.

문서를 통해 정확하게 i18n(internationalization)과 l10n(localization)을 구별하여 다루지 않겠습니다. 실제로 KDE 에서 "i18n"은 "번역과 관련된" 기본적인 의미를 가지고 있으며 "l10n"은 통화기호, 단위, 특수기호등의 "지역적인 설정"(KDE의 제어판으로부터 선택할 수 있는 모든 것들)을 다루는 것을 말합니다. 실제 의미의 간략한 설명과 개발자 측면에서의 설명을 보기 원하시면 developer.kde.org/documentation/library/kdeqt/kde3arch/kde-i18n-howto.html 을 보시기 바랍니다.

이 Howto는 대부분 "Quick start" 형식의 문서로 실제 번역에 필요한 기초적인 내용을 제공합니다. KDE 문서에서 사용되는 DocBook의 내부 동작에 대한 것들과 같이 복잡한 영역의 설명은 이곳에서 할 수 없습니다. 다만 외부 용어는 관련 설명을 제공합니다. DocBook에 대한 이해가 문서 번역과 거의 밀접하기 때문에 같은 주소인 kde-i18n-doc@kde.org 로 메일링 리스트를 같이 쓰고 있습니다. 기술적인 주제로 Docbook과 관련된 내용의 메일링 리스트를 얻고 싶으시다면 kde-docbook@kde.org 를 사용하십시오. 또한 문서 작성과 관련된 메일링 주소로 아직까지 kde-doc-english@kde.org 주소가 사용되고 있습니다.

개인적인 번역팀에서 이 문서에 대해 번역을 하는 것에 대해 문의를 하는 경우가 많습니다. 자유롭게 생각하고 번역하시기 바랍니다. 다만 KDE는 급격하게 변하기 때문에 KDE 에 대한 최신의 DocBook 을 번역에 사용하시고 확인하여 주시기 바랍니다. 새로운 버전에 대한 공지는 번역자, 개발자 메일링 리스트로 전달될 것입니다. 이 문서에 대해 변경된 점은 DocBook과 연결되어 있지 않기 때문에 긴 공백이 있을 것입니다. 다음 섹션을 보십시오.

건설적인 피드백이나 배포는 물론 대환영입니다. kde-i18n-doc 메일링 리스트에 이메일을 보내주시고 여기서 무엇을 하고 싶으신지 알려주세요.

2. KDE에 새로운 언어 제안하기


제일 먼저 해야 할 것

무엇이든 하시기 전에 번역자나 문서작성자에 대한 메일링 리스트를 얻으십시오. (웹페이지나 kde-i18n-request@kde.org 에 subscribe 라는 제목으로 메일을 보냄으로써 얻을 수 있습니다.) 이 메일링 리스트는 lists.kde.org에서 전달됩니다. 두번째로 KDE 언어의 목록과 번역팀 운영자를 찾으십시오.

목록에 당신의 언어가 있는지에 따라 해야 할 것이 다릅니다.

  • 만약 당신의 언어가 있다면 간단하게 번역팀 운영자에게 어떻게 진행해야 하는지 메일을 보내십시오.
  • 만약 목록에 당신의 언어가 없다면, kde-i18n-doc 메일링 리스트에 이미 언어에 대해 작업중인 사람이 있는지 같이 작업 할 수 있는지 등을 메일로 보내십시오.

    (주의: KDE는 아직 인도 주변의 언어를 완벽하게 지원하지 않습니다. 만약 이 주제에 대해 더 많은 정보를 얻고 싶으시다면 메일링 리스트에 접촉해주십시오.)

만약 아무에게도 메일 답신이 오지 않는다면, GUI 번역 담당자로부터 메시지를 받으실 것입니다. (만약 그렇지 않다면, 직접 담당자에게 메일을 보내세요.) 아마도 그가 당신에게 당신의 언어 번역팀의 팀장이 되지 않겠냐고 물어볼 것입니다.

사용 가능한 리소스와 SVN 을 검색하기


  • 이 번역 Howto 문서를 전체적으로 읽어보시고, 특별히 GUI 번역 부분을 잘 보십시오.
  • KDE를 어떻게 설치하는지 찾아보고 그대로 설치하십시오. 비록 번역하려는 버전의 이전버전 KDE에 이론적으로 번역을 적용 할 수 있습니다만, 적어도 테스트 목적으로 당신의 컴퓨터에 필요한 버전을 설치해 볼 것을 권장합니다. 이 제목(Taking a Look at Available Resources and SVN)과 관련된 문서에 대해 HOWTO를 확인해 보십시오.
  • 가장 최근의 GNU gettext 패키지가 설치되어 있는지 가장 유사하게 사용할 수 있는 프로그램이 설치되어 있는지 확인하십시오. 적어도 정보페이지에 잘 나타나 있을 것입니다.(기억사항 : 온라인 KDE 문서는 이러한 종류의 문서를 읽기에 제일 편리한 방법입니다.)
  • 번역에 도움이 되도록 번역 프로그램과 스크립트, 통계를 모으십시오.적어도 GUI 번역에 대해 UTF-8 인코딩 환경을 다룰 수 있는 프로그램이 필요할 것입니다. GUI 번역에 대해 추천하는 프로그램이 KBabel 입니다. 다른 프로그램들은 심한 두통의 원인이 될 것입니다. Unicode 와 관련된 부분을 보십시오. KBabel은 여타 다른 프로그램보다 번역자의 삶을 편하게 만들어 줄 수 있는 구별된 요소를 많이 가지고 있습니다.
  • (번역관리자로서의 역할을 한다면) 최종적으로 SVN을 친숙하게 다루십시오. (개인적인 번역을 하는 경우) 비동기식 SVN을 잘 하시면 됩니다. SVN(Subversion)에 대해 들어본 적이 없는 경우라면, 이것은 디렉터리와 파일의 버전을 제어하는 프로그램이라고 인식하십시오. KDE(또는 다른 많은 오픈소스 프로젝트)의 경우 인터넷을 통해 다른 사용자들이 SVN을 사용하여 파일과 디렉터리를 생성, 삭제, 변경, 제거합니다. KDE에서는 "SVN" 혹은 "KDE SVN"은 "svn.kde.org"라고 부르는 서버를 지칭합니다. 이 곳은 KDE와 관련된 모든 프로그램 소스코드, 문서, 번역에 관련된 모든 자료가 저장되어 있습니다. SVN 계정을 가지고 있는 사람들은 그들의 컴퓨터에 원격 시스템에 있는 소스 트리를 미러링한 SVN 서버에 연결할 수 있는 로컬 클라이언트를 설치합니다. 이 로컬 SVN 클라이언트 또한 원격 소스트리 시스템에 새로운 번역을 적용시키거나 저장하는 등의 일을 할 수 있습니다. 계정을 얻기 위해선 KDE Sysadmin에 사용자 이름과 암호화된 패스워드를 전달하여 계정 요청을 보내야 합니다. 이 작업을 어떻게 정확하게 하는지 튜토리얼을 보십시오. 규칙으로서 한 번역팀에 대해 하나의 계정을 줍니다. 그러나 물론 당신의 팀에서 하나 이상의 계정을 원한다면 더 승인할 수 있습니다. 만약 SVN에 대해 알지 못하거나 이를 잘 사용할 줄 모른다면 여러분이 설치한 SVN 패키지의 문서부분 중에 있는 'Subversion을 이용한 버전 제어'를 읽으십시오. 온라인에서 읽을 수 있다면 SVN에 관련된 온라인 핸드북을 읽으십시오. (이 책은 인쇄판 책으로도 시중에 나와있습니다.) 물론 프로그램 버전이나 관리자 목적으로 SVN을 사용하는 것이 아니라면 굳이 SVN에 대한 전체 장을 읽고 이해할 필요는 없습니다.



    만약 다른 오픈소스 프로젝트에 사용되기 때문에 CVS를 알고 있다면, 다른 관련된 문서를 읽는 것도 유용합니다. CVS to SVN 전환 가이드 등을 읽어보십시오. (이 또한 SVN 문서의 일부분으로 되어 있습니다.) svn 클라이언트의 주요 명령어는 다음과 같습니다:
    • svn checkout (원격 시스템으로부터 로컬 저장소에 몇몇의 버전을 얻기 위해 사용)
    • svn update (로컬 시스템에 있는 내용들을 단순히 갱신하기 위해 사용)
    • svn add (존재하는 새로운 파일이나 디렉터리를 버전관리에 추가하기 위해 사용)
    • svn remove (존재하는 새로운 파일이나 디렉터리를 버전관리에서 제거하기 위해 사용)
    • svn copy (파일을 복사하기 위해 사용)
    • svn move (파일을 이동하기 위해 사용)
    • svn commit (작업한 내용을 원격 시스템에 보내기 위해 사용, 이 작업은 "전달하기(commiting)이라고 불립니다.)
  • 이 문서의 문단을 쓰고 있는 시점에서도 설명할 수 없는 KDE 프론트앤드 그래픽 SVN 프로그램들이 있습니다. (특수한 릴리즈되지 않은 Kbabel의 개발버전과 새 SVN 지원 제공의 Cervisia 등...) 컨커러에서 몇몇 SVN 기능을 갖춘 (kdesdk 모듈의 일부인) KIO slave는 SVN에만 지원합니다.

실제 번역 시작하기


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

  • kdelibs.pot와 kdelibs의 모든 번역에 대한 임시 파일을 다운로드합니다. (이것은 예를 들어 WebSVN을 사용하여 할 수 있으며 최신의 리비전을 다운로드 할 수 있습니다.)
  • 이 파일을 여러분의 컴퓨터 로컬 디렉터리에 kdelibs.po 파일로 저장하십시오. (모든 번역된 GUI 파일의 끝에는 ".po"가 붙습니다. 원본파일에는 ".pot"가 붙으며 이것은 ".po 템플릿"을 뜻합니다.)

  • 번역을 시작합니다. (이 HOWTO의 GUI 항목과 다른 번역자들의 작업 내용을 검색하는 것은 때때로 유용할 것입니다.)

  • kdelibs.po로 완료를 하면, msgfmt 명령어로 확인을 해보십시오.
     msgfmt --statistics --check kdelibs.po
    
    여러개중의 대부분은 (문법을 확인하기 위해 정확한 .pot의 번역에서 .po 파일로) K바벨에 의해 자동적으로 완료될 것입니다. 일반 텍스트 편집기가 UTF-8을 지원하지 않는 반면에 K바벨이 UTF-8 또한 처리하기 시작하면서 KDE GUI 번역에 대해 추천받는 도구입니다. 이 영역에서 어떤 자유 번역 프로그램보다 더 유용한 요소를 갖고 있다고 해도 과언이 아닐 것입니다.

  • 첫번째 파일을 보낼 준비가 되었을 때, kde-i18n-doc 메일링 목록에 첨부 파일이 없이 짧은 이메일을 쓰십시오. 어느 누군가가 여러분이 작업한 파일을 원한다고 답변을 보낼 것이며, 그에게 파일을 보낼 수 있습니다. 이 사람은 여러분의 언어에 대한 새로운 디렉터리를 만들것입니다. (l10n/$LANG/) 또한 문서에 대한 디렉터리가 필요할 경우 po 파일에 대한 하위 디렉터리를 만들것입니다. 만약 이전에 답장받지 못했다면, 팀페이지에서 여러분의 언어에 대해 당신이 팀장으로 입력된 것을 확인하십시오.

    더욱이 만약 당신에게 답장이 오지 않았다면 당신은 entry.desktop 파일을 l10n/$LANG/messages에 만들고 추가할 필요가 있습니다. 이 entry.desktop은 다음의 두줄만 포함하면 됩니다.
    [KCM Locale]
    Name=Add_here_the_name_of_your_language_in_American_English
    


    KDE에서 언어코드의 문법은 RFC3066, 2장 3항에 기술된 내용에서 KDE 쪽이 대쉬(-)문자보다 밑줄 문자(_)를 사용한다는 것을 제외하고는 아주 비슷합니다. (예를 들어, KDE는 영국 영어에 대해 en_GB 라고 씁니다. 반면에 RFC 3066은 en-GB라고 씁니다.) 대부분 자주 RFC 3066을 사용한다는 것은 ISO 639-1로부터 언어에 대한 2문자 코드를 사용하는 것을 뜻합니다. 예를 들어, de 는 독일, fr은 프랑스 입니다. (ISO 639에 관한 위키피디아의 기사를 보십시오.)

    주의
    당신의 언어가 RFC3006에 등록되어 있지 않는 희귀한 경우(예를 들어, 당신의 언어가 작은 지역의 언어라서 등록이 안된 경우), INAN에 RFC3066, 3항에 기술된 형식으로 언어 코드를 등록하길 추천합니다. 어떠한 이유가 있어서 IANA에 당신의 언어를 등록하길 원치 않는다면, 'x-' 문자열로 시작하는 언어 이름을 사용하셔야 합니다.

  • (만약 팀이 없다면) 같이 일할 번역자를 모아 팀을 만들고, 작업을 분배하고 당신의 작업에 대한 효율적인 "하위구조"를 세우기 시작하십시오. 모든 것의 처음은 메일링 리스트를 만들고 여러분의 언어 팀에 의해 내부적으로 사용하기 위한 웹 사이트를 만드는 것입니다. 비록 기본적인 것이 될 것이지만 KDE로부터 두가지 모두를 얻을 수 있습니다. (리스트 서버는 많은 명령을 받아들이지 않을 것이고, 웹 사이트는 아직 CGI를 허용하지 않습니다.) 어쨌든, 관심이 있다면, i18n-server 의 웹마스터에게 접촉하십시오. 이것들을 구성하고 난 후, 때때로 이 HOWTO 의 "실무적인 힌트"에 보이길 원하실 것입니다.

  • 만약 GUI 번역이 평탄하게 잘 되어 당신의 팀에서 모든 것이 잘 구성된 것으로 보인다면, 당신은 문서 번역을 해야합니다. 당신은 i18n 서버의 문서 사이트에서 기본 정보를 찾을 것입니다. 이 HOWTO는 단지 여러분들이 진행하게될 과정의 대강을 제공할 뿐입니다.

  • GUI 번역팀들이 만들고 있는 진행의 대강이 HEAD 프렌치에 대해 KDE 번역의 상태 테이블에 공급됩니다. 이 데이타에 기초하여 KDE 릴리즈의 일부분으로서 어떤 언어를 선택할지 결정하게 됩니다. 릴리즈 버전에 대한 공식적인 규칙은 kdelibs.pot 의 90 %, desktop_kdelibs.pot와 desktop_l10n.pot의 100%, kdebase 의 75% 정도가 번역이 되어야 릴리즈로 채택됩니다. 그러나 보통 팀장이 "릴리즈 할 시기"가 언제인지 결정하고 릴리즈를 하는 사람들에게 알려줍니다.

지역화에 대한 화제


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

주의
다시 강조: 이 부분은 국가와 관련된 것이지, 언어와는 관계가 없습니다. 따라서 여러분의 언어가 여러분의 국가에서 "공식" 언어가 아니라면 아마도 이것에 관해 걱정하지 마십시오.

심지어 여러분의 언어가 국가의 공식 언어가 아니어도, 특정 국가와 관계되거나 몇몇의 국가와 약간의 연관이 있을 것입니다. 이 국가에 대해서 여러분의 국가 항목이 존재하는지 확인하고 때때로 빠진 항목을 추가하면 좋을 것입니다. 이것은 한 국가의 공식언어가 그 나라에서 통용되는 관습을 따르지 않으면서 다른 국가에서 사용될 경우, 즉 영어나 프랑스어와 같이 여러 지역에서 사용되는 경우에는 특별히 중요합니다. 물론 몇몇 언어를 같이 공용해서 사용한다면, 다른 언어팀 번역가가 그 국가에 대한 항목에 동의하는 것이 적절합니다.

주의
불행하게도, 만약 한 국가에서 다른 사용자가 한 언어에 대해 다른 설정을 사용한다면 이것은 KDE에 정확히 반영할 수 없습니다. 이것은 특별히 각 언어지역에 대한 정확히 번역된 철자법에서 "P.O. Box"를 표현할 수 없는 스위스나 벨기에 같은 국가에 대해서는 특별히 중요합니다. 만약 정말 필요하다면, KDE를 해킹할 수 있으며, 아직도 완벽하지 않은 국가에 대한 설정이 언어에 종속될 것입니다. (예로 제네바 P.O. box 에 대한 문자가 스위스의 프랑스어 사용 지역에선 항상 "Case Postale"인 반면, 독어를 사용하는 스위스 취리히 지역에선 "Postfach" 이 될 것입니다.)

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의 일부분으로서, 팀의 일부분으로서 일하십시오. 만약 잠시동안 떨어져서 일해야 하게 된다면, 여러분의 팀 사이트나 메일링 리스트를 통해 알게 하십시오. 만약 다른 일들이 바빠서 팀장의 일을 하기 어렵다면 다른 팀장을 찾아주시기 바랍니다. "자리"에 집착하지 마십시오. 당신의 작업은 보통 팀의 노력으로 완성된 것입니다. KDE 전체를 생각하십시오.
  • 만약 한 명 이상의 팀장이 있다면 각각의 팀장이 책임을 지는 영역이 어디인지, 주로 일하는 사람이 누구인지 사람들이 알게 하는 것이 좋습니다. (예를 들어, PO 파일, 문서, 웹사이트, 사용자 피드백, 버그 리포트 등...) 그리고 팀 내에서 팀에 관련된 분쟁이나 토론이 있다면 내부적으로만 유지하십시오. i18n 팀장들은 문제에 대해 중재해주거나 판결을 내려줄 개인적인 팀 문제에 대해서는 충분히 모릅니다.
  • "단독으로 일하지 마십시오"는 팀의 그룹이 어떤 목표를 가지고 있는지, 당신의 번역 작업을 어떻게 보고 있는지에 대해 팀장과 얘기하는 것을 뜻하기도 합니다. 만약 당신의 번역이 "일반적인 사용자(영업직과 관련된 사람을 포함하는)에 대한 것"이라면 컴퓨터 전문가에 대해 만들어진 번역과 다르게 보일 것입니다. (보통, KDE는 "컴퓨터 도사"들만을 고려하지 않습니다.) 많은 경우 여러분의 팀이 제시하는 대로 개발을 시도해 주십시오.
  • 표준적인 요소에 대해 표준 번역을 찾으십시오. 그리고 그것을 고정하십시오. 이러한 관점에서 i18n.kde.org/po_overview 에서의 함축된 PO 번역(또한 "요약 파일"로 알려진)들은 매우 유용할 것이며, 이러한 파일을 찾거나 일관성을 확인하는데 도움을 줄 수 있는 비교될 수 있을 의미를 제공하는 번역 프로그램에 특별할 것입니다. 또한 웹 포라와 메일링 리스트의 단어와 사전을 잘 사용하도록 합니다. 그러한 단어 목록을 관리하는 아주 흥미있는 도구는 Matthias Kiefer의 kdedict 입니다.
  • 모두가 수용한 규칙을 확인하기 위해 "상호 교정"의 시스템을 개발하십시오. 이것은 때때로 민감한 사안이 될 수 있습니다. (따라서 너무 토의하지 마십시오.), 그러나 이것은 오래봤을 때 실수한 철자와 메카니즘으로 인해 나타나는 어리석은 오류를 수정하는 데 최고의 수단으로 공급될 것입니다.
  • 주어진 프로그램에 대해 온라인 도움말의 번역과 GUI 번역을 같은 사람이 하는 것도 좋은 생각입니다. 만약 이것이 불가능하다면, 최종 문서, 스크린 샷을 감수하는 사람이 하는 것이 좋습니다. 그래서 "같은 언어"로 온라인 도움말과 GUI 인터페이스, PO 파일등을 일치하도록 해야 합니다. 문서와 메뉴의 단어가 다른 경우 사람들에게 큰 혼란을 일으킵니다.
  • 각 GUI 와 문서 번역에서 지적되는 지점에 적절한 문법 확인을 하지 않고 SVN에 파일을 보내지 마십시오. 다시 문법과 다른 부분을 확인하는 메카니즘을 공급하는 특별한 프로그램(GUI의 PO파일과 문서 번역에 대한 K바벨과 같은 프로그램)을 강력히 추천합니다.

당신의 작업에 대한 인증 얻기


자유 소프트웨어의 사람들 대부분이 아무런 댓가 없이 작업을 잘 해줍니다. 게다가, 그들은 작업의 몇몇 지식을 보기를 좋아합니다. 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 장. GUI 번역


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 파일들


번역에 대한 템플릿을 제공하기 위해, 프로그램의 영어 메뉴와 대화상자 텍스트가 .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", 등등의 언어 코드에 대한 약어입니다.)

GUI 번역에 대한 할 일(To-do) 목록


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

  • [http]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.)

Step by Step: POT 와 PO 파일들의 번역


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:
msgid "" msgstr "" "Project-Id-Version: Some Program\n" "POT-Creation-Date: 2005-08-23 02:43+0200\n" "PO-Revision-Date: 2005-08-28 12:25+0200\n" "Last-Translator: Somebody <null@kde.org>\n" "Language-Team: Some Language <kde-i18n-doc@kde.org>\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "X-Generator: KBabel 1.11\n" "Plural-Forms: nplurals=2; plural=(n != 1);\n"

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:

#: kedit.cpp:90 kedit.cpp:1071 msgid "Show &Status Bar" msgstr ""

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

#: kedit.cpp:90 kedit.cpp:1071 msgid "Show &Status Bar" msgstr "&Statusleiste anzeigen"

And from the incorrect:

#: ReniceDlg.cpp:31 #, fuzzy msgid "Renice Process" msgstr "Laufende Prozesse"

...you would produce the correct translation:

#: ReniceDlg.cpp:31 msgid "Renice Process" msgstr "Neue Prozessprioritaet"

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:

#~ msgid "Where do you want to go tomorrow?" #~ msgstr "Where do you want to go tomorrow?" #~ msgid "No comment available" #~ msgstr "Keine Erklung verfbar"

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

특수성과 차이점


Caution

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:


#: kdeui/kstdaction.cpp:669 msgid "" "_: beginning (of line)\n" "&Home" msgstr "&Dateianfang"

#: src/kernel/qaccel.cpp:562 msgid "" "_: QAccel\n" "Home" msgstr "Pos1"

  • Special characters such as quotes must be "escaped" (i.e. preceded with a backslash), if you want to use them as part of the text (see example below). Unescaped quotes will be interpreted by the programs which read the file as the end of the "msgstr". The test routine msgfmt --statistics --check, described below, would terminate at this point with an error. The syntax highlighting and the check routines in KBabel will help you with the handling of these special characters.


#: cardmaps.cpp:105 #, c-format msgid "kpat: PANIC, cannot load card pixmap \"%1\"\n" msgstr "KPat: schwerer Fehler, kann Kartenbild \"%1\" nicht laden\n"

  • One problem which languages with longer than average words (German, for example, is notorious here) sometimes encounter is dialog boxes which are too small, cutting off or cramming together translated text. This is one of the things that can only be determined for sure by checking the translations in the compiled program. The obvious, but always temporary, solution is to "keep it short." You would basically do this if there were no more time to pursue the proper solution, namely contacting the author of the program so that he/she can adjust the geometry of the offending boxes. In any case, an email describing the problem should be sent to the author or even better create a new bug report in KDE Bugs.
  • Sometimes English text appears in the program interface even though the PO file has been completely translated, and the text in question cannot even be found there. One way this can happen is when the text comes from "somewhere else" (often from kdelibs which can be found throughout the KDE interface, sometimes from separate modules of the same program that have extra POs). Another possibility is that this particular text has not been made "i18n conform" by the author. Any strings which should be seen by the user are supposed to be passed to the C++ function QString i18n(const char *text). This ensures that the properly localized version of a string is shown (assuming there is a translation). Thus, it is only possible to translate texts which have been prepared in this manner. In cases where the untranslated text cannot be found in the PO file the author may have forgotten to do this. If you want to know for sure, you need to look in the source to the program; for example, you can find out the filename and line number by using grep -n "text in question" *.cpp in the source code folder. Anyway, if you discover such a case, please file a bug at bugs.kde.org or write the author of the program. Do not just leave the problem unmentioned.

GUI 번역에 대한 특별한 프로그램을 사용하기


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.

KBabel


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

==== (X)PO Mode의 Emacs====

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.

Syntax Check: msgfmt --statistics --check


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.

Tip

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.

Committing Your Work to SVN


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.

Note

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

SVN Conflicts


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:
Date: Wed, 05 Jan 2000 15:33:17 +0100 From: Stephan Kulow <coolo@kde.org> To: kde-i18n-doc@master.kde.org Subject: Re: Errors?

Marko Rosic wrote:
msgid ""
msgstr "" <<<<< kdelibs.po "Project-Id-Version: PACKAGE VERSION\n" "POT-Creation-Date: 1999-12-06 00:59+0100\n" "PO-Revision-Date: 1999-12-30 20:22+0100\n" "Last-Translator: Strahinja Radi <E6> <rstraxy@sezampro.yu>\n" "Language-Team: Serbian <LL@kde.org.yu>\n" ======= "Project-Id-Version: kdelibs\n" "POT-Creation-Date: 1999-12-30 00:53+0100\n" "PO-Revision-Date: 1999-08-23 12:57+0100\n" "Last-Translator: Marko Rocic <roske@mainstream.co.yu>\n" "Language-Team: Serbian <sr@li.org>\n"
1.21
"MIME-Version: 1.0\n" "Content-Type: text/plain; charset=iso-8859-2\n" "Content-Transfer-Encoding: ENCODING\n"
What does this mean? Which do I need to delete?
Depends. The portion between <<<<< and ====="=" is your version and the one between ===="=" and >>>>>> is the one in CVS. I would say merge them :)

Greetings, Stephan

Note

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

Note

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

Chapter 4. Doc Translation


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

Checking the Markup and the Spelling What to Do with Translated and Corrected Documentation?

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

General Requirements for Doc Translation


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.

POT and PO Files Used for Documentation


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.

Caution

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)

To-do Lists for Doc Translation


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.

Step by Step: The Translation of Documentation Files


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):

Important

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.

Important

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

Caution

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

Important

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.

Peculiarities and Difficulties


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:
"... volume of your" sound card."
would otherwise become:
... volume of yoursound card.
  • Between <keyword> and </keyword> only text is allowed, for example <keyword>&kmidi;</keyword> is not valid. It has to be <keyword>kmidi</keyword> instead.
  • The screenshots should always show the current appearance of the GUI.
  • One word of advice: Do not translate word for word or sentence for sentence literally. Try to translate the meaning. Read a complete section and translate it.

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:
msgid "CREDIT_FOR_TRANSLATORS" msgstr "" "<para>Translation FIRSTNAME1 LASTNAME1 " "<email>EMAILADDRESS1<email></para>" "<para>Correction of the Translation FIRSTNAME2 LASTNAME2 " "<email>EMAILADDRESS2</email></para>"
and
msgid "ROLES_OF_TRANSLATORS" msgstr "" " "role=\"translator\"><firstname>FIRSTNAME1</firstname><surname>LASTNAME1 me>" "<affiliation><address><email>EMAILADDRESS1</email></address></affiliation>" "<contrib>Translation</contrib></othercredit>" " "role=\"translator\"><firstname>FIRSTNAME2</firstname><surname>LASTNAME2 me>" "<affiliation><address><email>EMAILADDRESS2</email></address></affiliation>" "<contrib>Correction of the Translation</contrib></othercredit>"
  • In KBabel the quotation marks (") have a special meaning. On the other hand you need them at several places in the markup or the normal text. In such cases you have to "escape" them with a backslash. In the above example in the markup you find:
"...role=\"translator\"...
instead of
"... role="translator"...
KBabel helps with this because if you hit the quotation mark key on the keyboard KBabel actually inserts a backslash before the quotation mark automatically.
  • & in the msgid is used in the GUI translation as the mark for a shortcut to a menu entry. So to help with this KBabel highlights the msgstr as wrong if this character is not balanced between msgid and msgstr (actually KBabel tries to guess if you translate GUI or documentation but for this guess it is not always enough information available). For documentation this balancing is no longer true and can lead to a highlighted msgstr even though the msgstr is correct. For translation of documentation you can turn this feature off (Settings->Configure KBabel... and Edit, General, Change text color on error).

What else to watch out for in the translation process?

Organization and syntax:
  • If the documentation is missing something or is not up to date with the current GUI you should contact the author of the original documentation and ask him or her to add the missing part in the original documentation. (In case (s)he is unavailable you may also contact the documentation coordinator.) Your possibilities to differ from the original are very limited since the markup has to be consistent with the English documentation and the structure of the document must match the English version. So if you want e.g. to add one paragraph in the translation, it is best to ask the author to add that paragraph in the original. That gives you an additional msgid to translate. For special cases there is a possibility to add paragraphs, that only exist in the translated documentation but not in the English original. However this should be used with care. Two msgids, that represent text, which does not exist in the English document are CREDIT_FOR_TRANSLATORS and ROLES_OF_TRANSLATORS. They are generated by a special comment in the English documentation. You will find the lines
<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
and
<!-- TRANS:ROLES_OF_TRANSLATORS -->
This are XML comments and are not displayed in the English documentation. split2po however generates msgids for this two comments and po2xml fills the msgstrs into the translated doucmentation. This feature can be used to fill in more paragraphs that are only needed for the translated documentation. Every comment in the English documentation, that is of the above form leads to a msgid.

Important
You have to watch out for the correct markup, so that your translated msgstr fits into the context.
  • Work as closely as possible together with the GUI translator of the respective application if you cannot translate the GUI yourself (which would be advisable). Always make sure the terms in the GUI and the documentation for the same program are the same for the same elements.
  • For the program name you should use the entity that is defined for this program. For example the program KApp will have the entity &kapp; defined. You should always use that to make sure the name is written in a consistent way.
  • Screen shots and all other pictures have to be in the PNG format (Portable Network Graphics) because of patent licensing issues with the former GIF format. In other words: GIF pictures must not be used.

Style:
  • Each translation team should probably have some basic style guides which sets the tone for the texts, determines how to address the user and so on. The technical terms of the GUI should be translated in a consistent manner (like button, menu, tab, ...). To help with this, there is the visual dictionary in the KDE help center. So once these items are translated the terms should be used consistent by all translators of your language.
  • KBabel has a translation database. This database collects all msgids and msgstrs you translate to make the diff feature work. It is a good idea to put the translations of all other translators into this database as well. This is also a great help to keep consistency (Settings->Configure Dictionary->Translation database).
  • There exists also the web based KDE Dictionary database with translations that you can use for your language.

Checking and Committing Your Work


Checking the Markup and the Spelling


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:
update_xml de kdemultimedia
or the German translation application aktion:
update_xml de 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.

Note
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
yourself and generate the docbook file. For this to work po2xml needs the English docbook file (usually located in the doc/ subdirectory of the package containing the program with the name index.docbook) and the translated PO file. The syntax is: po2xml English.docbook translated.po
translated.docbook This generates the translated.docbook
file. In the header of the generated file you have to specify your language, i.e. if your language was "German" change the line
<!ENTITY % English "INCLUDE" ><!-- change language only here -->
like this:
<!ENTITY % German "INCLUDE" ><!-- change language only here -->
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.

Important
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.
  • Error correction: Keep in mind that you need to correct the errors in the PO file, because the docbook file is autogenerated from this. Start corrections from the beginning of the document, because one error may result in a chain of subsequent errors. If you get errors about some file "dtd/kde.dtx" that could not be found, check that the needed version of meinproc is called. (If you realize that your self-compiled KDE is missing a new meinproc, check the BZip2 library and recompile kdelibs.)

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.

Note

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

What to Do with Translated and Corrected Documentation?


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.

Chapter 5. Bug Reports and User Feedback: Handling and Translating


Table of Contents

Handling Translation Bugs

Submitting Bug Reports Closing Bug Reports Followup Messages

Caution

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

Handling Translation Bugs


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):

Submitting Bug Reports


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:

i18n-de Thomas Diehl <thd@kde.org>

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

Closing Bug Reports


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.

Followup Messages


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.

Chapter 6. Web Site Translation and Design


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.

Web Sites for Internal Use


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

Web Sites for KDE Users


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.

Chapter 7. Tools and Resources for KDE Translators


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

...for GUI Translation ...for Doc Translation

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.

The i18n Server


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)

SVN WebSVN...


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.

Mailing Lists, IRC, and On-line Fora


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.

Web and FTP Sites


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

Statistics


Caution

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.

HOWTOs and Info Sites


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.

Specialized Programs and Modules


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.

...for GUI Translation


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.

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

Dictionaries and Tools for Consistency Checking


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.

Appendix A. The l10n Modules


Table of Contents

Overview Directories of the l10n Module How To Translate?

Overview


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.

Directories of the l10n Module


l10n/templates/messages
Place of the translation template files for the GUI.

l10n/templates/docmessages
Place of the translation template files for the documenation.

l10n/templates/webmessages
Place of the translation template files for some of KDE websites.

l10n/$lang/messages
Place of the translation files for the GUI.

l10n/$lang/docmessages
Place of the translation files for the documentation.

l10n/$lang/docs
Place of the translated documentation.

l10n/$lang/webmessages
Place of the translation files for some of KDE websites.

l10n/$lang/internal
Place for internal files of the translation teams, e.g. for the compendium file. The files in such a directory will never be released.

l10n/documentation
Place for the untranslated original English DocBook documention files. The sub-directories of this directory are external reference to the doc sub-directories of the corresponding modules.

l10n/scripts
Place for internal script files of the l10n module.

How To Translate?


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.

Note

You can get files via SVN or WebSVN.

Appendix B. Quick CVS Overview


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

Note

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.

Appendix C. Thomas Diehl's Acknowledgements


Note

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.



sponsored by andamiro
sponsored by cdnetworks
sponsored by HP

Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2006-10-11 01:12:17
Processing time 0.1312 sec