CK2 Crusader Kings 2 - 2.4 한글화와 관련된 이야기들

[tacitus]

1. 이 글을 쓰는 이유

이제 거의 한글화 시스템의 안정화가 이루어진 시점입니다. 방법론에 대해서는 더 이상 이론의 여지가 없고, 시스템도 완성되었습니다. 현재 이미 폰트를 적용한 테스트용 한글화 모드가 배포되고 있고, 아마도 정식 한글화 모드 버전에 추가될 폰트도 곧 완성될 것 같습니다.

이 시점에서, 이번 한글화 시스템에 대한 기술적, 현실적인 이야기들을 하나의 문서로 정리해둬야 할 필요성을 느꼈습니다. 최근에 질문/답변 게시판에 올라오고 있는 몇몇 질문들은 이러한 배경을 알지 못하기 때문에 발생하는 문제에 대한 질문이었기 때문에, 이대로 정식 한글화 모드가 공개되면 비슷한 질문이 CK2와 EU4 양쪽 모두에서 터져나올 것이 예상되기 때문입니다.

아래 내용 중에서, 쉬운 설명을 위해서 실제보다 좀 단순화하거나, 정확하지는 않지만 그렇다고 아주 틀렸다고 하기도 뭐한 내용으로 바꿔 설명한 부분도 있습니다. 전공자분들은 그런 내용이 보이더라도 그냥 한쪽 눈을 살짝 감아주시면 좋겠습니다. 물론 정확히는 이런 거라고 덧글로 알려 주셔도 좋긴 하겠네요.

2. 알아둬야 할 것 - 요약

긴 글을 읽기 싫어하시는 분들을 위해서, 해서는 안 될 것들을 먼저 말씀드리고 시작해야 할 것 같습니다. 이유를 알고 싶으시면 아래를 계속 읽으시면 됩니다. 만사 귀찮으시면 이 사실들을 그냥 머릿속에 때려박으면 되고요.

1. 2.3.x 시절까지 사용되었던 모든 종류의 한글을 사용한 모드들은, 2.4.x 버전에서 그대로 사용할 수 없습니다. 구버전용 한글 모드를 실행하고 왜 글자가 깨지냐고 묻지 말아주세요. (즉, 이전에 개인적으로 만들어 사용하던 모드, 오늘 현재 자료실에 등록된 각종 모드들 중 한글을 사용한 대부분의 모드들은 2.4.x 에서 사용할 수 있다는 명시적인 언급이 없는 한, 그대로는 사용 불가능이라고 보면 됩니다.)

2. 위 1의 모드들을 2.4 이후에 사용하기 위해서는 해당 모드에 사용된 한글들을 현재 공개된 변환 프로그램을 이용하여 새로운 한글 출력 방식에 맞추어 변환해 주어야 합니다.

3. 위 (2) 의 방법으로 모드를 변환한 후 변환한 파일을 사용했을 때 한글이 제대로 출력된다면, 해당 모드가 오동작하더라도 그건 일반적으로 한글화의 문제가 아니라 2.4.x 버전의 CK2 와 이전 버전의 CK2 간의 모드 호환성 문제입니다. 우선 해당 모드 제작자에게 문의해보십시오.

4. 이 한글화 시스템에서 가장 중요한 것은 사용된 비트맵 폰트입니다. 따라서, 모드 중에서 자체 폰트를 사용하는 종류의 모드는 한글화 모드와 함께 돌릴 수 없습니다.

5. 원본에서 대규모의 파일이 수정된 모드의 경우, 한글화 모드와 함께 동작시키면 모드 사이의 충돌로 인한 오작동의 우려가 있습니다. 따라서, 한글화 모드에서 원본을 수정한 파일과, 해당 모드에서 원본을 수정한 파일을 비교하여 수작업 수정을 해야 합니다. 다만, 과거의 한글화 방식과 현재의 한글화 방식이 다르기 때문에, 이런 변환 작업이 오히려 더 쉬워졌습니다.

