翻訳作業の管理プロセスとPootle

OLPC EToys

OLPCが翻訳作業のための共用インフラとして Pootleを立ち上げたのですが、それにEToysが乗っかるかどうかについての分析です。なおこの記事は、開発をお手伝いしている一ボランティアから見た私見です。
id:propella さんどうでしょう？

OLPC以前のEToysの翻訳の開発プロセス

従来のSqueakは翻訳辞書をイメージ内のデータとして持っていたので、翻訳の追加や修正は Chunk形式などで出力した差分をコアの開発者さんに送り、 Changesetとしてアップデートストリームに流してもらえばよかったです。
（たぶん他のオープンソースのプロジェクトもそうなのかもしれませんが）教科書的な開発管理プロセスというのはなく、アップデートストリームに流す権限のある人に認めてもらえればストリームに流してもらえるという感じです。これはコードの修正でも翻訳の場合でもあまり差はないと思います。

OLPC EToysの現状

OLPC EToysでは翻訳の仕組みが変更され、gettextのエミュレーションを行うようになりました。翻訳データもgettextのMOファイルをイメージの外部のファイルシステム上に置いて実行時にアクセスしています。
これに伴い翻訳データはMO/POファイルをSVNリポジトリに入れてバージョン管理するようになり、アップデートストリームに流したchangesetでは更新できなくなりました。SVNはコア開発者さんだけが更新権限を持っています。
SVNとは別にhttps://translations.launchpad.net/etoys/にPOファイルが登録されていて、一般のボランティアさんが翻訳作業に参加できるようにしてあります。ただしSqueak本体でのコード修正で msgid（翻訳の原文）も変化している箇所があるのですが、それをLaunchPad側にタイムリーに同期することはできていません。

PootleソフトウェアとOLPC Pootleの現状

Pootleは、Web上で翻訳作業を管理・実行できるシンプルな機能のソフト（GPL）です。
バージョン管理システムと統合する機能も持っています。これにより、翻訳作業者にPOを渡した後、コード変更でmsgidが変わったことなどもタイムリーに翻訳側に伝えられるように意図しているようです。
OLPCでは、OLPCで標準的に使われているバージョン管理システムの git リポジトリと統合して運用しようとしています。「Pootle側で翻訳を修正した場合、直接gitのPOを修正することがあるよ、そのための書き込み権下を持ったgitユーザが増える」というアナウンスが先日ありました。
OLPC Pootleでは一応全ての言語はwelcomeだけど、プロジェクトの対象国を優先するようです。

EToysの翻訳をPootleに移す場合の課題

  • EToysのほとんどはOLPC用（OLPC EToys）と一般用（OLPC Squeakland）を区別せずに開発されており、現状OLPCの対象国でない日本向け翻訳データもあります。これを本当にOLPC Pootleで管理できるかは大変重要です。現在日本語のプロジェクト自体がOLPC Pootle上に1つもありませんし、ツールがちゃんと動くかどうかもテストしないといけません。Spikyさんが日本語の翻訳者に立候補されてますが、OLPC側の反応はML上ではまだありません。
  • LaunchPadの場合、逐語的にオンラインで翻訳する以外に、POをアップロードすることもできます。しかしPootleにはこのような機能はないようです。
  • LaunchPadはサイト上で翻訳を編集した後、管理者がサイト上でレビュー・承認したものしか出力に出てきません。しかしPootleのソフトウェアには翻訳の編集をワークフローで管理する機能はないようです。（つけられたサジェスチョンを承認する機能はあります
  • EToysはgitには「EToys Activity」のグルーコードしか入れていません。その他はVM、コンテンツの２つのRPMとして別のところでバージョン管理しています。翻訳データについては、ビルド処理の中で、SVNからPOを取り出してコンテンツのRPMにパッケージしているようです。ですから、Pootleのgit統合は使えません。一応SVNなどとも技術的には統合できるようですが、テストはされていないようです。
  • Pootleから直接リポジトリ上のPOを更新するというのはかなり危険な気がします。実際、現状ではEToysのSVNを更新できる権限は限られた人しか持っていませんし、そこにいきなり翻訳プロジェクト側が自由にコミット権限を持つのは危険だと思います。PootleとEToysのビルドで使うリポジトリ（またはブランチ）を分けて、ベースラインへの反映はEToys側で管理することが必要な気がします。