Internationalisation and use of _() function for variables

[GoogleCodeExporter]

What functionality do you want to see?

The __() function could be wrapping variables such as post_title so that  
taking-care-of-transation plugins could correctly split the string value if it 
is made of two (or more) language parts.

I'm referring to Backend only, customized_hierarchical_post_types() function in 
StandardizedCustomFields.php where I noticed the Parent drop down menu showing 
a long string, but maybe similar variables are used elsewhere.

Please provide any additional information below.

The qTranslate plugin, as an example, take the standard Title and Content 
fields and replace one text box with n boxes according to how many languages 
are set to be supported.
When saving, the values of these n boxes are merged together and each one is 
prepended with a language-defining tag (i.e. <!--:en-->In ENG<!--:it-->In ITA) 
then saved as a single post_title.

The __() function wrapped on such variables when retrieved has the effect of 
splitting them back and showing only one (in the preferred language) post_title.

On a not-multilanguage site the string is returned as is, just like __() 
function normally does when it doesn't find a corresponding msgid in .pot file.

Original issue reported on code.google.com by m.sivi...@webartisan.it on 5 Jan 2012 at 8:39

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Also support for WMLP: Wordpress Multilanguage Plugin  would be useful.

Original comment by ever...@fireproofsocks.com on 10 Jan 2012 at 10:13

[GoogleCodeExporter]

I added this to the StandardizeCustomFields bit where the custom hierarchy, and 
I'm working to add this to the various Ajax thickbox controllers that list 
data.  I'm not sure which fields might get actively translated by 3rd party 
plugins but I suspect it's the following:

* post_title
* post_content
* post_excerpt

Original comment by ever...@fireproofsocks.com on 24 Jan 2012 at 2:51

• Changed state: InProgress

[GoogleCodeExporter]

Thank you!
I can confirm for post_title because, as you know, I found it on my way and it 
populates a dropdown menu. 
As for post_content I don't know yet where it appaers and what controls it 
populates but believe that if it is only used in the standard "Main content 
block" the qTranslate will take charge of splitting it into the correct tabs, 
but I still haven't found it in a field.

If you need it to test it with qTranslate installed before releasing, just let 
me know if and how I can help.

Original comment by m.sivi...@webartisan.it on 24 Jan 2012 at 4:11

[GoogleCodeExporter]

Ok, I think I got this all in... can you please test this out with the lates 
version (0.9.5.6)?  Thanks.

Original comment by ever...@fireproofsocks.com on 25 Jan 2012 at 4:04

• Changed state: Fixed

[GoogleCodeExporter]

Tested 0.9.5.6 both on a multi(3)lingual and single (french) language 
installation and it works on the custom hierarchycal post_type dropdown.

post_excerpt is used when Excerpt field is enabled for the specific custom post 
type, isn't it? Anyway it also works, though for translating that field one 
must have "qTranslate META" (sub-plugin) installed.

As for the post_content it seems to work in the default WYSIWYG area but 
testing here is difficult due to a (known and reported) issue of the qTranslate 
plugin itself.

Is there any element else where you make use of post_content and post_excerpt? 

Original comment by m.sivi...@webartisan.it on 25 Jan 2012 at 9:55

[GoogleCodeExporter]

Thanks for the feedback!  The only other place where the post_title etc. is now 
being translated is in the various relational fields (relation, image, media), 
specifically when you select the related field in the thickbox: since it lists 
posts (usually by their title), I went ahead and passed the title, excerpt, and 
content through the __() function.  Passing data through that function should 
be benign -- if there's nothing to translate, the input is returned unchanged 
(albeit with a bit more overhead).  Keep an eye on it and let me know if 
there's something I missed.  I'll poke around and see if there's a workaround 
for the WYSIWYG limitations.

Original comment by ever...@fireproofsocks.com on 25 Jan 2012 at 3:52