|
sboisvert
|
June 26, 2012 at 11:56 pm
Hi there,
I first want to make clear what we want to accomplish, we don’t want to have events only in one non-english language, we want to have events in multiple (really only 2 in our case) languages. For our particular scenario, not all events need to be in both languages at all times.
Now while I at first thought of WPML. Now while this might work for some parts in some ways since Event espresso doesn’t use custom post type it might just be taking on something that doesn’t need to be tacked on. Word on the street is that there is a version 3.2 coming out ‘soon’ we wouldn’t mind coding against that if it has structural changes.
The way WPML handles multilingual posts is that it creates a post for both languages and then adds a filter in the query to get the right post when its looked up. Would this be the right way to go in Event espresso? create 2 separate events and create a linking table that links them and add some filtering so that you only see the events in the language you are browsing in? Do you have another suggestion?
Thank you for your time.
-Stéphane
|
|
Josh
|
June 27, 2012 at 9:05 am
I do. We are actually looking into adding support for the qTranslate plugin.
So something like this:
would become:
Here’s more info about getting a plugin to add support for qTranslate:
http://www.qianqin.de/qtranslate/forum/viewtopic.php?f=3&t=294
-
This reply was modified 12 years, 5 months ago by
 Josh.
-
This reply was modified 12 years, 5 months ago by Josh.
|
|
sboisvert
|
June 27, 2012 at 12:16 pm
Thanks Josh!
We use __() and _e() extensively for string translations. Now regarding your example, I believe __() will not have the desired effect. qTranslate works like WPML, and from what I gather from the link only static text can be translated with __() [or static text with placeholders] not dynamic text. And by Dynamic text what I mean is user generated, stored in a database and not some that is hard coded in a file.
The way WPML and I suspect qTranslate works for __() is that is scans all the files and builds a list of strings to be translated. Now qtranslate and WPML offer a dynamic way of adding strings to their translation interface, $output = qtrans_useCurrentLanguageIfNotFoundUseDefaultLanguage($output); and icl_t(context, name, value) (http://wpml.org/documentation/support/wpml-coding-api/) (for more info on context see here: http://codex.wordpress.org/I18n_for_WordPress_Developers#Disambiguation_by_context )
So lets say we were to add filters and then use either qtrans_useCurrentLanguageIfNotFoundUseDefaultLanguage or icl_t() in the case of WPML this would only make the strings such as event description and etc appear in the wpml string translation backend like such: http://www.liberal.ca/files/2012/06/wpml.png which is far too cumbersome for most of our users (we want to allow users in various offices to submit events for approval with the permissions plugin) Therefore an interface more like this: https://www.liberal.ca/files/2012/06/language.png where the events are linked in some fashion and they are entered by the end user twice or some info is entered twice would be preferable.
What are your thoughts on this?
Thanks again,
-Stéphane
|
|
Josh
|
June 27, 2012 at 2:24 pm
Sounds like you know more about this than I do.
If we were going to add ML support to Event Espresso, we would have to make it possible to change dynamic strings, so the example I gave above wasn’t the greatest.
You raise an interesting thought about the user submitted end of things. We’re actually working on a front-end event submission tool that will work along with the permissions add-on. Adding ML support to Event Espresso isn’t something we’re able to tackle right now, but we are certainly looking into ways to make it work with ML plugins/solutions.
|
|
Chris Reynolds
|
June 27, 2012 at 5:23 pm
@ Stéphane
__() can be used for dynamic text/variables. We use it all over the place in the code. That solution was actually sent to us from a user who is using qTranslate and they got it from the qTranslate devs.
What you may be thinking is _e() which canNOT be used with variables but rather needs to be a string.
-
This reply was modified 12 years, 5 months ago by
 Chris Reynolds. Reason: clarification
|
|
sboisvert
|
June 27, 2012 at 10:43 pm
Hi Chris, Thank you for that.
In truth I don’t know qTranslate, I only got what I read from Josh and extrapolated that it did the similar thing as WPML. WPML also sorta handles __ and _e with dynamic text, the problem is that it doesn’t ‘know’ the string before runtime and therefore you can’t see them in the backend to put in the translations. But if there is a translation for a string that happens to be the one that is generated, that will get translated.
WPML works by scanning the files, collecting the strings and presenting them in the backend and you input the translation. Now it seems that qTranslate does store these strings and permit you to do this. So that’s pretty cool. Sadly we’re stuck on WPML for better or for worse :P.
The good news is that I’m not looking for you guys to build the multilingual events aspect. We’re more than happy to do that ourselves, we’re just looking for guidance in terms of what you guys would think is the best way to logically structure multilingual events. Is it to just dump all the strings in a translation plugin? That’s a bit harder to use for the end user than if we were to create 2 events and link them or something of the sort.
Your thoughts on the matter are greatly appreciated
|
|
sboisvert
|
June 27, 2012 at 11:35 pm
Turns out WPML has a feature called Auto-Register strings that takes the content from __ and _e and registers it as strings to be translated, its just off by default and a bit hidden!
That means it would be ‘relatively’ simple to put all the content thru __() calls. Is that the best solution instead of trying to build a way to make it easier for end users to manage events in multiple languages in a efficient manner?
|
|
Josh
|
June 28, 2012 at 8:40 am
I don’t know what the best solution would be for WPML. We haven’t tested or developed with WPML in mind.
|
|
Chris Reynolds
|
June 28, 2012 at 11:19 am
I don’t know what the best solution would be for WPML. We haven’t tested or developed with WPML in mind.
…that said, if WPML supports __(), it should work in the same way (assuming you’re doing that in the actual template files and it’s not something that gets done in the post or something like that). Again, we haven’t had a chance to test this all that much, but I do know that someone was able to get qTranslate working this way (or at least, we didn’t hear that it wasn’t working after we pointed them in this direction in response to qTranslate’s support response for how plugin developers could/should handle their strings to allow them to be supported by their plugin.
But, we can’t guarantee it will work flawlessly because, again, haven’t had the opportunity to do much testing or implementation. However, this is the route we are/I am planning on pursuing to try to make EE multilanguage-compatible.
we’re just looking for guidance in terms of what you guys would think is the best way to logically structure multilingual events. Is it to just dump all the strings in a translation plugin? That’s a bit harder to use for the end user than if we were to create 2 events and link them or something of the sort.
Yes, but that would be a whole lot easier to implement than trying to link to separate events (which would involve some SQL magic to get the event information to sync up, and some more SQL and PHP and possibly some JS magic to filter the version that is not in the language you want to display from appearing in the event list and on the calendar). Getting some kind of multilanguage plugin to read your event description variable and spit out the correct translated string is much simpler.
-
This reply was modified 12 years, 5 months ago by Chris Reynolds. Reason: added more of a response to the original question
|
