Loading...
 
Skip to main content

번역 분기 전략

 경고
영어 원문의 작성 자체가 매끄럽지 못하여 한글 번역의 결과가 썩 좋지 못합니다. 양해 바랍니다
 경고
번역이 가능한 최종 사용자에 대한 모든 정보는 tiki.org 상의 작업 공간에 있어야 합니다


정책은 번역들이 이제 대부분의 경우 예외가 없다는 것이며, 변경은 트렁크 안에서 이루어지며 원하는 경우 backport 될 수 있다는 것입니다 (비록 backport 는 여전히 수정되어야 할 필요가 없어야 합니다만).

반자동 병합 기간 동안에는 (예: 7.x 이전부터 7.1 까지), 7.x 상의 변경이 트렁크로 병합되리라는 보장이 없습니다. 변경은 충돌이 없을 경우 병합되어야 합니다, 하지만 그 외의 경우 무시될 수도 있습니다. 사람들은 트렁크에 커밋하고 7.x로 backport해야 합니다. 그렇지 않다면, 7.x로 커밋하는 사람들은 그들이 가한 변경이 다음 반자동 병합 동안 트렁크로 적절하게 병합된다는 것을 확인해야하는 책임이 있습니다.

만약 누군가 어떤 언어에 대하여 병합을 처리할 의사가 있다면, 의사를 표현해주십시오 그러면 좀 더 많은 기여를 옹호하는 쪽으로 정책이 변경될 수도 있습니다.

언어 파일 병합하는 법

다른 분기에서 언어를 병합하려면 doc/devtools/mergelang.php 스크립트를 사용해야 합니다.

7.x 를 귀하께서 트렁크에서 Brazilian Portuguese (pt-br) 파일로 작업하신 몇몇 번역으로 갱신하고 싶다고 가정 해 봅시다.

먼저 해야할 일은 7.x 내부의 language.php 파일이 갱신되었다는 것을 확인하는 것입니다. 분기 폴더 내부에서 get_strings.php 를 실행하면 티키로 추가된 새 문자열을 얻게 될 것이빈다:

php get_strings.php lang=pt-br

그리고 나서 mergelang.php:

php doc/devtools/mergelang.php pathToTikiTrunk pathToTiki7x lang=pt-br

여기서 pathToTikiTrunk 는 트렁크 루트 디렉터리로의 경로이고 pathToTiki7x 는 7.x 루트디렉터리 입니다. lang 은 한 개의 언어 코드 혹은 쉼표로 구분된 언어 코드들의 목록일 수 있습니다. 이 매개변수는 선택적이며, 누락을 하게되면, 모든 언어파일들이 갱신될 것입니다.

이 스크립트가 양 파일 내부에서 발견하는 각각의 영어 문자열에 대하여, 7.x 버전 내부의 번역을 트렁크 버전으로부터의 번역으로 교체할 것입니다 (문자열이 7.x 내부에서 번역되어있지 않은 경우에도).

i18n.tiki.org

i18n.tiki.org 는 항상 트렁크 (개발 중인 티키의 다음 버전) 를 사용할 것입니다. 정기적으로 (매 1-2주마다) Rodrigo 가 그곳에서 이루어진 번역을 SVN 리포지터리 (의 트렁크) 로 내보내기를 할 것입니다. i18n.tiki.org 내부의 데이터베이스에서의 번역을 내보내기 전에, 그는 language.php 파일들을 업데이트하게 됩니다, 그러면 이 절차상에서 그 어떤 번역도 누락되지 않을 것입니다.

토론

문제


다음이 바로 문제입니다:

http://old.nabble.com/language.php%3A-trunk-versus-3.0-tt23746165.html

번역이 관리되는 방식 내부에서 2 개의 충돌하는 것들이 모두 선호되기도 합니다 :

  • 가장 많은 기여를 얻기 위하여 번역가의 작업을 가능한 쉽고 즉시 그들에게 유용하게 만드는 것.
  • 새 번역에 의하여 야기되는 병합을 수행하는 코더의 업무를 최소화하여 병합이 자주 발생하고 번역이 손실되지 않는 것.


정책은 번역가들이 번역을 안정화 분기로 커밋할 수 있고 그 번역들이 트렁크로 병합되는 것이었습니다. 불행하게도 이는 그 누구도 병합을 수행하지 않았고 번역이 손실되었기 때문에 잘 안되었습니담.

문제는 language.php 내부의 문자열이 항상 같은 순서로 머무르지 않기 때문에, (문자열에 문자열의) 병합이 악몽스러운 일이 될 수 있다는 것입니다. 일반적으로, 병합을 하는 사람들이 제공되는 언어들의 일부만을 알기 때문에, 충돌을 처리하는 것은 하나의 도전이기도 합니다. 하지만, 이 문제에 대한 하나의 쉬운 해결잭은 language.php 내부의 모든 줄을 알파벳 순서로 정렬을 하는 것입니다, 그렇게 된다면 버전에 상관없이 같은 순서로 놓이게 되며 됩니다, 이와 함께 language.php 의 트렁크 버전의 여기저기 중간에는 새 줄들이 포함이 되어있을 것이며, 동시에 어떤 줄들은 없어져있을 것입니다. Xavi 님이 아는 바로는, 단순한 편집기 (GNU/Linux-Gnome 의 gedit과 같은 것, 그리고 다른 운영체제에 있는 많은 유사한 것들) 는 "// 텍스트"르 시작하는 줄들을 "텍스트"로 시작하는 것처럼 이미 처리하고 있어서, 어느 한 줄을 (한 번 알파벳순으로 정렬이 되고나면) 그 자체가 이미 번역되었는지 아닌지 여부에 상관없이 동일한 위치에 유지한다는 것입니다.

