로컬라이징 팁

프로그래밍 일반에 관한 포럼입니다.

운영자: 류광

Locked
사용자 아바타
kotonoha
전체글: 69
가입일: 2009-05-22 16:29

로컬라이징 팁

전체글 글쓴이: kotonoha » 2009-06-16 23:08

1. 만약에 가능하다면 스스코드는 utf-8 로 저장한다.
utf-8 이 아니면 한글로 적은 주석이 Ansi code 페이지 바꾸는순간 깨져서 보인다.

2. UI 메시지 출력을 위해서라면 sprintf 를 사용하지 않는다.
어순문제가 해결되는 FormatMessage 를 사용한다.

3. 영어는 프로토스 종족까지도 사용하는 우주공통 언어이지만
불행하게도 OK,Cancel,Yes,NO 가 뭔지 모르는 국가도 있다.
이런 국가에서는 OK,Cancel,Yes,No 까지 모두 번역해달라고 한다.)

4. 처음부터 번역이 힘든 표현은 쓰지 않는다.
예를들어서 "하얀꽃 고이접어 나빌레라" 라는 문장은 한국어로는 적합하지만
영어나 다른 언어로 번역할 방법이 없다.
물론 기획자는 이러한 생각에 매우 반대할수 있지만
해외런칭시 유저는 원작이 어떻게 되어있는지는 모른다.
오직 번역된 컨텐츠만이 유저들이 보는 전부이다.

5. 모든 폰트는 획수가 많은 한문도 충분하게 출력할수 있도록 넉넉하게 잡는다.
竊癤 齉 과 같은 한문도 안티알리어싱이 먹은 상태에서 식별할수 있을정도의 크기가 되어야 한다.
볼드 : 竊癤 齉
노멀 : 竊癤 齉
볼드처리될경우 획이 많은 글자는 잘 안보인다.

6. 번역을 통해서 단어 및 문장의 경우 1.5 배 최대 2배까지 증가할수 있다.
UI 레이아웃은 번역에 대비하여 약간의 여분이 있는것이 좋다.
물론 기획자와 디자이너가 규격에 딱딱 맞는 디자인을 좋아한다면 어쩔수 없다.
(딱딱 맞는 단정한 레이아웃을 추구하다가 해외런칭시 후회할수도 있다.)

7. 게임내에서 음성사용을 자제한다.
이는 비용상의 문제이다. 예를들어서
리니지2 에서 여엘프가 마법을 쓰면 다음과 같이 말한다.
"히야라 바~~ 마~~ 하~~~ 캼온~~"
무슨 말인지는 모르겠지만 남휴먼 법사는 마법쓰면 다음과 같이 말한다.
"하메하메하메~~ 챠파~~"

도데체 어느나라말인지 모르겠다. 그래서 주파수 특성이 좋아서, 나쁘게 들리지는 않지만,
이러한 리니지2 의 마법주문 선택은 로컬라이징에 있어서는 GREAT 한 판단이다.
만약에 특정언어(한국어,영어,중국어,일본어) 로 주문을 말했을경우
출시하는 국가마다 모두 비싼 성우 구입해서 더빙해야 했을것이다.
(성우 채용 비용 생각보다 비싸다.)

8. 아이템 이름을 일정하게 짓는다.
장검이라는 아이템이 있고 "롱소드" 라는 아이템이 있었는데,
영어로 번역하니 아이템 이름이 똑같아져서 결국 이름을 바꾸었다는 슬픈사연이 있다.
물론 아이템이름짓는것도 힘들다는 기획자들에게는 할말이 없다.

9. 정치적으로 민감한 소재는 피한다.
특정 국가에서는 판매금지될수도 있다.

10. 특정 기념일 명절 이벤트를 할경우 세계공통 이벤트 혹은
가장 많은 인원이 수혜를 입는 이벤트부터 만든다.
예를들어서 1월 1일(새해 인류공통), 12월 25일 과 같은것들이다.

