next »

[yama]

http://modxcms.com/forums/index.php/topic,4910.0.html
詳細はこちら。

[ ダウンロード ]

[yama]

※追記・MODxをEUC運用している場合のみの対応情報です。たぶん。
 UTF-8環境でもGUIが日本語表示されてなければ以下の書き換えをどうぞ。

追加情報です。先日作った日本語化ファイルでは、MODx管理画面のTinyMCEの項目が
日本語化されるだけです。TinyMCE自体が日本語化されるわけではありません。
TinyMCE自体の日本語化については、実は最初から日本語langファイルがutf-8・eucともに
付属しています。しかしMODx自体が持つ言語リソース名をTinyMCEが内部的に持つそれに
変換するルーチンに不備があり、日本語で表示されません。以下のように書き換えます。

MODxの「リソース」→「リソース管理」→「プラグイン」を開き、TinyMCEを開いてください。
51行目に以下のような記述があります。

Code:

case "japanese-utf8":
$returnlang = "ja";
break;

これを以下のように書き換えます。

Code:

case "japanese-utf8":
$returnlang = "ja_utf-8";
break;

case "japanese-euc":
$returnlang = "ja_euc-jp";
break;

で、保存して対応完了！です。
英語言語リソースのキャッシュがブラウザに残っているかもしれませんが、
キャッシュをクリアするなどしてみてください。
拡張子jsのファイルだからか、けっこうしつこく残ることがあるみたいですが。

http://modxcms.com/forums/index.php/topic,5403.msg41172.html#msg41172
こちらにも報告を出しておいたので、もしかしたら次から標準で対応されるかもです。

[kecha]

現在TinyMCE 2.0.6.1aを使用しています。
最新版では上記のルーチンの不具合は修正されているみたいなのですが本体部分がどうしても日本語になりません。
皆さんは本体の表記も日本語になっていますか？
色々な環境で試してみるもうまくいかなっかたので質問させていただきました。

英語表記でも問題なく使用できるので構わないのですが何か気持ち悪くて...。

[yama]

0.9.5にTinyMCE 2.0.6.1aをインストールしてみましたが、たしかに英語表記ですね。
仮にen.jsをja_utf-8.jsにリネームすると日本語化されますが。
管理言語判定のルーチンあたりが少し変わったのかな？

[ZeRo]

これはバグですね
プラグインテンプレートの以下の一番下の1行を追加することにより、正しい言語を認識するはずです。

Code:

