This forum is a discussion about improving the "Keyboard shortcuts - Perform common Firefox tasks quickly" article. If you'd like to participate, please register.

If you need help with Firefox, please ask a question.

I accidentally approved a revision without marking it for translation ... and two "Miscellaneous" blocks

  • 8 Replies
  • Last reply by AliceWyman
  1. guigs 769 posts
    Report Abuse

    Apologies, in haste to try to help the Websites project manager fix a link to MDN in the English version, I did not flag the edit for localization.

    Can I be taught a bit more about the edit process so I don't do this again?

    The MDN article link used to include "Page Inspector" in the link and is now: https://developer.mozilla.org/ar/docs/Tools/Keyboard_shortcuts

    However I did not factor into the language url. Is there a way to undo of flag it correctly?

    Thank you for your help!

    Apologies, in haste to try to help the Websites project manager fix a link to MDN in the English version, I did not flag the edit for localization. Can I be taught a bit more about the edit process so I don't do this again? The MDN article link used to include "Page Inspector" in the link and is now: https://developer.mozilla.org/ar/docs/Tools/Keyboard_shortcuts However I did not factor into the language url. Is there a way to undo of flag it correctly? Thank you for your help!
  2. AliceWyman 5146 posts
    Report Abuse

    guigs said

    Apologies, in haste to try to help the Websites project manager fix a link to MDN in the English version, I did not flag the edit for localization. Can I be taught a bit more about the edit process so I don't do this again? The MDN article link used to include "Page Inspector" in the link and is now: https://developer.mozilla.org/ar/docs/Tools/Keyboard_shortcuts However I did not factor into the language url. Is there a way to undo of flag it correctly? Thank you for your help!


    I made a new revision to change the MDN link to https://developer.mozilla.org/docs/Tools/Keyboard_shortcuts (without the language part). See Write articles for the Knowledge Base under Style guide and copy rules:


    Links to mozilla.org should not contain the locale:


    Go ahead and approve it "ready for localization", if you wish. To mark revisions RFL if you ever forget, just click the red [-] in the article history, To learn more, see Article review guidelines.

    ''guigs [[#post-16913|said]]'' <blockquote> Apologies, in haste to try to help the Websites project manager fix a link to MDN in the English version, I did not flag the edit for localization. Can I be taught a bit more about the edit process so I don't do this again? The MDN article link used to include "Page Inspector" in the link and is now: https://developer.mozilla.org/ar/docs/Tools/Keyboard_shortcuts However I did not factor into the language url. Is there a way to undo of flag it correctly? Thank you for your help! </blockquote> I made a new revision to change the MDN link to https://developer.mozilla.org/docs/Tools/Keyboard_shortcuts (without the language part). See [[Write articles for the Knowledge Base]] under [[Write articles for the Knowledge Base#w_style-guide-and-copy-rules|Style guide and copy rules]]: ----- '''Links to mozilla.org should not contain the locale:''' *Use https://www.mozilla.org/ instead of https://www.mozilla.org/en-US/ ----- Go ahead and approve it "ready for localization", if you wish. To mark revisions RFL if you ever forget, just click the red [-] in the article history, To learn more, see [[Article review guidelines]].
  3. Chris Ilias 2070 posts
    Report Abuse

    guigs said

    Can I be taught a bit more about the edit process so I don't do this again?

    Check out Article review guidelines Ready for localization 2

    Theoretically, we shouldn't be marking edits ready for localization at the time of review. While no more edits are intended, other contributors will notice things they want to change and make further edits, then localizers get mad about having to re-localize the same article many times in a week.

    It's best to let the changes bake.

    ''guigs [[#post-16913|said]]'' <blockquote> Can I be taught a bit more about the edit process so I don't do this again? </blockquote> Check out [[Article review guidelines]] [[Image:Ready for localization 2]] Theoretically, we shouldn't be marking edits ready for localization at the time of review. While no more edits are ''intended'', other contributors will notice things they want to change and make further edits, then localizers get mad about having to re-localize the same article many times in a week. It's best to let the changes bake.
  4. AliceWyman 5146 posts
    Report Abuse

    Chris Ilias said

    guigs said
    Can I be taught a bit more about the edit process so I don't do this again?

    Theoretically, we shouldn't be marking edits ready for localization at the time of review. While no more edits are intended, other contributors will notice things they want to change and make further edits, then localizers get mad about having to re-localize the same article many times in a week.

    It's best to let the changes bake.

    Check out Article review guidelines:

    Ready for localization

    Marking an article revision as "Ready for Localization" lets us tell localizers that the English version is done and can be translated without fear that the article will change a few more times before they're done.

    When you are approving a revision, if all of the changes needed (needs change notes, article discussion forum) have been done and more are not planned for the current or next release, go ahead and mark the article as ready for localization.

    Ready for L10n

    {note}Note: Articles with approved content changes that have not been marked ready for localization are listed in the Changes Not Ready for Localization page.{/note}


    If you're going to approve articles that don't have any planned changes pending, without marking them RFL, you'll need to keep track of them so they don't fall by the wayside.[*] For example, https://support.mozilla.org/en-US/contributors/unready lists this article: 2. Install the Flash plugin to view videos, animations and games This article revision was created Sept 2017 and approved on Jun 14, 2018 but was never marked ready for localization - see https://support.mozilla.org/en-US/kb/install-flash-plugin-view-videos-animations-games/history

    [*] Related open bug: Bug 1205093 "Ready for L10N" column on KB dashboard should reflect only the last normal or major revision

    ''Chris Ilias [[#post-16924|said]]'' <blockquote> ''guigs [[#post-16913|said]]'' <blockquote> Can I be taught a bit more about the edit process so I don't do this again? </blockquote> Theoretically, we shouldn't be marking edits ready for localization at the time of review. While no more edits are ''intended'', other contributors will notice things they want to change and make further edits, then localizers get mad about having to re-localize the same article many times in a week. It's best to let the changes bake. </blockquote> Check out [[Article review guidelines]]: =Ready for localization= Marking an article revision as "Ready for Localization" lets us tell localizers that the English version is done and can be translated without fear that the article will change a few more times before they're done. '''When you are approving a revision, if all of the [[Article review guidelines#w_needs-changes|changes needed]] (needs change notes, article discussion forum) have been done and more are not planned for the current or next release, go ahead and mark the article as ready for localization.''' ;[[Image:Ready for L10n]] {note}'''Note:''' Articles with approved content changes that have not been marked ready for localization are listed in the [/contributors/unready Changes Not Ready for Localization] page.{/note} ----- If you're going to approve articles that don't have any planned changes pending, without marking them RFL, you'll need to keep track of them so they don't fall by the wayside.[*] For example, https://support.mozilla.org/en-US/contributors/unready lists this article: 2. [[Install the Flash plugin to view videos, animations and games]] This article revision was created Sept 2017 and approved on Jun 14, 2018 but was never marked ready for localization - see https://support.mozilla.org/en-US/kb/install-flash-plugin-view-videos-animations-games/history [*] Related open bug: [https://bugzilla.mozilla.org/show_bug.cgi?id=1205093 Bug 1205093] "Ready for L10N" column on KB dashboard should reflect only the last normal or major revision
    Modified by AliceWyman on
  5. Underpass 726 posts
    Report Abuse

    Hello, sorry to disturb you but the "Miscellaneous" block is shown twice.

    I see it starting from this revision

    https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly/revision/166226

    when the "for fx64" was added for the first time. Is it supposed to work?

    Hello, sorry to disturb you but the "Miscellaneous" block is shown twice. I see it starting from this revision https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly/revision/166226 when the "for fx64" was added for the first time. Is it supposed to work?
    Modified by Underpass on
  6. AliceWyman 5146 posts
    Report Abuse

    Underpass said

    Hello, sorry to disturb you but the "Miscellaneous" block is shown twice. I see it starting from this revision https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly/revision/166226 when the "for fx64" was added for the first time. Is it supposed to work?

    The second duplicate "Miscellaneous" block was first added in the "unreviewed" revision 166225, which contains both {for fx64} and {for not fx64} content, and then carried forward in later revisions:

    Revision id: 166225 Created: Sep 6, 2018, 11:17:31 AM Creator: gijs Comment: Bug 237027 changed shortcuts in the location bar for completion to various domains.


    ... which was based on Bug 237027 Use ctrl-enter for URL canonization on all platform, and offer an opt-out for Windows/Linux users where it interferes with opening URLs in (background) tabs RESOLVED FIXED in Firefox 64

    The "Miscellaneous" block is shown twice because {for fx64} content isn't hidden for earlier versions, since Firefox 64 hasn't been added to the version picker yet.

    We could either comment out the block and then add it back when fx64 is added to the version picker, or else just leave it as is, since it will eventually resolve itself.

    ''Underpass [[#post-17010|said]]'' <blockquote> Hello, sorry to disturb you but the "Miscellaneous" block is shown twice. I see it starting from this revision https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly/revision/166226 when the "for fx64" was added for the first time. Is it supposed to work? </blockquote> The <sub>second</sub> <s>duplicate</s> "Miscellaneous" block was first added in the "unreviewed" [https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly/revision/166225 revision 166225], which contains both {for fx64} and {for not fx64} content, and then carried forward in later revisions: ''Revision id: 166225'' ''Created: Sep 6, 2018, 11:17:31 AM'' ''Creator: gijs'' ''Comment: Bug 237027 changed shortcuts in the location bar for completion to various domains.'' ----- ... which was based on [https://bugzilla.mozilla.org/show_bug.cgi?id=237027 Bug 237027] Use ctrl-enter for URL canonization on all platform, and offer an opt-out for Windows/Linux users where it interferes with opening URLs in (background) tabs RESOLVED FIXED in Firefox 64 The "Miscellaneous" block is shown twice because {for fx64} content isn't hidden for earlier versions, since Firefox 64 hasn't been added to the version picker yet. We could either comment out the block and then add it back when fx64 is added to the version picker, or else just leave it as is, since it will eventually resolve itself.
    Modified by AliceWyman on
  7. AliceWyman 5146 posts
    Report Abuse

    P.S. The {for fx64} block has different content compared to the {for not fx64} block so it isn't actually a "duplicate".

    To Rachel: Should we make a new revision to hide (add <!-- ... --> tags around) the {for fx64} content and set up a "Needs change" entry for when Firefox 64 is added to the version picker, so that the {for fx64} content can be unhidden? Or, can you add Firefox 64 to the version picker yourself, right now? (If you don't have that ability, you could ask Joni or vesper).

    P.S. The {for fx64} block has different content compared to the {for not fx64} block so it isn't actually a "duplicate". '''To Rachel:''' Should we make a new revision to hide (add <nowiki><!-- ... --></nowiki> tags around) the {for fx64} content and set up a "Needs change" entry for when Firefox 64 is added to the version picker, so that the {for fx64} content can be unhidden? Or, can you add Firefox 64 to the version picker yourself, right now? (If you don't have that ability, you could ask Joni or vesper).
    Modified by AliceWyman on
  8. guigs 769 posts
    Report Abuse

    AliceWyman said

    P.S. The {for fx64} block has different content compared to the {for not fx64} block so it isn't actually a "duplicate". To Rachel: Should we make a new revision to hide (add <!-- ... --> tags around) the {for fx64} content and set up a "Needs change" entry for when Firefox 64 is added to the version picker, so that the {for fx64} content can be unhidden? Or, can you add Firefox 64 to the version picker yourself, right now? (If you don't have that ability, you could ask Joni or vesper).

    Yes, and thank you for the ping, I did miss the notification.

    ''AliceWyman [[#post-17012|said]]'' <blockquote> P.S. The {for fx64} block has different content compared to the {for not fx64} block so it isn't actually a "duplicate". '''To Rachel:''' Should we make a new revision to hide (add <nowiki><!-- ... --></nowiki> tags around) the {for fx64} content and set up a "Needs change" entry for when Firefox 64 is added to the version picker, so that the {for fx64} content can be unhidden? Or, can you add Firefox 64 to the version picker yourself, right now? (If you don't have that ability, you could ask Joni or vesper). </blockquote> Yes, and thank you for the ping, I did miss the notification. <!--if there is anyone who may be interested in shadowing a community manager or would like to volunteer to help with twitter data science stuff please contact me at guigs@mozilla.com-->
  9. AliceWyman 5146 posts
    Report Abuse

    guigs said Yes, and thank you for the ping, I did miss the notification. </blockquote>

    I took that to mean you want to edit the article to hide the {for fx64} content, then set up a Needs change entry to do a second revision when Firefox 64 is added to the version picker.

    I submitted a revision to "comment out" the {for fx64} Miscellaneous section and set up a Needs change entry. I also removed the outdated {for not fx50} content block and left the {for fx50} tags, so that it can be changed to {for not fx64} when we do the next revision.

    I'll leave this revision pending awhile in case I misunderstood what you want to do. Approved RFL.

    ''guigs [[#post-17015|said]]'' Yes, and thank you for the ping, I did miss the notification. </blockquote> I took that to mean you want to edit the article to hide the {for fx64} content, then set up a Needs change entry to do a second revision when Firefox 64 is added to the version picker. I submitted a revision to "comment out" the {for fx64} Miscellaneous section and set up a Needs change entry. I also removed the outdated {for not fx50} content block and left the {for fx50} tags, so that it can be changed to {for not fx64} when we do the next revision. <s>I'll leave this revision pending awhile in case I misunderstood what you want to do.</s> Approved RFL.
    Modified by AliceWyman on