Translating plugin's meta, was [wp-hackers] no-code-duplication i18n for WordPress

Andrew Ozz admin at laptoptips.ca
Wed Mar 5 20:19:55 GMT 2008


I would put it in the codex, but it's still just a proposal.

Currently all plugins hosted on wordpress.org are required to have
readme.txt, following specific formatting and are wrapped in a folder
with the plugin's name when downloaded.

It shouldn't be hard to auto-make a sub-directory named "languages" if
it doesn't exist and add an empty .pot template named
[plugin_name]_en.pot to it. The .pot would contain the meta strings,
allowing them to be translated. It could even fill it with the current
plugin's meta the same way it displays it on Extend - Plugins. I'll ask
Mike about this.

I was planning to go through older tickets this evening, as there are
many that are fixed or invalidated by the changes in 2.5. But perhaps
should start on a patch implementing this and see how it goes.

Jacob Santos wrote:
> 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 
>> 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
>>> again.
>>>
>>> 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
>>>>> directory,
>>>>> 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
>>>> plugin data and the kitchen sink into one file (php, html, 
>>>> javascript, I
>>>> 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?
>>>>     yarly
>>>>         include metadata.php
>>>>     nowai
>>>>         parse teh plugin teh old way
>>>>     kthx
>>>>
>>>> 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
>>>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>>>
>>>
>>>
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
> 
> 



More information about the wp-hackers mailing list