Page MenuHomePhabricator

RfC: Scoped language converter
Closed, InvalidPublic

Description

We need to decide on the Scoped language converter RfC.

Event Timeline

Qgil created this task.Sep 25 2014, 11:41 AM
Qgil raised the priority of this task from to Medium.
Qgil updated the task description. (Show Details)
Qgil added a project: Architecture.
Qgil changed Security from none to None.
Qgil moved this task from Inbox to Ready to Go on the Architecture board.
Qgil added a subscriber: Qgil.
Qgil added a comment.Oct 1 2014, 7:00 AM

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

Qgil edited projects, added TechCom-RFC; removed Architecture.Oct 22 2014, 8:45 PM
daniel assigned this task to cscott.Feb 27 2015, 3:15 PM
daniel added a subscriber: daniel.

TODOs according to https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-04-02

C. Scott to

  • (a) confirm consensus on replacing the existing template-based system with a "glossary" system.
  • (b) discuss how glossaries should interact with templates (page inclusions)
daniel moved this task from P1: Define to Old on the TechCom-RFC board.Feb 27 2015, 3:15 PM

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.

RobLa-WMF added a subscriber: RobLa-WMF.

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.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 18 2015, 9:06 PM

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.

Qgil added a comment.Oct 3 2015, 8:57 PM

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.

jmadler added a subscriber: jmadler.Jan 6 2016, 5:13 AM

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!

Aklapper removed cscott as the assignee of this task.Jun 19 2020, 4:27 PM
Aklapper edited subscribers, added: cscott; removed: RobLa-WMF.

This task has been assigned to the same task owner for more than two years. Resetting task assignee due to inactivity, to decrease task cookie-licking and to get a slightly more realistic overview of plans. Please feel free to assign this task to yourself again if you still realistically work or plan to work on this task - it would be welcome!

For tips how to manage individual work in Phabricator (noisy notifications, lists of task, etc.), see https://phabricator.wikimedia.org/T228575#6237124 for available options.
(For the records, two emails were sent to assignee addresses before resetting assignees. See T228575 for more info and for potential feedback. Thanks!)

Krinkle closed this task as Declined.Sep 16 2020, 7:32 PM
Krinkle added a subscriber: Krinkle.

Closing old RFC that is not yet on to our 2020 process and does not appear to have an active owner. Feel free to re-open with our template or file a new one when that changes.

Jdforrester-WMF changed the task status from Declined to Invalid.Sep 16 2020, 8:15 PM
Jdforrester-WMF added a subscriber: Jdforrester-WMF.

Not Declined.