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

Andrew Ozz admin at laptoptips.ca
Thu Mar 6 18:22:36 GMT 2008 

I think you misunderstood this a bit. The truth is that almost all 
problems with internationalization of plugins and themes metadata can be 
fixed by standardizing the way both plugins and themes are build for 
WordPress.

If we require them to be in a directory with plugin's/theme's name 
(which is the case with most of them now) and  have a sub-directory 
named "languages" containing all available translations in the form 
[plugin/theme-name]_[locale].po/mo, it will be quite easy to look for 
these files when displaying the metadata without the need to load any 
.php or other additional files, etc.

The .pot files will have to include the meta strings at the top and the 
plugin/theme authors would enter the information there. We could provide 
an empty .pot making this even easier.

The only problem with this method is that all plugins and themes will 
have to be updated to use it, but that's the case with all the other 
methods too. Whit this method, all that's needed is to add a 
sub-directory named "languages" to all plugins and themes that doesn't 
have one, and to include an empty .pot file in it, allowing it to be 
translated. I don't think that would put a lot more load on the download 
server.

When a plugin/theme metadata is translated, the translator can contact 
the author asking her/him to add the new translation and it can also be 
included on the [lang].wordpress.org site too.

Jacob Santos was suggesting to add this message to the codex, so it 
doesn't get lost, not to use the codex for translation, etc.

Anirudh Sanjeev wrote:
> i'm seeing two problems with this:
> 1. if a server has fsockopen disabled, it might not work
> 2. this way for translation, you're forcing them to use the codex.
> 3. might create undue stress on the codex servers(or I guess they can handle
> it)
> 
> On Thu, Mar 6, 2008 at 1:49 AM, Andrew Ozz <admin at laptoptips.ca> wrote:
> 
>> 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
>>>
>> _______________________________________________
>> 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