Content translation/CX3

Content Translation version 3 or CX3 is a fresh version of Content translation tool. This version will be implemented using Vue.js. Better mobile support and Section Translation (SX) will be major new features.

Technology
CX3 uses Vue.js as the JavaScript framework. A new UI library developed using Vue.js and as per Wikimedia Style Guidelines will be used as the foundation. CX3 is a Single Page Application (SPA) built using vue-cli. The assets built are then served as a ResourceLoader module. For a user, the Special:ContentTranslation page will act as an SPA. The application is designed and developed as mobile-first application.


 * Vue.js 2.x is used as base JavaScript framework
 * Vuex 3.x is used as Vue Store
 * Vue CLI 4.x is used as the build tool
 * Banana-i18n is used as i18n framework with vue binding. This makes the application less MediaWiki dependent and jQuery independent.
 * Visual Editor is used as section editor

The application is primarily targeted mobile devices running Modern (grade A) browsers.

Setup
Check out content translation code and install documented in the Extension:ContentTranslation page. Content translation need the cxserver running and configured. Enable the CX3 using the configuration: $wgContentTranslationVueDashboard=true;

Development
In the source code of Content translation extension, go to app folder and install dependencies Start the development server which gives features like hot module reloading, access to Vue dev tools. To test the application, run: To build the assets for production, run The application comes with a UI library and illustrated using a storybook. The current storybook is available here. To run storybook locally, run

Why Vue is used for this application
This application, by its purpose and design is a single page application with about a dozen of steps from starting a translation and publishing it. Since translation is an activity that require lot of context, loading pages between each of this steps is a bad experience, hence the workflow should be smooth inside a single page like a shopping cart application. Vue is often used in these contexts because of its SPA capabilities using vue-router based routing.

Secondly, the application need to be mobile first application and should be responsive to different screensizes. Current MW frameworks are limited to achieve this. So, thinking about long term path of Content translation, we wanted to start building responsive, modern web application that boost developer productivity. Since Vue is chosen as the framework for MediaWiki's frontend, we decided to start using it.

The developer productivity tools like Hot Module Replacement helps developers to quickly develop the system, that otherwise require countless navigation through the workflow to inspect some changes in UI.

This application has less risk to use a new framework like Vue because it is not exposed to the large set of users, confined to a special page and disabled in large wikis by default.

Why does this application look so different from typical MediaWiki page?
Content translation, ever since its first version, tried to use maximum screenspace available for translation. Translation require presenting articles in two languages and often involve relatively large set of tools. In desktop, we avoided sidebar in Content Translation. Here, in section translation, we use the same approach. The whole application is a MediaWiki Special page, but uses a custom skin, named contenttranslation. It is a hidden skin, so it is not available as a skin option. It is conditionally activated only for Special:ContentTranslation page. This skin does not load usual code like OOUI because the whole interface is managed by Vue

Why are you using custom i18n system?
This application uses vue-banana-i18n, a vue binding for banana-i18n system. banana-i18n is MediaWiki independent vanilla javascript port of our localization system. This decision was intentional to open up a path for a standalone translation app in future, to make sure that i18n is integrated with a default vue development workflow involving hot module replacement. The RTL support does not use the Resource Loader's CSS Janus system, but uses a style library with CSS helper classes supporting RTL. These experiments also provides an opportunity for experimentation and innovation with low risk factors in this fields

Why are you not using OOUI?
OOUI follows different paradigm for UI component library that Vue's declarative, reactive system. So section translation developed its own UI library following the design guidelines of Wikimedia.

Why are you using Webpack for building assets?
The vue-cli tool we use for transpiling and bundling the system, internally uses webpack. Webpack is a large ecosystem of several npm modules which are potentially non-secure. We started this application with vue-cli which is default bundling tool for Vue projects. There are discussions going to find a better bundling tool for Wikipedia's Vue projects. We will switch to that bundling tool when that decision is made.

Why are you not using coding conventions of MediaWiki?
We wanted our projects friendly for contributing by volunteers and our own staff engineers. MediaWiki coding styles are very uniquer and limited to MediaWiki. We wanted to use a widely accepted and used coding style to attract mode volunteers. We wanted to avoid writing and maintaining those styles and linting rules so that we can focus on project development. We use Vue recommended styles and linting rules, default formatting coming with formatting tools.

How can I try this tool?
You may go to https://sx.wmflabs.org, create an account, use the links given its main page to use the tool. It is recommended to use a mobile device or use narrow screen space in browsers.

Why it is called SX?
SX is short form we use for "Section Translation" similar to CX for Content Translation. CT was not used because that acronym was already taken for Category Tree extension.