Hi, I’m using this wonderful plugin in a multilanguage site (translations by the mean of qTranslate).
I created a custom content type with just standard ‘Title’ and ‘Content’ fields. When rendered in a “Add new” or “Edit” window qTranslate take charge of generating the two different titles’ text boxes, one for each language.
Then I created a new custom content type that is meant to be hierarchically below the other one. I checked the ‘Page attributes’ > ‘Hierarchical’ in order to have the Attributes‘ meta box.
Now, when editing this content the meta box is correctly generated but the Parent drop-down menu contains a very long string made up of the two post_title (in the two languages).
My temporary solution was to edit the
customized_hierarchical_post_types()function on line 144 by replacing $p->post_title with __($p->post_title).
Just using the __() standard WP function (that is somehow overridden by qTranslate) allows the Parent drop-down menu to show only one title, in the backend choosen language.
Don’t know if this is something that is going to be considered in future versions but just wanted to let other multilanguage sites’ users that this worked for me.
Sorry, I forgot to mention that the
customized_hierarchical_post_types()function is in custom-content-type-manager/includes/StandardizedCustomFields.php file.
Man, that sounds hacky all the way through. If qTranslate has overridden WP’s __() function, then it’s moving in the wrong direction to try and modify that behavior any further (in my opinion). It might be possible to intercept the fields as they are read and pass them through various filters to enable translations. If you want to make a feature request, please do so in the bug tracker. I already have slated one for internationalization for version 1.0, when the functionality has settled down:
Hi, pardon my english. Maybe “overridden” is not the correct term and I didn’t mean to say that qTranslate does it (actually I don’t really know what it does 🙂 ). Apologize me for saying that.
What I wanted to express was that just by adding some __() (as you wrote in the issue report) for some important variables that normally are not supposed to be translated, such as post_title, can prevent these little problems.
The problem with __() and the other gettext localization functions is that you can’t actually translate a variable. I mean, the function works, but the PoEdit and other localization tools won’t pull that out as a viable dictionary entry for translation. I wrote a chapter on this in my book: http://www.amazon.com/WordPress-3-Plugin-Development-Essentials/dp/184951352X
But I’m babbling… maybe simply wrapping the variables in the __() function will make qTranslation work. It’s worth adding to the issue tracker so I can look at it in more detail later.
I added the issue as a feature request (though not so important) with a small explication of what qT does.
- The topic ‘[Plugin: Custom Content Type Manager] translations in custom. hierarchical post’ is closed to new replies.