Page 1 of 1

L10N 용어 통일 문제.

Posted: 2008 03 21 10:21 20
by dyhan81
제가 느낀 문제점 중 가장 크고 시급한 문제 하나가 바로 한국 Mozilla 에서 사용하는 용어 통일안 (미국 Mozilla - 한국 Mozilla 용어 사전) 이 없다는 겁니다. 협동 작업을 하는데 기준이 없으니 가다가 흐지부지 되는게 당연하다고 할까요? 문법이라던지 그런 것들은 일본어 언어팩이라던지 다른 나라 언어팩을 봐도 사용자가 알아보고, 원래의 의미가 크게 왜곡되어 전달되는 문제만 없으면 그다지 큰 문제로 간주해야할 것 같지는 않습니다. 문법 문제를 완벽히 해결한다는 것을 극단적으로 말하면, en-US 언어팩을 문법적으로 완벽하게 한국어로 번역하는 번역기를 만들어야 한다는 이야기가 되어버리지 않습니까? 또한 엄밀히 말해, 원래 무료인 한글판 Firefox를 미션 크리티컬한 분야에 쓰는데 문제가 있다고 하더라도, 그건 그 쪽에서 해결해야할 문제이며 우리 커뮤니티에 책임을 물을 수 있는 문제가 아니기도 합니다.

예전에 이 문제에 대해서 논의한 것이 없는가 찾아봤는데, 2006년에 불여우2에서의 확장 및 어플리케이션용어 통일안라는 제목으로 토론이 있긴 있었네요. 처음에는 가볍게 "통일이 되고 있지 않은 용어를 하나씩 찾아 통일안을 마련해보자~"라는 취지로 시작한 것이 중간에 가다가 용어의 적합성을 따지고 드는 사람들이 나타나서 논의가 진척되지 않자, 석찬님과 정균님께서 "일단 IE의 용어를 따라갑니다"라고 못박아두고 용어 통일을 진행시키려 했음에도 불구하고 논쟁으로 비화되어 더 이상 진행되지는 않은 것 같아보입니다. 용어의 적합성 문제를 들고 오신 분들의 이야기는 Firefox 만의 정통성을 만들어보자는 이야기인데... 이런 분들에게는 앞으로 우리나라에서 점유율이 2%도 안되는 Firefox가 IE 사용자들에게 쉽게 다가갈 수 있는 길이 일단 IE와의 유사성이라고 말씀 드리고, 용어의 적합성 문제에 대해서는 초반에 "한국 Mozilla 커뮤니티가 지금 해결하고자 하는 문제가 아니다"라고 처음부터 못박아둘 필요가 있겠습니다. 사실 용어 적합성 문제도 본질은 "일반 사용자가 얼마나 해당 용어 대해서 쉽게 이해할 수 있느냐?"라는게 주된 화두로서, 개인적으로 "잘라내기, 오려내기, 끊어내기, 갈무리하기, 클립보드에 옮기기" 중에 어떤 것이 어법상 옳다고 논쟁하는 것은 올바른 방향이 아니라고 생각합니다. 용어 통일에 대한 다른 글이 또 있나요?

위과 같은 일이 있어서 그런 것이었는지도 모르겠으나, 요전 한국 모질라 홈페이지를 개편하면서 새로운 웹페이지에 대한 번역 자원봉사를 요청하셔서 조금 도와드렸는데, 번역 참여자들 사이에서 용어에 대한 이견이 생기자 석찬님께서 핵심 페이지 몇 개만 진행시키시고 나머지에 대해서는 계속 보류하고 계시는 것 같네요.

암튼 저는 용어의 적합성 문제나 문법 등은 장기적으로 해결할 문제로 간주, 일단 완전히 제쳐두고서라도, Mozilla 프로젝트에서 사용되는 용어가 우선 일관성을 가져야 한다고 생각합니다. 그렇게 하기 위해 문제가 되는 용어를 "가볍게 하나 하나씩 해결"하는 것보다 아예 용어사전을 통째로 편찬해서 한꺼번에 해결하고, 일단 그것을 기준으로 L10N 언어팩을 개발하도록 하면 어떻겠습니까? 또한 편찬된 용어 사전을 커뮤니티에 던져놓고 용어 적합성을 따지고 싶어하는 사람들에게는 얼마든지 그렇게 할 수 있도록하면 장기적으로 용어 적합성 문제를 해결할 수도 있을 것 같습니다. 그래야 한국 Mozilla 프로젝트 활동이 좀 더 활발해질 수 있을 것 같기도 하구요.


