[ Home | Freetime works | FreeBSD | KFUG ]

모질라의 국제화와 지역화

이 글은 월간 프로그램세계 98년 10월호에 실린 기사입니다. 프로그램세계 홈페이지에서 볼 수 있는 기사는 완전한 글이 아니므로, 전체 글을 보고 싶은 분은 이 페이지의 글을 보시기 바랍니다.

1. 국제화와 지역화의 개념

이런 문제는 운영체제와 어플리케이션 중 어느 한쪽에서 발생하는 것이어서, 운영체제에서 다국어 지원을 하지 않으면 어플리케이션이 독자적으로 지원해야 하는 경우도 필요하였고, 운영체제가 다국어를 지원한다고 해도 어플리케이션 프로그래머가 운영체제의 방침에 맞추어 작성하지 않으면 소용없는 일이었다. 그러나 컴퓨터가 전세계적으로 사용되고 비영어권의 사용자들이 늘어감에 따라, 소프트웨어를 전세계적으로 공급하는 경우에 이런 영어가 아닌 언어의 지원이 필요하게 되었다. 대부분의 경우에는 영어로 된 어플리케이션을 먼저 개발하고, 이를 기반으로 하여 다른 나라 언어에 맞는 프로그램을 다시 개발하는 식이었지만, 이것도 번거로운 작업이 되므로 처음부터 어플리케이션을 어느나라의 언어와 관습에 대응할 수 있도록 하는 것이 국제적으로 널리 사용될 수 있도록 하는 소프트웨어를 작성하는 데 필요한 일이 되었다.

PC의 상황을 생각해 보자. DOS가 널리 사용되던 시절의 어플리케이션은 이런 다국어 지원의 배려가 없는 경우가 많았다. 대부분의 외국 어플리케이션은 모든 메시지와 사용 기준이 영어로 되어 있었고, 우리나라 사람들을 위해 작성된 소프트웨어에서는 한글만 출력되도록 되어 있었다. 한글 MS-DOS가 나오기 이전에 이런 영어권 어플리케이션에서 한글을 쓰기 위해 도깨비와 같은 DOS용 한글 사용 프로그램이나, 이야기와 같이 어플리케이션 내에 한글을 내장한 경우을 많이 볼 수 있었을 것이다. 전자와 같은 경우에는 기존 어플리케이션을 고치지 않아도 된다는 문제가 있었으나 프로그램의 문제에 따라 한글 지원이 불가능한 경우도 있었고(예를 들어 프로그램 내에서 문자열을 8비트 그대로 보존하지 않는다고 생각해 보자. 영문은 7비트만으로 표현 가능하므로, 8번째 비트를 다른 용도로 사용한다면 완성형이나 조합형 한글 어플리케이션은 사용할 수 없게 된다), 한글 처리부를 내장하는 프로그램의 경우에는 다른 어플리케이션이나 운영체제의 기능에 구애받지 않을 수 있었지만 프로그램마다 한글 처리부를 내장한다는 것은 프로그래머에게 큰 짐이 아닐 수 없었다. 이런 문제는 운영체제 수준의 해결 방법이 나오면서 점차 사라지게 되었는데, 특히 한글 MS-DOS의 등장과 한글 윈도우즈의 등장으로 이러한 문제는 점차 사라지게 되었다. 그러나 한글와 영어의 문제 뿐 아니라, 여기에 프랑스어나 일본어 등의 다른 나라 언어까지 함께 사용할 수 있어야 하는 그런 프로그램을 작성해야 한다면 어떤 문제가 일어날까?

이와 같이, 하나의 프로그램을 여러나라의 언어와 문화에 맞게 사용할 수 있도록 설계하고 작성하는 것을 국제화(Internationalization. 줄여서 i18n이라고 쓰며, i는 숫자 1과 구분하기 위해 보통 소문자로 쓴다. 중간의 18의 의미는 i와 n사이의 글자수이다)라고 한다. 이런 과정은 지원해야 하는 언어와 그에 필요한 기능 등을 잘 활용할 수 있는 코딩 방법을 필요로 한다. 위에서 든 예처럼, 영문만을 지원하는 어플리케이션이라면 한 문자를 7비트로 된 바이트로만 생각해도 문제가 없지만, 한글을 지원하려면 한 문자를 7비트로 된 영문과 2바이트로 된 한글 글자를 모두 생각해야 하는 것이다. 그러나 이것은 언어에 대한 문제일 뿐이고, 각 나라의 관습과 문화적 차이를 고려하려면 더 많은 문제를 생각해야 한다. 그런 문제의 예로 화폐 단위(우리나라의 경우 KSC5636에 따라 백슬래시(\)기호를 원화 기호로 대체해서 사용하고, 키보드와 글꼴도 그렇게 정의되어 있다. 하지만 일본 키보드의 경우에는 이 글자가 엔화 기호로 되어 있다)나 날짜나 시간의 표시(영어권에서는 보통 일/월/년으로 날짜를 표시하지만, 동양권에서는 년/월/일로 표시한다)를 들 수 있다. 이런 언어와 지역적인 관습의 차이에 영향받는 요소를 로케일(locale)이라고 부르며, 로케일에는 언어, 글자 셋, 날짜나 시간의 양식, 통화 기호, 문자열 정렬 순서등의 요소가 포함된다. 이런 소프트웨어는 별도의 변경 없이 로케일의 지정을 통해 어느나라에서도 적절하게 사용될 수 있으며, 최근의 운영체제는 이런 국제화를 지원하기 위해 시스템 자체에서 로케일을 도입하는 경우가 있다. 이는 NLS(National Language Support)라고 부르기도 한다. 최근의 유닉스와 윈도우즈 시스템에는 모두 이런 다국어 지원이 준비되어 있다. 넷스케이프 네비게이터는 그 자체로 국제화된 프로그램이며, 적절한 글꼴 등의 지원이 있다면 어떤 운영체제에서도 지원하는 언어를 브라우징하는 일이 가능하게 된다.

