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

[Heiko Rabe]

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)