또한, 위 링크의 토론을 주욱 보니까, "L10N 업데이트 방식에 대한 불만"에 대한 글도 있는데, 지금도 예전 업데이트 방식에서 좀 더 나아진 것이 없는건가요? 구체적으로 어떤 것이? 이 문제와는 별 관계가 없을 수도 있지만 말씀드리자면, 제가 얼마전에 security 모듈부에 대해서만 번역을 대규모로 손봤을 때, security 모듈부에 대해서 번역을 손 보면서 기존에 번역되어있는 다른 부분과의 차이에 신경이 많이 쓰였습니다. 다시 말해, 저는 지금처럼 모듈별로 l10n 메시지 저장 파일이 따로 있어서, Mozilla의 제품에서 쓰이는 한국어 메시지 전체를 통합해서 한꺼번에 볼 수 없는 것에 많은 불편을 느꼈습니다.

시간이 얼마나 걸릴지는 모르겠지만, 업데이트를 용이하게 하기 위한 Mozilla 제품용 l10n 개발/검토/용어 사전 제작용 툴을 현재 구상해보고 있습니다...... (누군가 이미 Python으로 개발해놓은게 있는걸 봤습니다만, 영 마음에 들지는 않아서요...) Mozilla 측에서 "던져주는거나 잘 받아먹으라"는 식으로 답변해 왔다면, l10n 개발/유지관리 부분에 대해서는 l10n 개발을 하는 쪽에서 해줘야 한다고 생각하는게 아닌가 싶습니다. 그렇다면 꼬물꼬물~ 한번 움직여봐야죠. :mrgreen:

Re: L10N 개발에 많은 어려운 점이 있군요... 특히 용어 문제.

Posted: 2008 03 21 13:42 15
by Channy
dyhan81 wrote:요전 한국 모질라 홈페이지를 개편하면서 새로운 웹페이지에 대한 번역 자원봉사를 요청하셔서 조금 도와드렸는데, 번역 참여자들 사이에서 용어에 대한 이견이 생기자 석찬님께서 핵심 페이지 몇 개만 진행시키시고 나머지에 대해서는 계속 보류하고 계시는 것 같네요.
일단 이건요. 제가 바빠서 적용을 못하고 있습니다.
일단 Firefox 3가 나오게 되면 Mozilla 사이트 리뉴얼도 계획 되어 있어서 한꺼번에 해야 겠다는 생각도 있구요.
RC가 나오면 그 때 다시 한번 할 예정입니다.

제 희망 사항으로는...
웹마스터 역할을 해 줄 사람이 있으면 더 좋겠죠.

Channy

Re: L10N 개발에 많은 어려운 점이 있군요... 특히 용어 문제.

