Limit language selection to available languages

I gave this another thought. I think this depends on #313497: Allow to configure advanced editor settings. In an ideal world, each editor would just use the current interface language (locale) of Drupal - but that is not possible since editors like TinyMCE need a separate language pack to be downloaded and installed to work correctly.

Originally, I really considered to remove this language selection a few times already. However, if we would do that, each editor would have to provide a separate language detection function - and - in the end, also (external) editor plugins come into the game, for which we do not know whether they provide language files at all.

Needs further analysis.

I'd like to second this request. As you say, ideally it would take it from the langauge of the site (could it not check if the language pack is installed / have an admin supplied list of languages installed and fallback to a default if you're viewing the site in a language it doesn't have a TinyMCE lang pack for?) Given the variety of ways of doing language plugins in different editors, I think it'd be reasonable to expect the admins to add/enable to language in some way and the module can just rely on the list supplied by the admin.

Alternatively, is it possible to create several "TinyMCE profiles" (for want of a better term) for a given input format[1] and let users switch between them (maybe by adding a button to the toolbar or a drop-down list or series of links below the text area next to the "disable rich text editor" link). Preferably users could set their own default too. This would mean I could create an "English" and a "Svenska" and so on profile. It would be a slightly clunky solution to the language thing, but useful in other situations - you could have a "basic" profile and an "advanced" profile with more buttons. Most users use basic but those who are fairly comfortably on computers generally (but still a bit scared at the idea of writing HTML) can use the advanced one if they need it.

[1] Yes, I know I could probably achieve this by creating several, essentially identical, input formats and configuring TinYMCE differently for each one. However, with a lot of the sites I'm involved with it's vital to make the number of instructions and other places to go as small as possible, otherwise people get intimidated and don't post! So, I'd like to avoid having to tell them to go and expand the input formats list and choose one from the scary looking list with all the lists of what HTML is/isn't allowed...

Proper title and version.

The obstacle really is native editor plugins here: If we would extend the API to make editors as well as plugins language-aware, and would configure the editor's language in wysiwyg profile settings (like we do now), then we could probably "hide" plugins and buttons that are not available for the configured language.

However, if we would auto-detect the language (i.e. re-use Drupal's detected language), then we would have to "hide" (limit) the editor's functionality (plugins/buttons) at runtime. Which means, user A would get less buttons in French than user B in English.

Hm. Another option would be to "register" available languages for each plugin, and if the auto-detection requests a language for which not all plugins are available, it would just fall back to the default language (English). That would prevent JavaScript errors, but probably lead to a bloat of support requests of the kind "Why is it working in French, but not in German?".

Note that this issue is limited to native editor plugins. Drupal plugins in 2.x (provided by other Drupal modules) do not have this issue, because they are translated by Drupal and do not need any additional language files.

Subscribe. I have not yet used TinyMCE nor any others... not sure if it's possible in tinymce to configure two languages like "DE, EN" and if DE is missing it falls back to EN? FCK have all languages build in... so we are fine, "nothing" to do.

Tinkering about ImageCache's approach...

TinyMCE and probably all other editors try to find language files in a certain location:

This means we can predict where an editor will look for language files.

Insane idea: Could we

1) Remove the language selection from the wysiwyg profile settings form.

2) Determine the available languages in Drupal via Locale module.

3) Auto-detect and register available languages for each native editor plugin.

4) Dynamically register menu items in hook_menu() for each plugin's language folder, i.e.

5) If the editor requests a language file that does not exist, Drupal takes over the request, gets the file contents of the English language file and returns that as Content-type text/javascript.

?

Certainly, this would only work if Clean URLs are enabled (they are on 99% of all Drupal sites though). If Clean URLs are disabled, we could simply fallback to loading the default language when at least one plugin does not provide the requested language.

Note, however, that "themes", e.g. TinyMCE's Advanced Theme, also need to be translated.

Sounds very good, but why does this approach depends on clean urls? Do you like to to the file exists based on JS (by trying to load it and fall back if it fails) or filesystem exists? I think the last is better... not sure if always work.

It seems you are not familiar with the way ImageCache works. When Clean URLs are enabled, Drupal no longer uses paths of /index.php?q=sites/all/modules/wysiwyg/plugin/break/langs/de.js, but just /sites/all/modules/wysiwyg/plugin/break/langs/de.js. Drupal's rewrite rules in .htaccess direct Apache to first look whether the requested path exists. If it does, Apache serves it directly, not invoking Drupal at all. If it does not, the request URI gets rewritten to the former way and Drupal is invoked, passing the original "path and filename" as $_GET['q'] to Drupal.

This means that Drupal would be automagically invoked for all language file paths that do not exist, but not for those that do exist.

Ah, this functionality... I'm very familiar with this logic, but have not understood what you meant as it was very general.

I know this makes much sense for images... but JS files!? I think this is a too complex solution for requests that are not very expensive and rare (dynamic image generation/manipulation is very *expensive* and time consuming). I would only do some file name tests on PHP level/disk and decide if the JS files get added via drupal_add_js() with /land/[de].js or it needs to falls back to EN - if the JS file doesn't exists. What's wrong with this approach?

The problem is that TinyMCE and other editors do not use drupal_add_js().

> What's wrong with this?

We cannot alter the editor libraries. If you tell TinyMCE to appear in German, it unconditionally tries to load a de.js for each plugin and theme. If only one of those de.js files does not exist, hell is breaking loose, and all JavaScript is breaking on the page. (I was under the assumption that you already faced the issue...)

If this isn't working, we can use oninit : "myCustomOnInit" and build our own JS detection. If the file can be loaded we load it - otherwise not. jQuery helps us...

Something like testing if "tinyMCE.addI18n())" having an array {de:{}} with the language we are trying to switch to - could also solve this problem. I have never developed much for tinymce, but oninit may be our helper.

@hass: Sorry, but you are looking at the wrong places. Each plugin invokes tinymce.PluginManager.requireLangPack() independently, and TinyMCE spawns a new instance of AddOnManager (PluginManager/ThemeManager) for each editor instance. Entire falling back to the default language would only be the last resort (Clean URLs disabled), as already mentioned in #4.

I just discovered the reason why TinyMCE with Img_assist did not work for me.
I declared fr as language for TinyMCE. Then the module looks for fr.js everywhere even in plugins. As there is none in drupalimage module all failed.

I just made a copy of en.js and renamed it fr.js. It is OK now.

But it would be great to have a fallback language (en) to avoid all broken when only one language file is missing.

Here's a patch that makes the following:

- For TinyMCE and FCKeditor, in their semi-implementation of hook_wysiwyg_plugin(), a directory scan retrieves the list of languages installed in the editor package. This list is passed via 'languages' element in the $plugins array. Another element in this array ('languages_help') is added to provide hints on how to download more languages.

- The administration interface to edit editor settings in Wysiwyg API is changes to load the list of languages made available from the plugin itself (previous step). If no language is available, the language option is not added to the form.

I have testes with TinyMCE 3. I'm not sure if what I did for FCKeditor works, or the path to the languages needs to be amended.

Once this is refined, it would be nice to awake #532794: Use current user's language. The list of available languages per plugin could be used to check if the current interface language can be used to dynamically configure the editor based on that. :)

Attachment	Size
wysiwyg_languages-362318-16.patch	4.49 KB

Any idea on whether the approach taken by #16 looks good? :-|

Sorry! I quickly scanned it and it looks like you want to attach the languages to editor plugins. That felt wrong at first sight, but now that I recall that we also have to account for separate languages in native editor plugins, it sounds like a sane idea.

I think that the improved language handling can only be done in 3.x though. There, we want to use classes, both in PHP and JS. Because we also need to account for the fact that a language may not be made available for an editor, if one plugin is not available for that language. Some editors support to pass on a separate language parameter to use for each plugin (those should work, although you'll get an interface in 2 different languages), but I'm pretty sure that not all editors support that - so those editors can only load a language, if the language is supported by all enabled plugins/buttons.

Anyway, this is a great starting point and a neat, little patch! However, I will personally focus very hard on pushing some badly needed patches into Drupal core until code freeze. So I'm afraid I won't find time to work on this prior freeze.

Ok, thanks for the update. Will get back to this when there's more time to work on it. In the meantime, we'll try to live with an alternative solution.

This would be great to have. There is one issue that I'd like to offer comments on, so that a potential problem could be avoided.

It would be helpful to have a way to map the two sets of language codes together when they don't match exactly. This is something we ran across with Google vs Drupal language codes on our sites, so I can see a similar issue arising here.

For instance:
TinyMCE has a language pack for Chinese (ZH), but Drupal supports Traditional Chinese (ZH-HANT) and Simplified Chinese (ZH-HANS)
TinyMCE has a language pack for Portuguese (PT), but Drupal supports both Portuguese (PT) and Brazilian Portuguese (PT-BR)
There may be other cases.

In both of these cases, I would think you'd want to use the TinyMCE language pack that is available, since it would be far better than nothing, but the mismatching codes might prevent it unless a mapping is done.

Thanks for working on this. We're looking forward to the release.