New Community Forums are coming. Watch this space for news.
Subscribe: RSS
  • こんばんは。

    プラグインの実際のイベント処理でFrontEndの場合は、$frontend_languageを関数に渡しているので問題なさそうに思えます。
    			if(isset($forfrontend)||$modx->isFrontend()){
    				$html = getTinyMCEScript($elementList,$webTinyMCETheme,$width,$height,$frontend_language);
    			} else {
    				$html = getTinyMCEScript($elementList);
    			}
    

    ↑のロジックで。
    なので、日本語で出ないのは、
    $frontend_language = isset($modx->config['fe_editor_lang']) ? $modx->config['fe_editor_lang']:"";
    

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

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

      ちょっと補足いたします。
      			if(isset($forfrontend)||$modx->isFrontend()){
      				$html = getTinyMCEScript($elementList,$webTinyMCETheme,$width,$height,$frontend_language);
      			} else {
      				$html = getTinyMCEScript($elementList);
      			}
      

      ↑でgetTimyMCEScript関数に$frontend_languageを渡し、
      		$tinymce_language = !empty($lang) ? getTinyMCELang($lang) : getTinyMCELang($manager_language);
      

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

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

        こんばんわ

        ちょっと補足いたします。
        			if(isset($forfrontend)||$modx->isFrontend()){
        				$html = getTinyMCEScript($elementList,$webTinyMCETheme,$width,$height,$frontend_language);
        			} else {
        				$html = getTinyMCEScript($elementList);
        			}
        

        ↑でgetTimyMCEScript関数に$frontend_languageを渡し、
        		$tinymce_language = !empty($lang) ? getTinyMCELang($lang) : getTinyMCELang($manager_language);
        

        ↑で$timymce_languageを$manager_languageに置き換えられ、$timymce_languageがTinyMCE自体に受け渡されていると思います。このトピックの対応にあるように、getTimyMCEScript関数に$manager_languageの定義を追加すればロジック上は変数に値が渡りますが、そもそも$manager_languageは管理画面のUIに対する文字コードで$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の言語指定は英語のままでした :’( 

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

          $fontend_languageは,$langになるので、$tinymce_languageはgetTinyMCELang($front_language)と同じになるんでは?
          getTimyMCEScript関数の$langがデフォルト引数でブランクになっているので、
          				$html = getTinyMCEScript($elementList);
          

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

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

            Quote from: franken at Feb 05, 2007, 07:32 AM

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

            $fontend_languageは,$langになるので、$tinymce_languageはgetTinyMCELang($front_language)と同じになるんでは?
            getTimyMCEScript関数の$langがデフォルト引数でブランクになっているので、
            				$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);
            }
            のロジックでいえば、下の引数1つではない方、すなわち$frontend_languageがパラメタとして入ってる方が呼ばれるんではないかというロジックだと思います。(っていうか、そうとしか思えないif文だと)
            なので、Scripts関数のパラメタ$langがemptylの場合は、$manager_languageを引っ張ってくるのでいいんじゃないかな? っていうのが前回の意味だったんです。


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

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

              なお、$manager_languageはユーザに紐づいてるみたいです。
              ユーザの設定画面側の指定が優先されるみたいです。Config側を日本語でユーザ側を英語にしてみたら、ユーザの方が優先されましたから。。。
              • Quote from: franken at Feb 05, 2007, 03:41 PM

                ZeRoさん、

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


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

                なら余計に・・・ですね