Changwoo's Hacks

최근 우분투 런치패드는 런치패드에 들어 있는 번역문에 대해 BSD 라이센스로 확인하는 작업을 하고 있다. 일정은 없지만 동의하지 않은 번역문은 런치패드 시스템에서 지워질 예정이다.

이러한 조치는 런치패드의 번역문들이 라이센스를 명확히 하지 않는다는 비판과 더불어, 번역문을 여러 프로그램 사이에 공유할 때 생기는 라이센스 문제에 대한 해결책으로 보인다. (예를 들어 GPL 프로그램의 번역문을 LGPL 프로그램에 사용하는 경우처럼.)

하지만 왜 하필 BSD이며, 왜 BSD가 아니면 시스템에서 지운다는 걸까?

첫째로 과연 GPL 소프트웨어의 번역을 BSD로 하는 게 가능한 것인가 의문을 갖게한다. 원문은 GPL 라이센스로 배포되는 프로그램의 소스코드에서 xgettext 프로그램을 통해 추출한 것이고 번역문은 파생 작업이라고밖에 할 수 없다. GPL 코드에서 추출한 템플릿을 번역한 번역문의 라이센스를 BSD로 한다는 게 가능한 것일까?

또 실제적으로 런치패드의 온라인 번역 시스템이 훌륭하긴 하지만 여전히 훨씬 더 많은 번역문들이 이 시스템 밖에서 만들어져서 런치패드 시스템으로 import되고 있다. 런치패드에 들어 있는 번역문의 대다수는 런치패드에서 시작한 번역문이 아니라 외부에서 import한 번역문을 보완한 정도이고 이렇게 GPL 번역문을 고쳐서 만들어진 결과물을 BSD 라이센스라고 할 수는 없다. 이러한 모든 번역을 지우고 런치패드 내부에서 scratch부터 시작할 것인지?

그리고 GPL은 GPL의 가치가 있다. 나는 내가 번역한 번역문이 해당 소프트웨어의 라이센스를 따르게 할 뿐, 일부러 번역문에 BSD 라이센스를 사용할 생각은 전혀 없다. GPL의 파생작업에 대한 라이센스 조항을 좋아하든 싫어하든 이 GPL 조항은 자유소프트웨어 발전에 대단히 큰 역할을 했다. 런치패드 시스템에서 사용하려고, 호환성때문에 GPL이었을 때의 장점을 버리고 BSD를 택한다는 건 받아들이기 힘들다.

몇몇 언어의 그놈/데비안/KDE 번역 팀들은 런치패드 시스템의 편리함때문에 공식적인 번역 도구로 사용하고 있다. (한국어 번역팀은 아님.) 런치패드의 이러한 조치는 이 팀들이 계속 런치패드에서 작업해야 하는지 고민하게 만들었다. 번역문 사이의 호환성이 문제라면 좀 수고를 하더라도 라이센스 호환성 문제를 처리하도록 시스템을 구현할 수도 있지 않을까? 왜 BSD로 통일해야 하며 그게 아니면 시스템에서 지워야 할까? 이러한 결정은 지금까지 훌륭히 번역 작업을 해 온 런치패드의 발목을 잡게 될 것이다.

예전에 회사 팀장과의 에피소드:

팀장모씨: (팀원들에게) 리포트 쓸 때는 말이지 이건 저렇게 하고 저건 저렇게 하고..  그리고 전문용어 영어 단어같은 거 그냥 영어로 쓰라고. 다 알아들으니까 말이야.

창우: (속으로 투덜투덜...) 얼마나 다 영어로 쓰나요?

팀장모씨: 전부 다. 여기 단어 몇개 영어로 나온다고 문제 될거 없잖아? 오히려 엔지니어들한텐 그게 읽기 좋다고.

창우: 그거보다 훨씬 많아요. encoding, decoding, source code, compile, build, bug, editor, debugger, typing, ....  한글은 몇 개 안 남네요. (다 고쳐서 한 줄에 영어단어가 너덧개씩 있는 보고서를 보여준다) 자 이렇게 쓰면 가독성이 좋을까요?

팀장모씨: ...  (독해에 어려움을 겪는 모씨...)

썬의 번역 가이드

썬마이크로시스템에서 만든 StarSuite style guide에 보면 이런 말이 들어 있다.

1.4.2한국어로 번역하지 않는 용어들 (Do not translate)

