예를 들어 “Pan”이라는 말을 번역하려고 한다. “Pan”이라는 단어를 전세계 수십 나라의 번역가에게 보내면 어떻게 번역을 해올까? 많은 나라에서 “빵”이라고 번역을 할 것이다. 그리고 “프라이팬”으로 번역하는 번역가도 있을 것이다. 이렇듯 번역할 메시지만 보고 번역을 한다는 것은 거의 불가능에 가깝다. 그래서 번역 가이드가 필요한 것이다. 번역할 메시지만 번역가에게 전달하는 것이 아니라 어떻게 번역해야 하는지 방법도 전달해야 한다.
“Open”이라는 메시지를 번역해야 한다고 생각하자. 번역가에게 무엇을 알려줘야 번역을 제대로 할 수 있을까? 한국어로는 어떻게 번역이 될지 생각해보자. “열기”? “열어라”? 어떤 투로 번역을 해야 하는지 알려줘야 할 것이다. “명사입니다.”라고 가이드를 주면 “열기”로 번역을 할 수 있을 것이다. 물론 번역 가이드는 전세계 수많은 나라의 번역가가 봐야 하므로 영어로 기록을 해야 한다. “It is a noun”과 같이 남기면 된다. 또한 “첫 글자는 대문자를 유지해주세요.”와 같은 가이드도 남길 수 있다.
그럼 번역 가이드를 남기는 방법과 어떤 가이드를 남겨야 하는지 알아보자.
번역 가이드는 별도의 파일이 따로 남기는 것이 아니라 소스코드의 메시지와 같이 기록해야 한다. 별도의 문서에 번역 가이드를 남기는 것은 관리가 너무 어렵기 때문이다. 프로그래머가 소스코드에 메시지를 기록할 때 번역 가이드를 동시에 적고 메시지를 추출할 때 자동으로 번역 가이드도 같이 추출되도록 해야 한다.
소스코드에 번역 가이드를 남기는 방법은 크게 3가지가 있다. 물론 번역 라이브러리에 따라서 지원하는 방법이 다르고 번역 가이드를 지원하지 않는 것도 있다. 번역 가이드를 지원하는 번역 라이브러리를 사용하는 것이 좋다.
첫째, 메시지 앞에 주석으로 남기는 방법이다. TRGUIDE라는 키워드는 번역 라이브러리마다 다를 수 있으며 사용자가 표준을 따로 정해서 지정해줄 수도 있다.
/* TRGUIDE: It is a noun. */번역함수(“Open”);둘째, 메시지 뒤에 주석으로 남기는 방법이다.번역함수(“Open”); // TRGUIDE: It is a noun.셋째, 번역함수의 인자로 가이드를 추가하는 방법이 있다.번역함수(“Open”, “It is a noun.”);
StringFormat함수(번역함수(“%1 of %2”, “%1, %2 will be replaced any word. Please consider the order in your language”), 번역함수(“Leg”, “It is a leg”), 번역함수(“dog”, “It is a big dog”));
/* TRGUIDE: %1, %2 will be replaced any word. Please consider the order in your language */StringFormat함수(번역함수(“%1 of %2”),/* TRGUIDE: It is a leg */번역함수(“Leg”),/* TRGUIDE: It is a big dog */번역함수(“dog”));
StringFormat함수(번역함수(“%1 of %2”), // TRGUIDE: %1, %2 will be replaced any word. Please consider the order in your language번역함수(“Leg”), // TRGUIDE: It is a leg번역함수(“dog”)); // TRGUIDE: It is a big dog
그럼 번역 가이드에는 어떠한 내용들이 추가되어야 할까?
1. 대문자 또는 소문자를 유지해주세요. 첫글자만 대문자를 유지해주세요. 이 경우 대소문자가 없는 언어라면 무시를 할 것이고, 대소문자가 있는 언어라면 가이드대로 번역이 될 것이다.
2. 메뉴 또는 버튼에 쓰이는 단어이니 명사로 번역해주세요. 명령어로 번역을 해주세요.
3. 이 단어는 번역하지 말아주세요. 고유명사입니다.
예를 들어 골프 선수 이름인 “Tiger Woods”를 번역해야 한다고 하자. 아무런 가이드가 없다면 “호랑이 나무”로 번역이 될 수도 있다. “사람 이름입니다.”라는 가이드를 주면 “타이거 우즈” 정도로 번역을 할 것이다. 이렇듯 회사 이름, 지역 명 등 고유 명사는 적절한 가이드가 필요하다.
한화(당시 한국화약)의 고위임원이 1990년에 중국 정부를 방문했는데”환영 남조선 폭파집단”이라는 환영 플랜카드가 걸린 것을 보고 회사이름을 “한화”로 바꾼 계기가 되었다는 일화도 있다.
4. %1, %2는 다른 단어로 교체가 될 수 있으니 순서를 고려해주세요.
5. 이 단어는 반도체 관련 단어입니다. 번역을 하지 말거나 용도에 맞게 번역해주세요.
같은 단어라고 하더라도 분야별로 의미가 다른 경우가 많다. 따라서 어떤 분야의 단어인지 또는 그 뜻을 정확하게 설명해주는 것이 좋다. 개발자는 단어를 적을 때 번역가가 헷갈려 할 수 있다는 것을 생각해야 한다. 물론 그런 판단을 하는 것이 쉬운 것은 아니다.
6. 약어인 경우 원래 의미를 적어주는 것이 좋다. 그렇지 않으면 약어는 정말 엉뚱하게 번역이 될 수도 있다. 전세계 표준 약어라고 하더라도 영어로 된 약어를 받아들이지 않는 나라도 많다. 따라서 약어의 줄이기 전 원래 단어를 알려줘야 제대로 번역이 될 수 있다.
7. 문화의 차이에 따라서 잘 알지 못할 수 있는 단어는 의미를 자세히설명해주거나 해당 단어를 잘 설명하고 있는 웹사이트 주소를 같이 적어주는 것도 좋다. 이때 Wikipedia 주소를 추가하기도 한다.
대부분의 번역가는 번역 가이드가 없어도 최대한 번역을 한다. 하지만이러한 번역가의 자세가 번역을 엉터리로 되게 하기도 한다. 대부분의번역가는 번역회사와 계약 관계에 있는 계약직 번역가이며 외국어를 전공한 학생이기도 하고 외국에서 살다온 사람일수도 있고 전문 번역가인 경우에도 있다. 번역가는 번역 단어수로 수입이 결정되기 때문에번역이 애매할 경우 적극적으로 해결하려는 경우는 그리 많지 않다. 그래서 소프트웨어 개발사에서 적극적으로 번역의 품질을 높이기 위한 정보를 제공해야 한다.
우리가 번역 라이브러리 또는 프레임워크를 사용할 경우 번역 가이드를 지원하는 것을 선택해야 한다. 또한 전 과정은 자동화가 되도록 해야 한다. 프로그래머가 영어 실력이 부족하여 번역 가이드와 영어 메시지를 문법에 맞고 자연스럽게 적는 것이 어려운 경우라면 개발 과정에서 이를 감수해서 수정해주는 프로세스를 적용해서 개발이 끝나고 번역을 위해서 메시지를 추출할 때는 소스코드에 제대된 영어 문장이 존재하게 하면 된다.
필자가 설명하는 하나하나의 과정은 소프트웨어 국제화 품질을 올려주는 과정이고 이런 것들이 모여서 소프트웨어가 해외에서 더욱 인정받는 길이 될 것이다. 아직 가야 할 길이 많이 남아 있다.
댓글을 남겨주세요
You must be logged in to post a comment.