11. 게임내 모든 특별행사는 게임내의 세계관에 근거하는것이 좋다.
만약에 어린이날,광복절,설날 이벤트를 할경우 모든 데이터는
하드코딩되어서는 안된다. 한마디로 데이터 바꿔서 크리스마스 이벤트로
변신할수 있어야 한다.

12. char 는 악의 세력이며 wchar_t 만이 진리일뿐이다.
만약에 가능하다면 char 를 못쓰도록 막는것도 좋은 방법이다.

13. 국가별로 따로가는 컨텐츠를 최대한 줄여야 하지만
이를 위해서는 처음 기획단계에서 모든 인류가 공감할만한 세계관을 다루는것이 좋다.
하지만 기획자의 생각은 많이 다를수 있다.

14. 폰트시스템 구축시 글자단위로 폰트그림(글리프) 를 캐슁하지 않는다.
이는 MSDN 에서도 나오는 말인데, 글자단위 캐슁이 힘든 인도어,태국어,아랍어 때문이다.
아랍어의 경우 같은 유니코드라고 해도 문액에 따라서 형태가 변하며
태국어는 n 개의 유니코드가 모여서 하나의 글자를 만든다.
유니코드를 글리프로 전환한뒤에 이 글리프를 캐슁해야 한다.

15. 로컬라이징은 번역이 아니다.
로컬라이징은 번역이 아니다. 로컬라이징의 대상은 게임 전체 데이터이다.
실제로 텍스트는 로컬라이징 업무시간중 극히 일부분이다.



그리고 가장 중요한것이 있다면.

16. 반드시 한국에서 성공해야 한다. 한국에서 성공한게임이 해외에서도 뜬다.
물론 한국에서 망했지만 해외에서 뜬 게임도 있지만, 극소수이다.

한국에서 망해도 해외가 있겠지? 라는 마음가짐으로는 절대 해외에서 성공할수 있다.
수많은 과거사례는 결국

한국에서 성공한 게임만이 해외에서 성공한다는것을 보여준다.

sanybyme
전체글: 157
가입일: 2007-11-30 09:26
연락처:

전체글 글쓴이: sanybyme » 2009-06-17 11:10

생각할게 정말 많군요.
좋은 글 잘 읽었습니다.

비회원

전체글 글쓴이: 비회원 » 2009-06-17 17:15

많은 노하우가 묻어나오는 글이군요

감사합니다.

gorekun
전체글: 15
가입일: 2007-01-05 20:28
연락처:

Re: 로컬라이징 팁

전체글 글쓴이: gorekun » 2009-06-17 17:15

kotonoha 작성:2. UI 메시지 출력을 위해서라면 sprintf 를 사용하지 않는다.
어순문제가 해결되는 FormatMessage 를 사용한다.

6. 번역을 통해서 단어 및 문장의 경우 1.5 배 최대 2배까지 증가할수 있다.
UI 레이아웃은 번역에 대비하여 약간의 여분이 있는것이 좋다.
물론 기획자와 디자이너가 규격에 딱딱 맞는 디자인을 좋아한다면 어쩔수 없다.
(딱딱 맞는 단정한 레이아웃을 추구하다가 해외런칭시 후회할수도 있다.)

12. char 는 악의 세력이며 wchar_t 만이 진리일뿐이다.
만약에 가능하다면 char 를 못쓰도록 막는것도 좋은 방법이다.
이 세 가지는 정말 진리입니다. 2번 관련해서 어순 문제를 해결하기 위해서는 Boost의 Format을 사용하는 방법도 있습니다. 6번 문제의 경우 레이아웃 기능을 제작할 때는 어느 정도 SMART하게 크기 조정 및 정렬이 가능한 기능을 만들 필요가 있죠.

12번 관련해서, 저 같은 경우는 아예 char나 std::string을 안 씁니다. TCHAR / std::basic_string<TCHAR>를 애용합니다. 좀 과격하지만, 문자열에 char 따위를 쓴 코드는 당장 폐기당해도 할 말 없다고 생각합니다.

마지막으로 무조건 국내에서 성공하라는 데 캐공감. 해외에서 뜬 다음 컴백한 건 오디션 정도로 알고 있습니다.

비회원

