Weblate というオンライン翻訳支援ツールがあることを知りました。
via 世界を目指す人に：ブラウザ上で翻訳ファイルを作れる「Weblate」:phpspot開発日誌
昨年（2012 年）開発されたばかりの、新興 Web アプリケーションです。
上記の記事を読んで、そもそもこの Weblate が他の類似サービスとどう違うのか、なんでいまさら新しいオンライン翻訳支援ツールを（しかも Pootle とモロカブりする Python ベースで）立ち上げたのか、ちょっと不思議に思いました。
調べてみたところ、開発者の Michal Čihař さんのブログにその辺りの事情を説明したエントリがありました。CC BY-SA 3.0 ライセンスにしたがって、拾い訳してみます。
以下、引用訳の原文著作者は Michal Čihař さんです。一応、ご本人から日本語訳の許可を直接いただいています。
"Looking for Pootle alternative" によると、もともと phpMyAdmin のローカライゼーションに Pootle を使っていて、不満が出てきたのが切っかけのようです。さまざまな代替サービス（Transifex、Translatewiki、Crowdin など）を試したけれど、マッチするものが見つからず、これなら自分で作った方が早いということで Weblate 誕生に至ります。
そのとき、作者さんがいったい何を求めていて、何を目指していたのかについては、下記エントリにまとめられていました。
Weblate を始めたワケ
いまだに、なんで既存のソリューションに留まらず Weblate を書いたのかって、よくきかれる。理由の大半は、以前のエントリ（"Looking for Pootle alternative" や "Announcing Weblate"）に書いた。でも、ここでもう一度おさらいしてみようと思う。
Git 統合
Git と統合できるツールが無かった。翻訳システムをリモートブランチに設定できれば、翻訳作業結果を反映させるのは Git マージ一発で済むじゃないか。
翻訳者のクレジット
翻訳者が自分のコントリビュートに対して、適切なクレジットを得られる。Git でコミットしたら、翻訳者の名前がそのままコミッタの名前に載る。誰が翻訳したか探すための別のツールなんて、要らない。
ブランチ管理
phpMyAdmin では、リリース後のメンテナンスにブランチを多用している。だから、翻訳者に二度手間をかけさせることなく、安定版と開発版の両方に翻訳をプッシュしたかった。Weblate は、すべてのブランチに変更を自動でプッシュする。ブランチに限らず、サブプロジェクトでも同じだし、たとえば Gammu と Wammu のような関連プロジェクトでも同じ。
コンテキストの表示
ほとんどのツールは、関連するソースコードをうまく参照できない。Gettext プログラムで出力した po ファイルには、ちゃんと参照情報が付いてるっていうのに。Weblate では、ビューアの URL を設定するだけでいいんだ。Github みたいな既存のサービスと連携するのには、最適だよ。
アップロードした翻訳の適切なマージ機能
Pootle では、翻訳途中の po ファイルをアップロードすると、ファイルごと置き換わる。これは極めて危険だよ。だって、すでにあるていど翻訳済みのものがリリースされていて、しかも作業者は自分がアップロードしようとしているファイルが翻訳途中の状態であることに気づいていないかもしれないわけだろう？ Weblate はアップロードされた翻訳を、分節単位でマージする。もちろん、遅いよ。でも差分を最小限にとどめてくれるし、複数ブランチにまたがって機能する。
整合性チェック
書式指定子の混じった文字列などは、翻訳中に簡単にミスる。だから翻訳ツールには、できるだけ早い段階でそれを検出してほしい。Weblate の半強制チェックは、検証にパスしないと、正しかったはずの以前の翻訳にリダイレクトされる（またはチェックを無視もできる）。今のところ、このチェック機能はぼくが望んでいるレベルに達してはいないけれど、完全にモジュール化されているので、簡単に拡張して、改善できる。
おまけ
Weblate を開発しているあいだに、いくつかの機能は、当初思い描いていたものよりもずっと良い形に仕上がった。たとえば、Github の Web フック。これでリポジトリの更新通知を受け取ることができるんだけれど、おかげで作業中の翻訳プロセスを邪魔することなく、リポジトリの変更をマージすることができるようになったんだ。Git ではカスタムのマージドライバを登録できるので、これを使うとマージ作業における po ファイルの競合（通常、ヘッダーのタイムスタンプによって引き起こされる）を、より抑えることができる。これは間違いなく、Weblate を使う利点といえるんじゃないかな。
もちろん、他にもたくさんあるよ。詳しくはドキュメントを見てね。
このエントリが書かれたのは 2012/4 で、Weblate 1.0 リリース前でした。
で、Weblate 1.0 リリース後の 2012/5 に、次のエントリが書かれています。
Pootle 対 Weblate
Weblate 1.0 がリリースされたから、そろそろライバルツールとの比較をしてみてもいい頃合じゃないかな。まずは Pootle にお相手願いたい。長い使用経験があるし、それに何といっても Weblate の着想の元になったツールだからね。
まず、Weblate と Pootle はともに、翻訳ファイルを操作するために同じバックエンドを使っている。Translate Toolkit だ。ただファイルの操作に Pootle とは違うやり方を採用したので、Weblate では変更の規模がずっと小さい（Pootle は po ファイル全体を再整形する）。また、Pootle に見られる、ファジーフラグの変更を正しく処理できない問題（phpMyAdmin では、何度もこれに悩まされた）のようないくつかの問題は、Weblate では起きない。
他の共通点といえば、Web フレームワークの Django だろう。ぼくにとっては、アプリを書くなら当然の選択だった。最も大きな違いは、管理画面のインターフェイスかな。Weblate は Django が自動生成する admin インターフェイスをそのまま使っている。Pootle は独自インターフェイスを使っているので、一貫性という点では Pootle が大きく優っているね。そこは Weblate の管理画面の開発を少ないコード量で済ませようとしたツケが回ったところだ（もちろん Django の admin インターフェイスはじゅうぶん強力なんだけど）。あと、同じフレームワークを使っているから、Pootle と Weblate 間でユーザーアカウントを移行するのは、とても簡単だね。
じゃあ機能面の話に移ろうか。ちなみに、あったらいいなと思っていた機能を Weblate に追加しているあいだもずっと、ぼくは Pootle で見たすべての良いところを取り込もうと努めていた。最も大きな違いは、Weblate のプロジェクト/サブプロジェクト分類だろう。これはもともと複数のブランチに対応しようとしたのが始まりだったんだけれど、関連プロジェクトの翻訳でも有用なのが分かった。この機能は、プロジェクトを横断して変更を自動伝搬させる。同じプログラムの違うブランチでも、同じ機能の異なるインターフェイス（たとえば GUI アプリケーションとコマンドラインツールのような）でも、かまわない。とにかく本当に翻訳の助けになるよ。
他の大きな違いとして（そして、これぞ Weblate 最大の売りと言いたいが）、Git 統合を挙げられる。すべての変更は、適切な著作者情報とともに Git にコミットされる。これは po ファイルのマージや、自動的に（たとえば GitHub からの）アップストリームの変更をプルするときの助けになる。それによって（Git ベースの）開発プロセスへの統合が、本当に簡単になるんだ。
整合性チェックや辞書（用語集）のような他の機能については、理由は違うものの、似たような状況にある。Weblate の整合性チェックは Pootle より簡単なものしかないんだけど、その最大の理由はぼくが Pootle の一部のチェック機能をウザいと思ったからなんだよね。Weblate のユーザー辞書には、まだとても基本的な機能しかない。でもこっちは、間違いなく将来のバージョンで改善すべき点だ。
設定面では、Pootle の方がずっと細かい設定が可能になっている。Weblate は設定項目が少ない。理由は簡単で、Pootle のオプション設定の大半を、ぼくがぜんぜん使わなかったからなんだけど。そんなわけで、チェック関連や権限に関するプロジェクト別の設定は、Weblate には無い。同様に、Weblate 上から新しい言語のサポートを追加する方法も、無い。新しい言語をサポートするってことはふつう、単に適切な po ファイルを追加すれば済むってものじゃないんだ。どっちみち、あれやこれやの手作業が必要になる。だから、Weblate ではその辺はユーザーに任せている。一方で、Git リポジトリに新しい言語を追加する作業が行われたら、それはすぐにインターフェイスに反映されるよ。
どちらのプロジェクトも、よく整備されたドキュメントを提供している。Pootle は大抵のことなら wiki でカバーされている。Weblate は、まだ文書が分散しているけれど。もっとも両者ともに、ちょっとした情報の欠落は、間違いなくある。
PS: もっといろいろな比較に興味があるなら、Ohloh を見るといいと思うよ。(^_^)
これらのエントリは 1.0 リリース前後に書かれたものですが、Weblate は精力的に開発が進められているため、現時点（2013/1）ではすでにバージョンが 1.3 になっています。中には最新バージョンに当てはまらない記述があるかもしれませんが、Weblate の方向性は十分に読み取れるのではないかと思います。
少なくとも、Pootle にパッチを当ててどうにかなるというレベルではなく、完全に Git ありきの翻訳プラットフォームを目指していることが、よく分かります。
また、もともと phpMyAdmin のローカライゼーション支援目的で開発されたという出自からすると当然かもしれませんが、OSS の i18n、l10n 用途しか眼中にないといわんばかりの記述（たとえばコントリビューターのクレジットやブランチ連携、ソースコード参照など）も、今となっては微笑ましいものがあります。
二ヵ月後のエントリで、彼は（やや自嘲気味に？）次のように書いています。
Weblate が驚きの使用者に
ぼくが Weblate を書いたときは、自由ソフトウェアのプロジェクトが、公開の翻訳サービスに使ったりするんだろうなと思っていた。少なくとも、ぼくはそのつもりで書いていたんだ。
ところが、ぼくは間違っていたらしい。今のところ、そのように見える。Weblate についてぼくに問い合わせてきた人たちの大半は、非公開の環境にインストールしていて（訳注：たぶん企業ユース）、しかもぼくが知っているいくつかの場所では、Weblate を使い倒していた。残念ながら、彼らのほとんどはそのことを公にしたくないそうなので、ここでその名前を出すことは控えたい。でも本当に実在するんだよ。(^_^;)
とにかくさ、他にも自由ソフトウェアのプロジェクトがどこか Weblate を採用してくれないかなあ。でなきゃ、Weblate を商用ソフトとして書くべきだったのかも？(^_^;)
この後、作者さんの悲痛な叫びに応えるかのように、Debian の i18n プロジェクトが Weblate を採用するというハッピーエンドが待っていました。ただし、今回も作者さんの予想を斜め上に裏切り、Debian はソフトウェアの翻訳ではなく、ドキュメント（The Debian Administrator's Handbook）の翻訳を Weblate で管理しだしたようです。(^_^;)
他にもいろいろ興味深いエントリがあるのですが、ここで全部訳出するわけにもいかないので、関心のある方は関連エントリを直接ご覧ください。
Weblate 自体のローカライズも Weblate で行われていますので、ユーザー登録してちょっと翻訳作業してみました。使ってみた感想は、まあ良くも悪くも Pootle 改、という感じでした。文脈参照（ソースコードリンク）や差分ハイライトなど、便利な機能はたしかに増えているのですが、根本的に Web アプリ特有のモッサリ感はいかんともしがたい感じです。コントリビューター側からすると、裏で Git 連携しているかどうかなんて、ぶっちゃけ知ったこっちゃない話なので、どうしてもフロントエンドの操作感が評価基準になってしまいます。ただ逆に言うと、Web アプリ縛りの前提なら、Pootle にしか無い機能を必要とするのでない限り、今から Pootle を選ぶ理由は無いかな、とも感じました。自分は Pootle を使い込んでいるわけではないので、あくまでうわっつらをなでたレベルのユーザーが気づく範囲内での印象ですが、対 Pootle 比で見ると、プラスはあっても、ふつうに使う範囲でマイナス要因はほとんど見当たりません。Weblate が近いうちに Pootle に対抗する存在に成長する可能性は、十分にあるように思います。
若いアプリで勢いはありますが、まだまだ未知数です。でも、そこを生暖かく見守っていくのも、OSS ヲチの楽しさだと思うので、l10n/i18n 関係者の皆様は、ぜひ一度チェックされてはいかがでしょうか。
0 件のコメント:
コメントを投稿