국제화에 반대되어 하나의 소프트웨어를 하나의 로케일에 맞게 작성하는 것을 지역화(Localization, 줄여서 L10n이라고 쓰며, L은 숫자 1과 구분하기 위해 보통 대문자로 쓴다. 중간의 10의 의미는 L과 n사이의 글자수이다)라고 부른다. 이는 프로그램의 메시지를 번역하고 관련 매뉴얼과 문서, 그 언어나 국가에서 사용하는 기능등을 추가하는 일을 포함한다. 우리의 경우 DOS에서 한글 처리부를 내장하였던 이야기와 같은 프로그램, 유닉스에서 사용하는 xterm을 지역화한 hanterm등이 대표적인 예가 된다. 이런 어플리케이션들은 그 언어와 관습에 맞도록 특화되어 있어 해당 언어 사용자가 사용하기에는 전혀 불편이 없지만, 다른 언어를 사용하는 사람들은 사용할 수 없다는 단점이 있다. 지역화된 어플리케이션이란 앞서 말한 이야기와 같은 어플리케이션의 예를 들 수도 있지만, 한글판 넷스케이프나 한글 워드와같이 메시지가 번역되거나 한글을 위한 기능이 추가된 것도 지역화된 것이라 볼 수 있다.

모든 소프트웨어를 국제화된 것과 지역화된 것으로 완전히 구분지을 수는 없다. MS윈도우즈의 경우 중간 정도의 형태를 취한다고 볼 수 있는데, 워드와 같은 프로그램의 경우 영문판과 한글판 사이의 기능이 일부 틀리며, 모든 메시지가 번역되어 있다. 하지만 이는 전적인 지역화라고 보기는 여러운데, 이런 기능 중 대부분(한글 입/출력 등)은 한글 윈도우의 기능에 의존하기 때문이다. 또한 이의 기반이 되는 한글 윈도우즈도 국제화되기보다는 지역화된 OS에 가까운데, 기존 어플리케이션에서 한글을 지원할 수 있도록 하기 위해 Font association(한 글자의 8번째 비트(MSB)가 1인 글자가 나오면 자동적으로 한글 글꼴로 대체하는 기능. 이때문에 한글 윈도우즈에서 넷스케이프로 독일어 웹페이지등을 기본적으로 볼 수 없게 된다)와 기본적인 한글 메시지 등을 갖고 있어서 오히려 다른 나라 언어를 사용하는데 불편함이 생기기 때문이다. 앞으로 나오는 윈도우즈 NT 5.0과 같은 경우에는 이런 문제가 해결되었다고 하니 기대해 볼 일이다(즉 한글판이 별도로 나오지 않는다고 한다). 유닉스의 경우에도, 솔라리스와 같이 동아시아 언어 버전과 영문 버전이 따로 존재하는 경우도 있으며, 디지탈 유닉스와 같이 설치할때 사용 언어를 선택하는 것만으로 충분한 경우도 있다.

2. 용어 정리

로케일(locale)

특정 지역 내에서 정의되는 언어와 관습에 따라 결정되는 요소들.

국제화(Internationalization, i18n, Globalization, Enabling)

: 다국어 로케일 내에서 작동하도록 소프트웨어를 설계하고 개발하는 일

지역화(Localization, L10n)

소프트웨어를 특정 로케일의 요구사항에 맞도록 수정하는 일. 이 글에서는 모질라 어플리케이션의 메시지 번역을 통해 지역 사용자의 언어에 맞는 버전을 만드는 과정을 말하는 경우도 있다.

지역화 정도(Localizability, L12y)

소프트웨어가 지역화될 수 있는지 판단하는 기준. 데이터를 코드에서 분리하고, 지역화 후에 대상 언어를 잘 지원해야 한다.

프론트엔드(Frontend, FE)

각 운영체제와 GUI요소에 따라 달라지는 모질라의 사용자 인터페이스. 윈도우즈의 MFC를 사용하는 WinFE, MacOS의 MacFE, 모티프를 사용하는 유닉스/X11의 XFE가 존재한다. 또한 포스트스크립트 출력 모듈(PSFE)와 텍스트 변환 모듈(TXFE)도 별도의 프론트엔드로 생각할 수 있다.

XP(Cross platform)

모질라에서 운영체제에 관계없이 공통적으로 사용할 수 있는 라이브러리를 XP라이브러리라 한다. 해당 운영체제의 함수보다는 반드시 XP라이브러리 함수를 이용해서 프로그램을 작성해야 한다. 예를 들어 malloc()함수보다는 XP_Malloc을 사용하는 것이다. 운영체제별의 차이점은 XP라이브러리에서 흡수한다.

문자셋(character set)

한 언어에서 사용하는 문자 집합의 한 글자를 비트 열에 연관시키는 것. 예를 들어 US-ASCII, KSC5601(현 KSX1001)등을 들 수 있다. 주의할 것은, 문자셋은 운영체제에서 표현하는 특정 글자의 비트 표현과 일치하지 않는다.

인코딩(encoding)

문자셋의 글자를 실제 컴퓨터에서 표현하는 비트 열에 연관시키는 것. 완성형 글자의 경우 KSC5601표준에서 정의된 글자를 MSB가 1인 2바이트 문자에 연관시키는 것은 EUC-KR, MSB가 0인 2바이트 문자에 연관시키는 것은 이를 제어하는 콘트롤 문자와 포함하여 ISO-2022-KR이라고 부른다. 넷스케이프에서는 한 언어의 서로 다른 인코딩을 선택할 수 있다. 한국어의 경우 EUC-KR과 ISO-2022-KR을 자동 탐지하지만, 일본어의 경우 SJIS, EUC-JP의 메뉴를 볼 수 있을 것이다.

문서 문자셋(document charset)

해당 웹문서나 전자우편/뉴스 기사등의 문자셋. 프로토콜 전송 과정에서 밝혀진 경우(HTML문서의 META태그나 Content-Type등의 RFC822헤더)에는 그것을 사용하며, 그렇지 않은 경우에는 프론트엔드의 View-Encoding메뉴에서 지정할 수 있다.

창 문자셋(window charset)

창 문자셋은 문서를 GUI화면에 나타내기 위해 사용하는 것으로, 일반적으로 화면 글꼴의 인코딩과 일치한다. 한글 문서의 경우 EUC-KR이나 ISO-2022-KR을 갖지만, 화면 문자셋은 WinFE의 경우 완성형 글꼴(코드페이지 949, 통합 완성형이라고도 한다. MSB가 1)이지만, XFE의 경우 ksc5601.1987-0(KSC5601, MSB는 0)를 일반적으로 사용한다.

MIME(Multipurpose Internet Mail Extensions)