전체글 글쓴이: 비회원 » 2009-06-17 23:13

저는 char를 사용하지만 DB, XML, CSV등의 텍스트 데이터를 모두 UTF-8로 쓰고 있습니다.
윈도우 플랫폼만 생각한다면 wchar_t로 모두 통일해버리면 되지만,
wchar_t는 구현에 따라 2또는 4바이트일 수 있고, 엔디안 문제도 있어서...

비회원

전체글 글쓴이: 비회원 » 2009-06-18 01:25

궁금한게 있습니다

유니코드로 쓰이는곳에만 wchat_t 형으로 변환해서 쓰면 안되는지요?


예를 들면 제 경우, CustomUI 같이 유니코드 쓰는 라이브러리는 유니코드로 컴파일하고
데이터를 넘겨줄때 char를 wchar_t 형으로 변환해 넘겨주고
받아올때 wchat_t 를 char로 변환해서 가져오는 방식을 취합니다


그리고 루아나 그외 많은 라이브러리들이 유니코드를 지원안하는것으로 알고 있습니다
결국 멀티바이트와 유니코드는 상존할수 밖에 없지 않나요?

오히려 char <-> wchat_t 변환해서 쓰는게 더 유용하지 않나 싶은데 어떻게 생각하시는지요?

사용자 아바타
kotonoha
전체글: 69
가입일: 2009-05-22 16:29

전체글 글쓴이: kotonoha » 2009-06-18 08:48

wchar_t -> char -> wchar_t 로 변환한 결과가 반드시
똑같지 않기 때문입니다.
유니코드상에 아랍어/태국어/중국어/한국어/일본어/India 를 밀어넣고
wchar_t -> char 로 변환할경우 해당 운영체제의 안시 로케일에서
표현 못하는 문자는 ?? 로 변하게 됩니다.
char -> wchar_t 의 경우 그래도 wchar_t 보다는 약간 사정이 나은 편입니다.

저의 경우 루아에 "안녕하세요" 라는 문장을 통째로 넣기 보다는
xml 테이블에 "안녕하세요" 라는 문장을 넣고 lua 에서는 "안녕하세요" 라는 문장의 인덱스를 반환하는 방식을 사용했습니다.

유니코드를 지원 안하는 라이브러리의 경우 언어 의존적인 부분은
사용하지 않고는 방식으로 최대한 사용했씁니다.

char -> wchar_t 의 경우 어디까지나 임시방편적인 측면이 많습니다.
여러가지 언어가 동시에 표기되기 위해서는 결국 char->wchar_t 자체가
문제가 될수 있습니다.

zupet
전체글: 2764
가입일: 2003-05-13 03:34
사는 곳: NCSOFT LE팀

전체글 글쓴이: zupet » 2009-06-18 09:22

kotonoha 작성:유니코드상에 아랍어/태국어/중국어/한국어/일본어/India 를 밀어넣고
wchar_t -> char 로 변환할경우 해당 운영체제의 안시 로케일에서
표현 못하는 문자는 ?? 로 변하게 됩니다.
제 경우 Locale 을 시스템에 맡기지 않고 g_codePage 라는 전역 변수를 하나 선언해서 이 값으로 돌려쓰도록 했습니다. 물론 한 프로그램에서 다국어를 다 처리할때는 ??가 뜨게 되지만 대부분은 1개 언어만 쓰기 때문에 ini 파일등에서 적절한 code page 값을 지정해주고 초기화때 셋팅해주면 OS 언어에 관계없이 잘 돌아갔습니다.

