[wp-hackers] no-code-duplication i18n for WordPress
admin at laptoptips.ca
Wed Mar 5 09:48:52 GMT 2008
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 this.
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 (quite
> 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 created
> 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 been
> 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 i18n,
> 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 solved.
>> 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
>> 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
More information about the wp-hackers