In wpml version 2.3.4 the following fix is required in order for custom fields (included those used in amr-events) to be copied correctly. (Note: I am not a fan of modifying source code as this may take you out of the upgrade path. However this change is required for wpml to work correctly. Hopefully they will include it in the next upgrade.)
It has come to my attention that in wpml 2.3.4, new event creation is somewhat ‘broken’ – this may be due to new code added in wpml to address previous bug in earlier versions where custom fields were not being copied initially. See previous bug: post-15871.
The events / wmpl test site at lang.anmari.com has been updated to lastest everything (wp, wpml, and events plugins) , so you can see the problem in action there (yes anyone can login).
When wpml is enabled
Basically it appears that when wpml is enabled, and one tries to save a new event, the event custom fields are overwritten with array versions of themselves.
I wonder if it is related to this kind of problem related by Andrew Nacin.? or maybe fetching without the ‘single’ flag (returns an array) and then updating ? Tried to search through wpml code, but all get_post_meta’s seem to have the flag set (Aside: Hmm what would happen if one did need multiple values with same meta key ie not single??)
Weirdly enough the events plugin does in many instances check if gets an array instead of expected value due to ics being able to have multiple values of some things. However there is only supposed to be 1 timezone and 1 start date, so it falls over there with these wpml created array values.
I’ll look to see what can be done to get around this for now (as one of you has a site going live soon), however it would be better if it were resolved by wpml as there may be other consequences. I’ll cross post over there too.
Update: struggling to come up with a fix, since fix for ‘new’ events breaks old events. May have to wait till wpml fix and in meantime, revert to earlier wpml version – at least with that version one could workaround the issues.
Want a multilingual website with an events plugin ? WPML works with amr-events (or the other way around!) – with standard posts or custom post types.
Please note that WPML is not necessary if all you want is events in another language with localised dates and numbers. If all you want to do is create a translation manually, the code-styling localisation translation plugin (free) is handy.
WPML is a free plugin that you can use to either create translations manually, or pass translation requests through to their ICanLocalize [aff] service. IcanLocalize requires payment for translations.
With WPML, how to make it work
It is gratifying when plugins integrate seamlessly, using WordPress as it is intended. I designed amr-events with this in mind – that one should be able to use a host of other plugins with it and was happy to discover that paid off here. In addition WPML enables plugins and themes to pre-configure some bits for you to make it even easier. Thus the necessary XML file is now included in the plugin files.
Check the WPML settings (see advanced below) to be sure that it has picked up the info from the .xml file
check the custom field copy settings. This is essential to be sure that the event data goes with the translation. Think carefully about the LOCATION (address) field.
check the “translate custom post type” settings (if using custom)
check the blog post retrieval setting if no translation
Create some representative events in original languages
Create the translations. WPML should copy the necessary event data. This event data is essential for the translation to be picked up as an event in a language calendar.
Create your calendar page, add shortcode, save
Create the translation page of the above calendar page, add same shortcode, save
View calendars in original and other languages, check that events that have been translated are showing up on the appropriate pages.
If you experience any problems with event data copying, then please explore the WPML configuration as follows:
In WPML settings, go to MultiLingual Content Setup, scroll down to the custom fields, and check all the events fields for “copying”. See list at bottom of this post. Note: Decide whether you want “_LOCATION” addresses to be copied or translated. The XML file is currently set to copy, but the next version will be to translate. If this is an inappropriate default, please let me know.
If you are using custom post types and taxonomies, scroll down a bit further and tick boxes for those too to enable translation for them. Since you can create your own taxonomies for events, it is not possible to pre-configure these for you. (Remember to flush permalinks)
Under WPML > Languages, please scroollll down to more options, check “Blog posts to display” – this choice may impact your events retrieval.
See screenshots below.
Without WMPL, single language content possible, with translated plugin files
Amr-events aims to localise, using recommended WordPress functions for translation and date and number display. So if there is a language .mo file, it should use that for all text’s produced by the plugin.
Without a .MO file – dates and numbers will localise
Even without the mo file, with the calls to WordPress date and number localisation, you may find the public output (the dates etc with your language content) tolerable if your event creator can handle the english prompts!
RTL css for event creation.
I have included a basic RTL css for right to left languages, however am aware that it may not be adequate. I would welcome input from anyone using a right to left language.
Please note that I am reliant on people using it in other languages to provide feedback and pickup on any details that are not localising or are not RTL compliant. I will fix those asap.
Translations are always appreciated (by others at least! – hard for me to know how accurate or up to date they are!). Translations should be in .po and .mo format. Thanks.
Custom fields to mark for copy in WMPL:
In the wpml settings, the radio buttons will be greyed out if preset from the xml file
Location fields (amr-events and other geo plugins that integate)
/* own fields */
_LOCATION (optional -it is the address, you may wish to translate rather),
/* _wpgeo fields*/
/* geolocation fields no underscore */
/* _gpress posts */
Ical fields not yet in use, but may be later. Update required if you use new functionality: