Support national short forms for months in calendar

As I’ve reported before, calendar-small.php outputs the Finnish months in the wrong form: “January” is “tammikuu”, and the short form is “tammi”, equivalent for “Jan”. No one uses “Tam”, ever, but that is what EM gives here.

Some other languages in which short representation of the month doesn’t equal the three first letters of the full name: Arabic, Azerbaijani, Greek, Estonian, Farsi, Hebrew, Croatian, Hungarian, Armenian, Indonesian, Korean, Lithuanian, Polish, Tamil, Thai, Vietnamese and Chinese. In other words, something like half the population of the planet.

What’s new is that calendar-small.php has been updated: instead of forcing three-letter short forms for all languages it now checks the settings:

echo ucfirst(date_i18n(get_option('dbem_small_calendar_month_format'), $calendar['month_start']));

The result is still the same as before, “Tam” instead of “Tammi” for Finnish ands similar misrepresentation for every other language listed above. EM has included the proper translations in http://plugins.trac.wordpress.org/browser/events-manager/tags/5.4.4/includes/js/i18n/jquery.ui.datepicker-fi.js for 3 years, so it’s a shame that the calendar widget doesn’t get the correct strings from anywhere. As it is, we’re stuck with maintaining a customization to the template replacing the above line with:

$custom_month = date_i18n('M Y', $calendar['month_start']);
if ( function_exists( 'qtrans_getLanguage' ) && qtrans_getLanguage() == 'fi' ) {
  $custom_month = preg_replace( '/kuu /', ' ', date_i18n('F Y', $calendar['month_start']) );
}
echo ucfirst( $custom_month );

Until the proper translations are used, Events Manager will suffer from:

1. All users of the languages listed above are seeing incorrect language in their EM site
2. Except on sites that use this workaround, which leads to
2.a) either having to check and synchronize changes to the template with every single EM update, or, when skipping a few versions to save time for actual development work,
2.b) risk having issues due to non-synced updates to the template, and then filing bug reports that eat up the development time for siteadmins and EM developers.

One way to fix this:

1. Add shorthand months to the EM translations.
2. Use those instead of date_i18n( ‘M’ ).

#2 can be implemented without breaking customizability by parsing the setting string before passing it to date_i18n(), and replacing any M with the lookup for the proper translation string.

A permanent fix should possibly be implemented at date_i18n() level, but that might take a long time before it’s implemented. In the meanwhile a few lines of code go a long way in properly supporting that half of the planet that is currently seeing incorrect month names when accessing an EM site.

http://wordpress.org/plugins/events-manager/