Go to the first, previous, next, last section, table of contents.

@dircategory GNU Gettext Utilities * Gettext-ko: (gettext-ko). GNU gettext 유틸리티. * gettextize-ko: (gettext-ko)gettextize 실행. gettext를 사용할 패키지 준비. * msgfmt-ko: (gettext-ko)msgfmt 실행. PO 파일에서 MO 파일 만들기. * msgmerge-ko: (gettext-ko)msgmerge 실행. 두개의 PO 파일을 하나로 갱신. * xgettext-ko: (gettext-ko)xgettext 실행. 문자열을 뽑아내 PO파일 만들기.

Copyright (C) 1995, 1996, 1997, 1998, 2001 Free Software Foundation, Inc.

Copyright (C) 1999, 2000, 2001 Changwoo Ryu

Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.

Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.

Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Foundation.

소개

아직 이 안내서는 초안 상태이다. 어떤 절은 거의 혹은 전혀 공백 상태이다. 우리는 계속 여러 곳에서 (주로 전자우편 폴더에서) 자료들을 모으고 있지만, 이 자료들을 제대로 결합하는 작업이 늦어지고 있다.

이 안내서에서, 우리는 프로그래머나 관리자에 대한 대명사로 그(he)를 쓰고, 번역자에 대한 대명사는 그녀(she), 프로그램을 설치하는 사람이나 번역된 프로그램을 사용하는 사람에 대한 대명사로 그들(they)을 사용할 것이다. 이 규칙은 명확한 문서를 만들기 위해서 편의상 정했을 뿐이고, 남성이나 여성에게 적합한 역할이 따로 있다고 가정하는 것은 절대 아니다. 당연히 GNU gettext는 컴퓨터를 사용하는 사람이라면 성별, 인종, 종교, 혹은 국적에 관계없이 모든 이에게 쓸모 있는 도구이다! (역자주---이 한국어 번역본에서는 남성, 여성 대명사의 구별이 없다.)

이 장에서는 GNU gettext와 자유 번역 프로젝트(Free Translation Project)를 만들 때 추구했던 목표들에 대해 설명한다. 그 다음에 고유어 지원(Native Language Support)과 관련하여 널리 쓰이는 용어들을 몇 가지 설명한다. 또, 각 나라별 차이와 문화적 차이를 생각해 볼때 번역 메세지를 프로그램에 포함시키는 일이 어떠한 가치가 있는지 설명한다. 또 번역문을 프로그램에 포함시킬 때 이용하는 파일들에 대해 대략 살펴본다. 여기서는 이러한 파일들을 만드는 데 GNU gettext에 들어 있는 도구들이 어떤 작용을 하는지 설명하고, 좀 더 뒤에는 어떻게 관리 사이클(maintenance cycle)이 동작해야 하는지 설명한다.

제안이나 고칠 점이 있으면 다음 주소로 보내주기 바란다: 

인터넷 주소:
    bug-gnu-utils@gnu.org

편지를 보낼 때 이 안내서의 판번호와 마지막으로 수정된 날짜를 포함해 주기 바란다.

한국어판 번역자의 변

위에 쓰여진 바와 같이 이 안내서는 완성된 안내서가 아니다. 어떤 부분은 매우 잘 쓰여졌지만, 또 어떤 부분은 사람들 사이에 오간 이메일 조각들을 긁어 붙여놓은 것 뿐이다. 더 나쁜 사실은, gettext는 0.10.35 이후에 더 이후의 버전이 발표되지 않고 있다; 그 이유는 gettext의 하는 일이 딱 고정되어 있기 때문이기도 하고, 이제 libintl 코드가 GNU C Library의 일부로 포함되어 있기 때문이기도 하다 (gettext와 GNU C Library의 메인테이너는 같은 사람이다).

분명 형편없는 번역의 책임은 번역자에게 있지만, GNU gettext 영문 안내서 역시 읽기 힘든 초안 상태라는 점을 감안해 주기를 바란다.

GNU gettext의 목적

보통 프로그램은 영어로 만들어 지고, 영어로 문서화된다. 또 프로그램을 실행할 때 사용자와 정보를 주고받는 언어로 영어를 사용한다. 이는 GNU 소프트웨어뿐만이 아니라, 상당수의 상업용, 자유 소프트웨어의 경우에도 마찬가지이다. 어떤 공통된 언어를 사용하면 전 세계에 흩어져 있는 개발자, 관리자, 그리고 사용자 사이에 의견을 교환하기가 대단히 편리하다. 하지만 다른 한편으로, 대부분의 사람들은 영어보다는 자신의 모국어를 더 편하게 사용하고, 일상적인 생활에서는 가능한 한 모국어를 사용하려고 한다. 당연히 많은 사람들은 컴퓨터 스크린에 영어가 좀 더 적게 보이고, 모국어가 더욱 더 많이 보이기를 바랄 것이다.

