소프트웨어 번역을 효율적으로 하는 방법 (23)

국제화 개발팀에서 근사한 번역함수를 만들어 준다고 해도 번역이 잘 되도록 번역함수를 사용하는 것이 쉬운 것은 아니다. 특히 주니어 개발자들이 소프트웨어 번역의 원리를 이해하지 못하고 번역함수를 잘못 사용해서 번역가가 아무리 번역을 잘해도 이상하게 되는 경우가 있다. 

그래서 번역이 효율적으로 되도록 하고 번역함수가 제대로 동작하게 하려면 어떻게 해야 하는지 알아보자.

1. 용어 사전을 만든다.

번역에 있어서 용어사전(Dictionary)를 만드는 것은 매우 중요한 활동이다. 잘 정리된 용어사전은 번역이 일관되게 하며 여러 번역가가 협업을 할 때 같은 용어를 사용할 수 있도록 한다. 

영어에는 같은 뜻이지만 다른 단어가 엄청나게 많다. 따라서 용어사전에는 해당 뜻일 경우 어떤 단어를 사용하라는 지침이 포함된다. 이렇게 영어를 기준으로 용어사전을 만들면 번역가들은 각 로케일별로 각각 용어 사전을 만들어 달라고 요청을 하는 것이 좋다. 여기서 언어별이 아니고 로케일별인 이유는 스페인의 스페인어와 멕시코의 스페인어의 용어사전이 다를 수 있기 때문이다.

이렇게 용어 사전을 만들어 놓으면 나중에 번역회사를 교체해도 일관된 번역을 유지하기 좋다. 

2. 번역의 기준이 되는 영어 문장은 최대한 간결하고 번역이 쉬운 용어를 사용한다.

소프트웨어는 문학작품이 아니고 문법 시험이 아니다. 소프트웨어에서 사용하는 용어는 소프트웨어를 이해할 수 있는 정도로 최대한 간결하고 번역이 쉬워야 한다. 올바른 문법을 주장하다가 문어체 문장으로 도배를 하면 오히려 어색한 경우도 많다. 

용어 선택도 주의를 해야 한다. "Hard"라는 단어보다는 "Difficult"가 좋다. 예를 들어 실생활에서는 "Hard"를 더 많이 쓴다고 하는 경우라도 번역에 오해가 없는 "Difficult"를 쓰는 것이 더 좋다. 

3. 대소문자 번역을 효율적으로 한다.

Open, OPEN, open을 각각 번역하면 3번 번역을 해야 하고 비용도 3배 더 나간다. 한국어로는 모두 "열기"다. 이런 경우 "open"하나만 번역을 하고 대소문자 변환 함수를 이용해서 변환하여 사용하는 것이 효율적이다. 대소문자를 처리하는 로케일 카테고리 표준은 LC_CTYP이다. LC_CTYPE의 영향을 받는 대소문자 변환 함수를 사용하면 로케일에 따라서 적절히 대소문자를 변환해준다.

C언어에서는 strlwr, strupr, wcslwr, wcsupr, stricmp, wcsicmp 등이 있다. 내가 바퀴를 다시 만들 필요는 없고 있는 함수를 쓰면 된다.

4. Broken sentence를 피한다.

대표적인 Broken sentence는 한 문장을 통째로 번역하지 않고 단어들을 쪼개서 합치는 것이다. 이렇게 쪼개진 단어들을 번역하기도 어려울 뿐만 아니라 어쨌든 번역을 해도 언어별로 어순이 달라서 이상한 문장이 되게 된다. "Leg of dog"을 쪼개서 번역하면 "다리의 개"가 될 수도 있다.

문장은 온전한 문장을 통째로 번역해야 하며 문장을 분리하는 기준은 각 언어의 특성을 어느 정도 알아야 효과적으로 정할 수 있다.

반대로 쪼개야할 문장을 하나로 연결해서 번역을 할 경우 번역해야 할메시지가 엄청나게 늘어나는 경우가 있다. 번역가는 이렇게 반복되는 패턴을 발견해도 이상 여부를 알리지 않고 기계적으로 번역하는 경우가 많다. 번역가는 오히려 이런 현상을 환영한다. 번역은 쉽고 수입은늘기 때문이다. 번역할 문장을 적당히 자르는 것은 개발자의 몫이다.