이제부터 서술할 내용은 모두 위 내용들에 대한 구체적인 설명입니다. 많은 부분은 기술적인 내용이 되겠지만, 문과 레벨에서도 알아들을 수 있을 정도로 쉽게 설명드릴 테니 한번 이해해 보십시오. 이 글을 읽으시는 분께서 관련된 지식이 전혀 없다고 가정하고 설명드리겠습니다.

3. 기존의 한글화 방식과 새로운 한글화 방식

(1) 2.3.x 버전까지의 한글화 방식 (2바이트 출력)

1) 기본중의 기본이 되는 이야기

일단 컴퓨터가 0과 1밖에 모르는 깡통이라는 사실은 대부분 잘 알고 계실 것 같습니다. 가장 저차원적인 연산이자, 가장 표현하기 쉬운 연산이 "그렇다/아니다"의 T/F 연산이니까요. 전기가 들어가면 참이고, 안 들어가면 거짓이고. 얼마나 간단합니까? 그래서 컴퓨터는 모든 입력 정보를 이와 같은 0과 1의 조합으로 바꿔서 처리합니다. 예를 들면 우리가 A 라는 문자를 입력하더라도, 컴퓨터가 이걸 알아먹기 위해서는 1000001 이라고 바꿔서 전달해줘야 한다는 겁니다.

그런데, 컴퓨터가 서양에서 만들어진 물건이다 보니, 이런 설계가 서양의 체계에 맞게 만들어져 버렸습니다. 하나의 문자를 표기하기 위해 몇 개의 0과 1을 쓸 것이냐의 문제도 그렇습니다. 별 말이 없으면, 컴퓨터는 하나의 처리 단위로 8개의 0과 1을 묶어서 처리해버립니다. 이게 바로 1바이트(=8비트)라는 거죠.

1개의 비트는 독립적으로 0이냐 1이냐의 정보 하나를 저장할 수 있는 단위입니다. 따라서 8개의 비트를 묶어서 하나의 문자로 처리한다면, 00000000 부터 11111111 까지의 주소를 가질 수 있습니다. 이진수 11111111은 십진수로 고치면 255이니, 0~255 까지 총 256개의 문자를 저 주소 내에 배정할 수 있는 거죠. 이제 이렇게 확보된 256개의 주소 내에, 그들의 필요에 따라서 알파벳 대소문자, 각종 기호, 특수문자 등을 배정해 넣은 겁니다. 이게 흔히 말하는 1바이트 아스키(ASCII) 코드입니다. 그들이 사용하는 알파벳이야 26자에 불과하고, 대소문자를 나누어 넣어도 52자밖에 안 되니, 한번에 256개의 문자 세트는 차고 넘치는 것이었습니다. (그렇다 보니, 7개의 비트만 사용해서 128개의 공간만 문자에 배정하고, 남은 1개의 비트는 다른 용도로 사용하는 만행(?)을 저지르기도 했죠.) 컴퓨터가 처음 발명될 당시의 부족한 처리 용량과 저장 용량을 생각한다면, 그들의 이런 결정은 합리적인 선택이었습니다.

그러나, 컴퓨터가 미국 밖의 영역으로 넘어오면서 문제는 달라지기 시작합니다. 이미 256개의 공간은 알파벳, 숫자, 특수문자, 서유럽 고대 문자 등으로 가득 차서 더 배정할 수가 없는데, 세계의 수도 없이 많은 문자들이 컴퓨터 안으로 들어오려고 하니 문제가 생긴 거죠.

결국, 이런 문자들을 처리하기 위해서는 1바이트만으로는 부족하다고 하여 2바이트(혹은 그 이상)를 묶어서 각 국가마다 고유한 문자 체계를 만들기 시작했습니다. 2바이트면 이론적으로 256x256=65536 개의 주소를 만들어낼 수 있으니, 기존의 아스키 문자가 사용하던 영역을 포함하여 최대 65536개의 문자를 처리할 수 있는 겁니다. 우리 나라의 경우에도 그래서 2350개의 완성형 한글과 상용 한자, 특수 문자 등을 2바이트 영역에 배정한 KS-5601 완성형 문자 체계를 1987년에 고시했고, 지금도 이것을 기반으로 하여 확장한 문자 세트(MS 윈도우의 경우 CP949, 유닉스/리눅스/인터넷의 경우 EUC-KR)를 사용하고 있습니다. 이웃 나라인 일본과 중국 역시, 자국의 한자, 가나 등을 표시하기 위해서 2바이트 체계로 문자 세트를 구성했고요. 러시아도 마찬가지입니다.

