안녕하세요. 
첫 포스팅은 번역과 GitHub란 주제로 시작해보려합니다. 이번 글에서는 간략히 GitHub 환경에서 번역 프로젝트가 실제로 어떤 프로세스로 진행되는지 소개하고, GitHub 기반 번역 프로젝트에서 발생할 수 있는 문제점들을 살펴보겠습니다. 이어지는 포스팅에서는 이러한 문제점들을 해결하는데 도움을 줄 수 있는 번역 플랫폼(crowdin, transifex 등)의 주요 특징과 장단점을 알아보도록 하겠습니다.
GitHub 에서는 개발 문서, 지역화, 자습서 등 다양한 영역에서 번역 프로젝트가 진행되고 있습니다. 몇 가지만 예를 들어보겠습니다.
로케일과 관련된 파일들을 이용해 메뉴나 안내 메시지 등을 지역화(localization)
ex) steemit 의 condenser
영문으로 작성된 모든 콘텐츠를 대상으로 다국어 또는 특정 언어 번역 지원
ex) Go 언어 specification 번역 프로젝트
개발 관련 홈페이지와 자습서
ex) facebook 의 React
이처럼 수많은 프로젝트들이 GitHub 워크플로우를 이용해 번역 프로젝트 일정과 품질을 관리하고 있습니다. 편의를 위해 GitHub와의 동기화를 지원하는 crowdin 같은 번역 플랫폼들을 이용해 번역을 진행하는 경우도 있습니다.
그럼, 이제 번역 프로젝트가 실제로 어떤 과정을 통해 진행되는지 알아보도록 하죠. 분야마다 차이가 조금씩은 있겠지만 제가 활동하고 있는 Go 언어 specification 번역 프로젝트를 기준으로 번역 진행 과정을 설명드리겠습니다.
번역 지원자 모집 - PR 생성 - Review - Merge - GitBook 포스팅 - Proof of Reading - Issue 생성 - Contents Update(PR)
번역 지원자 모집:
페이스북을 이용해 지원자 모집을 홍보했구요, 구글 스프레드시트를 이용해 지원자 현황을 관리했습니다.
PR 생성
번역 지원자가 마크다운 포맷으로 작성된 영어 원문을 번역한 후 Pull Request(PR)를 생성합니다. PR은 자신의 작업을 프로젝트에 반영해달라고 요청하는 절차라고 이해하시면 되겠습니다.
Review
관리자, proof of reader, 프로젝트 참가자들이 함께 PR 에 대한 리뷰를 진행합니다. 리뷰과정에서 서로 의견을 조율하고 합의된 의견은 다시 PR 에 반영됩니다.
Merge
리뷰가 완료된 PR은 master 브랜치로 merge 합니다.
GitBook 포스팅
master 브랜치에 새로운 PR 이 merge 되면 온라인 출판 도구인 GitBook 포스팅이 자동으로 빌드되어 새로운 출판물을 생성합니다.
Proof of Reading
GitBook 을 통해 새롭게 빌드된 출판물 결과를 확인하고 다시 한번 Proof of Reading을 진행합니다.
Issue 생성
번역 문서와 관련된 용어 문의, 잘못된 설명, 개선된 번역문 제시 등은 GitHub issue 게시판을 통해 이루어집니다.
Contents Update(PR)
issue 에서 논의된 내용들 중에 개선이 필요한 부분은 새로운 PR을 통해 프로젝트에 반영합니다.
이후부터는 PR 생성으로 시작해서 PR 생성으로 끝나는 과정의 연속입니다.
https://github.com/golangkorea/golang-spec/pull/142 에는 코멘트가 32개나 달려있네요. 열띤 토론은 리뷰의 필수!
추가로, 번역을 진행하기 전에 가이드라인 문서를 작성해서 번역 참가자들과 공유하면 올바른 번역 지침을 제시할 수 있고, 참가자의 의견을 받아서 꾸준히 문서를 업데이트하면 번역 프로젝트를 관리하는데 많은 도움이 됩니다.
하나의 번역 결과물을 만들기 위해서는 번역자부터 리뷰어, 버그 리포터 등의 활발한 참여가 요구되며, 번역 품질은 이들의 열정에 의해 결정된다고 보시면 되겠습니다. 한 명이 잘해서 되는 일이 결코 아닙니다.
다음으로, 이같은 GitHub 워크플로우로 번역 프로젝트를 진행했을때 어떤 문제가 발생할 수 있는지 알아보겠습니다.
GitHub 만을 이용해서 번역 프로젝트를 진행했을때, 아래와 같은 문제가 발생할 수 있습니다.
우선, 진행 현황 관리가 힘들 수 있습니다. 다행히, GitHub에서는 issue/PR 에 대한 milesstone 을 설정하면 이 문제를 어느 정도까지는 해결할 수 있습니다.
milesstone에 포함된 issue 들이 닫힐 때마다 프로젝트 진행 상황이 일정 비율씩 증가하게 됩니다.
https://github.com/golangkorea/golang-spec/milestones
번역은 44% 가 완료되었네요.
PR을 기준으로 milesstone을 설정하는 방식은 Go 언어 specification 번역 프로젝트와는 어울리지 않아서 issue에 대한 milesstone 만 적용했고, milesstone과 관련된 issue에는 별도의 label을 부여하여 issue에서 필터 처리할 수 있게 조치했습니다.
하지만, GitHub 에서 제공하는 기능 중에 특정 챕터를 담당한 번역 지원자가 현재 번역을 진행하고 있는지 여부를 파악할 수 있는 기능은 아직 없습니다. 개별 작업 현황을 파악할 수 없다는 것은 관리자나 또 다른 번역 지원자 입장에서 보면 굉장히 효율적이지 못한 일입니다. GitHub에서 개별 번역자에게 부여된 번역작업이 현재 진행 중인지, 한동안 아무 일도 일어나지 않았는지 알려줄 수 있는 도구가 있다면 얼마나 좋을까요? (Crowdin에서 제공하는 task 가 이러한 기능을 제공합니다. 야호!)
또 다른 문제는 번역 지원자들의 진입 장벽입니다. 개발자가 아닌 이상 GitHub 기반의 번역 프로젝트는 굉장히 낯설고 어렵게 느껴질 수 있습니다. 이로 인해 훌륭한 번역자들이 프로젝트에 참가하지 못하게 되는 현상이 발생할 수 있습니다. fork, merge, PR 등의 개념을 익히고 번역을 시작해야 한다면 번역 프로젝트에 참여자들을 많이 끌어들일 수 없을 것입니다.
마지막으로 원문 업데이트 대응 문제가 있을 수 있습니다. 제가 참여하고 있는 Go 언어 specification 번역 프로젝트를 예로 들어볼까요? 이 프로젝트는 Go 버전 1.9 를 기준으로 작성된 스펙 문서를 기준으로 번역을 진행하고 있습니다. 2018년 2월에 Go 버전 1.10 이 출시되면 스펙 문서도 함께 업데이트 됩니다. 번역 프로젝트에서는 이에 대해 어떻게 대응할 수 있을까요? 현재 GitHub에서 제공하는 기능으로는 대응 방법이 마땅치 않습니다. 보통은 영어 원문 내용에서 변경된 내용을 하나씩 찾아서 번역문에 반영하는 방법이 거의 유일한 해결책이라고 보시면 됩니다.
다음 포스팅에서는 이러한 문제점들을 어느 정도 해소해주는 번역 플랫폼 Crowdin에 대해서 다루도록 하겠습니다. 짧지 않은 글을 읽는데 소중한 시간을 내어주셔서 감사드립니다. 일주일 뒤에 다시 뵙겠습니다.