RFC1521과 RFC1522에서 정의되어 있다. 기존의 7비트 ASCII문자셋을 사용하여 한 메시지 내에 여러 메시지나 바이너리를 포함할 수 있으므로, 기존 전자우편 시스템의 확장 방법으로 사용할 수 있고, 메시지의 인코딩과 변환 방법을 규정한다.

3. 모질라의 국제화

그림: 모질라 국제화 프로젝트 홈페이지

소개

• 세계를 하나의 코드 기반으로(one code base for the world)
• 영어는 단지 하나의 언어이다(english is just another language)

가이드라인

• 세계를 하나의 코드 기반으로
  지역화 과정은 소스코드를 다시 컴파일하지 않는다면 간략화될 수 있다. 외부 리소스 파일만 바꾸도록 하면 되므로, 지역 언어를 위한 조건부 컴파일은 피해야 한다. 예를 들면,

  #ifdef KOREAN
  ...(한국어만의 코드)...
  #endif
  

  와 같은것은 피해야 한다는 것이다. 따라서 한국어 윈도우즈가 아니더라도 다른 언어 윈도우즈에서 한글 웹페이지를 볼 수 있도록 해야 한다.
• 8비트를 모두 사용(8-bit clean)
  한 바이트의 8번째 비트(MSB)가 사용되지 않는다고 가정하지 않는다. 많은 언어의 인코딩에서 8번째 비트는 ASCII이외의 글자를 나타내기 위해 사용한다.
• 1문자는 1바이트가 아니다.
  한 글자는 한 바이트가 아니다. 아시아권 언어의 멀티바이트 인코딩은 한 글자가 2바이트 또는 그 이상이 되도록 한다(완성형 한글을 생각해 보면 쉽게 알 수 있다). 따라서 한글자 전진을 위해 char* 포인터에 1을 더하거나, 문자열 내의 특정 위치로 점프하면 안된다. 이 경우에는 반드시 libi18n에서 정의된 문자 탐색 코드를 사용해야 한다(소스 내에서 mozilla/include/libi18n.h를 보라). 따라서 다음 문자를 찾기 위해 INTL_NextChar, 문자의 길이를 얻기 위해 INTL_CharLen등의 함수를 사용해야 하며, 한 글자의 다음 위치를 얻기 위해 INTL_NextCharIdxInText등의 함수를 사용해야 한다. 또한 특정 길이 문자열을 저장하기 위해 고정된 배열을 사용하지 말자(512글자 문자열을 위해 char str[512]를 사용하면 안된다).
• 로케일을 이해하는 연산 사용
  날짜/시간등을 문자열로 변환하기 위해서는 로케일을 아는 함수를 사용해야 한다. 따라서 strftime()함수보다는 XP_Strftime을 쓰며, 문자열 비교 함수는 strcoll()보다는 XP_StrColl()을 사용해야 한다. 해당 운영체제에서 로케일을 지원하는 경우라도 반드시 XP함수를 사용하자.
• 프로토콜 요소는 영문
  프로토콜 요소의 문자열은 영문이다. 전자우편 헤더에서 주소를 나타내는 문자열은 "Subject:"인데(RFC822를 보자), 이는 사용자에게 보여줄 때에는 적당히 지역화된 문자열로 나타내어야 하지만, 내부적으로는 사용자 인터페이스에 상관없이 프로토콜의 문자열을 그대로 사용해야 한다.
• 비 ASCII 텍스트의 특별한 인코딩 지원
  어떤 프로토콜은 네트워크를 통해 비 ASCII문자열을 손실 없이 전송하기 위해 특별한 인코딩을 사용한다. 예를 들어 RFC2047은 전자우편 헤더에서 비 ASCII텍스트를 전송하기 위한 표준을 정의한다. 아래와 같은 Q인코딩이 이런 예에 해당한다:

   =?ISO-8859-1?Q?Andr=E9?= 

  이런 문자열이 사용자에게 직접 나타나서는 안되며, 반드시 사용자가 쓰는 문자셋으로 디코딩 되어야 한다. 역으로 전송시에 문자열은 반드시 위와 같이 프로토콜에서 사용하는 방식으로 인코딩되어 전송해야 한다.
• libi18n을 사용한다.
  가능하면 반드시 libi18n을 사용한다.

libi18n

libi18n은 모질라 모듈에서 사용할 수 있는 다음 기능을 제공한다.

• 문자 코드 변환
  여러가지 인코딩 사이의 변환을 지원한다. 예를 들어 XFE에서 완성형 문자열을 표현하기 위해서는 EUC-KR을 ISO-2022-KR과 같은 7비트 인코딩으로 바꾸어야 할 필요가 있으며, 전자우편 등에서 ISO-2022-KR을 EUC-KR로 저장하는 등의 코드 변환이 필요하다.
• 문자 경계 찾기
  국제화 가이드라인에서 말한바와 같이 한 문자씩 탐색하기 위한 API를 제공한다. 따라서 문자열 내의 문자의 갯수(문자열의 바이트 수보다 같거나 작다)나 한 문자의 바이트수 등을 검사할 수 있다.
• i18n관련 HTTP 헤더 처리
  MIME에서 정의하는 Content-Type이나 Content-Transfer-Encoding등의 언어와 인코딩 관련 헤더등을 이해하고 올바른 문자열 처리가 가능하도록 한다.
• 행/단어 구분(텍스트 레이아웃 지원)
  텍스트를 올바르게 표시하기 위해서는 행 구분이나 단어 구분을 위한 방법이 마련되어야 하는데, 빈칸만이 띄어쓰기의 구분이 되지 않으며, 때로는 개행 문자로 인한 빈칸을 언어에 따라 없애주어야 할 필요가 있다.
• 로케일 관련 연산(정렬, 날짜/시간 포맷)
  시스템의 로케일 지원에 관계없이 적절하게 문자열 정렬이나 날짜/시간 포맷을 변환해 줄 수 있는 기능이다.
• 전자우편/뉴스 헤더 처리
  HTTP헤더와 비슷하게, 다국어 인코딩과 문자셋 지정을 처리할 수 있어야 하며, 해당 언어에서 사용하는 정보 교환 표준에 따라 전자우편과 뉴스를 인코딩하여 보내고, 디코딩하여 저장한다.
• 플랫폼 비의존적인 문자열 자원
  이는 오류 메시지나 알림에서 나타나는 메시지들이 각 플랫폼이나 프론트엔드별로 따로 작성되어 지역화 과정에서 일어날 수 있는 번거로움을 막기 위해 문자열을 모두 별도의 리소스에 지정하고 이를 번역하도록 한다. 따라서 한번만 번역하게 되면 이는 모든 프론트엔드에서 동일하게 나타날 수 있다.