문제는, 이 2바이트 체계의 경우 1바이트 체계와는 달리 각 국가마다 독자적으로 만들어 쓰다 보니 서로 연동이 안 됩니다. 그래서 한글로 텍스트 파일을 작성해서 일본 컴퓨터에서 텍스트 에디터로 열어보면 한글은 안 나오고 막 정신없이 깨진 글자들이 보입니다. 걔들은 KS-5601이 아니라 SHIFT-JIS 같은 걔들의 독자적인 2바이트 문자 세트를 쓰거든요.

참고로, 이렇게 서로가 서로를 못 알아듣는 2바이트 문자 체계라도, 1바이트의 7비트 공간, 즉 0~127의 공간은 서로 공통적으로 쓰고 있습니다. 왜? 이 공간에는 알파벳 대소문자, 숫자, 각종 기호 등 일반적인 키보드에 배정되어 있는 문자들과 기본적인 제어 문자들이 배정되어 있는데, 이것까지 따로 써 버리면 기본 ASCII 문자 체계와의 호환성이 무너져서 문제가 심각해지기 때문입니다.

그래서, 하위 7비트는 그대로 아스키 코드 영역에 할당을 해서, 최상위 비트가 0이면 1바이트 문자로 그대로 출력을 하고, 만약 최상위 비트가 1이라면 이건 1바이트 문자가 아니라 2바이트 문자이므로 다음 바이트까지 읽어서 2바이트를 합친 값으로 주소를 찾아라. 라는 식의 규칙이 만들어지는 것입니다. 예를 들어 1바이트를 읽었는데 01000001 이면 최상위 비트가 0이므로 1000001 을 찾아서 A 라는 문자를 출력하고, 10110000 이면 최상위 비트가 1이므로 다음 바이트까지 읽어서 10110000 10100001 을 주소에서 찾아서 45217번 글자인 "가" 를 출력하게 되는 겁니다.

2) 그런데, 뭐가 문제래요?

위에서 제가 말씀드렸듯이, 컴퓨터는 별 말이 없으면 8개의 비트를 하나의 처리 단위로 해서 하나의 문자를 표시합니다. 그 말은, 2바이트를 묶어서 하나의 문자로 처리하기 위해서는 그런 일을 하는 별도의 프로그램이 존재해야만 합니다. 그런 게 없다면, 우리가 "가" 를 입력하면, 이 무식한 컴퓨터는 °¡ 라는 문자를 출력을 해 버린다는 거죠. 두 개의 바이트를 각각 다른 문자로 봐서 따로따로 출력한다는 겁니다.

사실, 현재는 이미 유니코드가 대세로 되어 있는 상황이라(유니코드는 한 개의 문자를 표시할 때 2~4바이트를 사용합니다. 최소 65535개의 주소 배정, 최대 4294967296개의 주소 배정이 가능합니다. 세상에 존재하는 모든 문자들을 다 때려박을 수 있어요!), 글로벌을 지향하는 소프트웨어 기업들은 대부분 유니코드 기반으로 프로그램을 짜곤 합니다.

파라독스의 경우에도, 그들이 직접 만들지 않은 씨티즈 스카이라인의 경우 매우 쉽게 한글화가 됐죠. 왜? 유니코드 기반이기 때문입니다. 기본적으로 2바이트를 읽어서 하나의 문자를 표시하는 체계거든요. 그런데, Crusader Kings 2 의 기반이 되는 클라우제비츠 엔진은 안타깝게도 유니코드 기반이 아닙니다. 기본적으로 1바이트 코드 기반이예요.

