[wp-hackers] no-code-duplication i18n for WordPress
wordpress at santosj.name
Wed Mar 5 14:07:29 GMT 2008
This would be great on a Codex Page! Make sure to add a link from the
main Plugin Development page, so that people can find it. Also, a good
post like this will most likely be lost, so make sure to post back with
a link to the codex page.
Andrew Ozz wrote:
> IMHO the best and probably easiest way to do this is by standardizing
> the way plugins are written for WordPress:
> 1. Each plugin should be in a sub-directory of /wp-content/plugins.
> That way the plugins directory will be better organized and new users
> won't make the mistake of putting a plugin in the wrong sub-folder. I
> know there are many plugins that are installed directly in
> /wp-content/plugins, but what's wrong with putting them in a sub-dir
> if that would benefit new users? Also lots of plugins already follow
> 2. Each plugin should contain a directory named "languages" or similar
> with .pot and .mo files in it. The names of these files should be
> [plugin-name]_[locale].pot/mo and the first few lines of the .pot
> would be the plugin's meta. We can even provide a template for the .pot.
> It would be very easy to scan all .mo files when WordPress loads the
> plugin page and display the relevant language if it exists, or default
> to English if it doesn't. The average size of a plugin's .mo is just a
> few KB, so even if there are 40-50 plugins it won't take much memory
> or make the plugins page noticeable slower.
> Of course all this won't happen overnight, and the current display of
> plugin's meta would have to be supported for a while, or perhaps we
> can keep it as a default in case the plugin is not translated, but the
> sooner something like this is implemented, the better.
> Jacob Santos wrote:
>> Well, I think this part of the discussion has been beaten to death
>> literally actually).
>> 1. There is already a solution to the problem in Trac, which was
>> create by
>> Jennifer and me. I think it is quite excellent, but why don't you
>> test it
>> to see?
>> 2. The solution hasn't been accepted, because one that hasn't been
>> yet (although, honestly Ryan or a member of the core team or community
>> member might have already started on it) was just that.
>> The central argument is whether to include the current solution, which
>> works and then obsolete it when the proposed better one comes along
>> or not
>> include the finished solution and wait until the proposed solution is
>> created, tested, has test cases, and is included in core.
>> Unless you have thoughts on either the first point, or the second,
>> then I
>> think we'll go around in cycles beating the same issue to death once
>> You will find that both solutions are excellent (well, the first is
>> in my
>> opinion and I also love the second).
>> I think that unless you have solutions to the metadata, the one that is
>> proposed, that the discussion is rather pointless.
>> I would rather see input on how the other issues that haven't already
>> beaten to death or solved. I think it is rather interesting to see what
>> people come up with. I've yet to fully read the entire proposal for
>> but I'll probably get around to it tonight.
>>> Anirudh Sanjeev wrote:
>>>> okay then how about this:
>>>> A seperate description text file for each language, in a seperate
>>>> or along with the .po files. All it's gonna be is desc-fr.txt or
>>>> desc-it.txtand wordpress can detect this along with the appropriate
>>>> textdomain and
>>>> install them. This way the issues with size and translation are
>>> the idea was to avoid creating several files (there was an older
>>> proposal to add a file called metadata.php which would contain, well,
>>> the metadata, so wordpress would not need to load the whole plugin for
>>> that); some people seem to have the strange habit of putting all their
>>> plugin data and the kitchen sink into one file (php, html,
>>> have yet to see base64-encoded images, but I wouldn't be very surprised
>>> to see it one day).
>>> I, for one, am for something like:
>>> can has metadata.php?
>>> include metadata.php
>>> parse teh plugin teh old way
>>> since a separate file would be overkill for small plugins
>>>> Also the major problem with adding them in the PO file is that the
>>>> localization file is loaded only when the plugin is activated or
>>>> load_plugin_textdomain is called
>>> that's why metadata.php is a better idea: it could also
>>> load_plugin_textdomain if needed ;o)
>>> wp-hackers mailing list
>>> wp-hackers at lists.automattic.com
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
http://www.santosj.name - blog
http://funcdoc.wordpress.com - WordPress Documentation Blog/Guide Licensed under GPLv2
Also known as darkdragon and santosj on WP trac.
More information about the wp-hackers