ユーザログイン
タグ
最近のコメント
- ryo@drupal.org
- nicotoyo@drupal.org
- masr1975@drupal.org
- 0829@drupal.org
- kabetani@drupal...
- keizi@drupal.org
- ryo@drupal.org
- ptaro@drupal.org
- gondayu@drupal.org
- zorac@drupal-jb...
更新ドキュメント
- 2010年2月17日 08:53
- 2009年1月22日 11:54
- 2009年1月22日 11:53
- 2008年11月18日 17:55
- 2008年4月24日 17:53
Locale Ex
2007年4月18日(水) 18:32 — zorac@drupal-jb...
Locale Exモジュールは、モジュールのソースファイルから原文を抽出し、DBにインポートされている翻訳データから対応する訳文を引用して翻訳ファイルを作成します。このため、作成された翻訳ファイルを配布される場合は、ライセンスにご注意ください。
大きなファイルが含まれたモジュールの文字列を抽出するには、多くのメモリが必要となります。もし、メモリが足りなかった場合は、翻訳ファイルがダウンロードされず、ブラウザの表示が真っ白になったりします。
また、サーバのエラーログには以下の様なエラーが記録されます。
この項目は書きかけです。
概要
Locale Exモジュールは、Drupalのモジュールから文字列を抽出し、.po形式の翻訳ファイルを作成します。
Locale Exモジュールは、モジュールのソースファイルから原文を抽出し、DBにインポートされている翻訳データから対応する訳文を引用して翻訳ファイルを作成します。このため、作成された翻訳ファイルを配布される場合は、ライセンスにご注意ください。
ここでは原文及び翻訳文字列が著作物に相当するか否かの判断は控えますが、drupal.orgで配布されているモジュールはすべてGNU GPLでライセンスされており、Drupal日本語プロジェクトで配布している翻訳ファイルに関しても同様です。ですので、作成された翻訳ファイルを配布する場合もGNU GPLでライセンスするのが一番安全でしょう。
大きなファイルが含まれたモジュールの文字列を抽出するには、多くのメモリが必要となります。もし、メモリが足りなかった場合は、翻訳ファイルがダウンロードされず、ブラウザの表示が真っ白になったりします。
また、サーバのエラーログには以下の様なエラーが記録されます。
Allowed memory size of 33554432 bytes exhausted (tried to allocate 44 bytes)
このような時は、PHP.INIファイルのmemory_limitの設定値を大きくして使用メモリ量を増やすしかありません。memory_limitの設定変更はサーバ管理上の都合もありますので、無理でしたらそのモジュールの文字列の抽出は別の方法で検討してください。
なお、目安として、Drupalコアの文字列の抽出に約16Mバイト必要です。
大抵のモジュールはこれ以下で動作すると思いますが、なかにはとても大きなファイルを持ったモジュールもあります。
コメント
マルチサイト運用で、微妙な感じでした。
テストサイト用にサブドメイン（testsite.example.com）を作成し、1つのDrupalでマルチサイト運用という形で動作させ（以下のような構成）、テストサイト用のディレクトリ（sites/testsite.example.com/modules）にアップロードしたモジュールの翻訳を抽出した場合、ファイルは作成されるけれど、一部の翻訳がかけていたり、エラーが出たりするようでしたので、念の為ご報告させていただきます。
/sites/all/modules/ 以下に、両方のサイトで使用するモジュールを、
/sites/default/modules/ 以下に、メインサイトのみで使用するモジュールを、
/sites/testsite.example.com/modules/ 以下にテストサイトのみで使用するモジュールを設置。
Locale EX モジュールも /sites/testsite.example.com/modules/locale_ex/ として設置。
テストサイト用のディレクトリに設置しているモジュール（hoge）の翻訳ファイル抽出時のエラー
warning: Error parsing sites/testsite.example.com/modules/hoge/hoge.module on line 2 in /virtual/...../includes/module.inc on line 195.
※翻訳ファイルには .info ファイルの内容のみが抽出され、.module ファイルの内容は抽出できていませんでした。
特に困っているわけでもないですし、Locale EX が原因かどうかもわかりませんが、一応、ご報告ということで…
1点確認させてください。
1つ問題になる点が見つかりました。
もしかして、モジュール内に"hoge.info.inc"の様にファイル名に".info"を含んだファイルがあるでしょうか？
".info"を含んだファイルを.infoファイルとして処理してしまっているので、その場合はご報告頂いた様なエラーになるかと思います。
[追記]
あ、ドメインが.infoで、マルチサイトのディレクトリ名が".info"になるんですね。
おっしゃるとおりです。
あ、ですです。 info ドメインなので、サブドメイン用のディレクトリ名に .info が含まれていました。
それが原因でしたか... 他のドメインでも試してみればよかったですね。
お手数をおかけして申し訳ありませんでした。
了解です。
また修正版をリリースしますね。
ご報告有難う御座います。
あとで調べてみます。
しかし、parsingのエラーとなると、PHPの問題かもしれませんね。
使用メモリ量を削減
何とかならないかなあと眺めてましたが、若干でも減少したのでLocale Exを更新しました。SourceForge.jpでダウンロードできます。
コアの抽出が16M、weatherモジュールが32Mで動作するようになりました。
実行時間にも特に影響はありません。
ありがとうございます。
色々とありがとうございます。
うちの鯖は調べてみたら３２Mだったので、きっと微妙なところでメモリーエラーになっているのだと思います。
weatherモジュールはやっぱり駄目でした(T.T)
家主と相談と言うところですね。
モジュールが多いのかな？
家の殆どモジュールが入ってないサーバでテストしたので、いっぱいモジュールが入っているサーバでは32Mでも無理なのかもしれませんね。
あくまで「目安」ということで、すみません。(^^;;
いえいえ
色々とありがとうございました。
何事にも限界というモノはあります。全てに対応しようとすることは現実的ではありませんのでどこかで妥協する必要はありますからね。
そうですね。少なくはないですね。ま、仕方ないですよ。他の手段が0というわけではないので、何とかなります。
ただ、文字列の重複分が取り出せないのがもったいないのと、上書きしてしまう可能には気をつけないといけなさそうですね。
情報ありがとうございます。
Allowed memory size of 33554432 bytes exhausted (tried to allocate 44 bytes)
メモリ不足ですねぇ。でも、30Mも使うはずはないのですが...。
あと考えられるのは、メモリ破壊ですね。これは、PHP本体かPHPの拡張モジュールが悪さしているのかも。
小さなモジュール(コアのpingあたり)で「文字列の抽出」しても同じエラーが出るようなら、たぶんメモリ破壊だと思います。
しかし、複数のサーバで出るというのも解せませんねぇ。うーん。
私も最近別件でこのエラーを見たのですが、PHP4でiconvかrecodeモジュールを入れた時でした。外すと問題はなくなりました。
メモリ不足でした。
メモリ不足かどうかは家のサーバでも確認できるかと思い、やってみたところメモリ不足でした。(^^;;
私のところでも真っ白になりましたので、amayadoriさんの件も同じですね。
weatherモジュールでは48Mくらい必要なようです。memory_limitを増やすのはシステムの問題ですので、増やすかどうかは管理者の方とご相談ください。
0829さんのご報告では90Mでも駄目ということですが、エラーメッセージでは32Mになっていますので、何か別の制限が入っているのではないでしょうか。セーフモードがらみとか。
あと、なんでweatherモジュールでそんなにメモリを食うのかと見てみましたが、icao_codes.incでとても大きなテーブルを定義していました。(^^;;
ということは、weatherモジュールを使うのもかなりメモリが必要ですね。まあ、48Mよりは小さくて済むとは思いますが。
# しかし、こんな大きなデータは外部ファイルにして欲しいなぁw
やっぱり…
私の確認したメモリの報告はやはり、"一応" そうなっていただけだったようですね。エラーメッセージと phpinfo の内容が一致しないように思えたのでどうかな…と思ったのですが、やっぱりだったようで、お手数をおかけしました。
何が問題なのかを調査するのは大変なので、今後、大きなメモリが必要なモジュールに遭遇したら、他の方法で抽出するという方向で頑張りたいと思います。
大きなテーブル
お忙しいというのに、色々と検証していただきまして、ありがとうございます。
weatherモジュールのような巨大なメモリを要求するモノはまれとしても、今後も他のモジュールで起こりえないことではないのですよね・・・。上手い対策とかがあればいいんですけどね。
ひとまず、教訓として忘れないようにしましょう。
問題のicao_code.incというファイルですが、天気を表示する場所の設定の時に利用するファイルだと思われます。
通常動作の際には常に必要なファイルではないとは思います。なぜ、インクルードしているのですかね？
国を選んで選択できる場所(このモジュールの場合は空港)を絞り込んで選択肢を出しているのですが、どうも、その動作にスクリプトを使っているっぽいので、その関係でインクルードしているんですかね？想像でしかないですけど。
しかし、あんまりメモリを使うとレン鯖のような共有サーバーでは辛いモノがありますね。うーむ。
locale_exの挙動
weatherというモジュールを入れてpoを抽出しようかと思ったのですが、なぜか、ホワイトスクリーンになります。
ログにも特にエラーは吐き出されていないようですし、IEの場合はホストが存在しないとか言うエラーを返してくるので(Firefixの場合はソースすら見れない。セッションタイムアウトっぽい感じ)のでタイムアウトっぽい印象を持っていますが・・・。
試しにswsでローカルにてテストしてみたら抽出できたのでサーバー環境の問題？とか思っていたりしますが・・・よくわからないですね。
他のサーバーとかに入れてみてないので何とも言えないのですが、とりあえず報告＆お知恵を拝借したいというあたりで。
お願いいたします。
うーん。
サーバの情報とか、可能な範囲で上げられますか？
多分、mime_types辺りの設定じゃないかとは思うのですが。
Apacheのerror.logです
先ほど再テストした Apache の error.log です。
試してみました。
XREA の二つのサーバで試してみましたが、両方とも真っ白ではなく、以下のようなエラーが出ましたので、念の為ご報告させていただきます。
Apache 1.3.37 / PHP 5.1.6 / MySQL 5.1.16 のサーバ環境でのエラーメッセージ
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 35 bytes) in *****/modules/locale_ex/extract.inc on line 179
Allowed memory size of 33554432 bytes exhausted (tried to allocate 133 bytes)
Apache 1.3.37 / PHP 4.4.4 / MySQL 4.0.26 のサーバ環境でのエラーメッセージ
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 35 bytes) in *****/modules/locale_ex/extract.inc on line 173
Allowed memory size of 33554432 bytes exhausted (tried to allocate 20 bytes)
memory_limit の値は phpinfo() で確認すると、一応 90M になっています。
ご報告まで
[テスト環境]
Ubuntu 6.10
Server version: Apache/2.0.55
Server version: 5.0.24a-Debian_9ubuntu2-log
PHP Version: 5.1.6
php.ini の設定など環境設定の変更は何時でもできますので言って頂ければ設定を変更してテストします。
Firefox 2.0.0.3 では 真っ白け で、PHP の error_reporting を変更しても エラー表示はされませんでした。
Ubuntu 6.1 Opera バージョン 9.20 ではブラウザのエラーメッセージが表示されました。以下にエラー表示を全文掲載しておきます。
情報のありか
情報はどんな手段で入手したものが良いでしょう？
サーバーはまるで判らないので指示していただいた方法で取得したものを提示します。
phpinfoのようなものでしょうか？
情報を取得するのにもしかしたら、家主に投げないといけないかもしれないので面倒掛けて申し訳ないのですが、方法を指示していただけませんでしょうか？
よろしくお願いします。
こちらは別問題かも
amayadoriさんの方は別問題という気もしますね。
ホワイトスクリーンになるのはある意味で正しいのですが、それなのに翻訳ファイルがダウンロードできないのは変です。
どこを確かめて貰ったらいいのか判りませんので、もうちょっとお待ちください。
時間が取れ次第調べます。m(__)m
よろしくお願いします。
とりあえず、件のweatherモジュールの方はpotファイルが付属していたし、swsを使って吐き出せたので、それ使ってpoファイルを作ったので、ゆっくりお待ちします。ご面倒おかけします<(_ _)>
ここで相談する話でもないのかもしれませんが、今回の翻訳時に、コアの単語と同じ単語が使われている文字列があったのですが、意味合い的にはまるで別な日本語を当てないとあまりよろしくない(意味が通じない訳ではないが日本語としてはおかしい)ケースがありました。
Visibilityという単語ですが、swsにてローカルで吐き出したときにこの単語には表示可否という単語がセットされてました。weatherモジュール上ではどうも視界という単語を当てた方が良い気がするのですが、これをしちゃうとコアの翻訳を上書きしてしまうのですよね？
こういうケースはこれからも(過去にも？)出てきそうな気がするのですが・・・どういう対応をするのがいいんでしょう。
こちらは余談なので・・・後日、ゆっくりとでも。
難しいですね。
今のDrupalではどうしてもそういう問題が出ます。Viewsの「View」も「表示」になっちゃいますし...。
コアの翻訳も拡張モジュールと同様に変更していっていいと思うのですが、すべてで意味が通る訳を考えるのが難しいですね。
とりあえず、コアの方のVisiblityがどういう使われ方をしているか見てみます。が、「視界」ではないでしょうね、多分。
"表示"ですかね？
保存されている文字列を調べてみました(と言うことは、調べないで投稿してました<(_ _)>)。
表示可否という日本語はどうも手前のAdSenseモジュールで使われているようでした。スミマセン。
Visibilityと言う単語(先頭文字を小文字にするとたくさん出てきました)、コア側で特にblockモジュールで多く使われており、そこでは"表示"という日本語として当てているようでした。
おそらく、AdSenseモジュールの時もその辺に合わせて表示可否のような表現をしたのだと思います。
そうは言ってもお天気情報モジュールの情報表示画面で"表示"と言うのも、"表示可否"というのもどちらも変な気はしますので悩みは解決はしません。逆に、AdSenseやブロックモジュールで"視界"と言うのもどうかとは思うので実に悩ましいところではありますね。
英語では同じ単語で別な意味として表現できるモノでも、言語が違うと同じ単語で別な意味を持たせられとは限らないので、今の言語対応の落とし穴という感じですね。
ローカル対応すればいいのだろうけど、それをやっていくと共通文字列というのは少なくなってしまってデメリットが多くなりそうですからね・・・(^_^;)
ワタシの翻訳の範囲では調整はできるかもしれないですが、他のモジュールで使っていないという保証ができない以上、悩ましいことになりそうですね。