It's a shame that - whereas Xinha has lots of languages available - htmlarea does not make use of them, with the result that the editor buttons always display their information in English.

A very easy hack to improve this is to put this in function _htmlarea_load_js()

1) At the beginning of the function add:

  global $user;

2) Then replace the line

  $output[] = "  _editor_lang = \"en\";";

with this

  $output[] = "  _editor_lang = \"".$user->language."\";";

There is only one problem - no check for exactly which languages are available in Xinha and defaulting back to English. This doesn't bother me, since all the ones I want are there. But if you wanted to do it cleanly then you would make that check.

Comments

gordon’s picture

I have asked for help on this before, as I am just a little moari boy that only knows english.

The implementation of this has always been easy, but I will have to do some additional work, and the fact that the Drupal languages are not a 1 to 1 match.

So is the best method using the $user->language, what about anonymous users, how do they get the correct language as well.

I am happy to make the changes, but I do not have the knowledge of how this should work. If you want to help I will make the modifications for htmlarea to make use of the languages.

joel_guesclin’s picture

I can't help feeling that there is an easier way to find out the site default language, but until somebody answers my query, here is a suggestion for code to detect the user language to display in htmlarea.
Note that this makes one key assumption: that the Drupal language codes are the same as the xinha ones - however, as long as everybody sticks to the approved iso standard as mentioned in the Drupal locale module you should be ok.

This extra function will return English as default if the locale module is disabled, or if the user language is not available for xinha. Anonymous users get the site default language (or English if site default unavailable for xinha).

NOTE: irritatingly, there is not a function to get the "default language" from the locale list. However, looking at the code in drupaldocs, I see that the array is sorted by "isdefault" - ie the first item in the array is the default language. This is not very satisfactory in my view - but I didn't like the idea of writing another select statement.

Here is the function:

function _htmlarea_lang() {
  global $user;
  if (!module_exist('locale')) {
    return 'en';
    }
  else {
    if ($user->language) {
      if (file_exists(_htmlarea_get_jsdir()."/lang/$user->language.js")) {
        return $user->language;
        }
      else {
        return 'en';
        }
      }
    else {
      $langs = (locale_supported_languages());
      $ulang = key($langs['name']);
      if (file_exists(_htmlarea_get_jsdir()."/lang/$ulang.js")) {
        return $ulang;
        }
      else {
        return 'en';
        }
      }
    }
}

You then modify the line of code in _htmlarea_load_js() which takes care of the editor language, to this:

  $output[] = "  _editor_lang = \""._htmlarea_lang()."\";";

Hope this helps

gordon’s picture

I have added this to cvs. Thanks very much.

I have made some changes so that it will also make use of the i18n module if it exists to better detect the anonymous users languages.

If this is working I am going to add a new page to the configuration so that user defined languages can have the correct language selected.

I also think some changes need to be done for the plugins as well.

Can you please test this and if it is all working I will extend it.

joel_guesclin’s picture

All being well I will be testing this for several languages (though without the i18n module, which I would love to use but prefer to avoid till it gets into core) over the next 2-3 weeks. So will let you know how it goes. I presume this means that I should install the cvs version of the module rather than the standard 4.6.0 one?

gordon’s picture

Yes this is correct, the cvs version will work on 4.6.0 without any problems at this stage. At this point in time I am not planning to backport this to 4.6.0. Maybe with alot of testing I will backport it.

joel_guesclin’s picture

Category: feature » bug

Just discovered a minor glitch in the htmlarea language settings. I am testing in the Spanish language, and find that the special characters do not display properly. I presume that this is because Drupal does everything in UTF-8 and the language-specific javascript is in ISO8859. Don't know if it is possible to convert the javascripts in "lang" directory to UTF-8?

gordon’s picture

You will have to ask the Xinha guys this question, they will be able to answer this.

joel_guesclin’s picture

Just installed the cvs version dated "v 1.78 2005/05/25 13:15:02" and there is a call to "module_exists(i18n)" - which doesn't exist. It should read "module_exist(i18n)".

gordon’s picture

Assigned: Unassigned » gordon

fix in cvs now. 1.79

druvision’s picture

I have tested the HEAD (1.80) version with Hebrew and the tooltips are indeed displayed in Hebrew.
Not all things are translated, but it works without problems so far.

The only issue is that I am getting the following error in the admin logfile:
"not found: modules/htmlarea/xinha/plugins/FullScreen/lang/he.js"

druvision’s picture

The fullscreen works correctly. The logfile error is only cosmetic, but not a real issue.

gordon’s picture

I found that for the plugins I was not loading the correct language so I changed this with a fall back to en

gordon’s picture

Category: bug » feature

I think this is complete now.

Anonymous’s picture

michalska’s picture

For rtl languages (ie Hebrew) where do I specify the text direction on startup?

gordon’s picture

I did a little investigation. If you add the following

body{ direction: rtl; }

into the "page style" field it will change direction of the text globally. Looking on the xinha.python-hosting.com site I think there has been some issue, and I am not sure if these have been fixed.