[ Home | Freetime works | FreeBSD | KFUG ]

오픈 소스 유닉스에서의 한글 구현 - 메시지의 국제화

들어가며

일반적으로 다른 나라 언어나 문화를 위해 작성된 프로그램을 작성하기 위해서는 먼저 해 당 국가 언어의 입출력이 가능한지의 문제를 해결해야 한다. 물론 이런 것은 기존에 구성된 시스템의 것을 이용할 수도 있는데, 가령 우리나라의 경우 한글 처리가 가능한 터미널을 사 용할 수 있다면 터미널용 어플리케이션의 한글 출력 문제를 8비트 클린(8bit-clean)의 문 제를 제외하고는 고려할 필요가 없다. 그 다음에 주로 하는 것은 메시지의 번역인데, 메뉴 등의 사용자 메시지를 번역하는 일이다. 여기에는 많은 문제가 개입될 수 있는데, 메시지의 출력 순서나 프로그램의 코딩 상태 등이 많은 영향을 미치기 때문이다. 완전히 국제화되지 않은 프로그램이라면 해당 국가에서 번역을 할 때 자신들의 메시지 구조에 맞도록 프로그 램을 많은 부분 손보아야 할 필요도 있는데, 이는 원본 소스를 고치는 일이 된다. 이 작업 은 훌륭한 결과를 얻을 수 있지만 이후의 업데이트 등에서 많은 문제를 안게 된다. 그러나 이러한 국제화 작업을 보조하기 위한 메시지 번역 시스템이 존재한다면, 번역자는 원본 소 스에 대한 고려나 접근 없이 분리된 메시지 파일 번역만으로 원하는 작업을 달성할 수 있다.

이런 문제를 해결하기 위해서 각 운영체제는 고유의 메시지 번역 시스템을 갖고 있다. 윈도 우의 경우 리소스의 형태로 프로그램의 메시지를 분리해 낼 수 있고, 유닉스의 경우도 catgets()나 gettext()등의 인터페이스등을 통해 메시지와 소스의 분리를 이룰 수 있다. 물 론 상당수의 프로그램은 단순한 메시지 번역 이상의 국제화를 요구하는 경우가 있지만, 이 런 요소들은 어차피 별도의 작업이 필요하다.

메시지 번역을 위한 도구들

X 리소스

다음은 넷스케이프 4.61 한글판에 들어있는 X 위젯 메시지의 한 예이다.

        *menuBar*exit.labelString: 종료
    

        Hanterm*vt100*scrollBar: True
    

X윈도우의 경우 이러한 "번역할 수 있는 메시지"와 "번역하면 안되는 값"의 경계가 모호하 다. 어떤 값을 번역할 수 있는 것인지를 판단하기 위해서는 프로그램의 소스를 참조하거나, 기존 위젯을 사용하는 경우 위젯에서 기본적으로 제공하는 키인지를 살펴보는 일이 필요하다.

이런 X리소스의 번역은 대부분의 X용 어플리케이션에서 볼 수 있다. 알짜 리눅스 등에서 볼 수 있는 xedit나 xmessage의 번역은 이러한 방식으로 이루어진 것인데, 물론 그에 앞 서 해당 프로그램이 로케일 기능을 이용하도록 코딩되어야 한다. X툴킷을 사용하는 프로그 램의 경우라면 Athena 위젯이나 Motif 위젯 등의 차이가 없이 main()함수의 앞부분에서

    setlocale(LC_ALL, "");
    XtSetLanguageProc(NULL, 0, 0);
    

넷스케이프의 경우는 리소스 파일이 X윈도우 위젯의 각 메시지 번역과 함께 공통적으로 사 용하는 메시지의 번역을 분리해 놓았다. 한글 넷스케이프가 설치되어 있다면 리소스 파일 을 열어볼 때(알짜나 파워, 엑셀 리눅스 등이라면 /usr/X11R6/lib/X11/ko/app-defaults/Netscape, FreeBSD의 경우에는 /usr/local/lib/netscape/ko_KR.EUC/Netscape),

    *strings.xxxx: ....
    