5. 메시지 표준을 정한다. 

보통 여러 개발자가 함께 소프트웨어를 개발하기 때문에 개발자들이 작성한 영어 문장이 서로 상당히 다른 경우가 있다. 용어사전이 있다고 하더라도 일관되게 사용하기는 쉽지 않다. 몇몇 회사는 소프트웨어에서 사용하는 모든 메시지를 전문팀에서 정해주곤 하는데 100% 커버하기는 쉽지 않다. 개발자가 문장을 결정해야 하는 경우도 많다. 이럴 때 지켜야 할 규칙을 정해야 한다.

예를 들어 문장의 끝에는 마침표를 찍을지 말지, Cannot을 쓸지 can’t를 쓸지? 등과 같은 사소한 규칙들의 집합일 수도 있다. 이런 표준은 발견될 때마다 조금씩 보강해나가면 된다.

6. 번역 제외 메시지 표시 함수를 정한다. 

가끔은 번역을 하면 안되는 메시지들이 있을 수 있다. 그런 메시지는 번역을 하지 않아도 되니 번역함수를 사용하지 않고 그냥 놔두는 경우가 있다. 이렇게 해도 소프트웨어는 문제없이 동작한다. 하지만 이 소스코드를 본 어떤 개발자가 번역함수가 누락된 것으로 착각을 하고 번역함수로 메시지를 감싸는 경우가 발생한다.

예를 들어 "IT"라는 단어가 소프트웨어에 있고 절대 번역을 하면 안되는데 이를 본 개발자가 번역함수("IT")로 바꿔놨다고 하자. 그러면 또 이 단어를 수십개의 언어로 번역을 해야 한다. 비용은 비용대로 들고 이 단어가 번역이 돼서 문제가 발생하기도 한다.

번역을 하면 안되는 단어는 화면에는 출력이 되지만 번역을 하면 안되는 경우와 화면에는 출력이 안되고 소프트웨어 내부적으로만 사용을 하는 경우가 있다. 소프트웨어 내부적으로 사용하는 단어를 번역해버리면 소프트웨어가 동작하지 않기도 한다. 또한 로그 등 번역을 할 필요가 없는 경우도 있다.

이런 일을 방지하기 위해서는 번역 제외 표시 함수를 사용하는 것이 좋다. 번역제외("IT") 이렇게 해놓으면 어느 누구도 실로 번역을 하게 만들지는 않는다. 물론 번역제외 함수는 아무 일도 하지 않고 원래 메시지 그대로 넘겨줄 뿐이다.

번역 제외 함수는 번역 라이브러리나 프레임워크에 따라서 다르며 지원하지 않는 경우도 있다. 이런 경우는 번역제외함수를 직접 만들어서사용하면 된다.

7. 번역가에게 번역가이드를 전달한다.

지난번에 얘기를 했듯이 메시지 별로 번역가에게 어떻게 번역을 해야 하는지 번역 가이드를 전달해야 한다.

8. 메시지 파일은 UTF-8으로 인코딩한다.

국제화가 잘된 소프트웨어는 멀티바이트보다 유니코드를 지원하도록 개발하는 것이 여러모로 편리하고 자잘한 문제도 적다. 번역가에게 메시지 파일을 보내서 번역을 요청할 때 최초의 파일은 ASCII 인코딩일 가능성이 높다. 메시지키가 영어이기 때문이다. 이때 번역가들은 자국의 인코딩을 이용해서 번역을 해 오는 경우가 종종 있다. 이때 UTF-8으로 인코딩을 해달라고 요청하는 것이 좋다. 이때 지난번에 언급했듯이 Windows의 Notepad를 이용하면 BOM이 따라 붙어서 낭패를 보는 경우가 가끔 있다. BOM이 없는 UTF-8 파일이 필요한 번역 함수를 사용하고 있다면 Notepad는 사용하지 말라고 가이드를 해야 한다.

소프트웨어 국제화를 오래 하다 보면 이런 여러가지 노하우가 쌓이게 된다. 이런 노하우를 꾸준히 쌓아가면서 회사의 자산이 되도록 해야 한다.