function getTinyMCEScript($elmList,$webTheme='',$width='',$height='',$lang='') {
global $base_url;
　　　　　　　　　　　　：　省略
global $manager_language;

mixiに中途半端に書いちゃいましたが、この修正になります。

[yama]

直りました。開発チームに報告しとくのがよさそうですね。

[ZeRo]

あ、そうですね・・・
どっちがいいんでしょう・・・TinyMCEの作者さんの方なのかコアメンバーの方なのか
どちらにしろ、さて・・英語で・・・は　Yamaさんにお願いしちゃいます

[kecha]

おかげさまで無事日本語表記出来るようになりました。
検証作業までして頂き申し訳ございませんでした。

バグとは思いもしなかったのでこちらの環境設定が間違っているのかと見当違いのことばかりしておりました
ありがとうございました。

[SSMx]

助かりました。
ところで、firefox1.5を使用していますが、TinyMCEで画像挿入すると、新規ウィンドウが開かれかれますが、
サイズ固定で表示され左枠が切れて表示されます。これが正しいサイズで表示されるにはどうしたらよいでしょうか？
_{直接日本語化とは関係ないのかな？日本語で表示されるようになっても改善されないので誤ったところにpostしたかも}

[franken]

はじめまして、今週よりＭＯＤｘはじめました。
よろしくお願いします。

本体0.95に添付しているＴｉｎｙＭＣＥ2.08もＦｒｏｎｔＥｎｄ側が修正されていないようなので、当トピックを読みながらソースを見ていたのですが、対応としては以下の方が正しいような気がしますがいかがでしょうか？

Code:

function getTinyMCESettings() {
global $_lang;
　　　　　　　　　　[省略]
global $manager_language;
// global $frontend_language;

こちらは管理画面側のＵＩの表示設定用の関数で

Code:

function getTinyMCEScript($elmList,$webTheme='',$width='',$height='',$lang='') {
global $base_url;
　　　　　　　　　　[省略]
//add
                global $frontend_language;
//add
$scriptfile = ($tinymce_compressor == 'enabled' ? 'tiny_mce_gzip.php' : 'tiny_mce.js');
　　　　　　　　　　[省略]
// $tinymce_language = !empty($lang) ? getTinyMCELang($lang) : getTinyMCELang($manager_language);
                $tinymce_language = !empty($lang) ? getTinyMCELang($lang) : getTinyMCELang($frontend_language);

こちらの関数の方がＦｒｏｎｔＥｎｄ側かと。。。

[ZeRo]

こんばんは。

プラグインの実際のイベント処理でFrontEndの場合は、$frontend_languageを関数に渡しているので問題なさそうに思えます。

Code:

if(isset($forfrontend)||$modx->isFrontend()){
$html = getTinyMCEScript($elementList,$webTinyMCETheme,$width,$height,$frontend_language);
} else {
$html = getTinyMCEScript($elementList);
}

↑のロジックで。
なので、日本語で出ないのは、

Code:

$frontend_language = isset($modx->config['fe_editor_lang']) ? $modx->config['fe_editor_lang']:"";

ここで、japanese_xxxで返ってきてないんではないかと思います。

frontendで使ってないので実際どうなのかは分かりませんが・・

[franken]

こんばんわ

ちょっと補足いたします。

Code:

if(isset($forfrontend)||$modx->isFrontend()){
$html = getTinyMCEScript($elementList,$webTinyMCETheme,$width,$height,$frontend_language);
} else {
$html = getTinyMCEScript($elementList);
}

↑でgetTimyMCEScript関数に$frontend_languageを渡し、

Code:

$tinymce_language = !empty($lang) ? getTinyMCELang($lang) : getTinyMCELang($manager_language);

↑で$timymce_languageを$manager_languageに置き換えられ、$timymce_languageがＴｉｎｙＭＣＥ自体に受け渡されていると思います。このトピックの対応にあるように、getTimyMCEScript関数に$manager_languageの定義を追加すればロジック上は変数に値が渡りますが、そもそも$manager_languageは管理画面のＵＩに対する文字コードで$frontend_languageがページ編集側の文字コードではないでしょうか？

つまり、私の疑問点は
getTinyMCESettings関数では$manager_language
getTimyMCEScript関数では$frontend_language
の組み合わせが正しいのではないかということですね。
まぁ、管理画面が日本語で、ウェブページ側を英語とかの運用をしなければ問題ありませんが。。。

[ZeRo]

こんばんわ

ちょっと補足いたします。

Code:

if(isset($forfrontend)||$modx->isFrontend()){
$html = getTinyMCEScript($elementList,$webTinyMCETheme,$width,$height,$frontend_language);
} else {
$html = getTinyMCEScript($elementList);
}

↑でgetTimyMCEScript関数に$frontend_languageを渡し、

Code:

$tinymce_language = !empty($lang) ? getTinyMCELang($lang) : getTinyMCELang($manager_language);

↑で$timymce_languageを$manager_languageに置き換えられ、$timymce_languageがＴｉｎｙＭＣＥ自体に受け渡されていると思います。このトピックの対応にあるように、getTimyMCEScript関数に$manager_languageの定義を追加すればロジック上は変数に値が渡りますが、そもそも$manager_languageは管理画面のＵＩに対する文字コードで$frontend_languageがページ編集側の文字コードではないでしょうか？

$fontend_languageは,$langになるので、$tinymce_languageはgetTinyMCELang($front_language)と同じになるんでは？

つまり、私の疑問点は
getTinyMCESettings関数では$manager_language
getTimyMCEScript関数では$frontend_language
の組み合わせが正しいのではないかということですね。
まぁ、管理画面が日本語で、ウェブページ側を英語とかの運用をしなければ問題ありませんが。。。

管理画面は、manager_languageで動作しているのでドキュメント編集時は、manager_languageの文字コードであるべきなので、Settingsでわざわざ文字コードを指定する必要性はないと思います。
なので、Settingsではfrontend側の設定となっているのではないでしょうか？

いずれにしても、TinyMCEのツールバーの文言なので日本語で出ないことが大きな問題にはならないとも言えますね。
今回のFrontendの件を言われるまで、MODxの言語指定は英語のままでした 　

[franken]

なんか、細かい話に時間をとっていただいてすみません。。。
またまた、補足です。

$fontend_languageは,$langになるので、$tinymce_languageはgetTinyMCELang($front_language)と同じになるんでは？

getTimyMCEScript関数の$langがデフォルト引数でブランクになっているので、

Code:

$html = getTinyMCEScript($elementList);

から呼び出されたときは、global変数の$manager_languageになりますよね？

と書きましたが、確かに$manager_languageで統一されれば良いので$front_languageは無視でよいのかもしれませんねー。。。
※$front_languageはユーザに紐づいていないし。。。

[ZeRo]

いえいえ、せっかくのなのでお勉強がてらに・・。

なんか、細かい話に時間をとっていただいてすみません。。。
またまた、補足です。

$fontend_languageは,$langになるので、$tinymce_languageはgetTinyMCELang($front_language)と同じになるんでは？

getTimyMCEScript関数の$langがデフォルト引数でブランクになっているので、

Code:

$html = getTinyMCEScript($elementList);

から呼び出されたときは、global変数の$manager_languageになりますよね？

$elementListだけが引数のときはそうなりますね。
但し、Frontendの呼び出しだった場合は、

if(isset($frontend)||$modx->isFrontend()){
            $html = getTinyMCEScript($elementList,$webTinyMCETheme,$width,$height,$frontend_language);
         } else {
            $html = getTinyMCEScript($elementList);
         }

のロジックでいえば、下の引数１つではない方、すなわち$frontend_languageがパラメタとして入ってる方が呼ばれるんではないかというロジックだと思います。（っていうか、そうとしか思えないif文だと）
なので、Scripts関数のパラメタ$langがemptylの場合は、$manager_languageを引っ張ってくるのでいいんじゃないかな？　っていうのが前回の意味だったんです。

と書きましたが、確かに$manager_languageで統一されれば良いので$front_languageは無視でよいのかもしれませんねー。。。
※$front_languageはユーザに紐づいていないし。。。

確かに、マルチリンガルなコンテンツを作る場合ならユーザに紐づいてないと駄目ですよね。
ユーザ紐付けの視点はありですねぇ、気が付きませんでした。
プラグインでフロントエンドはSJISで出すとかでない限り現状だと分ける意味はあまりないですねぇ。　

[franken]

ZeRoさん、

なるほどー、そうですねー。
でも、getTinyMCEScript関数呼び出すときは$frontend_language渡すのに、関数の中で$manager_languageに入れ替えるのも変ですよね？
もともと$manager_language渡せばいいし。。。
とりあえず、スッキリしました。長々とお付き合いいただきありがとうございました。

なお、$manager_languageはユーザに紐づいてるみたいです。
ユーザの設定画面側の指定が優先されるみたいです。Config側を日本語でユーザ側を英語にしてみたら、ユーザの方が優先されましたから。。。

[ZeRo]

ZeRoさん、

なるほどー、そうですねー。
でも、getTinyMCEScript関数呼び出すときは$frontend_language渡すのに、関数の中で$manager_languageに入れ替えるのも変ですよね？
もともと$manager_language渡せばいいし。。。
とりあえず、スッキリしました。長々とお付き合いいただきありがとうございました。

いえいえ、こちらこそ。

なお、$manager_languageはユーザに紐づいてるみたいです。
ユーザの設定画面側の指定が優先されるみたいです。Config側を日本語でユーザ側を英語にしてみたら、ユーザの方が優先されましたから。。。

なら余計に・・・ですね