[wp-hackers] wordpress.org *.pot file feature for plugins gets broken by PoEdit

[Heiko Rabe]

Sorry, litte mistake at code but for sure it was thought as $plugin_data 
instead of $plugin :-)

function my_plugin_data($plugin_data) {
   $plugin_data['Name'] => __('....', 'custom-field-images'),
   $plugin_data['Title'] => __('....', 'custom-field-images'),
   $plugin_data['PluginURI'] => __('....', 'custom-field-images'),
   $plugin_data['Description'] =>__('....', 'custom-field-images'),
   $plugin_data['Author'] => __('....', 'custom-field-images'),
   $plugin_data['AuthorURI'] => __('....', 'custom-field-images'),
   $plugin_data['Version'] => __('....', 'custom-field-images'),
   $plugin_data['TextDomain'] => __('....', 'custom-field-images') ,
   $plugin_data['DomainPath'] => __('....', 'custom-field-images')
   return $plugin_data;
}
add_filter('wp_plugin_data-' .'custom-field-images', 'my_plugin_data');

But nevertherless the problem description is still valid, verfied with 
PoEdit (lost this entries as obsolete) and a lot of online/ofline 
translation systems able to scan sources also loosing this entries.

regards

Heiko Rabe
(www.code-styling.de)
> Today i discovered, that plugin header fields (shown at plugin install 
> pages) can be translated too.
> This only can be done, if the *.pot file will be used directly the 
> service of wordpress.org is able to created.
> Any attempt to rescan the sources through PoEdit wipe out this fields 
> as obsolete!
>
> Example out of "custom-field-images" plugin *.pot file:
>
> #. Plugin URI of an extension
> msgid "http://scribu.net/wordpress/custom-field-images"
> msgstr ""
>
> #. Description of an extension
> msgid "Easily associate any image to a post and display it in post 
> excerpts, feeds etc."
> msgstr ""
>
> #. Author of an extension
> msgid "scribu"
> msgstr ""
>
> #. Author URI of an extension
> msgid "http://scribu.net/"
> msgstr ""
>
> This dissenting message entry creation is not standardized and won't 
> work with normal gettext pasing applications.
> There should be introduced a safe way this can also be handled by 
> re-scanning with gettext applications, otherwise this feature is 
> worthless.
> One option would be a section of code only for purpose of getting this 
> right by gettext processors like:
>
> function my_plugin_data($plugin_data) {
>    $plugin['Name'] => __('....', 'custom-field-images'),
>    $plugin['Title'] => __('....', 'custom-field-images'),
>    $plugin['PluginURI'] => __('....', 'custom-field-images'),
>    $plugin['Description'] =>__('....', 'custom-field-images'),
>    $plugin['Author'] => __('....', 'custom-field-images'),
>    $plugin['AuthorURI'] => __('....', 'custom-field-images'),
>    $plugin['Version'] => __('....', 'custom-field-images'),
>    $plugin['TextDomain'] => __('....', 'custom-field-images') ,
>    $plugin['DomainPath'] => __('....', 'custom-field-images')
>    return $plugin_data;
> }
> add_filter('wp_plugin_data-' .'custom-field-images', 'my_plugin_data');
>
> I have left the message texts as '....' just for illustration.
> If the file /wp-admin/includes/plugins.php would get patched, this can 
> be requested by apply_filter() calls for active plugins and also works 
> for not loaded plugins the current way.
>
> But the goal is, that gettext processors now normally been able to 
> find those translations because they are normal part of gettext 
> detection.
> Anyone would be able to rescan a plugin (as example if i gets modified 
> and/or rewritten) without loosing this plugin field translations.
>
> This is a first try to cover up this issue, it need not to be the best 
> so far solution but it is one.
>
> What's your opinion about ?
>
> regards
>
> Heiko Rabe
> (www.code-styling.de)
>
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>