비영어권 개발자의 다국어 관련 슬픈 현실

개인적으로 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 같이 모조리 뽑아서 사용하는 건 아닌것인가?

에궁