• 문자열 비교
  보통 문자열 정렬을 위해서는 strcmp()함수를 사용하지만, 지정된 로케일 하에서는 strcoll()함수를 사용해야 하는데, 시스템에서 지원하지 않는 로케일을 사용하는 경우에는 이를 libi18n에서 처리해 줄 수 있도록 한다.
• 유니코드 문자열 함수
  모질라는 4.0버전부터 유니코드를 처리할 수 있다. 이를 위해 각 언어의 인코딩을 유니코드로 변환할 수 있도록 하며, 유니코드의 몇가지 표현법(UTF-8이나 UTF-7)을 위해 유니코드 문자열을 변환할 수 있는 기능을 제공한다.

• 넷스케이프 네비게이터 1.1
  일본어 웹브라우징 기능에 중점을 맞추었다. 문서 문자셋과 창 문자셋의 개념이 처음 도입되었으며, 문서 문자셋을 창 문자셋으로 바꾸는 스트림 모듈이 도입되었다. 나중에 SJIS, JIS와 EUC-JP간의 자동 탐지 모듈이 도입되었다. 메시지는 여전히 영문이었지만, 나중에 메시지 리소스를 분리하여 사용자 메시지를 쉽게 번역할 수 있도록 하는 1.1i버전이 나와 일본어, 독일어, 프랑스어 버전의 넷스케이프가 나오게 되었다. 이는 2.x버전 이후의 기반 구조가 되었다.
• 넷스케이프 네비게이터 2.x
  일본어와 서구어 이외의 문자셋을 지원하기 시작하였다. 그 결과로 중유럽 언어와 중국어, 한국어 인코딩이 libi18n에 추가되었다. 또한 모든 창에 공통적으로 적용되던 인코딩 개념을 각 창별로 나눌 수 있게 되었으며, MIME헤더를 지원하는 RFC1522지원이 추가되고, XP 로케일 지원(정렬이나 날짜/시간 처리), HTTP의 Accept-Language 헤더 지원이 시작되었다.
• 넷스케이프 네비게이터 3.x
  키릴(러시아 문자), 그리스, 터키어의 지원이 추가되었으며, 아시아 언어의 행 구분 처리 기능이 강화되었다(이를 kinsoku shori라고 하며, 긴 행을 나눌 때 행의 가장 앞에 올 수 없는 글자등의 처리를 말한다).
• 넷스케이프 네비게이터 4.x
  유니코드 2.0 변환기, 한글 문자셋 자동 변환(이때부터 View-Encoding에서 한글은 Auto-detect로 표시되었다). HTTP의 Accept-Charset 헤더 지원이 추가되었다.

지금까지 libi18n의 주요 기능에 대해 알아보았는데, 이제는 이것을 모질라 소스코드 내에서 쓰는 방법에 대해 간단히 알아보자. 참고로, libi18n의 소스는 모질라 소스 내에서 mozilla/lib/libi18n에 존재하고, 사용을 위해서는 include/libi18n.h 헤더를 링크하면 된다.

