저는 윈폼은 다루지 않지만, 가능한 한 모든 UI 앱을 한국어-영어로 만드는 편입니다.
이 것이 가능한 이유는 IStringLocalizer 라는 든든한 도구가 있기 때문입니다.
이 인터페이스의 구현 객체는 서비스 컨테이너에서 제공하는 것이라, 윈폼에서는 사용할 수 없을 것입니다.
윈폼의 지역화와 다른 도구를 사용했지만, 지역화를 하면서 느낀 점을 공유해드리겠습니다.
- 자원 파일 관리는 어렵다.
지역화 자원을 관리하는 것 자체가 쉬운 일은 아닙니다.
뷰 마다 지역화 파일을 만들어 보기도 하고, 전역적인 파일을 만들어 보기도 하고, 도메인 클래스 마다 지역화 파일을 만들기도 해봤지만, 방법 별로 큰 차이는 없었습니다.
- 짧은 문장보다는 긴 문장
한국어와 번역어 사이에 문자열 길이에 차이가 있기 마련입니다. 근데, 이 차이가 디자인 확정을 어렵게 합니다. 그래서 가급적 문자열을 길이를 맞추도록 노력했습니다. 예를 들어,
한: “삭제되면 복구할 수 없습니다.”
영: “Items will not be recoverable.”
추가:
이러한 길이 맞춤도, 외국어 폰트가 모노 스페이스(모든 문자의 폭이 같음)일 때 의미가 있지, 아니라면 부질없습니다.
그런데, 보통 위와 같은 짧은 문장은 길이를 맞추는 게 힘듭니다.
맞춘다 하더라도, 한국어든 번역어든 표현이 쉽게 어색해집니다.
또한, 이 허접한 결과를 위해, 투입되어야 하는 시간도 만만치 않습니다.
그래서, 메시지는 가급적 긴 문장으로 상정하고, 이를 위해 디자인도 넉넉히 고려하거나, 디자인과 무관한 시스템 메시지 박스를 적극 사용했습니다.
- 아이콘 + 툴팁.
콘트롤에 문자열을 입히는 것보다, 아이콘을 쓰는 것이 디자인 통일 측면에서 유리합니다.
설명이 필요한 경우, 콘트롤에 툴팁을 부여하고, 툴팁 메시지를 지역화 하는 것이죠.
VS 도 보시면, 생각보다 많은 툴팁을 적용하고 있음을 아실 것입니다.
문제는 아이콘은 개발 업무가 아니라 디자이너의 업무라는 점이죠.
디자이너가 없다면 아이콘 동냥 많이 다녀야 합니다.
- 개발 비용
보시면 아시겠지만, 지역화는 적지 않은 추가 업무를 유발합니다.
제 생각에는 지역화를 하겠다고 결정했으면, 반드시 추가 인력이 투입되어야 할 것 같습니다.
어설프게 했다간 디자인이 망가져 촌티가 나거나, 문자열 문제로 개발 기간이 굉장히 길어지거나, 미완성인 채로 출시하거나…
예산의 추가 투입이 없으면, 지역화가 독으로 작용할 수 있습니다.