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

[Sabin Iacob]

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?
>   

the patch looks fine, but doesn't address adding the metadata to the pot 
files; this is not so much a wordpress concern, though, since plugin 
authors would need to do it :D

providing a script that would extract the info would be nice; I can 
provide what I am using for https://launchpad.net/gscrobbler/ (atm it is 
a setuptools extension, but it can go easily in a standalone script), 
however people might resist adding non-php code to the code base (you 
can shoot me and I won't do shell scripts in php :P)

> 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.
>   

well, until I see some code I can't say much about the second choice 
(the one with metadata written in php), it should be rather easy to add 
later and not break the old stuff.

> 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.
>   

well, I see that it's been moved to 2.6; maybe it could go in 
2.5.something after some testing and if it's complete, and some other 
eyes took a look at it.

For instance
 * I am not sure why you need to call translate instead of __() 
(xgettext can recognise php variables and won't pollute the core text 
domain)
 * I am also unsure of why plugin_get_contents doesn't just grab the 
first multiline comment, instead of blindly reading 512 more bytes "just 
to be sure"
 * (unrelated to your patch) we should have a standard structure for 
distributing mo files; I am totally against just throwing them in 
wp-content/plugins or in the plugin dir, I figure it would be best to 
use wp-content/plugins/pluginname/locale/ll_CC.mo

I'll apply the patch and see what I can come up with if I get some spare 
time.

> 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.
>   

where is that? is there a list of issues somewhere? if you mean the OP 
of this thread, it just reinvents the wheel and makes it square :)

one problem I remember hitting was that admin page hooks, for instance, 
used to be computed from the translated strings, so 
"options_page_inline_gallery" became "einstellungen_page_inline_gallery" 
in German, but something seems to have changed in there, I didn't get to 
look at the source yet (one should translate as late as possible, 
preferably right before displaying, anyway).