2017. 4. 25. 15:00

Cettear 프로젝트

- 게임 공동 번역 플랫폼

 

하위 프로젝트

세티아(Cettear) 클라이언트 - 실시간 화면 번역 프로그램

 

 

 

Author  : Dang-Gun Roleeyas ( http://blog.danggun.net/ )
Create date : 2017.03.14
License  : GPL (GNU General Public License)

(하위 프로젝트는 해당 라이선스를 따릅니다.)

 

 

개요

공식 번역이 없는 게임을 한글화하는 방법이 몇 가지 있습니다.

 

흔히 말하는 유저 한글 패치는 게임의 코드를 분석하여 한글 데이터를 넣는 방식입니다.

장점은 사용자 입장에서 간편하고 별도로 번역작업을 하므로 어느정도 질이 보장된다는 것입니다.

단점은 프로그램을 분석하는 작업이 필요하므로 아무나 할 수 없어 패치가 나올 때까지 사용할 수 없다는 것입니다.

 

프로그램을 분석하는데 시간도 걸리고 아무나 할 수 있는 작업이 아니다 보니 나온 방식이

화면을 캡쳐 -> OCR 추출 -> 기계번역 -> 화면에 출력

방식입니다.

 

이 방식의 장점은 어떤 게임이든 상관없이 바로 적용할 수 있다는 것입니다.

단점은 OCR추출이 완벽하지 않고 기계번역의 질을 올리기 위해서는 외부 API를 활용해야 하는데 비싸다는 점입니다.

그리고 기계번역의 한계상 어떤 내용인지 알아보는 수준이라는 문제도 있습니다.

이 문제를 해결하려고 몇 가지 방법들을 사용하는데 이러한 방법들은 결국 수작업이 필요하다는 문제가 있어 활용도가 떨어집니다.

 

그래서 제가 생각한 방법은 이렇습니다.

캡쳐된 화면과 OCR, 번역정보(기계번역) 등을 서버로 올리고 위키 방식으로 취합 및 관리를 하는 것입니다.

유저는 이렇게 취합된 정보를 다운받아 사용하고 취합된 정보에 없으면 API를 호출하고 이것을 서버로 전송하여 취합하고 다시 위키로 관리하는 것을 반복하여 깔끔한 번역이 가능하도록 하는 것입니다.

 

기능 흐름

기능 흐름은 다음과 같습니다.

 

 

 

이것을 풀어쓰면...

 

1) 게임 출시

 

2) 게임 정보 입력(위키)

개임의 제목, 스캔 영역과 스캔 색상표 등을 생성한다.

생성과 동시에 사전, 번역 테이블이 생성된다.

사전은 우선 번역돼야 하는 고유명사, 설정 등의 정보를 넣는다.

번역 룰(예>A는 B에 존댓말을 해야 한다)도 여기서 정합니다.

 

3) 게임 정보 다운로드

사용자는 게임 정보를 다운받아 사용한다.

 

4) 사용

나온지 얼마 안 된 게임이면 다운받은 정보가 없으므로 캡쳐 및 기계번역으로만 사용한다.

 

5) 업로드

캡쳐와 기계번역 자료를 서버로 업로드 한다.

 

6) 취합(위키)

다른 사용자들이 올린 정보와 비교하여 일치하는 자료는 제외한다.

OCR문제나 다른 문제로 중복되거나 잘못된 정보가 들어오는 경우 유저들이 위키방식을 통해 수정한다.

 

7) 다시 게임 정보 다운로드

이렇게 취합된 정보를 사용자가 다시 다운로드 하여 사용한다.

첫 사용 때 보다 많은 정보가 취합되어 있으므로 좀 더 빠르고 부드럽고 저렴한 번역이 가능하다.

 

이후 3)~7) 반복

 

장점

이 방식의 장점은

 

1) 어떤 게임도 사용할 수 있다.

2) 프로그래밍 지식이 없어도 번역에 참여할 수 있다.

3) 참여도에 따라 양질의 번역을 사용할 수 있다.

