611641 - When translating an article, all available locales are shown as target locale

Status: RESOLVED FIXED

(support.mozilla.org :: Knowledge Base Software, task, P4)

Description

[Tobias (:Tobbi) Markus]

When translating an article, all available locales are shown instead of only showing those that don't yet have a translation into that locale. 

See https://master.support.mozilla.com/en-US/kb/Firefox%20crashes/locales as an example.

Whilst https://master.support.mozilla.com/en-US/kb/Firefox%20crashes was translated into the majority of all locales, the site above still shows all of them.

Comment 1

[James Socol [:jsocol, :james]]

David, Michael, Kadir:

Not sure what's best here. We could drop existing locales from the list, or (de-)emphasize them somehow, or...?

Comment 2

[David Tenser [:djst]]

One solution might be to un-link (and gray) the ones that are already localized, but then add a note saying exactly that. E.g.:

...
Dansk (da)
Deutsch (de) - Already translated
Ελληνικά (el)
Esperanto (eo)
Español (es) - Already translated
...

("Already translated" would be a link to that translated article, and those locales with that link would not be a link target -- e.g. "Deutsch (de)" would in this case be just gray, non-clickable text.)

Michael/Kadir: thoughts?

Comment 3

[James Socol [:jsocol, :james]]

"Already translated" is a bigger target than most of the locales themselves. Maybe we could style the links differently but still leave them links?

Comment 4

[Paul Craciunoiu [:paulc]]

Could color them differently, or add a * next to them and an explanation at the top/bottom. E.g. red=not translated yet. blue=translation exists.

Comment 5

[Scoobidiver (away)]

In reply to comment 3:
> Maybe we could style the links differently but still leave them links?
I tried to translate an english article in French with an existing french translation. Results: there is no reference to the existing title in French, translated content is in English but preview content is in French.
Example: https://support-stage.mozilla.com/fr/kb/Parental controls in English,
https://support-stage.mozilla.com/fr/kb/Contr%C3%B4les%20parentaux in French.

So if links are kept, en-US/kb/english-article/translate must be redirected to locale/kb/localized-article/edit

Comment 6

[Scoobidiver (away)]

> So if links are kept, en-US/kb/english-article/translate must be redirected to
> locale/kb/localized-article/edit
I filed bug 612874 for that.

Comment 7

[Safwan Rahman (:safwan)]

Attachment: Proposed Patch

Hope this Fix the issue

Comment 8

[vesper]

Commenting as per Safwan's request: the best way would be to show only the locales that are missing. This way we can assume that other locales are either localized already or not enabled.

Comment 9

[vesper]

Correction: after further discussion with Safwan, we agreed on two sections - one listing the missing locales (with links to the l10n panels), the other listing the existing locales with links to the localized versions.

Comment 10

[Ricky Rosario [:rrosario, :r1cky]]

Comment on attachment 8540393 [details] [review]
Proposed Patch

This is missing the section of translated locales as mentioned in the comment above.

Comment 11

[Safwan Rahman (:safwan)]

Comment on attachment 8540393 [details] [review]
Proposed Patch

Updated the Patch with "section of translated locales" as mentioned above.

Comment 12

[Safwan Rahman (:safwan)]

Attachment: The Patch should make the page like this

The Current Patch will make the page look like this. Vesper, can you please confirm if its Ok? Or need more improvement.

Comment 13

[vesper]

@Safwan: this looks great! I think you want to show "locale name + locale code" strings for both untranslated and translated sections.

Comment 14

[Ricky Rosario [:rrosario, :r1cky]]

Comment on attachment 8540393 [details] [review]
Proposed Patch

Landed on master:
https://github.com/mozilla/kitsune/commit/3380c8f675d68997c9116fb17179f0046d997beb

Comment 15

[Ricky Rosario [:rrosario, :r1cky]]

Assiging and adding sprint bits.

Comment 16

[Ricky Rosario [:rrosario, :r1cky]]

