180bpm
scaleform 3.3과 4.0에서 로컬라이징 테스트(2) 본문
반응형
FontConfig를 사용한 GFxTranslataor를 사용하는 방법은 Scaleform에서 기본적으로 제공해주는 기능입니다.
다만, 이미 언리얼에는 로컬라이징을 위한 폴더링이 되어 있고 번역테이블까지 있기 때문에 스케일폼만을 위해 2개를 만들어서 두는건 비효율적인 방법이고, 또 에픽게임즈에서 이런 방식을 내버려두진 않았을꺼라 생각해서 언리얼의 로컬라이징 파일을 사용하는 방법을 테스트 해봤습니다.
언리얼에 통합된 Scaleform의 로컬 테이블은 Localization/국가코드/GFxUI.int (디폴트)에서 가져 올 수 있습니다.
번역을 처리할때의 내부구조도 똑같은 방식으로 돌아가는것으로 알고 있습니다.
사용법은 다음과 같습니다.
1. GFxUI.int를 연다
2. [Global] 다음째 줄에 키 값=매핑 값을 쓴다.
FontConfig.txt에서는 tr "키 값" = "매핑값" 입니다.
그래서 언리얼에서 로컬라이징이 될 때 키 값 구분을 위해 임시로 붙여둔 인자인 $가 들어가니 해당 키 값을 찾지 못했습니다. 문자열로 하는것이 좋을듯 싶습니다.
3. 인게임에 들어가면 바로 확인이 가능합니다.
다만 문제점이 있습니다. FontConfig는 개발시 Scaleform Launcher에서 테스트가 가능하지만 언리얼 로컬라이징 테이블은 가져와서 테스트 할 방법이 없습니다.
(UDN 메일 답변에서 확인. Unprog3에서도 불가능이라고 함)
정리
FontConfig의 장점
Scaleform Launcher로 테스트 가능.
단일 파일 안에 모든 각국의 로컬 테이블을 넣을 수 있다.
FontConfig의 단점
default folder가 현재 테스트중인 파일의 root이기 때문에 인게임에서는 쿸킹이 되서 txt를 넣을 수 없다.
그래서 엔진으로 경로를 수정해줘야 한다.
컨테이너던, 개별 UI건 어쨌든 지역명을 던져줘야한다. 하지만 이 불편을 꼼수로 사용 할 방법도 있다. korean1, korean2 이런식으로 구분해서 같은 UI에도 필요할 때 마다 로컬만 던져주면 바로 변한다.
다만 4.0에서는 지역명을 받는 변수가 사라져서 대처법을 찾는 중. 다만 FontConfig 파일이 있다면 첫번째 로컬 테이블로 매칭이 됨
언리얼 로컬 테이블의 장점
새로 만들지 않아도 된다. 엔진의 로컬을 따라가서 별도로 날려 줄 필요가 없다.
언리얼 로컬 테이블의 단점
개발중 테스트가 불가능하다.
HTML 태그가 안된다.
https://udn.epicgames.com/lists/showpost.php?list=undev-kor&id=46944&lessthan=46995&show=200
이건 큰 문제라고 생각한다.
그래서 로컬라이징 테스트를 하려면 테스트땐 FontConfig를 사용하고 인게임에서는 언리얼 로컬 테이블을 사용하면 된다고 생각합니다.
반응형
Comments