Page MenuHomePhabricator

Language: Proper support for languages and variants in MW and its APIs (Action and REST)
Closed, DeclinedPublic

Description

Session title

Language: Proper support for languages and variants in MW and its APIs (Action and REST)

Main topic

none

Type of activity

Unconference session

Description



=== 1. The problem ===

Originally, the problem was stated as //How do we support language variants in the REST API?// There are plenty of W(P/M) projects that have decided using language variants to accommodate the needs of their communities, the Chinese WP being the most known example. Specifically, on that wiki, one can decide to read the content in traditional or simplified Chinese. This is achieved by tweaking the path to the desired article: `/wiki/` vs `/zh-{variant}/`. Alas, this is currently not possible in the REST API, which has some unfortunate repercussions, such as not being able to use the native Android app for `zhwiki` (to name just one).

During the discussion of this question, it became apparent that other language-related issues need disentanglement as well:

- Do we need to separate the interface language from the content language, i.e. distinguish between them, and if so to what degree?
- How to chose the language (/variant) for logged-out users?
- How many commonalities are there between multi-language and multi-variant wikis? Is the intersection large enough so that a shared solution is possible?

From a technical standpoint, MW tackles this problem by always consulting the `wgUserLang` variable internally to decide on the actual languages and variants to render the content in. However, this is not an ideal solution today because //(a)// it is a MW-specific, user-centric functionality that is hidden from external, stateless services; and //(b)// it makes it impossible to reference, i.e. provide a URI for, a specific render of a page (a corollary of this is that it is not possible to cache such content, nor is it possible for search engines to index it).

=== 2. Expected outcome ===

* Have a clear API / URI layout that will account for all language specificities
* A roadmap showing the effort involved and a (tentative) implementation ETA

=== 3. Current status of the discussion ===

Languages and language variants have been the subject of two Architecture committee meetings, but as the problem grew in scope no decisions have been made.

=== 4. Related ===

- The two original RfC's and their respective meeting minutes
# {T122942} - E168
# {T114662} - E384
- Current Parsoid status
# {T43716}
# [Language conversion blocks](https://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec/Language_conversion_blocks) on mediawiki.org
- Related unconference session: {T149419}

== Proposed by ==
@mobrovac

== Preferred group size ==
15-20

== Any supplies that you would need to run the session ==
A whiteboard and some markers should do it

== Interested attendees (sign up below) ==

# @mobrovac
# @ssastry
# @bearND
# @niedzielski
# @Mholloway

Event Timeline

Do we need to separate the interface language from the content language, i.e. distinguish between them, and if so to what degree?

I don't think we should be concerned about interface language at the level of Parsoid and MCS. That's a client concern IMO.

How to choose the language (/variant) for logged-out users?

Interesting question. I would say this fits right into T149419, and whatever is the decision there should work for us. In other words, outside of scope for us here to decide IMO.

To the facilitator of this session: We have updated the unconference page with more instructions and faqs. Please review it in detail before the summit: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Unconference. If there are any questions or confusions, please ask! If your session gets a spot on the schedule, we would like you to read the session guidelines in detail: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Session_Guidelines. We would also then expect you to recruit Note-taker(s) 2(min) and 3 (max), Remote Moderator, and Advocate (optional) on the spot before the beginning of your session. Instructions about each role player's task are outlined in the guidelines. The physical version of the role cards will be available in all the session rooms! See you at the summit! :)

The session didn't take place, so declining the task.