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

[Jacob Santos]

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
>


-- 
Jacob Santos

http://www.santosj.name - Personal Blog
http://funcdoc.wordpress.com - WordPress Function Documentation Blog