If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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



8 years ago
5 years ago


(Reporter: Seth Bindernagel, Unassigned)


Firefox Tracking Flags

(Not tracked)




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


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

8 years ago
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

8 years ago
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

8 years ago
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

8 years ago
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

8 years ago
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

8 years ago
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

8 years ago
Sub-view seems like a great solution.

Comment 8

8 years ago
Priority: -- → P2
Summary: [dashboard][shipping] Compare-locales view should list string value → [dashboard][l10nstats] add l10n-merge view, linked from compare-locales view


7 years ago
Component: Infrastructure → Elmo
Product: Mozilla Localizations → Webtools
QA Contact: infrastructure → elmo
Summary: [dashboard][l10nstats] add l10n-merge view, linked from compare-locales view → [l10nstats] add l10n-merge view, linked from compare-locales view
Version: unspecified → 1.0


7 years ago
Severity: normal → enhancement
Priority: P2 → P3
Target Milestone: --- → 1.3
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.


5 years ago
Target Milestone: 1.3 → ---

Comment 10

5 years ago
I'm marking this WONTFIX, we lived without this for three years.
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.