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?
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  that was never localized. It does have a "needs localization" flag set according to its history  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
(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 that was never localized. It does have a "needs localization" flag set > according to its history  <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.
2 years ago
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)
"Needs Update Detail" Field is now migrated: http://migration26.stage.lithium.com/t5/tkb/articleeditorpage/tkb-id/customize-preferences-android/message-uid/1223010 http://migration26.stage.lithium.com/t5/tkb/articleeditorpage/tkb-id/customize-preferences-android/message-uid/1244457 http://migration26.stage.lithium.com/t5/tkb/articleeditorpage/tkb-id/customize-preferences-android/message-uid/1247541 http://migration26.stage.lithium.com/t5/tkb/articleeditorpage/tkb-id/customize-preferences-android/message-uid/1259204 Still need an answer to the needs translation field and if we should be concerned w/migrating it.
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.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.