834317 - Localization Dashboard

Status: RESOLVED FIXED

(developer.mozilla.org Graveyard :: Localization, enhancement)

Description

[John Karahalis [:openjck]]

In Austin, we discussed deciding on a mockup of the Localization Dashboard before we go ahead with implementation. Like the revision dashboard, this should happen before we get started on actual implementation.

Comment 1

[Eric Shepherd [:sheppy]]

Jean-Yves, any thoughts on who all should be involved in getting this dash designed? Presumably we should talk to Jeremie and Florian at least.

Comment 2

[John Karahalis [:openjck]]

Hey Sheppy. We were hoping to get a mockup done before Wednesday. Even if we can't get others to join the discussion, maybe you and David could collaborate on one?

Comment 3

[Florian Scholz (Open Web Docs)]

I might have some time to get into this. Not so familiar with Balsamiq Mockups, but I'll see. 
Also, ages ago (in deep MindTouch time), I was pulling some data using the MT API and baked this: http://mdc.elchi3.de/ Terribly outdated but some first ideas in there ...

Comment 4

[Florian Scholz (Open Web Docs)]

Attachment: Mockup xml file

Comment 5

[Florian Scholz (Open Web Docs)]

Attachment: Draft mockup as a png

Comment 6

[Florian Scholz (Open Web Docs)]

First draft to get this started. Feedback welcome ;-)

Comment 7

[Eric Shepherd [:sheppy]]

We need to keep in mind that we need a way to mark that translation work is complete for a given revision, and do we want to add a "translation review" flag, where someone that's finished translation can ask for someone to review it?

Comment 8

[John Karahalis [:openjck]]

Filling out a more detailed specification for this feature based on our discussions in Austin. Florian, Jean-Yves: Please let me know if any of this is wrong.

What problems would this solve?
===============================
The localization dashboard should increase localization activity and provide an overview of progress.

Who would use this?
===================
Anyone interested in contributing to or watching the status of localization.

What would users see?
=====================
The localization dashboard should look and behave similar to the revision dashboard. The dashboard will list content that is no longer up-to-date with the original versions. The sorting of the entries has yet to be determined -- maybe alphabetical, or most visited, or most important. The dashboard should provide filters similar to those on the revision dashboard.

What would users do? What would happen as a result?
===================================================
A localizer will use this dashboard as a starting point. After reading through the dashboard, he will click on an article that he wants to work on. Doing so will open the article in the side-by-side localization view (TBD: how do we know /which/ language the localizer will be translating into?). A localizer will also be able to change what appears on the dashboard by using the filters.

Is there anything else we should know?
======================================

Comment 9

[John Karahalis [:openjck]]

Some input for the design phase, based on what we discussed in Austin.

* We should take a look at the dashboard being used on SUMO as a guide for
  building our own dashboards.
* We should also take a look at the "Unanswered Questions" dashboard being
  used on SUMO. It is solving the same problem -- finding remaining work
  and encouraging people to do that work.
  https://support.mozilla.org/en-US/questions?filter=no-replies
* We probably want some actual localizers to approve the ultimate design before
  we sign off on it.

Comment 10

[Jean-Yves Perrier [:teoli]]