Posted: 2008 03 21 23:16 18
by 후니미닉
dyhan81 wrote:예전에 이 문제에 대해서 논의한 것이 없는가 찾아봤는데, 2006년에 불여우2에서의 확장 및 어플리케이션용어 통일안라는 제목으로 토론이 있긴 있었네요. 처음에는 가볍게 "통일이 되고 있지 않은 용어를 하나씩 찾아 통일안을 마련해보자~"라는 취지로 시작한 것이 중간에 가다가 용어의 적합성을 따지고 드는 사람들이 나타나서 논의가 진척되지 않자, 석찬님과 정균님께서 "일단 IE의 용어를 따라갑니다"라고 못박아두고 용어 통일을 진행시키려 했음에도 불구하고 논쟁으로 비화되어 더 이상 진행되지는 않은 것 같아보입니다. 용어의 적합성 문제를 들고 오신 분들의 이야기는 Firefox 만의 정통성을 만들어보자는 이야기인데... 이런 분들에게는 앞으로 우리나라에서 점유율이 2%도 안되는 Firefox가 IE 사용자들에게 쉽게 다가갈 수 있는 길이 일단 IE와의 유사성이라고 말씀 드리고, 용어의 적합성 문제에 대해서는 초반에 "한국 Mozilla 커뮤니티가 지금 해결하고자 하는 문제가 아니다"라고 처음부터 못박아둘 필요가 있겠습니다. 사실 용어 적합성 문제도 본질은 "일반 사용자가 얼마나 해당 용어 대해서 쉽게 이해할 수 있느냐?"라는게 주된 화두로서, 개인적으로 "잘라내기, 오려내기, 끊어내기, 갈무리하기, 클립보드에 옮기기" 중에 어떤 것이 어법상 옳다고 논쟁하는 것은 올바른 방향이 아니라고 생각합니다. 용어 통일에 대한 다른 글이 또 있나요?
해당 논쟁 글타래의 장본인입니다. :oops:
제가 알고있는 바로는 그 이후에 더 이상의 용어통일논란은 없었습니다.
현재는 용어의 적합성 논란을 따지기보다는 쉽게 참고할 수 있을 만한 용어 통일안부터 만드는 게 시급한것 같습니다.
현재 대부분의 확장 기능 개발자와 번역가들이 사용하고 있는 바벨질라에서는 용어 사전 비슷한 서비스를 제공하고 있네요.
http://www.babelzilla.org/component/opt ... Itemid,73/
중어,일어,불어,독어사전 등등이 있는데 한국어사전은 아직 없습니다.
Channy wrote:일단 이건요. 제가 바빠서 적용을 못하고 있습니다.
일단 Firefox 3가 나오게 되면 Mozilla 사이트 리뉴얼도 계획 되어 있어서 한꺼번에 해야 겠다는 생각도 있구요.
RC가 나오면 그 때 다시 한번 할 예정입니다.
RC가 나온 뒤면은 좀 늦은 감이 있는데요...
RC버전이 발표될 무렵이면 대부분의 확장 기능들이 차기 버전에 대한 지원을 포함한 버전을 배포합니다.
RC버전 이후 통일안을 만들면 이미 배포된 확장기능의 용어들을 수정하여 제작자에게 보내고 제작자는 수정된 한국어 언어팩이 포함된 버전을 다시 배포해야되는 서로가 불편한 상황이 됩니다.

Re: L10N 개발에 많은 어려운 점이 있군요... 특히 용어 문제.

Posted: 2008 03 22 13:01 17
by 용오름
후니미니 wrote: 현재 대부분의 확장 기능 개발자와 번역가들이 사용하고 있는 바벨질라에서는 용어 사전 비슷한 서비스를 제공하고 있네요.
http://www.babelzilla.org/component/opt ... Itemid,73/
중어,일어,불어,독어사전 등등이 있는데 한국어사전은 아직 없습니다.
예전엔 바벨질라에 한국어 사전이 있습니다만, 개편후 언제가부터 한국어 사전이 사라져 버렸더군요.
정확히는 사전에 입력이 그나마 활발한 몇몇 언어를 빼고 나머지 언어들을 삭제한듯 싶습니다.
저도 3~5개정도의 단어를 입력했는데 한국어 사전에 입력된 전체 단어의 갯수는 10개 안팎이었던것으로 기억됩니다.

아무래도 우리나라의 참여율과 인지도가 낮아서 발생한 문제가 아닌 싶기도 하고 많이 아쉽더군요.

윗글 정정합니다.

Posted: 2008 03 22 13:28 25
by 용오름
사라졌다고 했는데 지금 다시 확인해 보니 다시 살아 있네요.
문제는 아직 별도로 사전으로 빼놓기엔 부족한지 별도의 링크가 없습니다.

한때 일본(ja-JP)을 따라 잡기도 했는데(2007년 2월 25일, 13위),
열심히 활동하는 분들이 제한적이라서 그런지 현재는 15위(47.3 %)로
바벨질라에 등록된 확장기능의 절반도 채 한글지역화가 이뤄지지 못했네요.
(일본은 꾸준히 올라가 현재 10위로 66.2 %, 한때 상위권을 유지하던 대만은 많이 떨어져 12위로 56.3 %죠.)

바벨질라에 가입해 확장기능에 대한 한글지역화에 참여하는 분들이 더욱 늘어났으면 좋겠습니다.

바벨질라 내 한글사전 주소는
http://www.babelzilla.org/index.php?opt ... 3&catid=16
입니다.

Re: 윗글 정정합니다.

