This RfC is proposed to be discussed on October 15. https://www.mediawiki.org/wiki/Architecture_committee/2014-10-01

At the moment I am working on implementing basic LanguageConverter support (parsing the syntactic constructs) in Parsoid. When that framework is in place I'll be better able to propose an implementation of the glossary system.

I'm adding this to the list of proposals to consider, per the very long conversation @cscott and I had on the #wikimedia-tech IRC channel today. That conversation led him to post a proposal to meta "The future of Language Variant support ". Here's what he wrote as the summary of what needs to be decided:

There are two main proposals.

• One involves attempting to allow Visual Editor to edit text in the user's preferred variant. This involves changes to LanguageConverter to create structured "Glossaries" (as described in the RFC). The ultimate editing process would still be error-prone, as users would have to be fluent in both variants to ensure they did not accidentally create dirty diffs or errors when editing.
• The other proposal involves improving the ContentTranslation tool and interwiki synchronization so that it would be possible to fully separate the content in the different variants and use ContentTranslation to semi-automatically convert edits from one variant to another. The existing LanguageConverter code would migrate to ContentTranslation, to allow it to perform automatically conversions between variants at least as well as the current LanguageConverter does.

I'm going to propose that we try to resolve this debate prior to Wikimedia-Developer-Summit-2016, but if we don't have it figured out, use Wikimedia-Developer-Summit-2016 as an opportunity to at least establish clear technical consensus one way or the other.

I think one of the sources of confusion and useless debate is that "language variants", the term, is used to cover a different set of issues as if they are all instances of the same problem which can be solved with a uniform solution. I think for some scenarios CX is indeed a very good solution, and for others, for non-technical / political reasons, the resulting split in wikis might be considered problematic. In other scenarios, there may be non-technical reasons why, even if imperfect and difficult, lang. variants in the sense of multiple lang-scripts on the same wiki, might be preferred. Some decisions are purely technical, and some are not, and perhaps part of the discussion ought to be to identify the lang pairs and which of those pairs are amenable to what kinds of purely technical decisions, and which need more non-technical resolutions.

I think we should not confuse the "separate domain names for wikis" issue with the issue of language variant support. There are political reasons for different languages/variants to remain "separate". But (for example) improving CX to better handle synchronizations between closely-related languages/variants would help even (say) als.wikipedia.org and de.wikipedia.org even if they maintain separate identities. It would also help users of simplified and traditional Chinese, even if they both lay claim to zh.wikipedia.org. Implemented well, it could even ensure that American and British Wikipedians don't unnecessarily step on each other's toes.

Fundamentally the LC approach is "a single document with multiple variants commingled" and the CX approach is "separate documents for each variant". Nothing should be inferred about whether this distinction is visible to users, we're just talking about what the database entries look like. We'll keep the politics at arm's length, beside simply acknowledging that not every wiki which *could* share edits from another wiki will *want* to do so.

Congratulations! This is one of the 52 proposals that made it through the first deadline of the Wikimedia-Developer-Summit-2016 selection process. Please pay attention to the next one: > By 6 Nov 2015, all Summit proposals must have active discussions and a Summit plan documented in the description. Proposals not reaching this critical mass can continue at their own path out of the Summit.

Wikimedia Developer Summit 2016 ended two weeks ago. This task is still open. If the session in this task took place, please make sure 1) that the session Etherpad notes are linked from this task, 2) that followup tasks for any actions identified have been created and linked from this task, 3) to change the status of this task to "resolved". If this session did not take place, change the task status to "declined". If this task itself has become a well-defined action which is not finished yet, drag and drop this task into the "Work continues after Summit" column on the project workboard. Thank you for your help!

@Nikerabbit is this something the Language-Team should track?

In T484#9341053, @MSantos wrote:

Is this something the Language-Team should track?

Language Team don't maintain language converter.

per mw:Maintainers.