どうか教えて下さい！
| 機能要望 > その他 > gettext の採用可否について |
その他
 |
| スレッド表示 | 古いものから | 前のトピック | 次のトピック | 下へ |
| 投稿者 | スレッド |
|---|---|
| pineray |
投稿日時: 2012/5/8 20:31
対応状況: −−−
|
長老   登録日: 2006/9/9 居住地: 伊賀 投稿: 292 |
Re: gettext の採用可否について ＞AMUAMUさん
コメントありがとうございます  ひとまず「クラス名＋関数名」までを基本として、同じ関数内に複数の文言がある場合は適宜名付けることにしました。 ただ、ページのタイトルやフォームパラメーターなんかは、上記のルールに当てはめず、「PAGE_TITLE_...」「FORM_PARAM_...」といった名付けにしたほうが使い勝手が良いのかな、とも思っています。
|
| AMUAMU |
投稿日時: 2012/5/8 14:19
対応状況: −−−
|
神   登録日: 2009/5/2 居住地: 東京都 投稿: 2712 |
Re: gettext の採用可否について 個別に考えるのは大変だと思いますので
>コード中の文言をエイリアスに差し替えるにあたって、各エイリアスをどのように定義するか悩みどころです。 >逐一考えるのが面倒なので、「クラス名＋関数名＋通番」にしようかと思うのですが、いかがでしょうか。 で今は十分だと思います。 将来的にはコーディング規約などで命名規則を決め、徐々に置き換える形で良いとは思います。 P.S. 着手素晴らしいです・・・
|
| pineray |
投稿日時: 2012/5/7 20:06
対応状況: −−−
|
長老 登録日: 2006/9/9 居住地: 伊賀 投稿: 292 |
Re: gettext の採用可否について php_gettext を利用しての開発に着手しました。
ひとまず、エイリアスの文字列を置換するための関数群は作成してコミットしました。 あとは、コードに散らばっている文言をエイリアスに差し替えてmoファイルに集約するのと、Smarty拡張を用意する作業が残っています。 コード中の文言をエイリアスに差し替えるにあたって、各エイリアスをどのように定義するか悩みどころです。 逐一考えるのが面倒なので、「クラス名＋関数名＋通番」にしようかと思うのですが、いかがでしょうか。 例えば、SC_CheckError クラスの EXIST_CHECK 関数にある文字列であれば SC_CHECKERROR_EXIST_CHECK_1 => '※ :fieldが入力されていません。<br />' SC_CHECKERROR_EXIST_CHECK_2 => '※ :fieldが選択されていません。<br />' といった感じです（「:field」は置換用のトークン）。 ご意見いただけたら幸いです。
|
| shutta |
投稿日時: 2012/4/25 10:17
対応状況: −−−
|
仙人   登録日: 2010/2/4 居住地: 関西 投稿: 835 |
Re: gettext の採用可否について 引用：
多言語化や複数言語での同時運用等をするなら、上記の対応まで考慮した大改造が必要になってくるでしょうね。 ただ、そこまでを一気にやるのは大変でしょうから、システムメッセージをgettext化で一元管理できるようになるだけでも、個人的には有用に思います。 日本語で運用する際も、メッセージを変更しようと思ってもあちこちに分散しているので、少々面倒ですし、漏れも出やすいので、そこが改善されるだけでも非常に嬉しいです。 ですので、まずはその部分の整備というか機能化から実装して頂ければと、個人的には思います。 その後に、多言語化対応の議論・実装へシフト・ステップアップして行くやり方でも良いんじゃないでしょうか。
|
| pineray |
投稿日時: 2012/4/25 10:15
対応状況: −−−
|
長老 登録日: 2006/9/9 居住地: 伊賀 投稿: 292 |
Re: gettext の採用可否について 複数の言語で同時に運用する場合はそうですよね。
ただ、まずはコード中のメッセージを集約して、 メンテナンスや変更をしやすくすることが目標です。 なので単一の言語で運用することを考えています。 もし翻訳ファイルの提供があれば、中国語版EC-CUBEや 英語版EC-CUBEが実現できる、といった程度です。 ゆくゆくは複数言語での運用もできればとは思いますが、 yosakoさんが書かれているとおり、道のりは遠いです 
|
| yosako |
投稿日時: 2012/4/25 9:14
対応状況: −−−
|
一人前   登録日: 2011/12/3 居住地: 投稿: 101 |
Re: gettext の採用可否について あのぉ...メッセージだけを多言語化しても、データ側が単一言語だけではダメだと思います。
商品情報なども多言語で登録する必要があり、DB構造自体を多言語化する必要があると思います。すなわち、dtb_lang_keyテーブルを新規に作成し言語キーを登録し、必要なものはdtb_xxxに言語キーフィールドをもち、言語キー別にデータを登録できるように大改造する必要があると思います。管理画面もこれに対応して修正しなければなりません。 また、shop側では、ユーザのブラウザlocaleからその言語で初期表示し、ユーザが任意に言語を切り替えることができるようにすることも必要です。 いずれにしても、gettextだけの問題ではなく、大改造が必要になる思います。 |
| pineray |
投稿日時: 2012/4/23 13:49
対応状況: −−−
|
長老 登録日: 2006/9/9 居住地: 伊賀 投稿: 292 |
Re: gettext の採用可否について 独自ライブラリーをイチから作ると大変なので、既存のライブラリーを利用して省力化しつつ、拡張モジュールには依存しない形で実装しようと思います。
既存のライブラリーだと shutta さんが挙げてくださっている php-gettext が良さそうですね。 Zend Framework のものは高機能で作りもしっかりしていると思うのですが、なにぶん PHP 5.2.4 以降からのサポートなので、また別の問題が生じてきます。 あと、毎度ファイルを読み込むと負荷が高くなりそうなので、PEAR の Cache_Lite を使ってキャッシュを実装しようかとも計画しています。
|
| tao_s |
投稿日時: 2012/4/20 22:05
対応状況: −−−
|
仙人  登録日: 2008/8/20 居住地: 東京 投稿: 799 |
Re: gettext の採用可否について concrete5は前はgettext必須でしたが、今はZendのライブラリ使ってgettext無くても動く様になってます。
実装もそこまでゴリゴリ書いて無かったと思いますよ。
|
| shutta |
投稿日時: 2012/4/19 19:34
対応状況: −−−
|
仙人 登録日: 2010/2/4 居住地: 関西 投稿: 835 |
Re: gettext の採用可否について 引用：
独自ライブラリーを一から作成するとなると大変そうですね。 以前のWordPressは、下記のライブラリーを使用していたっぽいですね。 php-gettext https://launchpad.net/php-gettext/ 既存のライブラリーを利用可能なら、少しは工数も抑えられるように思いますので、参考にして頂けたら幸いです。 あと、さらに工数掛かかる話で心苦しいですが、 管理画面からメッセージの変更ができるようになると大変便利になると思います。 こちらの機能も検討頂ければ、ものすごく嬉しいです。
|
| pineray |
投稿日時: 2012/4/19 19:04
対応状況: −−−
|
長老 登録日: 2006/9/9 居住地: 伊賀 投稿: 292 |
Re: gettext の採用可否について 調べてみたところ、WordPress・Drupal・Zend Framework・CakePHP・Code Igniter のいずれも、拡張モジュールに依存しないように、独自のライブラリーで実装しているみたいですね。
うーん、やっぱり gettext を使わない形で実装したほうが良いのかもしれません。 かなり工数が上がっちゃいますけど
|
| (1) 2 » | |
| スレッド表示 | 古いものから | 前のトピック | 次のトピック | トップ |
