In work with the wysiwyg api and img assist and you enabled a language other than English in any of the wysiwyg input formats. If you do so without adding your language in sites\all\modules\img_assist\drupalimage\langs, the tinymce editor will not work. But there is no warning, no indication, except for a file not found error in the log files.

Is it possible to make sure some warning is given on the screen?

Is it possible to add more language .js files to sites/all/modules/img_assist/drupalimage/langs
For instance, for Dutch, could this one be added.

File:
==
nl.js

Contents:
======
tinyMCE.addI18n('nl.img_assist', {
desc : 'Ingebedde afbeelding toevoegen of wijzigen.'
});

Comments

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Title: wysiwyg api + tinymce and img assist: work with other language than English » TinyMCE 3: External plugins break JavaScript if no language file exists

Better title. I'm not yet sure how to handle this issue.

myDRU’s picture

myDRU commented

These kind of bugs must disappear asap, because they cause many people who install tinymce, wysiwyg, img assist, do not get it work and leave the modules for what they are... Therefore, what about this proposal:

For all language for which there is a .po file in the translation directory of image assist:
make sure that there is a corresponding .js file in img_assist/drupalimage/langs.

Next, the code may be as follows, I'll put in pseudo code:

If (.js file for selected language found in img_assist/drupalimage/langs)
Take that .js file
Else
Take the default en.js file.

upupax’s picture

upupax commented

Confirm and subscribe.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Status: Active » Closed (duplicate)

Marking as duplicate of #379182: TinyMCE stopped showing in languages other than English

VanCauwenbergeJan@gmail.com’s picture

VanCauwenbergeJan@gmail.com commented

Confirm.

Ran into the same issue today! Took me half a day to figure out what was wrong...

myDRU’s picture

myDRU commented
Status: Closed (duplicate) » Active

@Sun: By no means this problem is a duplicate of http://drupal.org/node/379182 as you state in #. If you try yourself, to install for instance the Dutch language and then configure at least one wysiwyg input format into language 'Dutch', you will see that tinymce is gone when you try to edit a page. To work around the problem, simply copy sites/all/modules/img_assist/drupalimage/langs/en.js and rename it to nl.js.

To solve this issue: is there not a way to make wysiwyg grasp for the default en.js if the .js file is not found, along with a warning?

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Status: Active » Closed (duplicate)

You are configuring TinyMCE to load the Dutch language, but there is no Dutch language file.

That's exactly the title of the other issue, and exactly the bug that is reported there. Hence, this is a duplicate.

myDRU’s picture

myDRU commented

What do you mean by Dutch language file? The nl.po of wysiwyg?
I installed TinyMCE from the http://tinymce.moxiecode.com and also the language pack from http://tinymce.moxiecode.com.
The fact that somebody can install this http://tinymce.moxiecode.com language pack is one thing.
Whether there is a corresponding .po file for that language in wysiwyg is another thing (and, indeed there is no nl.po).
But these two independent facts lead to tinymce not working any more, which is not monkey proof. Many of us are monkeys, in one thing, although specialists in another thing :-). Therefore I propose wysiwyg to take the default en.js in case .js is not found, and, to send a warning to the screen.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

No, I mean the nl.js you mentioned.

We are in control of .po files, and Drupal does not break when a translation does not exist.

TinyMCE breaks, because it cannot find/load the language file it tries to load via AJAX.

Note, however, that this only applies to internal (native) plugins for TinyMCE. The new Drupal plugins for editors in Wysiwyg API 2.x (such as Image Assist) use Drupal's language/translation system.

myDRU’s picture

myDRU commented

I see, but cannot remain silent. Many people will install wysiwyg + tinymce + language pack, and run away from it because "it doesn't work". And you cannot expect that every user is capable of digging into the details to solve it. Therefore, let my contribution to Drupal be to help out to make it become more user friendly where needed. In case there is no pure, clean and easy software solution to this problem what can we do?

What about delivering a wysiwyg version where we put about about all the .js files one can think of? A pragmatical solution, which takes just a little effort (each .js file only contains one line and no coding is to be done at all). Do you agree? If so, I will send you some translated .js files tonight. Let me know.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

A technical/programmatical solution is discussed in #362318: Limit wysiwyg language selection to available languages (the aforementioned issue mainly serves as placeholder to not derail that dev issue).

A non-technical/trivial solution I can't think of. The most trivial would be to remove the language selector entirely. So, no chance to configure a non-existing language. However, that wouldn't allow to use editors like TinyMCE in other languages (FCKeditor and others feature an auto-detection to some degree).

