Software Localization, Done Properly
It's much more than simple translation.
해외 진출을 목표로 하고 있다면, 소프트웨어 제품 내의 정확한 영어 표현이 매우 중요합니다.
소스코드를 볼 수 없을 경우 소프트웨어의 질을 평가할 수가 없기 때문에 인터페이스를 바탕으로 소프트웨어의 질을 평가하게 됩니다.
아무리 좋은 제품이라고 할지라도 인터페이스가 어색하고 부정확한 표현(Expressions)들로 가득 차 있다면 전문적으로 보이지 않을 뿐만 아니라 제품의 질을 낮게 평가하는 결과를 초래합니다. 더욱이 부정확한 영어 표현은 사용자들을 혼동시키고 사용자들로 하여금 부정적 인식을 갖게 합니다.
Proper software localization is not just for UI/UX designers.
소프트웨어의 질을 평가할 때 영어의 효과는 단순히 CUI에만 국한된 것이 아닙니다. 에러 메시지, 기타 여러 가지 메시지, 그리고 API (Application Programming Interface)를 통해 엔드 유저, 개발자, 혹은 SI (Systems Integrators)에게 보여지는 객체와 프로퍼티 이름 등등 이 모든 것이 부정확한 영어 사용에 영향을 받으며 결과적으로 제품에 대한 부정적인 인상을 심어주게 됩니다.
여러 가지 언어로 제품을 제공하고자 한다면 상황은 더 복잡해 질 것입니다.
다국어로 된 제품의 현지화를 위한 일반적인 프로세스는 매우 단순합니다. 보통, 엔드유저에게 보이는 모든 언어는 소스코드로부터 분리되어 있고, “resource file”(리소스 파일) 혹은 “string table”이라고 불리는 파일에 들어있습니다. 파일은 “key-value pairs”(키-값의 쌍)의 형식을 가지고 있는데 아래와 같이 각각 “=” 부호를 이용해 키와 값이 쌍을 이루고 있습니다.
이 리소스 파일은 일반 번역 업체에 보내지고 각 “키-값의 쌍”에서 “값”을 번역한 결과물은 다음과 같습니다
번역 업체는 영어 소스파일 결과물을 소프트웨어 회사에 보내고 해당 회사는 한국어 원본 리소스 파일 대신 번역본을 사용하게 됩니다. 소프트웨어 회사는 소프트웨어의 모든 한글이 영어로 번역되어 있어 만족해 할 수도 있습니다. 하지만 이렇게 번역된 소프트웨어는 문법적 오류와 어색하고 불분명한 의미의 표현들로 가득 차 있을 뿐입니다.
Where Korean Software Companies Get It Wrong
위 과정에서 한국의 중소 소프트웨어 기업들은 다음과 같은 실수를 범합니다.
- IT 분야에 전문성이 없는 번역업체에 리소스 파일 번역을 요청한다.
- 번역 업체가 IT 자료 번역 경험이 있다고 하더라도 해당 소프트웨어 회사는 번역자에게 개발자에 대한 접근성이나 문맥상의 이해를 도울만한 추가적인 정보를 제공하지 않는다.
- 소프트웨어 개발자들과 번역자들은 잠재적 추가 비용이나 문제들을 제기할 인적 시간에 대한 예산을 세우지 않는다.
One Example of What Can Go Wrong: Singular vs. Plural
리소스 파일에서 예를 들어 보겠습니다.
위의 예에서 "{0}" 은 당연히 실제 메시지 개수를 런타임 때 표시 하는 것입니다.
새로운메시지 2개 있습니다.
새로운메시지 3개 있습니다.
번역업체에서는 아래와 같이 번역하여 보냅니다.
이 의미는 아래와 같이 소프트웨어가 아웃풋을 낸다는 뜻입니다.
You have 2 new message.
You have 3 new message.
당연히 아웃풋은 “2 message” 가 아닌 “2 messages”가 되어야 합니다. 하지만 아래와 같은 아웃풋이 생기기 때문에 단지 “s”를 “message”에 붙인다고 해서 이 문제가 해결 되는 것은 아닙니다.
그러므로 2개 이상의 메시지를 처리하기 위해 추가적인 키를 만들어야 하는 필요성이 생기게 됩니다. 이런 문제들을 파악하고 수정하기 위해서 개발자와의 직접적인 커뮤니케이션이 필요하게 되는 것입니다.
Another Example: Word Order
또 다른 예로 시간을 표시하는 경우를 살펴보겠습니다.
이 경우 리소스 파일은 아래와 같은 키-값의 쌍을 포함 할 수 있습니다.
minute=분
영어로 번역하면 아래와 같습니다.
minute=minute
번역된 리소스파일이 소스코드와 결합되면 유저에게는 아래와 같이 보여집니다
실제로는 이렇게 보여져야 합니다
자바와 같은 개발 환경은 날짜나 시간과 관련되어 흔히 발생할 수 있는 현지화 문제들을 처리할 라이브러리와 도구들을 제공합니다. 가능하다면 그런 것들을 이용하기를 권합니다.
Example 3: Word Forms and UI Elements
리소스파일에서 아래와 같은 경우를 살펴보겠습니다.
일반 번역자에 의해 영어로 번역된 경우 결과는 아래와 같을 수 있습니다.
직접적으로 UI를 보지 않고 개발자와 상의 하지 않고는 IT 경험이 있는 원어민 번역자에게 번역 업무를 맡긴다 하더라도 번역자는 아래 중에서 어떤 것이 적합한지 알지 못할 것입니다.
approval=approval
approval=approved
이 중에서 어떤 것이 적합한 표현인지 판단하기 위해서 번역자는 UI를 직접 보고 설명을 들어야 합니다. 아래 표에서처럼 요청 상태의 표시를 위해 표에 나타나는 단어의 경우들을 살펴보겠습니다.
| 상태 | ||
|---|---|---|
| 승인 | ||
| 거부 | ||
| 승인 |
이 경우에는 “Approved” 와 “Denied” 가 적합합니다.
| Status | ||
|---|---|---|
| approved | ||
| denied | ||
| approved |
이제 요청을 어떻게 처리 할지 선택하기 위해 사용된 버튼에서 단어가 보여지는 경우를 살펴 봅시다.
여기서, “Approve” (그리고 “Deny”)가 정확한 번역이 될 것 입니다.
The Solution: A Meaningful Investment
위의 설명된 문제와 같은 것을 극복하기 위해 아래와 같은 투자가 필요 할 것 입니다.
- 번역자는 당신의 소프트웨어를 직접적으로 보고 이해해야 할 것 입니다.
- 당신은 리소스파일에 추가적인 키-값의 쌍을 포함해야 할 것 입니다.
- 어순의 문제를 해결 하기 위해 코드를 분리해야 할 것입니다.
Don't confuse localization with simple translation.
현지화는 단순번역과는 다릅니다. 만약 리소스 파일의 번역을 일반 번역업체에 요청한다면 번역업체에서는 단어 수를 바탕으로 산출한 견적서를 보냅니다. 해당 견적서의 비용은 일반 서류 번역비용 보다 저렴할 수밖에 없는데 이는 리소스파일의 단어 수는 일반 서류에 비해 적기 때문입니다. 하지만 이 저렴한 비용은 현지 고객의 외면과 신뢰성 저하로 이어지기 마련입니다. 소프트웨어 현지화란 ‘개발자와의 지속적인 피드백’이 가장 우선시되어야 하며 이렇게 투자된 시간과 노력이 최상의 결과를 만들어냅니다. 조악한 영어 번역으로 훌륭한 제품이 세계의 모든 유저들에게 보여지고 사용될 기회를 잃어버려서는 안될 것입니다.
