[wp-hackers] Improving Plugin (and Theme) metadata

[kingler]

Hi, Nikolay

First of all, I like the idea of using the gettext translation on the
metadata. It requires no extra effort from the plugin author and will
be backward compatible. However, one issue I can see is that it would
mean that each plugin will need a set of po/mo files, stored in a
folder structure. This will force some simple one-file plugin in the
folder /wp-content/plugins/ to be organized into subdirectories.

Your new idea of keeping the metadata in the plugin repository sounds
good, but I am not really seeing how you are going to implement that.
Does it mean that if the user installs a blog with a specific locale,
the plugin/theme metadata for that locale will be downloaded and will
be used to replace the original English metadata? If the blogs have
multiple authors and each one uses a different locale, would it be
possible?

Thanks.

-Liang


On Feb 7, 2008 11:39 PM, Nikolay Bachiyski <nbachiyski at developer.bg> wrote:
> Hello all,
>
> Sorry about the monstrously late reply, the problem had just slipped
> out of my mind.
>
> First I want to stress on one of the goals of this feature: to work
> for both plugins and themes.
>
> Although westi's method of explicitly defining the metadata in php
> code is cleanest and is easier to deal with on our side, it will have
> two side effects, which are not desirable:
>
> 1. Breaks current scheme.
>
> It won't be easy to trick theme authors into adding a special php file
> and calling functions and escaping strings just for writing their
> plugin description. Users will want to use their old themes, so we
> won't be allowed to deprecate comment headers. Ever. Of course, since
> old headers are allowed, theme authors will continue using them. We
> can push for the new ones of course -- but I don't think the gain is
> worth it.
>
> 2.  Harder to parse, without including the php file.
>
> Again, we can't make all plugin developers to start offering their
> plugin in a directory with a special, metadata php file. If we allow
> them to call the register_plugin function in the main plugin file, we
> will have to either include it before it has been activated or try to
> parse the strings out of it.
>
> I really like the idea, but I wouldn't vote for it.
>
> Running the metadata through translate -- it twists the idea behind
> gettext, but could work very well. We can create both shell scripts
> and web interface for generating pot files, which will add the medata
> to it. It is totally doable and is a matter of hours. I would happily
> volunteer to write the code, which does the extraction and formatting
> it for gettext.
>
> Apart from this one, I have another idea: we can keep the metadata
> translations in the plugin repository.
>
> First, imagine users can add plugin/theme translations to the
> corresponding official repository (through the web interface) and the
> translations are visible in the extension download pages. When
> accepting a translation we can ask the translator to give us the
> description, etc. in her language.
>
> Once we have the translations, they will be available through simple
> API and WordPress will download and cache the appropriate
> descriptions. On certain plugin  events: e.g. upgrade metadata will be
> downloaded again.
>
> Happy hacking,
> Nikolay.
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>