727084 - [SUMO KPI dashboard] display L10n coverage number

Status: RESOLVED FIXED

(support.mozilla.org :: General, defect, P1)

Description

[Kadir Topal [:atopal]]

The definition of this is tbd.

Comment 1

[Ricky Rosario [:rrosario, :r1cky]]

It is hard to estimate this without a definition. I am assuming it has to do with the number of documents that are ready for l10n that don't have an up to date translation yet. But I have a feeling you will mix in traffic data, which will make it more complicated.

Until we have a definition, *for planning purposes only* I am making it a 2pter like most of the new metrics we have added to the dashboard.

Comment 2

[:ibai]

As you say, we want to weight the amount of translations by locale traffic;

The algorithm of the definition is:

-----
SUMO visits = Total non-en-US SUMO visits for the last 3 months from WebTrends;
Total translated = 0;

For each locale different to en-US {
Total translated = Total Translated + ((Number of updated articles from the English top 50 most visited articles)/50 ) * (Visitors for that locale / SUMO visits));
}
------

There's no need to calculate the visits and the list of articles that we evaluate more than once a quarter if that simplifies the code.

Comment 3

[Ricky Rosario [:rrosario, :r1cky]]

(In reply to Ibai from comment #2)
> Total non-en-US SUMO visits for the last 3 months from WebTrends;
> Visitors for that locale

Do we have reports setup for that in Webtrends? That is a prerequisite for any of this to happen.

Comment 4

[:ibai]

Does this work?

https://analytics.webtrends.com/analytics/spaces/6356/profiles/11794/reports/FRnJo3T7MM6?dateShortcut=91d

Comment 5

[Ricky Rosario [:rrosario, :r1cky]]

(In reply to Ibai from comment #4)
> Does this work?

Looks promising. But we'll have to figure out how to deal with the mix of .com and .org data there.

> Total translated = Total Translated + ((Number of updated articles from the
> English top 50 most visited articles)/50 ) * (Visitors for that locale /
> SUMO visits));

I am missing something here. I don't see where number of translations comes into play? You are probably implying something in "Number of updated articles from the
English top 50 most visited articles"? This part needs better definition. I am assuming it has to do with newer revisions that are ready for localization but aren't translated yet. But it does get tricky when that revision is no longer the current one, but the current one isn't ready for localization yet.

Comment 6

[Ricky Rosario [:rrosario, :r1cky]]

To clarify, here is an example of what I was trying to describe.

en-US:
revision #1 - ready for localization
revision #2 - ready for localization
revision #3 - current revision, no ready for localization

es:
current revision is based on revision #1 above

This is out of date. But if es current revision was based on revision #2 then it is up to date.

So we need an algorithm that accounts for stuff like this.

Comment 7

[:ibai]

Isn't this implemented for the UI? The localization dashboard already has a differentiation between updated and localized (translated but not updated).

Can we reuse that logic?

Comment 8

[Ricky Rosario [:rrosario, :r1cky]]

Yeah, we can probably look at how it is done there. I just wanted clarification on what we are trying to measure. If you look at https://support.mozilla.org/es/localization, for example.

There are lists for articles that:
1- need translations
2- need immediate updates
3- need updates

Are we grouping all those together as out of date?

Comment 9

[:ibai]

That's correct.

The idea is to get fresh translations. We need to push ourselves into that direction.

Comment 10

[Ricky Rosario [:rrosario, :r1cky]]

Landed on prod:

https://github.com/mozilla/kitsune/commit/4f21e8410773baed49e53122f9469190de19dd16