2007년 12월 30일 일요일

브랜드의 번역

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

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

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

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

창우: 그거보다 훨씬 많아요. 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"라는 이름만은 영문 표기를 하는 브랜딩을 고집하는지 이해하기 힘들다. (번역자 맘대로 건드리기도 힘들게 만들어 놨다.)


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 파일의 단어들에 대해 통계를 내는 것도 의미가 있어 보이는데..  나를 포함해 누가 한 번역도 이 빈약한 번역 어휘의 문제에서 자유롭지 못할 것이다.

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

2007년 12월 11일 화요일

GtkBuilder 탐험

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

GtkBuilderlibglade의 대체품이라고 말할 수 있다. 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()

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

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에서 옮겨올 수 있을까? 많은 사람들이 어려움을 호소하는 걸 보면, 얼핏 보면 깔끔하고 좋아 보이지만 실제 적용하기는 쉽지 않은 모양이다.

2007년 12월 4일 화요일

아시나요 - 데비안 미러

ftp.debian.org 망가진 기념으로 잘 알려지지 않은 진실을 써 보면:

  • 데비안 메인 사이트 ftp.debian.org -- 아니다. 이 사이트는 데비안 메인 사이트가 아니라 1차 미러의 하나일 뿐이다. 마스터 사이트는 외부에서 접근이 불가능하다.
  • 그래도 ftp.debian.org가 제일 안정적이다 -- 아니다. 지금 하드 공간이 모자라서 업데이트가 안 되는 상태이고, 다른 1차 미러들은 멀쩡하다.
하지만 ftp.kr.debian.org는...  몇 개 사이트로 분산시키는 게 좋지 않을까? 카이스트 네트워크가 시도때도 없이 변화한다는 건 익히 알고 있는 사실이지만 "주5일제"라는 말을 할 정도로 너무 불안하다..  기업의 ftp 미러가 지속적으로 미러해 준다는 약속을 해 준다면 모르겠는데, 과거의 다른 기업 사이트들은 하드 모자라기만 하면 데비안을 지워버렸기 때문에 믿기도 난감하다.. -_-