[wp-hackers] i18n of plugin description

[wordpress at santosj.name]

> Jacob Santos wrote:
>>
>> 3. The third method extends the second and allows for placing all of
>> the locale in the same file. So it extends upon the previous patch,
>> where brackets are used, except that the parsing would be a little bit
>> more slower and the locale would absolutely have to be before the
>> description text.
> I thought of something like this:
>
> /*
> Plugin Name: ...
> Plugin URI: ....
> Description: {de_??} Dies ist eine deutsche Beschreibung. {en_EN} This
> is an English description. {nl} Nederlandse taal.
> Version: ...
> */
>
> (or any other delimiter instead {...} like [...] or $...$ which are
> rarely used in descriptions)
> This should be easy to parse, is quite intuitive, and you don't have to
> insert the description part more than once.
>
> Another solution would be to place only the English description in the
> plugin header and the foreign descriptions in a single file and parse
> this file. This would keep the header clear:
>
> /*
> Plugin Name: ...
> Plugin URI: ....
> Description: This is an English description. {descriptions.lang}
> Version: ...
> */
>
> and the file description.lang:
> {de_??}     Dies ist eine deutsche Beschreibung.
> {en_EN}   This is an English description.
> {nl, dut}     Nederlandse taal.
>
> (or instead of defining the filename in the plugin header there may be a
> predefined filename).
> Solution 1 and 2 are sub optimal since you are definitely violating the
> DRY (Don't Repeat Yourself) principle and they're hard to maintain.
>
> Lutz
>
> BTW: Is this the correct list to discuss this topic or should we move
> somewhere else?)

Hmm, good question. I'm sure someone with more karma will say something,
if it is not. I think it would only be off topic if no implementation is
created.

However, you did give me an idea. Basically, it would be to add locale to
the description to the location (from the plugin description file base).

I think allowing for more than one way should be the best solution. So
instead of having your way or my way, I think I will try to implement both
ways.

The first way is as you say, have one description, and allow for '{' or
'[' and ']' or '}' respectively, to set the locale of the description,
plugin name, etc.

The second way would be to define the PHP file with the alternative plugin
headers, which will be loaded instead for that locale.

/*
Plugin name: ...
version: ...
description: ....
en_US: locale/en_US.php
de_??: locale/de_??.php
az_AZ: locale/az_AZ.php
 */

Execution Flow:

1. Pull in plugin locale file.
1.a. Get locale of WordPress installation.
1.b. Search for "locale:" in comment header.
1.c. If found then go to 1.d, if not found, then skip to 5.
1.d. Open and use that file and continue to 2

2. Find "Plugin Name:" and use text.
3. Find "Description:" and use text.
4. Find etc and use text.

(Basically just how it is now without any further checks for '{...}' or
'[...]' for the locale in the description. It will be assumed that the
locale file does not include any more locale information except the one
listed.)

5. Search for "Whatever:"
6. Search for "{az_AZ}", where az_AZ is the locale of the blog.
7. If found go to 8, if not found, go to 10.
8. Grab text after "{az_AZ}" and either until end of text or until
'{az_A2}' or '[az_A2]' is found.
9. Use text and go back to 5 until all text has been found.
10. If no [...] or {...} exists in text, then use all of text (assume
English) and go back to 5 for next text search else if text does exist,
then use en_US locale or first text before first {...} or [...].

An overview on how both methods can be implemented. Now to just code it
and after an implementation, complain to the commit team until it is in
core. I think it would be great, if this can finally be resolved in 2.5!

As I do have school, it might take some time... hmm. Actually give a few
hours and I should have something. I /should/ be doing homework, but okay,
this fascinates me more than like passing the class with an 'A'.

Jacob Santos