1. 고유 명사나 소프트웨어, 운영 체제 등의 고유 이름

MySQL (ODBC) -
PostgreSQL
MySQL (JDBC)  
Mozilla
Adabas D      
Microsoft Outlook
Oracle JDBC   
Microsoft Windows
JDBC          
LDAP
ODBC          
Evolution
XStorable
...

이 부분은 내가 오픈오피스 번역 중에서 가장 못 마땅하게 생각하는 부분이다. 번역 가이드의 다른 부분은 몰라도 위 사항은 절대 따르지 않고 번역이나 음역하기를 권장한다. 특히 Gnome은 영문 그대로 쓰지 말고 "그놈"이라고 표기하기를...

Branding

"언어와 문화가 다른 지역에 진출할 때 기존 브랜드를 어떠한 형태로 사용할 것인가?", 이 문제는 어제 오늘의 문제는 아니다. 수십년동안 기업들의 글로벌화가 진행되면서 회사는 저마다 경우에 따라 다른 전략을 취해 왔고 뭐가 정답이라고는 쉽게 말할 수 없다. 보통 3가지 방법 중에 하나를 선택하게 될 것이다.

1. 본래 브랜딩의 철자를 그대로 가져간다.
2. 본래 브랜딩을 그 나라의 언어에 맞게 음역한다.
3. 본래 브랜딩을 포기한다. 새로운 브랜드를 만들어 낸다.
   

실제로 한국에 진출한 글로벌 기업은 어떤 전략을 사용했을까?

영어 약자로 된 브랜드는 (KFC, HP, ...) 음역으로 쓸 수 없기 때문에 다른 선택이 없지만, 그 외에 1의 선택을 하는 경우는 의외로 별로 많지 않다. 길거리에서 영어로 가득한 간판을 보긴 하지만, "우리 STARBUCKS는..."이라고 회사 소개를 하지는 않는다. 거의 모든 회사가 "맥도나알드~"라고 멋드러지게 한글 음역을 이용하지 TV 화면을 영어로 가득 채우지는 않는다.  우리들도 일상 생활에서 "아웃백에서 봐요"라고 문자를 보내지 "Outback에서 봐요"라고 쓰지는 않는다. (게다가 1바이트 더 많다!)

3번째로 새로운 브랜드를 만들어 내는 경우도 잘 찾아보면 드물지 않게 볼 수 있다. 햄버거 체인점인 하디스(Hardees)는 미국의 찰스 쥬니어를 가져온 것인데 찰스 쥬니어는 말도 길어지고 왠지 맛있는 느낌이 안 나니까한국판에서는 새로운 말을 만들어 냈다. 한솥도시락은 일본의 도시락 체인점인 혼께가마도야의 메뉴와 시스템과 인테리어를 그대로 가져왔지만 이름은 우리말로 다시 지었다.

1과 2의 장단점을 적당히 취하는 경우도 볼 수 있다. 많이 사용하는 방법이 로고는 원래 영어가 들어간 로고를 무슨 그림 마냥 그대로 사용하면서 글자로 쓸 경우는 한글 음역을 사용하는 방법이다. (스타벅스, 커피빈, 아웃백 스테이크하우스, 리바이스, ...)  원래 로고와 한글 로고를 둘 다 만들어 놓거나 원래 로고의 영어에 한글 표기를 추가하는 식으로 동시에 사용하면서 글자로 표기할 때는 한글 음역을 쓰는 경우도 있다. (맥도날드, 버거킹, 철수하기 전의 월마트, ...)

하지만 로고나 간판을 원래 브랜드 그대로 이용하는 경우는 많아도, 일반 광고나 보도자료 등의 일반 텍스트 문서에서 영어 표기를 고집한 회사는 한국에 들어온 글로벌 기업중에 거의 없었다. (약자로 된 브랜드는 제외.) 몇가지 예외가 있으니 바로 소프트웨어 회사들이다. 마이크로소프트는 양지사 와의 상표 분쟁에서 패소했기 때문인지는 몰라도 "Windows 95" 이후 계속해서 한글마이크로소프트의 제품 설명에서도 "Microsoft Windows" 영문 표기를 고집하고 (그 전에는 "윈도우"라고 사용했다) 오피스의 경우에도 프로그램 메뉴에까지 "Microsoft Word"라고 영문으로 들어가 있다. 어도비, 오라클 등등 모두 영문 표기를 고집하고 있다. (하지만 광고나 그렇지 절대로 언론은 영문 표기로 보도해 주지 않는다.)

