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 is Vue used for this application?
This application, by its purpose and design is a single-page application (SPA) with about a dozen of steps from starting a translation to publishing it. Since translation is an activity that requires a lot of context, loading pages between each of these 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 routing based on vue-router.

Secondly, the application need to be mobile first application and should be responsive to different screen sizes. The capability of the current MediaWiki frameworks to do this is limited. So, thinking about the long-term path of Content translation, we wanted to start building a responsive, modern web application that boosts 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 screen space available for translation. Translation requires presenting articles in two languages and often involves a relatively large set of tools. In desktop, we avoided MediaWiki's default Vector sidebar in Content translation because the links on it are usually not needed during during translation. Here, in Section translation, we use the same approach. The whole application is a MediaWiki Special page, but it uses a custom skin, named contenttranslation. It is a single-purpose skin, so it is not available as a skin option in preferences. 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 (Content Translation also uses Visual Editor as a component, and it may load OOUI.)

Why are you using a custom i18n system?
This application uses vue-banana-i18n, a vue binding the 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 CSSJanus system, but a style library with CSS helper classes supporting RTL. These experiments also provide an opportunity for experimentation and innovation with low risk factors in these fields.

Why are you not using OOUI?
OOUI follows a different paradigm for UI component library than 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 the default bundling tool for Vue projects. There are ongoing discussions 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 MediaWiki coding conventions?
We wanted our projects to be friendly for contributing by volunteers and our own staff engineers. The MediaWiki coding conventions are unique 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 and 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 for Content translation because that acronym was already taken for the Category Tree extension.