국제화 개발팀에서 근사한 번역함수를 만들어 준다고 해도 번역이 잘 되도록 번역함수를 사용하는 것이 쉬운 것은 아니다. 특히 주니어 개발자들이 소프트웨어 번역의 원리를 이해하지 못하고 번역함수를 잘못 사용해서 번역가가 아무리 번역을 잘해도 이상하게 되는 경우가 있다. 그래서 번역이 효율적으로 되도록 하고 번역함수가 제대로 동작하게 하려면 어떻게 해야 하는지 알아보자. 1. 용어 사전을 만든다. 번역에 있어서 용어사전(Dictionary)를
한국어로 번역된 소프트웨어를 쓰다 보면 코웃음이 나오는 정도로 어색하게 번역이 되는 경우를 종종 본다. 물론 전문 번역가를 활용하지 않고 구글번역기를 이용해서 번역을 할 경우는 웃기는 경우가 많이 벌어진다. 하지만 전문 번역가가 번역을 하더라도 제대로 번역이 안되는 경우가 많다. 예를 들어 "Pan"이라는 말을 번역하려고 한다. "Pan"이라는 단어를 전세계 수십 나라의 번역가에게 보내면 어떻게 번역을
소프트웨어 번역 시 흔히 경험하는 문제 중 하나는 언어별 어순이 다르다는 것이다. 예를 들어 "Leg of dog"라는 문장을 번역해야 한다고 하자. 관사가 빠져서 어색하지만 무시하자. 대소문자, 단수/복수 문제도 있지만 무시하자. 한국어로 변역 하면 "개의 다리"가 된다. 여기서 "Leg"는 "Eye", "Ear"로 대체가 가능하고 "dog"는 "cat", "cow"등 여러 동물로 바뀔 수 있다고 하자. 먼저 소프트웨어의 소스코드에서 아래와 같이 사용하면 번역 시 어순에서
이전 글에서 소프트웨어 번역 프로세스의 제 1원칙은 메시지 키는 영어 자체여야 한다고 했다. 즉, 번역의 기준은 영어여야 한다는 것이다. 현재 시중에 나와 있는 수많은 번역 함수들은 이 제 1원칙에 어긋나있다. 개발자들도 제 1원칙에 어긋난 수많은 방법을 이용해서 소프트웨어 번역을 하면서 수많은 문제가 봉착하고 있다. 대규모 프로젝트들이 MS개발툴, Java 등 널리 쓰이는 개발툴에서 제공하는 번역 함수들을 그대로 이용해서 번역을 하고 있다고 착각하고 있는 개발자들이 매우 많다. RC파일을 이용해서 메시지가 10,000개,지원하는 언어(로케일)가 30개인 프로젝트를 수행해 낼 수 있다고 착각한다. 할 수도 있겠지만 너무 비효율적이고 거의 불가능하다. 대부분의 대규모 프로젝트에서는 오픈소스 또는 내부에서 개발한 번역 함수와 자동화된 번역 프로세스를 통해서 해결하고 있다. 이를 위해서 매우 전문적인 소프트웨어 국제화 담당자들이 활약하고 있다. 우리나라에서도 대규모 프로젝트에서는 스스로 개발한 번역 함수와 번역 프로세스를 사용하곤 하지만 원칙에 어긋나거나 완전 자동화에 실패를 해서 빠져 나오기 어려운 문제에 봉착하곤 한다. 그럼 번역의 기준이 되는 메시지의 키는 어떤 것들이 있으며 영어가 아니면 왜 문제가 되는 것일까? 번역 함수에 “메시지 키”를 넘겨주면 “번역된 메시지”가 넘어 온다. 번역된 메시지 = 번역함수(메시지 키) "번역함수"에는 여러가지고 있고 물론 자동으로 번역을 해주는 함수가 아니고 번역가가 번역한 메시지를 소프트웨어서 보관하고 있다가 사용자가 사용하는 언어로 변경 해주는 함수를 말하는 것이다. 개발자들이 번역을 위해서 사용하는 메시지의 키는 대략 4가지 정도가 있다. 1. 숫자 2. 심볼 3. 한국어 4. 영어 첫 번째 숫자부터 알아보자. 번역의 기준을 숫자로 사용하는 방법은 매우 오래된 방법이다. 번역함수(1) => 사과 번역함수(2) => 딸기 이렇게 사용하는 방법이다. 이 방법의 문제점은 숫자를 잘 관리해야 한다는 점이다. 번역이 필요한 메시지를 새로 추가할 때 기존의 숫자들과 중복되지 않는 숫자를 찾아야 하고 삭제할 경우에는 해당 메시지가 더 이상 정말로 사용되지 않는지 면밀히 검토를 해야 한다. 이런 번거로운 절차를 자동화하는 툴들도 있지만 잘 동작하지 않는 경우가 많았다. 또한 숫자를 보고 바로 번역할 수 없으므로 영어 메시지를 전달해야 하고 영어 번역이 바뀌면 다른 언어도 번역을 변경해야 하는데 이를 관리하는 것이 너무 어렵다. 숫자를 기준으로 번역하는 것은 함수는 간단해 보이지만 관리가 너무 어려워서 이제는 거의 쓰이지 않는다. 두 번째 심볼을 쓰는 방법은 가장 널리 사용되고 있다. 번역함수(MSG_CLOSE) => 닫기 번역함수(BUTTON_OPEN) => 열기 이렇게 사용하는 방법이다. 이 방법은 숫자에 비하여 심볼을 보면 대충 무슨 의미인지 알 수 있어서 개발자들이 메시지 파일을 뒤지지 않고도 심볼을 기억해서 사용할 수도 있고 엉뚱한 메시지를 사용할 위험성이 줄어든다. 하지만 이 방법에도 치명적인 몇 가지 문제가 있다. 먼저 매번 새로운 메시지가 추가될 때마다 심볼을 정해야 한다. 이때 다른 동료와 동시에 같은 심볼을 정해서 충돌이 날 수도 있고, 기존에 사용된 심볼을 없는 줄 알고 다시 쓰는 문제도 발생할 수 있다. 이 또한 삭제할 메시지를 정하는 것이 매우 어렵다. 실수로 삭제하는 위험성 때문에 삭제는 영원히 안하는 회사도 있다. 그러면 새로 지원하는 언어가 늘어 날 때마다 사용도 안하는 메시지를 번역하는 일도 생긴다. 번역가에게는 영문 메시지파일을 전달해서 여러 언어로 번역을 요청하지만 나중에 영어가 바뀌면 바뀐 메시지만 다시 각 언어별로 번역을 요청하는 것이 너무 어렵다. 바뀐 영어 메시지를 찾고 관리하는 것도 어렵지만 번역가에게 몇 개의 메시지만 번역을 변경해달라고 요청하기도 힘들다. 어떤 소프트웨어가 v1.0에서 3,000개의 메시지를 번역했다고 하자. 그런데 v1.1에서 500개의 메시지가 삭제되고 500개는 영어 메시지가 수정되었고, 1,000개의 메시지가 추가되어서 최종 3,500개의 메시지가 되었다고 하자. 그럼 번역가에게는 1,000개는 새로 번역을 요청하고 500개는 번역 수정을 요청해야 한다. 어떤 메시지가 수정할 메시지이고, 삭제될 메시지, 추가된 메시지를 버전 별로 관리하고, 번역가에게 보내고, 번역된 메시지를 메시지 파일과 통합하는 일련의 프로세스가 얼마나 복잡한지 대규모 프로젝트의 번역 프로세스를 담당해본 개발자라면 잘 알 것이다 이런 과정에서 문제가 없이 번역 프로세스를 처리하는 것은 거의 불가능하며 수많은 버그를 포함하게 된다. 번역이 누락된 경우 “MSG_CLOSE”와 같은 심볼이 출력되기도 한다. 메시지 키에 심볼을 사용하는 이상 이런 복잡한 프로세스를 피해가기 어렵다.세 번째는 한국어를 메시지 키로 사용하는 방법이다. 번역함수(닫기) => Close 번역함수(열기) => Open 이 방법은 먼저 영어로 번역을 한 후에 다른 언어로 번역을 해야 하기 때문에 번역 프로세스가 더 오래 걸린다. 그렇게 널리 쓰이는 방법은 아니다.이 방법이 좋다고 생각하는 경우 한국어에서 영어, 한국어에서 일본어와 같이 우리와 친숙한 언어들을 위주로 지원하고 한국어를 잘아는 번역가를 활용을 하기 때문이다. 이렇게 한국어를 기준으로 변역해도 별 문제가 없는 경우도 있지만 대부분의 번역가는 영어와 해당언어의 전문가들이다. 한국어는 그 중에 하나의 언어인 경우가 많다.
개발자들이 소프트웨어를 개발하면서 가끔 하는 실수 중 하나가 현지 시간을 저장했다가 나중에 소프트웨어가 확장되면서 꼬이는 것이다. 보통의 소프트웨어라면 시간에 그렇게 민감하지 않다. 하지만 일정관리, 항공권 예약, 배송 시스템 등 시간에 민감한 소프트웨어들이 있다. 이 외에도 시간을 신경 써서 다뤄야 하는 소프트웨어가 많다. 이런 소프트웨어에서 시간의 기록과 처리를 현지 시간을 기준으로 처리를 하다가는 문제가 발생하고 꼬이게 된다.
소프트웨어를 국제화하려면 수많은 요소를 국제화해야 하지만 그 중에서 절대 빠지지 않는 부분이 번역이다. 또한 가장 중요하면서 어렵다. 필자가 얘기하는 주제는 번역 그 자체를 제외한 번역을 위한 모든 활동을 말한다. 소스코드에서는 어떠한 함수를 사용하고, 메시지는 어떻게 추출해서 어디에 저장하고 번역가에게는 어떻게 보내고, 번역된 메시지는 소프트웨어에서 어떻게 읽어 들여서 출력할 것인지에 대한 아키텍처와 프로세스 전반을 말하는 것이다.
앞으로 번역에 대해서 다룰 여러 주제 중에서 오늘은 단수/복수에 대해서 알아보자. 국제화/지역화가 잘 된 소프트웨어라고 하더라도 단수/복수를 제대로 처리하고 있는 소프트웨어는 찾아보기 쉽지 않다. 우리는 단수/복수에 대한 구분을 하지 않는 언어를 사용하고 있다. 그래서 단수/복수 처리에 대해서 민감하지 않다. 하지만 단수/복수를 구분하는 언어권에서는 이를 제대로 처리하지 않으면 어색한 표현이 된다. 물론 의미는 알아보겠지만 그만큼 소프트웨어의 품질은
이제부터 소프트웨어 국제화에서 가장 중요한 번역과 관련된 얘기를 시작하려고 한다. 번역은 다뤄야 할 주제가 광범위하므로 여러 회차를 거쳐서 다루게 될 것이다. 필자는 수십 개의 회사의 소프트웨어 국제화 방식을 조사했으며 대부분의 회사가 수많은 번역 함정에 빠져서 어려움을 겪고 있는 것을 보았다. “변역 함정”이란 소프트웨어를 번역하면서 비효율적인 방법에 쉽게 빠져서 허우적거리는 것을 말한다. 번창한 회사일수록 어려움은 더 커졌다. 그래서
미국에서 미터법을 잘 쓰지 않듯이 국제 표준이 있는데 자국만의 표준을 고집하는 나라들이 있다. 우리가 모든 나라의 문화를 다 이해하지 못하는 상황에서 이를 비난 해서는 안된다. 다만 소프트웨어를 개발하는데 엄청 번거로울 뿐이다. 날짜에서도 전세계 대부분의 나라가 그레고리력을 사용하는데 그레고리력을 사용하지 않는 몇몇 나라가 있다. 물론 그레고리력과 혼용을 하기도 한다. 게다가 달력은 로케일 표준 카테고리에 해당하지 않기 때문에 대부분의 개발툴이나
지난 12회에서 국가별, 로케일별로 날짜 표기 형식이 매우 다르다는 것을 보았다. 하지만 이런 방식을 따르기만 한다고 해서 날짜 표기 형식 문제가 모두 해결되는 것은 아니다. 시스템에서 제공하는 날짜 표기 형식이 실제로 해당 국가에서 오류라고 생각할 수도 있고, 입력 시 사용자의 실수로 인한 혼동도 무시 못한다. 그래서 국제화가 잘 된 소프트웨어에서는 날짜 형식에 대해서 조금 더