CRM-21470 Add support for WordPress Polylang plugin

[samuelsov]

Overview

For multilingual sites, CiviCRM has a useful setting to inherit the language from the CMS language.
Unfortunately, in WordPress, there is no unified way to deal with multilingual site so for each i18n plugins, we need to add some code in CiviCRM to support it.

This PR adds support for WordPress Polylang plugin => https://fr.wordpress.org/plugins/polylang/

To reproduce the problem :

1. Install Polylang and configure at least 2 languages
   

2. Configure CiviCRM in multiligual mode with 2 languages and set "Inherit CMS Language"
   

3. In civicrm.settings.php, uncomment as needed lines like : define('CIVICRM_LANGUAGE_MAPPING_xx_XX') (to resolve ambiguity between language short 'fr' and language long form 'fr_FR' or 'fr_CA')

4. Create a contribution page and translate at least the title

5. Add a page with the shortcode to the contribution page and translate it to the second language
   

Before

When visiting the new page and switching language, the form is not translated (CiviCRM default language) - see title and submit button for example.

After

The form is properly translated.

---

• CRM-21470: Add support for WordPress Polylang plugin

[seamuslee001]

ping @mlutfy @kcristiano @christianwach Your thoughts on this? seems fairly sensible to me

[mlutfy]

This would be a same-shop-merge, but it seems OK to me (I haven't worked on this, and if I recall correctly, Samuel had added WPML support, back in the day).

[christianwach]

@samuelsov This looks very promising! I have a couple of questions about scope:

• Is this purely for logged-out users on the front end?
• If not, does this trigger translation of the CiviCRM back end as well?
• How does this interact with the logged-in user's chosen language as set on their Profile page?

(Disclaimer: I have never used Polylang)

[eileenmcnaughton]

I'm strongly inclined to merge this based on reading the code. It simply calls the Polylang function if available (so will have no impact on people who do not have the extension).

I suspect the intersection between wordpress experts & i18N experts is fairly small? @KarinG or @nganivet might fall in the camp..

[christianwach]

I'm strongly inclined to merge this based on reading the code.

Agreed - I see no conflict with existing installs.

What interests me is that activating the inheritLocale setting calls getUFLocale() but getUFLocale() doesn't call get_user_locale() or get_locale() nor is there a fallback to WPLANG (that constant was retired in WordPress 4.7 but I suspect there are a number of pre-4.7 sites still out there). This means the method only has any effect at all when either WPML or PolyLang are installed - hence my questions :-)

[eileenmcnaughton]

I've given this the merge-ready flag to indicate it is considered (by me) 'good to merge' - but there is still scope for some discussion so we should find a balance between rushing to merge & letting it drift off the radar

[kcristiano]

I agree this is an improvement and I see no conflict with existing installs.

[samuelsov]

@christianwach My knowledge of WordPress is somewhat limited, but CiviCRM language content should follow the website current language whatever context :

• logged-out users or logged-in user using the current wordpress language (tested)
• for admin pages if you switch the language before going to CiviCRM - in my case, the admin language switcher is hidden by CiviCRM admin menu, hence the "before" (tested)

[mlutfy]

Merging based on the reviews.