[강좌] 오픈소스 프로그램 한글화하기 - 4
2009/04/13 03:25
관련 글 목록
이제 마지막으로 힘들게 번역한 한글파일을 배포해보자.
배포하는 방법은 총 세 가지 정도가 있다. 하나는 배포 안하기, 두번째는 개인 사이트나 커뮤니티를 통해 배포하기, 그리고 세번째는 원 프로그램 프로젝트에 포함시켜 배포하기. 물론 절대적으로 권장되는 것은 세번째이다.
많은 사람들이 번역을 한 뒤에 이 과정을 빼먹어서 열심히 번역한 작업물을 그냥 사장시키는 경우가 많다.
번역을 했으면 꼭 메인 프로젝트에 업로드를 하자!
1. 번역 재검토(번역 가이드와 ko-po-check)
2. 패치 파일 만들기
3. 프로젝트별 번역 기여 방법 알아하기
4. 기타..
- 오픈소스 프로그램 한글화하기 - 1 : i18n 방식 파악
- 오픈소스 프로그램 한글화하기 - 2 : 실제 번역
- 오픈소스 프로그램 한글화하기 - 3 : 번역 테스트
- 오픈소스 프로그램 한글화하기 - 4 : 개발팀에 패치 전달
- 오픈소스 프로그램 한글화하기 - 2 : 실제 번역
- 오픈소스 프로그램 한글화하기 - 3 : 번역 테스트
- 오픈소스 프로그램 한글화하기 - 4 : 개발팀에 패치 전달
이제 마지막으로 힘들게 번역한 한글파일을 배포해보자.
배포하는 방법은 총 세 가지 정도가 있다. 하나는 배포 안하기, 두번째는 개인 사이트나 커뮤니티를 통해 배포하기, 그리고 세번째는 원 프로그램 프로젝트에 포함시켜 배포하기. 물론 절대적으로 권장되는 것은 세번째이다.
많은 사람들이 번역을 한 뒤에 이 과정을 빼먹어서 열심히 번역한 작업물을 그냥 사장시키는 경우가 많다.
번역을 했으면 꼭 메인 프로젝트에 업로드를 하자!
1. 번역 재검토(번역 가이드와 ko-po-check)
이제까지는 단순 번역에 대한 이야기를 해왔지만, 이 작업물을 배포하려면 다른 부분까지 신경을 써야 한다.
즉, 이 번역이 과연 누구를 위한 것인가? 라는 부분이다.
배포를 고려하지 않았다면 아무래도 관계없다. 하지만 배포를 고려한다면 다음과 같은 사항을 준수해야 한다.
이러한 내용은 직접 소스를 재 검토하거나 번역 가이드와 ko-po-check 를 통해 확인해 볼 수 있다.
사실 번역가이드는 번역을 실제로 행하기 전에 보는 것이 좋은데, 이렇게 뒤늦게 이야기하는 것은 초보자에게 부담을 주지 않기 위해서이다. 필자는 처음은 자기 멋대로 번역하고, 그 후에 자신의 스타일과 많은 사람들이 권장하는 스타일의 차이를 확인하고 수정하는 것을 권한다. 특히 대부분의 경우 1000 스트링 미만의 작은 프로그램을 번역하기 때문에 나중에 고친다고 해도 큰 부담이 가지는 않으므로 퇴고를 한다는 느낌으로 뒷 부분에서 이야기를 한다.
필자가 권고하는 번역 가이드는 다음과 같다.
- 모질라 한국어 스타일 가이드
- 스타스위트 한국어 스타일 가이드
- 한국어 지역화 스타일 가이드
가이드를 참고하여 잘못된 부분들을 수정했으면, 이젠 ko-po-check 를 이용해 기계적인 확인을 더 해 보자.
ko-po-check 는 그놈용 프로그램의 번역에서 자주 실수하는 부분들을 확인하기 위한 프로그램이다. 이는 리눅스 환경에서 동작하지만, 윈도우즈에서도 사용할 수 있다.
- ko-po-check 다운로드
- 윈도우에서 ko-po-check 사용하기
ko-po-check 시에 자주 등장하는 오류는 '~을(를)' 등의 조사부분과 mnemonic 이다. mnemonic 은 메뉴 옆에 있는 빠른 접근키로, 예를 들어 "저장(S)" 가 있다면, S 가 바로 mnemonic 이다.
즉, 이 번역이 과연 누구를 위한 것인가? 라는 부분이다.
배포를 고려하지 않았다면 아무래도 관계없다. 하지만 배포를 고려한다면 다음과 같은 사항을 준수해야 한다.
- 평이하고 자주 사용되는 단어를 사용하였는가? : 지나친 외국어 음차도 문제지만, 지나친 순한글화도 문제이다.
- 기존의 프로그램들에서 사용한 단어나 번역 스타일과 지나치게 다르지는 않은가?
- 번역 가이드에 맞춰 번역을 하였는가?
이러한 내용은 직접 소스를 재 검토하거나 번역 가이드와 ko-po-check 를 통해 확인해 볼 수 있다.
사실 번역가이드는 번역을 실제로 행하기 전에 보는 것이 좋은데, 이렇게 뒤늦게 이야기하는 것은 초보자에게 부담을 주지 않기 위해서이다. 필자는 처음은 자기 멋대로 번역하고, 그 후에 자신의 스타일과 많은 사람들이 권장하는 스타일의 차이를 확인하고 수정하는 것을 권한다. 특히 대부분의 경우 1000 스트링 미만의 작은 프로그램을 번역하기 때문에 나중에 고친다고 해도 큰 부담이 가지는 않으므로 퇴고를 한다는 느낌으로 뒷 부분에서 이야기를 한다.
필자가 권고하는 번역 가이드는 다음과 같다.
- 모질라 한국어 스타일 가이드
- 스타스위트 한국어 스타일 가이드
- 한국어 지역화 스타일 가이드
가이드를 참고하여 잘못된 부분들을 수정했으면, 이젠 ko-po-check 를 이용해 기계적인 확인을 더 해 보자.
ko-po-check 는 그놈용 프로그램의 번역에서 자주 실수하는 부분들을 확인하기 위한 프로그램이다. 이는 리눅스 환경에서 동작하지만, 윈도우즈에서도 사용할 수 있다.
- ko-po-check 다운로드
- 윈도우에서 ko-po-check 사용하기
ko-po-check 시에 자주 등장하는 오류는 '~을(를)' 등의 조사부분과 mnemonic 이다. mnemonic 은 메뉴 옆에 있는 빠른 접근키로, 예를 들어 "저장(S)" 가 있다면, S 가 바로 mnemonic 이다.
2. 패치 파일 만들기
번역한 언어팩 파일을 원 프로그램의 소스에 포함시키려면 패치를 만들어 관련 프로젝트에 보내주어야 한다.
그런데 언어팩의 경우 사실 반드시 패치파일을 작성할 필요는 없다. 그저 번역 소스인 .po 파일을 보내주기만 해도 된다. 다만 패치를 요구하는 프로젝트도 있으니 알아두는 편이 좋다. 참고로 필자의 경우 최초 번역물을 보낼때 3가지를 보내곤 한다. 원 번역본, 수정본, 패치)
패치를 작성하는 요령은 간단하다.
그런데 언어팩의 경우 사실 반드시 패치파일을 작성할 필요는 없다. 그저 번역 소스인 .po 파일을 보내주기만 해도 된다. 다만 패치를 요구하는 프로젝트도 있으니 알아두는 편이 좋다. 참고로 필자의 경우 최초 번역물을 보낼때 3가지를 보내곤 한다. 원 번역본, 수정본, 패치)
패치를 작성하는 요령은 간단하다.
$ diff -uNr new_ko.po old_ko.po > ko.patch이러면 두 파일간의 차이점이 ko.patch 파일에 예쁘게 정리된다. 패치를 요구하는 경우 이 파일을 보내면 된다.
3. 프로젝트별 번역 기여 방법 알아하기
프로젝트마다 번역물을 다루는 방식이 조금씩 다르다.
예를 들어 단순히 주요 개발자 이메일을 통해 새 번역물을 받는 경우도 있고, 메일링을 통해 보내야 하는 경우도 있고, 커뮤니티 게시판을 이용해야 하는 경우도 있다. 해당 프로젝트 사이트를 방문하여 번역 기여 방법에 대한 부분을 찾아보자.
대부분의 프로젝트에는 번역을 비롯한 각종 기여에 대한 안내서가 잘 작성이 되어 있다.
해당 내용을 잘 따라하며, 혹시 없을 경우에는 제작자나 포럼에 문의를 하자. 문의할때는 꼭 파일을 첨부하고, 파일은 다른 곳에 올려 링크로 첨부하는 쪽이 좋다.
예를 들어 단순히 주요 개발자 이메일을 통해 새 번역물을 받는 경우도 있고, 메일링을 통해 보내야 하는 경우도 있고, 커뮤니티 게시판을 이용해야 하는 경우도 있다. 해당 프로젝트 사이트를 방문하여 번역 기여 방법에 대한 부분을 찾아보자.
대부분의 프로젝트에는 번역을 비롯한 각종 기여에 대한 안내서가 잘 작성이 되어 있다.
해당 내용을 잘 따라하며, 혹시 없을 경우에는 제작자나 포럼에 문의를 하자. 문의할때는 꼭 파일을 첨부하고, 파일은 다른 곳에 올려 링크로 첨부하는 쪽이 좋다.
4. 기타..
프로그램을 번역하는 것도 중요하지만, 정작 더 중요한 것은 해당 프로그램에 대한 지속적인 관심이다.
그리고 누구든 한 번에 100% 완벽한 번역을 할 수는 없다. 번역 자체의 미완성성도 있지만, 각 문자열이 실제로 어디서 사용되는지 모르고 번역하는 경우가 많기 때문에, 프로그램 UI 번역은 1차 번역 이후에 많은 수정을 요구하게 된다.
따라서 번역을 완성한 뒤에, 번역물이 메인 프로그램과 함께 배포된 후라도 지속적으로 관심을 갖으며 오역이 없는지 확인하는 것이 좋다. 꾸준히 오역을 확인하면서 꾸준히 고쳐나가는 것. 실제 번역도 중요하지만 이 또한 그 무엇보다 중요한 일이다.
그리고 누구든 한 번에 100% 완벽한 번역을 할 수는 없다. 번역 자체의 미완성성도 있지만, 각 문자열이 실제로 어디서 사용되는지 모르고 번역하는 경우가 많기 때문에, 프로그램 UI 번역은 1차 번역 이후에 많은 수정을 요구하게 된다.
따라서 번역을 완성한 뒤에, 번역물이 메인 프로그램과 함께 배포된 후라도 지속적으로 관심을 갖으며 오역이 없는지 확인하는 것이 좋다. 꾸준히 오역을 확인하면서 꾸준히 고쳐나가는 것. 실제 번역도 중요하지만 이 또한 그 무엇보다 중요한 일이다.
오호! 번역 가이드라는 것이 있었군요. 번역에 많은 도움이 되겠습니다.
한국어 PO 파일 검사툴(ko-po-check)도 며칠전에 북마크 해 두었는데 사용법까지 올리셨네요. 감사 드립니다.