Forum Replies Created

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • 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 (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

    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 ? 😉

    Cheers,

    Daniel

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

    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

    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?

    Cheers,
    Daniel

    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…)

    Cheers,

    Daniel

    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: http://svn.symfony-project.com/components/templating/trunk/lib/sfTemplateLoaderFilesystem.php (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,

    Daniel

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