다국어 관리팀이 분리되어 있는 조직에서 개발 방법은 다음과 같은 두 가지일 것입니다.

  • 다국어 처리를 위해 개발자는 pot를 만들고, poEdit 를 이용하여 작업하는 그룹은 그들이 가지고 있는 po file에 pot를 merge하여 작업을한다.
    - 즉, 다국어 처리 그룹은 merge의 개념을 알고 있다.
  • 다국어 처리를 위해 개발자는 pot를 만들고, 이를 po file에 merge하여 나온 po file을 poEdit 를 이용하여 작업하는 그룹에게 전달한다.
    - 즉, 다국어 처리 그룹은 번역만 주로한다.

po file의 포맷은 단순히

msgid "I am Hojin"

msgstr "나는 호진 입니다."

와 같은 번역 텍스트의 나열일 뿐입니다.

여기에 참조된 위치에 대한 정보가 주석으로 들어 있거나 여러 행으로 되어 있는 문자열인 경우에 대해서 복수의 행으로 표시할 수 있도록 허용됩니다. 이러한 허용 때문에 줄바꿈이 일어나면서, 형상관리에 어려움이 있는데, 그것은 xgettext(po 파일을 소스로부터 만들어주는 툴)와 msgmerge (어느정도 번역이 되어 있는 po 파일에 새로운 번역 대상문을 추가해주는) 프로그램으로 생성되는 파일이 윈도우의 poEdit와 한 줄로 표현할 것을 여러줄로 표현하는 차이가 있기 때문입니다.

따라서 어느 한 쪽에서 변경한 것이 subversion 등으로 관리하는데, 상당량 같은 내용을 포맷이 다르다는 이유로 다르게 취급하는 상황이 발생하게되고, 이런 짜증스러운 일을 해결하기 위해 하나 만든것이 linux 환경에서 poEdit와 같은 형식으로 바꿔주는 툴이다.

이른바 "poedit_friendly.pl"(클릭으로 다운로드) 이름 좀 괜찮습니까? ;) 이 프로그램을 xgettext나 msgmerge를 한 뒤 바로 수행해 주면 되고, 주로 Makefile에서 po를 만들어 내므로 쉽게 적용할 수 있으리라 봅니다.

사용방법은, 표준입력으로 po file을 넣어 주면, poedit에 친절한 po file이 나옵니다.

참고로, poEdit의 po file은 다음과 같은 특징이 있습니다.

  1. 모든 주석은 한 줄에 하나씩, 즉 참조하는 파일 위치가 여러개일 경우 한 줄에 하나씩 주석으로 달립니다.
  2. msgid, msgstr 내에 \n을 만나면 두 줄로 만들어 저장합니다. 즉,
    msgid "I am Sam\n"
    "You are Lucy"
    msgstr "나는 샘이다.\n"
    "나는 루시이다."
    위와 같은 형식으로 만들어 집니다.

반면 gnu의 xgettext, msgmerge 는 다음과 같은 특징이 있습니다.

  1. 모든 주석 및 msgid, msgstr은 가능한 한 줄로 씁니다.
  2. 만약 주석이나 msgid, msgstr이 한 줄에 80자를 넘어가면 80자를 넘기는 단어에서 끊고 다음줄로 넘깁니다. 즉,

    msgid, "Picture yourself in a boat on a river\n With tangerine trees and marmalade skies\n"
    "Somebody calls you, you answer quite slowly\n A girl with kaleidoscope eyes"

    위와 같이 적절히 나뉘게 됩니다.

xgettext에 --no-wrap 옵션을 쓰면, 80줄 마다 다음줄로 내리는 형식을 사용하지 않게 되고, 모두 한 줄에 나열합니다.

-- end --

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
  1. Mr.Dust 2008.06.16 13:33 신고

    본문과는 관계없지만 xgettext 에 대해 질문하나 드립니다.
    프로그램 소스로부터 pot 파일을 생성하고 싶은데, 잘 안되네요. 관련지식이 전무해서..
    우선 현재 시도중인 것은 blender 이며, 차후 gimp 같은 비슷한 프로그램들에 대해 pot 파일을 추출해내고 싶습니다. 뭐 이유는 po 파일 업데이트를 위해서이지요. ;;; 어떻게 해야할지 힌트라도 부탁드리겠습니다. 제가 사용하는 환경은 우분투이고, 윈도에서는 cygwin 을 쓰고 있습니다.

    • 최호진 2008.06.16 17:25 신고

      xgettext -k 옵션을 잘 줘야합니다. -k _ 라든지 -k __ 라든지, gettext를 _, __, _t, _text, _T 등으로 define하여 사용할 경우 -k 옵션을 줘야하지요.

    • Mr.Dust 2008.06.17 21:29 신고

      무슨 말씀인지 전혀 알아듣고 있지 못하고 있습니다.
      역시 너무 과도한 욕심이었나 봅니다. ㅠ.ㅜ
      일단 번역이나 열심히 해야지.. ;;;

    • coolengineer 2008.06.18 02:00 신고

      xgettext가 하는 일은 소스에서 함수의 인자 부분에 해당하는 문자열을 추출하는 것이라서요. 그런 함수를 지정하는 일에 대한 말쌈입니다.

개인적으로 Open Source 프로그램을 번역하는 일은 그 프로그램에 애정이 있어서 하는 일이므로, 즐겁고 나로 인해 영어로된 프로그램을 한글화 한다는 자긍심도 생기기 마련이다. 그러나 밥먹기 위해서 하는 일로 국제화된 프로그램을 만드는 일은 이것과는 약간 슬픈(?) 현실이 있다.