• 문서 문자셋 변환
  libi18n의 주요 기능인 문자셋 변환 기능은 네트워크에서 전송되는(때로는 캐시에 존재하는) 텍스트의 문자셋을 판별하여 화면에 출력할 수 있는 창 문자셋으로 변환하는 것이다. 이는 HTML파서와 레이아웃 엔진에서 사용하게 된다. 현재의 HTML파서와 레이아웃 엔진이 HTML의 특수 문자들을 ASCII값으로 인코딩하므로, ISO-2022계열, UTF-7, HZ의 7비트 인코딩은 8비트를 사용하는 ASCII의 수퍼셋에 해당하는 인코딩(EUC와 같은)으로 바뀌어야 한다. libi18n의 문자셋 변환기는 스트림의 변환 상태를 유지하는데, 이는 상태가 있는 인코딩들(ISO-2022계열과 같이 SI(Shift In)과 SO(Shift Out)을 써서 문자셋을 바꾸는 경우)을 처리하기 위한 목적과 문자셋 자동 선택 기능을 사용하기 위한 두가지의 목적이 있다. 이런 변환 기능에는 다음의 3가지가 있다.
  • 중국어, 일본어, 한국어의 알고리즘에 의한 변환(SJIS와 EUC-JP간 등)
  • 1바이트 인코딩의 테이블에 의한 변환(CP1250과 ISO8859-2등)
  • 유니코드 변환(테이블)
  예를 들어 XFE에서 출력을 위해 사용하는 HTML문서의 포스트스크립트 변환 루틴(lib/xlate/print.c)의 비 영어 멀티바이트 문자셋의 출력을 위한 display_non_latin1_multibyte_text()함수를 보자. 이 함수에서는 문서 문자셋을 창 문자셋으로 변환하는 간단한 예를 볼 수 있다. 모르는 함수나 구조체에 대해서는 LXR인터페이스에서 소스코드를 찾도록 하자.

  소스를 볼 때, 기본적으로 각 모듈의 함수에 사용되는 접두사는 다음과 같다.

  • INTL_xxx: libi18n의 함수
  • LO_xxx: 레이아웃 모듈의 함수
  • XP_xxx: XP모듈의 함수
  • FE_xxx: 프론트엔드 모듈의 공통적인 함수

   /*
   * 이 함수는 다중바이트 문자열을 포스트스크립트 글꼴 인코딩에 맞추어
   * 변환하여 출력하는 기능을 한다.
   * non_latin1의 의미는 엄밀히 말하면 ISO-8859-1글자셋이 아닌 것이지만,
   * 여기에서는 US-ASCII가 아닌 글자들이라는 의미로 축소된다.
   */
   static void display_non_latin1_multibyte_text(MWContext *cx,
                 unsigned char *str, int len, int sf, int fontmask){
    int             charSize;
    int             convert;
    XP_File         f;
    unsigned char   *freeThis;
    CCCDataObject   obj;
    unsigned char   *out;
    int             outlen;
    unsigned char   *start;
  
    /* 현재 레이아웃된 문서 콘텍스트의 문자셋 정보를 얻어낸다 */
    INTL_CharSetInfo csi = LO_GetDocumentCharacterSetInfo(cx);
    /*
     * 문자셋 정보 개체에서 창 문자셋을 알아낸다. 여기서 창 문자셋은
     * 포스트스크립트의 글꼴 인코딩이라고 생각하면 된다
     * 포스트스크립트 변환 모듈의 경우, 글꼴 인코딩은 창 문자셋의
     * 개념과는 조금 다르지만 프론트엔드라는 관점에서 보면 출력 글꼴
     * 인코딩은 프론트엔드의 창 문자셋과 동일하게 된다.
     */
    int16 win_csid = INTL_GetCSIWinCSID(csi);
  
    /* 문자셋 변환기 개체를 얻는다 */
    obj = INTL_CreateCharCodeConverter();
    if (!obj)
    {
      return;
    }
  
    /*
     * 포스트스크립트 글꼴 인코딩과 얻어낸 창 문자셋이 같으면
     * 문자셋 변환기를 얻어낸다. convert의 값이 0이면
     * 변환하지 않고 그대로 출력한다.
     * otherFontCharSetID의 값을 세트하는 부분은
     * 모질라 소스의 cmd/xfe/dialog.c를 보기 바란다
     */
    if (win_csid != cx->prSetup->otherFontCharSetID)
    {
      convert = INTL_GetCharCodeConverter(win_csid,
                cx->prSetup->otherFontCharSetID, obj);
    }
    else
    {
      convert = 0;
    }
  
    /*
     * prSetup->out은 포스트스크립트로 출력할 파일이다.
     * XP인터페이스로 가려져 있지만. 실제로는 FILE*구조체이다
     */
    f = cx->prSetup->out;
    freeThis = NULL;
  
    while (len > 0)
    {
    /*
     * 앞에서 설명한 이유 때문에, HTML파서와 레이아웃 엔진의 특성상
     * MSB가 1로 세트된 경우 이를 비 ASCII문자셋으로 간주할 수 있다
     */
      if ((*str) & 0x80)
      {
        start = str;
        while ((len > 0) && ((*str) & 0x80))
        {
          /*
           * 한글자를 얻는다. 단순히 2바이트나 1바이트를
           * 증가시키지 않고 INTL_CharLen을 사용하였음을
           * 주의하자
           */
          charSize = INTL_CharLen(win_csid, str);
          len -= charSize;
          str += charSize;
        }
         /*
          * of는 포스트스크립트 프로시저 중
          * 영문이 아닌 글꼴을 선택하는 프로시저이다.
          * of의 정의는 lib/xlate/ps.c에서 볼 수 있다
          */
          XP_FilePrintf(f, "%d of\n", sf);
        if (convert)
        {
          /* 문자셋 변환기를 불러 한 글자를 바꾼다 */
          out = INTL_CallCharCodeConverter(obj, start, str - start);
          outlen = strlen(out);
          freeThis = out;
        }
        else
        {
          out = start;
          outlen = str - start;
        }
        /*
         * 변환된 글자를 출력한다. 포스트스크립트이므로
         * 16진수로 출력한다는 점에 주의하자.
         */
        XP_FilePrintf(f, "<");
        while (outlen > 0)
        {
          XP_FilePrintf(f, "%02x", *out);
          outlen--;
          out++;
        }
        /*
         * show는 포스트스크립트 연산자로 문자열을 출력하는
         * 연산자이다. 앞에서 of로 정한 글꼴로 출력하게 된다.
         */
        XP_FilePrintf(f, "> show\n");
        if (freeThis)
        {
          free(freeThis);
          freeThis = NULL;
        }
      }
      else
      {
      /*
       * MSB가 지정되지 않은 경우이므로, 이 경우에는
       * US-ASCII로 생각하고 그대로 출력한다
       */
        start = str;
        while ((len > 0) && (!((*str) & 0x80)))
        {
          len--;
          str++;
        }
        XP_FilePrintf(f, "%d f%d\n", sf, fontmask);
        xl_show(cx, (char *) start, str - start, "");
      }
    }
  
    /* 문자셋 변환기 개체를 해제한다 */
    INTL_DestroyCharCodeConverter(obj); } 

• 문자셋 인코딩 관리
  문자셋은 각 창과 문서마다의 특성으로 보관되는데, 이는 텍스트 입력에 의한 결과의 변환과 편집의 특성을 좌우한다. 또한 프론트엔드에서 출력할 텍스트의 위치와 크기를 측정하고 실제로 글꼴을 이용하여 그리는데에도 인코딩 정보가 중요한 역할을 한다. 문자셋 인코딩은 문서와 창에 각각 부여되며, 이를 얻는 간단한 예제는 앞의 소스코드 앞부분을 보면 알 수 있다.
• XP 로케일 함수
  XP로케일 함수에서는 문자열 비교와 날짜/시간 포맷 변환을 위한 플랫폼 독립적인 API를 제공하는데, 운영체제의 로케일 지원을 믿을 수 없기 때문이다. 이들은 앞에서 설명한 바와 같다. 예를 들어 XP_Strftime함수를 살펴보자. 이 함수는 날짜와 시간 출력을 문자열로 바꾸어 주는데, lib/xp/xp_locale.c에서 그 구현을 볼 수 있다.

   size_t XP_StrfTime(MWContext* context, char *result,
                 size_t maxsize, int format, const struct tm *timeptr){
    /* Maybe eventually do some locale setting here */
    return(FE_StrfTime(context, result, maxsize, format, timeptr)); }
  

  생각보다는 간단(?)한데, FE 접두사는 프론트엔드 모듈의 함수이다. 따라서 각 프론트엔드마다(달리 생각하면 운영체제마다) 구현이 달라진다는 것을 알 수 있다. WinFE의 경우 FE_StrfTime함수의 구현은 cmd/winfe/intlwin.cpp파일에서, XFE의 경우 cmd/xfe/locale.c에서 찾을 수 있다. 즉 플랫폼마다 달리 구현할 수 있다는 뜻이지만, 대부분의 경우 표준 C라이브러리에서 strftime()함수를 찾을 수 있으므로 이를 이용한다.

현재 프로젝트

• 아르메니아어(Armenian) 지원
  Hovik Melikyan <hovik@undp.am>
• 아라비아/히브리어 양방향 쓰기(Bi-Di) 지원
  Franck Portaneri <franck@langbox.com>와 alex khalil <iskandar@ee.tamu.edu>
• 발트어(Baltic) 지원
  Ricardas Cepas <rch@ip.lt>
