Changwoo's Hacks

2.22에서 특히 바뀐 점


원문은 팬그램(pangram)으로 유명한 The quick brown fox jumps over the lazy dog 문장이다. 그놈 2.20 이전에는 MS 윈도우즈가 했던 것처럼 "무궁화꽃이 피었습니다"라고 했었다. 그런데 알고 보니까 MS는 "무궁화꽃이 활짝 피었습니다"라고 쓰고 있었는데 "활짝"을 빼먹었다는 것... 약간 실망(?)을 하고 바꾸는 김에 다른 대안이 없을까 하다가 마침 "스폰지" TV 프로그램에서 팬그램에 대해 소개를 하다가 한글 자모별로 한번씩 사용한 이 팬그램 문장이 나오길래 쓰게 되었다. (무궁화꽃이 피었습니다 놀이가 일본 전래 놀이인 건 둘째치고라도...  요즘 애들은 길에서 많이 놀질 않아서 그래서인지 잘 알지도 못하는 것 같다.)

연시를 맞아 수많은 올해 예언 시리즈가 나오는 바, 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 세계에 마치 북한이 존재하지 않는 것처럼 보이는 이유는, 다른 이유도 있지만 미국의 테러지원국 지정때문에 미국 및 미국과 관련 조약을 맺은 (한국을 비롯한) 국가에서 소프트웨어를 수출하는 게 불법이기 때문이기도 했다. 조금씩 들려오는 말들을 보면, 북쪽은 리눅스 관련 개발도 하고 배포판까지 만들어 쓰고 있다. 폐쇄성과 낮은 컴퓨터/인터넷 보급때문에 (그리고 아마도 남쪽보다도 참여의 문화가 부족할 것이므로) 녹록치 않겠지만, 제도적인 장벽이 사라지면 조금씩 업스트림에 북한이 모습을 드러낼 수 있을까?

GTK+ 2.12에 포함된 GtkBuilder 기능에 대해 탐험해 보면,

GtkBuilder는 libglade의 대체품이라고 말할 수 있다. GUI의 구성을 코드 내에서 하지 않고 XML 파일로 기술하고 런타임에 그 XML을 읽어들여서 UI를 구성한다. libglade를 써 봤다면 별로 새로운 건 아니겠지만, 일단 GTK+에 포함되어 버렸으니까 추가로 libglade를 링크할 필요가 없다는 장점이 있다. 또 일부 glade가 커버하지 못하고 있는 TreeView 따위의 복잡한 위젯도 쓸 수 있다. 요즘에 하드코딩으로 GTK+ 코딩하는 사람들이 거의 없다는 걸 생각해 보면 충분히 GTK+에 포함될 만한 기능이다. (GTK+가 너무 커진다 싶으면 언젠가 메이저 버전 뒤엎겠지.)

간단히 맛보기 필요한 소프트웨어: GTK+ 2.12 이상, pygtk (컴파일이 귀찮으므로)

import gtk
builder = gtk.Builder()
xml = '''
<interface>
  <object class="GtkWindow" id="cwwindow">
    <child>
      <object class="GtkButton" id="cwbutton">
        <property name="label">Build Me</property>
      </object>
    </child>
  </object>
</interface>
'''
builder.add_from_string(xml, len(xml))
win = builder.get_object('cwwindow')
win.show_all()
gtk.main()

위 파이썬 코드를 실행하면 이런 창이 나온다.

libglade를 사용해 봤다면 XML 문법만 다르지 별 다른 점을 느끼지 못할 것이다. 또 대부분의 glade 파일은 gtk 2.12에 포함되어 있는 gtk-builder-convert 프로그램을 이용해 GtkBuilder용 XML 파일로 변환할 수 있다. ui.glade라는 파일로 저장을 했다고 하면,