지역화와 관련해서 지역 표시는 다음과 같은 표시방법을 따른다. 예를 들어 몇년전까지만해도 우리나라의 웹사이트는 다음과 같은 지역표시를 가지고 있었다.

ko_KR.euckr

이것은 한국어(ko)로 되어 있고, 지역(territory)이 한국(KR)이며, 문자 집합은 euckr(한글을 위한 확장 유닉스코드)이라는 뜻으로

언어_지역.문자집합

으로 표시한다. 그리고 뭔가 수정이 일어나면 뒤에 "@수정명칭" 형식으로 회사, 개인, 기타 의미 있는 문자를 붙일 수 있다.

회사에서 국제화된 프로그램을 작성할 때 방법은 다음과 같다. 문자 집합은 utf-8을 사용한다.

1. 프로그램을 작성한다.
2. 다국어 지원을 해야하는 문자열은 영어로 작성한다. 이 문자열을 key로 번역 string을 만들기 때문이다.
3. 영어로 작성된 문자열은 gettext("....") 형식의 함수 안에 넣는다. 혹은 gettext 를 "_" 하나로 define 하여 작성한다.
4. 다국어 작성된 문자열을 xgettext 라는 유틸리티로 문자열들을 뽑아 낸다.
5. 뽑아서 만들어진 pot, po를 번역팀에 넘기고, 이들은 poEdit를 이용하여 번역한다.
6. 번역되어 나온 ko_KR 한글, ja_JP 일어, zh_CN zh_TW 중국어 po 파일들을 mo 파일로 컴파일하거나 적절한 javascript로 변환하는 유틸리티로 만들어 다국어 릴리즈에 포함한다.

즉, 혼자 Open source 프로그램을 번역하는 일에 해당하는 5 번일을 프로그래머가 아닌 전문 번역팀이 하게되는 것인데, 이들은 영어에 전문가이므로 프로그래머들이 말도 안되게 작성된, 그러나 바뀌어서는 골치아픈 2 번의 프로그램 소스부분에 대한 수정을 요구한다. 왜냐, 개발자들이 콩글리쉬(konglish)로 만들었기 때문이다!!!

한국에서 사용될 것 같은 영어! 공식적인 지역표시에는 없는 en_KR 이라는 것이 우리들에게는 실제하는 것이다!!

내가 슬픈 현실이라고 말하는 것은, 다음과 같은 프로세스여야하기 때문이다.

1. 프로그램을 작성한다.
2. 다국어 지원을 해야하는 문자열은 en_KR 영어로 작성한다.
3. en_KR 영어로 작성된 문자열은 gettext("....") 형식의 함수 안에 넣는다. 혹은 gettext 를 "_" 하나로 define 하여 작성한다.
4. 다국어 작성된 문자열을 xgettext 라는 유틸리티로 문자열들을 뽑아 낸다.
5. 뽑아서 만들어진 pot, po를 번역팀에 넘기고, 이들은 poEdit를 이용하여 번역한다.
6. 번역되어 나온 en_US 영어를 기반으로 en_KR로 되어 있는 소스를 바꾼다.
7. en_US 로 만들어진 pot, po를 다시 번역팀에 넘긴다.
8. 번역되어 나온 ko_KR 한글, ja_JP 일어, zh_CN zh_TW 중국어 po 파일들을 mo 파일로 컴파일하거나 적절한 javascript로 변환하는 유틸리티로 만들어 다국어 릴리즈에 포함한다.

국제화를 지원하는 유틸리티 xgettext, poedit 들은 소스를 전혀 건드리지 않는 상황에서 만들어진것이다. 당연한것 아닌가, 영어권에서 만들어졌으니, 6 번같이 소스의 문자열이 바뀌는 프로세스는 고려되지 않는 것이다.

쩝... 조금 슬프지...

그렇다고 메시지를 한글로 만들고, 한글로 모든 다국어의 key로 사용하는 것도, 사실 일반적인 것이 아니라서 어*렵*다.

----

영어권 이놈들은 개발자들의 모든 메시지를 감수팀에 의해 다시 고치는 일을 하지 않을까? 하더래도 poedit 같이 모조리 뽑아서 사용하는 건 아닌것인가?

에궁

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
내가 하는 번역중 가장 활발하게 일하는 것이 TortoiseSVN이다. 비록 번역이긴하지만 Open Source에 기여하고 있고, 나름 대로 feedback을 받으며, 내 활동의 일부를 도움받는다.

feedback은 딱 한 사람으로부터 오는데, tdkim 씨이다. 이 자리를 빌어 꾸준히 피드백해주고 있어 감사하다는 말을 하고 싶다. 이 분은, 시간날 때마다 TortoiseSVN의 nightly build를 받아다가 버그리포트도 활발히 하는 분인데, 재미를 가지고 있는 소프트웨어에 그런 열정을 들이는 것이 이런일하는 재미아니겠는가.

Tdkim!
제게 번역 교정 리포트하시는 것에 미안하게 생각하지 말아주시라.
맞닥드리지 않은 상황을 번역하는 것이 어려운것이 사실이고, 가끔 자동 번역 결과를 확인도 안하고 커밋하는 우를 범하기도 하지만, 걱정되지 않는 것은 이렇게 피드백하시는 분들이 계시기 때문아니겠는가!

감사하다.
다시 한 번 감사하다.
언제 만나면, 션한 음료수 한 잔(?)하시자..!
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

+ Recent posts