번역한 글자가 네모로 보이는 이유

내보내기가 끝났고, 게임이 실행되었고, 대사 줄마다 똑같은 빈 사각형이 늘어서 있습니다. 번역에는 아무 잘못이 없습니다. 파일 안의 텍스트는 제공자가 돌려준 그대로이고, 그 파일을 텍스트 편집기로 열어 보면 제대로 읽힙니다. 실패한 것은 사슬의 마지막 단계입니다. 게임이 렌더러에 건네는 폰트에 그 글자를 그릴 도형이 없는 것입니다.

네모 상자가 실제로 무엇인가

폰트는 유니코드 코드포인트에서 모양으로 가는 조회 표입니다. 렌더러가 폰트에 없는 코드포인트를 그리라는 요청을 받으면 폰트의 빠진 글자 도형으로 대신합니다 — 보통 비어 있거나 가위표가 쳐진 사각형이고, 공식 이름은 .notdef, 다른 곳에서는 두부 상자(tofu box)라고 부릅니다. 상자 하나가 폰트가 그리지 못한 글자 하나입니다. 이게 전부입니다.

여기서 두 가지 결과가 따라오고, 둘 다 진단에 쓸모가 있습니다. 첫째, 상자 개수가 글자 개수와 같습니다. 태국어 다섯 글자는 다섯 개의 상자가 되지, 더 짧게 뭉개진 덩어리가 되지 않습니다. 둘째, 문자열은 메모리 안에서 온전합니다 — 게임은 여전히 그것을 재고, 비교하고, 저장하고, 다시 불러올 수 있습니다. 빠진 것은 픽셀뿐입니다. 번역된 메뉴가 전혀 읽히지 않는데도 조작은 멀쩡히 되는 이유가 이것입니다.

세 가지 증상, 세 가지 다른 문제

"번역이 깨졌다"는 혼란의 대부분은, 이 셋 중 하나의 해법을 다른 하나에 적용하는 데서 옵니다. 무엇이든 바꾸기 전에 손상의 모양부터 읽으세요.

• □□□ 네모 — 글자는 올바르고, 폰트가 그것을 그리지 못합니다. 폰트를 고치세요.
• ???? — 글자가 사라졌습니다. 무언가가 문자열을 더 좁은 문자 집합으로 다시 인코딩하면서, 표현할 수 없는 것을 전부 바꿔치기했습니다. 어떤 폰트도 되살릴 수 없습니다. 인코딩을 고치거나, 그 형식이 담을 수 있는 대상 언어를 고르세요.
• `テキスト` 같은 깨진 라틴 문자, 또는 テキスト가 ﾃｷｽﾄ로 보이는 것 — 글자 깨짐(모지바케)입니다. 바이트는 맞고 디코더가 틀렸습니다. 한 인코딩으로 쓴 텍스트를 다른 인코딩으로 읽고 있는 것입니다. 어떤 인코딩으로 읽는지를 고치세요.

빠르게 가르는 법: 네모와 글자 깨짐 둘 다 바이트 수가 원본에 대략 비례하지만, 글자 깨짐은 눈에 띄고 제각각인 쓰레기 글자를 만들고 네모는 똑같이 생긴 균일한 사각형을 만듭니다. 균일하면 "폰트", 제각각이면 "인코딩"입니다.

네모: 빠진 글자

게임은 자기에게 필요한 것만 덮는 폰트를 담아 배포되었습니다. 파이프라인에서 고장 난 것은 없습니다 — 아티스트가 한 번도 넣은 적 없는 코드포인트를 여러분이 요청한 것입니다. 해법은 언제나 렌더러에 그 글자를 가진 폰트를 주는 것입니다. 폰트를 교체하거나, 기본 폰트가 빈손으로 돌아왔을 때 렌더러가 참고할 폴백을 더하는 방식으로요.

물음표: 글자가 버려졌다

레거시 싱글바이트나 더블바이트 인코딩으로 텍스트를 저장하는 형식에 문자열을 다시 써 넣어야 할 때, 그 인코딩 밖의 글자는 전부 무언가가 되어야 합니다. 관례적으로 그 무언가가 ?입니다. Shift-JIS와 cp932는 일본어와 ASCII를 담을 수 있고 그 외에는 거의 담지 못합니다. 엄격한 ASCII 필드는 그리스, 키릴, 태국어, CJK 중 아무것도 담지 못합니다. 이것은 폰트가 아니라 파일 형식의 성질이고, 내보낼 때 일어납니다 — 게임이 그 파일을 읽는 시점에는 정보가 이미 사라진 뒤입니다.

RuneTranslate에도 이것이 실제 한계인 엔진이 하나 있고, 숨기지 않고 명시합니다. YU-RIS는 문자열을 cp932로 다시 인코딩하는데, 영어를 비롯한 라틴 계열 출력에는 친화적이지만 태국어는 ?로 나갑니다. 그 엔진에서 cp932 밖의 대상 언어는 아직 만들지 않은 폰트 핵이 필요합니다.

깨진 라틴 문자: 글자 깨짐