문제가 있다면 해당 언어팩이 깔려 있어야 하고(정확히는 *.nls 파일) 대만의 경우 몇몇 한자가 ANSI 호환 체계에서 입력이 안되었다는 점입니다. 저도 wchar_t 가 다국어에 적절한 대안이라고 생각되지만 ANSI 호환 체계 만으로 짰을때 해결되는 문제가 있는가 하면 그 반대로 추가 발생하는 문제가 있기 때문에 그때그때 적절한 것을 고르는게 답이라고 생각합니다.
kotonoha 작성:유니코드를 지원 안하는 라이브러리의 경우 언어 의존적인 부분은
사용하지 않고는 방식으로 최대한 사용했씁니다.
해결책으로 UTF-8 이 있습니다. ANSI 호환모드에 맞춰서 짜여진 라이브러리들에 잘 돌아가도록 만들어진 코드 체계인 만큼 호환성은 매우 좋습니다. 문제가 있다면 '문자수'를 세는데 약간 애로사항이 있다는 것인데 뭐 이 부분만 조심하면 대부분의 경우 매우 잘 작동합니다. 문자수를 세는 것도 사실 간단하긴 한데 char text[32] 식으로 고정하면 안되는게 조금 귀찮죠.
kotonoha 작성:char -> wchar_t 의 경우 어디까지나 임시방편적인 측면이 많습니다.
여러가지 언어가 동시에 표기되기 위해서는 결국 char->wchar_t 자체가
문제가 될수 있습니다.
wchar_t 만으로 해결이 안되는 문제가 있는데 바로 '폰트' 문제입니다. MSN 메신저에서 한글/영어를 섞어서 타이핑 하다보면 [ , ] 브라켓의 좌-우 크기가 틀리던지 일본어를 입력하는데 몇몇 한자들이 쪼그라들어서 보기 싫게 나오는 경우가 있죠.

이것은 각각 언어에 따라 폰트가 다르기 때문에 생기는 문제입니다. 특히 언어별로 다른 폰트를 쓰게 되면 특수 문자, baseline, 폰트 크기등이 전부 달라지게 되는데 wchar_t 정보만으로는 언어를 구별할 수 없기 때문에 윈도우 폰트 시스템은 문자를 출력하던중 자신의 폰트에 없는 언어가 나오면 자동적으로 해당 언어 폰트를 찾아서 찍어지구 때문에 발생하는 문제죠. 프로그래밍 적인 부분은 아니지만 로컬라이즈 적인 부분에선 상당히 신경 쓰이는 문제입니다.

문자열 첫번째 바이트를 charset 으로 설정하고 나머지에 문자를 채운적이 있습니다. 임시 방편이긴 한데 이렇게 하면 다국어 채팅시 적절한 폰트도 골라갈 수 있고 언어도 확인할 수 있기 때문에 간단히 해결이 되었었죠. wchar_t 도 이런 방식을 동일하게 적용할 수 있겠죠. ^_^

사용자 아바타
oranke
전체글: 244
가입일: 2002-05-09 09:00

전체글 글쓴이: oranke » 2009-06-18 17:10

한 단락 한 단락이 정말 가슴에 팍팍~~ 와 닿네요.
귀중한 말씀 감사드립니다.

fghj1
전체글: 2
가입일: 2009-11-11 12:47

조금 다른 화제이지만 기획자의 이런 생각 어떤가요?

전체글 글쓴이: fghj1 » 2010-08-05 21:05

최초 기획부터 대박은 꿈에도 생각하지 않고 오로지 "적어도 중박은 되지 않겠어?!"라는 생각으로 기획을 시작하는 신규 프로젝트의 8년차 이상의 기획자... 어떻게 생각하시나요?

저는 이런 생각에 동의할 수 없어 결국 이 신규 프로젝트 팀에 합류하는 것은 포기해야 하는 상황입니다.
그리고 가장 중요한것이 있다면.

16. 반드시 한국에서 성공해야 한다. 한국에서 성공한게임이 해외에서도 뜬다.
물론 한국에서 망했지만 해외에서 뜬 게임도 있지만, 극소수이다.

한국에서 망해도 해외가 있겠지? 라는 마음가짐으로는 절대 해외에서 성공할수 있다.
수많은 과거사례는 결국

한국에서 성공한 게임만이 해외에서 성공한다는것을 보여준다.
이 말에 생각하게 되는 것이 많아지면서 지금, 팀 분위기를 돌아볼 때, 한숨만 나와 오래전 글임에도 불구하고 글을 남겨봅니다.

사용자 아바타
oranke
전체글: 244
가입일: 2002-05-09 09:00