이건 기본적으로 파라독스사의 생각 문제입니다. 2바이트 문자 시장인 동아시아, 러시아 등의 시장 진출을 별로 고려하지 않고 있다는 거죠. 이들 시장을 고려하지 않는다면, 굳이 기본이 2바이트 출력인 유니코드 체계로 전환해서 더 많은 처리 용량을 할당할 필요가 없는 겁니다. 시스템 자원을 낭비할 필요가 없다는 거죠. 그 결과, 2바이트 문자를 기본 문자 세트로 사용하는 동아시아 등의 국가에 사는 유저들은.. 이하 생략합니다.

이런 1바이트 기반 시스템에서 2바이트 문자를 표시하기 위해서는, 2바이트 문자를 인식할 수 있도록 중간에 통역 역할을 하는 프로그램 하나가 더 돌아가야 됩니다. 그 일을 했던 것이 지난 버전까지 약방의 감초처럼 들어가 있던 d3d9.dll 파일인데, 이건 그냥 만들어진 것이 아닙니다. Crusader Kings 2 의 실행 모듈을 역 어셈블링(리버스 엔지니어링)해서, 다시 말하면 프로그램의 코드를 다 풀어 헤쳐서, 몇십만줄에 달할 것이 분명한 암호문과도 같은 코드들 헤쳐 가며 화면에 글자를 출력하는 부분이 어딘지를 찾고, 그 부분을 해킹해서 2바이트 출력을 위한 별도 코드를 심어넣은 것입니다. 말도 안 되는 분량의 노가다와 일정 수준 이상의 컴퓨터 시스템에 관한 지식, 그리고 어셈블리어 해독 및 작성 능력, 많은 시간 투입이 필요한 작업이죠. 이걸 그동안 해 낸 사람들이 바로 이웃 중국 유저들이었고, 한국과 일본은 이 코드를 편하게 받아쓰고 있었던 겁니다.

그런데, 2.4 버전에 와서, 파라독스가 무슨 생각을 했는지 몰라도 이 코드를 무지막지하게 뒤틀어버렸습니다. 출력 부분을 상당히 복잡하게 꼬아놨다는 거죠. 그 결과, 인해전술로 무장한 중국 유저들도 몇달째 2바이트 출력 코드를 만들어내지 못하고 있는 상황입니다. 그걸 편하게 받아먹고 있던 한국과 일본은 덩달아 같이 멘붕... 이게 몇 주 전까지의 상황이었습니다.

(2) 2.4.x 버전 이후의 한글화 방식 (1바이트 출력)

1) 도입

해결의 단초는 몇 주 전에 스팀 창작마당에 등장한 EU4 러시아어 모드였습니다. 분명 러시아어의 키릴 문자는 2바이트 영역에서 사용 가능한 문자 세트인데 2.4 버전 대응으로 나왔거든요. 그러나, 이 러시아어 모드에는 기존에 흔히 사용되던 출력 모듈이 존재하지 않았고, 확인 결과 1바이트의 확장 영역에 키릴 문자를 때려박은 형태의 패치라는 사실이 밝혀졌습니다. 기대가 한방에 실망으로 바뀌는 순간이었죠.

앞에서 2바이트 체계의 문자는 1바이트 체계 문자와 호환성을 유지하기 위해서 하위 7비트는 그대로 사용한다고 말씀드렸었죠. 이 0~127번에 해당하는 문자 세트를 기본 ASCII 문자 세트라고 하고, 최상위 1바이트가 1인 128~255 의 영역을 확장 ASCII 문자 세트라고 하는데, 이 확장 아스키 문자 세트에는 주로 고대 서유럽어 문자 등 현재에는 일반 용도로는 별 영양가가 없는 문자들이 들어 있습니다. (이 부분도 엄밀하게 말하면 조금 다릅니다. 해당 영역이 확장 아스키 코드 영역인건 맞습니다만, CK2가 사용하는 문자 세트는 ASCII 가 아니라 ISO-8859-1 이라고 하는 ASCII 호환 서유럽 문자 세트거든요.) 바로 이 영역에 기존의 문자들 대신 러시아어의 키릴 문자를 대응시켜서 러시아어 폰트를 연결하면 그 문자들이 출력되는 것입니다.

