Translate.Next


(Adrian) #1

What’s Translate.Next, you ask?

Well, I’m going to tell you. Translate.Next is a big-scale project of reworking the translate application of Pontoon. It covers many aspects, from code quality and maintainability to design and user experience. We have recently decided to split that project into several steps.

1. Rewrite to a Single Page App

The very first step is a very technical one. The current technology stack isn’t well adapted to the things we do with the Translate app, and if it works, it is very hard to maintain and to evolve. We are thus going to rewrite the Translate app to more robust Web technologies, as a Single Page App (a client-side application, where most of the templating is done in your browser instead of in the server). We’re going to use React as our rendering framework, redux as our data management system, and many other tools that will make our code a lot more flexible and maintainable.

The goal for this first step is to not lose features, nor create new ones. When it’s ready, we’ll remove the current app and turn on the new one, and the change should be fairly transparent for users.

While this is certainly an unexciting step for users, as we won’t be fixing bugs or adding requested features, we firmly believe it will be a steping stone for a better future. Working on the Translate app will be much easier, lowering the barrier to contribution, enabling more people to help us achieve our goals and build a better Pontoon for everyone.

We’re also using the opportunity to make some architectural changes that will bring great things. For example, we’ll make sure that theming will be extra easy to do. We’ll also build it so that the interface will be fully localizable (heck, we might soon be able to translate Pontoon in Pontoon, how cool would that be? ).

2. Experiment with new features

The next step is to propose new ways of translating. We have crazy (and not so crazy) ideas for what the Translate app could look and feel like. I’ve even started making some prototypes that I’m going to show in a follow-up post.

The goal here is to explore how we could improve the translation process. We want to make it easier for users to contribute strings and to increase the quality of translations.

Some ideas we already have include:

  • creating a dedicated “review” page
  • implementing a sort of “branching” model (à la git) to make changes in a sandbox before sending them
  • adding conversations around strings and translations
  • creating an advanced Fluent editor

We intend to involve the community in this phase. We’ll be organizing gatherings where we’ll bring a proposal to a group of Pontoon users, and work with them on exploring that proposal. I expect the proposal will take the form of a prototype that will be easy to hack, so that we’ll be able to make iterative changes and test a lot of different things. We will also use this forum to present those ideas to you all, gather feedback and share our work in progress.

3. Make substantial changes to the Translate app

There are big changes users have been asking for for a long time now. Things that would require substantial architectural changes, that are quite difficult to implement with the current code. Once step 1 is done with, we will be able to much more easily do those changes.

Here I’m thinking about things like:

  • localizing Pontoon
  • enabling custom themes
  • activity stream / notifications
  • everything from step 2

This step is blocked on step 1, and thus is less defined at the moment. We have a list of features that users have been requesting, we’re keeping track of it and using it to drive our work in steps 1 and 2.


I hope this helps understand what I’m currently working on in the Pontoon team, and it clarifies what Translate.Next is. I’m very happy to answer any questions and to read any feedback you have about this!

Adrian


Pontoon API - MUC 2018
(Michal Stanke) #2

I like the idea of Translate.Next (or Pontoon.Next) very very much. I have to ask - is there any rough (quarters) roadmap for the changes to happen?


(Adrian) #3

Very roughly, step 1 is what I’m working on in Q1 and Q2. My goal is to have it near code completion by the end of Q2, but I suspect review and QA will take some time, so hopefully it will replace the current code by the end of Q3. Step 2 is going to take more time, especially because it involves a lot of design, prototyping, testing… But that work should be ongoing through all of 2018. Step 3 is blocked on step 1, so work there won’t start before the end of Q3 or Q4 in my opinion, but once it starts it should move fairly quickly.

Of course, all of that is subject to change depending on external requirements, shifting priorities… :smile:


(Adrian) #4

Quick update here: my schedule has taken some detours, and I’m approximately two months late. I’m aiming for the rewrite to React (phase 1) to be done by the end of Q3 (reviews included).

The very first step of this can be seen in the pull request: https://github.com/mozilla/pontoon/pull/989

It’s very technical for now, mostly architecture and tool choices, but anyone interested is very welcome to review and comment!