링크: 우분투 Japanese UI에 잘못된 번역이 있네요
좀 뒷북이지만... 일단 일본이나 중국에서 朝鮮語라고 칭하는 건 북조선을 가리키기 때문이 아니라 조선 시대부터 오랫동안 그렇게 불러 왔기 때문일 것이다. 중국이 오늘날도 서울의 도시 이름을 100년 전의 명칭이자 속국의 의미가 들어 있는 한성(漢成, 漢나라의 마을)이라고 칭하는 것처럼 진짜 모욕적인 용어도 있지만, 적어도 조선어는 차별적이거나 모욕적인 의미를 가진 용어는 아니다. 글쎄, 그런데 꼭 나라 이름과 언어 이름을 맞춰야 되나? 외국어에서 어떻게 쓰는 것까지 신경 쓰면서 살아야 되나?
서양 사람들이 부르는 Korea나 Korean이라는 이름 역시 올바른 명칭은 아니다. 심지어 조선 시대에 조정에서는 서양에서 온 공문에 수신자가 Korea라고 써 있다고 반송한 적도 있다고 한다. 고려는 자기들이 멸망시킨 패배자들의 이름이니까. 지금은 남북한 모두 자국어 공식 명칭은 대한민국/조선민주주의인민공화국으로 완전히 다른데도 공식 영문 명칭은 마찬가지로 Korea라고 하고 있으니 아이러니하다. 아예 통일되면 거기에 맞춰 국호를 꼬레아라고 하는 게 무난할 것 같다고 말하는 학자들도 있으니...
사람이 교류하는 단위, 같은 언어가 통용되거나 분화하는 과정이 국가와 관계가 있으니, 국가와 언어는 밀접하게 관계되어 있기는 하다. 하지만 꼭 그렇게 일대일 대응이 되지도 않는다. 페르시아라는 이름을 사용한 제국이 사라진 지가 천 년도 더 지났고 수많은 국가가 생겨나고 없어졌지만 아직도 그 지역의 공식 언어는 페르시아어이다. 쿠데타가 일어나든 분리독립을 하든 나라 이름이 바뀔 때마다 거기에 맞춰 전세계 어학 교과서의 제목을 그 나라 이름에 맞춰 줘야 하는 지는 의문이다.
2009년 3월 15일 일요일
2008년 7월 5일 토요일
우분투 런치패드 번역의 BSD 라이센스 전환의 문제
최근 우분투 런치패드는 런치패드에 들어 있는 번역문에 대해 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로 통일해야 하며 그게 아니면 시스템에서 지워야 할까? 이러한 결정은 지금까지 훌륭히 번역 작업을 해 온 런치패드의 발목을 잡게 될 것이다.
이러한 조치는 런치패드의 번역문들이 라이센스를 명확히 하지 않는다는 비판과 더불어, 번역문을 여러 프로그램 사이에 공유할 때 생기는 라이센스 문제에 대한 해결책으로 보인다. (예를 들어 GPL 프로그램의 번역문을 LGPL 프로그램에 사용하는 경우처럼.)
하지만 왜 하필 BSD이며, 왜 BSD가 아니면 시스템에서 지운다는 걸까?
첫째로 과연 GPL 소프트웨어의 번역을 BSD로 하는 게 가능한 것인가 의문을 갖게한다. 원문은 GPL 라이센스로 배포되는 프로그램의 소스코드에서 xgettext 프로그램을 통해 추출한 것이고 번역문은 파생 작업이라고밖에 할 수 없다. GPL 코드에서 추출한 템플릿을 번역한 번역문의 라이센스를 BSD로 한다는 게 가능한 것일까?
또 실제적으로 런치패드의 온라인 번역 시스템이 훌륭하긴 하지만 여전히 훨씬 더 많은 번역문들이 이 시스템 밖에서 만들어져서 런치패드 시스템으로 import되고 있다. 런치패드에 들어 있는 번역문의 대다수는 런치패드에서 시작한 번역문이 아니라 외부에서 import한 번역문을 보완한 정도이고 이렇게 GPL 번역문을 고쳐서 만들어진 결과물을 BSD 라이센스라고 할 수는 없다. 이러한 모든 번역을 지우고 런치패드 내부에서 scratch부터 시작할 것인지?
그리고 GPL은 GPL의 가치가 있다. 나는 내가 번역한 번역문이 해당 소프트웨어의 라이센스를 따르게 할 뿐, 일부러 번역문에 BSD 라이센스를 사용할 생각은 전혀 없다. GPL의 파생작업에 대한 라이센스 조항을 좋아하든 싫어하든 이 GPL 조항은 자유소프트웨어 발전에 대단히 큰 역할을 했다. 런치패드 시스템에서 사용하려고, 호환성때문에 GPL이었을 때의 장점을 버리고 BSD를 택한다는 건 받아들이기 힘들다.
몇몇 언어의 그놈/데비안/KDE 번역 팀들은 런치패드 시스템의 편리함때문에 공식적인 번역 도구로 사용하고 있다. (한국어 번역팀은 아님.) 런치패드의 이러한 조치는 이 팀들이 계속 런치패드에서 작업해야 하는지 고민하게 만들었다. 번역문 사이의 호환성이 문제라면 좀 수고를 하더라도 라이센스 호환성 문제를 처리하도록 시스템을 구현할 수도 있지 않을까? 왜 BSD로 통일해야 하며 그게 아니면 시스템에서 지워야 할까? 이러한 결정은 지금까지 훌륭히 번역 작업을 해 온 런치패드의 발목을 잡게 될 것이다.
2008년 3월 22일 토요일
그놈 2.22 gnome-font-viewer
2.22에서 특히 바뀐 점
원문은 팬그램(pangram)으로 유명한 The quick brown fox jumps over the lazy dog 문장이다. 그놈 2.20 이전에는 MS 윈도우즈가 했던 것처럼 "무궁화꽃이 피었습니다"라고 했었다. 그런데 알고 보니까 MS는 "무궁화꽃이 활짝 피었습니다"라고 쓰고 있었는데 "활짝"을 빼먹었다는 것... 약간 실망(?)을 하고 바꾸는 김에 다른 대안이 없을까 하다가 마침 "스폰지" TV 프로그램에서 팬그램에 대해 소개를 하다가 한글 자모별로 한번씩 사용한 이 팬그램 문장이 나오길래 쓰게 되었다. (무궁화꽃이 피었습니다 놀이가 일본 전래 놀이인 건 둘째치고라도... 요즘 애들은 길에서 많이 놀질 않아서 그래서인지 잘 알지도 못하는 것 같다.)
원문은 팬그램(pangram)으로 유명한 The quick brown fox jumps over the lazy dog 문장이다. 그놈 2.20 이전에는 MS 윈도우즈가 했던 것처럼 "무궁화꽃이 피었습니다"라고 했었다. 그런데 알고 보니까 MS는 "무궁화꽃이 활짝 피었습니다"라고 쓰고 있었는데 "활짝"을 빼먹었다는 것... 약간 실망(?)을 하고 바꾸는 김에 다른 대안이 없을까 하다가 마침 "스폰지" TV 프로그램에서 팬그램에 대해 소개를 하다가 한글 자모별로 한번씩 사용한 이 팬그램 문장이 나오길래 쓰게 되었다. (무궁화꽃이 피었습니다 놀이가 일본 전래 놀이인 건 둘째치고라도... 요즘 애들은 길에서 많이 놀질 않아서 그래서인지 잘 알지도 못하는 것 같다.)
2008년 1월 2일 수요일
맘대로 예언 2008 (?)
연시를 맞아 수많은 올해 예언 시리즈가 나오는 바, FL/OSS 세계에 대해 올해 벌어질 일들에 대해 써 보려고 한다. OOXML, DRM, GPLv3 적용 등등 FL/OSS 분야의 큰 뉴스거리가 될 만한 이야기는 이런 예언을 보면 될 것이고, 기술 분야에 대한 광범위한 예언은 이런 예언을 봐도 될 것이지만... 국내의 이야기나 직접 관계있고 당장 생각나는 이야기들을 모아본다.
생각나는 대로 뽑아 봤기 때문에 결론은 내리지 않고 문제만 제기하는 것으로 대신하려고 한다.
그놈이 그놈?
언제나처럼 그놈 데스크탑이 3월과 9월에 릴리스될 것이다. (너무 뻔한 얘기?) 그놈 데스크탑 L10N의 과제에서 말했던 도움말 번역 부분은 2007년에 일단 시작을 했다는 것만으로 만족해야 겠지만, 2008년은 한국어 L10N에 관해서도 더더욱 많은 문서와, 충실한 번역과, 나은 품질의 번역이 들어갈 것이다. 어느정도나 "더"일지는 참여자들이 얼마나 더 많이, 더 적극적으로 하느냐에 달려 있다. :)
새로운 글꼴?
한편 작년에 뉴스로 나왔던, 2008년 6월까지 개발할 것이라고 하는 NHN의 글꼴이 (계속 진행중이라면) 기대된다. 부디 사악하지 않은 라이선스로 자유롭게 배포/수정할 수 있기를..
지역화 개발
맞춤법검사, 사전 구축, TTS 등 손쓰기 어려운 한국어 관련 신규 개발 이슈 중에서 어느 하나라도 진전이 있지 않을까? (품사태깅 기능은 KPC에서 필요한데...)
리눅스 탑재 장난감들, 한국에 출시될까?
Asus EEE PC - 수입가격과 국내 수요가 문제.
구글 안드로이드 탑재 휴대전화 - 국내 제조업체중 하나가 만들 건 분명해 보이는데, 국내 출시는 미지수.
Nokia N800/N810 - 이건 몇년 됐고 2008년도 안 될 것 같지만 희망사항으로 일단 적어놓고...
리눅스 탑재 WiFi/VoIP 전화기들 - 이것도 희망사항.
오픈웹 vs 금결원 소송의 결과와 그 이후?
오픈웹과 금결원 소송은 작년 초에도 2007년에 어느정도 결론이 나올 거라고 생각했는데 2008년으로 넘어왔다. 합의가 안 될거라고 어느정도 예상했다. 공공기관은 소송의 피고가 되었을 때 합의해서 생긴 손해를 담당자가 책임진다고 생각하고 패소해서 생긴 손해를 조직 전체가 감수한다고 생각해서인지, 지는 입장에서는 최종 소송까지 가는 선택을 하는 게 보통이다. 금결원 소송이 결론이 나면 다른 기관을 상대로도 진행이 될까?
이제 리눅스에서 웹질을 할 만해 질까?
2000년대초에 비하면 나아졌지만, 플래시 비디오인 척 하는 activex 사이트가 (uccc, 판도라tv) 등장하질 않나, 플래시가 만능이라고 플래시로 이상하게 만들어서 문제를 일으키는 사이트가 (MBC) 등장하질 않나, 어떻게 한 건지 몰라도 리눅스용 플래시에서만 잘 죽게 만든 플래시 비디오 사이트가 (엠엔캐스트) 등장하기도 하고 시련은 끊기지 않았다. 하지만 언터처블이라고 생각했던 전자정부가 2007년 초에 표준준수 원칙을 공표했고 제한적이나마 ia32 리눅스를 지원하기 시작하는 걸 보면 새로운 시련이 닥치더라도 영원히 가는 시련은 없을 것이고 만족스러운 속도는 아니겠지만 조금씩이나마 개선될 것 같은 생각이 든다. 2008년에는 그놈 애플리케이션과 최근의 웹 서비스들과의 연동 문제를 개선하는 데도 참여하고 싶다.
GPL 위반 기업은 언제까지?
GPL 위반에 대해 무감각했던 한국 기업들은 올해에는 얼마나 솔직해 질 수 있을까? (1, 2, ...) 오래전도 아니고 2년 전에, 바로 한국에서, 꽤 유명한 리눅스 기반 휴대용 게임기인 GP2X를 만든 (주)게임파크홀딩스는 "GPL을 위반했다"는 정도가 아니라 "GPL을 이해하지 못한다"는 비아냥을 받은 적이 있다. 우여곡절 끝에 게임파크는 제대로 개발포럼에 소스코드와 SDK를 릴리스했고 GP2X는 지금도 매니아들에게 꽤 괜찮은 홈브루 게임기로 판매되고 있다. 이제 GPL 이슈를 생각도 안 하거나 고의로 무시하는 기업들은 정신 차려야 할 일이다..
"공개SW" 정책은 어떻게?
"open source"라는 말이 "free software"가 듣기에 불편해서 새로 만든 용어임에도 불구하고, 오픈소스라는 말조차도 듣기 불편했는지 한국 정부가 새로 만든 물타기용 용어, "공개SW". 공개SW 활성화 정책 중에서도 실행 과정에서 가시밭길을 걸어왔으면서 부풀리기도 힘들 정도로 성적이 초라했던 (하지만 실행되면 효과는 클 것 같은) "공공기관의 공개SW 도입"이 2008년에는 얼마나 실행될 수 있을까? 아니면 새 정부 들어서 이 쪽 정책이 방향이 완전히 바뀔 가능성은?
한편 지금까지의 정책은 너무 쉬운 방법의 단기적인 예산 집행에 급급했던 게 아쉬웠다. 아쉬웠던 제도적 개선도 이루어졌으면 한다.
북한이 눈에 뜨일까?
6자회담에서 북한의 테러지원국 해제 문제가 순탄치 못하더니 결국 2008년으로 넘어왔다. 갑자기 왠 외교 문제냐 하겠지만 FL/OSS 세계에 마치 북한이 존재하지 않는 것처럼 보이는 이유는, 다른 이유도 있지만 미국의 테러지원국 지정때문에 미국 및 미국과 관련 조약을 맺은 (한국을 비롯한) 국가에서 소프트웨어를 수출하는 게 불법이기 때문이기도 했다. 조금씩 들려오는 말들을 보면, 북쪽은 리눅스 관련 개발도 하고 배포판까지 만들어 쓰고 있다. 폐쇄성과 낮은 컴퓨터/인터넷 보급때문에 (그리고 아마도 남쪽보다도 참여의 문화가 부족할 것이므로) 녹록치 않겠지만, 제도적인 장벽이 사라지면 조금씩 업스트림에 북한이 모습을 드러낼 수 있을까?
생각나는 대로 뽑아 봤기 때문에 결론은 내리지 않고 문제만 제기하는 것으로 대신하려고 한다.
그놈이 그놈?
언제나처럼 그놈 데스크탑이 3월과 9월에 릴리스될 것이다. (너무 뻔한 얘기?) 그놈 데스크탑 L10N의 과제에서 말했던 도움말 번역 부분은 2007년에 일단 시작을 했다는 것만으로 만족해야 겠지만, 2008년은 한국어 L10N에 관해서도 더더욱 많은 문서와, 충실한 번역과, 나은 품질의 번역이 들어갈 것이다. 어느정도나 "더"일지는 참여자들이 얼마나 더 많이, 더 적극적으로 하느냐에 달려 있다. :)
새로운 글꼴?
한편 작년에 뉴스로 나왔던, 2008년 6월까지 개발할 것이라고 하는 NHN의 글꼴이 (계속 진행중이라면) 기대된다. 부디 사악하지 않은 라이선스로 자유롭게 배포/수정할 수 있기를..
지역화 개발
맞춤법검사, 사전 구축, TTS 등 손쓰기 어려운 한국어 관련 신규 개발 이슈 중에서 어느 하나라도 진전이 있지 않을까? (품사태깅 기능은 KPC에서 필요한데...)
리눅스 탑재 장난감들, 한국에 출시될까?
Asus EEE PC - 수입가격과 국내 수요가 문제.
구글 안드로이드 탑재 휴대전화 - 국내 제조업체중 하나가 만들 건 분명해 보이는데, 국내 출시는 미지수.
Nokia N800/N810 - 이건 몇년 됐고 2008년도 안 될 것 같지만 희망사항으로 일단 적어놓고...
리눅스 탑재 WiFi/VoIP 전화기들 - 이것도 희망사항.
오픈웹 vs 금결원 소송의 결과와 그 이후?
오픈웹과 금결원 소송은 작년 초에도 2007년에 어느정도 결론이 나올 거라고 생각했는데 2008년으로 넘어왔다. 합의가 안 될거라고 어느정도 예상했다. 공공기관은 소송의 피고가 되었을 때 합의해서 생긴 손해를 담당자가 책임진다고 생각하고 패소해서 생긴 손해를 조직 전체가 감수한다고 생각해서인지, 지는 입장에서는 최종 소송까지 가는 선택을 하는 게 보통이다. 금결원 소송이 결론이 나면 다른 기관을 상대로도 진행이 될까?
이제 리눅스에서 웹질을 할 만해 질까?
2000년대초에 비하면 나아졌지만, 플래시 비디오인 척 하는 activex 사이트가 (uccc, 판도라tv) 등장하질 않나, 플래시가 만능이라고 플래시로 이상하게 만들어서 문제를 일으키는 사이트가 (MBC) 등장하질 않나, 어떻게 한 건지 몰라도 리눅스용 플래시에서만 잘 죽게 만든 플래시 비디오 사이트가 (엠엔캐스트) 등장하기도 하고 시련은 끊기지 않았다. 하지만 언터처블이라고 생각했던 전자정부가 2007년 초에 표준준수 원칙을 공표했고 제한적이나마 ia32 리눅스를 지원하기 시작하는 걸 보면 새로운 시련이 닥치더라도 영원히 가는 시련은 없을 것이고 만족스러운 속도는 아니겠지만 조금씩이나마 개선될 것 같은 생각이 든다. 2008년에는 그놈 애플리케이션과 최근의 웹 서비스들과의 연동 문제를 개선하는 데도 참여하고 싶다.
GPL 위반 기업은 언제까지?
GPL 위반에 대해 무감각했던 한국 기업들은 올해에는 얼마나 솔직해 질 수 있을까? (1, 2, ...) 오래전도 아니고 2년 전에, 바로 한국에서, 꽤 유명한 리눅스 기반 휴대용 게임기인 GP2X를 만든 (주)게임파크홀딩스는 "GPL을 위반했다"는 정도가 아니라 "GPL을 이해하지 못한다"는 비아냥을 받은 적이 있다. 우여곡절 끝에 게임파크는 제대로 개발포럼에 소스코드와 SDK를 릴리스했고 GP2X는 지금도 매니아들에게 꽤 괜찮은 홈브루 게임기로 판매되고 있다. 이제 GPL 이슈를 생각도 안 하거나 고의로 무시하는 기업들은 정신 차려야 할 일이다..
"공개SW" 정책은 어떻게?
"open source"라는 말이 "free software"가 듣기에 불편해서 새로 만든 용어임에도 불구하고, 오픈소스라는 말조차도 듣기 불편했는지 한국 정부가 새로 만든 물타기용 용어, "공개SW". 공개SW 활성화 정책 중에서도 실행 과정에서 가시밭길을 걸어왔으면서 부풀리기도 힘들 정도로 성적이 초라했던 (하지만 실행되면 효과는 클 것 같은) "공공기관의 공개SW 도입"이 2008년에는 얼마나 실행될 수 있을까? 아니면 새 정부 들어서 이 쪽 정책이 방향이 완전히 바뀔 가능성은?
한편 지금까지의 정책은 너무 쉬운 방법의 단기적인 예산 집행에 급급했던 게 아쉬웠다. 아쉬웠던 제도적 개선도 이루어졌으면 한다.
북한이 눈에 뜨일까?
6자회담에서 북한의 테러지원국 해제 문제가 순탄치 못하더니 결국 2008년으로 넘어왔다. 갑자기 왠 외교 문제냐 하겠지만 FL/OSS 세계에 마치 북한이 존재하지 않는 것처럼 보이는 이유는, 다른 이유도 있지만 미국의 테러지원국 지정때문에 미국 및 미국과 관련 조약을 맺은 (한국을 비롯한) 국가에서 소프트웨어를 수출하는 게 불법이기 때문이기도 했다. 조금씩 들려오는 말들을 보면, 북쪽은 리눅스 관련 개발도 하고 배포판까지 만들어 쓰고 있다. 폐쇄성과 낮은 컴퓨터/인터넷 보급때문에 (그리고 아마도 남쪽보다도 참여의 문화가 부족할 것이므로) 녹록치 않겠지만, 제도적인 장벽이 사라지면 조금씩 업스트림에 북한이 모습을 드러낼 수 있을까?
2007년 12월 30일 일요일
브랜드의 번역
예전에 회사 팀장과의 에피소드:
썬의 번역 가이드
썬마이크로시스템에서 만든 StarSuite style guide에 보면 이런 말이 들어 있다.
Branding
"언어와 문화가 다른 지역에 진출할 때 기존 브랜드를 어떠한 형태로 사용할 것인가?", 이 문제는 어제 오늘의 문제는 아니다. 수십년동안 기업들의 글로벌화가 진행되면서 회사는 저마다 경우에 따라 다른 전략을 취해 왔고 뭐가 정답이라고는 쉽게 말할 수 없다. 보통 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"라는 이름만은 영문 표기를 하는 브랜딩을 고집하는지 이해하기 힘들다. (번역자 맘대로 건드리기도 힘들게 만들어 놨다.)
팀장모씨: (팀원들에게) 리포트 쓸 때는 말이지 이건 저렇게 하고 저건 저렇게 하고.. 그리고 전문용어 영어 단어같은 거 그냥 영어로 쓰라고. 다 알아들으니까 말이야.
창우: (속으로 투덜투덜...) 얼마나 다 영어로 쓰나요?
팀장모씨: 전부 다. 여기 단어 몇개 영어로 나온다고 문제 될거 없잖아? 오히려 엔지니어들한텐 그게 읽기 좋다고.
창우: 그거보다 훨씬 많아요. encoding, decoding, source code, compile, build, bug, editor, debugger, typing, .... 한글은 몇 개 안 남네요. (다 고쳐서 한 줄에 영어단어가 너덧개씩 있는 보고서를 보여준다) 자 이렇게 쓰면 가독성이 좋을까요?
팀장모씨: ... (독해에 어려움을 겪는 모씨...)
썬의 번역 가이드
썬마이크로시스템에서 만든 StarSuite style guide에 보면 이런 말이 들어 있다.
1.4.2한국어로 번역하지 않는 용어들 (Do not translate)이 부분은 내가 오픈오피스 번역 중에서 가장 못 마땅하게 생각하는 부분이다. 번역 가이드의 다른 부분은 몰라도 위 사항은 절대 따르지 않고 번역이나 음역하기를 권장한다. 특히 Gnome은 영문 그대로 쓰지 말고 "그놈"이라고 표기하기를...
1. 고유 명사나 소프트웨어, 운영 체제 등의 고유 이름
MySQL (ODBC) -
PostgreSQL
MySQL (JDBC)
Mozilla
Adabas D
Microsoft Outlook
Oracle JDBC
Microsoft Windows
JDBC
LDAP
ODBC
Evolution
XStorable
...
Branding
"언어와 문화가 다른 지역에 진출할 때 기존 브랜드를 어떠한 형태로 사용할 것인가?", 이 문제는 어제 오늘의 문제는 아니다. 수십년동안 기업들의 글로벌화가 진행되면서 회사는 저마다 경우에 따라 다른 전략을 취해 왔고 뭐가 정답이라고는 쉽게 말할 수 없다. 보통 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"라는 이름만은 영문 표기를 하는 브랜딩을 고집하는지 이해하기 힘들다. (번역자 맘대로 건드리기도 힘들게 만들어 놨다.)
2007년 12월 20일 목요일
번역 메세지에서 남용되고 있는 말
기반 (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 파일의 단어들에 대해 통계를 내는 것도 의미가 있어 보이는데.. 나를 포함해 누가 한 번역도 이 빈약한 번역 어휘의 문제에서 자유롭지 못할 것이다.
해결 방법은 평소에 폭넓은 독서와 글쓰기를... (논술 시험?)
위하여 (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 파일의 단어들에 대해 통계를 내는 것도 의미가 있어 보이는데.. 나를 포함해 누가 한 번역도 이 빈약한 번역 어휘의 문제에서 자유롭지 못할 것이다.
해결 방법은 평소에 폭넓은 독서와 글쓰기를... (논술 시험?)
2007년 11월 10일 토요일
OLPC 배포국가
OLPC 배포국가: 브라질(포르투갈어),멕시코(스페인어),우루과이(스페인어),페루(스페인어),팔레스타인(아랍어),리비아(아랍어),나이지리아(아프리칸/영어),에티오피아(암하라),르완다(르완다어/프랑스어),타이(태국어)..
OLPC를 쓰고 싶은 개도국 어린이는 영어부터 배워야?
괜한 네거티브가 아니라.. OLPC 하드웨어는 양산을 시작했지만, 소프트웨어 완성도는 아직 "글쎄"다. 국제화나 번역쪽은 특히나 진행이 느려서 사실상 영어 못 쓰면 사용이 어렵다. 네그로폰테가 방한해서 잠깐 했던 말처럼 북한에 OLPC를 보내는 사업을 하게 된다면, 한국어 XO 번역 커뮤니티를 만들 필요도 있을 것이다.
(업데이트) 지금 OLPC 한국어 개발과 관련되어 참여하고 있는 "것처럼 보이는" 사람들은, 방향이 현실성 없는 정치적인 활동이나 OLPC의 기본 방향과 다르게 별개 사업을 진행하려고 하고 있다. 이 사람(들)이 지금 활동하고 있는 것 같지도 않고 이대로 성공할 거라고 생각하지도 않지만, 혹시라도 이러한 방향으로 협조하지는 말기를..
OLPC를 쓰고 싶은 개도국 어린이는 영어부터 배워야?
괜한 네거티브가 아니라.. OLPC 하드웨어는 양산을 시작했지만, 소프트웨어 완성도는 아직 "글쎄"다. 국제화나 번역쪽은 특히나 진행이 느려서 사실상 영어 못 쓰면 사용이 어렵다. 네그로폰테가 방한해서 잠깐 했던 말처럼 북한에 OLPC를 보내는 사업을 하게 된다면, 한국어 XO 번역 커뮤니티를 만들 필요도 있을 것이다.
(업데이트) 지금 OLPC 한국어 개발과 관련되어 참여하고 있는 "것처럼 보이는" 사람들은, 방향이 현실성 없는 정치적인 활동이나 OLPC의 기본 방향과 다르게 별개 사업을 진행하려고 하고 있다. 이 사람(들)이 지금 활동하고 있는 것 같지도 않고 이대로 성공할 거라고 생각하지도 않지만, 혹시라도 이러한 방향으로 협조하지는 말기를..
2007년 4월 24일 화요일
pootle의 가장 큰 문제는
온라인 번역 시스템으로 pootle을 심각하게 고려해 보았으나 결론은...
못 쓰겠다 (적어도 지금은)
그리 나쁘다라는 게 아니다. pootle은 매우 간결하고, PO 파일을 백엔드로 사용해서 그런지 PO 파일 번역에 좋고 훌륭하게 처리한다. 사용자별로 권한레벨을 분리해 놓았고, translation-toolkit에 잘 구성되어 있는 파이썬 모듈을 이용해 메세지별로 온갖 체크를 온라인에서 할 수 있다. (여기에 KPC를 붙이면 금상첨화) 이정도만 되도 일단 시작하는 데 문제가 될 일이 없다. launchpad가 우분투 스케줄대로 움직이고 closed source이기 때문에 직접 컨트롤할 수 있는 웹 번역 시스템은 pootle이 유일하다. 하지만, 결정적인 문제는,
기록이 안 남는다
아무리 후지고 완성도가 시스템이라고 해도 개선의 여지가 있으면 그래도 일단 돌리고 볼 텐데, 당장 반달리즘으로 작업물이 날아갈 수 있다는 점은 참 어려운 이야기이다. 백엔드가 PO 파일이기 때문에 PO 파일을 그냥 고쳐버린다. RDBMS를 쓸 필요까지야 없겠지만 백엔드의 한계때문에 변경 사항의 기록을 남기도록 고치는 것도 매우 힘들다.
못 쓰겠다 (적어도 지금은)
그리 나쁘다라는 게 아니다. pootle은 매우 간결하고, PO 파일을 백엔드로 사용해서 그런지 PO 파일 번역에 좋고 훌륭하게 처리한다. 사용자별로 권한레벨을 분리해 놓았고, translation-toolkit에 잘 구성되어 있는 파이썬 모듈을 이용해 메세지별로 온갖 체크를 온라인에서 할 수 있다. (여기에 KPC를 붙이면 금상첨화) 이정도만 되도 일단 시작하는 데 문제가 될 일이 없다. launchpad가 우분투 스케줄대로 움직이고 closed source이기 때문에 직접 컨트롤할 수 있는 웹 번역 시스템은 pootle이 유일하다. 하지만, 결정적인 문제는,
기록이 안 남는다
아무리 후지고 완성도가 시스템이라고 해도 개선의 여지가 있으면 그래도 일단 돌리고 볼 텐데, 당장 반달리즘으로 작업물이 날아갈 수 있다는 점은 참 어려운 이야기이다. 백엔드가 PO 파일이기 때문에 PO 파일을 그냥 고쳐버린다. RDBMS를 쓸 필요까지야 없겠지만 백엔드의 한계때문에 변경 사항의 기록을 남기도록 고치는 것도 매우 힘들다.
2007년 4월 7일 토요일
어색한 번역 습관
어색한 메세지 번역을 피하는 팁 몇가지에 이어...서 쓰는 건 아니고 관련 있는 몇 가지 메모:
한자를 붙여 신조어 만들기: 비(非)~, ~자(者), ~기(機)
우리가 일상생활이나 컴퓨터에서 쓰는 단어 중에 분명히 비~, ~자, ~기라는 단어가 있고, 많이 쓰는 건 사실이다. nonpreemptive/비선점, editor/편집기, constructor/생성자, manager/관리자 등등등.. 이러한 단어들이 만들어지게 된 유래가 (상당부분 중국과 일본에서 만든 한자 차용) 옳은지 그른지는 재쳐두고라도, 번역할 때 이러한 단어를 임의로 만드는 일은 정말 바람직하지 않다. non-free - 비자유?, tokenizer - 구문분석자?, monitor - 감시기? 일단 보기에 어색하다.
이미 익숙하게 쓰는 단어가 아니라면 "비~" prefix가 한글로 붙었을 때 그게 부정의 의미인지 파악하기 어렵고, "~기"나 "~자"를 소프트웨어에 사용하는 것도 우리말에 자연스럽지 않다.
살아있는 소프트웨어
흔히 이야기하는 "수동태를 쓰지 말라"는 번역 팁과 연관있는 이야기로, 우리말에선 생명체가 아닌 존재에 동사를 잘 붙이지 않는다. 무생물은 주체적이지 않다. (철학적인 문제?)
예를 들어 프로그램의 메세지에서 "I"와 "YOU"를 사용하는 말이 나올 때 상당히 고민하지 않으면 자연스럽게 번역하기 힘들다. 흔히 영문 메세지 원문에서는 소프트웨어가 생명을 가지고 사용자와 대화하는 것처럼 I를 주어로, you를 목적어로 사용하는 경우가 있는데 "나는", "당신은"이라고 번역하기 시작하면 번역 결과물이 상당히 곤란해 진다.
마땅히 무슨 말을 써야 한다는 정답은 없고, 아예 I나 you를 번역문에서 언급하지 않고 충분히 뜻이 통하도록 적당히 번역하는 게 가장 좋은 것 같다.
한자를 붙여 신조어 만들기: 비(非)~, ~자(者), ~기(機)
우리가 일상생활이나 컴퓨터에서 쓰는 단어 중에 분명히 비~, ~자, ~기라는 단어가 있고, 많이 쓰는 건 사실이다. nonpreemptive/비선점, editor/편집기, constructor/생성자, manager/관리자 등등등.. 이러한 단어들이 만들어지게 된 유래가 (상당부분 중국과 일본에서 만든 한자 차용) 옳은지 그른지는 재쳐두고라도, 번역할 때 이러한 단어를 임의로 만드는 일은 정말 바람직하지 않다. non-free - 비자유?, tokenizer - 구문분석자?, monitor - 감시기? 일단 보기에 어색하다.
이미 익숙하게 쓰는 단어가 아니라면 "비~" prefix가 한글로 붙었을 때 그게 부정의 의미인지 파악하기 어렵고, "~기"나 "~자"를 소프트웨어에 사용하는 것도 우리말에 자연스럽지 않다.
살아있는 소프트웨어
흔히 이야기하는 "수동태를 쓰지 말라"는 번역 팁과 연관있는 이야기로, 우리말에선 생명체가 아닌 존재에 동사를 잘 붙이지 않는다. 무생물은 주체적이지 않다. (철학적인 문제?)
예를 들어 프로그램의 메세지에서 "I"와 "YOU"를 사용하는 말이 나올 때 상당히 고민하지 않으면 자연스럽게 번역하기 힘들다. 흔히 영문 메세지 원문에서는 소프트웨어가 생명을 가지고 사용자와 대화하는 것처럼 I를 주어로, you를 목적어로 사용하는 경우가 있는데 "나는", "당신은"이라고 번역하기 시작하면 번역 결과물이 상당히 곤란해 진다.
마땅히 무슨 말을 써야 한다는 정답은 없고, 아예 I나 you를 번역문에서 언급하지 않고 충분히 뜻이 통하도록 적당히 번역하는 게 가장 좋은 것 같다.
2007년 3월 24일 토요일
구글 blogger.com - 한국 포털 블로그와의 잘 보이지 않는 장벽
뭐랄까. 구글은 디자인이나 사용성 등 기발한 상상력보다는 노동력이 투입되는 부분에 약한 면이 있다. 다른 글 읽으려고 blogger.com에 들어갔다가 오른쪽 위에서 자꾸 만들 수 있다고 유혹을 하길래 만들어 봤더니...
일단 뭔가 알 수 없는 어색함을 느낀다. 기계적인 번역만을 한 상태이고, 한국말로 사용성 테스트가 제대로 되지 않은 듯 하다.
이렇게 어색한 번역도 그렇고.. 확실히 테스트가 안 된 것처럼 정렬도 영문 순서로 되어 있다.
나도 한국 포털의 인위적 조작에 대해 상당히 반감을 갖고 있지만, 이런 건 사람이 노동력을 좀 투입해 줘야.. -_-
(일단 한국말로 보면 어색하다는 거 빼고는.. 온갖 기능들은 상당히 뛰어나다.)
일단 뭔가 알 수 없는 어색함을 느낀다. 기계적인 번역만을 한 상태이고, 한국말로 사용성 테스트가 제대로 되지 않은 듯 하다.
이렇게 어색한 번역도 그렇고.. 확실히 테스트가 안 된 것처럼 정렬도 영문 순서로 되어 있다.
나도 한국 포털의 인위적 조작에 대해 상당히 반감을 갖고 있지만, 이런 건 사람이 노동력을 좀 투입해 줘야.. -_-
(일단 한국말로 보면 어색하다는 거 빼고는.. 온갖 기능들은 상당히 뛰어나다.)
2007년 3월 22일 목요일
배포판 중심 메세지 번역의 폐해 - 커뮤니케이션 부재
과거에도 그랬듯이, 배포판 중심의 메세지 번역은 보통 그 배포판 안에서만 사용되고 그 안에서 수명을 다한다.
우분투의 런치패드/로제타는 온라인 메세지 번역 시스템으로 기술적으로는 내가 생각했던 이상적인 모습이지만, 배포판 중심의 번역 운영은 (한국이든 세계 어디든) 커뮤니케이션의 문제를 가질 수밖에 없다. 예전에 런치패드/로제타에 의해 한국어 번역이 시작되었을 때 내가 우려했던 것처럼 업스트림과 따로 노는 현상이 벌어지곤 한다.
간단히 예를 들어 우분투 feisty의 한국어 번역 중에서 KDE 관련 프로그램은 로제타에서 많은 부분이 번역되어 있다. 많은 부분이 비슷한 모습을 보이지만, 꽤 많이 번역된 일부분을 보면,
그럼 KDE upstream의 한국어 통계를 들어가서 이 부분이 업스트림에 어떻게 되어 있는 지 확인해 보자. 위에 나온 kdebase를 비교해 보면 다음과 같다. 거의 반영이 되어 있지 않다.
그럼 보너스로 또 한 가지 비교해 보자. 한소프트리눅스는 어떨까? 한소프트리눅스 오픈 프로젝트에서 kde-i18n 패키지의 src.rpm 파일을 받아서 확인해 보았다.
"위와 같은 꼴"을 보고 절대 잘 한다는 소리는 절대 못하겠지만, 어제 오늘의 일이 아니고 이제는 적어도 이해는 할 수 있다. FOSDEM 2007의 비디오 중에서 리눅스 커널에 관한 세션을 보면 이런 얘기가 있다 -- "임베디드 분야의 리눅스 커널의 발전이 더딘 이유는 피드백이 없기 때문인데, 칩 메이커를 제외하고 완제품을 만드는 제조업체들은 제품의 개발기간도 짧은 데다가 스펙이 한정되어 있고 소프트웨어 업데이트도 거의 없기 때문에 피드백의 현실적인 필요가 적다". 배포판 업체들도 마찬가지이다. 번역에 관한한 충분한 맨파워를 동원할 수 있다면 (우분투와 한소프트리눅스는 그 방법을 다르게 취한 것 같지만) 업스트림 피드백으로 얻을 건 별로 많지 않다. 런치패드/로제타의 자발적인 참여자들도 자기들의 번역 결과물이 자기가 사용하는 OS에 반영되는 것만으로도 상당히 만족하고, 또 다른 업스트림에 반영하는 건 런치패드/로제타보다 진입장벽이 높기 때문에 부담스러워하는 것도 같다.
이 상황을 어떻게 해결해야 하나. 업스트림에 번역을 반영하는 장벽을 낮추는 게 한 가지 방법이지만, 어떻게 쉽게 컨트롤할 수 없는 부분이다. 적어도 내가 상당부분을 컨트롤하고 있는 그놈 / 데비안 번역은 가능할 것도 같은데, 앞으로 생각할 부분이다..
우분투의 런치패드/로제타는 온라인 메세지 번역 시스템으로 기술적으로는 내가 생각했던 이상적인 모습이지만, 배포판 중심의 번역 운영은 (한국이든 세계 어디든) 커뮤니케이션의 문제를 가질 수밖에 없다. 예전에 런치패드/로제타에 의해 한국어 번역이 시작되었을 때 내가 우려했던 것처럼 업스트림과 따로 노는 현상이 벌어지곤 한다.
간단히 예를 들어 우분투 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어라? -_- 완벽한데 대체 무슨 일이 벌어진 것일까? 과연 누가 이걸 번역했는지 알아보기 위해 PO 파일의 Last-Translator: 엔트리를 찾아보았다.
번역된 메시지 70개.
번역된 메시지 47개.
번역된 메시지 68개.
번역된 메시지 121개.
번역된 메시지 21개.
번역된 메시지 8개.
번역된 메시지 67개.
번역된 메시지 34개.
번역된 메시지 180개.
...
zeus:~/tmp/kdebase/kde-i18n-ko-3.5.6/messages/kdebase$ grep Last-Translator: kcm*po다름 아닌 한소프트리눅스 측에서 자체 번역한 결과물이다. (위의 결과로 알 수 있는 사실, 번역자는 루트 계정으로 KBabel을 이용해 번역한다.) 이것이 한소프트리눅스 광고에 등장하곤 하는 "전문 번역팀을 통해 자연스럽지 못했던 한글 번역부분을 말끔히 개선하였습니다"의 실체인가?
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"
...
"위와 같은 꼴"을 보고 절대 잘 한다는 소리는 절대 못하겠지만, 어제 오늘의 일이 아니고 이제는 적어도 이해는 할 수 있다. FOSDEM 2007의 비디오 중에서 리눅스 커널에 관한 세션을 보면 이런 얘기가 있다 -- "임베디드 분야의 리눅스 커널의 발전이 더딘 이유는 피드백이 없기 때문인데, 칩 메이커를 제외하고 완제품을 만드는 제조업체들은 제품의 개발기간도 짧은 데다가 스펙이 한정되어 있고 소프트웨어 업데이트도 거의 없기 때문에 피드백의 현실적인 필요가 적다". 배포판 업체들도 마찬가지이다. 번역에 관한한 충분한 맨파워를 동원할 수 있다면 (우분투와 한소프트리눅스는 그 방법을 다르게 취한 것 같지만) 업스트림 피드백으로 얻을 건 별로 많지 않다. 런치패드/로제타의 자발적인 참여자들도 자기들의 번역 결과물이 자기가 사용하는 OS에 반영되는 것만으로도 상당히 만족하고, 또 다른 업스트림에 반영하는 건 런치패드/로제타보다 진입장벽이 높기 때문에 부담스러워하는 것도 같다.
이 상황을 어떻게 해결해야 하나. 업스트림에 번역을 반영하는 장벽을 낮추는 게 한 가지 방법이지만, 어떻게 쉽게 컨트롤할 수 없는 부분이다. 적어도 내가 상당부분을 컨트롤하고 있는 그놈 / 데비안 번역은 가능할 것도 같은데, 앞으로 생각할 부분이다..
2007년 3월 21일 수요일
메세지 번역에서 흔히 발생하는 문제와 해결
보안용 장비를 만들 시절에, 회사에서 번역 업체를 많이 이용했었다. 이 번역업체는 세계 곳곳의 각 언어권마다 지사를 두고 있는데 각 지사마다 네티이브 번역자가 있는 동시에 그 지역의 번역 의뢰자를 상대로 영업을 한다. 번역 의뢰가 들어오면 원문을 각 세계 지사에 보내서 네이티브들이 번역을 하게 만든 다음 번역한 결과물을 모아서 의뢰자에게 돌려준다. 이런 식으로 동작하는 번역 전문 회사가 꽤 많이 있고, 이 방식으로 꽤 괜찮은 품질의 번역을 빠르게 만들어 낼 수 있다. 보통 제품을 릴리스할 때마다 백여개 내외의 메세지가 독일어, 프랑스어, 이탈리아어, 스페인어, 일본어로 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% 없애기는 쉽지 않다. 실제로 마이크로소프트가 공개한 마이크로소프트가 릴리스하는 번역문도 하나하나 살펴보면 어색한 번역문도 있고 오역이라고 생각되는 번역문도 꽤 있으며 시간이 지나면서 다른 용어를 사용하는 부분도 꽤 보인다. 하지만 그 번역문 중에서도 자주 사용하는 마이크로소프트의 대부분의 번역문은 아주 매끄러운데, 이는 다름 아니라 엄청난 사용성 테스트의 결과물이다. 역시 피드백을 많이 받아서 계속해서 다듬어 나가면 잘 번역했다는 소리를 들을 수 있다는 얘기이다. 하지만 역시 보안 장비를 만들 때나 그놈 메세지를 번역할 때나 자기 스스로 깨닫고 고치는 것 외에 외부에서 피드백을 받기는 쉽지 않은 일이다. 그놈 메세지는 특히, 심심풀이 작업때문에 일부러 프로그램 테스트를 심각하게 할 수는 없는 노릇이다.
그래서 앞으로 그놈 및 내가 참여하는 번역은 번역자들의 (특히 류모씨의) 부담을 줄이면서도 좀 더 많은 참여와 피드백을 받고 번역을 다듬을 수 있는 방법을 찾아 보려고 한다. 어떤 게 될 지는 나도 아직 잘 모르겠으므로 다음 시간에...
그 번역 업체는 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% 없애기는 쉽지 않다. 실제로 마이크로소프트가 공개한 마이크로소프트가 릴리스하는 번역문도 하나하나 살펴보면 어색한 번역문도 있고 오역이라고 생각되는 번역문도 꽤 있으며 시간이 지나면서 다른 용어를 사용하는 부분도 꽤 보인다. 하지만 그 번역문 중에서도 자주 사용하는 마이크로소프트의 대부분의 번역문은 아주 매끄러운데, 이는 다름 아니라 엄청난 사용성 테스트의 결과물이다. 역시 피드백을 많이 받아서 계속해서 다듬어 나가면 잘 번역했다는 소리를 들을 수 있다는 얘기이다. 하지만 역시 보안 장비를 만들 때나 그놈 메세지를 번역할 때나 자기 스스로 깨닫고 고치는 것 외에 외부에서 피드백을 받기는 쉽지 않은 일이다. 그놈 메세지는 특히, 심심풀이 작업때문에 일부러 프로그램 테스트를 심각하게 할 수는 없는 노릇이다.
그래서 앞으로 그놈 및 내가 참여하는 번역은 번역자들의 (특히 류모씨의) 부담을 줄이면서도 좀 더 많은 참여와 피드백을 받고 번역을 다듬을 수 있는 방법을 찾아 보려고 한다. 어떤 게 될 지는 나도 아직 잘 모르겠으므로 다음 시간에...
2007년 2월 28일 수요일
Seahorse 번역
그놈 데스크탑 2.18에 포함될 프로그램으로 가장 작업량이 많았던 Seahorse 번역을 마쳤다. 700여개..
위에서도 "Full"과 같이 번역이 안 되어 나오는데, 프로그램 문제로 번역 안 되는 부분이 아주 많은 게 문제이다. 릴리스된 뒤에도 여기저기 번역 안 되는 버그를 잘 찾아봐야 할 듯 하다. 애플릿은 아예 전체가 번역이 안 되어 나온다. 다음은 애플릿을 이용해 클립보드의 내용에 서명을 붙인 것.
문제는 키링에 키가 많을 때 GPG가 시스템 대부분의 로드를 먹으면서 엄청나게 느려지는 현상이 있다. 내 키링이 기껏해야 300개 내외인데 이런 현상이 벌어진다. (키링이 이보다 더 큰 키사이닝파티 매니아가 과연 seahorse를 사용할 지는 모르겠지만.) 상당히 featureful한 건 맞고 도움말 문서도 훌륭하지만 안정성은 좀 떨어져 보인다...
번역하면서 재미있는 기능을 발견했는데, DNS-SD(애플 랑데뷰/봉쥬르)를 이용해 네트워크에 자기 pubkey 키링을 export하고, 네트워크 안에서 seahorse를 사용하고 있는 사람들끼리 pubkey를 교환할 수 있다! 실험은 못 하지만 사무실/연구실같은 환경에서 사용했을 때 상당히 괜찮은 기능으로 보인다.
위에서도 "Full"과 같이 번역이 안 되어 나오는데, 프로그램 문제로 번역 안 되는 부분이 아주 많은 게 문제이다. 릴리스된 뒤에도 여기저기 번역 안 되는 버그를 잘 찾아봐야 할 듯 하다. 애플릿은 아예 전체가 번역이 안 되어 나온다. 다음은 애플릿을 이용해 클립보드의 내용에 서명을 붙인 것.
문제는 키링에 키가 많을 때 GPG가 시스템 대부분의 로드를 먹으면서 엄청나게 느려지는 현상이 있다. 내 키링이 기껏해야 300개 내외인데 이런 현상이 벌어진다. (키링이 이보다 더 큰 키사이닝파티 매니아가 과연 seahorse를 사용할 지는 모르겠지만.) 상당히 featureful한 건 맞고 도움말 문서도 훌륭하지만 안정성은 좀 떨어져 보인다...
번역하면서 재미있는 기능을 발견했는데, DNS-SD(애플 랑데뷰/봉쥬르)를 이용해 네트워크에 자기 pubkey 키링을 export하고, 네트워크 안에서 seahorse를 사용하고 있는 사람들끼리 pubkey를 교환할 수 있다! 실험은 못 하지만 사무실/연구실같은 환경에서 사용했을 때 상당히 괜찮은 기능으로 보인다.
2007년 2월 25일 일요일
그놈 데스크탑 L10N의 과제
한번 그놈 데스크탑의 한국어 지원 상태와 과제에 대해 정리해 보았다.
번역
메세지 번역 업데이트, 다듬기 - 그놈 데스크탑의 한국어 메세지 번역은 그놈 역사와 함꼐 버전이 0.x일 때부터 시작되어 지금 거의 10년 가까이 계속되었다. 요즘에는 릴리스 노트에서도 "supported language"라고 선전을 하는데, 애초부터 "지원하는" 언어였다. 오랜시간 작업하면서 나름대로의 일관성도 생겼고, KPC같은 툴의 도움도 컸다. 메세지 번역은 완성도가 꽤 높다고 자부하지만.. 아무래도 번역자가 직접 사용하지 않는 프로그램의 번역 완성도는 상대적으로 높지 않다. 예를 들어 gnome-games에 있는 번역들은 번역하기도 힘들게 만들어 놓은 부분도 있고, 게임을 이해하지 못한 부분이 많다. 또 일반적인 데스크탑 사용자가 사용하지 않는 sabayon 따위는 제대로 돌아가기는 하는지 알 길이 없다. 다양하게 그놈을 활용하는 사람들의 좀 더 많은 피드백과 참여가 필요하다. 또 FDO 등 그놈 번역 통계에 잡히지 않지만 데스크탑에서 사용하는 메세지도 번역할 필요가 있다.
도움말 번역 - 도움말 번역은 썬이 상당히 해 주었는데, 썬의 작업은 JDS/Solaris/OpenSolaris를 타겟으로 하다 보니 그놈 릴리스와 스케줄이 맞지 않고, 숫자로 봐도 매우 저조하고. 메세지 번역과 맞지 않는 면이 있다. 지금 번역된 숫자가 0에 가깝지만 PO 파일 기반으로 바뀌면서 기존 썬의 XML 번역이 PO로 변환되지 않은 상태로 남아 있어서 정확한 숫자는 아니다... 아마 지금부터 준비하면 올해 9월 릴리스에는 어느정도 할 수 있지 않을까?
웹사이트 번역 - 이제 그놈 웹사이트도 다음번 릴리스 타겟으로 Plone CMS를 이용하도록 개편될 예정이다. 개편의 목표 하나가 다국어 사이트이니까 웹사이트에 있는 내용의 번역도 필요해졌다.
그놈 관련 개발
입력기 통합 - 이상한 방향으로 논의만 있던 상태이지만, 입력기 프레임워크를 데스크탑에 통합하는 데 참여한다. 방향조차 애매한 상태라서 갈길이 멀지만, 지금보다 더 그놈 환경에 잘 통합되도록 만들 필요가 있다. 예를 들어서 알림 영역에 입력기 UI가 들어간다든지, 별도 설정 파일에 설정사항을 저장한다든지, 언어별로 다른 프로그램이 동작한다든지 하는 건 범용성을 위한 것이지, 그놈 데스크탑에 잘 통합된 형태는 아니다.
접근성 관련 작업 - 현재 Orca나 GOK같은 접근성 관련 소프트웨어는 메세지 번역만 됐을 뿐이지 실제 한글 입/출력 환경에서 동작할 수는 없다. (dasher는 첫가끝 코드 덕분에 꽤 쓸만하게 동작한다.) orca같은 경우에는 TTS 소프트웨어가 필요하고 (아래에서 다시), GOK는 조금 동작하겠지만 키보드 입력이 불편한 사람들이 한글 입력을 어떻게 할 지에 대해 다른 non-free 소프트웨어도 참고하는 등 연구가 좀 필요하다. 당장 수요가 거의 없다고 생각되거나 최소한 알려져 있지 않기 때문에 무턱대고 노력을 투자하기도 힘든 부분이다. (혹시 자신이나 주변 분들이 그놈의 접근성 관련 기능들을 이용하고 있거나 이용할 필요가 있다면 알려 주시길..)
버그, 버그, ... - 끊임없는 버그 찾기 및 고치기.
일반 한국어 관련 개발
쓸만한 한글 정자체 글꼴 - 바람직한 라이센스에, 품질이 높고, 모든 한국어 유니코드 영역을 커버하면서, 계속 메인테인되는 정자체 글꼴이 있었으면 좋겠다. (현존하는 글꼴들이 과연 여기에서 뭐가 부족할까?)
철자 검사 프로그램 - kts 등의 문제를 해결하고 쓸만한 상태로 끌어올리거나 새로 만들어도 좋다. 다른 프로그램과 연동해서 사용할 수 있도록 gnome-spell, Enchant 등 다른 소프트웨어에 통합하는 작업도 필요하다.
Text To Speech - Orca 따위에 필요하다.
기타 개발
하드웨어 지원 - 한국 컴퓨터 시장에서 볼 수 있는 TV 수신 카드, 화상 카메라, 디지탈 카메라 등의 하드웨어들이 리눅스에서 지원되도록 한다. 직접적인 L10N이라고 할 수는 없지만, 그 하드웨어를 이용하는 그놈 프로그램들을 한국 사용자가 쉽게 사용할 수 있게 만드는 일이 된다. (Ekiga, gnome-volume-manager 등) 한국 시장의 노트북 컴퓨터들의 전원 관리 문제들을 잘 보고하고 도움을 주는 일도 그놈의 전원 관리 기능 향상에 도움이 된다.
커뮤니티
이제 공식 웹사이트에 한국어 번역이 들어간다면 로컬 사이트가 해야 할 일은? 사용자 사이의 의사소통이 가장 크다. 또 하나의 언어 장벽이 될 수밖에 없는 버그질라 등의 다리 역할을 하면서 사용자 의견을 받아들이고 로컬 사용자 모임으로 역할을 해야 한다. 최근 gnome.or.kr의 개편이 있었으니 잘 되리라 믿는다.
번역
메세지 번역 업데이트, 다듬기 - 그놈 데스크탑의 한국어 메세지 번역은 그놈 역사와 함꼐 버전이 0.x일 때부터 시작되어 지금 거의 10년 가까이 계속되었다. 요즘에는 릴리스 노트에서도 "supported language"라고 선전을 하는데, 애초부터 "지원하는" 언어였다. 오랜시간 작업하면서 나름대로의 일관성도 생겼고, KPC같은 툴의 도움도 컸다. 메세지 번역은 완성도가 꽤 높다고 자부하지만.. 아무래도 번역자가 직접 사용하지 않는 프로그램의 번역 완성도는 상대적으로 높지 않다. 예를 들어 gnome-games에 있는 번역들은 번역하기도 힘들게 만들어 놓은 부분도 있고, 게임을 이해하지 못한 부분이 많다. 또 일반적인 데스크탑 사용자가 사용하지 않는 sabayon 따위는 제대로 돌아가기는 하는지 알 길이 없다. 다양하게 그놈을 활용하는 사람들의 좀 더 많은 피드백과 참여가 필요하다. 또 FDO 등 그놈 번역 통계에 잡히지 않지만 데스크탑에서 사용하는 메세지도 번역할 필요가 있다.
도움말 번역 - 도움말 번역은 썬이 상당히 해 주었는데, 썬의 작업은 JDS/Solaris/OpenSolaris를 타겟으로 하다 보니 그놈 릴리스와 스케줄이 맞지 않고, 숫자로 봐도 매우 저조하고. 메세지 번역과 맞지 않는 면이 있다. 지금 번역된 숫자가 0에 가깝지만 PO 파일 기반으로 바뀌면서 기존 썬의 XML 번역이 PO로 변환되지 않은 상태로 남아 있어서 정확한 숫자는 아니다... 아마 지금부터 준비하면 올해 9월 릴리스에는 어느정도 할 수 있지 않을까?
웹사이트 번역 - 이제 그놈 웹사이트도 다음번 릴리스 타겟으로 Plone CMS를 이용하도록 개편될 예정이다. 개편의 목표 하나가 다국어 사이트이니까 웹사이트에 있는 내용의 번역도 필요해졌다.
그놈 관련 개발
입력기 통합 - 이상한 방향으로 논의만 있던 상태이지만, 입력기 프레임워크를 데스크탑에 통합하는 데 참여한다. 방향조차 애매한 상태라서 갈길이 멀지만, 지금보다 더 그놈 환경에 잘 통합되도록 만들 필요가 있다. 예를 들어서 알림 영역에 입력기 UI가 들어간다든지, 별도 설정 파일에 설정사항을 저장한다든지, 언어별로 다른 프로그램이 동작한다든지 하는 건 범용성을 위한 것이지, 그놈 데스크탑에 잘 통합된 형태는 아니다.
접근성 관련 작업 - 현재 Orca나 GOK같은 접근성 관련 소프트웨어는 메세지 번역만 됐을 뿐이지 실제 한글 입/출력 환경에서 동작할 수는 없다. (dasher는 첫가끝 코드 덕분에 꽤 쓸만하게 동작한다.) orca같은 경우에는 TTS 소프트웨어가 필요하고 (아래에서 다시), GOK는 조금 동작하겠지만 키보드 입력이 불편한 사람들이 한글 입력을 어떻게 할 지에 대해 다른 non-free 소프트웨어도 참고하는 등 연구가 좀 필요하다. 당장 수요가 거의 없다고 생각되거나 최소한 알려져 있지 않기 때문에 무턱대고 노력을 투자하기도 힘든 부분이다. (혹시 자신이나 주변 분들이 그놈의 접근성 관련 기능들을 이용하고 있거나 이용할 필요가 있다면 알려 주시길..)
버그, 버그, ... - 끊임없는 버그 찾기 및 고치기.
일반 한국어 관련 개발
쓸만한 한글 정자체 글꼴 - 바람직한 라이센스에, 품질이 높고, 모든 한국어 유니코드 영역을 커버하면서, 계속 메인테인되는 정자체 글꼴이 있었으면 좋겠다. (현존하는 글꼴들이 과연 여기에서 뭐가 부족할까?)
철자 검사 프로그램 - kts 등의 문제를 해결하고 쓸만한 상태로 끌어올리거나 새로 만들어도 좋다. 다른 프로그램과 연동해서 사용할 수 있도록 gnome-spell, Enchant 등 다른 소프트웨어에 통합하는 작업도 필요하다.
Text To Speech - Orca 따위에 필요하다.
기타 개발
하드웨어 지원 - 한국 컴퓨터 시장에서 볼 수 있는 TV 수신 카드, 화상 카메라, 디지탈 카메라 등의 하드웨어들이 리눅스에서 지원되도록 한다. 직접적인 L10N이라고 할 수는 없지만, 그 하드웨어를 이용하는 그놈 프로그램들을 한국 사용자가 쉽게 사용할 수 있게 만드는 일이 된다. (Ekiga, gnome-volume-manager 등) 한국 시장의 노트북 컴퓨터들의 전원 관리 문제들을 잘 보고하고 도움을 주는 일도 그놈의 전원 관리 기능 향상에 도움이 된다.
커뮤니티
이제 공식 웹사이트에 한국어 번역이 들어간다면 로컬 사이트가 해야 할 일은? 사용자 사이의 의사소통이 가장 크다. 또 하나의 언어 장벽이 될 수밖에 없는 버그질라 등의 다리 역할을 하면서 사용자 의견을 받아들이고 로컬 사용자 모임으로 역할을 해야 한다. 최근 gnome.or.kr의 개편이 있었으니 잘 되리라 믿는다.
2007년 2월 23일 금요일
마법사와 드루이드
glade3 번역을 하다가 잠깐 든 생각..
그놈 UI 위젯의 하나로 GnomeDruid라는 것이 있다. 프로그램을 처음 실행했을 때 여러가지 설정을 순서대로 한다든지 할 때 사용하는 GUI 위젯으로, "다음"/"이전" 단추를 눌러가며 순서대로 복잡한 설정을 해 나갈 때 쓰는 위젯이다. 당연히 이 위젯은 "마법사"(Wizard)의 패러디이다.
하지만 아마 한국말로 그놈 프로그램을 사용하고 있는 사람들은 "마법사"만 볼 뿐이지 드루이드라는 말은 본 적이 없었을 것이다. 아무리 원문에서 Druid라고 해도 마법사라고 번역할 수밖에 없었다. 위저드나 드루이드 모두 우리 문화에서는 존재하지 않았던 것이지만, 외래 문화의 수입으로 "마법사"는 많이 알려졌다. 또 마이크로소프트가 "마법사"라는 GUI가 이런 것이다라는 걸 많이 주입을 시켰기 때문에 "마법사"라는 용어가 자연스럽게 받아들여진다. 아마 판타지 소설이나 게임을 통해 접한 사람이 아니라면, 드루이드라는 게 무엇인지 모르는 한국 사람이 대부분이고 알더라도 마법사가 들어갈 자리에 드루이드를 쓴다면 혼란을 일으킬 것이다.
하지만 glade를 쓰는 사람들은 드루이드라는 말을 보게 될 것이다. glade는 개발자용이니까 위젯 이름을 그대로 반영하는 게 좋다.
(업데이트) 이제 GnomeDruid는 deprecated이고 GtkAssistant로 대체되어 이제 마법사라는 말조차도 못 보게 될 것 같다.
그놈 UI 위젯의 하나로 GnomeDruid라는 것이 있다. 프로그램을 처음 실행했을 때 여러가지 설정을 순서대로 한다든지 할 때 사용하는 GUI 위젯으로, "다음"/"이전" 단추를 눌러가며 순서대로 복잡한 설정을 해 나갈 때 쓰는 위젯이다. 당연히 이 위젯은 "마법사"(Wizard)의 패러디이다.
하지만 아마 한국말로 그놈 프로그램을 사용하고 있는 사람들은 "마법사"만 볼 뿐이지 드루이드라는 말은 본 적이 없었을 것이다. 아무리 원문에서 Druid라고 해도 마법사라고 번역할 수밖에 없었다. 위저드나 드루이드 모두 우리 문화에서는 존재하지 않았던 것이지만, 외래 문화의 수입으로 "마법사"는 많이 알려졌다. 또 마이크로소프트가 "마법사"라는 GUI가 이런 것이다라는 걸 많이 주입을 시켰기 때문에 "마법사"라는 용어가 자연스럽게 받아들여진다. 아마 판타지 소설이나 게임을 통해 접한 사람이 아니라면, 드루이드라는 게 무엇인지 모르는 한국 사람이 대부분이고 알더라도 마법사가 들어갈 자리에 드루이드를 쓴다면 혼란을 일으킬 것이다.
하지만 glade를 쓰는 사람들은 드루이드라는 말을 보게 될 것이다. glade는 개발자용이니까 위젯 이름을 그대로 반영하는 게 좋다.
(업데이트) 이제 GnomeDruid는 deprecated이고 GtkAssistant로 대체되어 이제 마법사라는 말조차도 못 보게 될 것 같다.
2007년 1월 14일 일요일
어색한 메세지 번역을 피하는 팁 몇가지
문장 부호를 똑같이 붙이려고 하지 말아라.
- 우리말에서는 문장에 세미콜론을 쓰지 않는다.
- 원문에 쉼표가 있다고 번역문에 쉼표를 넣을 필요는 없다. 우리말로는 쉼표를 쓰지 않아도 문장이 명확한 경우가 많다.
- 영어에서는 흔히 문장 끝에 괄호를 열고 괄호를 닫은 다음 마침표를 찍는다. 하지만 우리말에서는 그렇게 쓰지 않는다.
영어 문장의 처음에 쓰인 대소문자를 그대로 따라할 필요는 없다.
- 영어에서는 첫 단어가 소문자로 쓰는 단어일 경우에도 (프로그램 이름 따위) 대문자로 만들어서 쓴다. 그대로 쓰지 않도록 신경 쓴다.
관계사가 줄줄이 붙은 문장을 한문장으로 번역하려고 순서를 여기저기 뒤집지 않는다.
- 어느정도 같은 말을 반복하더라도 여러 문장으로 쓰는 편이 낫다. 한 문장으로 쓰려고 하다가는 오히려 말 순서가 바뀌어서 핵심단어가 뒤에 가는 등 의미가 불명확해질 수가 있다.
- 우리말에서는 문장에 세미콜론을 쓰지 않는다.
- 원문에 쉼표가 있다고 번역문에 쉼표를 넣을 필요는 없다. 우리말로는 쉼표를 쓰지 않아도 문장이 명확한 경우가 많다.
- 영어에서는 흔히 문장 끝에 괄호를 열고 괄호를 닫은 다음 마침표를 찍는다. 하지만 우리말에서는 그렇게 쓰지 않는다.
영어 문장의 처음에 쓰인 대소문자를 그대로 따라할 필요는 없다.
- 영어에서는 첫 단어가 소문자로 쓰는 단어일 경우에도 (프로그램 이름 따위) 대문자로 만들어서 쓴다. 그대로 쓰지 않도록 신경 쓴다.
관계사가 줄줄이 붙은 문장을 한문장으로 번역하려고 순서를 여기저기 뒤집지 않는다.
- 어느정도 같은 말을 반복하더라도 여러 문장으로 쓰는 편이 낫다. 한 문장으로 쓰려고 하다가는 오히려 말 순서가 바뀌어서 핵심단어가 뒤에 가는 등 의미가 불명확해질 수가 있다.
2007년 1월 1일 월요일
피드 구독하기:
글 (Atom)