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

[Jacob Santos]

Sabin Iacob wrote:
> 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

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

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 
> domain)

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

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

>
>> 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 :)

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.

-- 

Jacob Santos

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.