한글로 음역해서 쓰는 이유는 그게 세종대왕과 주시경선생께서 기뻐하시는 옳은 방향이라서가 아니라, 그게 더 올바른 브랜딩 전략이기 때문이다. 잠재적인 소비자들에게 쉽게 인식되고, 쉽게 기억되고, 눈에 잘 뜨이는 게 좋은 브랜드이다. 현재 평균적인 한국 소비자들은 왠만큼 교육 수준이 높은 경우에도, 영어 그대로 쓴 브랜드는 기억하거나 인식하기에 힘든 게 현실이다. 물론 본래 브랜드를 지역화하는 비용도 있고 본래 브랜드가 손상될 우려가 있어서 본래 로고를 남겨두고 일부만 지역화한다든지 선택을 할 수는 있다. 하지만 트레이드오프로 그런 선택을 할 수는 있어도 영어로 쓰는 게 한글로 쓰는 것보다 더 원래 의미를 전달하니까 좋은 브랜딩이다라고는 할 수 없다.  구찌, 버버리, 까르티에의 영문 철자를 기억하고 있는 사람이 얼마나 될까?  (소프트웨어 회사들이 예외적인 전략을 쓰는 이유는 한국의 소프트웨어 소비자들이 영어에 익숙하기 때문일까?)

에볼루션은 있는데 Evolution은 어딨지

썬의 번역 가이드는 첫째로 한국에 진출한 브랜드들이 취한 현실과 다르다. 위에서 말한 것처럼 한국에 진출한 글로벌 기업의 대부분은 브랜드를 한글로 음역했다. 특히 그놈 에볼루션은 분명히 (내가!) 한글로 "에볼루션"이라고 음역했고 한국어 데스크탑에는 프로그램 정보 창을 보지 않는 한, Evolution이라는 단어도 찾아보기 힘든데 예제에까지 "Evolution"이라고 써 놓는 건 맞지 않다.

또 (소프트웨어 회사들의 상업용 소프트웨어들도 그렇지만) 그 지역의 언어로 표기하는 편이 쉽게 인지되고 기억되는 더 좋은 브랜딩인데도, 왜 OpenOffice.org, Firefox 따위의 번역도 그 "OpenOffice.org", "Firefox"라는 이름만은 영문 표기를 하는 브랜딩을 고집하는지 이해하기 힘들다. (번역자 맘대로 건드리기도 힘들게 만들어 놨다.)

기반  (based on, derived)

위하여 (to ~, for ~)

~하는 것이 (to ~, what/which/that ~)

적절한/적절히 (proper, appropriate, accordingly, ...)

제공 (provide, offer, come with, ...)

설정 (option, configure, preference, property, ...)

포함 (have, contain, exclude, consist of, ...)


"A를 기반으로 하는 적절한 B를 포함하기 위해 C 설정하는 것을 제공합니다"

위의 단어를 합쳐보면 이 정도 문장이 되는데...  의외로 많은 메세지 번역에서 제공하고 설정하고 포함하는 정도로 상당히 수많은 영어 단어를 번역하고 있다. 형태소 분리 프로그램이 제대로 돌아가는 게 있다면 PO 파일의 단어들에 대해 통계를 내는 것도 의미가 있어 보이는데..  나를 포함해 누가 한 번역도 이 빈약한 번역 어휘의 문제에서 자유롭지 못할 것이다.

해결 방법은 평소에 폭넓은 독서와 글쓰기를...  (논술 시험?)

OLPC 배포국가: 브라질(포르투갈어),멕시코(스페인어),우루과이(스페인어),페루(스페인어),팔레스타인(아랍어),리비아(아랍어),나이지리아(아프리칸/영어),에티오피아(암하라),르완다(르완다어/프랑스어),타이(태국어).. 

OLPC를 쓰고 싶은 개도국 어린이는 영어부터 배워야?

괜한 네거티브가 아니라..  OLPC 하드웨어는 양산을 시작했지만, 소프트웨어 완성도는 아직 "글쎄"다. 국제화나 번역쪽은 특히나 진행이 느려서 사실상 영어 못 쓰면 사용이 어렵다. 네그로폰테가 방한해서 잠깐 했던 말처럼 북한에 OLPC를 보내는 사업을 하게 된다면, 한국어 XO 번역 커뮤니티를 만들 필요도 있을 것이다.

