오픈램프 : 오픈소스 전문 팀블로그 :: [강좌] 오픈소스 프로그램 한글화하기

본 글은 필자가 개인 블로그에 올렸던 글로, 최근 시리즈로 글을 이어내면서 이곳에 다시 정리해서 쓰는 글이다. 강좌라고 하기에는 창피한 글이지만, 꼭 필요한 글이라 생각되어 이곳에 올린다.

프로그램 한글화 과정은 크게 네 가지로 나눌 수 있다.

- 오픈소스 프로그램 한글화하기 - 1 : i18n 방식 파악
- 오픈소스 프로그램 한글화하기 - 2 : 실제 번역
- 오픈소스 프로그램 한글화하기 - 3 : 번역 테스트
- 오픈소스 프로그램 한글화하기 - 4 : 개발팀에 패치 전달

번역에 관심있는 많은 사람들이 1번에서 많이 포기하고, 4번을 하지 않아 애써 번역한 것을 사장시키는 경우가 많다. 따라서 이 전 과정을 모두 설명함으로써 번역에 관심이 많은 사람들의 참여가 조금 더 활발하게 이루어지기를 기대해 본다.

1. i18n 과 l10n

Internationalization : 번역하기를 "국제화" 라고 한다. 이 단어는 패키지화 된 프로그램이 있을때 그 프로그램이 다양한 언어를 지원하도록 만들어진 것을 의미한다. 이는 다시말해 영어로 된 문자열을 사용하여 이루어지는 행동과, 영어 이외의 다른 언어로 이루어지는 행동이 "차이 없는" 일반화 과정(Generalization process)이라고 할 수 있다. 프로그램 개발자는 자신의 프로그램에 국제화를 적용할때 다양한 기술을 사용할 수 있는데, GNU gettext는 이들 표준중에 하나를 제공하는 것이라고 할 수 있다.

Localization : 번역하기를 "지역화" 라고 한다. 지역화는 국제화(I18n)가 모집합인 집합 구성원으로 (쉽게 말해 이미 국제화가 된 소프트웨어만 국제화를 진행 할 수 있다는 뜻이다), 관련된 정보를 특정 지역의 언어/문화에 관련된 행동양식에 맞추어 (예를 들자면 화폐단위, 지역시간 등) 사용할 수 있게 하는 것이라고 할 수 있다. 이는 특정방법으로 이미 국제화로 일반화된(Generalized) 프로그램을 부분화시키는 작업이라고도 할 수 있다. 이들 지역화의 구분은 특별한 환경 변수를 바탕으로 프로그램 실행전에 "어느 로케일에서 사용되고 있는지"를 파악, 실행시간대에 그것을 적용하게 하는 것이다.

-from 그놈한국, Gettext를 사용한 I18N 학습서

쉽게 말해
i18n = Internationalization = 프로그램 만들때 다국어를 지원하도록 만든 것.
l10n = Localization = i18n 이 지원되는 프로그램에 다국어 모듈을 넣는 것.

2. i18n 방식

기본적으로 우리는 i18n 이 지원되는 프로그램, 즉 다국어를 지원하는 프로그램을 가지고 l10n, 즉 한글화를 해야한다. 다국어 지원도 안되는데, 리소스핵 등의 프로그램으로 한글화하는 것은 여기서는 논외로 한다.

i18n 을 구현하는 방식에는 다음과 같은 것들이 있으며, 이를 구분하는 방법은 해당 프로그램이나 소스의 파일을 보고 알아내야 한다. 언어팩 관련 파일은 po, language, lang, nls(Native Language Support) 등의 디렉토리에 저장되는 것이 일반적이며, 해당 디렉토리에 있는 파일들의 확장자를 보고 어떠한 방식을 사용하였는지 유추한다.