이런 방법은 X윈도우 시스템이 기본적으로 지원하는 기능이므로 별도의 부담 없이 X어플 리케이션에서는 유용하게 사용할 수 있지만, 터미널용 어플리케이션 등에서는 이용할 수 없다는 것이 단점으로 작용한다.

메시지의 구분 기준 해당 언어의 메시지 번역은 데이터베이스의 형태로 표시할 수 있는데, 키는 시스템에 따라 정해지는 값이고, 값은 번역된 메시지이다. 이 경우 키는 어떤 값으로 결정하게 될까? 이것 은 번역 시스템을 구분할 수 있는 중요한 요소이기도 하다. 윈도우의 경우라면 사용자가 지 정한 임의의 문자열을 키로 부여하게 되고, X윈도우의 리소스 시스템은 해당 위젯의 이름, catgets()시스템의 경우 사용자가 지정한 임의의 문자열, 그리고 gettext() 시스템은 메시 지의 영문 원본이 키가 된다. 사용자가 지정한 임의의 문자열을 키로 하는 것은 편리할 수 도 있지만 메시지가 계속 갱신되고 생겨나는 상황에서는 번역된 메시지 뿐 아니라 메시지 키 자체를 관리하는 일도 상당히 큰 일이다.

catgets

    nl_catd catd = catopen ("catalog_name", 0);
    char *translation = catgets (catd, set_no, msg_id, "original string");
    catclose (catd);

gettext

    textdomain ("domain_name");
    char* msg = gettext ("msgid");

GNU에서는 gettext를 자신의 방법대로 구현하고 이를 메시지 번역 시스템을 사용하고 있다. 솔라리스와 GNU gettext는 대략적인 개념은 같지만 그 구현 방법이 서로 다르다는 점을 명심해 두자.

GNU gettext

      ftp://prep.ai.mit.edu/gnu/gettext/gettext-0.10.35.tar.gz

원리

원 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/프로그램 -------'

조금 복잡해 보일지 모르겠지만, 대략적인 흐름은 C 소스에 번역할 문자열을 표시하고, 여기에서 xgettext를 사용하여 메시지 번역을 위한 템플리트 파일(pot)를 추출하고. 이를 각 언어 번역자가 번역한다(po). 업그레이드된 프로그램의 경우라면 새로 번역물을 추출하고 이를 msgmerge프로그램을 사용하여 기존의 번역문을 유지하며 새 번역물로 바꿀 수 있다.

번역된 메시지 파일(LANG.po)는 msgfmt프로그램을 통해 시스템 고유의 바이너리 포맷인 mo형식으로 바뀐다(여기서 GNU스타일의 mo파일은 gmo라고 부른다). 이는 해당 로케일의 번역물을 지정하는 디렉토리에 저장되고, 프로그램은 컴파일한 후 libintl.a와 링크되어 만들어진다. 이후 사용자는 LANG환경변수를 해당 언어로 지정하고 프로그램을 실행하기만 하면 된다.

이러한 구조는 몇가지의 특징이 있다.

• 프로그램과 번역 메시지의 분리
• 번역물을 바이너리로 컴파일된 형태로 보관
• 영문 원본 메시지가 키로 작용

따라서 번역자는 메시지 Id에 상관없이 영문 메시지를 직접 번역하면 되고, 프로그래머와 상관없이 번역 파일을 유지하고 테스트해 볼 수 있다. 실제로 mo 파일은 프로그램 실행 시간에 읽어들이므로 이미 컴파일되어 설치된 프로그램에서 번역자는 msgfmt으로 새로운 mo를 생성하여 설치만 하고 테스트할 수 있다.

이러한 시스템의 작업을 편리하게 하기 위하여 GNU emacs의 po-mode를 사용할 수 있다. po-mode를 사용하면 po파일의 생성, 번역, 관리, 유지를 편리하게 할 수 있다.

메시지 번역하기

    #include 

    main()
    {
      int i, total;

      printf("Hello World!\n");
      for(i=1,total=0; i<=10; i++) total+=i;
      printf("Total sum of 1~10 is %d\n", total);
    }