키릴 문자의 수는 다 합쳐도 100개 미만으로, 문자 수가 많지 않습니다. 그래서 이와 같은 방식의 로컬라이징이 가능했죠. 그러나 완성형 한글은? KS-5601-1987 하에서도 2350자입니다. 도저히 100개도 안 되는 공간에 때려박을 수가 없습니다. 일본과 중국 역시 한자 때문에라도 애초에 불가능하고요.

그러나 - 마침 오늘 한글날인데 - 세종대왕께서 창제하신 한글의 자모 조합 제자 원리 덕에, 한글의 경우에는 이 방식을 적용할 여지가 생깁니다. 한글은 기본적으로 14개의 자음과 10개의 모음을 초/중/종성에 조합하여 하나의 글자를 만들어내는 방식이므로, 이런 자모를 별도로 떼어 내서 자모마다 하나의 공간을 할당하고, 출력 단계에서 이들을 조합하는 방식으로 출력을 하면 의외로 한글의 출력이 가능해질 수 있는 것이죠. 가능성이 타진되자 실제로 테스트 폰트가 만들어져서 적용이 시도되었고, 그 적용의 결과가 바로 지금의 1바이트 한글화입니다.

사실 이미 이런 방식의 한글화는 많은 분들이 지적하셨다시피 과거에도 사용된 예가 있습니다. 다만 여러 가지 단점들이 있기 때문에 - 곧 말씀을 드리겠습니다 - 웬만하면 사용이 되지 않는, 이제는 고대의 유물이 되어버린 방식입니다. 헌데, 쓸데없는 몽니를 부린 파라독스사 덕에 다시 빛을 보게 되었네요.

2) 원리

원리는 간단합니다. 128번 이후의 공간에 한글의 자모를 초성, 중성, 종성으로 나누어 때려박아 둔 후, 그것을 잡아당겨 붙이는 겁니다. 예를 들어, 킹 이라는 글자를 표현하려면, ㅋ,ㅣ,ㅇ 의 세 자모를 별도로 지정한 후, ㅣ를 한 글자만큼 앞으로 잡아당기고, ㅇ을 두 글자만큼 앞으로 잡아당기면 되는 거죠. 잡아당겨서 붙게 되는 개별 자모의 위치가 초성/중성/종성에 따라서 달라지기 때문에, 같은 자음이라도 초성과 종성은 따로 정의되어야 합니다. 또한, 쌍자음과 이중모음 등도 별도로 정의되어야 하죠.

혹시 타자기 실물을 직접 보신 분들이라면 이 원리가 바로 이해가 되실 겁니다. 타자기의 각 활자들은 이를테면 같은 ㄱ 이라도 초성의 ㄱ과 종성의 ㄱ이 서로 다른 키를 사용하죠. 종이에 찍혀야 하는 위치가 다르니까요. 이것과 같은 원리입니다.

사실 여기까지 알아야 하나 싶은 생각은 들지만 좀 더 이야기를 해보자면, 그렇다고 해서 128번 이후의 공간에 원래 있었던 고대 서유럽 문자 등의 문자들이 "실제로" 한글 자모로 변환되는 건 아닙니다. 실제 출력은 그 문자가 출력되지만, 그 문자가 화면에 그려지는 단계에서 폰트에 의해서 그 문자 대신 한글 자모가 그려지는 거죠.

예를 들어, 우리가 아스키 코드 161번을 호출하면, 이 멍청한 컴퓨터는 아스키 코드 161의 원래 문자인 ¡ 문자를 호출하는 줄 알고 이 문자를 출력하라고 던질 거고, 또 화면에 이 문자가 출력되는 줄 알 겁니다. 하지만, 폰트를 거치면서 이 이상한 문자는 우리가 알고 있는 ㄱ 문자로 그려지는 겁니다.

3) 한계

