Forum Replies Created

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
  • in reply to: Multilingual Options #489

    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 ( 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:

    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:
    Piklist uses get_file_data on those strings, but it is not enough.

    To be translatable on, 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/

    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

    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 !



    in reply to: Conditions in 0.6.6 #440

    Yes, 0.6.7 was worth the wait! I still have to play with taxonomy and user fields, but I will definitively have usage for that in a near future. Well done, guys!

    But it seems that conditions are still broken in version 0.6.7 (see my initial post above). Is it still on the radar ? 😉



    in reply to: add extra choice to 'select' #376


    Here is what I did in my own code:

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

    Hope it helps !



    in reply to: title translation #342

    @Steve- I had the same question some times ago and I’m not sure that your suggestion is doable : from what I see, piklist loads the string from text-domain “piklist” and not from the text-domain of the plugin:

    add_meta_box( ... __($data['name'], 'piklist') ...)

    If I add a string in my PO with domain “piklist”, it seems that wordpress ignores it:

    #@ piklist
    msgid "test"
    msgstr "translation of test"

    I guess that wp don’t like PO files with multiple text-domains (plugins like “CodeStyling Localization” warn about that)…

    Any clue?


    in reply to: Conditions in 0.6.6 #311

    Ok. I’m impatient! Do you have any info about this update ? (date, new functionnalities, roadmap…)



    in reply to: Small patch for windows #147

    Another one:

    In PikList::render(), you’re testing for an absolute path by checking if the first char is ‘/’ (line 125 in class-piklist.php).
    $_file = (substr($view, 0, 1) == '/' ? $view : self::$paths[$_display] . '/parts/' . $view) . (strstr($view, '.php') ? '' : '.php');
    It can’t work on windows: an absolute path can be \xxx ou X:\xxx and so on.

    I think you need an isAbsolutePath() function like this one which is from symfony: (at the end of file).

    The code would become:
    $_file = (self::isAbsolutePath($view) ? $view : self::$paths[$_display] . '/parts/' . $view) . (strstr($view, '.php') ? '' : '.php');

    With that, it seems that PikList is happy on windows! Didn’t do extensive tests, but I’m able to play with the demos!

    Keep on the good work,


Viewing 6 posts - 1 through 6 (of 6 total)