• 중국어 변환 - Big5와 EUC-TW간
  Leong Kok Yong <kokyong@irdu.nus.edu.sg>
• 중국어 기능 향상 - ISO-2022-CN
  Leong Kok Yong <kokyong@irdu.nus.edu.sg>
• 중국어 기능 향상 - GBK(GB13000)
  Chen Xiangyang <chenxy@sun.ihep.ac.cn>
• 그루지아어(Georgian) 지원
  Nino Doijashvili <nino@homecom.com>
• 인도어 스크립트 지원
  Anupam Saurabh <anupam@cdac.ernet.in>
• 타이어 지원
  Samphan Raruenrom < samphan@email.ksc.net>
• 우크라이나어(Ukrainian) 지원
  Dmitry Kohmanyuk <dk@farm.org>
• 유닉스 비 라틴1 출력 향상
  CHOI Junho <cjh@kr.FreeBSD.org>
• 베트남어 지원
  Tin V Le <tin@szebra.saigon.com>

이런 기능들은 모질라의 레이아웃 모듈과 libi18n의 근본적인 변화를 필요로 하는 것들도 있다. 타이어와 아라비아어, 인도 스크립트 등이 그런 예인데, 타이어는 화면 출력에서 있어서 한글자를 표시하는데 여러 단계를 나누어야 하고, 인도어도 글자를 표시하는 면에 있어서 한글의 조합형 글꼴의 표시방법과 유사한 점이 많지만, 아직 모질라의 레이아웃 모듈은 이런 면을 지원하지 않고 있다. 아라비아어는 더 문제가 큰데, 이는 글을 대부분의 언어들처럼 왼쪽에서 오른쪽으로 쓰지 않는다는 점이다. 이런 언어에서는 한번에 한 문장을 쓰는 방향이 결정되어 있는 것이 아니라 한 문장 내에서도 쓰는 방향이 바뀔 수 있는데, 이를 지원하기 위해서는 레이아웃 모듈과 각 프론트엔드의 화면 출력부가 크게 바뀌어야 한다. 이런 언어(아라비아어 등)는 글을 양방향으로 써야 하는 관계로, Bi-Di(Bidirectional)이라고 부른다. 최근에 HTML 4.0스펙에서도 HTML문서 내에서 이런 방향성을 지원하기 위해 몇가지 태그가 새로 추가되었다.

여기에서 제시된 기능만 모질라 개발에 포함되는 것은 아니다. 이들 기능은 소스코드 정리와 중간 버전 릴리즈를 위해 별도로 정리한 것들이고, 넷스케이프의 국제화 팀은 여전히 많은 자원자 프로그래머들의 모질라 기능 개선을 바라고 있다.

필자는 유닉스의 포스트스크립트 변환 모듈의 개선을 맡고 있는데, 이는 Liu Hai(liuhai@irdu.nus.edu.sg)씨의 4.x버전의 개선 코드를 기반으로 하여 모질라 5.0에 통합하기 위한 것이다. 이는 포스트스크립트 변환 모듈에서의 다국어 지원 향상이 주 목적인데, 비영어권 문자의 여러 글자체 지원과 외부 글꼴 지원등이 큰 특징이다.

우리에게는 별로 필요없는 일이겠지만, 한가지의 언어를 추가하는 일에 대해서는 정리된 문서가 있다. 이 방법에 대해서는 "How to Add Additional Charset Support"라는 문서를 읽어보자.

한글 관련

• 한글 입력
  한글 윈도우즈의 경우에는 운영체제의 지원 때문에 한글의 입력이 자유롭지만, 유닉스의 XFE의 경우에는 XFE의 기반이 되는 모티프 위젯의 국제화 수준과 한글 처리가 직결되게 된다. 현재 상용 유닉스 운영체제에서는 전용의 한글 입력기 등을 사용하여 비교적 자유로운 한글 입력이 가능하지만, 공개 유닉스에서는 이런 종류의 한글 입력기의 부족과 관련 문제들로 인해 한글 입력이 부자연스러운 경우가 많다. 리눅스나 FreeBSD에서 많이 사용되는 공개 한글 입력기인 hanIM의 경우 브라우저의 텍스트 영역 입력창에서(<TEXTAREA>로 만든 폼) 한글의 입력이 제대로 되지 않는다.

  하지만 다국어 입력의 문제는 단지 위젯의 지원 여부에만 좌우되는 것이 아니다. 한글이 잘 입력되더라도 그것은 대부분의 한글 전용의 환경을 필요로 하므로(한글 윈도우즈나, LANG환경변수를 ko등으로 맞추고 띄우는 넷스케이프와 한글 입력기) 진정한 다국어 지원과는 거리가 있다. 예를 들어 일본어나 중국어 등을 입력하고자 할 때에는 어떻게 할 것이며, 일본어 웹페이지의 폼에서 한글을 입력하는 것은 전혀 의미없는 일이 될 것이다. 이런 문제들을 해결하기 위해서는 운영체제나 프론트엔드의 기반이 되는 GUI라이브러리에서의 지원 문제도 있으며, 이런 문제에서 사용하는 위젯의 의존성을 줄이기 위해 플랫폼 비의존적인 입력 장치를 마련하려는 노력이 있다.

  하지만 이것보다 먼저 우리의 문제를 생각해 보자. 이전에 넷스케이프 네비게이터에서 한글 입력과 입력기상의 문제는 우리가 소스를 볼 수 없었기 때문에 동작을 보고 생각하는 추측과, 넷스케이프사측게 이런 현상을 알리고 시정을 요구하는 수 밖에는 없었지만, 소스를 볼 수 있는 이상 이런 문제를 직접 해결할 수 있는 여지가 생긴 것이다. 입력기와 X윈도우 프론트엔드에 관심 있는 독자라면 이런 문제를 직접 해결해 보는 것은 어떨까?

