Roadmap for the post and term locales proposal

Here’s what I feel we need to do to investigate the proposal to add locales to posts and terms, and to test whether this is feasible and desirable.

Write a proof of concept plugin which:

  • Implements a new column in wp_posts and wp_terms
  • Implements an enhancement to WP_Query

Then test this against some existing multilingual and non-multilingual plugins, looking for:

  • Performance
  • Any bugs or unexpected behaviours introduced

I also think it would be good to look at how locale information for posts and terms might be exposed via the proposed WordPress REST API endpoints (I knowledge or preconceptions here).

I’m happy to have help on this journey.

The next multilingual WordPress weekly…

The next multilingual WordPress weekly chat is on Monday 30 November at 17:00 GMT

We’ll be talking about:

We’ve got leaders for the above topics/proposals, and we need help in the following areas:

  • Developers to build, review, and discuss implementations of these ideas
  • Others with an active interest to help understand the shape and size of the community in terms of statistics and usage

We’re not discussing or critiquing existing multilanguage and translation plugins… instead we’re talking about how WordPress core can make life easier for the developers (plugin developers, theme developers, site developers) and users of WordPress sites using multiple languages.

See you there! 🙂

Current status: need help :)

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​ 😦

So:

  • 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 🙂

#core-channel, #core-multilingual

Defining a post or term language

I’m going to try to set this out in stages, so people can take issue with each or any particular stage. 🙂

WordPress provides no way to define a locale for posts and terms. This means that plugin authors must define one, which adds complexity to all content queries during the actions and filters run for each request, and may also add complexity to the data structures. The lack of a built-in API for locale definition additionally complicates saving content, though that is significantly less impactful that the content retrieval issues.

Examples:

  • WPML stores locale in an additional table, and this table is joined to allow retrieval of the content in the correct language
  • Polylang uses a taxonomy to store locale, and this taxonomy is referenced in queries for the content
  • Babble uses a parallel post type or taxonomy for each language, which complicates the data structure

Each of the above solutions is further unique to that particular plugin, which means that any other plugin author, theme author, or developer, who wants to act on content of a given type is presented with a complications specific to each; what language is the post in, what post type represents the language for this post, etc.

In broad outline, I propose:

  • WordPress core provides an API to allow a locale to be defined for a post or term, the locale should default to “unspecified”, and data structure(s) to store this
  • WordPress provides an API to allow content queries, for posts and terms, to request content with a specific locale

Currently I envisage the implementation as:

  • wp_insert_post and related functions accept a parameter to allow a locale to be defined for a post or term, the locale should default to “no locale”
  • The locale designation is stored in an additional column in wp_posts and wp_terms respectively
  • wp_query allows an additional parameter to specify content from a particular locale

One thing which has occurred to me: If some content gets assigned a locale, but other content does not, (e.g. if a multi-locale aware plugin has been active and is not inactive) what content should be retrieved? It’s possible the desired behaviour for a content query on a site which has no interest in multiple locales is different to that of a site which is aware of multiple locales.

Core Multilingual Support chat notes,…

Core Multilingual Support chat notes, Monday 27 July 2015

Chat transcript starts at 16:07pm UTC. Discussion centred around Proposal 1 (locales for terms and posts), and Proposal 2 (make it easier to translate widgets, user meta, and options).

Adding locales to posts and terms (proposal 1)

@simonwheatley would like to define what would make the proposal worth doing, so we can hold ourselves to account on that. Possibly some experiments to assess the changes in types, efficiency, and quantities of queries if this API and data structure was available.

Relating post translations is considered out of scope for this proposal, as taxonomies already provide a way to associate posts, and, further down the Taxonomy Roadmap we will have other methods for relating posts to each other.

Make it easier to translate widgets, user meta, and options (proposal 2)

We discussed a possible extension of this idea to provide an API and data structure for storage of translations, but we decided this would add too much complexity. @sciamannikoo is considering an implementation which basically uses a gettext-like filter, where we pass the string, and some data to contextualize that string. Perhaps something like apply_filters('some_handle_I_cant_think_of', $string, $context);.

We will need to include strong arguments with both proposals which cover how we are making things better, how the proposed changes will not break existing sites, and how the proposals make things possible or easier where previously they were impossible or difficult.

Both the proposals discussed will aim to add some notes and intentions on this site.

@MarkoHeijnen offered apologies that he’d not had time to look into things.

Any feedback or discussion on these notes is more than welcome! Please just add a comment. 😀

Notes from WordPress Multilingual Meeting…

Notes from WordPress Multilingual Meeting Monday 20 July 2015

We had people working on the following multilingual plugins in the discussion: Multilingual Press, WPML, and Babble. Any other multilingual plugin authors are more than welcome to join us, and help shape any solutions we propose so they will work for the community.

We discussed and agreed to work on three proposals:

  1. Mark a post or term as in a particular locale – @simonwheatley leading
  2. Make it easier to translate strings stored in settings and user meta – Andrea Sciamanna leading
  3. Allow plugins to translate taxonomy names and slugs – Marko Heijnen leading

Each person leading one of the proposals will need help, so if you have time and want to help please let us know in the comments below.

Each proposal team will let us know next week how they plan to work on their proposal (public repository for a proposed feature plugin, patch on core trac, etc).

Next meeting is Monday 27th July, 16:00 UTC, in the WordPress core Slack channel.

Slack archive

#meeting-notes

We held a multilingual discussion…

We held a multilingual discussion at #WCEU, and you can read the notes are on make/core.