그러나, 많은 사람들에게 이러한 꿈의 실현은 너무 멀리 있는 것처럼 보이고 어쩌면 그런 일을 생각하는 데 시간 낭비할 필요조차 없다고 할 지 모른다. 사람들은 그 꿈이 과연 앞으로 실현될 지도 확신하지 못한다. 하지만 몇 사람들은 희망을 잃지 않았고, 그 몇 명이 모였다. 번역 프로젝트(The Translation Project)는 이런 희망들을 쳬계적으로 정리해서, 효과를 거둘수 있도록 만든 조직체이며. 우리 모두가 참된 다국어 프로그램의 실현에 좀 더 가까워질 수 있는 좋은 기회이다.

GNU gettext는 번역 프로젝트가 내딛는 중요한 한 걸음이다. GNU gettext는 이 프로젝트의 또 다른 발걸음들을 내딛기 위한 밑천이기 때문이다. 이 패키지는 다음을 프로그래머, 번역자, 그리고 사용자에게까지 잘 결합된 도구들과 문서들을 제공한다. 특히, GNU gettext 유틸리티에 들어 있는 작업 환경 안에서 다른 자유로운 패키지들이 다국어 메세지를 출력하도록 만들 수 있다. 이 도구들은 다음을 포함한다:

GNU gettext는 프로그램 소스가 국제화되었을 때 미치는 영향을 최소화하도록 설계되었으므로, 이 영향을 최대한 작고, 거의 알아챌 수 없도록 유지한다. 국제화는 국제화의 부담이 작거나, 최소한 프로그램 소스를 봤을 때 부담이 작은 것처럼 보일 수록 더 성공 가능성이 높다.

번역 프로젝트는 GNU gettext 배포본을 이용해 번역 프로젝트의 구조와 프로젝트 진행 방법을 문서화한다. 이것은 엄격히 말하면 GNU gettext의 문서화 범위를 넘어서는 것이다. 이렇게 해서, 번역자는 가능하면 한 장소에서 번역 작업을 위해 알아야 할 모든 정보를 찾을 수 있다. 또, 프로그래머와 호기심 많은 사용자들도 이렇게 번역 프로젝트와 관련된 내용들을 보고 GNU gettext가 번역 프로젝트의 여러 부분들과 어떤 관계가 있는지 알 수 있을 것이고, 큰 그림을 잠깐 볼 수 있을 것이다.

I18n, L10n, 그 외

프로그램의 고유어 지원에 관한 얘기가 나오면, 항상 길다란 단어 두 개가 등장한다. 이 단어 두개는 정확한 의미가 있으며, 여기서, 그리고 이 문서의 모든 곳에 걸쳐서 설명할 만한 가치가 있는 중요한 단어이다. 이 단어는 국제화(internationalization)와 지역화(localization)이다. 많은 사람들은 이 길다란 단어를 반복해서 쓰는 것에 지친 나머지, i18n과 l10n이라고 쓰는 버릇을 갖고 있다. 이 약어는 각 단어의 첫번째와 마지막 글자를 쓰고 나머지 중간의 글자들을 그 글자가 몇개인지를 나타내는 수로 바꿔 버린 것이다. 하지만 이 안내서에서는, 명확함을 위해 인내심을 갖고 이 단어들을 있는 그대로 사용할 것이다. 매번 반복해서...

국제화란, 어떤 프로그램 혹은 프로그램들의 집합이 여러 언어를 지원할 수 있도록 만드는 과정을 뜻한다. 국제화는 그 프로그램이 영어 문자열 혹은 그 밖에 영어와 관련된 버릇들에 고정되지 않도록 일반화하는 과정이다. 프로그램을 국제화할 때 프로그램 개발자는 여러 가지 기술들을 활용할 수 있는데, 그 중에 몇 가지는 표준화되어 있고, GNU gettext에서 제공하는 것은 이러한 표준화된 기술 중의 한 가지이다. See section 프로그래머의 관점.

지역화란, 이미 프로그램들이 국제화된 상태에서, 특정 언어 및 그 문화적인 버릇들에 맞게 입출력을 처리할 수 있도록 필요한 정보를 포함시키는 과정을 말한다. 지역화는 이미 국제화된 프로그램에서 일반적인 기능들을 특정 방법으로 쓰이도록 특화하는 과정이다. 국제화된 프로그래밍 환경에서는 프로그램이 실행할 때 어떻게 설정되어 있느냐에 따라 몇몇 기능들이 다르게 동작하도록 되어 있다. 이러한 문화적인 버릇들의 몇 가지 집합에 대해 기술해 놓은 것, 그리고 특정 언어를 위해 만들어진 번역문들을 그 언어 혹은 그 국가의 로케일(locale)이라고 부른다. 사용자가 프로그램을 실행하기 전에 로케일에 관한 환경 변수의 값을 제대로 맞춰 놓으면 어떤 로케일이 사용될지 지정하는 것이고, 사용자는 이렇게 지역화된 프로그램을 이용할 수 있다.

