@Roland– We need to do a better job with supporting multilanguage. The issue is that Piklist builds most of the translatable items dynamically.

Any suggestions would be appreciated.

@emzo– Thanks for the suggestion. We contacted WPML a few days ago, and are in the beginning stages of working with them.

Wish you posted this a few weeks ago, it would have saved us some time. 😉

Can I suggest that where possible, if any WPML specific code is required, it would be better placed in a separate “bridge” plugin, rather than in Piklist core. This way, it keeps Piklist clean and minimal if multilingual capability is not required.

Jason Bobich followed this approach with his Theme Blvd WPML bridge plugin. Also Gravity Forms has a separate WPML bridge plugin, as do many of the leading WordPress eCommerce plugins.

Hi piklisters!

I’m not sure that a wpml bridge is in fact needed. Here are my thoughts about this:

1. piklist need to better respect wordpress i18n:
– In many places, the code use the “__” function but without specifing the piklist text domain.

Exemple : $title = __('Piklist Widgets') in class-piklist-widget.php:60
It should be $title = __('Piklist Widgets', 'piklist')

Using a plugin like codestyling localization (http://wordpress.org/extend/plugins/codestyling-localization/) helps because those strings appear in the “default” text domain (98 strings, including the piklist demos add-on).

– Using i18n functions with function calls or variables result in untranslatable strings:

Code like this : $title = __($title); or this $description = __('Widgets for the ' . get_current_theme() . ' Theme.'); is not translatable using usual tools.

This blog article from Otto explain why you can’t do this:
http://ottopress.com/2012/internationalization-youre-probably-doing-it-wrong/

2. In many places, piklist calls __() but with its own text domain and not the plugin text domain

Exemple : in post_type_labels() there are calls like
'name' => __(self::pluralize($label), 'piklist')

It can’t works: i have a custom label, piklist pluralize it and then we ask gettext to find it in the piklist text-domain and obviously it won’t.

3. Strings in files headers (title, etc.) are not translatable

(see this thread: http://piklist.com/support/topic/title-translation/)
Piklist uses get_file_data on those strings, but it is not enough.

To be translatable on wordpress.org, wordpress plugins have to define their text domain and domain path in the main plugin file header:
* Plugin name: my-plugin
* Text Domain: my-domain
* Domain Path: languages/
(see http://codex.wordpress.org/File_Header#Plugin_File_Header_Example)

Piklist could use these headers to translate the strings specified in other plugin file headers.
Something along:
– when you search for “plugin type: piklist”, store the text-domain of each piklist plugin ;
– when rendering a view, call get_file_data() ; foreach header do header=__(header, plugin-text-domain).

4. Piklist functions Pluralize and Singularize are only usable in english
I don’t see this as a problem. These functions are very pretty if you work in english or for prototyping, you just write:
‘labels’ => piklist(‘post_type_labels’, ‘Demo’)
and it works.

But you can also specify all the labels if you want and it will work fine with piklist:
‘labels’ => array(
‘name’ => __(‘my cpt name’, ‘my-text-domain’),
‘add_new’ => __(‘add a my cpt record’, ‘my-text-domain’),
…
),
(see : “labels” in http://codex.wordpress.org/Function_Reference/register_post_type#Arguments)

5. i18n also have impact on dates formats and so on
Code like this is probably not correct: $datef = __('M j, Y @ G:i');
We should used the format defined in worpress options (get_option(‘date_format’)).

Hope it helps !

Cheers,

Daniel

@Daniel– STEP 1 of your 5 step plan will be in the next release… it’s the easiest one. 😉