Core Multilingual Support chat notes,…

Core Multilingual Support chat notes, Monday 14 September 2015.
Transcript starts at 16h UTC.

@sc0ttkclark joined us in the discussion after giving @markoheijnen and I admin access to the WP Compare doc. As he’s working on the Fields API project, he was inquiring as to whether there is anything with regard to locale and the core propositions that we’re working on that he should be aware of / that he might take into special consideration.

i assume you have the same concerns with Customizer API

We have not, as of yet, discussed our current proposals/research in terms of other APIs.


  1. What can be localized and translated through po/mo should be.
  2. Where fields are dependent posts they will inherit locale.
  3. Are there cases where fields aren’t dependent on posts?
  4. Are there cases where fields shouldn’t inherit locale?


Core Multilingual Support chat notes,…

Core Multilingual Support chat notes, Monday 31 August 2015.
Transcript starts at 16h12 UTC.

This was a bank holiday in England, but brief discussion was had about:

  1. @chouby mentioning during previous meeting working on a plugin that uses taxonomies  to define locale for posts (and possibly terms). Would be great to get feedback from him about his progress and what challenges he’s run into with it.
  2. My idea to tack on a fourth mission to this project: data. Following Matt’s comments at WCEU about the lack of data, I’m going to start gathering some to use toward a base argument for our general proposal.

@alvarogois popped in at the end of the meeting to say he’s pinged Alessandro Senese about this project and our weekly meetings – author of another plugin we haven’t yet discussed, Ceceppa Multilingua.

Core Multilingual Support chat notes,…

Core Multilingual Support chat notes, Monday 3 August 2015.
Transcript starts at 16h UTC.
Discussion centered around Andrea’s solution (below) for Proposal 2—translating for non gettext strings—in which he proposes a filter.
Marko has added the need to wrap this filter in a function, to account for and avoid human error when applying the filter (comment also below).
Marko also stated that he would have a draft for Proposal 3 by the next meeting (today!)

Jenny notes that she is better at facilitating meetings than at writing up meeting notes.

News from Polylang

I reached out to Frédéric Demarle, the author of Polylang, who has been following the discussion from afar but hasn’t been available as of yet to participate directly. He says he’ll still be tied up for the next two weeks, but invited me to share his point of view / questions with everyone here.

@simonwheatley his username is polylang.

From the email he sent me:

I am not sure of the objectives.

Is the goal to ease writing of multilingual plugins? We have already almost 30 plugins on the repository which offer the most important features. There are however some minor issues that the core could help to fix but I guess that’s the same with every kind of plugins. Mathieu Viet clearly showed in WordCamp Lyon that BuddyPress has more hooks than WordPress (his goal was to show that BuddyPress is easy to extend, but it could be interpreted as WordPress not being so easy to extend. The core team is not very proactive to add hooks even when required by several plugins developpers). So if we can convince the core team to add some hooks, then it’s a good idea!

Is the goal to ease multilingual support by 3rd party themes and plugins? That would be good even if WPML, as market leader, has already established a de facto standard for most of the issues. However, the wpml-config.xml file is lacking validation / sanitization for options translations, so it needs to be improved.

About the proposals:

1) I don’t catch what would be the benefits and in my opinion, there are several risks if the core provides a way to assign a language to posts and terms:
* That’s useless for plugins using multisite approach so not really a risk
* That’s redundant for plugins using the single site / multiple posts approach (unless the plugin is already using the core way to assign the language)
* That’s conflicting with plugins using the single site / single post approach (qTranslate like)

2) That’s a good idea for me but I believe that it will benefit only to plugins using the single site / multiple posts approach (except for user meta which would benefit to multisite approach too).

3) That’s already feasible.