Prepare plugin options for multi-lingual support

by

I’m looking for a way to make my plugin’s options available/translatable across a multi-lingual site.

For example, several of my options are text strings that are then used on the front end.

echo get_option( 'my_plugin_text', __( 'Whoa default text', 'my-plugin' ) );

However, it has come to my attention that these strings are then not translatable by WPML. And I would presume by other multi-lingual plugins as well. The whole point of the options was to give users a way to customize some of the text, but this is currently negated in a multi-lingual context.

Since the option text will vary, it doesn’t seem to make sense to wrap the whole thing in a gettext function:

_e( get_option( 'my_plugin_text', __( 'Whoa default text', 'my-plugin' ) ), 'my-plugin' );

I could wrap the whole thing in a filter, but then people are obligated to know how to write a filter in order to change the text, but again, that defeats the purpose of allowing users to change these certain text strings from the admin.

One suggestion, I’ve received is to use get_locale(). 

$text = get_option( 'my_plugin_text_' . get_locale(), false );
if( $text === false ){
   $text = get_option( 'my_plugin_text', __( 'Whoa default text', 'my-plugin' ) );
}
echo $text;

That seems pretty reasonable, but I’m not too familiar with the multi-lingual plugins to know if that will work universally. Does the locale change on the admin side too, such that someone could save the plugin options in the English version and then save different text for the (for example) Spanish version?

Has anyone ever run into this? Is there another solution that I have overlooked?

1 Answer
1

WP translation functions, are meant to translate static strings. E.g. Regarding options, you should use them to translate the labels, not values.

However, as far I remember, the translation utility of WPML works in contrast to standard translation, i.e. if you use that than you can’t load the transaltion using from .po/.mo files.

If users want to use that feauture, everyone is free to to what they like on it’s own site, but build a plugin upon that is a thing I really would stay away from.

The get_locale() trick can be used to retrieve an option value, but can’t be used to save it: you can be sure that the function returns the language for the page a site visitor is viewing, but get_locale() in admin pages is assumed to return the locale in which the administrator is navigating the admin pages, not the locale of the option value to be saved.

The workflow you need would be something like that:

  • check if site is multi-language. If not just output a field, optionally saving in the form 'my_plugin_text_' . get_locale(). Where even the unique locale is used to build option name.

  • if the site is multi-language show multiple fields for every option, one for each site language. It means that you have to be able to get all site languages, and there is no standard way to this task: you have to look at various plugin docs (or ask plugin support) and then show appropriate fields that will be saved appending to option name the proper locale.

This is such a pain. Not being universal is just part of the problem, it brings a non trivial coding overhead and easily makes your option pages messy and bloated.

An alternative way might be to use standard WP entities, e.g. posts or taxonomy terms to store informations.

E.g. if the option texts you want to be translate are stored as CPT titles you don’t have to mind about translate them: all translation plugins are able to translate CPT titles, and they will provide a translation UI.

I don’t know if your plugin fits well this workflow, but if so, I think it’s a far better way to solve the problem.

Leave a Comment