언어마다 다른 순서를 소프트웨어에 적용하는 방법 (21)

소프트웨어 번역 시 흔히 경험하는 문제 중 하나는 언어별 어순이 다르다는 것이다.

예를 들어 "Leg of dog"라는 문장을 번역해야 한다고 하자. 관사가 빠져서 어색하지만 무시하자. 대소문자, 단수/복수 문제도 있지만 무시하자. 한국어로 변역 하면 "개의 다리"가 된다. 여기서 "Leg"는 "Eye", "Ear"로 대체가 가능하고 "dog"는 "cat", "cow"등 여러 동물로 바뀔 수 있다고 하자.

먼저 소프트웨어의 소스코드에서 아래와 같이 사용하면 번역 시 어순에서 문제가 발생한다.

번역함수("Leg") + 번역함수(" of ") + 번역함수("dog")

이런 경우 " of "는 각 언어의 번역가들이 어떻게 번역을 할 수 있을까? 번역이 불가능하다. 이런 식으로 문장으로 작은 단위로 쪼개서 조합한 문장을 쪼개진 문장(Broken sentence)이라고 부르고 국제화된 소프트웨어를 개발할 때는 중요한 금기사항이다. 쪼개진 문장(Broken sentence)의 처리 방법에 대해서는 추후 좀더 자세히 알아보자.

" of "를 "의 "로 번역한다고 해도 "다리의 개"가 된다. 또한 "눈의 소", "귀의 고양이"가 된다.

문장은 온전하게 한 문장으로 이루어져 있어야 제대로 번역이 가능하다. 그래서 보통 마침표를 기준으로 문장을 나누고 ":"나 ";’로 문장을 나누기도 한다. ","로 문장을 나누는 것은 보통 위험하다.

따라서 위 "Leg of dog"은 소프트웨어에서 아래와 같이 코딩을 해야 한다.

StringFormat함수(번역함수("%1 of %2"), 번역함수("Leg"), 번역함수("dog"))

그래서 "%1 of %2", "Leg", "dog" 각각 따로 변역을 해서 조합하게 된다.

이 문장을 한국어로 번역하면 "%2의 %1", "다리", "개"가 된다.

조합하면 "개의 다리"가 된다. 또한 "소의 눈", "고양이의 귀" 이렇게 번역이 될 수 있다.

StringFormat함수는 개발 언어별로 프레임워크나 라이브러리 별로 다르다. 대표적으로 C언어의 sprintf 함수를 사용하면 다음과 같이 쓰면 된다.

sprintf(번역함수("%1$s of %2$s"), 번역함수("Leg"), 번역함수("dog"))

sprintf에서 인자를 받는 기호는 %d, %s 등이 있는데 여기에 $ 표시를 추가하면 순서를 지정할 수 있게 된다. 대부분의 개발툴이나 라이브러리 별로 각각 파라미터의 순서를 조절할 수 있는 포맷 지원 문자열 처리 함수들이 있으니 적절하게 사용하면 된다. 만약에 현재 개발 환경에서 그런 함수를 지원하는 않는다면 직접 만들거나 외부 라이브러리를 사용해야 한다. 오픈소스 중에도 이런 함수가 있으니 필요 시 사용할 수 있다.

"Error code : 1234"를 번역하기 위해서 아래 두 가지 방법이 있다.

첫 번째, StringFormat함수(번역함수("Error code : %1"), 1234)

두 번째, 번역함수("Error code") + " : " + 1234

둘 다 큰 무리는 없지만 첫 번째 방법이 좀더 안전하다. 우리는 "에러코드 : 1234"와 같은 순서를 자연스럽게 생각하지만 어떤 다른 언어에서 순서가 뒤바뀌는 것이 더 나은지는 전혀 알 수 없다. 또한 두 단어를 구분하기 위해서 ":"를 쓸지 다른 기호를 쓸지는 모르는 것이다.설령 우리가 지원하는 모든 언어에서 이런 변수가 없다고 하더라도 일단 안전하게 첫 번째 방법을 선택하는 것이 더 좋다.

100%, 120m 등을 번역하는 것도 동일하게 StringFormat함수(번역함수("%dm"), 120)과 같이 쓰는 것이 조금 더 안전하다. 전세계 어떤 언어에서 %와 m도 번역을 해야 하는지는 알기 어렵다. 한두개의 언어를 안다고 해도 모든 언어를 알 수는 없다. 제대로 번역하는 것은 번역가의 몫이고 개발자는 제대로 번역이 가능하도록 코딩을 해야 한다. 물론 영어, 한국어, 독일어 정도 지원하는 경우라면 어떻게 해도 아무 문제가 없다. 소프트웨어 판매 전략에 따라서 미래에 문제가 될 수도 있고 안될 수도 있다. 당장 문제가 안된다고 이런 것까지 언급하느냐고 불평을 하지 말고 원리는 알고 넘어가고 판단은 스스로 하면 된다.

국제화가 잘 된 소프트웨어를 개발하려면 문장의 모든 단어가 과연 우리의 상식으로 이해되는 순서로 배열이 될지 의심을 해봐야 한다. 만약에 의심이 된다면 안전한 방법을 선택하는 것이 좋다. 미래에 내가 만든 소프트웨어가 지금보다 10배, 100배 커지고 전세계 수백개의 나라에서 판매를 할지 그렇지 않을지는 모르는 것이다. 당장은 아니라도 10년 후에 그런 기회가 나에게 찾아 올 수 있다. 그 때를 위해서 필자가 설명하는 원칙과 원리를 이해해보자. 물론 당장도 이익이기는 하지만 이익이 눈에 띄게 보이지는 않을 수도 있다.