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
Comment #1
gordon commentedI 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.
Comment #2
joel_guesclin commentedI 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:
You then modify the line of code in _htmlarea_load_js() which takes care of the editor language, to this:
Hope this helps
Comment #3
gordon commentedI 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.
Comment #4
joel_guesclin commentedAll 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?
Comment #5
gordon commentedYes 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.
Comment #6
joel_guesclin commentedJust 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?
Comment #7
gordon commentedYou will have to ask the Xinha guys this question, they will be able to answer this.
Comment #8
joel_guesclin commentedJust 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)".
Comment #9
gordon commentedfix in cvs now. 1.79
Comment #10
druvision commentedI 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"
Comment #11
druvision commentedThe fullscreen works correctly. The logfile error is only cosmetic, but not a real issue.
Comment #12
gordon commentedI found that for the plugins I was not loading the correct language so I changed this with a fall back to en
Comment #13
gordon commentedI think this is complete now.
Comment #14
(not verified) commentedComment #15
michalska commentedFor rtl languages (ie Hebrew) where do I specify the text direction on startup?
Comment #16
gordon commentedI 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.