GNU gettext : GNU/Linux 로 대표되는 오픈소스 계열의 경우 대부분 GNU gettext 를 이용. 여기에 사용되는 파일은 .po .mo 등이 있으며, 사용되는 프로그램은 msgmerge, KBabel(KDE), Gtranslator(GNOME), PO Mode(EMACS), poedit 등이 있다.
Text file : 텍스트 파일로 i18n 을 구현한 프로그램도 꽤 볼 수 있는데, 이럴 경우 특별한 프로그램없이 메모장등의 간단한 텍스트 에디터로 언어파일을 만들거나 수정할 수 있다. 필자가 번역한 TYPsoft FTP server, Infra Recoder, Deepburner, Notepad++ 등 많은 프로그램들이 이러한 방식을 사용하고 있다.
QT : KDE 쪽의 QT 를 기반으로 하는 프로그램에서 자주 사용되는 형식으로, gettext 와 자유로운 변환이 가능하다. VirtualBox 나 scribus 등에서 사용하고 있다.

3. 그 외..

언어 파일이 텍스트 파일로 되어 있을 경우주[footnote]이를 확인하는 가장 쉬운 방법은 메모장 등의 텍스트 에디터로 열어보는 것이다. 글자가 온전히 보이면 텍스트 파일로 된 것이다. -_-;[/footnote] 두 가지를 염두에 두어야 한다.

문자 인코딩 : 문자의 포맷이 ASCII 냐, UTF-8 이냐, 아니면 다른 방식인가하는 것을 알아두어야 한다. 애써 번역했는데, 인코딩이 안 맞아서 글자가 깨져나온다면 굉장히 속상한 일이 될 것이다.
파일 형식 : 이는 정확히 말하자면, OS간 파일 처리에 대한 부분이다. 텍스트 파일의 다음줄을 표현함에 있어 DOS 에서는 cr과 lf 두 바이트로 표현하는데 반해, 리눅스에선 lf 만 사용하므로, 이러한 차이가 차후에 문제가 될 수 있다. 하지만 근래의 고급 텍스트 에디터들은 이러한 형식을 자동으로 인식해주므로 사실은 크게 신경쓰지 않아도 되는 부분이다.

그 외로 전혀 알 수 없는 형식으로 i18n 을 구현한 프로그램을 접하게 되면, 포기하는 것이 정신건강에 이롭다. -_-; 아니면 프로그램 제작자에게 메일을 보내라. 정중한 표현으로 부탁을 하면 l10n에 필요한 것들을 보내주거나 참고할만한 문서를 알려줄 것이다.

프로그램 제작자와 연락이 안된다면.. 역시나 l10n 은 포기해야 한다. 개인적으로 컴파일해서 배포하는 것은 한계가 있기 때문이다. 하지만 그럼에도 불구하고(예를 들어 너무 좋은 프로그램이나, 프로그램 개발이 중단되었다던가.. 하는 경우) 꼭 한글화를 해서 배포를 하고 싶다면, 앞서 말한 것과 같이 언어 파일의 확장자를 가지고 구글신에게 기도하는 수밖에 없다. Good luck!

4. 마지막으로..

모든 일이 그러하듯 처음의 마음가짐과 그 마음가짐을 끝까지 이어가는 것이 그 무엇보다 중요하다. 어설픈 마음으로 시작해서 하다가 그만두는 것은 아예 시작하지 않은만 못하다.

하지만 필자는 "그럼에도 불구하고" 일단은 시작해보라. 라고 말해주고 싶다.

잘난체 하고 싶어서여도 좋고, 필자처럼 심심해서 시간때우기용이어도 좋다. 영어를 못해도 좋고, 필자처럼 번역기로 돌린지 의심받아도 좋다. -_-;

그것은 당신이 어떤 프로그램을 한글화하기로 마음먹었다면, 이미 당신은 기본적인 마음가짐의 자세를 갖추고 있기 때문이다. 그것만으로 충분하다. 그것을 끝까지 마무리지을 것인가, 아니면 중도에 포기할 것인가, 그리고 꾸준한 교정을 통해 번역의 질을 높일 것인가, 한번 하고 잊어버릴 것인가는 그 이후의 문제이다.

참고로 필자는 그렇게 시작한 김프 매뉴얼 번역을 2년째하고 있다.
지금까지 1/4 했으니까 최초 완역까지 6년 더 남은건가 ㄱ-

Writer profile