Page MenuHomePhabricator

Reorganize the CX classes using OOjs/OOUI (tracker)
Closed, ResolvedPublic


As preparation for VE, and also as a consolidation of usecases that were patched up over last 2 years, we need to reorganize the classes in a better way.

It is better to do now before VE integration so that the tech debt does not carry forward.


  1. CX was developed iteratively for last 2+ years. During that time, features were added in several stage of product development. In the beginning of the project, there was a highlevel understanding of features but not the details. So the architecture was a flexible one where modules can be plugged and get this done. This worked very well for us and we were able to add features fast. But the approach caused code duplication, less organized hierarchy of similar usecases. So a consolidation and reorganization of these use cases is much needed.
  2. The general direction in which CX is moving is to align with the MediaWiki extension good practices which includes OOUI based standardised frontend. Also CX need much improved editing experience with the help of VE. OOjs and obviously VE follow object oriented architecture heavily. CX's plugin based and global hooks based architecture is ill suited to mix with them. So the above mentioned organization should follow OO architecture for the best match.
  3. The patched up CX code showed some shortcomings recently and we can solve it during this reorganization.

This excercise will be done in several iterations and the code in production wont switch to this new codebase till everything is in place.

Trying out
The new codebase will be available with version=2 param in URL.


Following coding, architecture concepts are followed

  1. Data manipulation, adaptation are done in DataModel classes and made independent of UI or contentedtiable elements. Changes in contenteditables are updated in datamodels whenever content changes.
  2. Definition of translation unit - Any translatable element which has correspondence in target language, automatically adaptable or manually translatable and editable are defined as TranslationUnit.
  3. Clean hierarchy of translation units
  4. The translation context is available in Translation Units and other classes by dependency injection. Avoiding the globals for context
  5. A translation unit can have zero or more translation tools which are tools shown in translation column.
  6. All translation units are wrapped in <section> tags
  7. Methods to be designed to help unit testing as much as possible
  8. OOUI widgets
  9. Object oriented code arrangement with the help of OOjs


  • Migrate The 3 column based UI frame to OOjs
  • Rewrite the translation source selector using OOjs widgets
  • Define a data model hierarchy - abstract the translation units
  • Source page loading
  • Rendering translatable sections in source column
  • Categories widget migration (
  • Placeholders for source sections
  • Section alignment on edits
  • Cache management for links, title pairs (New in this version. it did not exist properly in old code)
  • Success, error message integration
  • Data model and UI separation
  • Registries for tools and translation units
  • Automatic adaptation
    • Link adaptation
    • Reference adaptation
    • Image adaptation
    • Template adaptation
    • Gallery adaptation
    • Math extension adaptation
    • Poem adaptation
    • Category adaptation
  • Tool card management system
  • Tool cards
    • Link tool : A dummy tool exist, displays adapted target title
    • Dictionary tool - A card exist, appears on text selection. No api to fetch dictionary meaning.
    • Search tool - Tool is present, search is not present
    • Formatting tool- Tool is present, actions not implemented
    • Reference tool - Reference card shows adapted reference and a reference removal button works. TODO: adapt refererences that are templates
    • Template tool
    • Instructions tool
  • Template translation system
  • Progress bar widget using OOUI
  • Progress calculation integration
  • Abuse detection
  • Restoring a translation
  • Saving a translation
  • Publishing translation
    • Building the target page document from data models
    • Conflict checks
    • Cleaning up for clean wikitext
  • Translation linting
  • Separation of two codebases using URL switch
  • unit tests - Some tests exist, code is written to help easy unit testing.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Change 335753 had a related patch set uploaded (by Santhosh):
Add machine translation tool

Change 335436 merged by jenkins-bot:
Image translation unit: Adapt namespace

Change 335753 merged by jenkins-bot:
Add machine translation tool

Arrbee raised the priority of this task from Medium to High.Feb 21 2017, 6:50 AM

Change 340923 had a related patch set uploaded (by santhosh):
[mediawiki/extensions/ContentTranslation] Add OOjs UI based formatter tool

Change 340923 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation] Add OOjs UI based formatter tool

Change 341996 had a related patch set uploaded (by Santhosh):
[mediawiki/extensions/ContentTranslation] Infobar rewrite using OOjs UI

Change 341996 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation] Infobar rewrite using OOjs UI

Arrbee renamed this task from Reorganize the CX classes using OOJS to Reorganize the CX classes using OOJS (tracker).Apr 5 2017, 7:03 AM
Volker_E renamed this task from Reorganize the CX classes using OOJS (tracker) to Reorganize the CX classes using OOjs/OOUI (tracker).Jan 5 2018, 10:21 PM
Volker_E updated the task description. (Show Details)

Closing this since we have CX2 as the default editing surface and we have addressed all of the items in the ticket.