사실 로케일 메세지 지원기능은, 로케일 내에 들어 있는 여러 가지 문화적 습관을 담은 여러 정보들 가운데 한 가지일 뿐이다. 여러 가지 프로그램과 함수들을 이용해 프로그래머는 국제화된 소프트웨어의 개발 및 특정 로케일의 정보를 접근하는 일을 편리하게 할 수 있다. 누군가 특정로케일을 참조하면, 실제로는 그 로케일 내에 저장된 정보를 참조하는 것이다. 비슷하게, 프로그래머가 "로케일 루틴을 접근한다"면, 그 로케일 루틴이란 로케일 정보를 접근하기 위한 모든 루틴들의 집합을 뜻하는 것이다.

어떤 이들은, 프로그램에서 여러 개의 언어를 사용하도록 해 주는 국제화와 지역화를 모두 포함하는 작업 및 관련 기능을 고유어 지원(Native Language Support), 혹은 간단히 NLS라는 말로 표현하기도 한다. 요약하면, 국제화는 국제화 이후에 하게 될 지역화를 가능하도록 만드는 과정이라고 할 수 있다.

다국어 번역 메세지에만 국한시켜서 대충 말한다면, 국제화는 프로그래머가 신경 쓸 문제이고, 지역화는 보통 번역자가 신경쓸 문제이다.

고유어 지원의 측면들

완벽한 다국어 배포본을 만드려면, 출력 메세지 이외에도 번역되어야 할 것이 많다.

이미 강조한 것처럼, 번역은 로케일의 오직 한 가지 측면일 뿐이다. 그 외의 국제화 측면들은 GNU libc가 처리한다. 어떤 국가의 문화적인 관습들을 정의하려면 많은 요소들이 필요하다. 이 요소들은 그 국가의 국어, 날짜와 시간을 표시하는 방법, 숫자 표기, 통화표시 등이다. 로케일은 이러한 국가 고유의 속성들을 지원하기 위해 필요한 정보들을 담고 있다.

국가마다 다르게 처리해야 하는 분야가 몇 가지 있는데, 바로 그 분야들을 보면 로케일 데이타가 무엇을 담고 있어야 하는지 정의된다. 다음 리스트를 보면 다국어 메세지 처리 분야가 그 밖의 로케일 관련 작업들과 비교했을 때 어디에 위치하는지 알 수 있다. 자세한 것은 GNU libc 안내서를 참조하기 바란다.

문자와 코드셋
미국 전역과 세계에서 영어를 사용하는 모든 분야에서 가장 공통적으로 사용되는 코드셋은 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와 리눅스에서 새롭고 완벽한 로케일 기능을 구현하여, 쓸만한 로케일 지원이 없는 시스템에서 사용될 수 있을 것이다.

메세지 처리 이외의 로케일 요소들은 ISO C 표준과 SUSV2 스펙에 표준화되어 있다. GNU libc에는 이 기능들이 완전히 구현되어 있다. 최근의 대부분의 시스템들은 거의 쓸만할 정도로 이 기능들을 지원하고 있으며 최소한 이 중 일부가 빠져 있을 뿐이다.

번역문을 담고 있는 파일들

`.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 파일은 시스템마다 다르고 다른 시스템에서는 서로 공유할 수 없다.

이들 시스템들에서 제공되는 프로그램들은 GNU gettext에 있는 기능들중에 지원되지 않는 것이 있다. 그러므로 GNU gettext는 독자적인 MO 파일 형식을 이용한다. `.gmo'로 끝나는 파일은 GNU 형식을 이용하는 MO 파일이다.

GNU 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 모드'는 두 군데에 걸쳐 나타나는데, 간단히 사용하고 싶은 에디터를 사용해 "손으로 편집"하는 것이라고 생각하면 된다. 하지만 운 좋게도 이맥스 사용자라면, 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 라이브러리를 사용할 준비가 되었으면, 이 정의를 다음으로 바꾸면 된다: 

#include <libintl.h>
#define _(String) gettext (String)
#define gettext_noop(String) (String)
#define N_(String) gettext_noop (String)

그리고 `libintl.a' 혹은 `libintl.so'와 링크한다. GNU 시스템에서는 GNU libc안에 gettext 라이브러리 함수들이 포함되어 있기 때문에 따로 libintl과 링크할 필요가 없다.

일단 C 소스가 수정되었으면, xgettext 프로그램을 이용해 번역 가능한 문자열들을 모두 찾아서 뽑아내고, PO 틀(template) 파일을 만든다. 이 `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' 파일에 번역 메세지를 추가하는 과정에서 이맥스에 익숙하지 못하다면, 번역문이 PO 파일 포맷에 완전히 들어맞고 인용부호 규칙을 따르는지에 대해 직접 확인해야 한다 (see section PO 파일의 형식). 이렇게 작업하는 일은 불가능한 작업이 아니고, 이미 유니포럼이나 솔라리스에서 PO 파일 작업을 할 때 사용해 왔던 방법이다. 한편, 이맥스의 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 일반 사용자를 위한 마술), 프로그램은 프로그램이 실행될때 자동으로 지역화된 채 실행된다.

이 안내서의 나머지에서는 위에서 대충 요약한 각 단계 하나하나를 좀더 깊이 설명한다.

Go to the first, previous, next, last section, table of contents.