Posted: 2008 03 22 18:38 22
by 후니미닉
용오름 wrote:사라졌다고 했는데 지금 다시 확인해 보니 다시 살아 있네요.
문제는 아직 별도로 사전으로 빼놓기엔 부족한지 별도의 링크가 없습니다.

한때 일본(ja-JP)을 따라 잡기도 했는데(2007년 2월 25일, 13위),
열심히 활동하는 분들이 제한적이라서 그런지 현재는 15위(47.3 %)로
바벨질라에 등록된 확장기능의 절반도 채 한글지역화가 이뤄지지 못했네요.
(일본은 꾸준히 올라가 현재 10위로 66.2 %, 한때 상위권을 유지하던 대만은 많이 떨어져 12위로 56.3 %죠.)

바벨질라에 가입해 확장기능에 대한 한글지역화에 참여하는 분들이 더욱 늘어났으면 좋겠습니다.

바벨질라 내 한글사전 주소는
http://www.babelzilla.org/index.php?opt ... 3&catid=16
입니다.
한국어 전용 사전이 아니라 그냥 범용 사전에 한국어 단어가 몇개 있을 뿐이네요.
저도 개인적으로 몇개 올린 적이 있습니다만...

Re: L10N 개발에 많은 어려운 점이 있군요... 특히 용어 문제.

Posted: 2008 03 25 01:10 29
by 김정균
dyhan81 wrote:"L10N 업데이트 방식에 대한 불만"에 대한 글도 있는데, 지금도 예전 업데이트 방식에서 좀 더 나아진 것이 없는건가요? 구체적으로 어떤 것이?
달라진 것이 아마 전혀 없을 겁니다. 다만, 그 때 보다는 많이 익숙해 져서 그 때의 상황 보다는 좀 낫은 상황이기는 합니다만..

일단 현재의 문제점은.. 영문팩과 diff 를 할 수 없기 때문에 영문팩의 cvs commit 정보를 하나하나 쫒아서 가야 한다는 점입니다. 즉 매일 매일 체크하면서 따라가면 크게 문제는 없으나 한달 정도를 쉬었다고 한다면.. 어디서 부터 해야 하는지 부터 찾아야 한다는 것이죠. 전 이점 때문에 diff 를 할 수 있는 원본을 원했던 것이고요. :-)

솔직히 요즘에는 이 익숙함 때문에 별 생각 없이 따라가고 있기는 하지만, 반대 급부로 다른 생각할 겨를 없이 tinderbox 에 불끌 것에만 신경이 집중이 되는 오작용도 있기는 합니다. ^^

Re: L10N 개발에 많은 어려운 점이 있군요... 특히 용어 문제.

Posted: 2008 03 25 06:10 05
by dyhan81
김정균 wrote:
dyhan81 wrote:"L10N 업데이트 방식에 대한 불만"에 대한 글도 있는데, 지금도 예전 업데이트 방식에서 좀 더 나아진 것이 없는건가요? 구체적으로 어떤 것이?
달라진 것이 아마 전혀 없을 겁니다. 다만, 그 때 보다는 많이 익숙해 져서 그 때의 상황 보다는 좀 낫은 상황이기는 합니다만..

일단 현재의 문제점은.. 영문팩과 diff 를 할 수 없기 때문에 영문팩의 cvs commit 정보를 하나하나 쫒아서 가야 한다는 점입니다. 즉 매일 매일 체크하면서 따라가면 크게 문제는 없으나 한달 정도를 쉬었다고 한다면.. 어디서 부터 해야 하는지 부터 찾아야 한다는 것이죠. 전 이점 때문에 diff 를 할 수 있는 원본을 원했던 것이고요. :-)

솔직히 요즘에는 이 익숙함 때문에 별 생각 없이 따라가고 있기는 하지만, 반대 급부로 다른 생각할 겨를 없이 tinderbox 에 불끌 것에만 신경이 집중이 되는 오작용도 있기는 합니다. ^^
mozilla에서 제공하는 툴로만 유지보수 하자면, 상당히 힘들지 않나 그렇게 생각합니다.

