자유 소프트웨어는 국제화되고 있다! 번역 프로젝트는 관리자, 번역자, 그리고 사용자를 한데 모아서, 자유 소프트웨어는 서서히 여러 개의 모국어로 말할 것이다.
GNU gettext 도구는 관리자가 그들의 패키지 메세지를 국제화하는 데
필요한 모든 것을 갖고 있다. GNU gettext는 번역자가 일단
어떤 패키지가 국제화되었을 때, 그들 모국어에 따라 지역화하는 도구들도
담고 있다.
국제화 프로젝트를 성공적으로 이끌기 위해, 그들 자신의 언어를 좋아하고 잘 쓰면서, 같은 언어를 말하는 또다른 번역자들에게 상승작용을 일으킬 수 있는 사람들이 필요하다. 메세지 번역에 작업하는데 자원하고 싶다면 여러분의 번역팀에 메일을 보내기 바란다.
Linux International의 도움을 받아, 각 팀은 각 팀의 메일링 리스트를 가지고 있다. 각 번역팀에 `ll@li.org'로 연락할 수 있는데, ll을 두글자의 ISO 639 코드로 바꾸면 된다. 언어 코드는 ISO 3166에 정의된 국가 코드와는 다르다. 다음 번역팀이 존재한다:
중국어
zh, 체코어cs, 덴마크어da, 네덜란드어nl, 에스페란토eo, 핀란드어fi, 프랑스어fr, 아일랜드어ga, 독일어de, 그리스어el, 이탈리아어it, 일본어ja, 인도네시아어in, 노르웨이어no, 폴란드어pl, 포르투갈어pt, 러시아어ru, 스페인어es, 스웨덴어sv그리고 터키어tr.
예를 들어, 중국어 번역팀은 `zh@li.org'로 편지를 써서 연락할 수 있다. 번역팀의 멤버가 되고 싶으면, 그 리스트에 가입하면 된다. 예를 들어 스웨덴 사람은 `sv-request@li.org'로 본문에 다음과 같이 써서 메일을 보낸다:
subscribe
팀 멤버는 그냥 둘러 보는 것보다는, 번역 작업 혹은 번역상의 문제점을 해결하는 데 관심있는 사람들이어야 한다는 점을 명심하자. 만약 번역팀이 존재하지 않아서 새로운 팀을 시작하고 싶다면 `translation@iro.umontreal.ca'로 편지를 보낸다: 그러면 모든 번역팀들을 조율하는 사람에게 연락할 수 있다.
몇 개의 GNU 패키지들은 이미 여러 언어에 대한 메세지 번역을 받아들여서 그 안에 제공하고 있다. 번역 팀은 이 패키지들을 시작점으로 해서 조직되었다. 하지만, 번역에 자원하는 사람이 없는 패키지도 많고 언어도 많다. 메세지 번역 작업에 자원하고 싶으면 `translation@iro.umontreal.ca'로 어떤 언어에 작업하고 싶은지 써서 편지를 보내주기 바란다.
이제 공식적으로, GNU는 국제화되고 있다! 다음은 GNU Bulletin 1995년 1월자에 실린 발표문이다:
몇개의 GNU 패키지는 이미 여러 언어에 대한 메세지 번역을 받아들였고, 이용해 오고 있다. 번역 팀은 이 패키지들을 시작점으로 해 결성되기 시작했다. 하지만, 아직 번역을 자원한 사람이 없는 패키지와 언어가 훨씬 더 많다. 만약 메세지를 번역하는데 자원할 마음이 있다면, 부디 `translation@iro.umontreal.ca'로 편지를 보내 어떤 언어(들)에 작업할 수 있는지 알려주기 바란다.
이 문서는 이 프로젝트에 대해 의문을 갖고 있거나, 기여하려는 사람들이 할만한 많은 질문에 대해 답을 해 준다. 최소한 이 문서를 훑어보기라도 하기 바란다. 자유 소프트웨어의 국제화를 향한 노력들에 의해 만들어진 좀 많은 양의 이메일의 양을 줄이 기를 바라는 마음에서 바란다.
널리 쓰이는 대부분의 공개 프로그래밍은 영어로 이루어지고, 현재 영어는 자유 소프트웨어에 관여하는 수많은 나라의 단체들 사이에 통신하는 주요 수단이다. 바로 이 문서도 영어로 쓰여졌다. 이런 풍조는 우리가 내다볼 수 미래에는 바뀌지 않을 것이다.
하지만, 지역 단체에서는 그 지역의 언어와 습관에 따라 소프트웨어를 만들기를 더 좋아하고, 그런 식으로 동작할 수 있도록 자유 소프트웨어를 수정하는 계속되어 온 노력이 있다. 이 실험이 예비 테스터들에게 너무도 열광적인 반응을 얻어내었기 때문에, 자유 소프트웨어 국제화는 성공할 것임이 분명하다.
이 문서에 대한 제안을 명확히 하거나, 추가 혹은 수정사항에 대해 `translation@iro.umontreal.ca'로 이메일을 보내주기 바란다.
이 국제화 노력을 접하면서, 몇몇 사용자는 그들의 걱정을 표현했다. 그 의심스러운 사항중 몇 가지가 여기에 소개되고, 토의된다.
getteext를 사용하면 패키지를 GNU
General Public License의 날개 아래 둬야만 하는가라고 의문을 가진다. 그
대답은 `그렇다'이다.
단순히 패키지 내의 지역화할 문자열을 표시하거나, 초기화를 위해 몇줄을
포함하는 정도는 GPL 코드를 포함하는 것이 아니다. 하지만 지역화 루틴
자체는 GPL이고, 이 라이브러리와 함게 배포하는 경우 나머지 패키지도 GPL이
되어야 한다. 내가 예상하건데 이 문제가 발생할 경우에, 최종적으로
설치하는 사람이 지역화를 위한 패키지를 모아야 하는 부담을 줄 수도
있다. 즉 지역화 루틴 자체는 배포할 때 제공하지 않는 것이다.
더 크게 보면, 참된 해결 방법은 자원자들이 참여할 수 있도록 어떤 아주 정확한 조직을 만드는 것이다 나는 최근에 여기에 대해 생각을 했고, 민감한 부분이 있을 거라는 점을 알았다. 나는 리차드 스톨만(Richard Stallman)에게 그러한 프로젝트를 시작하자고 편지를 쓰려고 생각했지만, 먼저 우리들 사이에 있는 생각들을 합쳐보는 것도 좋다고 느꼈다. 아마도 Linux International이 이 분야에 대해 이미 전문가를 갖고 있거나, 자원자들의 작업을 총 지휘할 의지가 있을 것이다. 어떤 경우든, 생각해 볼 일이다!
뭐든지 빨리, 어느 정도라도 같은 언어에 대해 기여할 사람들이 서로 중복된 작업을 막도록 돕고, 그들의 언어에 국한된 문제들을 같이 해결할 수 있도록 하는 (대부분의 언어에서, 영어로 된 기술 용어를 번역할 때 많은 어려움이 있다) 장치를 마련해야 한다고 생각했다. 스웨덴어에 기여한 많은 사람들은 이 어려움을 이미 알았고, 나 또한 프랑스어에 대해 이런 어려움을 안다.
이는 기술적인 문제가 아니지만, 각 로케일에 기여하는 노력들이, 그 기여하는 사람들과 관리자들 사이의 인터페이스를 통해 최대한 활용될 수 있도록 해야 한다.
번역 프로젝트는 번역자들을 조율하는 어떤 장치를 만들어야 한다. 계속
발전하는 프로그램을 지역화하는 것은 분명 한번 시작하면 자유 소프트웨어
사회에서 영원히 계속되야 하는 작업이다. 이러한 장치는 GNU
gettext가 공식적인 도구가 되기 전에 최소한 완결되어 있어야 한다.
`translations@iro.umontreal.ca' 이메일 어드레스가 자원자들로부터
제안 및 이 문제에 대한 그외의 이메일들을 받기 위해 준비되었다. 이
주소는 번역 프로젝트 조정자와 연락하기 위해 쓰인다.
나 역시 GNU에서 빨리 생각한 것보다 빨리, 누군가 이 모임들을 조직해서 조율하는 장치를 만들어야 한다고 생각한다. 즉 모임들을 위한 모임이다. 간략하게 말해서, 내 의견은 GNU가 이 작업을 해서 이 모임이 되면 좋다는 것이다. 아마도 `gnu.announce'에서 각 국가별 모임의 리스트를 알릴 수 있을 것이다.
조정자로서 나 Ulrich의 역할은 자유 소프트웨어 패키지들을 지역화하는 데 관심있는 독일어를 말하는 자원자의 조정자이고, 아마도 국가별 그룹이 국가별 등록업무를 떠맡을 때가지 그 임무를 대신하면서 처음 국가별 모임을 조직하는 일을 도울 것이다. 사실 조정자는 자원자가 국가별 팀을 만들때 언어, 혹은 지역별로 쉽게 서로 연락할 수 있도록 도와줘야 한다. 잘 된다면, 이 협동작업은 이 조정작업은 거대한 작업이 되는 일 없이 잘 될 것이고, 이 위치를 위임할 때가 올 것이다.
각각의 언어에 대해 조정자/편집자로서 자원할 사람을 우리가 찾아야 한다고 제안한다. 이러한 사람들은 여러 가지 언어에 대해 그들 언어에 대한 번역물들을 둘러보고, 번역의 질이 높고 통일된 표준적인 용어를 사용하도록 할 것이다.
오늘날 여러 사람들과의 경험에 따르면, 지역화를 하는 사람들은 그 작업에 대해 매우 열정적이고, 지역화하는 프로그램보다는 지역화하는 과정에 더 많은 관심이 있으며, 하나보다는 여러 개의 프로그램에 대해 이 작업을 하려고 한다. 이러한 경향은 각 언어에 대해 한 사람씩의 조정자/편집자가 있는 게 좋다는 생각을 뒷받침해 준다.
누군가 그 언어로 명확하고 잘 알 수 있는 문구를 쓸 수 있는 사람을 선택해야 한다는 의문이 생긴다. 이건 어렵다---우리는 우리 자신을 검사할 수 없다. 그러므로 몇몇 사람들에게 서로가 쓴 번역문을 평가하고, 가장 좋은 번역문을 선택하도록 해야 한다.
나는 내 프리릴리즈를 대여섯명 정도의 사람들에게 발표했으나, 모든 토론이 끝났다고 믿지 않는다. 나는 이 번역문이 공식적으로, 전 세계에 사용될 경우 일어날 결과를 생각하기가 두렵다. 예를 들어서 서로 의견이 대치되는 두명의 체코슬로바키아 사용자 사이에 누구를 찍어야 하는가?
독일팀이 프랑스어팀보다 낫다고 생각하므로 이러한 수식에 대해 평가할 수 없을 것이다. 내가 제안하려고 하는 바는 각 언어에 대해서 PO 파일을 관리하고 변경된 점을 평가하는 사람들의 모임을 만들자는 것이다. 나는 어떻게 그 사람들의 모임이 운영될지에 대해 문화적 차이가 있다고 생각하지 않는다. 어떤 모임은 관대한 방법으로, 쉽게 의견이 일치될 것이고, 모임의 누구든지 관리자와 연관되어 있을 수도 있다. 반면 다른 모임들은 죽을 때가지 싸우고, 국가의 표준을 정하도록 많은 조직 관리가 필요하며, 엄격한 채널을 사용한다.
독일 팀은 좋은 예를 보여주었다. 지금 현재 아마도 대여섯명 정도의 사람들이 서로의 번역문들을 검토하고 언어 문제에 대해 토론한다. 나는 이 이름들을 전부 알지도 못한다. Ulrich Drepper가 독일 팀의 조정자 역할을 맡고 있다. 그는 나의 모든 프리테스트 리스트에 가입하였고, 나는 발표를 앞두고 있는 패키지에 대해 특별히 그에게 알려줄 필요조차 없다.
각 언어의 팀들이 번역 작업을 하는 건 좋은 생각이라는 데는 확신한다. 번역문을 더 좋고 더 일관되도록 만들 것이다.
프랑스어를 예로 들자면, 각각 다른 용어들을 만들어 낸 여러 개의 컴퓨터 문화가 있다. 이 문제를 조직적으로 해결하지 않고 여기저기서 자원자들을 끌어모은다면 형편없는 국제화된 프로그램의 짬뽕을 만들어 낼 것이고, 아마 이 문제에 신경을 쓰는 사람들 사이에 끊임없는 싸움을 일으킬 것이다
국제화된 프로그램의 프랑스 지역화를 통일된 방법으로 하는 일은 어려운
(그리고 미묘한) 작업이다. 프랑스 사람들의 라틴계 성격을 알기 때문에
(:-), 이 작업을 잘못 한다면, 어디에서도 끝나지 않을 것이고, 수많은
에너지를 낭비하게 될 것이다. 아마 GNU gettext가 공식적으로
나오기 전에 이 문제 해결을 시작해야 할 것이다. 그리고 그건
지금 곧 해야 한다는 뜻이 아닐까!
나는 공식 발표 뒤에 큰 변화를 기대한다. 내가 짧은 GPL 메세지의 독일어 번역문을 쓴다는 사실에 주목하자. 우리는 자유 소프트웨어 공동체에서 지역화를 시작하기 전에 좋은 예가 필요하다. 다음은 몇 가지 토의해야 할 점이다:
GNU gettext에 대해 질문이 있으면, 다음으로 편지를 보낸다:
`translation@iro.umontreal.ca'
`*-pretest' 리스트도 나에게는 매우 유용하고, 이 아이디어는 많은 GNU, 그리고 GNU 이외의 패키지들에 대해 일반화될 수 있을 것이다. 하지만 각 관리자는 그들의 길을 가고 있다!
Fran@,{c}ois, 우리는 각 팀들을 추적하고, 그들을 위한 메일링 리스트를 제공하고, 멤버들을 기록할 체계를 `gnu.ai.mit.edu'에 있는 곳에 마련했다. 우리는 당신이 사용하기 좋은 것을 갖고 있다. 당신이 좋다면, 정보를 줄 수 있다.
변화하고 있다! 몇년 전에, Daniel Fekete와 내가 GNU 지역화를 위한 FSF
내의 메일링 리스트를 요청했을 때, 우리는 정중히 다른 곳에서 이 리스트를
만들라고 요청받았고, 우리는 그렇게 했다. pretester들과 연락하기 위해,
나는 iro.umontreal.ca에 위치하고 majordomo로 관리되는 여러 개의
메일링 리스트를 만들었다. 이 리스트는 지금까지 매우
믿음직했다...
나는 독일 팀이 독일 내에 위치한 메일링 리스트로 조직될 수 있을지 의심이 가고, 다른 국가들에 대해서도 그렇다. 하지만 진짜로 팀이 조직되기 전에, FSF에 위치한 메일링 리스트를 각 국가의 팀에 제공하면 분명히 좋을 것이다. 좋다, 그러면 어떻게 이 메일링 리스트를 만들고 관리할 것인가?
우리는 일단 각 국가별로 임시 메일링 리스트를 만들어서, 사람들이 모이도록 도와줘야 한다. 임시로, 모임이 다시 만들어지고 체계화되었기 때문에, 각 나라에서부터 온 자원자들에게 그 사람들의 리스트를 돌려주고, 그 사람들이 원하는 대로 관리하도록 돌려주는 게 합당할 것이다. 내 생각은, 최종적으로 각 팀이 그들의 국가 내에 있는 팀 자체의 리스트를 운영해야 한다. 각 팀들이 어떤 중심 역할을 리스트 내에서 활동하게 된다면, 모든 팀이 구독할 수 있는 이러한 리스트도 있어야 한다.
마침내 패키지가 발표되고 나서 이 메세지를 어떻게 처리하느냐에 관해 분명 논란이 있을 수 있다. 만약 사람들이 더 나은 메세지에 대한 제안을 보내오면, 어떻게 할 것인가? Jim, 지금 당장 내가 대여섯개의 지역화된 프로그램을 넘겼을 경우를 생각해 보라. 나는 번역과 번역자 사이의 조정역할을 함께 하고 있다.
내가 내 번역문중의 하나를 프리테스트하면, Ulrich는 그 발표를 받고는 독일어 팀에게 넘긴다. 그리고 마지막으로 교정한다. 그리고 그 번역 파일을 관리자인 나에게 제출한다. 이 방법은 전체 번역 프로젝트에 대해 동작할 수 있다고 생각한다. 보안 문제를 생각하면, 아마 한동안 Ulrich(사실 한 지역의 조정자이긴 하지만)가 번역 프로젝트(Jim, 나, 그리고 Len의 신입생들)에 있는 중심 등록을 갱신해야 할 것이다.
12월/1월에, 난 의욕적으로 GNU의 모든 것을 국제화할 준비가 되었고, 일주일에 한개의 작은 GNU 패키지, 더 큰 패키지는 여러 주 혹은 여러달에 한 개씩, 국제화하는 작업에 들어갔다. 나는 처음에 내가 맡고 있는 모든 일을 했다. 난 다른 관리자가 하는 일을 방해하는 것이 아니었지만, 여기에 투자한 노력의 많은 부분이 헛된 노력이 되었다---똑같은 논쟁이 다시 일어났다.
그리고 첫번째로 지역화된 패키지가 발표되었을 때 엉터리 번역에 대해 수많은 반응을 받았다 :-). 물론, 우리는 어떻게 각 지역 팀과 패키지 관리자 사이의 정보 흐름을 처리할지 좋은 생각이 있어야 한다.
각 PO 파일의 어딘가에 간단한 히스토리를 기록하는 것에서부터 시작하라. 나는 분명히 이 파일 형식이 주석문을 허용하도록 바뀔 거라고 생각한다. 각 파일이 일종의 기록, 혹은 의견, 불평, 혹은 어떤 도움을 줄 사람을 위한 참고자료를 갖고 있으면 좋을 것이다. 난 빠르고 유연한 형식에 대한 제안을 냈지만, 아직 GNU의 결정자들이 받아들이지 않았다. 이에 대한 정보를 받으면 당신에게 알려주겠다.
Go to the first, previous, next, last section, table of contents.