[wp-hackers] no-code-duplication i18n for WordPress
iacobs at m0n5t3r.info
Wed Mar 5 08:55:12 GMT 2008
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.
* I am not sure why you need to call translate instead of __()
(xgettext can recognise php variables and won't pollute the core text
* 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
I'll apply the patch and see what I can come up with if I get some spare
> 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).
More information about the wp-hackers