Make WordPress Core

Opened 16 years ago

Closed 16 years ago

Last modified 15 years ago

#2476 closed defect (bug) (fixed)

Language support for TinyMCE

Reported by: capt_kirk's profile capt_kirk Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.0.1
Component: General Keywords: tinymce language
Focuses: Cc:



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.


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

Attachments (1)

tiny_mce_gzip.php.diff (3.9 KB) - added by capt_kirk 16 years ago.

Download all attachments as: .zip

Change History (13)

16 years ago


#1 @capt_kirk
16 years ago

  • Milestone changed from 2.1 to 2.0.2

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


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.

#2 @capt_kirk
16 years ago

  • Priority changed from normal to high

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.)

#3 @ryan
16 years ago

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

#4 @stephenju
16 years ago

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.

#5 @ryan
16 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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

#6 @ryan
16 years ago

  • Resolution set to fixed

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

#7 @pkirk
16 years ago

  • Priority changed from high to normal
  • Resolution fixed deleted
  • Status changed from closed to reopened
  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,

#8 @skeltoac
16 years ago

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:


How does that sound?

#9 @SteveAgl
16 years ago

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

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

#10 @gwagenknecht
16 years ago

  • Cc gunnar@… added

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.

#11 @skeltoac
16 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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

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

#12 @(none)
15 years ago

  • Milestone 2.0.2 deleted

Milestone 2.0.2 deleted

Note: See TracTickets for help on using tickets.