gettext の採用可否について、皆さんのご意見を聞かせていただきたく、投稿します。

プログラムから出力されるエラーメッセージ等の文言が、現在はそれぞれのコードに直接記述されている状態ですが、これは保守性の面でかなりよろしくない状態だと思います。

そのため、現在のハードコーディングされている文言をそれぞれエイリアスに置き換え、そのエイリアスを実際に表示する文言へ変換する方式に変えてコミットしようかと思っています。

その場合、PHPの拡張モジュール gettext を利用して mo ファイルや po ファイルから文言を抽出する方法が一般的なようです。

ただ、gettext モジュールが有効になっている環境が一般的とはいえ、有効でない環境がある可能性も考えると、gettext を採用するのはどうなのかな、と考えてしまいます。

みなさんはどう思われますか？

----------------
EC-CUBEのプラグインを公開しています！
いつも reCAPTCHA

個人的には gettext 周りでハマった過去もあり若干の拒絶反応もありますが(笑)、他(多?)言語対応の方向にも繋げていけそうな、興味深い提案ですね。

この辺り(動作環境要件)は、ホスティングパートナーとの調整もあるっぽいので、最終的には株式会社ロックオン社の判断も必要そうですね。

「他のメジャーなアプリで、こんなものでも必須となっています」という話があると、説得しやすいようにも思います。(たしか、何かの CMS のインストールで導入した記憶が。)

あとは、どのタイミングで投入するのかというのもありますよね。2.12 はβまで進んでいるからなぁ・・・

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

個人的には賛成です.

ただ, ハードコーディングされている画像の文言まで対応しないといけませんよね...
最終判断は, 株式会社ロックオンさんに委ねます.

私も、メッセージを変更したい場合に、あちこちに散らばっていて不便な思いをしばしばしています。
そのあたりのメッセージが1ファイルに集約できるという部分で是非前向きに採用して欲しいですね。

動作環境要件的には、多くの場合gettextエクステンションは有効になっているんじゃないかなぁと思うんですが、やはり株式会社ロックオン社のディシジョンが必要でしょうね。

WordPressなんかは、自前でライブラリを持っていて、gettextエクステンションが有効でない場合にも対応しているっぽいです。
こういった手法だと環境面ではクリアできそうですが、実装工数が上がりそうですね。

投入時期に関しては、2.12のロードマップには、
ソース凍結予定日：2012/05/16
となっているので、それまでに盛り込めなければ、次期バージョン以降になりそうですね。

----------------

リゾート会員権(エクシブ等)の売買・仲介

調べてみたところ、WordPress・Drupal・Zend Framework・CakePHP・Code Igniter のいずれも、拡張モジュールに依存しないように、独自のライブラリーで実装しているみたいですね。

うーん、やっぱり gettext を使わない形で実装したほうが良いのかもしれません。
かなり工数が上がっちゃいますけど

----------------
EC-CUBEのプラグインを公開しています！
いつも reCAPTCHA

引用：

独自ライブラリーを一から作成するとなると大変そうですね。

以前のWordPressは、下記のライブラリーを使用していたっぽいですね。

php-gettext
https://launchpad.net/php-gettext/

既存のライブラリーを利用可能なら、少しは工数も抑えられるように思いますので、参考にして頂けたら幸いです。

あと、さらに工数掛かかる話で心苦しいですが、
管理画面からメッセージの変更ができるようになると大変便利になると思います。
こちらの機能も検討頂ければ、ものすごく嬉しいです。

----------------

リゾート会員権(エクシブ等)の売買・仲介

concrete5は前はgettext必須でしたが、今はZendのライブラリ使ってgettext無くても動く様になってます。
実装もそこまでゴリゴリ書いて無かったと思いますよ。

----------------
EC-CUBEカスタマイズ相談してください。
緊急のEC-CUBEの障害対応
EC-CUBEカスタマイズブログ

独自ライブラリーをイチから作ると大変なので、既存のライブラリーを利用して省力化しつつ、拡張モジュールには依存しない形で実装しようと思います。

既存のライブラリーだと shutta さんが挙げてくださっている php-gettext が良さそうですね。
Zend Framework のものは高機能で作りもしっかりしていると思うのですが、なにぶん PHP 5.2.4 以降からのサポートなので、また別の問題が生じてきます。

あと、毎度ファイルを読み込むと負荷が高くなりそうなので、PEAR の Cache_Lite を使ってキャッシュを実装しようかとも計画しています。

----------------
EC-CUBEのプラグインを公開しています！
いつも reCAPTCHA

あのぉ...メッセージだけを多言語化しても、データ側が単一言語だけではダメだと思います。

商品情報なども多言語で登録する必要があり、DB構造自体を多言語化する必要があると思います。すなわち、dtb_lang_keyテーブルを新規に作成し言語キーを登録し、必要なものはdtb_xxxに言語キーフィールドをもち、言語キー別にデータを登録できるように大改造する必要があると思います。管理画面もこれに対応して修正しなければなりません。

また、shop側では、ユーザのブラウザlocaleからその言語で初期表示し、ユーザが任意に言語を切り替えることができるようにすることも必要です。

いずれにしても、gettextだけの問題ではなく、大改造が必要になる思います。

複数の言語で同時に運用する場合はそうですよね。

ただ、まずはコード中のメッセージを集約して、
メンテナンスや変更をしやすくすることが目標です。
なので単一の言語で運用することを考えています。

もし翻訳ファイルの提供があれば、中国語版EC-CUBEや
英語版EC-CUBEが実現できる、といった程度です。

ゆくゆくは複数言語での運用もできればとは思いますが、
yosakoさんが書かれているとおり、道のりは遠いです

----------------
EC-CUBEのプラグインを公開しています！
いつも reCAPTCHA