561488 - [l10nstats] add l10n-merge view, linked from compare-locales view

Status: RESOLVED WONTFIX

(Webtools Graveyard :: Elmo, enhancement, P3)

Description

[Seth Bindernagel]

Presently on the dashboard/shipping app, the compare-locales view only shows the list of missing entity names.  For example, check the following URL:

https://l10n-stage-sj.mozilla.org/dashboard/compare?run=40004

The list here could show both the entity name and string value.

A localizer who uses a tool like Narro to translate cannot search on the entity name to find an untranslated string.  But, if the string value were provided, the localizer could use that value to search in Narro.  Since many complete translations often leave several untranslated strings, finding the strings in Narro that need translation can be difficult in the long list of acceptable, untranslated strings.

Comment 1

[Axel Hecht [:Pike]]

Is there a ticket on narro to fix that on their side?

I agree that we should link to the sources, but showing all values would make that view pretty cluttered, I think.

I'm also not sure if leaving untranslated strings in narro is a good practice. If people want special markup for that, narro should support a flag "not gonna translate any time soon, or maybe never" or something.

Comment 2

[Seth Bindernagel]

I think the bug comment uses Narro as an example to illustrate the use case.  But, what about other tools?  Searching on the value of the entity would probably serve localizers who don't use Narro.

Comment 3

[Axel Hecht [:Pike]]

Technical comment, this is not just about whether or not to show the values.

Our current data doesn't have the values, so actually getting the values is a good chunk of implementation work, and possibly server load.

Comment 4

[Axel Hecht [:Pike]]

I'm wondering if a "l10n-merge" view per file would solve most use-case efficiently.

I'm thinking about a view-source of the l10n file with inserted en-US values (and possibly strike-throughs for obsolete and error?), with only one l10n entity before and after to denote context. Not exactly sure how to spec removal and insertions, and in particular if change-detection is required. Neither on whether we'd show l10n in the revision it was in, or in current default head.

This will require some hefty changes on the compare-locales json data, still, plus backwards compat code.

Comment 5

[Seth Bindernagel]

I like this idea.  

View-source of the l10n file still doesn't solve the problem of clutter you bring up in comment #1.  That does seem to be an issue to consider.  Provided the changes tot he compare-locales json data is accomplished, can you add some AJAX to the site which might allow expanding/collapsing an entity name to show the value?

Comment 6

[Axel Hecht [:Pike]]

I was thinking about a sub-view linked off of the file.

The clutter would be less as it'd be only per-file, and not per app, so you don't have the path navigation elements in that view. And it would distribute the load a bit over multiple requests.

Comment 7

[Seth Bindernagel]

Sub-view seems like a great solution.

Comment 8

[Axel Hecht [:Pike]]

Re-summarizing.

Comment 9

[Staś Małolepszy :stas]

This might be a sub-view (as comment 6 suggests), or a feature request in compare-locales, which would be a follow-up bug against c-l.

Comment 10

[Axel Hecht [:Pike]]

I'm marking this WONTFIX, we lived without this for three years.