다만, 이 방식을 사용하게 되면 최소한 Crusader Kings 2 에 한해서는 중대한 문제가 생깁니다. CK2는 고대에서 중세에 이르는 유럽을 그리고 있기 때문에, 국가나 인물 등의 명칭에 고대 서유럽 문자들이 많이 보입니다. 문제는 이 자리를 한글 자모가 대체하고 있기 때문에, 이들 고대 서유럽 문자들은 화면에 출력이 불가능해집니다. 이걸 그대로 냅두면, 분명 서유럽어 고대 문자가 보여야 하는 자리에 뜬금없는 한글 자모가 보이는 사태가 벌어지죠. 따라서, 화면에 출력될 수 있는 모든 고대 서유럽어 문자들은 모두 일반 26자 알파벳으로 고쳐야만 합니다.

또한, 맵에 표시되는 구부러진 문자를 이 방식으로 표현하기는 상당히 어렵습니다. 엉망으로 조합되기 때문이죠. 게다가 글자 크기가 (나라 크기에 따라) 매우 다양하기 때문에, 이런 것까지 모두 맞춰서 자모의 조합을 조정하는 건 거의 불가능에 가깝습니다.

그래서 이번 한글화에서 맵폰트에 출력되는 다양한 고유명사들은 모두 번역하지 않고 영문으로 표기하고 있습니다. 이 부분은 이 방식의 어쩔 수 없는 한계입니다.

(3) 1바이트 출력 한글의 장점과 단점

일단 이 방식의 장점이라면, 앞으로도 문제 없이 이 방식을 사용할 수 있다는 점입니다. 1바이트 출력이기 때문에 파라독스가 무슨 짓을 한다고 해도 근본적으로 이 방식의 한글 출력을 막을 수는 없습니다. (방법이 하나 있긴 한데, 그렇게까지 해야 할 이유가 없습니다.) 따라서, 앞으로 2.5, 2.6 등으로 메이저 버전업이 된다고 하더라도 한글 출력 여부에 대해서 골머리를 썩일 이유가 없습니다. 그냥 번역만 계속 추가하면 돼요. 세종대왕님 만세!

그럼 이 좋은 걸 왜 그동안 안 썼느냐.. 안 좋습니다. 뭐가 안 좋냐면, 화면에 뿌려지는 글씨가 별로 예쁘지가 않아요. 옛날 타자기 글씨 생각해 보세요. 예쁘던가요? 안 예쁘죠. 완성형 글자로 화면에 이미 만들어져서 뿌려지는 글씨는 읽기 좋고 예쁘지만, 억지로 자모를 끌어당겨서 기계적으로 맞춘 글씨이기 때문에 완성형보다 보기 좋을 수가 없는 겁니다.

이 단점을 최대한 극복하기 위해서, 같은 ㄱ이라도 뒤에 오는 모음이 무엇이냐에 따라서 별도의 문자를 할당하기도 하고, 받침이 있는지 없는지에 따라서 초성과 중성을 별도의 세트로 만들기도 하는 등, 빈 공간이 얼마나 있느냐에 따라서 최대한의 공간을 할당함으로써 조금이라도 더 읽기 좋은 글씨가 나오도록 노력하고 있는 거죠. 지금 작업실에서 진행되고 있는 작업입니다. 

4. 새로운 한글 패치 모드를 잘 쓰기 위해서

(1) 기존의 한글로 된 모드를 쓰려면

앞에서 열심히 기존 한글화 방식과 새로운 한글화 방식을 설명드렸습니다. 위에서 설명드린 것처럼, 두 방식은 한글을 출력하는 방식이 서로 다릅니다. 따라서 똑같은 "가" 라도, 하나는 B1h A0h 이고, 다른 하나는 A1h B3h 입니다. 따라서, 기존의 한글로 된 모드를 새로운 한글화 모드를 적용한 데에 갖다 붙이면 어떻게 될까요? 한글이 아닌 뭔가 다른 이상한 문자들이 튀어나올 것은 불을 보듯 뻔합니다.

