The above code is using filters, so something else is amiss. The location filter is the same as in your link, but still location names are displayed as “<!–:en–>Location Name<!–:–><!–:fi–>Paikan nimi<!–:–>” instead of “Location Name” or “Paikan nimi”.
The above code is in a plugin. Can’t test right now, but would it make a difference if it was in theme’s functions.php?
i’m not sure… would have to test qtranslate to figure this out and no time for that atm.
i think it’d be to do with your odering of filters, e.g. qtransalte hasn’t figured out the language it’s in at that time.
That qTranslate function uses default language when unsure. That code kicks in for some shortcodes, for example as #_EVENTNAME. The only non-affected shortcodes seem to be #_EVENTLINK, #_EVENTCATEGORIES and #_LOCATIONLINK. What they have in common is that they return HTML instead of a plain, translatable string.
Is there a way to make $EM_Event and $EM_Location objects apply filters to all their values upon creation? That way $location_name = $EM_Location->location_name; would always result in a string in a correct language.
yes, you can try to override placeholder ? http://wp-events-plugin.com/tutorials/modifying-placeholder-default-information/
e.g.
add_filter('em_location_output_placeholder','my_em_placeholder_mod',1,3);
function my_em_placeholder_mod($replace, $EM_Location, $result){
if ( $result == '#_LOCATIONNAME' ) {
$replace = $EM_Location->location_name;
}
return $replace;
}
*paste in your theme functions.php
That’s what we’re doing at the moment. We’re looking forward to a more update-safe solution by filters and hooks that complement the core placeholders instead of overriding them.
An option that crossed my mind is whether it’d be feasible to make placeholders in core recursive for one level so they would work like this:
1. #_EVENTLINK is called
2. The appropriate placeholder rule is triggered via filter em_event_output_placeholder
3. That placeholder calls for #_EVENTNAME, which triggers the appropriate placeholder rule via filter em_event_output_placeholder
This would sound to me like the most suitable way to contain the same functionality within placeholders. #_EVENTNAME and #_EVENTLINK then use the same line of code to retrieve the name of the event, so that any changes to it don’t need to be done in any other part of the code.
The ability to catch every placeholder via filters for multilinguality could be considered one of the best side effects.
I might have found what I was looking for. Testing continues, but so far it seems to me that everywhere where the site displays an event, filter ’em_get_event’ is called. The following adds qTranslate support for event names everywhere that I tested, with the exception for emails.
// qTranslate support for event names everywhere on the site 2013-06-11
// TODO: Notification email support
add_filter( 'em_get_event', 'my_em_get_event_qtrans', 10 );
function my_em_get_event_qtrans( $event ) {
if( function_exists( 'qtrans_useCurrentLanguageIfNotFoundUseDefaultLanguage' ) ) {
$event->event_name = qtrans_useCurrentLanguageIfNotFoundUseDefaultLanguage( $event->event_name );
}
return $event;
}
Next I’m looking into the option of hooking on to line 267 in classes/em-event.php‘s __construct() in the hopes of multilingualizing event names everywhere, including emails:
do_action('em_event', $this, $id, $search_by);