(업데이트) 지금 OLPC 한국어 개발과 관련되어 참여하고 있는 "것처럼 보이는" 사람들은, 방향이 현실성 없는 정치적인 활동이나 OLPC의 기본 방향과 다르게 별개 사업을 진행하려고 하고 있다. 이 사람(들)이 지금 활동하고 있는 것 같지도 않고 이대로 성공할 거라고 생각하지도 않지만, 혹시라도 이러한 방향으로 협조하지는 말기를..

온라인 번역 시스템으로 pootle을 심각하게 고려해 보았으나 결론은...

못 쓰겠다 (적어도 지금은)

그리 나쁘다라는 게 아니다. pootle은 매우 간결하고, PO 파일을 백엔드로 사용해서 그런지 PO 파일 번역에 좋고 훌륭하게 처리한다. 사용자별로 권한레벨을 분리해 놓았고, translation-toolkit에 잘 구성되어 있는 파이썬 모듈을 이용해 메세지별로 온갖 체크를 온라인에서 할 수 있다.  (여기에 KPC를 붙이면 금상첨화)  이정도만 되도 일단 시작하는 데 문제가 될 일이 없다. launchpad가 우분투 스케줄대로 움직이고 closed source이기 때문에 직접 컨트롤할 수 있는 웹 번역 시스템은 pootle이 유일하다. 하지만, 결정적인 문제는,

기록이 안 남는다

아무리 후지고 완성도가 시스템이라고 해도 개선의 여지가 있으면 그래도 일단 돌리고 볼 텐데, 당장 반달리즘으로 작업물이 날아갈 수 있다는 점은 참 어려운 이야기이다. 백엔드가 PO 파일이기 때문에 PO 파일을 그냥 고쳐버린다. RDBMS를 쓸 필요까지야 없겠지만 백엔드의 한계때문에 변경 사항의 기록을 남기도록 고치는 것도 매우 힘들다.

어색한 메세지 번역을 피하는 팁 몇가지에 이어...서 쓰는 건 아니고 관련 있는 몇 가지 메모:

한자를 붙여 신조어 만들기: 비(非)~, ~자(者), ~기(機)

우리가 일상생활이나 컴퓨터에서 쓰는 단어 중에 분명히 비~, ~자, ~기라는 단어가 있고, 많이 쓰는 건 사실이다.  nonpreemptive/비선점, editor/편집기, constructor/생성자, manager/관리자 등등등..  이러한 단어들이 만들어지게 된 유래가 (상당부분 중국과 일본에서 만든 한자 차용) 옳은지 그른지는 재쳐두고라도, 번역할 때 이러한 단어를 임의로 만드는 일은 정말 바람직하지 않다.   non-free - 비자유?, tokenizer - 구문분석자?, monitor - 감시기?  일단 보기에 어색하다.

이미 익숙하게 쓰는 단어가 아니라면 "비~" prefix가 한글로 붙었을 때 그게 부정의 의미인지 파악하기 어렵고, "~기"나 "~자"를 소프트웨어에 사용하는 것도 우리말에 자연스럽지 않다.

살아있는 소프트웨어

흔히 이야기하는 "수동태를 쓰지 말라"는 번역 팁과 연관있는 이야기로, 우리말에선 생명체가 아닌 존재에 동사를 잘 붙이지 않는다. 무생물은 주체적이지 않다.  (철학적인 문제?)

예를 들어 프로그램의 메세지에서 "I"와 "YOU"를 사용하는 말이 나올 때 상당히 고민하지 않으면 자연스럽게 번역하기 힘들다. 흔히 영문 메세지 원문에서는 소프트웨어가 생명을 가지고 사용자와 대화하는 것처럼 I를 주어로, you를 목적어로 사용하는 경우가 있는데 "나는", "당신은"이라고 번역하기 시작하면 번역 결과물이 상당히 곤란해 진다.

마땅히 무슨 말을 써야 한다는 정답은 없고, 아예 I나 you를 번역문에서 언급하지 않고 충분히 뜻이 통하도록 적당히 번역하는 게 가장 좋은 것 같다.