따라서, 기존의 한글로 된 모드를 계속 쓰고 싶다면, 2바이트 한글을 직결식 한글 코드로 변환해 주는 변환 프로그램을 사용하여 모드 파일을 변환해 주어야 합니다. 한글화 게시판에 가면 변환 프로그램이 공개되어 있으므로, 이들 프로그램을 사용하여 한번 돌려주세요. 아마도 언어 파일(.CSV)만 변환해 주면 거의 문제가 없겠지만, 좀 거대한 모드의 경우 다른 파일에도 한글이 들어있을 수 있으니, 한글이 들어 있는 모드 파일들을 모두 한번씩 돌려주시면 됩니다.

(2) 폰트의 문제

이 한글화 방식은 확장 아스키 코드 영역의 문자들을 그대로 둔 채, 폰트를 이용하여 출력만을 한글로 바꾼 것입니다. 따라서, 폰트는 가장 중요한 파일이죠. 그런데, 만약 이 한글 폰트 대신 다른 폰트가 사용된다면 한글이 나올까요 안 나올까요? 당연히 안 나오겠죠.

따라서, 모드들 중에서 자체 폰트를 사용하는 모드들과 이 한글 패치 모드는 같이 돌리면 안 됩니다. 아니면 그쪽 모드의 폰트 파일을 비활성화한 후에 돌리세요.

(3) 한글화 모드의 구성에 관한 도움말

이 내용은 다른 모드와 한글패치 모드를 혼용할 때에 알아두면 좋은 내용입니다.

지난 2바이트 한글화 시절에는 모든 고유명사들을 한글화했었습니다. 그래서 localisation 폴더 안에 있는 언어 파일들(.CSV 파일들) 이외에도,

• 문화에 따른 각종 이름들을 정의한 common/cultures/00_cultures.txt
• 가문의 이름을 정의한 common/dynasties/00_dynasties.txt
• 문화별로 달라지는 지역 이름을 정의한 common/landed_titles/landed_titles.txt
• 각 종교의 종교인들이 사용할 이름들이 별도로 정의된 common/religions/00_religions.txt
• 고정 캐릭터 이름들이 포함된 history/characters 폴더의 수많은 .TXT 파일들
• 일부 변경되는 프로빈스 명이 포함된 history/provinces 폴더의 몇몇 .TXT 파일 등

수많은 파일들이 한글화 모드 내에 포함되어 있었습니다. 그러나, 새로운 한글화 모드는 이런 고유명사들이 모두 영문으로 출력되므로, 이론상 이들 파일들은 굳이 한글화 패치 내에 포함될 이유가 없습니다. 그럼에도 불구하고, 새로운 한글화 모드를 받아 보시면 이들 파일이 그대로 포함되어 있는 것을 보실 수 있습니다. 왜?

그것은 이들 고유명사에 포함되어 있는 고대 서유럽 문자들 때문입니다. 앞에서도 말씀드렸듯, 이들 문자가 들어갈 자리에 한글 자모가 들어가 있어서, 이들 문자는 한글화 모드 하에서는 출력이 불가능한 문자들입니다. 따라서 이들 문자들은 모두 일반 영문 알파벳 문자로 치환되었고, 한글패치 모드에 들어있는 해당 파일들은 모두 이렇게 치환된 문자가 존재하는 파일들입니다.

따라서, 원칙적으로 localisation 폴더 내에 있는 .CSV 파일 이외에는 한글이 포함된 파일은 없으므로 (정확히 말하면 history/wars 내의 전쟁 데이터 파일들은 그 이름이 한글화 되어 있습니다. 하지만 이 파일들이 빠진다고 해도 문제는 없습니다. 단지 전쟁 이름이 영어로 출력되겠죠.) 다른 모드, 특히 굉장히 큰 규모의 모드(예를 들면 왕좌의 게임 모드 등)들과 한글화 패치 모드를 함께 사용하는 경우, 만약 충돌이 발생한다면 다음과 같은 조치를 취하면 됩니다.

