Internationalizing a plugin with half a dozen shortcodes like:

function plugin_show_schedule( $atts, )
       extract( shortcode_atts( array(
        'type' => __('week', 'mz-mindbody-api')
            ), $atts ) );
        //Do stuff
        return $something;
add_shortcode('plugin-show-schedule', 'plugin_show_schedule');

And found an article describing some ways to translate shortcodes like this:

function plugin_show_schedule( $atts, )
       extract( shortcode_atts( array(
        __('type', 'my-plugin') => __('week', 'mz-mindbody-api')
            ), $atts ) );
        $type = ${__('type', 'mz-mindbody-api')};
        //Do stuff
        return $something;
add_shortcode(__('plugin-show-schedule', 'my-plugin'), 'plugin_show_schedule');

I can get type to translate as expected, but plugin-show-schedule is remaining in en_EN and there are comments in the above article saying:

  1. "translating the shortcode tag, another plugin couldn’t reliable hook into this filter"
  2. "as a translator with 36 years of experience I can only smile – any real professional translator worth his salt will be able to spot short codes and will obviously NOT translate them!"

From my understanding, English is the fundamental language of programming, but my experience is also quite Anglo-centric. Are internationalized plugins expected to have translated shortcodes, and if it is advisable, why isn't my code working?


Based on answer below is replacement method for extract:

$atts = shortcode_atts( array(
        'type' => '1'
            ), $atts );
    $type = $atts['type'];

(Now the source of $type is visible within the current scope.)


Before I start, you should never ever use extract(). It is unreliable, and extremely hard to debug when it fails. For this specific reasons, it was (almost) completely removed from core and the codex. For more complete details, see trac ticket 22400. Along with query_posts, these are the two most commonly used and two worst functions to use.

Lets get back to the actual point. Shortcode names and attribute keys should never be made translatable, and should always be in English. It is bad practice and error prone doing it otherwise.


  • If a shortcode name is made translatable, any text can be used as a shortcode name. What this implies is the following:

    I have a shortcode [somename]. Now, I can decide to use it as follow, [anothername]. I download a plugin which have a shortcode called [anothername]. BANG!!! You have a naming clash. Which shortcode should be loaded

    Words with same spelling have different meanings in different languages, yet the spelling of the word is a valid word in English. Take the simple word bang. In English, is a word that descibes the sound of an explosion. In Afrikaans, which is my native tongue, it means afraid if it is translated to English. Now, I have a shordcode [afraid]. Because I am Afrikaans, I want it [bang]. I download an explosive plugin with a shortcode [bang], and BOOM!!! goes everything. (boom is the Afrikaans word for tree, yet another word valid in English and another language with different meanings


  • PHP do not allow duplicate keys. Take the following scenario

    I have a the following shortcode: [someshortcode key='value']. In my shortcode, my attributes are __( 'key' ) => 'default' and 'somekey' => 'some other value'. As I can enter any text for key, I decide to use somekey as my translated value. BOOM!!! Your shortcode fails and give unexpected output and you don't know why. You spend hours debugging and cursing just to find out your translation is the culprit

  • Shortcode attributes are filterable if the shortcode_atts third parameter are set. Making the attribute keys translatable can have unexpected results when filtering the attributes through these filters

These are just a very few important notes to why not making shortcode names and attributes translatable.

You should only make text translatable that will be sent to screen and what will be viewable by the end user. And remember, although it does not make sense to you, stick to English when you develop themes and plugins

| improve this answer | |
  • Thanks as always Pieter Goosen. Is there a recommendation as far as permalinks? create-account vs crear-cuenta – MikeiLL Jun 23 '15 at 9:22
  • 1
    I'm not quite sure about permalinks, but you should not have any problems. I know there are plugins using this method to load the same content in another language. To be honest, I'm still struggeling with permalinks and rewrites, so I cannot say for sure. If I'm not mistaken, this issue has been handled in the past. I know the common problem is that you get 404 errors. There are plugins available that let you have multilingual posts etc. – Pieter Goosen Jun 23 '15 at 9:37
  • For example, create-account loads the English post and create-cuenta loads the Spanish ( if I'm correct at identifying the language :-) ) version of the post. – Pieter Goosen Jun 23 '15 at 9:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.