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

Hi,

Here is what I did in my own code:

[...]
,'choices' =>
array('first-option-value' => 'first option label')
+
piklist( get_pages( [...] ) )
[...]


Hope it helps !

Cheers,

Daniel