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.
- 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.
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:
In the source code of Content translation extension, go to app folder and install dependencies
cd app npm install
Start the development server which gives features like hot module reloading, access to Vue dev tools.
npm run serve
To test the application, run:
npm run test
To build the assets for production, run
npm run build
npm run storybook:serve
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?
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.