• 한글 출력
  현재 웹페이지를 보는 것에는 어느 플랫폼이나 불편함이 없다. 하지만 좀 더 나아가서 생각해 보면, 완전한 한글 구현을 위해 몇가지 생각해 보아야 할 것들이 있다.
  • 유니코드 2.0의 모든 한글 지원
  • X프론트엔드의 조합형 글꼴 지원
  현재 대부분의 한글 웹페이지의 인코딩은 EUC-KR로 되어 있다. 이는 한글 완성형 인코딩와 영문 ASCII를 합한 인코딩인데, 현대어를 표시하는데에 필요한 거의 모든 글자를 갖추고 있지만, 고어를 표현하려 하거나, 완성형 내의 한글이나 한자 내에서 표현할 수 없는 글자들은 현재 웹페이지에서 표시할 방법이 없다. 이런 문제를 해결하는데 가장 좋은 방법은 새로운 표준을 지원하는 것인데, 이중에 가장 유용한 것은 유니코드 2.0에 정의되어 있는 현대어 한글의 11,172자의 한글을 모두 표시할 수 있도록 하는 것이고, 0x1100-0x11ff 영역에 정의되어 있는 첫가끝 한글 코드를 사용한 고어와 현대어의 한글 자모의 조합 출력을 가능하게 하는 것이다. 이는 현재 운영체제에서 제대로 지원하지 않으므로 모질라 내에서 구현해야 하지만, 한글의 완전한 구현을 위해서는 꼭 필요한 일이라 생각한다.

  XFE의 조합형 글꼴 지원 문제는 현재 hanterm등에서 사용하는 조합형 글꼴을 사용하여 웹페이지의 한글을 표시하고자 하는 것이다. 이는 현재 완성형 코드 내에서만 지원되는 유니코드 표시를 대체할 수 있는 방법이고, 조합 방식의 글꼴 표시 방법은 한글 뿐만 아니라 타이어나 인도 스크립트등을 표시하고자 할 때 꼭 필요한 방법이기도 하다. 하지만 현실적으로 조합형 글꼴이 종류나 크기 면에서 다양하지 못하고, 이런 방법이 정립된 표준이 아니라는 단점이 있다. 현재 완성형 이외의 글자를 웹페이지에서 보기 위해서 사용할 수 있는 방법은 유니코드 2.0의 UTF-8이나 UTF-7등의 인코딩으로 웹페이지를 작성하는 것인데, XFE의 경우 표준적인 유니코드 글꼴이 존재하지 않는 관계로 기존의 각 언어의 글꼴을 모아서 유니코드의 각 언어 영역의 글자를 보여주는 방식으로 처리하고 있다. 이때 한글 글꼴은 EUC-KR의 표시에 사용하는 완성형 글꼴을 사용하므로, 유니코드의 글자 중에서도 완성형 글자만을 표시할 수 있다는 단점이 있다. WinFE의 경우 한글 윈도우의 기본 글꼴은 유니코드 글꼴이므로 그런 문제가 없다. 굴림체와 같은 글꼴은 한글윈도우 95(98은 다르다)에서는 ISO10646.EXE를 실행하지 않으면 UHC영역의 글자를 사용하지 않지만, 유니코드 2.0에 해당하는 11,172자의 현대어 한글 글꼴과 한자를 모두 포함한다.

• 문자셋 변환
  넷스케이프 3.x버전까지만 해도 전자우편이나 뉴스 기사의 인코딩에 여러번 문제가 있어 논란이 된 적 있었는데, 최근에는 거의 버그가 고쳐진 상태이다. 이런 문자셋 변환의 문제는 단순히 문서 문자셋과 창 문자셋간의 문제가 아니라, 표준으로 정해진 전자우편이나 뉴스 송수신 방법에 대한 것이 중요하다.

4. 모질라의 지역화

그림: 모질라 지역화 프로젝트 홈페이지

가이드라인

• 데이터와 코드를 섞지 않는다.
  이는 프로그램 소스 내에 직접 사용자 인터페이스에 표시되는 문자열과 설정 가능한 코드를 넣지 않는다는 것이며, 이런 내용은 분리된 별도의 파일에 저장하도록 한다. 이 과정은 소프트웨어의 재컴파일을 피하고, 프로그램의 조그만 버그가 분리된 리소스간에 영향을 미치지 않도록 한다.
• 사용자 인터페이스와 사용자 설정(preference)을 섞지 않는다.
  일반적으로 지역화된 인터페이스 요소(메뉴, 다이얼로그, 메시지)는 지역화되지 않는 요소(사용자 설정 데이터)와 분리되어 저장되어야 한다.
• 그래픽에 비트맵 텍스트를 넣지 않는다.
  아이콘과 같은 그래픽 요소에 설명을 붙이고 싶으면 ToolTips(일종의 풍선 도움말)을 사용하거나 그 아래에 쓰도록 한다. 아이콘에 글자가 들어 있으면 지역화 과정에서 다시 그려야 하고, 아이콘의 크기상 맞지 않는 경우도 있다. 네비게이터의 경우 3.0버전까지는 아이콘에 텍스트까지 들어 있었지만, 4.0버전에서는 텍스트는 따로 표시한다.
• 표준이거나 인정받은 리소스를 사용한다.
  이는 운영체제에서 지원하는 리소스 형식이나, allxpstr.h의 플랫폼 비의존적인 문자열 리소스, 자바나 자바스크립트의 .property파일등을 말한다. 이들은 많이 사용되므로 지역화 도구를 만들거나, 기존 도구를 사용해서 편집하는 일을 쉽게 한다.
• 완전한 문장을 작성하자.
  바꿀 수 있는 문자열은 그 자체가 완성된 문장이어야 한다. 문장을 나누게 되면, 다른 언어로 번역하기 될 때 그 위치나 매개변수(printf()등의)의 위치를 서로 바꾸어야 할 필요가 있게 된다.
• 사용자 인터페이스를 혼란스럽게 하지 말자.
  다이얼로그는 적어도 30% 이상의 여유 공간을 남겨 두어야 한다. 번역된 문장은 원래의 영문보다 작을 수도 있지만 더 클 수도 있으므로, 이 경우에 다이얼로그의 크기를 재조정하기 보다는(일부 운영체제에서는 다이얼로그의 크기 조정을 허용하지 않는다) 처음부터 여유분을 남겨두는 것이 더 좋다.
• XP리소스를 최대한으로 사용하자. 플랫폼 비의존적인 문자열 리소스는 지역화 비용을 줄여준다. 한번만 번역하는 것으로 모든 플랫폼에서 사용하는 메시지를 번역한 것과 동일한 효과를 얻을 수 있기 때문이다. 하지만 주의할 것은, 영어 이외에는 운영체제 간에 기본적으로 사용하는 인코딩이 다를 수 있다는 것이다. 예를 들어 매킨토시의 기본 인코딩은 Mac-Roman인데, 처음 128문자까지는 윈도우즈 코드페이지 1252와 ISO-8859-1과 같지만 그 다음은 틀리다. 이런 운영체제간 인코딩 차이는 다국어 메시지를 서로 다른 플랫폼에서 공통적으로 사용하기 어렵게 하는데, 따라서 문자열에 문자셋이나 관련 정보를 지정할 수 있는 방법이 필요하게 된다.