선택사항

트렁크로 번역을 하고, 자동 backport 를 없애는 것 (안전한 방법)

번역가들이 자신들이 원하는 바에 따라 분기로 backport를 하는 것을 결정합니다.

  • backport가 없는 경우, 사람들이 사용을 하게되려면 다음 메이저 버전까지 기다려야만 합니닼.


문제점:

  • 번역가들이 번역을 즉시 사용하고 싶은 경우 직접 backport를 해야하기 때문에 더 적은 번역내역이 기여될 수 있습니다.

트렁크로 번역을하고, 안정화 분기로 자동 backport?

  • 사람들은 backport되지 않은 새 번역을 얻기위해 새 메이저 버전을 기다리지 않아도 됩니다


문제점:

  • 자원봉사자가 backport 를 수행하는 것에 의존

안정화 분기로 번역을하고, 위로 병합 (merge up)을 함


문제점:

  • 자원봉사자가 병합을 수행하는 것에 의존

버전이 부여되지 않은 (Unversioned) 번역 파일들

분기 당 하나의 번역을 보유하는 대신, 한 개의 트리에서 떨어져 나간 번역 파일이 사용되는 것입니다. 이는 병합 문제를 피할 수 있습니다.

로드맵

이상적으로는 저희는 버전이 부여되지 않은 번역 파일들로 이동해야 합니다.

이 방식이 가지는 하나의 단점은 특정 버전에서 사용되지 않는 몇몇의 번역을 포함한다는 것입니다. 하지만, 어떤 한 버전이 어떤 번역을 사용하는지를 말해주는 경우, 사용되지 않는 번역을 떼어내는 것이 가능합니다. 현재의 번역들은 사용될 수도 있지만 get_strings 가 사용되는 것으로 감지하지 않는 사용되지 않는 번역 섹션을 보유하고 있습니다. 모든 번역된 문자열이 적절하게 코드 내부에서 표식이 된다면, 떼어내기는 안전하며 가능한 것이 될 것입니다.

하지만, 저희가 염두에 두어야 하는 것은 mods가 동일한 한 개의 그리고 중앙의 language.php 파일을 그들의 번역에 대하여 사용했다는 것입니다. 그래서 누군가 (잠정적으로) 떼어낼 문자열을 검토하면, 어떤 mods가 번역한 많은 문자열이 번역된 것을 보유하고 있는 번역 (Catalan과 같은) 에 대하여 어떤 해결책이 제공되어야만 합니다 (현재와 잠정적으로 미래에서도 마찬가지 입니다). 잠정적 해결책:

  • lang/xx/ 폴더 하에 부가적 php 파일들을 추가할 어떤 방법 , mods가 제공하게 됨, 그리고 티키가 그들을 발견하게 되는 경우 사용됨 (custom.php 와 유사). mod 당 하나의 추가 파일.
  • 누구든지 잠재적으로 사용하지 않는 문자열을 검토할 때, 해당 버전에 사용되는 모든 mods를 설치한다 (어떤 것은 작동을 할 것이고, 이는 비록 그러한 mods들이 티키의 이전 혹은 지정되지 않은 버전에서만 작동하는 것으로 태그되었을 지라도 그러하다)
  • Mods에서 language.php-s 를 패치
  • 스트립되지 않을 문자열을 정의하는 파일을 보유

제안


(Torsten)

트렁크에서 번역을 하고 backport를 하지 않는다, 하지만 매우 활발하게 번역된느 특정 언어들에 대하여 다운로드 링크를 제공한다.

이 몇몇 개의 파일들을 정기적으로 트렁크에서 갱신한다.

더 이상 사용되지 않지만 이전 버전 내부에서 필요했던 문자열들을, 그 해당 이전 버전이 지원되는 기간동안은 트렁크에 유지한다.


그렇게 되면 사이트관리자는 단순히 하나 혹은 몇 개의 language.php를 다운로드하고 /lang/XYZ로 복사하여 직접 개별 언어(들)를 backport 할 수 있을 것이다 .

어찌되었건 특정 사용자 지정 번역에 대하여 이것이 관리자에 의하여 고려될 것이다.
(전자에 대하여, 내 사이트 중 하나에서 "외침상자"는 "roadbook"로 되어있다, 이는 매우 개별적인 것이며 메인 코드베이스를 위한 것이 아니다 - 이러한 번역이 여러개 있다)

관련 내용


Page last modified on Thursday 07 March 2013 08:48:28 GMT-0000