과거에도 그랬듯이, 배포판 중심의 메세지 번역은 보통 그 배포판 안에서만 사용되고 그 안에서 수명을 다한다.

우분투의 런치패드/로제타는 온라인 메세지 번역 시스템으로 기술적으로는 내가 생각했던 이상적인 모습이지만, 배포판 중심의 번역 운영은 (한국이든 세계 어디든) 커뮤니케이션의 문제를 가질 수밖에 없다. 예전에 런치패드/로제타에 의해 한국어 번역이 시작되었을 때 내가 우려했던 것처럼 업스트림과 따로 노는 현상이 벌어지곤 한다.

간단히 예를 들어 우분투 feisty의 한국어 번역 중에서 KDE 관련 프로그램은 로제타에서 많은 부분이 번역되어 있다.  많은 부분이 비슷한 모습을 보이지만, 꽤 많이 번역된 일부분을 보면,



그럼 KDE upstream의 한국어 통계를 들어가서 이 부분이 업스트림에 어떻게 되어 있는 지 확인해 보자.  위에 나온 kdebase를 비교해 보면 다음과 같다.  거의 반영이 되어 있지 않다.



그럼 보너스로 또 한 가지 비교해 보자.  한소프트리눅스는 어떨까?  한소프트리눅스 오픈 프로젝트에서 kde-i18n 패키지의 src.rpm 파일을 받아서 확인해 보았다.

zeus:~/tmp/kdebase/kde-i18n-ko-3.5.6/messages/kdebase$ for X in kcm*po; do msgfmt --stat $X -o /dev/null; done
번역된 메시지 70개.
번역된 메시지 47개.
번역된 메시지 68개.
번역된 메시지 121개.
번역된 메시지 21개.
번역된 메시지 8개.
번역된 메시지 67개.
번역된 메시지 34개.
번역된 메시지 180개.
...

어라?  -_-  완벽한데 대체 무슨 일이 벌어진 것일까?  과연 누가 이걸 번역했는지 알아보기 위해 PO 파일의 Last-Translator: 엔트리를 찾아보았다.

zeus:~/tmp/kdebase/kde-i18n-ko-3.5.6/messages/kdebase$ grep Last-Translator: kcm*po
kcmaccess.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmaccessibility.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmarts.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmbackground.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmbell.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmcgi.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmcolors.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmcomponentchooser.po:"Last-Translator: root <root@localhost.localdomain>\n"
kcmcrypto.po:"Last-Translator: root <root@localhost.localdomain>\n"
...

다름 아닌 한소프트리눅스 측에서 자체 번역한 결과물이다.  (위의 결과로 알 수 있는 사실, 번역자는 루트 계정으로 KBabel을 이용해 번역한다.)  이것이 한소프트리눅스 광고에 등장하곤 하는 "전문 번역팀을 통해 자연스럽지 못했던 한글 번역부분을 말끔히 개선하였습니다"의 실체인가?

"위와 같은 꼴"을 보고 절대 잘 한다는 소리는 절대 못하겠지만, 어제 오늘의 일이 아니고 이제는 적어도 이해는 할 수 있다.  FOSDEM 2007의 비디오 중에서 리눅스 커널에 관한 세션을 보면 이런 얘기가 있다 -- "임베디드 분야의 리눅스 커널의 발전이 더딘 이유는 피드백이 없기 때문인데, 칩 메이커를 제외하고 완제품을 만드는 제조업체들은 제품의 개발기간도 짧은 데다가 스펙이 한정되어 있고 소프트웨어 업데이트도 거의 없기 때문에 피드백의 현실적인 필요가 적다".  배포판 업체들도 마찬가지이다.  번역에 관한한 충분한 맨파워를 동원할 수 있다면 (우분투와 한소프트리눅스는 그 방법을 다르게 취한 것 같지만) 업스트림 피드백으로 얻을 건 별로 많지 않다.  런치패드/로제타의 자발적인 참여자들도 자기들의 번역 결과물이 자기가 사용하는 OS에 반영되는 것만으로도 상당히 만족하고, 또 다른 업스트림에 반영하는 건 런치패드/로제타보다 진입장벽이 높기 때문에 부담스러워하는 것도 같다.

