[wp-hackers] no-code-duplication i18n for WordPress

[Jacob Santos]

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


-- 

Jacob Santos

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.