Drupal 7 コアの翻訳スプリントをしませんか？
先日 Drupal 7 alpha 1 がリリースされ，D7 の開発も最終段階に入ったように感じています。Drupal 7 が正式リリースされたらエンドユーザーの皆さんがすぐに日本語環境で使用開始できるよう，近日中に翻訳スプリントをしませんか？
Drupal 7 正式リリースまで，あと 60 日！？
Drupal 7 code freeze: status update and next steps によれば，2009/10/31 時点で重要な問題は 403 ありました。これが 2010/2/15 時点で 149 に減っている事から，約 100 日間で 250 の重要な問題を消したことになり，これは言い換えると１日あたり 2.5 の問題解消ということができます。ですから，現在残っている問題を消化するのに，約 60 日間かかる計算になります（実際には計算通り進まないでしょう。この計算はすごく乱暴な推測と思ってください）。
Drupal 7 の日本語翻訳状況は？
l.d.o. にアカウントを持っていると，ここで D7 コアの文字列リストを見ることができます。たぶん。もしかしたら一般アカウントの人は見られないかもしれません。その際はごめんなさい。
そのリストを見ると，2010/2/15 13:15 JST 時点で Drupal 7 コアには全部で 4,290 の文字列があって，そのうち 2,580（60.1%）が翻訳済みのようです。言い方を変えると，まだ 40% も未翻訳の文字列が残っています。
○○スプリントとは
（僕自身何らかの「スプリント」に参加したことがないのでこれから述べる解釈は正確ではないかもしれませんが）僕が理解している○○スプリントとは，「あるプログラムを書く，ある機能をソフトウェアに実装する，バグを潰す，マニュアルなどのドキュメントを整備するなど，何らかのアクションを短期間で起こすために，有志が集まって集中して共同作業をすること」だと思っています。
今回の場合，Drupal 7 コアの日本語翻訳を集中して行うことが目的となります。
具体的には
具体的に翻訳スプリントを実施するには，いくつか考えるべきことがあると思います。
まず，場所と日時です。残された時間とやるべき作業のことを考えると，定期的（たとえば２週間おきぐらい？）に D7 正式リリースまで複数回，数時間（３〜４時間？），何人かで集まって作業することが望ましいと思います。場所はどこが参加者にとって便利なのか，平日の夕方がいいのか週末がいいのか，などをこれから検討しなくてはなりません。
何を訳すか限定することも必要でしょう。僕の個人的な意見では，(1) インストール直後のまっさらな状態のシステムが提供するユーザーインターフェース，(2) ヘルプ，にまず集中するのが良いのではないかと思っています。その後余力があればコア・ディストリビューションに含まれるオプションのモジュール群の翻訳をするという案はどうでしょうか。
実際の作業方法も考えなくてはなりません。一応僕のサーバーに D7 と今日時点の D7 日本語翻訳をセットアップしてみました。これを参加者の皆さんで共有してもらうことを考えています。ごく一部のセキュリティ上すごく重要な部分を除いて，ほぼ管理者として振る舞ってもらえるように設定しました。ただ，このままではあまり翻訳作業に適しているとは思いませんので，翻訳に便利なモジュールや，作業手順などをご提案いただきたいと思います。
[2010/2/16 00:46 JST 追記]
一応 Localization Client モジュールをインストールしてみましたが，翻訳インターフェースが表示されません。
[2010/2/16 01:01 JST 追記]
と思ったら，翻訳インターフェースが使えるようになっていました。現在表示されている画面を見て，どういう状況でオリジナルの英文が使われているのかを理解した上で日本語翻訳が可能のようです。
必要なものも要検討でしょう。先述のように僕のサーバーにインストールされた D7 を参照しながら，あるいはこの D7 インストレーション上で作業するとすれば，インターネットへの接続が必須です。そのほか，電源，机，椅子，スナック，ドリンクなどが必要と思われます。
参加者
世界中から認められ，どんどんと勢いを増しつつあるこの Drupal という素晴らしいソフトウェア／プロジェクトに，何らかの形で参加したい人は誰でも参加していただいて構わないと思います。Drupal 歴の長さ，英語の上手・下手も問わなくていいんじゃないかと考えています。みんなで集まって作業するので，分からない点などがあればすぐ横の人に尋ねる事ができ，一人で作業するよりもより効率よく翻訳を進めることができると思います。
さいごに
最悪，全然人が集まらず，２〜３人ぐらいでカフェなんかで作業することになるかもしれません。Drupal プロジェクトへの参加を楽しめればいいかな，ぐらいに気楽に考えています。
ご意見をお待ちしています。
Comments
スプリントの解釈はそれで合っています。同じ場所で作業をする
スプリントの解釈はそれで合っています。同じ場所で作業をすることで、コミュニケーションが円滑になり、効率が飛躍的にアップします。Drupalconでは丸一日やりますが(Paris以降二日に増えた)、それは半年に一度だからという希少性も作用していると思うので、それほど極端である必要はないと思います。
スプリントに関して一昨日aiwata55氏とIRCの#drupal-jpチャンネルにて話し合っていたので、その内容を共有するかたちで提案をします。
ペアによる翻訳
せっかく皆が集まるので、ペアになって翻訳するのが良いと思います。より良い日本語の言い回しを思い付いたり、不正確な翻訳が入り込むのを防ぐ効果が期待できます。
Quality Assurance(品質保証)
翻訳するだけではなく、翻訳が終わったセクション(例えばブロック管理画面)をレビューし、複数人による翻訳にも一貫性が保たれていることを確認する作業です。これは既存翻訳の修正に当たりますが、システム全体にわたる重要な変更でないこと、またアドミニが最低二人スプリントに参加していることを条件として、スプリント期間中は参加者だけで変更を決定して構わないでしょう。スプリントは迅速さが利点なので、それを奪うべきではないと思います。
参加者
他のスレッドにも書きましたが、翻訳ができなくても、日本語が上手な人が参加してくれるだけで品質の向上につながると思います。また、Drupalを知りすぎているがために初心者に分かりにくい翻訳になりうることもあると思います。aiwata55さんの提案する通り、Drupalに興味のある方なら誰でも参加してもらうのが良いと思います。
翻訳スプリントは、僕が４月に一時帰国する際に提案しようと思っていたのだけど、それだとさすがに遅いので、是非すぐに開始してください。４月にD7がリリースされていない場合、僕もQuality Assuranceに参加します。
翻訳スプリント面白そうですね
でも東京でやるんですよね。
ということで、関西でも開催したいと思います。
http://localize.drupal.org/node/963
admin である PineRay さんにも協力して頂けるようなので、安心して(?)お気軽にご参加ください。
とりあえず，第一回目の場所と日時の提案
とりあえず第一回目の場所と日時を僕のほうで提案したいと思います。
11:00〜15:00
（東急 田園都市線 二子玉川駅前）
電波が入るかどうか分かりませんが，WiMax の WiFi ルーターを持っていきます。
急な提案なので誰も都合が付けられないかもしれませんが，それはそれで構いません。これきりで終わるものでもないので，改めて第二回をきちんと企画しましょう。
みなさんの参加をお待ちしています。
第一回レポート
告知から実施まであまり時間がなかったせいか，非常に小さな会となってしまいました。しかし，イギリスから dokumori さんが参加してくれました。時差があってイギリスは夜中だったにも関わらず，ありがとうございました。
人数が少なかったので，地道に翻訳を進めるよりも，この翻訳グループの皆さんが今後効率よく翻訳を進められるような環境整備にスプリントの時間を使おうという提案を dokumori さんからいただきました。それを受けて，第一回翻訳スプリントは，翻訳ソフトウェアの評価と，翻訳ソフトウェアを使ったワークフローの検討をしました。
最初に ryo さんからここでご紹介いただいた，Google Translation Toolkit (GTT) をしばらく操作したりマニュアルを調べたりしましたが，
という印象を持ちました。
その後，Poedit というフリーソフトウェアを使ってみました。こちらは
という印象を持ちました。とくに，翻訳メモリーをグループで共有できないというのは大きな欠点だと思います。
こうしてさまざまなリサーチを行った結果，私たちの作業には
が必要ではないかと感じました。
この条件を満たすソリューションの一つが，
というワークフローかと思います。が，書いていても思いましたが，非常に煩雑で，問題が起きやすいソリューションだと思われます。また，何よりも，ローカルで実際の翻訳作業を行うため，今作業中のプロジェクト（Drupal コアとか，Views とか）を他の誰かが翻訳中かどうかが分からず，そのためグループ内で作業が重複しかねない，つまりグループのリソースを無駄にしかねないということが問題です。
一度 l.d.o. から .po ファイルをダウンロードし，それを何らかのシステム（おそらくはウェブ・アプリ）にインポートした後は，そのシステム上で翻訳を進められる，というソリューションがシンプルで問題が起きにくいと思います。ただ，この場合，l.d.o. や l10n client モジュールのインターフェースを使って翻訳したいメンバーによる翻訳データとどう統合するかが問題になります。さらなる調査・検討が必要だと感じます。
スプリント終了後，dokumori さんから，Sun Microsystems で Open Solaris や Open Office の翻訳プロジェクトに積極的に関わっていらっしゃる斉藤さんという方のブログを紹介されました。そのブログの中で，Pootle というオープンソースでウェブアプリとして作動する翻訳ソフトウェアが紹介されていました。もしかしたら，これを私たち l.d.o./ja でインストールするといいかもしれません。
また，彼女のブログから日本語スタイルガイド，同クイックリファレンスというドキュメントを発見しました。すでに翻訳活動で実績のある方々のノウハウが詰まっているようなので，l.d.o./ja にとっても大変有益ではないかと思います。
注
今回のブレインストーミングは，あくまで「こういう作業環境およびワークフローを使うと，さらに効率よく翻訳が進められる」という提案をすることを目的としています。特定の作業環境およびワークフローを l.d.o./ja としてメンバーに強要する意図はありません。
.POファイルからのプロジェクトマネジメント
上記の分析でGTTはいいなと思いました。
一つ言おうかなと思ってたのは、道具のtranslationMemoryは便利そうだけど、それ以外に.POファイルから直接プロジェクトを管理するという作業法です。
例えば、翻訳をその日手伝いたいというメンバーがいたら、それをアドミンに伝え、その日とメンバーに合わせてアドミンが.POファイル自体(や.POファイルのどこそこ宜しくみたいな)をそのメンバーに送信して宜しくというような方法です。翻訳完了後.POファイルをl.d.oにアップロードして、アドミンに報告。
この方法だと翻訳数に（多いという事に関して）真っ向から目をそらさず状況や質を感じて、状況に応じて必要なところから的確に活動ができる利点があると思います。直接、アドミンやプロジェクト管理者が翻訳活動が集中するべく箇所を正確に分析しており.POファイルをassignする事により導く事ができる、それこそ管理してると言えるのではないでしょうか。まあ提案としてやり方はどうあれ.POファイル管理先行型の活動方法はどうかなと思いました。（.POファイルの表などでも..）
@fuji， コメントどうも。 "上記の分析でGTTはいい
@fuji，
コメントどうも。
分析といえるほど詳細なものではないですが，そうですか？ 僕は GTT は不向きだと思ったんですが。僕の最大の不満は，一つ一つの原文ストリングを独立したものとして扱ってくれないことです。.po ファイルを読み込ませる事はできます（.po ファイルは単なるテキストファイルなので，コピー＆ペーストすればいい）が，そのやり方だと，一つの .po ファイルに含まれるすべての原文と翻訳文のペアが一緒くたに「翻訳対象」と見なされます。そして t() 関数による原文の区切りが失われます。たぶん。
でも，別の人が見たら，僕には分からなかった GTT の使い方が見えてくるかもしれないので，時間があればぜひ GTT を使ったワークフローについて検討してみてください。（fuji に限らず，他の人もよろしくお願いします）
.po ファイルを使ったワークフローは，アドミンがわざわざ介入しなくても，エクスポート＆インポートにより fuji が言っていることは実現可能だと思います。
ただ，翻訳箇所をアドミンが指定することについては，そういう厳格な管理スタイルがオープンソースプロジェクトに適しているかどうか，僕には判断しかねます。それよりも，「こういう箇所に労力を注がなきゃいけないと思う。誰かやりたい人いない？」と自主性に任せる方がオープンソース的だというのが，ここしばらくのいろんな人とのやり取りの中から感じた結論です。
Sun の斉藤さんとのミーティング
先のコメントでご紹介した，Sun で日本語翻訳リードを務めていらっしゃる斉藤さんが，2/26（金）に開催される Open Source Conference Tokyo に参加されます。その会場内で，斉藤さんにお時間を割いていただいてグループ翻訳のノウハウや注意点について話していただけるようになりました。
私は業務およびプライベートの都合から OSC には行かないつもりでしたが，もし l.d.o./ja メンバーの１〜３人と一緒に斉藤さんのお話を伺えるようだったら，行けるようなんとか都合をつけます。どなたか斉藤さんとのミーティングに興味のある方はいらっしゃいますか？
なお，もし斉藤さんとミーティングを持つのなら，l.d.o./ja が抱えている問題・課題・疑問（どういうワークフローが適しているのか，長音符の取り扱い，etc）をきちんと整理する必要がありますね。
参考
Open Source Conference 2010 Tokyo Spring
OSCに参加するつもりでブースやプレゼンを集中すると思うが
OSCに参加するつもりでブースやプレゼンを集中すると思うがちょっとでも時間できればミーティングに参加してみます。
g.d.oのスレッドをご参考まで：
http://groups.drupal.org/node/50178
時間が無いので簡単に。 @aiwata55 イベントのオー
時間が無いので簡単に。
@aiwata55
イベントのオーガナイズとレポートおつかれさまです。翌日さすがに眠かったけど、楽しくて収穫の多いセッションでした。またやりましょう :)
日曜にOmegaTのテストをしていたのだけど、文字化けで全然使えずyohgaki（大垣さん）に問い合わせたところ、すぐに返答をくださいました（ありがとうございました）。この問題と解決法に関しては後日またポストします。OmegaTのFuzzy matches（翻訳対象の文字列を含む、以前の翻訳の一覧を表示してくれる機能）を見て、OmegaTは強力なツールだと実感しました。これをうまくワークフローに組み込めたら良いと思います。
@fuji
ワークフローに関しては、確かに担当を決めるのは良いアプローチだけど、管理という形ではなくaiwata55が言うような、各メンバーが自らコーディネートする方式が良いと思います。
中央で管理するという方式の欠点は、中央の人が多忙／休暇等で不在になった際に全体が停滞するということ。また、オープンソースのコミュニティでは各自が好き又は得意なこと／各自にとって必要なことをするので、命令系統を持とうとすると上手く行かないということ。
翻訳というトピックではないけれど、以下のDriesのブログポストは、セキュリティチームが抱える膨大な作業を、contributorsと協力してどのように分散するか、という内容で、チームによる翻訳の際にも参考になるところが多いと思います：
http://buytaert.net/drupal-security-team-past-current-and-future
(1) no one is going to step up and spend a few days each week coordinating the security team, and (2) no volunteer contributor likes to be coordinated to begin with. It is key that we accept that.
「(1)誰も毎週数日をコーディネーションに費やせない、(2)ボランティアのコントリビューターはそもそもコーディネートされることを好まない。これらを受け入れることは重要」
まずはこの二つを前提として：
Our primary goal should be to establish a team that is designed to scale: a team that can handle more work in a healthy, fun and timely fashion. Addressing vulnerabilities should become our secondary goal.
「主要なゴールは、チームをスケーラブルにすることで、チームがより多くの仕事を健全に、楽しく、タイムリーにこなせるようになること。脆弱性解決の取り組みは二次的なゴール」という、大胆な提案をしています。
翻訳でも同様に、多数のメンバーが効率よく共同作業を行えるツールの提供、またワークフローのデザインが重要だと思うので、そういう意味でaiwata55が進めている一連の作業は利にかなっていると思います。
長くなったし時間切れなので、具体的な提案はまた後日にします。