(In reply to John Karahalis [:openjck] from comment #8)
> What problems would this solve?
> ===============================
> The localization dashboard should increase localization activity and provide
> an overview of progress.
More than the progress, the localization dashboard should display the work to be done for a given locale and for a subdirectory of our hierarchy.

Work to be done being: 
- pages to be translated (== pages without translation)
- pages to update (== pages with a translation than the last en translation)

(I don't like this en reference, but I can live with it for a start or until we have a better idea implemented)

The progress is nice to have, but secondary.

> What would users see?
> =====================
> The localization dashboard should look and behave similar to the revision
> dashboard. 
Not necessary. That isn't a requirement. I may be fine with it to get it quicker, but I don't think it must be so. 


>The dashboard will list content that is no longer up-to-date with
> the original versions. The sorting of the entries has yet to be determined
> -- maybe alphabetical, or most visited, or most important. 

Yes, this is important. The sorting should be changeable by the user: some users are working in a chronological order (or antichronological order) of the oldest change, some are working alphabetically and some may wanted to update most visited first.

I'm perfectly fine with a first version with chronological and alphabetical order only. (Important ones seems more complex to do as we have to set up this value in some way).

There is a second list: the list of non-translated page, ordered by chonological or alphabetical order. 

I think both lists should be separate.

> The dashboard
> should provide filters similar to those on the revision dashboard.
Yes. Per user and per name (filtering on CSS for example)


> What would users do? What would happen as a result?
> ===================================================
> (TBD:
> how do we know /which/ language the localizer will be translating into?).
We should always filter for a given language. There is no point in having a common fr+en l10n dashboard, so defining the language to translate into is trivial.

Like with all dashboards, I like to have several small iterations. It is difficult to think about missing elements out of the box.

Comment 11

[John Karahalis [:openjck]]

To anyone working on design here, the "Revision Dashboard" we are referring to is here:

https://developer.mozilla.org/dashboards/revisions

Comment 12

[John Karahalis [:openjck]]

I would love to help design a mockup, but I'm stretched a little thin at the moment. Would anyone (Florian?) be up for updating the mockup based on comment 7, comment 8, comment 9, and comment 10?

Comment 13

[Axel Hecht [:Pike]]

I'm wondering, why are we doing a separate l10n dashboard logic for mdn compared to sumo?

Having that being shared infrastructure should (hopefully) be easier to code, and it'd create synergies in the l10n communities in understanding the workflows of which documents to work on.

Comment 14

[John Karahalis [:openjck]]

(In reply to Axel Hecht [:Pike] from comment #13)
> I'm wondering, why are we doing a separate l10n dashboard logic for mdn
> compared to sumo?
> 
> Having that being shared infrastructure should (hopefully) be easier to
> code, and it'd create synergies in the l10n communities in understanding the
> workflows of which documents to work on.

I have to say, I really agree with this. It may only meet 80% of our needs, but it would cost us 20% of the work. Besides, consistency is huge.

Comment 15

[John Karahalis [:openjck]]

So the next step on this -- Sheppy and Jean-Yves, what do you think about comment 13?

Comment 16

[Jean-Yves Perrier [:teoli]]

I don't know what Sumo does. But if it fulfill the requirements (filtering by theme + list of pages to update + list of pages to translate), I have nothing about reusing code.

Comment 17

[John Karahalis [:openjck]]

Dev team: Any thoughts on reusing the Kitsune localization dashboard?

Comment 18

[Les Orchard [:lorchard]]

(In reply to John Karahalis [:openjck] from comment #17)
> Dev team: Any thoughts on reusing the Kitsune localization dashboard?

My main thought is: Sure, let's check it out. But, a silver bullet or that it necessarily even works. We started from kitsune code, but imported from over 2 years ago. We've both diverged since then. We could get lucky, or it could turn out that starting fresh is quicker.

(In reply to Axel Hecht [:Pike] from comment #13)
> I'm wondering, why are we doing a separate l10n dashboard logic for mdn
> compared to sumo?
> 
> Having that being shared infrastructure should (hopefully) be easier to
> code, and it'd create synergies in the l10n communities in understanding the
> workflows of which documents to work on.

It sounds like you're hoping MDN and SUMO would share the same dashboard, not just the same code. That's even less likely to be feasible.

If we do want some kind of l10n dashboard shared between sites like MDN and SUMO with dynamic content, that's a project in itself (ala verbatim)

Comment 19

[Les Orchard [:lorchard]]

(In reply to Les Orchard [:lorchard] from comment #18)

> But, a silver bullet or that it necessarily even works.

(ahem.) But, it's *unlikely that it would be* a silver bullet or that it necessarily even works for us.

Comment 20

[John Karahalis [:openjck]]

I am going to move this out of our "Design" phase for now, since more pressing redesign work is coming up. We can continue thinking about it, but I am going to not going to call it a priority for now, especially because we have limited design resources for this rather big project.

Comment 21

[Eric Shepherd [:sheppy]]

FWIW, we have opened up a Google Summer of Code project for this; with luck, we will get an awesome student to work on it!

Comment 22

[John Karahalis [:openjck]]

We need to get more detail on this feature as soon as possible. The eventual Google Summer of Code intern (and even those that are applying now) need this information.

The Google Summer of Code project involves building a Minimum Viable Product and iterating on that with as many improvements as time allows. As such, we need to publish a detailed requirements document and a large backlog of well-defined improvements to make on top of that MVP.

Please be as detailed as possible here. Assume that if we say nothing else, the final product will look like a pencil drawing and have a big yellow note next to it (see our earlier Balsamiq mockup). Assume if that if we say nothing else, the Dashboard will support no interactions at all, and the buttons will do nothing. I know it sounds crazy, but that is the mentality we need to get the proper level of detail here.

Some questions to get the discussion started (by no means exhaustive):

* Florian shared a mockup in comment 5. Is this mockup exactly what we want from
  a visual point of view? The same colors? The same spacing? The same copy?
  Again, assume that not answering is an implicit "yes".
* How exactly will users interact with the dashboard? What will they click? What
  will result from these actions? Does the order of user actions matter? Does the
  timing of user actions matter?
* Exactly how will the Dashboard work with our approval workflow? Sheppy refers to
  this in comment 7. Will there be a "translation reveiw" flag? Who will set it?
  What will happen when it is set? Who will unset it? Is this the only workflow
  feature we need?
* What features exactly do we want to borrow from SUMO? Will the features we borrow
  look and behave exactly the same way?
* Again, these are only starting questions. What else exactly is needed for the
  MVP? Exactly what other improvements do we want to build on top of this?

Within the next couple of weeks, I would like us to have a PSD and a very detailed description of behavior, among other assets. But again, this will not be possible until these questions are answered.

Comment 23

[John Karahalis [:openjck]]

Hey everyone. I am still on PTO, but wanted to pop in to make sure we push this forward.

I am still getting questions from interested contributors about detail. Do we still want to host this as a Google Summer of Code project? Unless we decide exactly how this feature should look and behave, we will not be able to.

David, do you think you could drive these discussions while I am out?

Comment 24

[John Karahalis]

It appears David is out on PTO as well. Moving over to Jean-Yves.

Jean-Yves, do you think you could drive these decisions while I am out?

Comment 25

[Jean-Yves Perrier [:teoli]]

Cleaning needinfo as it was done.

Comment 27

[[github robot]]

Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/747642b3b7be610662e278a62494be3c4ca7e32d
Bug 834317 - Localization Dashboard

https://github.com/mozilla/kuma/commit/b12a5746f4fc7e235e6bd689c87803237bfaf583
Merge pull request #1244 from berkerpeksag/l10n-dashboard

Bug 834317 - Localization Dashboard

Comment 28

[Eric Shepherd [:sheppy]]

I'm going to be honest here and say that looking at the dashboard, I'm not sure what if anything it actually does. :(

Comment 29

[Axel Hecht [:Pike]]

What's be a URL to look at?

Comment 30

[Luke Crouch [:groovecoder]]

https://developer.mozilla.org/dashboards/localization

Comment 31

[Tarashish Mishra [:sunu]]

The URL mentioned by Luke is giving me a "404 - Not Found". Has it been moved somewhere else?

Comment 32

[Luke Crouch [:groovecoder]]

It's only enabled for a subset of alpha testers, sorry. :(

It's still very rough and we're worried about the performance effect of too many users on the database.

Comment 33

[Florian Scholz (Open Web Docs)]

The dashboard is now enabled for MDN beta users (turn yourself into a beta user in your MDN profile)
https://developer.mozilla.org/dashboards/localization

There is now a wiki project page:
https://wiki.mozilla.org/MDN/Development/Localization_dashboard

We are also looking for some feedback on dev-mdc. Please test and let us know what you think!
https://groups.google.com/forum/#!topic/mozilla.dev.mdc/TNm7G-fXZwQ

Comment 35

[John Karahalis [:openjck]]

The Localization Dashboard bug is on production. We can open new bugs for specific improvements.