[ja-discuss] Re: [ja-discuss] master翻訳プロセスの開始について

小笠原です。


いくやさんのメールを読んで、

> > 2. 開発中のプロジェクト（例：5.0）に対しては、RC3までは同じ
> >    変更を手で反映する（提案者は両方に提案を行い、査読者は両
> >    方を査読する）

これはまったくの悪手だなということに今更ながら気づきました。
どうやるかの方法論はさておいて、

> branchで翻訳した後masterに反映させる

方が、時間的余裕はあきらかにあるので、その方針を採りたいと思います。


プロセスとしては：

1. リリースの谷間（前のバージョンの .0リリース〜新バージョンのβ）
   に関しては、変更は必ず master に反映する。

1-1. リリースされたものに適用したほうがよい変更、すなわち明らか
   な誤りなどについては、masterおよび任意のブランチに提案を行い、
   MLでその旨知らせる。
   変更内容については変更が適用された時点でwikiに記載する。
   （これは原則、今までの変更ルールと同じ）

2. 新バージョンのβリリース〜.0リリースについては、変更は最新の
   ブランチに反映する。

3. .0リリースが出た後、翻訳コーディネータはブランチの変更を
   masterに反映する。（方法はTBD）

という感じで如何でしょう。＞みなさん


L10N MLでの議論によれば、masterの存在を完全に無視して、
ブランチだけで作業すれば今までと同じプロセスになるので、
各国語翻訳プロジェクトとしてはそういう選択もありうる、とのこと
でしたが：

・9週間という短納期に縛られず翻訳ができる
・翻訳の仮定でnightlyなどを用いて新機能を見る機会が増えるので、
  先行して機能把握がしやすくなる

というメリットもまた捨てがたいところがあるので、個人的にはmaster
プロジェクトを活用する方法を考えたいところではあります。

# が、そこのところも、もちろん議論の余地はあります。


> branch作成前に翻訳するというのも手ではあるのですが、新機能が出揃ってな
> いので結局のところ中途半端になります。
> そう考えると、branchの作成タイミングをBetaリリース時じゃなくてRCリリー
> ス時にする、というのが落としどころとして悪くない気がしてきました。

なるほど、それは一つのアイディアですね。

あまり英語は得意でないので、MLなどでタフな交渉をするのは正直、
私としてはしんどいです。が。

お約束できるわけではないですが、今年のLibO Confにて、NLP BoFを
コミュニティデーでやるよという案内をもらっています。
その席で交渉を試みるのは可能かもしれません。面と向かってるほうが、
まだやりやすいので。


では。
-- 
Naruhiko Ogasawara (naruoga@gmail.com)

-- 
Unsubscribe instructions: E-mail to discuss+unsubscribe@ja.libreoffice.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/ja/discuss/
All messages sent to this list will be publicly archived and cannot be deleted