이 상황을 어떻게 해결해야 하나.  업스트림에 번역을 반영하는 장벽을 낮추는 게 한 가지 방법이지만, 어떻게 쉽게 컨트롤할 수 없는 부분이다. 적어도 내가 상당부분을 컨트롤하고 있는 그놈 / 데비안 번역은 가능할 것도 같은데, 앞으로 생각할 부분이다..

보안용 장비를 만들 시절에, 회사에서 번역 업체를 많이 이용했었다.  이 번역업체는 세계 곳곳의 각 언어권마다 지사를 두고 있는데 각 지사마다 네티이브 번역자가 있는 동시에 그 지역의 번역 의뢰자를 상대로 영업을 한다.  번역 의뢰가 들어오면 원문을 각 세계 지사에 보내서 네이티브들이 번역을 하게 만든 다음 번역한 결과물을 모아서 의뢰자에게 돌려준다. 이런 식으로 동작하는 번역 전문 회사가 꽤 많이 있고, 이 방식으로 꽤 괜찮은 품질의 번역을 빠르게 만들어 낼 수 있다. 보통 제품을 릴리스할 때마다 백여개 내외의 메세지가 독일어, 프랑스어, 이탈리아어, 스페인어, 일본어로 5개국 번역이 되었는데 (정확하진 않지만) 60-70여만원정도가 필요했다.  (그러면 GNOME 2.18의 한국어 메세지는 35000여개가 되므로 이 계산법에 따르면 수억의 가치가 있다고 할 수 있다. ^^)

그 번역 업체는 IT 전문 번역을 표방했고 상당히 많은 경험이 있는 것으로 보였다.  하지만, 번역이라는 건 그렇게 뚝딱 할 수 있는 게 아니다. 번역이라는 작업은 한계가 있다.

1. 번역자가 CCTV 시스템에 대한 지식이 부족했다.  예를 들어 전통적인 보안 시스템에서 NC/NO는 Normally Close, Normally Open으로 보안용 센서의 종류를 나타내는 말로 "붙은" 상태가 정상인가 "떨어진" 상태가 정상인가를 나타내는 말이다.  (예를 들어 출입문에 부착하는 접점 센서는 닫혔을 때 즉 붙은 상태가 정상이고 문을 열면 떨어지면서 센서가 activate된다.) 하지만 많은 번역자가 NC를 (유행이 한참 지난 용어인) Network Computer라고 번역하기 십상이었고 NO를 Number의 약자로 번역하기 십상이었다.

2. 꽤 오랜 기간동안 제품을 업데이트하다 보니 번역을 하면서 일관성이 맞지 않는 부분이 많이 발생했다.  의뢰인인 우리쪽 입장에서는 사실 누가 번역했는지는 알 수도 없고 신경도 안 쓰는데, 같은 용어를 여기저기서 다르게 사용한다든지 말투가 달라진다든지 하는 일이 그 언어를 전혀 모르는데도 뻔히 알 수 있을 정도로 자주 발생했다.

3. 번역 업체와는 상관없지만 번역한 결과를 적용할 때마다 언제나 화면 크기의 부족에 시달렸다.  작은 NTSC/PAL TV 화면의 크기에 맞춰야 하는 입장에서는 난감하기 짝이 없었다.  화면상의 각종 컨트롤의 크기를 dynamic하게 만들고 복잡한 클리핑과 스크롤 기능으로 보완해 보려고 했지만 결국 한계가 있었고, 특히 이탈리아어와 스페인어의 경우 점(.)으로 단어를 줄여쓴 (Abracatabra라면 Abra. 식으로) 신조어 레이블이 화면의 많은 부분을 차지하게 되었다.

옛날 얘기는 여기까지 하고 현재로 돌아와서, 위의 현상은 오픈소스 소프트웨어의 메세지 번역에도 똑같이 적용된다.  얼마전에 그놈 2.18이 릴리스되었지만, 여전히 (1) 메세지의 일부는 해당 프로그램의 기능에 대해 잘 이해하지 못한 부분때문에 오역이 있고, (2) 업데이트하면서 가끔 말투와 용어를 다르게 쓰기도 하며, (3) UI의 문제때문에 번역해 놓은 모양이 아주 보기 나쁜 경우가 많이 있다.  이와 같은 실수는 번역자의 실력과 경험에 따라 달라지겠지만 여전히 발생한다.