$ /usr/bin/gtk-builder-convert ui.glade ui.xml
$ python
Python 2.4.4 (#2, Aug 16 2007, 02:03:40)
[GCC 4.1.3 20070812 (prerelease) (Debian 4.1.2-15)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gtk
>>> builder = gtk.Builder()
>>> builder.add_from_file('ui.xml')
>>> builder.get_object('window1').show_all()
>>> gtk.main()

GtkBuilder의 장점은 "눈에 보이지 않는 오브젝트"를 정의할 떄 나온다. 특히 libglade를 사용할 때는 UI 디자인에서 지정하지 못하고 코딩으로 해결해야 했던 복잡한 위젯, 특히 모델/뷰/컨트롤러 개념이 필요한 TreeView, ComboBox 따위의 "모델"을 XML 파일에 집어 넣을 수 있다. 이 부분때문에 디자인과 프로그램이 완전히 분리하지 못했던 많은 코드를 분리할 수 있다.

<interface>
  <object class="GtkListStore" id="treemodel">
    <columns>
      <column type="gchararray"/>
      <column type="gint"/>
    </columns>
    <data>
      <row>
        <col id="0">cwryu</col>
        <col id="1">2</col>
      </row>
      <row>
        <col id="0">crew</col>
        <col id="1">1</col>
      </row>
      <row>
        <col id="0">clue</col>
        <col id="1">3</col>
      </row>
      <row>
        <col id="0">None of the Above</col>
        <col id="1">4</col>
      </row>
    </data>
  </object>
  <object class="GtkWindow" id="window1">
    <child>
      <object class="GtkTreeView" id="cwbutton">
        <property name="model">treemodel</property>
        <child>
          <object class="GtkTreeViewColumn" id="column0">
            <property name="title">Name</property>
            <child>
              <object class="GtkCellRendererText" id="r0"/>
          <attributes>
        <attribute name="text">0</attribute>
          </attributes>
        </child>
      </object>
    </child>
    <child>
          <object class="GtkTreeViewColumn" id="column1">
            <property name="title">Number</property>
            <child>
              <object class="GtkCellRendererText" id="r1"/>
          <attributes>
        <attribute name="text">1</attribute>
          </attributes>
        </child>
      </object>
        </child>
      </object>
    </child>
  </object>
</interface>

위의 XML 파일을 마찬가지의 python 코드로 돌리면,

이렇게 스트링-숫자 형식의 "모델"과 cwryu/crew/... 따위의 데이터를 포함할 수 있다.

현재 그놈 프로그램은 거의 glade만을 사용하고 있다. 내년 3월이나 9월 릴리스에서 libglade에서 옮겨올 수 있을까? 많은 사람들이 어려움을 호소하는 걸 보면, 얼핏 보면 깔끔하고 좋아 보이지만 실제 적용하기는 쉽지 않은 모양이다.

며칠에 걸쳐서 잠깐 잠깐씩, 재미가 없으면 내버려뒀다가 다시 생각나면 좀 만져보고 하는 일을 반복한 끝에...

lifepod openAPI의 인증 부분을 짰습니다.  며칠에 걸쳐서 lifepod API 서버의 버그로 잠깐 헤매다가, open ID에 http://를 넣었다가 뺐다가, 해시 부분을 소문자로 써야 하는 API의 숨겨진 사실을 깨닫기도 하다가, gnutls_fingerprint() 함수의 버그성 동작에 헷갈리다가 하면서 인증 부분만 완료.

• 상단의 openid, userkey, appid, appkey는 자기에 맞게 바꾸세요.
  
• 컴파일은 gcc -o example-lifepod `pkg-config --cflags libsoup-2.2` example-lifepod.c `pkg-config --libs libsoup-2.2`
• 스프(libsoup)는 GObject를 이용해서 만든 것이라서, synchronous하게 쓰려면 상관없지만 asynchronous하게 사용하려면 glib main loop가 필요합니다.

사실 인증보다 더 어려운 건 response로 날아온 XML을 파싱하는 거지만 그건 다른 종류의 내공이니까요. evolution frontend를 만드려고 했지만, evolution이 내부 데이터로 ical을 쓰고 있기 때문에 이건 lifepod xml to/from ical 변환 프로그램 만드는 꼴이 될 듯 합니다. 또 잠시 접어뒀다가 생각나면 조금씩 해 봐야죠.

"Just works"의 UI 철학에 따라(?) 패널에 배경 이미지를 씌울 수 있는 기능이 왜 있는지 잘 이해가 되지 않았다.  마침 그놈 사용자 안내서를 읽다가 드래그로 그놈 패널의 배경을 설정할 수 있다는 걸 발견, 노틸러스에서 "바탕색 및 꼬리표" 대화 창을 띄웠다.



얼마전 예비군 훈련을 갔다와서 빨아 놓은 군복을 정리하지 않은 지금...  "위장" 색을 패널에 끌어 놓아 보기로 했다.  (예비군 군복보다는 자이툰 부대 군복이랑 비슷한 것 같지만..)

앗!  정말 "위장" 효과가 있다.  패널이 눈에 잘 안 들어온다.


이렇게 하면 오히려 시야가 애플리케이션 창에 집중되서 패널에서 아무리 CPU 로드 그래프를 그려대고 깜박이는 거에 상관없이 집중할 수 있다. 

단, 패널을 볼 때도 패널이 눈에 잘 안 들어온다...

Tomboy를 실행하다가 날짜와 시간이 한국 포맷으로 나오지 않는 것을 발견해서 예전의 퍼키옹이 한 경로를 그대로 추적을 해 봤습니다. 막상 이걸 봐도 실제로 문제점을 추적하기는 힘들더군요.  그래서 일단 버그부터 지른다음에 조금 기다려봤는데...  역시 그냥 버그 현상만 써 놓으니까 메인테이너도 고쳐주질 않을 것 같고 퍼키씨도 당장은 손 안 대는 것 같고 해서 직접 찾아봤습니다.

결국 퍼키옹이 따라갔던 경로를 하나하나 다 반복해 보고서는 문제를 파악했는데..  문제는 헤더 파일을 제너레이트하는 C# 프로그램이 소팅을 하면서 "ko-kr"을 "kok" (콘칸어) 뒤에 배치하는 바람에 C 코드에서 strcmp로 바이너리 서치를 할 때 못 찾는 문제였습니다.  String.CompareTo()를 간단히 String.CompareOrdinal()로 교체해서 해결.

그런데 여기서 끝나지 않은 게, 빌드를 잘못했는지 이제 각각의 "1월", "2월", "월요일" 따위의 이름은 한글로 나오는데 포맷이 어떤 부분은 제대로 나오고, 어떤 부분은 "12월 6 2006"과 같이 나오네요.

(업데이트) 나머지 문제는 C# culture info와 상관없이 tomboy에서 자체적으로 사용한 날짜 포맷을 번역할 때 고려하지 않은 사항.  tomboy 번역을 바로잡았으니 다음 릴리즈에는 제대로 나오겠네요.

보안용 장비를 만들 시절에, 회사에서 번역 업체를 많이 이용했었다.  이 번역업체는 세계 곳곳의 각 언어권마다 지사를 두고 있는데 각 지사마다 네티이브 번역자가 있는 동시에 그 지역의 번역 의뢰자를 상대로 영업을 한다.  번역 의뢰가 들어오면 원문을 각 세계 지사에 보내서 네이티브들이 번역을 하게 만든 다음 번역한 결과물을 모아서 의뢰자에게 돌려준다. 이런 식으로 동작하는 번역 전문 회사가 꽤 많이 있고, 이 방식으로 꽤 괜찮은 품질의 번역을 빠르게 만들어 낼 수 있다. 보통 제품을 릴리스할 때마다 백여개 내외의 메세지가 독일어, 프랑스어, 이탈리아어, 스페인어, 일본어로 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% 없애기는 쉽지 않다.  실제로 마이크로소프트가 공개한 마이크로소프트가 릴리스하는 번역문도 하나하나 살펴보면 어색한 번역문도 있고 오역이라고 생각되는 번역문도 꽤 있으며 시간이 지나면서 다른 용어를 사용하는 부분도 꽤 보인다. 하지만 그 번역문 중에서도 자주 사용하는 마이크로소프트의 대부분의 번역문은 아주 매끄러운데, 이는 다름 아니라 엄청난 사용성 테스트의 결과물이다.  역시 피드백을 많이 받아서 계속해서 다듬어 나가면 잘 번역했다는 소리를 들을 수 있다는 얘기이다. 하지만 역시 보안 장비를 만들 때나 그놈 메세지를 번역할 때나 자기 스스로 깨닫고 고치는 것 외에 외부에서 피드백을 받기는 쉽지 않은 일이다. 그놈 메세지는 특히, 심심풀이 작업때문에 일부러 프로그램 테스트를 심각하게 할 수는 없는 노릇이다.

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

심심풀이 구글 SoC2007 그놈 포스터 번역

http://live.gnome.org/SummerOfCode2007/Poster

그놈 데스크탑 2.18에 포함될 프로그램으로 가장 작업량이 많았던 Seahorse 번역을 마쳤다.  700여개..


위에서도 "Full"과 같이 번역이 안 되어 나오는데, 프로그램 문제로 번역 안 되는 부분이 아주 많은 게 문제이다.  릴리스된 뒤에도 여기저기 번역 안 되는 버그를 잘 찾아봐야 할 듯 하다.  애플릿은 아예 전체가 번역이 안 되어 나온다.  다음은 애플릿을 이용해 클립보드의 내용에 서명을 붙인 것.


문제는 키링에 키가 많을 때 GPG가 시스템 대부분의 로드를 먹으면서 엄청나게 느려지는 현상이 있다.  내 키링이 기껏해야 300개 내외인데 이런 현상이 벌어진다.  (키링이 이보다 더 큰  키사이닝파티 매니아가 과연 seahorse를 사용할 지는 모르겠지만.)  상당히 featureful한 건 맞고 도움말 문서도 훌륭하지만 안정성은 좀 떨어져 보인다...

번역하면서 재미있는 기능을 발견했는데, DNS-SD(애플 랑데뷰/봉쥬르)를 이용해 네트워크에 자기 pubkey 키링을 export하고, 네트워크 안에서 seahorse를 사용하고 있는 사람들끼리 pubkey를 교환할 수 있다!  실험은 못 하지만 사무실/연구실같은 환경에서 사용했을 때 상당히 괜찮은 기능으로 보인다.

한번 그놈 데스크탑의 한국어 지원 상태와 과제에 대해 정리해 보았다.

번역

메세지 번역 업데이트, 다듬기 - 그놈 데스크탑의 한국어 메세지 번역은 그놈 역사와 함꼐 버전이 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의 개편이 있었으니 잘 되리라 믿는다.