Closed Bug 1321585 Opened 7 years ago Closed 7 years ago

"Needs Revision" for migrated articles

Categories

(support.mozilla.org :: Lithium Migration, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: scott.riley, Assigned: scott.riley)

References

()

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161104212021

Steps to reproduce:

Mozilla has provided this data for current articles that need to be revised.  Chavi's team is stating that it has been migrated.  We need to verify that on the UI side.


Actual results:

Examples from Migration: http://migration26.stage.lithium.com/t5/Templates/Template-closeFirefox/ta-p/1221835

http://migration26.stage.lithium.com/t5/Basic-Browsing/Firefox-menu-icon-is-missing-on-Android-how-to-access-the-menu/ta-p/1248947

http://migration26.stage.lithium.com/t5/Basic-Browsing/Use-Firefox-desktop-to-send-videos-and-webpages-to-your-Roku/ta-p/1257931

Based on the above, the UI is not reflecting this either in the 'Needs l10n' check box or the search results.


Expected results:

Migrated content that needs revision should be identifiable.
Tyson, would you be able to verify this one?
Flags: needinfo?(tyson.nunemacher)
Assignee: nobody → scott.riley
Does this bug cover migrated articles that need changes, such as those listed in https://support.mozilla.org/en-US/contributors/need-changes or in https://support.mozilla.org/en-US/contributors/kb-overview under the "Needs update" column? 

Related discussion in the KB articles forum: 
https://support.mozilla.org/en-US/forums/knowledge-base-articles/712293 Lithium Migration: Controls for articles that need changes
Madalina, you have already assigned this to Scot. If this occurs in the current migration surely the bug status needs revising to New.

Presumably contributors will be able to set and unset any such marking for all articles. Perhaps we could also add a see also bug1322511
(In reply to scott.riley from comment #0)
 
> Mozilla has provided this data for current articles that need to be revised.
> Chavi's team is stating that it has been migrated.  We need to verify that
> on the UI side.
> 
> 
> Actual results:
> 
> Examples from Migration:
> http://migration26.stage.lithium.com/t5/Templates/Template-closeFirefox/ta-p/1221835
> 
> http://migration26.stage.lithium.com/t5/Basic-Browsing/Firefox-menu-icon-is-missing-on-Android-how-to-access-the-menu/ta-p/1248947
> 
> http://migration26.stage.lithium.com/t5/Basic-Browsing/Use-Firefox-desktop-to-send-videos-and-webpages-to-your-Roku/ta-p/1257931
> 
> Based on the above, the UI is not reflecting this either in the 'Needs l10n'
> check box or the search results.
> 
> 
> Expected results:
> 
> Migrated content that needs revision should be identifiable.

By  "needs revision", do you mean "needs localization"?  Does this bug ONLY cover articles that need to be localized or "Needs L10n?" If so, the summary needs to be updated. 

For the record, http://migration26.stage.lithium.com/t5/Basic-Browsing/Use-Firefox-desktop-to-send-videos-and-webpages-to-your-Roku/ta-p/1257931 is an OBSOLETE article [1] that was never localized.  It does have a "needs localization" flag set according to its history [2] but, since it's an archived (obsolete) article, it does not need to be localized.

1. https://support.mozilla.org/en-US/kb/send-videos-and-webpages-your-roku-desktop
2. https://support.mozilla.org/en-US/kb/send-videos-and-webpages-your-roku-desktop/history
Flags: needinfo?(jsavage)
(In reply to Alice Wyman from comment #4)
> http://migration26.stage.lithium.com/t5/Basic-Browsing/Use-Firefox-desktop-to-send-videos-and-webpages-to-your-Roku/ta-p/1257931
> is an OBSOLETE article[1] that was never localized.  It does have a "needs localization" flag set
> according to its history [2] <snip>
> 1. https://support.mozilla.org/en-US/kb/send-videos-and-webpages-your-roku-desktop
> 2. https://support.mozilla.org/en-US/kb/send-videos-and-webpages-your-roku-desktop/history

I meant to say "not ready for localization". Approved revisions that are not ready to localize are listed at https://support.mozilla.org/en-US/contributors/unready (archived articles are not listed).
The filed in the migrated data is currently mapped to the needs l10n.  We can fix this, discussing with everyone how it makes the most sense to update needs update and needs translation with the teams now.
Status: UNCONFIRMED → NEW
Ever confirmed: true
“Needs Update” Field
-  UI is created and can be tested:  http://migration26.stage.lithium.com/t5/Video-audio-and-interactive/Watch-DRM-content-on-Firefox/ta-p/1254935
-  Migration data is mapped and can be tested:  http://migration26.stage.lithium.com/t5/forums/searchpage/tab/message?filter=adminTags&q=firefox&admin_tags=modbar.needs.update

“Needs Update Detail“ Field
-  UI is created and can be tested:  http://migration26.stage.lithium.com/t5/tkb/articleeditorpage/tkb-id/Video-Audio-Interactive/message-uid/1254935
-  Migration Data:  We have this data as “wiki_document.needs_change_comment” and will have this updated on the migration site shortly.

“Needs l10n” Field
-  UI is created and can be tested: http://migration26.stage.lithium.com/t5/Basic-Browsing/Tab-Groups-feature-discontinued/ta-p/1259376 and 
-  Migration Data:  Mozilla needs to tell us what field this is (Giorgos) and if we should be migrating it (Joni and Michal).  If many articles have this flag currently, makes sense to migrate.  If it's only a few, probably not needed.
Flags: needinfo?(tyson.nunemacher) → needinfo?(giorgos)
Flags: needinfo?(jsavage)
Flags: needinfo?(mdziewonski)
Thank you, Scott & team!

I don't think we need to be concerned migrating with a special separate field for l10n, since we already have the custom tag visible in the UI, and we can always use the version comments to convey additional information, as far as I understand.
Flags: needinfo?(mdziewonski)
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
Cancelling my needinfo from comment 7 per comment 9
Flags: needinfo?(giorgos)
You need to log in before you can comment on or make changes to this bug.