이와 같은 문제를 100% 없애기는 쉽지 않다.  실제로 마이크로소프트가 공개한 마이크로소프트가 릴리스하는 번역문도 하나하나 살펴보면 어색한 번역문도 있고 오역이라고 생각되는 번역문도 꽤 있으며 시간이 지나면서 다른 용어를 사용하는 부분도 꽤 보인다. 하지만 그 번역문 중에서도 자주 사용하는 마이크로소프트의 대부분의 번역문은 아주 매끄러운데, 이는 다름 아니라 엄청난 사용성 테스트의 결과물이다.  역시 피드백을 많이 받아서 계속해서 다듬어 나가면 잘 번역했다는 소리를 들을 수 있다는 얘기이다. 하지만 역시 보안 장비를 만들 때나 그놈 메세지를 번역할 때나 자기 스스로 깨닫고 고치는 것 외에 외부에서 피드백을 받기는 쉽지 않은 일이다. 그놈 메세지는 특히, 심심풀이 작업때문에 일부러 프로그램 테스트를 심각하게 할 수는 없는 노릇이다.

그래서 앞으로 그놈 및 내가 참여하는 번역은 번역자들의 (특히 류모씨의) 부담을 줄이면서도 좀 더 많은 참여와 피드백을 받고 번역을 다듬을 수 있는 방법을 찾아 보려고 한다. 어떤 게 될 지는 나도 아직 잘 모르겠으므로 다음 시간에...

glade3 번역을 하다가 잠깐 든 생각..

그놈 UI 위젯의 하나로 GnomeDruid라는 것이 있다.  프로그램을 처음 실행했을 때 여러가지 설정을 순서대로 한다든지 할 때 사용하는 GUI 위젯으로, "다음"/"이전" 단추를 눌러가며 순서대로 복잡한 설정을 해 나갈 때 쓰는 위젯이다.  당연히 이 위젯은 "마법사"(Wizard)의 패러디이다.

하지만 아마 한국말로 그놈 프로그램을 사용하고 있는 사람들은 "마법사"만 볼 뿐이지 드루이드라는 말은 본 적이 없었을 것이다.  아무리 원문에서 Druid라고 해도 마법사라고 번역할 수밖에 없었다.  위저드나 드루이드 모두 우리 문화에서는 존재하지 않았던 것이지만, 외래 문화의 수입으로 "마법사"는 많이 알려졌다.  또 마이크로소프트가 "마법사"라는 GUI가 이런 것이다라는 걸 많이 주입을 시켰기 때문에 "마법사"라는 용어가 자연스럽게 받아들여진다.  아마 판타지 소설이나 게임을 통해 접한 사람이 아니라면, 드루이드라는 게 무엇인지 모르는 한국 사람이 대부분이고 알더라도 마법사가 들어갈 자리에 드루이드를 쓴다면 혼란을 일으킬 것이다.

하지만 glade를 쓰는 사람들은 드루이드라는 말을 보게 될 것이다.  glade는 개발자용이니까 위젯 이름을 그대로 반영하는 게 좋다.

(업데이트) 이제 GnomeDruid는 deprecated이고 GtkAssistant로 대체되어 이제 마법사라는 말조차도 못 보게 될 것 같다.

문장 부호를 똑같이 붙이려고 하지 말아라.
- 우리말에서는 문장에 세미콜론을 쓰지 않는다.
- 원문에 쉼표가 있다고 번역문에 쉼표를 넣을 필요는 없다.  우리말로는 쉼표를 쓰지 않아도 문장이 명확한 경우가 많다.
- 영어에서는 흔히 문장 끝에 괄호를 열고 괄호를 닫은 다음 마침표를 찍는다.  하지만 우리말에서는 그렇게 쓰지 않는다.

영어 문장의 처음에 쓰인 대소문자를 그대로 따라할 필요는 없다.
- 영어에서는 첫 단어가 소문자로 쓰는 단어일 경우에도 (프로그램 이름 따위) 대문자로 만들어서 쓴다.  그대로 쓰지 않도록 신경 쓴다.

관계사가 줄줄이 붙은 문장을 한문장으로 번역하려고 순서를 여기저기 뒤집지 않는다.
- 어느정도 같은 말을 반복하더라도 여러 문장으로 쓰는 편이 낫다.  한 문장으로 쓰려고 하다가는 오히려 말 순서가 바뀌어서 핵심단어가 뒤에 가는 등 의미가 불명확해질 수가 있다.