1. 한글화 패치 모드의 common 폴더 아래에 존재하는 모든 파일 중 함께 돌리려는 모드 내에 존재하는 파일이 있다면 모두 삭제합니다.
2. 한글화 패치 모드의 history 폴더 아래에 존재하는 모든 파일 중 함께 돌리려는 모드 내에 존재하는 파일이 있다면 모두 삭제합니다.
3. 함께 돌리려는 모드의 구성 파일들을 서유럽 고대 문자를 변경 대체하는 프로그램으로 한번 돌려서 서유럽 고대 문자들을 모두 일반 알파벳으로 변경합니다.
4. 한글 패치 모드와 함께 실행하여 테스트해 보면서 더 뺄 요소가 있는지 확인합니다.

[페르이노]

한글화에 대해서 자세히 알게 되었네요. 상세하신 설명 감사드립니다.

[랜드파이어]

아 그러니까 지금 크킹 및 유로파 한글화팀은
우리 카페에 보물이세요!!
이분들은 반짝 반짝 반짝 거리는 진짜 보물들이세요!!!
아 멋지다 여러분들 최고!!

[뮤엘러리]

작업하시는분들 정말 고생이 많습니다. 항상 응원합니다!

[랜드파이어]

아 근데 지금 한글화 방식으로는
중국이나 일본은 안되나 봐요?
어궁.. 어떻하냐 게네들 ...

[tacitus]

중국이나 일본은 한자 때문에 죽으나 사나 2바이트 뚫어야 할겁니다.. -_-;;;

[유로빠]

그저 감사하고 고맙습니다.

[papepo]

한글화 매우 매우 감사하고
이렇게 자세한 설명까지,,,대단하십니다.

[호엔촐레른]

와 전문가라는 게 진정으로 느껴지네요
대단합니다;

[tacitus]

오해이십니다. 전 전문가가 아니예요. 그냥 제가 알고 있는 걸 (긴) 글로 풀어내는 걸 자주 할 뿐입니다.

[무영]

♡♡♡♡♡♡♡♡♡♡♡♡

[사우론]

보고 나니 정말 여러 제작자분들의 고생이 느껴집니다. 정말 패치 제작하시느라 고생하셨습니다.

[디스마]

선의를 가진 지식활용에 오랜만에 경외심이 느껴지네요. 언제나 감사드립니다!~

[BC4000]

와 정말 고생하셨네요 한글패치 하시는 분들 보면 마치 백성들을 편안하게 하려고 한글을 만드신 세종대왕님을 보는거 같습니다 정말 감사합니다

[영강부]

크 이것이 거대 카페의 이점 수고하십니다 대단하세요

[화눙동동]

와 정말 장난아니네요. 고생 많으십니다 ㅠㅠ

[망구다이]

한글화 만세!!!! 그리고 그냥 오리지날합시다. 이정도만 되도 대단한겁니다.

[kingrapter21]

자세하고 쉬운 설명 감사합니다 ㅎㅎ

[갈치]

전 차라리 이게 더 좋은듯 싶네요. 언제나 감사합니다.

[XX한 그넘을 만드는방법]

정말 감사합니다. 한글화 제작진 때문에 제가 페러독스 게임을 할 수 있습니다.

[Lyric]

정말 많이 배우고 가네요. 노고에 감사드립니다.

[tacitus]

주의할 점은 현재 영문버전의 크킹2와 진행중인 한글버전의 크킹2가 완벽하게 호환되지는 않습니다. 영문버전의 고대 서유럽 문자를 영문버전 세이브 파일을 통해 한글버전에 그대로 갖고올 경우 해당 글자가 깨져요. 세이브 파일을 한번 변환 돌려서 고대 서유럽 문자를 일반 알파벳으로 변경하면 괜찮을지도 모르겠습니다.

[tacitus]

제가 아직 공개 안한 유틸리티중에 그걸 하는 프로그램이 있는데, 그거 세이브파일도 돌릴 수 있을지는 해봐야 알겠네요. 나중에 영문판으로 한번 돌려서 시도를 해 봐야겠습니다.

[냐옹구름]

한패 작업에서 기존 방식과 달리 직결식을 채택해야했던 이유와 그 작업 내역 등. 차후 한패 작업을 진행하실 분들과 한패 진행에 있어 궁금증을 해소해줄 정리글입니다. 한글화 작업방에 스크랩해서 참고자료로 둡니다.