:?: 영문판 원본을 제공해달라고 했던거군요. CVS 리포지터리 자체에 파일별로 버전/날짜 단위로 저장되어있는 것을 꺼내와서 비교해보면 되잖아요? 제가 이해하지 못하고 있는 다른 문제가 있습니까? CVS 툴을 사용하고 계신게 없다면, eclipse를 추천해드립니다. Mozilla에서 툴을 제공하지 않는 이유는 이런 CVS 툴을 이용하면 되니까 별다른 조치를 취하지 않고 있는 것 같아보이네요.
http://img217.imageshack.us/img217/9687 ... zi4.th.png

:!: 위 캡처는 Firefox 3.0 beta4 RELEASE 버전과 trunk 버전(HEAD)을 비교해서 서로 달라진 부분을 표시한 eclipse IDE 화면입니다. CVS 리비전 번호, 날짜, 그에 따른 코멘트들, 버전 및 브랜치 테그, 커밋한 사람까지도 일목요연하게 표시되고 있습니다. 일단 Firefox 3.0 beta4 RELEASE 버전을 받아와서 비교한 것이지만, 날짜를 지정해서 현재 프로젝트로 보유하고 있는 CVS 파일와 비교 해당 날짜 이전/이후에 달라진 부분을 표시하는 것도 가능합니다. 역시 단점이라면, 현재 Mozilla 프로젝트 별로 분산되어있는 locales 폴더를 프로젝트 별로 따로 관리해야한단 점입니다만, Eclipse의 Workspace를 따로 관리하고, Working set으로 프로젝트를 묶어두면 불편함을 감소시킬 수 있을 것입니다.

영문판에서 달라진 내용의 한글판 반영은 이런 툴들을 이용해서하면 우선 해결할 수 있으리라 생각되구요...

제가 느끼고 있는 문제는 한국어 언어팩의 전체적인 용어 통일성입니다.

이것을 해결하기 위해서는 우선, 사전을 제작해야하기 때문에 영문팩 내에 들어있는 properties, dtd를 몽땅 스케닝해서 Lexical Analyzer (Lexer)에 넣어 단어를 추출해내려고 시도 중입니다... (누군가 하신분이 계신다면 쓸데없을지도 모르는 시도를 하는 저를 그만 두게끔 해주세요! :wink: ) 이 방면에 노하우가 없어서... 상당히 시간이 많이 걸리네요... ㅎㅎㅎ

그리고 다음 단계로 현재 만들어져있는 한국어 언어팩의 L10N 스트링들을 데이터베이스화 시켜서 영문 언어팩 파일의 내부구조를 유지한체로 키 단위로 스트링을 대치해넣을 수 있는 방법을 생각하고 있습니다. 현재 한국어 언어팩을 들여다보면 영문팩에 들어있는 코멘트가 없어져있고, 키 값들이 이리저리 섞여있어서 영어팩과 연동하여 유지보수를 하기가 쉽지 않게 되어있거든요. 또한 이 단계까지오면 이전 단계에서 만든 용어사전을 기반으로, ko L10N 스트링들을 전체적으로 조망할 수 있기 때문에 용어 통일성을 높일 수 있는 기회도 얻을 수 있을 것 같습니다.

암튼... L10N 프로젝트는 전체적으로 정리와 집중이 필요하다는 느낌입니다...

제가 하려는 작업에 적절한 툴들이 있으면 소개시켜주세요. Mozilla Developer Center에서 L10N에 관계하여 소개해놓은 툴들을 검토해봤습니다만, 별로 마음에 드는 것이 없어서 직접 만드려고하고 있거든요. 물론 그렇다보니 시간이 얼마나 걸릴지 모르고, 성능도 장담 못하겠고, 그렇습니다...

Re: L10N 개발에 많은 어려운 점이 있군요... 특히 용어 문제.

Posted: 2008 03 25 11:22 24
by Channy
현재 Firefox의 L10n 리소스가 mozill.org CVS에 탑재된지 4년째 접어 듭니다. 동윤님이 하실려는 비슷한 작업을 이미 많은 L10n 개발자들이 할려고 했습니다. MozTranslator를 비롯 gettext를 이용한 툴 등등... 번역 툴도 꽤 여럿 나왔고요.
각 나라 마다 Glossary를 가질려고 하는 노력도 시도 많이했습니다. 그런데 P1/P2 (주요 언어)에서 그런 툴을 사용하거나 Glossary를 이용하는 L10n community는 거의 없습니다.

그 이유는 몇 가지가 있는데요.

