でも例えば、英語の得意な両親とか友人がいて、
ちょっと協力して欲しいって声かけるくらいの
参加意識が芽生える事だってあると思うんですよ。
多くないことかも知れないけど。

大体、英語に堪能な人ならKDEが英語版だろうが
関係ないとか、更にUNIXに詳しい人間はKDEなんか
使わないよとかで、出来るけど興味無いとか、
目にする機会がなかったから参加しなかった。
とかなりがちだと思うわけで。

申し込みが殺到するから、既に求人広告で足切り
というgoogleみたいなやり方が必要な時ではなく、
求人広告の存在自体を知らせる段階だというのが、
60%という数字の示すものではないでしょうか。

私も多分、そうなんだろうなと思うんです。
しかし、中には質より量が必要な時期もあるのではないかな、と。
とりあえず日本語に直せればだいぶ違うと思います。
その後、日本語自体の推敲をしてもいいと思うんですよ。

それに、英語が堪能な人を連れてきたって、日本語がちぐはぐする事だってあるわけで、そういう部分の「日本語→日本語」翻訳だって期待できるかもしれないわけで

いきなり完璧な翻訳を目指そうとしてるのかな。
なんか、それってオープンソースというか、バザール方式らしくないのかな、という印象を受けます。
(日本人の英語に対する姿勢でよく言われていることと被る気もします)

それするなら、wikiには編集するファイル名を書いて、
編集後はwikiにあるメールアドレス宛てに添付ファイルで送ればいいんですか。

原文の更新時、更新マージツールによって、自動的に、原文が変更されていないならそのまま訳文がコピーされ、少し変更されている場合もfuzzyマークを付けて訳文がコピーされます。

これはKDEでもかなり前から実現されていますよ。SVNのログ [kde.org]を見てもらえればわかりますが、po自動更新スクリプトがscripty(Script Kiddy)というアカウントで定期的に更新しています。

詳しくはここ [kde.org]を参照してください。

「カタログ群をアプリ本体と分離（して配布）」というのはKDE固有というよりも巨大なアプリ(=全言語をパッケージングすると肥大化しすぎる)では一般的か思います。具体的にはmozilla,openoffice,eclipse等が思い当たります。
特殊なのはリリーススケジュールで、他のプロジェクトが通常カタログ群（あるいはカタログ群とバイナリをパッケージングしたローカライズ版）を若干遅れてリリースするのに対し、全世界（版）同時公開！ついてこれないのはステ！なところが無茶というかたいへんだろうなというか。他のプロジェクト同様カタログ群だけ遅れてリリースしても、それほど間が開くことなければ（ディストリビューションが採用するころまでにそろってれば）ユーザーはあまり困らないかと。まあこれは本家の方針と思われるので口出してもしょうがないですが。

なお重箱つつきになりますがQt/KDEではGNU gettextとフォーマット互換（なのでgettext用のツールが使える）ではありますがgettextとは違うAPIの独自実装を使ってたはずです。
gnu gettext自体、元はsunの国際化API互換（その後デファクトスタンダードになったか公式スタンダードになったかは詳しく知りませんが）だったかと思いますが、こちら（GNU gettextとsun）はAPI互換ではありますがフォーマット互換ではなかったかと。

ここで愚痴ったところで意味ないですよ。

変な訳を見つけたらクリック一発で報告フォームを開くような仕組みにはできないものでしょうか？