libintl을 사용할 수 있도록 준비

    #include 
    #define _(String) gettext (String)

    main()
    {
	...
        setlocale (LC_ALL, "");
        bindtextdomain (DOMAIN, LOCALEDIR);
        textdomain (DOMAIN);
        ...

setlocale()은 현재 지정한 로케일을 초기화하는 역할을 한다. 그러나 중요한 것은 LANG환경변수의 지정 유뮤이지, 해당 로케일이 존재하는지의 여부가 아니다. 따라서 사실 setlocale()함수가 실패하더라도 gettext()는 동작한다. 이는 시스템에서 로케일 지원이 없거나, 있더라도 해당 로케일이 없는 경우라도 제대로 동작하도록 한다.

bindtextdomain()은 지정한 디렉토리에서 지정한 도메인의 메시지 파일을 찾아 열어둔다. 이는 같은 도메인을 갖는 메지시가 여러 종류 있을때, 지정된 디렉토리에서 찾도록 한다. 일반적인 gettext어플리케이션에서는 /usr/local/share/locale디렉토리 아래에서 도메인.mo를 찾는다. 리눅스는 일반적으로 /usr/share/locale 아래에서 찾으며, FreeBSD나 다른 유닉스의 경우에는 /usr/local/share/locale 아래이다. 지정된 언어와 도메인 하에서 메시지 파일은 리눅스의 경우 /usr/share/locale/언어/LC_MESSAGES/도메인.mo 를 찾게 된다.

textdomain()은 앞으로 gettext()가 메시지를 얻어낼 도메인을 정한다. 미리 bindtextdomain()으로 지정된 메시지 파일을 연결해 두는 일이 필요하며, 도메인 명은 임의로 정하면 되지만 보통 어플리케이션 이름이 된다. 여기서 LOCALEDIR은 "."으로, DOMAIN은 "test"로 해 두자. LOCALEDIR을 현재 디렉토리로 두면 현재 디렉토리에 ko/LC_MESSAGE/도메인.mo를 찾게 된다.

번역 준비

    printf("test world");

    print(_("test world"));

    print(gettext("test world"));

이제 다음과 같이 test.c를 바꿀 수 있다.

    #include 

    #include 
    #define _(String) gettext (String)

    main()

    {
      int i, total;
      setlocale (LC_ALL, "");
      bindtextdomain ("test", ".");
      textdomain ("test");
      printf(_("Hello World!\n"));
      for(i=1,total=0; i<=10; i++) total+=i;
      printf(_("Total sum of 1~10 is %d\n"), total);
    }

    xgettext --keyword=_ -d test test.c

# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR Free Software Foundation, Inc.
# FIRST AUTHOR , YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 1999-09-13 17:20+0900\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME \n"
"Language-Team: LANGUAGE \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=CHARSET\n"
"Content-Transfer-Encoding: ENCODING\n"

#: test.c:15
msgid "Hello World!\n"
msgstr ""

#: test.c:19
#, c-format
msgid "Total sum of 1~10 is %d\n"
msgstr ""

    "Language-Team: Korean \n"

각 메시지 앞에 붙는 주석문 중 #: 뒤의 것은 사용된 소스 파일과 위치를 나타내고, #, 뒤에는 메시지에 대한 속성을 나타낸다. fuzzy로 표시되어 있다면 msgid와 msgstr의 내용이 일치하지 않는 번역문임을 나타내며 이는 번역자가 살펴보고 해결해야 하고, 번역자가 제대로 고쳤다면 fuzzy를 지우면 된다. c-format으로 지정되어 있는 것은 msgid가 C의 printf()등에서 사용하는 서식 문자열이라는 의미이다. 여기에서는 %d나 %s등의 위치와 순서에 주의하여 번역해야 한다.

다음과 같이 번역하였다고 하자.

    #: test.c:15
    msgid "Hello World!\n"
    msgstr "안녕하세요!\n"

    #: test.c:19
    msgid "Total sum of 1~10 is %d\n"
    msgstr "1-10까지의 합계는 %d입니다\n"

    # msgfmt --check --statistics test.po
    번역된 메시지 2개, 퍼지 번역문 1개.

번역되지 않은 문장이 없거나 더 이상 해결할 수 없다면(번역을 꼭 해야 한다는 강박관념에서 이상하게 번역하기보다는 안하는 편이 나을수도 있다) 이제 mo파일을 만들어 보자.

    # msgfmt -o test.mo test.po

mo파일 설치

    # mkdir -p ko/LC_MESSAGES
    # cp test.mo ko/LC_MESSAGES

실행

    # cc -o test test.c -lintl

    # cc -o test test.c -I/usr/local/include -L/usr/local/lib -lintl

    # env LANG=C ./test
    Hello World!
    Total sum of 1~10 is 55

    # env LANG=ko ./test
    안녕하세요!
    1-10까지의 합계는 55입니다

다른 언어로 번역하는 경우 해당 언어 디렉토리 아래에 두면 된다. 이 디렉토리명은 보통 ISO 639에서 정한 언어명을 사용하면 된다.

기타 문제

여러가지 문제가 있겠지만 몇가지에 대해서만 생각해 보자.

메세지의 번역

    msgid "hello"

    msgid "he"
    "llo"

배열의 번역

     static const char *messages[] = {
       "some very meaningful message",
       "and another one"
     };

     ...

     string
         = index > 1 ? "a default message" : messages[index];

     #define gettext_noop(String) (String)

     static const char *messages[] = {
        gettext_noop ("some very meaningful message"),
        gettext_noop ("and another one")
     };

     ...

     string
       = index > 1 ? gettext ("a default message") : gettext (messages[index]);

서식의 순서

     "%d of %d"

     "%d 중 %d 개"

이 문제를 해결하기 위해 printf()의 서식 문자열에서 제공하는 기능을 사용할 수 있다. 즉 순서를 지정하는 것이다.

     "%2$d 중 %1$d 개"

기타 정보

다른 언어를 위한 GNU gettext

perl

Locale-PGetText:

Locale::PGetText 모듈은 gettext()인터페이스를 제공해 주는데, 만들 어진 메시지 파일은 GNU gettext의 mo형식으로 저장되는 것이 아니라 별도의 데이터베이 스로 저장된다. 따라서 기존의 gettext와는 거의 호환성이 없다고 보아도 된다. Locale::PGetText로 작성된 perl 프로그램의 예는 다음과 같다.

        #!/usr/bin/perl

        use Locale::PGetText;

        Locale::PGetText::setLocaleDir('.');
        Locale::PGetText::setLanguage('ko');

        print gettext("Hello world");
    

메시지 po 파일은 XText명령으로 추출해 내고, 메시지 데이터베이스는 MsgFmt명령으로 만들어낼 수 있다. 번역의 대상이 될 문자열은 gettext()함수 안에 쓰면 된다.

    XText < gtest.pl > test.po
    MsgFmt ...
    

이와 달리 gettext.pm은 GNU gettext를 위한 인터페이스를 제공한다. 이것의 예는 다음과 같다.

        #!/usr/bin/perl
	
        use POSIX;     # for setlocale()
        use Locale::gettext;

        bindtextdomain("gtest", ".");
        textdomain("gtest");

        print gettext("Welcome to my program"), "\n";
    

메시지 파일은 PGetText모듈의 XText로 추출할 수 있다. 번역한 것을 msgfmt로 컴파일하 여 적당한 로케일 디렉토리에 저장하면 위 프로그램의 메시지를 다른 언어로 볼 수 있다. 이 모듈의 장점은 기존의 데이터베이스도 읽을 수 있다는 것으로, 도메인만 같다면 C로 작 성한 동일한 일을 하는 어플리케이션이 있을 경우 메시지를 공유할 수 있다.

sh 스크립트

쉘에서는 단순히 gettext명령의 결과를 받아 사용하면 된다.

        gettext [TEXTDOMAIN] msgid
	

의 형식으로 메시지 Id에 해당하는 메시지를 얻을 수 있다. 도메인은 TEXTDOMAIN 환경 변수 또는 gettext의 인수로 직접 넘기면 된다. LOCALEDIR은 환경변수 TEXTDOMAINDIR로 지정할 수 있다.

Tcl

gettext-0.10.35의 소스를 받아서 풀어 보면 misc/README-Tcl파일에 Tcl에서 gettext를 사용하기 위한 확장 정보와 소스를 얻을 수 있다. 하지만 조금 오래되었으므로 사용에 주의하기 바란다. 이 확장을 사용하면 gettext라는 명령어를 사용하여 번역된 메시지를 얻어올 수 있다.

python, Guile

최근의 프로그램에는 아직 국내에서는 생소한 python이라는 언어를 사용하는 경우도 늘고 있다. python은 래드햇 제어판 등에서 사용하는 스크립트 언어인데, perl과 비슷한 용도를 갖고 있으며 객체지향적 성격이 강하다.

python의 gettext바인딩은 py-gnome에서 구할 수 있다.

      ftp://ftp.daa.com.au/pub/james/python/

Guile(GNU's Ubiquitous Intelligent Language for Extension)은 Scheme언어의 확장 라이브러리이다. Guile의 gettext바인딩은

      ftp://ftp.cygnus.com/pub/tromey/guile-gettext.tar.gz

에서 구할 수 있다. 이외에도 gettext를 지원하는 언어는 많은데, 사실 gettext은 C함수의 형식으로 구현되어 있으므로, C함수와의 링크를 지원할 수 있는 대다수의 언어에서 사용할 수 있다.

번역 프로젝트

GNU 프로젝트를 위한 번역 팀은 gettext시스템이 만들어지던 시기에 구성되었다. 다만 저작권의 문제 - GPL로 된 소프트웨어에서의 메세지의 번역자가 소프트웨어의 제작자와 마찬가지로 자신의 번역에 대한 독점적인 권리를 주장할 수 없도록 - 로 지정된 GNU프로젝트의 저작물에 대해서 번역자는(단순한 메시지와 문서를 포함하여) 자신의 권리를 포기하고 이를 Free Software Foundation으로 양도하도록 하였다. 따라서 공식 번역자들은 모두 자신의 번역물에 대한 권리 포기 각서(DISCLAIMER)를 Richard Stallman에게 제출하도록 하였다.

대부분의 GNU 프로젝트 패키지는 번역자의 권리 포기 각서가 없이는 번역자의 번역물을 배포본에 포함시키지 않는다. 권리 포기 각서를 작성하여 제출하고 승인받은 번역자는 GNU 프로젝트의 여러 문서들을 자유롭게 번역할 수 있다. 그러나 최근 증가하고 있는 비 GNU 프로젝트 어플리케이션들(그리고 GNU 프로젝트의 것이라 인정되는 경우라도 제작자의 의도에 따라)에서는 이런 권리 포기 각서가 필요하지 않다. 이런 경우에 메시지의 저작권에 대해서는 패키지 관리자의 정책에 따르도록 되어 있다.

많은 사람들은 이러한 GNU의 정책이 번역 속도를 저하시키고 새로운 사람들의 참여를 망설이게 만드는 요인이라고 한다. 실제로 필자도 fileutils의 번역을 시작하기 전에 Richard Stallman에게 편지로(전자우편이 아닌 실제 국제우편으로) DISCLAIMER를 작성하고 손으로 사인해서 보내야 했다. 이는 어찌 보면 모든 면에서 완벽하고 싶은 GNU의 정책의 산물이라 볼 수 있는데, 필자도 많이 망설였지만 한번만 수고하면 되는 일이므로 그리 큰 부담은 아니었다고 생각한다. 그러나 모든 메시지 번역에 이런 일이 필요한 것은 아니다. 자신이 메시지 번역에 대한 열정만 있다면, DISCLAIMER를 보내지 않아도 참여할 수 있는 여러 번역 프로젝트에 지금도 얼마든지 참여할 수 있다.

GNU 자유 번역 프로젝트

그림: GNU 자유 번역 프로젝트 홈페이지: http://www.iro.umontreal.ca/contrib/po/HTML/

여기서 각 국가별/프로젝트별 메시지의 템플리트와 번역 상황을 얻을 수 있다.

한국어 팀은 1995년 방준영(bangjy@geocities.com)씨에 의해 결성되어 - 실제적으로는 혼자에 의한 관심과 노력이었지만 - 현재에 이르고 있다. 한국어 팀은 중간 정도 되는 번역 성과를 올리고 있는데, 그리 번역이 활발한 상태는 아니다. 방준영씨가 군대를 간 후 약간의 공백이 있었으나, 필자가 이를 이어받아 현재까지 관리하고 있다. 한국어팀의 홈페이지는 최근에 사이트를 옮기고 새로이 구성되었다. 도메인은 시민네트워크의 김바로님의 도움을 얻었다.

그림: 번역팀 한국어팀 홈페이지: http://translation.gnu.or.kr

한국어 번역팀에서는 DISCLAIMER를 낸 자원자들에 의한 GNU 프로젝트 어플리케이션의 번역 중심으로 이루어지고 있었지만 최근에 gettext를 사용하는 어플리케이션이 크게 증가하면서, 그리고 DISCLAIMER를 낸 자원자들의 수가 1년에 한명 정도로 증가하는 현 상황 때문에 여러가지 변화가 생겼다. 사실 번역팀이 별도로 구성된 것은 GNU 프로젝트 문서와 메시지의 번역도 중요한 일이기 때문이지만, 이러한 프리 소프트웨어의 번역에 있어서 따로따로 움직이는 번역자들에게 일관되고 문의의 중심이 될 수 있는 존재가 되는 일도 마찬가지로 중요하다고 생각한다. 한국어 팀은 현재 그러한 일을 할 수 있도록 노력하고 있다. 실제 어떤 패키지의 메시지를 번역하고 있거나, 이러한 작업에 관심있는 분은 한국어 팀의 메일링 리스트인 ko@li.org에 가입하기 바란다. 가입 절차는 한국어 팀 홈페이지에서 잘 설명하고 있다.

다른 번역 프로젝트

그리고 반드시 gettext를 통한 메시지 번역이 아니라도 나름대로의 번역 시스템을 갖추고 있어 메시지를 번역해야 하는 프로젝트들도 많이 있다. nvi나 vim의 메뉴 시스템도 그렇고, 소수이지만 tcsh과 같이 catgets()를 사용하는 시스템도 여전히 존재하며, 메시지 뿐 아니라 매뉴얼 등의 문서도 같이 번역해야 할 필요성이 프리 소프트웨어가 국제적으로 점점 널리 사용되면서 커지고 있다. 자신이 좋아하거나 관심 있는 프로그램이 국제화되어 지역화를 기다리고 있다면, 지금 참여하는 것을 심각하게 고려해 보기 바란다.

KLDP(리눅스 한글문서 프로젝트): http://www.kldp.org

주로 리눅스 HOWTO문서를 다루지만 그외의 많은 오픈 소스 관련 문서도 받아들이고 있다. 우리나라에서 가장 잘 운영되는 프로젝트의 하나이다.

FreeBSD 한국어 문서화 프로젝트: http://www.kr.freebsd.org/projects/doc-kr/

FreeBSD의 각종 문서들의 번역을 주제로 하고 있다. 현재는 핸드북의 번역을 하고 있으며, 전체 핸드북의 반 이상이 이미 번역되어 있다.

Debian-kr 프로젝트: http://www.debian-kr.org/

데비안 GNU/Linux 배포본의 한국어 지원을 위해 구성된 Debian-kr프로젝트에서도 홈페이지나 문서 등의 번역이 필요하다. 데비안 프로젝트 홈(www.debian.org)에서는 HTTP의 기능을 사용해 접속하는 브라우저에서 우선순위로 지정한 언어에 대한 홈페이지를 보여줄 수 있는데, 한국어로 나타나는 페이지는 이 프로젝트에서 번역한 것이다.

끝으로

참고자료

• 류창우님의 gettext 매뉴얼 번역: http://plea.kaist.ac.kr/gnu-doc/html/gettext-doc-ko

$Id: index.shtml,v 1.1.1.1 2001/05/23 03:11:33 cjh Exp $

[ Home | Freetime works | FreeBSD | KFUG ]