We cannot ship language files for TinyMCE, because we do not ship with files for libraries.

Perhaps we just need a new or improved handbook page?

myDRU’s picture

myDRU commented

Sorry, my statement in #10 was not fully correct Please deny it! I rewind, because I do see a mechanical workaround/solution, not in wysiwyg as I stated in #10, but in img_assist:

Many people will install WYSIWYG + TINYMCE + TINYMCE LANGUAGE PACK in combination with IMAGE_ASSIST, and run away from it because "it doesn't work". Why does it not work? Because they perfectly installed wysiwyg + tinymce + language packs in /sites/all/modules/wysiwyg/*, but did not know that they must also create manually a .js file in /sites/all/modules/img_assist/drupalimage/langs! This dependency between wysiwyg/tincymce and image_assist is what I want to report via this issue.

What about delivering an img_assist version where we put about about all the .js files one can think of? A pragmatical solution, which takes just a little effort (each .js file only contains one line and no coding is to be done at all). Do you agree? If so, I will send you some translated .js files. Let me know.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

Seems I have to repeat and perhaps re-phrase my amendment in #9:

Note that this bug only applies to native TinyMCE plugins. The new "Drupal plugins" in Wysiwyg API 2.x - like Image Assist 3.x - do not have this bug at all, because they use Drupal's regular language/translation system and TinyMCE does not try to load their language files.

So this particular issue about Image Assist is actually resolved already. All I need to create new releases for both modules is some positive feedback about the latest development snapshots.

myDRU’s picture

myDRU commented

It is very good news that img_assist 6.x-3.x solves the matter, but it is a development release at this moment. What about all the users who opt to install the stable and released versions instead?

For those users, I suggest to still deliver an img_assist (e.g. 6.x-2.0-alpha4) that has a bunch of .js files as a pragmatical workaround to this issue. Please let me know whether you want to incorporate the extra .js files.

To all the people reading this message: if you agree, please quickly submit a translation of the phrase "Insert or update an embedded image" in your mother language to this thread. Based on this we can provide a translatation of sites/all/modules/img_assist/drupalimage/langs/en.js in your mother language.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

Image Assist 6.x-3.0-alpha1 is about to be released, because 3.x is the only version of Image Assist that is compatible with Wysiwyg API now.

myDRU’s picture

myDRU commented

And Assist 6.x-3.0-alpha1 is in combination with the new Wysiwyg API will not contain any problem whatsover any more? You know as well as I do that new release introduce new problems. Just like D7 will introduce headaches for a considerable time, during which many people will be glad to have a D6 where small troubles are still solved... Baselining is soooo important in software.

I can only keep asking: let us cooperate on a stable wysiwyg 6.x-2.0 + img_assist 6.x-2.0 combination. One where no new functionality is added with respect to the current wysiwyg 6.x-2.0-alpha1 + img_assist 6.x-2.0-alpha3, but only small bugs, installation problems, etc are solved. I want to cooperate giving you some of the needed .js files, if you agree. Let me know.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

Sorry, but these are wild assumptions. Did you test IA 3.x-dev? I'm using that code on many production sites already, without any issues.

So, if you think there is a bug in 3.x, then please let me know (in a separate issue), so we can fix the bug before the aforementioned alpha is released.

myDRU’s picture

myDRU commented

Ok. New releases never contain start up inconveniences. Never. Let us release D7 today. And make all modules D6 incompatible immediately.

I really do not understand, why you don't take the point. I've installed many img_assist, wysiwyg, tincymce releases, because it is great sw. But each time, there are hickups. Which is normal. But the defence against these hickups is baselining. And here is where these 2 modules could do so much better.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

I'm trying to tell you that this entire issue you are having with IA 2 does not exist at all with IA 3. Why should we work on workarounds if there is a working, much better, and much cleaner solution already?

As of now, there is no other difference in IA 3 compared to IA 2, because this old-style/new-style Wysiwyg API plugin approach was the only reason to keep them separated.

myDRU’s picture

myDRU commented

Check out http://drupal.org/node/379182 #35

tzed’s picture

tzed commented

Hi guys, I know it's 3 years old thread but I've headed a very similar problem right now using D7 & TinyMCE 3.5.10 - just the missing file in logs is "/sites/all/libraries/tinymce/jscripts/tiny_mce/themes/advanced/langs/*.js". After adding it all ok. Hope this helps.