Shift-JIS로 쓴 일본어 텍스트를 UTF-8로 읽으면(또는 그 반대로 하면) 악센트 붙은 라틴 글자와 괘선 문자가 길게 늘어섭니다. 어떤 도구가 잘못된 인코딩으로 파일을 쓰거나, 게임 자체의 로더가 여러분의 내보내기가 쓰지 않은 인코딩을 가정할 때 나타납니다. 해법은 엔진이 기대하는 인코딩으로 파일을 쓰는 것이지, 폰트를 바꾸는 것이 절대 아닙니다 — 그래 봐야 아무것도 달라지지 않습니다.

왜 CJK와 태국어가 가장 크게 당하는가

라틴은 글자 100개 남짓이면 됩니다. 일본어는 수천 개, 중국어는 더 필요합니다. 폰트 파일은 크고, 게임은 자기 언어를 덮는 가장 작은 것을 담아 내보내므로, 여러분이 물려받는 커버리지는 그 게임이 어떤 언어를 위해 만들어졌느냐에 전적으로 달려 있습니다.

• 일본어용으로 만든 게임은 보통 가나, 상용 한자, ASCII를 갖고 있습니다. 이것을 러시아어, 그리스어, 태국어, 한국어로 번역하면 ASCII가 아닌 글자가 전부 떨어져 나갑니다.
• 영어용으로 만든 게임은 보통 라틴만 갖고 있습니다 — 그래서 일본어, 중국어, 한국어, 태국어, 그리스어, 키릴이 한꺼번에 실패합니다.
• 태국어가 실제로는 최악의 경우입니다. 흔한 게임 폰트 어디에도 없는 데다, 기본 글자 위아래에 붙는 모음·성조 기호까지 배치해야 해서, 코드포인트를 기술적으로 갖고 있는 폰트조차 엉망으로 렌더링할 수 있습니다.
• 라틴이라고 자동으로 안전하지는 않습니다. 폴란드어, 체코어, 헝가리어, 터키어, 베트남어, 루마니아어는 영어나 일본어용으로 만든 폰트가 자주 빠뜨리는 라틴 확장 글자를 씁니다. RuneTranslate가 Ren'Py에서 바로 그 대상 언어들을 위해 더 넓은 폰트를 함께 담는 이유입니다. "라틴은 괜찮다"가 사실이 아닌 것으로 드러났기 때문입니다.

Unity와 TextMeshPro의 경우

Unity에는 텍스트 시스템이 둘 있고 실패하는 방식도 다릅니다. 레거시 uGUI Text는 Font 오브젝트를 씁니다. 현대 게임 대부분이 쓰는 TextMeshPro는 런타임에 폰트 파일을 아예 쓰지 않습니다. 대신 TMP 폰트 에셋을 씁니다. 미리 렌더링된 글자 이미지의 텍스처 아틀라스와, 코드포인트를 그 아틀라스 안의 위치로 잇는 표입니다.

그래서 TMP 폰트 에셋에는 고정된 문자 집합이 있습니다. 개발자가 그것을 생성할 때 문자 범위를 골랐고 — 보통은 자기가 출시할 언어만 — TMP는 정확히 그 글자들만 아틀라스에 구워 넣었습니다. 정적 폰트 에셋은 무엇을 넣어 주든 그 집합 밖의 것을 절대 렌더링할 수 없습니다. 동적 폰트 에셋은 원본 폰트 파일에 대한 참조를 유지하고 필요할 때 새 글자를 래스터화할 수 있으며, 개발자가 고려한 적 없는 언어까지 자라날 수 있는 유일한 모드입니다.

TMP의 탈출구는 폴백 목록입니다. 각 폰트 에셋에는 m_fallbackFontAssets 목록이 있고 TMP Settings에는 전역 폴백 목록이 있습니다. 기본 에셋에 어떤 코드포인트의 글자가 없으면, TMP는 그 목록들을 훑어 가진 것을 찾습니다. 여기가 개입할 올바른 자리입니다. 게임 자신의 폰트가 이미 그릴 수 있는 것은 전부 그대로 맡겨 두기 때문입니다 — UI는 의도된 모습을 유지하고, 감당하지 못하는 글자만 다른 곳에서 옵니다.

런타임 도구로 고치기

XUnity.AutoTranslator는 실행 중인 게임에 후크를 걸고 설정 파일에서 폰트를 바꿔치기할 수 있습니다. [Behaviour] 아래의 관련 설정은 이렇습니다:

• OverrideFont — 레거시 Unity UI Text 컴포넌트가 쓰는 폰트를 교체합니다. 게임이나 OS가 찾을 수 있는 폰트 이름을 받습니다.
• OverrideFontTextMeshPro — TMP 폰트 에셋을 통째로 교체합니다. TMP 폰트 AssetBundle 파일이나, 게임이 이미 가진 에셋의 이름을 가리키게 하세요.
• FallbackFontTextMeshPro — 둘 중 더 안전한 쪽입니다. 게임 자신의 에셋에 없는 글자에 대해서만 TMP가 참고할 폰트를 더하고, 나머지 자리에서는 원래 서체를 그대로 둡니다.
• tmp_font_assetbundles — OverrideFontTextMeshPro와 FallbackFontTextMeshPro가 보통 가리키는, 커뮤니티가 관리하는 미리 만들어진 TMP 폰트 AssetBundle 모음입니다. Unity 버전별로 만들어지며, 게임과 다른 Unity 버전으로 만든 번들은 로드에 실패합니다 — 버전을 맞추는 것이 사람들이 빠뜨리는 단계입니다.