Deployed to prod now. Thank you Safwan!

Comment 17

[vesper]

Awesome work, Safwan! :)

Comment 18

[Tim [:pollti]]

I think this fix costs much time for localizers:
When I get an e-mail (article … is ready for l10) and want to update the German l10n:

1. I click on the link and am redirected to e.g. https://support.mozilla.org/en-US/kb/search-bar-add-change-manage-search-engines-firefox/locales.
2. I have to scroll down to the existing languages. When clicking on the link "Deutsch (de)" (=German), I am redirected to https://support.mozilla.org/de/kb/suchleiste-einfach-lieblingssuchmaschine-waehlen.
3. Then I have to click on "Show history".
4. I have to click on the edit button on the right of the last edit.

Before, I could just click on the link "German" and start translating/updating.

Comment 19

[vesper]

Safwan, would it be possible to change the link for the locales waiting for localization from:

https://support.mozilla.org/[LOCALE]/kb/[SLUG]

to:

https://support.mozilla.org/[LOCALE]/kb/[SLUG]/translate

??

Comment 20

[Safwan Rahman (:safwan)]

Vesper, The Current System makes as following

# The locals which Translation is needed (means no approved Revision), their links redirects into "locale/kb/slug/Translate" page

# The Locals which have any tranlsaion on that Document, their links Redirect into "Translated Article" Page

But, When a document got updated, and the localizers got Email notification with the link of "Translate Article" Page, they see their locals in the "Already translated" section
So when they try to localize that article, it make Time Consuming.

Polity, Thanks for the comment. As a localizer, I understand it well ;) I amtrying to dins a way to fix that!

Vesper, should we Redirect the second section locale to "/locale/kb/slug/history"? I think this way is better

Comment 21

[vesper]

@Safwan - yes, let's go with /locale/kb/slug/history - thank you!

Comment 22

[vesper]

Hi Safwan,

Can you update the generated link for already localized locales to /locale/kb/slug/history like we agreed? If you don't have the time, just tell me what I should add after the "document_slug" bit below, and I can do it via GitHub.

Thanks!

{% for locale in translated_locales %}
<li><a href="{{ url('wiki.document', locale=locale[0], document_slug=document.slug) }}">{{ locale[1] }} ({{ locale[0] }})</a></li>
{% endfor %}

Comment 23

[Will Kahn-Greene [:willkg] ET needinfo? me]

Is this bug still being worked on? Seems like it's stalled out and/or is waiting on something.

Comment 24

[Safwan Rahman (:safwan)]

(In reply to Will Kahn-Greene [:willkg] from comment #23)
> Is this bug still being worked on? Seems like it's stalled out and/or is
> waiting on something.

Oh! sorry. It was skipped as bug 1128948 was fixed.
The change mentioned in comment 22 is implemented with the following PR.
https://github.com/mozilla/kitsune/pull/2769

Comment 25

[Michael Cooper [:mythmon]]

PR 2769 has been merged and deployed.

Comment 26

[Tim [:pollti]]

https://github.com/mozilla/kitsune/pull/2769 caused many 404 links (bug 1051539) in "Translate article" pages like https://support.mozilla.org/en-US/kb/secure-connection-failed-error-message/locales (for all locales listed under "This document has already been translated to the following locales:"). Should we revert the PR for the moment?

Comment 27

[Safwan Rahman (:safwan)]

(In reply to Tim [:pollti] from comment #26)
> https://github.com/mozilla/kitsune/pull/2769 caused many 404 links (bug
> 1051539) in "Translate article" pages like
> https://support.mozilla.org/en-US/kb/secure-connection-failed-error-message/
> locales (for all locales listed under "This document has already been
> translated to the following locales:"). Should we revert the PR for the
> moment?

I think its better to ask for fixing that issue rather than reverting a PR. Reverting a PR does not solve the issue. Moreover, its not a blocker thing that its blocking localizers from localization. :)