[wp-hackers] no-code-duplication i18n for WordPress
wordpress at santosj.name
Wed Mar 5 14:03:33 GMT 2008
Sabin Iacob wrote:
> Jacob Santos wrote:
>> Well, I think this part of the discussion has been beaten to death
>> 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
True. The plugin author would need to have a function, which does
nothing that also has the metadata using __() somewhere. This will add
the metadata to the pot file and will loaded with translate.
> 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)
As long as it is Python and not Ruby, then I have no quarrels. I should
point out, that not everyone is on a host (although hosts are being
"cool" by including both more) which has Python and Ruby. Godaddy? Nope.
I would have one in PHP just to be sure, but default to the Python in
the case they do have it.
>> 2. The solution hasn't been accepted, because one that hasn't been
>> 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.
Yeah, that is exactly what I said at the time. The discussion link is in
the ticket at the bottom. It happened in January and February and is
about the metadata thread. It is a massive thread, so you shouldn't be
able to miss it.
>> 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.
It isn't going to make it in to 2.5, because even if you test it, they
still can't add it, because they need more people using and testing it
than just three people. It is too close to 2.5 to add at this point.
That is partially why I'm sour about the issue. If it was added back in
January or February before the feature freeze, then it could have been
more formally tested and accepted as stable when 2.5 came out.
The only code that will be accepted is the second proposal, which has no
current code and may skip 2.6 and be moved to 2.7, unless someone writes
the code. If no one else does, then I may get around to it for 2.7, but
that is two point versions, which a solution existed previously and was
not accepted. Oh well. You lose some, you gain some, but I'm still not
happy about the situation. I suppose that by the time 2.6 comes out that
I'll come to my senses about the issue and try to implement the proposal
(if no one else has at that point, three months? A lot can happen, if
more i18n people want a solution).
> 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
Some other gettext parsers will in fact parse the PHP variables and
also, the __() will pollute the WordPress .pot file with variables. It
was changed to translate to prevent those, but still allow for using
variables to get the metadata.
> * 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"
Well, I mean there are a lot of "what if"s in plugin_get_contents. The
padding isn't really needed, but it would be completely painful
debugging experience for plugin authors if part of the description was
cut off. The reason the first multiline comment is not grabbed is that
there is no way to do that without either pulling even more than the
1.5kB or pulling some random number and checking to see if the "*/
exists. In some extreme cases. The multi-line comment is massive with
the required information half way. While, in most cases, it will still
be less than the full file and therefore not cause any memory
exhaustion, I still would have the padding, even if it is totally hackish.
> * (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
The plugin author can put the .mo file in any directory they want. It
just defaults to the folder the plugin is in. I also think the common
theme is to not take away the flexibility of the plugin developer. Some
plugin developers are professionals and are probably already doing it
that way. However, at best, I think you should inform and get the word
out about your recommendations.
Add it to the codex, I mean. "This is what you do to add translatable
code and here are some recommendations to doing it right." I have to
admit this topic is something that I didn't understand myself and if
this resource was available, it would have helped me do it right, the
> I'll apply the patch and see what I can come up with if I get some
> spare time.
That would be helpful, but it is unlikely that the patch will be
accepted, even with more testers. I forgot to mention, but the core team
will not accept anything other than the second proposal (or something in
lines with the second proposal that is better). Thank you, but it
wouldn't help change their minds about the issue. I've already debated
the issue every which way I can think of. I'll be happy, if you can
provide the needed endorsement, but the patch was DOA and is unlikely to
>> I would rather see input on how the other issues that haven't already
>> 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
>> 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 :)
I actually think the only issue that wasn't covered or fixed was the /*
I18N_START */ stuff /* I18N_END */ proposal. However, from what I can
interpret of that, is that it has already been created as a tool.
> 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).
I'm actually not that very good at the whole Localization and
Internationalization. However, I would love to get my hands dirty and
there is one guy in mind that is very good at the stuff. I suppose the
problem is getting it down into words, so that someone who wants to make
a patch is able to fully meet your requirements.
http://www.santosj.name - blog
http://funcdoc.wordpress.com - WordPress Documentation Blog/Guide Licensed under GPLv2
Also known as darkdragon and santosj on WP trac.
More information about the wp-hackers