런타임 도구는 PC마다, 설정마다입니다. 설치된 그 PC에서 게임을 고치고, 같은 빌드를 돌리는 다른 사람은 같은 설정을 다시 해야 합니다. RuneTranslate는 플러그인 자신의 _AutoGeneratedTranslations.txt 파일을 읽고 쓸 수 있으므로, 이미 그것을 쓰고 있는 프로젝트도 막다른 길이 아닙니다 — 각 접근이 어디에 맞는지는 비교 페이지를 보세요.

파일 수준에서 고치기

RuneTranslate는 게임 데이터 안에서 곧장 폴백 경로를 택합니다. Unity 내보내기에서 게임의 TMP Settings와, 템플릿으로 쓸 수 있는 폰트 에셋과, Font 하나를 찾아낸 다음, 대상 문자를 덮는 번들 폰트를 중심으로 Dynamic 모드의 새 TMP 폰트 에셋을 만들어 폴백 목록에 덧붙입니다. 기존 폴백 항목은 건드리지 않고 게임 자신의 폰트가 기본으로 남으므로 — 태국어로 번역된 일본 게임은 라틴 부분의 원래 스타일을 유지한 채 태국어 글자만 주입된 에셋에서 가져옵니다.

여기에 솔직한 단서 두 가지. 게임 에셋의 같은 컨테이너 안에 TMP Settings와 쓸 만한 폰트 에셋 템플릿과 Font가 함께 있어야 하며, 그것들을 다르게 배치한 게임은 여기서 벗어날 수 있습니다. 그리고 주입이 건너뛰어지면 내보내기가 초록불로 끝나지 않고 경고에 그 사실을 적습니다 — 네모로 나가는 내보내기가 제대로 된 것과 똑같아 보여서는 안 되기 때문입니다. 그 경고를 보게 된다면, 위의 런타임 도구 경로가 대비책입니다.

Ren'Py는 TMP가 없으므로 다른 방식으로 같은 결과를 냅니다. RuneTranslate가 CJK나 비라틴 폰트를 내보낸 빌드에 함께 담고 Ren'Py 자신의 config.font_replacement_map으로 등록하면, 게임 폰트가 모자란 자리마다 엔진이 그것으로 대체합니다.

작업 체크리스트

1. 손상을 보세요. 균일한 사각형인지, ? 문자인지, 깨진 글자인지 — 무엇이든 건드리기 전에 셋 중 어느 것인지 정하세요.
2. ?라면 내보낸 파일을 여세요. 물음표가 파일 안에 있다면 글자는 쓰는 시점에 사라진 것이고 어떤 폰트도 도움이 되지 않습니다. 그 엔진의 문자열 인코딩이 여러분의 대상 언어를 담을 수 있는지 확인하세요.
3. 깨진 글자라면 폰트가 아니라 그 파일에 대해 엔진이 기대하는 인코딩을 확인하세요.
4. 네모라면 파일 내용이 올바른지 확인하고 — 거의 언제나 올바릅니다 — 폰트 작업으로 다루세요.
5. Unity에서는 게임 폰트를 교체하기보다 폴백을 더하는 쪽을 택하세요. 교체는 이미 잘 그려지던 것까지 포함해 모든 문자열의 모습을 바꿉니다.
6. TMP 폰트 AssetBundle을 쓴다면 게임의 Unity 버전에 맞추세요.
7. 다시 내보낸 뒤 첫 대사 줄만이 아니라 문제가 있던 바로 그 글자들을 확인하세요. 라틴 확장과 태국어 기호는 대충 훑어보면 넘어가고 다른 데서 실패하는 일이 잦습니다.

다음에 볼 것

Unity 작업 전체 — Unity가 실제로 무엇을 드러내고 무엇이 손에 닿지 않는지 — 는 Unity 게임을 번역하는 방법과 Unity 엔진 페이지를 읽어 보세요. 데이터가 아니라 아트워크에 구워진 텍스트는 별도의 도구가 필요한 별도의 문제입니다. 이미지 번역을 보세요. 그리고 FAQ가 첫 실행에서 흔히 겪는 나머지 놀라움들을 다룹니다.

RuneTranslate는 모든 엔진과 모든 제공자가 열린 채로 무료로 쓸 수 있고, 그중 셋은 API 키가 전혀 필요 없습니다. 게임 자체의 파일을 파싱해 여러분이 보관하는 플레이 가능한 번역 빌드를 내보냅니다. 다운로드하거나 지원되는 엔진을 둘러보세요.