플랫폼 비의존적인 문자열 리소스 allxpstr.h

• 개발: 개발자들은 이 파일 안에서 메시지를 추가하고, 유일한 ID를 부여한다. 나중에 개발자들은 이 텍스트를 접근하기 위해서 XP_GetString()나 XP_GetStringForHTML()함수를 사용하여 텍스트를 얻어낸다. 프로그램 컴파일 과정에서 이 파일은 플랫폼 의존적인 리소스 파일로 컴파일된다.
• 지역화: 번역자들은 이 파일을 직접 다른 언어로 번역하거나, 각 플랫폼의 컴파일된 리소스 파일을 번역하게 된다. 이를 위해서 윈도우즈와 매킨토시에서 리소스 파일 번역을 위한 도구가 존재한다.
• 실행시: 실행시에는 XP_GetString()과 XP_GetStringForHTML()함수가 플랫폼의 리소스 파일을 검색하여 메시지를 표시한다. 설치된 모질라의 언어 버전에 따라 다른 메시지를 표시할 수 있으며, 여러개의 언어용 리소스가 설치된 경우 실행시의 로케일에 따라 다른 메시지를 표시하도록 할 수 있다.

 RES_START BEGIN_STR(섹션 이름 A) ResDef(MESSAGE_ID, 메시지 번호,
메시지) END_STR(섹션 이름 A) BEGIN_STR(섹션 이름 B) ...  

 /* #define MK_HTTP_TYPE_CONFLICT           -204 */
ResDef(MK_HTTP_TYPE_CONFLICT, -204,"A communications error occurred.\n\
 (TCP Error: %s)\n\n\ Try connecting again.")  

 *strings.6796:통신 오류가 발생했습니다.\n (TCP 오류: %s)\n\n다시
연결을 시도하십시오.  

프로그래머들이 이를 소스파일 내에서 사용하려면 다음 단계를 거치면 된다.

1. XP_GetString()함수를 위한 헤더를 포함한다.

    #include
   "xpgetstr.h" 

2. allxpstr.h를 포함한다.

    #define
   WANT_ENUM_STRING_IDS #include "allxpstr.h" #undef WANT_ENUM_STRING_IDS
   

3. 문자열이 필요한 곳에서는, 다음 함수를 부른다.

   XP_GetString(MESSAGE_ID) 

   필요한 문자열이 HTML이라면, 다음 함수를 부른다.

    XP_GetStringForHTML(MESSAGE_ID, 문자셋 ID, 영문
   메시지) 

이런 메시지의 특성은 프로그램의 버전이 바뀌어도 메시지가 바뀌지 않는다는 것이다. 즉 버전 1.1에서 "foo"라는 문자열이 101이라는 ID를 받아 새로 만들어졌다면, 버전 2가 되더라도 같은 문자열(같은 의미로 사용되는)의 ID를 102로 바꾸어서는 안된다. 이와 비슷하게 버전 1.2에서 문자열 "foo"가 없어지더라도, 다른 의미의 메시지를 ID 101에 배당해서는 안된다. 이 경우에는 새 ID(예를 들면 102)를 만들고, 메시지 문자열을 배당하면 된다. 이와 같이 메시지와 ID를 배당하게 되면, 새 버전이 되면서 새로 나타난 메시지만을 번역하면 되며, 기존의 번역된 메시지는 더 이상 새로 번역할 필요가 없고 그대로 다시 사용할 수 있다.

지역화 키트

그림: 모질라 지역화 키트 다운로드 페이지

현재 프로젝트

5. 관련 정보

• 모질라 관련:
  • 홈페이지: http://www.mozilla.org
  • 뉴스그룹과 메일링 리스트:news://news.mozilla.org/netscape.public.mozilla.general, mozilla-general@mozilla.org, news://news.mozilla.org/netscape.public.mozilla.i18n, mozilla-i18n@mozilla.org 같은 주제는 뉴스그룹이나 메일링 리스트가 동일하므로, 둘중 하나만 보면 된다.
  • 소스코드 검색: LXR인터페이스: http://cvs-mirror.mozilla.org/webtools/lxr
  • i18n 프로젝트 홈페이지: http://www.mozilla.org/docs/refList/i18n/scripts.html
  • libi18n 라이브러리 참조: http://www.mozilla.org/docs/refList/i18n/libi18n
  • 모질라의 i18n/L18n 역사: http://www.mozilla.org/docs/refList/i18n/i18n-history.html
  • 문자셋 추가 방법(How to add additional charset support): http://www.mozilla.org/docs/refList/i18n/addcharset.html
• 코드와 문자셋 관련
  • 한글과 코드: http://trade.chonbuk.ac.kr/~leesl/code/
  • 한글 코드에 대하여: http://simac.kaist.ac.kr/~jwjung/seminar/hangul-i18n/ko-code.html
  • 한말/한글에 관련된 나라 안팎 자료 거미줄 한마당: http://asadal.cs.pusan.ac.kr/hangeul/
• 한글과 모질라 관련
  • 넷스케이프 4.0x의 전자우편 한글 인코딩 버그 패치: news://news.mozilla.org/netscape.public.mozilla.patches, 메시지 ID: <6k23u4$ab01@secnews.netscape.com>
  • 모질라 한글 프로젝트: http://www.www-kr.org/mozilla/, mozilla-kr-l10n@cre.co.kr (비공개 메일링 리스트)
  • 모질라 관련 한글 메일링 리스트: mozilla-ko@pimp.snu.ac.kr
    (공개. mozilla-ko-request@pimp.snu.ac.kr에 내용을 subscribe로 하여 메일을 보내면 된다)
  • Korea Mozilla Project: http://210.118.75.116/mozilla/
• 국제화 관련
  • CJK.INF: 한/중/일어 문자셋 관련 정보: ftp://ftp.ora.com/pub/examples/nutshell/ujip/doc/cjk.inf
  • 유니코드: http://www.unicode.org
  • HTML 4.0 스펙: http://www.w3.org/TR/REC-html40/
  • International Text in JDK 1.2: http://www.ibm.com/java/education/international-text/index.html