1. L10n 작업을 batch tool이나 그런데 의존하다 보면 실수가 생기거나 부정확한 번역이 생길 수 있습니다. 영문판 조차도 Glossary에 의존해서 만들고 있지 않구요. (가끔 Linux에서 Preference Winodws에서 Options 라고 하는 걸 최근에 와서 고치는 경우도 비일비재 합니다.) 과거의 메시지도 QA 과정을 거쳐 좀 더 완성된 번역본을 제공하고자 노력 하고 있습니다. 우리 같은 경우도 과거에 문제된 메시지를 지금 QA 과정을 거쳐서 다듬는 방법을 이용하는 것도 이런 이유구요.

2. 현재 Source Tree 변경 사항을 주 단위로 따라가는 것이 가장 좋은 방법이고 완성도를 높힌다고 생각 합니다. 과거에는 L10n 작업을 릴리스 단계에 거의 와서야 작업을 했습니다. 당연히 그 사이의 변경 사항을 en-US diff를 하고 그걸 ko 패키지에 이용하는 방식을 이용했구요. 이러다 보니 QA 없이 벼락치기식으로 작업했었습니다. 그래서 3.0 부터는 Alpha 때 부터 주 단위로 en-US checkin을 따라가는 방식으로 바꾸었고 지금까지는 꽤 만족하고 있습니다. 바쁠 때는 김정균님과 주 단위 로테이션으로 하기도 합니다.

3. 현재 Glossary가 필요할 만큼 번역을 해야되는 양은 많지 않습니다. L10n 메시지 관련 버그는 일주일에 고작해야 10~20개 버그 였고 (지금은 5~6개) 이 정도는 많지 않죠. 문제는 기존 메시지의 용어 통일성이 없는 것들인데 이런 것들은 발견되는 경우 논의를 거쳐 한번씩 Batch를 하거나 일일이 확인 후 고치려고 합니다.

용어 사전을 만드는 것보다 그냥 통일성이 잘 없는 용어들을 골라 토론 후 고치는 방향을 잡는 게 더 나을 겁니다. 용어 사전이란게 만드는 것 보다 유지하는 게 더 힘들고 그런 시간이 있으면 기존 메시지 QA 작업에 쓰는 게 더 낫다는 생각이 듭니다.

어쨌든 동윤님 작업이 헛되다는 건 아니고 기존에 하시던 QA 작업 위주로 더 집중하시는 게 낫지 않을까 싶어서 말씀 드립니다.

p.s. pki 관련 메시지들은 양이 너무 많아서 일부 검토하다가 중단했는데 RC1에는 추가되도록 해보겠습니다.

Re: L10N 개발에 많은 어려운 점이 있군요... 특히 용어 문제.

Posted: 2008 03 25 13:00 39
by dyhan81
석찬님, 요즘 상당히 바쁘실텐데도 장문의 글을 남겨주셔서 감사합니다.

사전을 만들고자하는 시도가 이미 있었고, 유지하는 일이 힘들 뿐더러, 애석하게도 사전 어휘의 기준이되는 en-US 메시지 조차도 기준이 될 수 없다는 말씀이시군요. :o

네, 제가 원래 사전을 만드려고 했던 것은 en-US 기준으로 여러가지로 통일성이 없게 번역된 한국어를 찾아내고, 앞으로 웹페이지라던지 번역 수요가 꾸준하게 있을텐데, 그런 것에 초보 번역자가 용이하게 사용할 수 있게끔 하자는 것이 본래 의도였습니다.

사전을 제작해서 프로젝트에 반드시 반영 시켜야 한다고 주장한 건 아닙니다. (그럴 계획이 있는지 여쭤보는 것이었습니다) 프로젝트에 나오는 메시지는 L10N. 즉 해당 언어 사용자가 원래의 뜻에 가깝게 이해하기 용이하게하면 되는 것이지, 정확도 100%를 유지해야하는 것은 아니지요.

--
한국어 L10N 프로젝트의 기존 메시지 QA작업시 힘든 점이라면 원본 (en-US) 메시지 파일 내부 구조와 달라서 두 개를 동시에 열어놓고 Line-by-Line으로 검토하기가 불가능 하다는 점인데요... 이렇게 해놓은 특별한 이유가 없다면, L10N QA 작업하면서, 이것도 바로 잡아보고 싶습니다. :)