See this function which generates the html for the calendar widget/shortcode:
https://github.com/stephenh1988/Event-Organiser/blob/master/classes/class-eo-calendar-widget.php#L78
It simply uses the global $wp_locale. So I’m not sure what you mean by ‘reset’ it – the plug-in doesn’t alter the global at all.
I suspect its because ajax requests (admin & front-end) are considered by WordPress to be ‘admin-side’. That is, is_admin() returns true. I would imagine that it isn’t possible for WPML to do check if the ajax request came from the front-end / admin, and so alter the language accordingly.
Any solutions to this would be welcome…
$wp_locale is set in wrong language, so I tried to reset it after changing current localization by the good one with a WPML method :
class EO_Calendar_Widget extends WP_Widget
{
[...]
function generate_output($month, $args=array())
{
//Translations
// $_GET['eo_lang'] => de
if (isset($_GET['eo_lang']) && !empty($_GET['eo_lang']))
{
global $sitepress;
// get_locale() => fr_FR
// $sitepress->get_current_language() => en
$sitepress->switch_lang($_GET['eo_lang'], true);
// get_locale() => de_DE
// $sitepress->get_current_language() => de
[...]
Next step is reloading plugin textdomain :
[...]
// __('Yes', 'eventorganiser') => Oui
// __('Yes') => Oui
// http://codex.wordpress.org/Function_Reference/unload_textdomain
unload_textdomain('eventorganiser');
// http://codex.wordpress.org/Function_Reference/load_plugin_textdomain
load_plugin_textdomain('eventorganiser', FALSE, dirname(plugin_basename(__FILE__)) . '/../languages/');
// __('Yes', 'eventorganiser') => Ja
// __('Yes') => Oui
[...]
It works fine with EO strings, but calendar is still in the same language than backend.
Then, I tried to reload $wp_locale after relaoding default textdomain, but it seems impossible to unload default textdomain, so this stuff doesn’t work :
[...]
// http://codex.wordpress.org/Function_Reference/load_default_textdomain
load_default_textdomain();
require_once(dirname(__FILE__) . '/../../../../wp-includes/locale.php');
$wp_locale = new WP_Locale;
}
else
{
global $wp_locale;
}
[...]
}
}
Is replacing manually $wp_locale in this function the only way to solve my problem ?
The initials of the days of the week are not translated using the plug-in’s domain. In fact – none of it is, but rather the default WordPress domain (since these generally have all the days of the week/months of the year).
In particular, the following are all used from the $wp_locale global:
$months = $wp_locale->month;
$monthsAbbrev = $wp_locale->month_abbrev;
$weekdays = $wp_locale->weekday;
$weekdays_initial =$wp_locale->weekday_initial;
Hi Stephen,
I’ve been struggling with calendar shortcode/widget problem for a while now.
Would you consider to apply for WPML’s Go Global Program:
http://wpml.org/documentation/theme-compatibility/go-global-program/
You just need to fill form and the people at WPML will review your code and suggest what to do to make it work with WPML -plugin.
I would really love to see this plugin to work 100% with WPML. That would be perfect 🙂
Hi JuTu83,
I think this thread is relating to translating plug-in strings rather than user content. Specifically it seems to be a problem with translation plug-ins that they don’t handle ajax very well – in the case of the widget calendar, the HTML is generated server side, and so translations are ‘lost’.
I’ve actually already contact WPML – so I’ll definitely chase them up about it :).
Hi Stephen,
Thank you for fast reply. It is good to know that you are on top of things and hopefully this will get sorted out soon 🙂
Hi Stephen,
Do you have an idea on when will your plugin be WPML compatible? I’m planning on setting up a WP multilingual website and your plugin looks good, but I need to choose the best plugin for an upcoming events calendar.
Thanks in advance
Jabi
