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

Major changes of some English articles don't show up in localization dashboards, if the localized article has not been edited after migration

VERIFIED FIXED in 2.5

Status

support.mozilla.org
General
P2
normal
VERIFIED FIXED
7 years ago
7 years ago

People

(Reporter: Scoobidiver (away), Assigned: erik)

Tracking

unspecified

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
Major changes on "Template:optionspreferences" don't show up in some localization dashboards. For instance, fr, it, pt-BR and ru locales are impacted.
It works well for some other locales as de, because there have been changes in this template after SUMO migration.
(Reporter)

Comment 1

7 years ago
It is also applicable to changes of "What is Firefox Sync?" article.
Summary: Major changes on "Template:optionspreferences" don't show up in some localization dashboards → Major changes of some English articles don't show up in localization dashboards, if the localized article has not been edited after migration
(Reporter)

Comment 2

7 years ago
It is also applicable to changes of "Contributor Home page" article.
James, could you have a look at this? Not being able to follow changes of English articles is a major issues.
Target Milestone: --- → 2.4.2
Added to 2.4.2 too close to freeze. Will dig into it next week for 2.4.3.

Erik, my suspicion is that the queries in the l10n dashboard don't find revisions that are current but have no approved value. Maybe it's easiest to just set is_approved = True where id in (select current_revision_id from documents)?
Assignee: nobody → erik
Target Milestone: 2.4.2 → 2.4.3
(Assignee)

Comment 5

7 years ago
Well, in my few-week-old dump, there are no current revisions that aren't approved.
(Assignee)

Comment 6

7 years ago
It doesn't look like we set based_on_ids for the articles we migrated. If we only migrated 1 revision of the English articles we migrated (which I think is the case), we should just run a migration to set the based_on_ids of the translations to the first revision of the originals.
(Assignee)

Updated

7 years ago
Priority: -- → P2
(Assignee)

Updated

7 years ago
Target Milestone: 2.4.3 → 2011Q1
Hey guys, this is a big one, is there a way to get it into the next release after 2.4.3?
If what Erik says in comment 6 still applies and fixes it, I should be able to get a migration SQL going for these.
Target Milestone: 2011Q1 → 2.5
(Assignee)

Comment 9

7 years ago
Fixed in https://github.com/jsocol/kitsune/commit/d4b83320d79abf815137ef5a3d5984189e9ba11c.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Is there a migrated article I can verify, or is there a way to have a test article migrated?
(Assignee)

Comment 11

7 years ago
Either of the two Scoobidiver mentioned above should be fine. Make a change to either of those, review it and mark it as substantial, and then confirm it shows up on the L10n Dashboard.
Verified approved major edits to an en-US article display under Traductions obsol├Ętes on the /fr locale.
Status: RESOLVED → VERIFIED
(Reporter)

Comment 13

7 years ago
Don't verify in the French locale as I have already edited articles based on the KB articles forum, even if they didn't show up in the localization dashboard. So that is normal it works even without the fixing.
(Reporter)

Updated

7 years ago
Status: VERIFIED → RESOLVED
Last Resolved: 7 years ago7 years ago
This was also tested in the /de locale
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.