当然の結果です.まぁPHPスクリプトでのメッセージカタログも配列より「$message = "メッセージ";」の方がさらに早いだろうけどそんな形式メンテナンス性悪すぎるのでステでそ.define()も等価.
理由は使用している全メッセージの取得が著しく行いづらい.

とりあえず第10回PHP勉強会でもでてきたのですが,
下記は「私がなぜgettextにこだわるか」ってところです.

gettextってそんなにいいのか?

ぶっちゃけgettextが完璧だ!!というわけではないです.現時点消去法で一番マシなのです.
理由は下記のとおり.

・英語メッセージカタログ(以後カタログ)の更新がほとんど確実に追跡できる
・カタログテンプレートの作成は当然更新と最新カタログと既存の翻訳カタログのマージが簡単.
・各種ユーティリティが豊富にそろっている

gettextでなければカタログの追跡は難しいのか?

答えは「yes」です.とりあずありがちなPHPスクリプトでカタログを扱う例を出してみます.
とりあえず英語のカタログは便宜上「en.php」というファイル名ということにしましょう.

簡単な英語ですね.ごめんなさいボキャブラリ少なくて(痛
では翻訳しましょう.

馬鹿みたいに簡単です.同様に便宜上「ja.php」というファイル名にします.
ここでen.phpで「?」を付け忘れていることに気づきました.
ってことで,変更します.

さてja.phpのメンテナンスをしている人はどうやればこれに気づくことができるでしょうか?
基本的に「変更したよ!!」って明言されないと気づきません.あるいはカンで気づいて見るかもしれません.
でも1000とかメッセージあるとわかりませんよね.
この原因は翻訳元と翻訳先のメッセージに関連付けがまったくないことから起こります.
PHPスクリプト的には

なりすることで「カタログ変数の各言語共通化」できますが,「翻訳される実際のメッセージ」はすべての言語で関連性がないのです.

余談になりますが,私はCVSやsvnが使用できる環境の場合,翻訳作業で下記のように擬似タグを挿入します.
<en-revision>はen.phpのリビジョン番号を入れます.
そうすれば下記のようにすることで最新と最終翻訳の差分を取得することができます.

後はこれをリダイレクトしたりしてちまちまと作業をします.
しかし正直diff読みながら作業は面倒です.
こういう仕組みが作れないときは,旧バージョンのアーカイブと新バージョンのアーカイブの比較になります.
まぁ結局やることは似たようなもんですね.リポジトリが公開されてアクセスできると一度に一気に作業しなくていいので負担が少ないってのはメリットですが.

じゃー単なる変数じゃなく配列にすればいいじゃん!!
えらい!!よく気づきました.

とかやっておいて使用するときは

などとする.関数化してもいいですね.

これならハテナを付けたくなれば

とすればいいですね.
これでカタログキーが変わるので,何らかのユーティリティを自作できそうです.
en.phpの連想キーとja.phpの連想キーの差分を取るとか.
でもこのen.phpの変更をja.phpに反映させ,「英文があれば未翻訳だよー」とか「連想キーと値が同じなら未翻訳ですよー」位したくないですか?
しかしそこまでツール作るとなるとちょっと面倒ですよね.
大体「英文のまま」イコール「未翻訳」ではないですし.「連想キーと値が同じなら未翻訳」ではありません.

とか.こういうのをしようとするとメッセージ毎に「翻訳済」「未翻訳」などをマーキングできなければなりません.
そんなことを配列でやってるとそもそもメッセージ自体の可読性が落ち,翻訳どころではありません.
ついでに忘れてませんか? プログラミングをしているときにわざわざ手動でカタログを作り直すんですか?
メッセージ摘出ツールが欲しいですよね.自作するんですか?
厳密にはgettextの摘出ツール(xgettext)を利用したり,「摘出するだけ」なら何らかの手段はあると思います.

結論

この辺で大体まとめてみます.

・ただのPHP変数で定義する「$message = "message";」という形式はメッセージ文(ここでは「message」)が変化しても追跡することが難しい
・配列にすると追跡できるが,翻訳の更新をすることが難しい
・どのみち未翻訳管理などができない
・カタログ作成ツールがない
・カタログを実際の各言語のカタログへの反映ツールがない

ということになります.
さて長くなったので一旦終わり.
次にgettextならどうなるのか辺りを.