Language support for TinyMCE

[capt_kirk]

===BACKGROUND===

I haven't been able to figure out a way to restore the native TinyMCE language support. It looks like tiny_mce_gzip.php will apply wp_translate_tinymce_lang, which in turn applies the overall WordPress mo and po files. So, if there is a phrase that's in the master mo and po, you're good to go. But since the TinyMCE plugins are not WordPress plugins, there is no obvious way to make and apply a mo and po file for them.

The only language files that ship with the WP instance of TinyMCE are the en.js files. The only phrases that I could find supported in the overall WP mo and po files are in support of the TinyMCE WP help popup. If you want to install the other lang files from TinyMCE, e.g., de.js or zh_TW.js, it appears you're out of luck.

===PROPOSED CHANGE===

I propose changing the following code in tiny_mce_gzip.php to allow loading TinyMCE lang files, if they exist. The code change finds WP's locale setting (xx), and then checks to see if there are corresponding xx.js files for core TinyMCE, the active TinyMCE theme, and any plugins. If there are not corresponding xx.js files, then the default en.js file is loaded. After that, the the wp_translate_tinymce_lang function is still called.

Patch to wp-includes/tiny_mce_gzip.php attached

[capt_kirk]

tiny_mce_gzip.php.diff

[capt_kirk]

I believe this is a significant issue for international support and should be in 2.0.2.

Thanks,
Kirk

P.S., I forgot to give credit to Stephen Chu for doing a significant amount of the development for this patch. He had the core idea. I cleaned it up and turned it into a patch.

[capt_kirk]

Raising priority to high to match Sewar's input on ​2158, which I closed as a duplicate. (I already had the patch posted here, so it was easier to leave this one open.)

[ryan]

Doesn't break anything for me using en. We have ​confirmation from an es user. Any other confirmations?

[stephenju]

Yes, I can confirm that the fix enables me to use Traditional Chinese in tinyMCE as capt_kirk proposed. Please add it to the code. Thanks.

[ryan]

(In [3623]) Language support for TinyMCE. Props capt_kirk and Stephen Chu. fixes #2476

[ryan]

(In [3624]) Language support for TinyMCE. Props capt_kirk and Stephen Chu. fixes #2476

[pkirk]

1. get_locale() returns "en_US" if WPLANG is empty (like default) and this patch search for /langs/en_US.js but it doesn't find that and goes with /lang/en.js .
   
   
2. I've got the italian translation of WP that calls itself "it_IT" (as many other that calls themself in the "xx_XX" format)(to be put in the wp-config.php at WPLANG's define) so this patch search for /lang/it_IT.js but I've downloaded translation for TinyMCE from ​capt_kirk's site and they are most in the xx.js format (the italian translation looks like "it.js").
   
   

I think that something has to be modified. Maybe only the name of the TinyMCE's translation .js files.

Thank you,
Paolo

[skeltoac]

Paolo: I am working on updating TinyMCE to 2.0.3. In the process, I am fixing the language support to look for the js files in this order:

xx_YY.js
xx_yy.js
xx.js

How does that sound?

[SteveAgl]

The language format xx_XX is a standard to identify the language and the country, eg. it_IT nad it_CH or pt_PT pt_BR that identify italian for Italy and Switherland or portughese for Portugal andd Brazil as described in ​http://www.ietf.org/rfc/rfc3066.txt.

I think that the best way is to compy to this standard and use the same method used for ,mo file then looking for a .js file with esactly the same name defined in the wp-config it's the best practice. My 2 cents

[gwagenknecht]

Note that there is also a region information possible. For example sgn-US-MA means "Martha's Vineyard Sign Language, which is found in the state of Massachusetts, US".

Usually you define a locale string and that can be either "en-US-MA", "en-US" or just "en". The lookup should happen in the exact same order starting with the most specific one and falling back till the default one.

I never found such a region locale string in the real world it may possible but IMHO WordPress does not need to support it.

I think the following should be suitable.

1. xx_XX
2. xx

AFAIK the lowercase "xx_xx" is not supported usually.

[skeltoac]

From RFC 3066 linked by SteveAgl:

All tags are to be treated as case insensitive; there exist
conventions for capitalization of some of them, but these should not
be taken to carry meaning.  For instance, [ISO 3166] recommends that
country codes are capitalized (MN Mongolia), while [ISO 639]
recommends that language codes are written in lower case (mn
Mongolian).

gwagenknecht, we are supporting xx_xx because that is how the language files that are distributed with TinyMCE are named.

When looking for the language file, we will try as-is, then force lowercase, then try only the first two letters. This is already in the code so I'm closing this.

See ​wp_tinymce_lang

[(none)]

Milestone 2.0.2 deleted