Read our initial intentions post
As I said in the WordPress Core slack channel: We’ve lost @markoheijnen‘s involvement I think permanently, and @sciamannikoo is taken up with work issues so not able to give time (currently) to the proposal on translating data stored in options, similarly I’ve not had the time to devote to the post/term locale project although I still intend to 😦
- We’re looking for more people to get involved
- We’re taking a break this week and next, back Monday 26 October, although we’ll pop in on the intervening Mondays not for a full chat but to keep the cadence and see if anyone is around who wants to join in
…ping me or @jennybcappaert if you’re interested in helping out, please 🙂
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 w.com 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.