[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
gettext
의 목적보통 프로그램은 영어로 만들어 지고, 영어로 문서화된다. 또 프로그램을 실행할 때 사용자와 정보를 주고받는 언어로 영어를 사용한다. 이는 GNU 소프트웨어뿐만이 아니라, 상당수의 상업용, 자유 소프트웨어의 경우에도 마찬가지이다. 어떤 공통된 언어를 사용하면 전 세계에 흩어져 있는 개발자, 관리자, 그리고 사용자 사이에 의견을 교환하기가 대단히 편리하다. 하지만 다른 한편으로, 대부분의 사람들은 영어보다는 자신의 모국어를 더 편하게 사용하고, 일상적인 생활에서는 가능한 한 모국어를 사용하려고 한다. 당연히 많은 사람들은 컴퓨터 스크린에 영어가 좀 더 적게 보이고, 모국어가 더욱 더 많이 보이기를 바랄 것이다.
그러나, 많은 사람들에게 이러한 꿈의 실현은 너무 멀리 있는 것처럼 보이고 어쩌면 그런 일을 생각하는 데 시간 낭비할 필요조차 없다고 할 지 모른다. 사람들은 그 꿈이 과연 앞으로 실현될 지도 확신하지 못한다. 하지만 몇 사람들은 희망을 잃지 않았고, 그 몇 명이 모였다. 번역 프로젝트(The Translation Project)는 이런 희망들을 쳬계적으로 정리해서, 효과를 거둘수 있도록 만든 조직체이며. 우리 모두가 참된 다국어 프로그램의 실현에 좀 더 가까워질 수 있는 좋은 기회이다.
GNU gettext
는 번역 프로젝트가 내딛는 중요한 한 걸음이다. GNU
gettext
는 이 프로젝트의 또 다른 발걸음들을 내딛기 위한 밑천이기
때문이다. 이 패키지는 프로그래머, 번역자, 그리고 사용자에게까지 잘
결합된 도구들과 문서들을 제공한다. 특히, GNU gettext
유틸리티에
들어 있는 작업 환경 안에서 다른 자유로운 패키지들이 다국어 메세지를
출력하도록 만들 수 있다. 이 도구들은 메세지 목록(message catalogs)을
지원하는 방법에 대한 규칙들을 담고 있고, 메세지 목록의 디렉토리 및 파일
명명법, 번역 메세지를 찾아내는 기능을 가진 라이브러리, 그리고 번역
가능한, 혹은 이미 번역된 문자열들을 조작하는 몇 가지 별도 프로그램들이
들어 있다. GNU 이맥스용으로 특별히 만들어진 편집 모드를 이용하면 번역
메세지를 만들고 최신판에 맞춰 수정하는 작업이 더 쉬워 진다.
GNU gettext
는 프로그램 소스가 국제화되었을 때 미치는 영향을
최소화하도록 설계되었으므로, 이 영향을 최대한 작고, 거의 알아챌 수
없도록 유지한다. 국제화는 국제화의 부담이 작거나, 최소한 프로그램
소스를 봤을 때 부담이 작은 것처럼 보일 수록 더 성공 가능성이 높다.
번역 프로젝트는 GNU gettext
배포본을 이용해 번역 프로젝트의
구조와 프로젝트 진행 방법을 문서화한다. 이것은 엄격히 말하면 GNU
gettext
의 문서화 범위를 넘어서는 것이다. 이렇게 해서, 번역자는
가능하면 한 장소에서 번역 작업을 위해 알아야 할 모든 정보를 찾을 수
있다. 또, 프로그래머와 호기심 많은 사용자들도 이렇게 번역 프로젝트와
관련된 내용들을 보고 GNU gettext
가 번역 프로젝트의 여러 부분들과
어떤 관계가 있는지 알 수 있을 것이고, 큰 그림을 잠깐 볼 수 있을
것이다.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
프로그램의 고유어 지원에 관한 얘기가 나오면, 항상 길다란 단어 두 개가 등장한다. 이 단어 두개는 정확한 의미가 있으며, 여기서, 그리고 이 문서의 모든 곳에 걸쳐서 설명할 만한 가치가 있는 중요한 단어이다. 이 단어는 국제화(internationalization)와 지역화(localization)이다. 많은 사람들은 이 길다란 단어를 반복해서 쓰는 것에 지친 나머지, i18n과 l10n이라고 쓰는 버릇을 갖고 있다. 이 약어는 각 단어의 첫번째와 마지막 글자를 쓰고 나머지 중간의 글자들을 그 글자가 몇개인지를 나타내는 수로 바꿔 버린 것이다. 하지만 이 안내서에서는, 명확함을 위해 인내심을 갖고 이 단어들을 있는 그대로 사용할 것이다. 매번 반복해서…
국제화란, 어떤 프로그램 혹은 프로그램들의 집합이 여러 언어를
지원할 수 있도록 만드는 과정을 뜻한다. 국제화는 그 프로그램이 영어
문자열 혹은 그 밖에 영어와 관련된 버릇들에 고정되지 않도록 일반화하는
과정이다. 프로그램을 국제화할 때 프로그램 개발자는 여러 가지 기술들을
활용할 수 있는데, 그 중에 몇 가지는 표준화되어 있고, GNU
gettext
에서 제공하는 것은 이러한 표준화된 기술 중의 한 가지이다.
See section 프로그래머의 관점.
지역화란, 이미 프로그램들이 국제화된 상태에서, 특정 언어 및 그 문화적인 버릇들에 맞게 입출력을 처리할 수 있도록 필요한 정보를 포함시키는 과정을 말한다. 지역화는 이미 국제화된 프로그램에서 일반적인 기능들을 특정 방법으로 쓰이도록 특화하는 과정이다. 국제화된 프로그래밍 환경에서는 프로그램이 실행할 때 어떻게 설정되어 있느냐에 따라 몇몇 기능들이 다르게 동작하도록 되어 있다. 이러한 문화적인 버릇들의 몇 가지 집합에 대해 기술해 놓은 것, 그리고 특정 언어를 위해 만들어진 번역문들을 그 언어 혹은 그 국가의 로케일(locale)이라고 부른다. 사용자가 프로그램을 실행하기 전에 로케일에 관한 환경 변수의 값을 제대로 맞춰 놓으면 어떤 로케일이 사용될지 지정하는 것이고, 사용자는 이렇게 지역화된 프로그램을 이용할 수 있다.
사실 로케일 메세지 지원기능은, 로케일 내에 들어 있는 여러 가지 문화적 습관을 담은 여러 정보들 가운데 한 가지일 뿐이다. 여러 가지 프로그램과 함수들을 이용해 프로그래머는 국제화된 소프트웨어의 개발 및 특정 로케일의 정보를 접근하는 일을 편리하게 할 수 있다. 누군가 특정로케일을 참조하면, 실제로는 그 로케일 내에 저장된 정보를 참조하는 것이다. 비슷하게, 프로그래머가 “로케일 루틴을 접근한다”면, 그 로케일 루틴이란 로케일 정보를 접근하기 위한 모든 루틴들의 집합을 뜻하는 것이다.
어떤 이들은, 프로그램에서 여러 개의 언어를 사용하도록 해 주는 국제화와 지역화를 모두 포함하는 작업 및 관련 기능을 고유어 지원(Native Language Support), 혹은 간단히 NLS라는 말로 표현하기도 한다. 요약하면, 국제화는 국제화 이후에 하게 될 지역화를 가능하도록 만드는 과정이라고 할 수 있다.
다국어 번역 메세지에만 국한시켜서 대충 말한다면, 국제화는 프로그래머가 신경 쓸 문제이고, 지역화는 보통 번역자가 신경쓸 문제이다.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
완벽한 다국어 배포본을 만드려면, 출력 메세지 이외에도 번역되어야 할 것이 많다.
gettext
에는 C 프로그램의 출력 메세지를 번역하는 데는
완벽한 도구가 구비되어 있다. 그런데 C 프로그램 이외에 펄 스크립트와 셸
스크립트도 번역되어야 한다. 번역하는 방법이 이미 몇 가지 나와 있지만,
이 방법들이 GNU gettext
에 완전히 포함되어야 한다.
autoconf
나 bison
과 같은 프로그램들은 또 다른 프로그램(혹은
스크립트)을 만들어 낼 수 있다. autoconf
나 bison
과 같은
프로그램들이 국제화되었다고 해도, 이 프로그램이 만들어 내는 프로그램
자체도 국제화 되야 한다. 이 간접적인 국제화 과정은 프로그램을 만들어
내는 프로그램에서 직접 자동화 할 수도 있을 것이다. 하지만, 사실
프로그램을 만들어 내는 프로그램과 만들어 지는 프로그램은 별도로 국제화될
수 있다. 왜냐하면 보통 프로그램을 생성하는 일과 생성된 프로그램을
국제화하는 일은 서로 아무 영향이 없기 때문이다.
recode
가 실행할 때
RFC 1345에 들어 있는 각 문자들에 대한 영어로 쓰여진 설명을 읽는다.
이 설명문은 RFC에서 기계적인 방법으로 추출된 것이기 때문에, 이 설명을
제대로 번역하려면 미리 그 RFC에 대한 번역문이 필요할 것이다.
이미 강조한 것처럼, 번역은 로케일의 오직 한 가지 측면일 뿐이다. 현재 GNU
gettext
는 번역 이외의 국제화의 측면들을 처리하지 못하지만, 아마도
미래의 버전에서는 처리할 수 있을 지 모른다. 어떤 국가의 문화적인
관습들을 정의하려면 많은 요소들이 필요하다. 이 요소들은 그 국가의 국어,
날짜와 시간을 표시하는 방법, 숫자 표기, 통화표시 등이다. 로케일은
이러한 국가 고유의 속성들을 지원하기 위해 필요한 정보들을 담고 있다.
국가마다 다르게 처리해야 하는 분야가 몇 가지 있는데, 바로 그 분야들을
보면 로케일 데이타가 무엇을 담고 있어야 하는지 정의된다. 다음 리스트를
보면 다국어 메세지 처리 분야가 그 밖의 로케일 관련 작업들과 비교했을 때
어디에 위치하는지 알 수 있고, GNU gettext
가 언젠가 처리해야 할
다른 분야들을 알 수 있다.
미국 전역과 세계에서 영어를 사용하는 모든 분야에서 가장 공통적으로 사용되는 코드셋은 ASCII 코드셋이다. 하지만, 이 코드셋에 없는 문자를 사용해야 하는 로케일들이 있다. 8비트 ISO 8859-1 코드셋은 주요 유럽 언어를 사용하는 데 필요한 문자 몇 가지가 포함되어 있다. 하지만 많은 경우에 ISO 8859-1 폰트는 부적합하다. 그러므로 각 로케일은 어떤 코드셋이 사용되어야 하고, 그 코드셋에 적합한 문자를 처리하는 루틴을 갖고 있어야 한다.
나라마다 통화를 나타내는 기호는 전부 다르다. 소프트웨어는 각 로케일에 맞는 통화 기호를 표시해야 한다.
날짜의 형식은 로케일마다 다르다. 예를 들어, 1994년의 성탄절은 미국에서는 12/25/94이고, 오스트레일리아에서는 25/12/94이다. 어떤 나라들은 ISO 8061 형식을 사용할 지도 모르고, 혹은 또 다른 형식을 사용할 수도 있다.
하루중의 시각은 hh:mm, hh.mm, 혹은 그 밖의 방법으로도 표기될 수 있다. 어떤 로케일은 시각이 오전 오후가 아니라 24시간으로 지정될 수도 있다. 더 나아가서, 일광 절약제를 실시하는 지 여부, 또 일광 절약제에서 몇 시간을 앞당길 것인지는 국가마다 제각각이다.
숫자는 로케일에 따라 다르게 표시된다. 예를 들어, 다음은 각 로케일에 따라 쓰여진 숫자이다:
12,345.67 영어 12.345,67 프랑스어 1,2345.67 아시아
어떤 프로그램은 더 나아가 미국식 단위계 혹은 미터법과 같이, 완전히 다른 단위계를 쓰기도 한다. 혹은 숫자를 아라비아 숫자가 아닌 완전히 다른 철자로 표기될 수도 있다.
가장 두드러진 분야는 로케일의 언어 지원이다. 이것이 GNU
gettext
가 제공하는 분야로, GNU gettext
의 도구를 이용해
개발자와 사용자는 프로그램이 사용할 언어를 쉽게 바꿀 수 있다.
아마 가까운 시일 안에는 메세지 처리 이외의 로케일 구성요소를 사용할 수
없을 것이다. 가장 현대적인 시스템 마저도 최소한 위에서 몇 가지
구성요소를 빠뜨린 채 로케일을 지원하고 있기 때문이다. 한편 GNU
libc
와 리눅스에서 새롭고 완벽한 로케일 기능을 구현하여, 쓸만한
로케일 지원이 없는 시스템에서 사용될 수 있을 것이다.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
‘.po’ 파일의 PO는 Portable Object를 뜻하고, ‘.mo’ 파일의 MO는
Machine Object를 뜻한다. PO 파일 포맷을 비롯해 gettext
의
패러다임은 유니포럼에서 개발된 NLS 표준에서부터 만들어 졌고, 썬
마이크로시스템즈 사가 그들의 솔라리스 시스템에 구현해 놓았다.
PO 파일은 사람이 직접 읽고 편집할 수 있도록 만들어 졌고, 주어진
패키지에서 변역할 수 있는 각 문자열을 어떤 특정 언어의 번역문과
대응시키는 역할을 한다. 한 개의 PO 파일은 한개의 번역할 언어에
사용된다. 만약 한 개의 패키지가 여러 개의 언어를 지원할 경우에는,
지원하는 각각의 언어마다 한 개씩의 PO 파일이 있고, 각 패키지마다 그
패키지를 위한 PO 파일이 들어 있다. 이 PO 파일은 xgettext
프로그램에 의해 가장 잘 만들어 지고, 나중에 msgmerge
프로그램에
의해 갱신된다. xgettext
프로그램은 C 파일에서 번역할 수 있다고
표시된 메세지를 추출하여 실제 번역문을 비워둔채 PO 파일을 초기화한다.
msgmerge
프로그램은 해당 소스가 릴리즈하는 중간중간마다 PO
파일들을 재조정하고, 없어진 문자열을 주석처리하고, 새로운 것을
초기화하고, 모든 소스코드 줄번호 참조를 다시 바꾼다. ‘.pot’로
끝나는 파일은 PO 파일 형식으로 된 기본적인 번역 파일의 틀이고,
‘.pox’ 파일은 임시로 만들어진 PO 파일이다.
MO 파일은 프로그램에서 읽어들이는 파일이고, 자연히 바이너리 파일이다.
어떤 시스템은 고유어 지원 기능의 일부로서 MO 파일을 만들고, 처리하는
도구를 제공한다. 하지만 이 MO 파일은 시스템마다 다르고 다른
시스템에서는 서로 공유할 수 없다. ‘.mo’ 를 파일 확장자로 쓸 필요는
없지만, 파일을 접근할 때 그 시스템의 라이브러리를 사용해야 하기 때문에
시스템이 이에 대해 일관적으로 동작하는 한 동작할 것이다. 만약 시스템에
제공되는 도구들을 GNU gettext
가 사용할 수 있다면, 이 도구들을
사용해 MO 파일을 만들 것이다. 그렇지 않은 경우, 즉 이런 도구들이
없거나, 사용할 수 없는 경우에, GNU gettext
는 고유 포맷으로 고유의
방법을 사용할 것이다. ‘.gmo’로 끝나는 파일들은 GNU 형식을
사용하도록 되어 있는 MO 파일들이다.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
gettext
의 개요다음 그림은 GNU gettext
가 처리하는 파일들과 그 파일에 작용하는
도구들 사이의 관계를 요약한 것이다. 다음에 조금 더 자세한 설명이
추가되는데, 계속 이 그림에 눈을 떼지 말아야 한다. 이 상호 관계를 잘
이해한다면 분명 프로그래머, 번역자, 그리고 관리자에게 도움이 될 것이다.
원 C 소스 ------------> PO mode ---> 표시된 C 소스 ------. | .---------<--- GNU gettext 라이브러리 | .--- make <---+ | | `---------<--------------------+-----------' | | | .-----<--- PACKAGE.pot <--- xgettext <---' .---<--- PO 요약문 | | | ^ | | `---. | | `---. +---> PO 모드 ---. | +----> msgmerge ------> LANG.pox --->--------' | | .---' | | | | | `-------------<---------------. | | +--- LANG.po <-- 새로운 LANG.pox <--' | .--- LANG.gmo <--- msgfmt <---' | | | `---> 설치 -----> /.../LANG/PACKAGE.mo ----. | +---> "안녕하세요, 여러분!" `-------> 설치 -----> /.../bin/프로그램 -------'
이 그림에서 ‘PO 모드’는 두 군데에 걸쳐 나타나는데, 간단히 사용하고 싶은 에디터를 사용해 “손으로 편집”하는 것이라고 생각하면 된다. 하지만 운 좋게도 GNU 이맥스 사용자라면, PO 파일을 편집하고 수정하는 아늑한 환경을 제공해 주는 PO 모드가 있다. PO 모드는 PO 파일을 편집하고 고치는 데 확실히 편리한 환경을 제공해 준다. PO 파일을 편집하는 동안, PO 모드는 보조 PO 파일, 요약 PO 파일들을 쉽게 보여주고, PO 파일이 만들어진 C 소스 파일의 위치를 따라갈 수도 있다. 특수한 기능들을 이용하면, 번역할 수 있는 프로그램 문자열을 대화적으로 표시하기도 하고, PO 파일의 문법이 틀렸을 때 PO 파일의 틀린 부분으로 이동해 PO 파일의 잘못을 쉽게 잡을 수 있다.
프로그래머로서 패키지에 GNU gettext
를 사용하는 첫번째 단계는
직접 C 소스에서 무엇이 번역될 수 있고, 무엇이 번역될 수 없는 문자열인지
확인하는 것이다. 이 지루한 작업은 이맥스 PO 모드를 사용하여 좀더 편하게
할 수 있지만, C 소스를 수정할 수 있는 어떤 방법이든지 사용할 수 있다.
이 간단한 작업 이외에, 번역 라이브러리를 제대로 초기화하려면 몇 가지
더 변경해야 한다. 여기에 대한 더 많은 정보는 See section 프로그램 소스 준비하기.
물론, 새롭게 쓰여지는 소프트웨어의 경우에는 그 소프트웨어를 작성할 때
표시를 한다. gettext
의 접근방법때문에 이 작업은 매우 쉽다.
간단히 각 파일의 시작, 혹은 중심 헤더 파일에 다음 줄을 넣는다:
#define _(String) (String) #define N_(String) (String) #define textdomain(Domain) #define bindtextdomain(Package, Directory)
이렇게 하면, 국제화를 위한 소스코드가 준비된 것이다. 나중에
gettext
라이브러리를 사용할 준비가 되었으면, 이 정의를 지워버리고
‘libintl.h’을 include하고 ‘libintl.a’과 링크한다. 이것이
전부이다.
일단 C 소스가 수정되었으면, xgettext
프로그램을 이용해 번역
가능한 문자열들을 모두 찾아서 뽑아내고, PO 파일을 만든다. 이
‘package.pot’ 파일은 모든 프로그램의 번역 가능한 문자열을
담고 있다. 여기에는 각 문자열이 C 소스의 어디에서 사용는지에 대한
정보도 들어 있다. 모든 번역문은 비어진 채로 남아 있다. ‘.pot’의
마지막 글자 t는 이 파일이 아직 특정 언어로 번역되지 않은
틀(Template) PO 파일임을 나타내는 것이다. 어떻게 xgettext
프로그램을 실행하는지에 대한 더 자세한 정보는 See section xgettext
프로그램 실행하기.
만약 정말로 게으르다면, 조금 더 편하게 전체 배포본을 준비해 놓고
싶을 것이다 (see section 관리자의 관점). 그렇게 하면, make
가 자동으로
파일들을 만들어 낼 것이기 때문에, 더 이상 xgettext
명령을
타이프하는 데 시간 낭비하지 않아도 될 것이다.
처음에는 ‘lang.po’ 파일이 아직 없기 때문에, msgmerge
단계는 지나가고, 단지 ‘package.pot’ 파일만을
‘lang.pox’ 파일로 복사한다. 여기에서 lang은 번역하고자
하는 언어를 나타낸다.
그 다음에는 최초로 메세지 번역을 한다. 아직까지 번역은 인간만이 할 수 있는 일이고, 번역의 복잡성은 이 안내서의 범위를 넘어선다. 하지만, 몇 가지 힌트가 이 안내서의 뒤에 주어져 있다 (see section 번역자의 관점). 그 곳에는 어떻게 번역팀에 연락하고, 번역팀의 일부가 되어, 같은 언어를 사용하는 번역자들과 번역 문제를 함께 논의할 수 있는 방법이 쓰여 있다.
‘lang.pox’ 파일에 번역 메세지를 추가하는 과정에서 GNU 이맥스에 익숙하지 못하다면, 번역문이 PO 파일 포맷에 완전히 들어맞고 인용부호 규칙을 따르는지에 대해 직접 확인해야 한다 (see section PO 파일의 형식). 이렇게 작업하는 일은 불가능한 작업이 아니고, 이미 유니포럼이나 솔라리스에서 PO 파일 작업을 할 때 사용해 왔던 방법이다. 한편, GNU 이맥스의 PO 모드를 사용하면 PO 파일 포맷의 대부분의 세부적인 사항들은 PO 모드가 알아서 신경을 써준다. 하지만 PO 모드를 이용할 경우에는 PO 모드에 대해 어느정도 익숙해질 필요가 있다. PO 모드의 명령 이외에도 (see section 주요 PO 모드 명령), 각 항목 사이를 어떻게 이동하고 (see section 항목 이동), 어떻게 번역되지 않은 항목을 처리하는지 (see section 번역되지 않은 항목) 알아야 한다.
만약 요약문 PO 파일에 몇 개의 공통적인 번역문이 이미 저장되어 있다면, 번역자는 PO 모드를 사용해 이 요약문 파일에서 번역되지 않은 메세지들을 초기화 할수도 있고, 번역문을 선택해서 이 요약문 파일에 저장할 수도 있다 (see section 번역 요약문 사용하기). 요약문 파일은 한 번역팀의 멤버 사이에서 교환되는 파일이다.
프로그램, 혹은 여러 프로그램들의 패키지들은 당연히 유동적이다: 사용자는 버그를 보고하고 개선할 점을 제안하며, 관리자는 여러 방법으로 프로그램을 수정해 이에 반응한다. 패키지가 이미 국제화되어 있다는 사실때문에 관리자가 새로운 문자열을 추가하거나, 이미 번역된 문자열을 수정하는 일을 주저할 필요가 없다. 관리자는 관리자가 할 수 있는 일에 최선을 다할 뿐이다. 번역 프로젝트가 원활히 동작하기 위해서 관리자는 안 그래도 부담이 가는 어깨에 번역 문제까지 짊어져서는 안되며, 번역자는 가능한 한 프로그래밍에 관련된 문제와는 분리된 상태로 남아 있어야 한다.
관리자가 신경을 써야 하는 오직 한 가지는 번역이 가능하고, 번역 되어야
하는 경우, 그 새로운 문자열을 주의깊게 표시하는 것이다. 적당히 시간이
지나면 메세지가 번역될 것이므로, 그 메세지가 번역될 지 아닐지에 대한
문제는 신경쓰지 않는다. 결과적으로, 관리자가 번역문제에 신경 쓰지
않고 그 메세지들을 수정할 경우에, xgettext
는
‘package.pot’ 파일을 계속해서 만들어 낼 것이고,
‘lang.po’ 파일을 만드는 번역자는 매우 천천히 뒤떨어질 것이다.
번역자는 (혹은 관리자까지도) 패키지의 번역이라는 작업이 패키지가 사라질 때까지 계속되는 과정임을 이해해야 하고, 단번에 끝나거나 처음에 모든 것을 할 수 있는 작업이 아님을 알아야 한다. 주어진 패키지의 번역을 시작했으면, 계속해서 그 일을 해야 한다. 왜냐하면 계속해서 번역된 항목이 없어지기도 하고, 번역되지 않은 항목들이 나타나기 때문이다.
msgmerge
프로그램의 목적은 현존하는 ‘lang.po’ 파일을
xgettext
가 최신의 C 소스에서 뽑아낸 ‘package.pot’ 틀
파일과 비교하여 갱신하는 일이다. 이 갱신 작업에서 문자열의 위치는
프로그램이 바뀔 때마다 달라지므로, 해당 문자열이 사용된 C 소스 파일의
위치를 업데이트한다. 또, msgmerge
는 더이상 프로그램 소스에서
사용되지 않는 번역된 메세지들을 ‘lang.pox’에서 주석처리한다
(see section 없어진 항목). msgmerge
는 마지막으로 새로운 문자열을
찾아서 최종 PO 파일에 번역되지 않은 항목으로 추가한다 (see section 번역되지 않은 항목). msgmerge
가 실제로 무엇을 하는지에 관한 더 많은
정보는 See section msgmerge
프로그램 실행하기.
어떤 경로, 혹은 방법을 사용하든지, 최종 목표는 갱신된 모든 문자열에 대한 번역문을 제공하는 ‘lang.pox’ 파일을 만들어 내는 것이다. 이 목표가 달성되었으면, 이 ‘lang.pox’ 파일은 이전의 ‘lang.po’ 파일 대신에 사용될 수 있다.
시간적인 기동성, 혹은 PO 파일의 유동성은 번역이라는 게임에서 한 가지 중요한 부분이며, 이 점을 잘 이해하고 받아들여야 한다. 이 점을 거부하는 사람들은 번역 프로젝트에 참여하는 데 어려움을 겪거나, 다른 참여자에게 어려움을 줄 것이다! 특히, 관리자는 안심하고 사용할 수 있는 모든 공식 PO 파일을, 설령 그 파일이 최근에 갱신되지 않았을지라도 거부하거나 번역자에게 번역을 끝마치라는 압력을 가하지 말고, 배포본에 포함해야 한다. 압력은 그 언어를 사용하는 사용자 그룹에서부터 나올 것이고, 관리자는 번역문이 적절한지에 대해는 안심해도 된다. 한편, 번역자는 책임지고 있는 패키지가 예비 테스트중이거나, 공식 배포를 앞두고 있을 때에 때맞춰 PO 파일을 갱신해 나가야 한다.
일단 PO 파일이 완성되고 문제가 없다면, msgfmt
프로그램은 PO
파일을 기계 중심 포맷으로 변환하고, 이 기계 중심 파일은 실행시에 필요한
만큼 효율적으로 번역문을 찾아낼 수 있는 포맷이다 (see section GNU MO 파일 형식).
msgfmt
프로그램을 실행하는 방법은 See section msgfmt
프로그램 실행하기.
마지막으로, 수정되고 표시된 C 소스는 GNU gettext
라이브러리와
링크되고 컴파일되어야 한다. 이 작업은 보통 그 프로젝트의
‘Makefile’에 주어진 대로 make
를 통해 하게 되며, 최종 실행
파일은 사용자가 찾을 수 있는 어딘가에 설치된다. MO 파일 자체도 적당한
위치에 설치되어야 한다. 알맞은 환경 변수가 사용된다면 (see section 일반 사용자를 위한 마술), 프로그램은 프로그램이 실행될때 자동으로 지역화된 채 실행된다.
이 안내서의 나머지에서는 위에서 대충 요약한 각 단계 하나하나를 좀더 깊이 설명한다.
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated on April 12, 2025 using texi2html 5.0.