전체글 글쓴이: oranke » 2010-08-06 13:02

한국에서 말 그대로 쪽박을 차고 외국 서비스로 먹고살고 있습니다.
결과로만 따지면야 기획자 이야기에도 일리가 있겠지만... 대박 꿈꾸며 만들어도 먹고살똥 말똥한 현실에서 시작부터 중박 운운하는 이야기가 나온다면 고민을 많이 하셔야 할 듯 하네요.

fghj1
전체글: 2
가입일: 2009-11-11 12:47

기획자의 말, 다년간의 경험에 의한 가장 현실적인(!?) 발언일지도 모르겠습니다

전체글 글쓴이: fghj1 » 2010-08-06 13:49

기획자의 말에 부정은 못하겠습니다. 그러나, 기획자라면 자신의 기획으로 게임이 만들어지기에 '자기 게임을 만드는 것'이라고 생각할 수도 있을텐데 자기 손으로 나오는 창조물에 대해 저런 얘기를 할 수 있는 것인지 잘 이해가 안됩니다.

왠지 저는 이상을 쫓고 있는 것 같고 기획자는 현실을 직시하고 있는 것 같습니다.

하지만, 이제 막 입사한 사원들이나 함께 일하는 팀원들의 분위기 또는 마음가짐도 그 수준으로 정해져 움직이고 있는 것이 아닌지 생각됩니다. 서있으면 앉고 싶고 앉아 있으면 눕고 싶은 것이 사람 심리인데 이미 8년 이상된 기획자가 그리 말하고 시작되었으니 그 밑에 경력자 또는 신입자들은 조금이라도 힘들어지면 쉽게 포기하는 마음가지기가 쉬워질 것입니다. 또는 결과물의 퀄리티도 자연스럽게 그런 방향으로 흐를지도 모르지요.

제 억측일 수도 있겠지만... 사람 심리라는 것이 그런거 아닌가 라는 생각에 팀에 대해 생각하면 답답해지는 느낌이 앞섭니다. 공적으로 팀웍이 좋아야 하는데 사적으로 팀웍이 좋아지는 경향이 있어 더더욱 그런 불안함을 느끼는지도 모르겠습니다.

아직은 이상을 쫓고 있는 저는 이 분들에게 출퇴근만 잘하고 월급만 받아가면 된다는 아마추어적인 생각 좀 버렸으면 좋겠다고 속(!!)으로 외칩니다만 이미 사적인 팀웍으로 뭉친 이 분들에게 있어 적이나 마찬가지인 저를 악의 축으로까지 생각하게 만들고 싶진 않군요... lllOrz

stpapa
전체글: 43
가입일: 2007-11-05 10:48

Re: 조금 다른 화제이지만 기획자의 이런 생각 어떤가요?

전체글 글쓴이: stpapa » 2010-08-11 18:14

fghj1 작성:최초 기획부터 대박은 꿈에도 생각하지 않고 오로지 "적어도 중박은 되지 않겠어?!"라는 생각으로 기획을 시작하는 신규 프로젝트의 8년차 이상의 기획자... 어떻게 생각하시나요?
일단 오랜만에 GPG에 댓글을 달아 보니 눈물부터 좀 닦고요 ㅜㅜ;;

예전에 신규 프로젝트를 들어가면서 CEO와 이야기 할 시간이 있었는데 거기서 그런 말이 나왔습니다.
"백두산을 목표로 올라가야 적어도 한라산 목표로보다는 많이 올라갈 수 있지 않겠는가?" 라는 말이었습니다.

그때야 그냥 고개를 끄덕여야하는 상황이라서 넘어갔는데 한편으로는 이렇게 생각해봅니다.
"한라산이 목표인것과 백두산이 목표인것은 준비부터 다르다"라구요

요즘처럼 개발의 대형화가 되가는 상황에서 초대박을 준비하기엔 대부분 개발비 및 개발시간이 많이 않을 텐데 괜한 비현실적인것을 추구하다가 개발비 및 시간을 다 날려 먹느니 정확히 목표를 수립하고 안배해서 개발을 진행해야 하지 않나 싶네요

Locked