4) 다른 프로젝트(예> 유저 한글화) 하는 팀에게 번역정보를 제공하여 빠른 작업을 가능하도록 해준다.

 

문제점

이 방식의 문제점은

 

1) 서버를 어떻게 유지할 것인가?

이 방식의 가장 큰 문제입니다.

이 방식은 엄청난 양의 트래픽과 저장공간이 필요로 한데.....

아무리 계산해봐도 광고만으로는 유지가 안될 듯 합니다.

 

2) 참여자가 적으면 시스템 자체의 메리트가 떨어진다.

사용자가 적다 -> 번역질 감소 -> 사용자 감소

이런 악순환이 발생할 수 있습니다.

 

 

생각해야 할 것들

지금 생각은 프로젝트 자체를 GPL로 공개하여 여러 사람이 붙어서 작업하는 것입니다.

참여자가 얼마나 있을지는 모르겠는데...

참여자가 있으면 좋겠지만 없으면 마는 거고.,...

 

일단 클라이언트는 GPL로 공개할 생각입니다.

나머지는 어떻게 할지 좀 더 고민해봐야 할 듯 합니다.

 

프로젝트 구성

아래는 프로젝트 구성도입니다.

 

 

 

머신 러닝을 통한 AI 개발은 아주아주 먼 이야기고 웹과 클라이언트를 개발하는 것이 주목적입니다.

API는 외부의 다른 프로그램들도 사용할 수 있습니다.

 

위키 - 웹

유저들이 업로드한 화면정보와 번역정보를 토론을 통해 갱신하는 사이트입니다.

 

1) 게임 재목

 

2) 스캔 영역

게임 안에서 번역해야 할 내용이 표시되고 있는 영역을 지정합니다.

여러 군데 지정이 가능하며 각 영역은 고유한 이름을 지정해야 합니다.

 

3) 스캔 색상표

좀 더 정확한 OCR인식을 위해 추출색상을 지정합니다.

 

6) 번역룰

번역에 사용되는 룰을 만듭니다.

강제적용이 아닌 해당 게임을 번역할 때 지켜야 할 내용을 만듭니다.

예를 들면 존칭이나 호칭을 어떻게 할지를 정합니다.

 

 

5) 사전

게임에서 사용되는 고유 사전입니다.

각각의 게임별로 사용되는 인명, 지명 등의 명사를 미리 지정합니다.

번역시 우선 번역되어 번역의 질을 높이고 번역의 비용을 낮추는 대표적인 방법입니다.

 

6) 번역

사용자가 업로드한 캡쳐 정보와 OCR정보를 기반으로 번역정보를 수정하고 중복을 제거합니다.

 

API - 웹

REST 형식의 API 서비스입니다.

다른 프로그램이 접근하여 사용할 수 있도록 공개됩니다.

 

주요 기능

1) 번역 데이터 다운로드

2) 사전 데이터 다운로드

3) 스캔 정보 다운로드

4) 번역 정보 업로드

 

클라이언트

이 클라이언트는 기능이 계속 추가된다면 MORT처럼 될 것입니다.

(참고 : MORT - 공식 사이트)

 

개발 사상이 비슷하기 때문입니다.

원래 이 프로그램의 목적은 데이터 수집과 출력에 있으므로 기능 추가는 최소화해야 한다는 게 제 생각입니다.

선행 프로그램으로 다른 사람이나 다른 회사의 프로그램을 사용할 수 없어서 클라이언트를 별도로 개발하는 것입니다.

 

이 플랫폼이 자리를 잡는다면 다양한 프로그램들이 API를 활용하여 정보를 수집하고 출력하게 될 것입니다.

그렇게 되면 점점 자체 클라이언트의 비중은 줄어들게 되겠죠?

 

주요 기능

1) 화면 캡처

2) OCR 추출

3) 추출된 OCR번역

4) 화면에 번역 정보 출력

5) 수집된 정보 업로드

6) 번역 정보 다운로드

 

 

 

수정 이력

 

2017.04.25

- 초안 작성