Closed Bug 2000072 Opened 4 months ago Closed 2 months ago

Add current Firefox Beta version to the "Customize this article" version picker

Categories

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

Product:
support.mozilla.org
Component:
Knowledge Base Software
Type:
task

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: alice.wyman, Unassigned)

References

Details

Firefox 146 Beta was released on November 11, 2025 but the "Customize this article" version picker ends at Firefox version 145, also released on that date. We should add Firefox version 146 to the "Customize this article" version picker. Note that Version 145 is already the default when a Firefox article such as https://support.mozilla.org/en-US/kb/import-data-another-browser is viewed in another browser, as I mentioned in bug 1994714 comment 1 ( tested on Windows 11 with Google Chrome and Microsoft Edge.)

Hi Alice, we now have automation to update product version without having to do it manually, but the automation only covers the release channel. There's another proposal to add Beta and Nightly here, but we haven't decided on anything as of now.

I'm going to resolve this bug as won't fix for now, mainly because 146 will be automatically added later when the version hit the release channel.

Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → WONTFIX

Is it not possible to manually add version 146? Who knows when https://github.com/mozilla/sumo/issues/2583 will be fixed.

See Also: → https://github.com/mozilla/sumo/issues/2583

@Alice

Can we step back a little bit and tell me more about the actual goal of having Beta and Nightly version added in advance? I know it has been the norm in the past, but I'm eager to learn more about the actual purpose of the action.

Here's my understanding of the use case: It's possible to use the {for} syntax without having the version added, but then we won't be able to test the content if the version hasn't been added in Kitsune. Am I getting it correctly? You've been here longer than me, so I'm counting on you to let me know if there's any other use cases that I may not consider.

Flags: needinfo?(alice.wyman)

(In reply to Kelimutu [:kiki] from comment #3)

@Alice

Can we step back a little bit and tell me more about the actual goal of having Beta and Nightly version added in advance? I know it has been the norm in the past, but I'm eager to learn more about the actual purpose of the action.

Here's my understanding of the use case: It's possible to use the {for} syntax without having the version added, but then we won't be able to test the content if the version hasn't been added in Kitsune. Am I getting it correctly? You've been here longer than me, so I'm counting on you to let me know if there's any other use cases that I may not consider.

If you read through the comments in https://github.com/mozilla/sumo/issues/2559 you will see that, by adding {for fx146} markup, for example, we can approve article updates that include content specific to Firefox 146 without waiting for that version to be released, which benefits localizers. Here is one article I know of that has {for fx146} content pending: https://support.mozilla.org/en-US/kb/about-new-tab-page/history

This is from https://github.com/mozilla/sumo/issues/2559#issuecomment-3410648674 (quote)

AliceWyman on Oct 16

@AliceWyman No, this automation is going to automatically check for, add & set as default the latest release version.

Is there a reason why we would like to add beta versions to the version picker?

That's been the normal practice since KB articles are often updated for upcoming versions which are still in beta. We use {for} tags (for example, {for fx145}, the current Firefox Beta version) so that content won't appear unless the article is viewed in Firefox 145.

The following is from https://support.mozilla.org/en-US/kb/how-to-use-for#w_leverage-for-tags-for-advanced-versioning-control
(quote)
Leverage {for} tags for advanced versioning control
With frequent updates and feature releases in Firefox, for tags play a key role for targeted content curation, enabling us to deliver relevant information to users based on their specific version of Firefox. Key applications of these tags include:

  • Early access for Nightly and Beta Users: It allows us to present upcoming features or changes to users who are on Nightly and Beta channels, giving them a heads-up about what they might find. This ensures that our most engaged and technical users can start exploring new functionalities ahead of the broader community.
  • Localization ahead of launch: for tags allow us to publish content for upcoming versions ahead of their public release. This allows our localization community to prepare translations early, guaranteeing multi-language support the moment a new version goes live in the Production channel.
  • Avoid confusion among general audience: Using for tags, we strategically avoid exposing our general audience to premature information, thereby preventing confusion about what's currently available in their current version of Firefox.
Flags: needinfo?(alice.wyman)
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

See https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles/history
There's a revision pending review with the comment, "See Bug 1997140. For 146 release." This revision needs {for fx146} markup for the updated content; however, Version 146 hasn't yet been added to the version picker.

Hi Alice,

I understand that it allows us to create content for an upcoming version. I'm talking more about the specific functionality that this enable us.

Correct me if I'm wrong, but here's my understanding of the use case: we can use {for fx146} syntax in the content just fine, without having to add version 146 in Kitsune. However, there we won't have the version picker to test the content (here's the first use case) and also, users won't be able to see the specific content for 146 because we haven't added the version (the second use case).

In the meantime, I'll check with the dev if I can manually add 146. I just want to make sure that it won't interfere with the automation.

Flags: needinfo?(alice.wyman)

(In reply to Kelimutu [:kiki] from comment #6)

Correct me if I'm wrong, but here's my understanding of the use case: we can use {for fx146} syntax in the content just fine, without having to add version 146 in Kitsune. However, there we won't have the version picker to test the content (here's the first use case) and also, users won't be able to see the specific content for 146 because we haven't added the version (the second use case).

You're wrong. If you use {for fx146} in the content and Version 146 hasn't been added to the version picker, all users will see the specific content, including those with Firefox 145 and below.

Flags: needinfo?(alice.wyman)

Oh, we wouldn't want that for sure. Let me double check this with my team. Thanks again for bringing this to our attention.

Kiki, You can confirm that {for fx146} content displays in Firefox 145 and below when Version 146 hasn't been added to the version picker, by viewing this pending revision that Flavius just submitted: https://support.mozilla.org/en-US/kb/profile-management/revision/315100 (Comment: Do not edit/publish without permission. To be published on 12/9. See Bug 1994848.)

Please add at least version 146. I'm not asking for 147... but at least 146...
Since 2008, we've never had to ask for beta and nightly releases because they were already there and didn't cause problems for users, since the version selector/picker automatically displays instructions for the browser version in use.
I don't understand these current choices and why it's become so difficult to manage a version selector (but I'm not a developer).
The lack of these higher versions from the selector doesn't help us localizers when we want to save time and complete our "work" ahead of time. We can't verify that everything is working properly.

Summary: Add Firefox Version 146 to the "Customize this article" version picker → Add current Firefox Beta version to the "Customize this article" version picker

Hi Alice,

Thanks for pointing out a concrete example of this issue. I can confirm that when content has no matching version assigned, it ends up being displayed for all versions by default.

That said, I’m still waiting on confirmation from the dev team regarding whether manually adding a new version will interfere with the current automation logic.

Apologies that this is taking longer than expected to figure this out. We’re still working through adjustments related to the new automation. Michele, I understand how important this functionality is for testing localized content. I’ll share any updates as soon as I have them. Hopefully, I’ll get a response by the end of the day.

Thanks again for everyone's patience!

Hi both,

Looks like we'll break the automation if we add a new version manually because the automation work by making the latest version the default. So if we add 146 now, the automation will generate 147 tomorrow and mark 147 as the default which will complicate things.

@Alice the revision note mentioned that the revision need to be published by 12/9. If the automation work as expected, there shouldn't be a problem to preview the revision with 146 selector tomorrow. Can you enlighten me why we need 146 to be added sooner? Is there any other articles with 146 content that that may be have been published?

@Michele Please forgive me if I have to ask a bit further. If most of the content for the next version published on the release date, how do you usually manage the localization work ahead of time?

Flags: needinfo?(michele.rodaro)

(In reply to Kelimutu [:kiki] from comment #12)

@Michele Please forgive me if I have to ask a bit further. If most of the content for the next version published on the release date, how do you usually manage the localization work ahead of time?

No worry ;)
I visit this page https://support.mozilla.org/en-US/contributors/unreviewed# > "Most recent" tab
I check the latest changes and, if I find something (written by a technical writer, staff, or a trusted contributor) that I can edit before the original change is marked "Ready for Localization" and I have time, I edit the Italian version online without approving it, or I edit it offline, then, once the article is RFL, I edit the Italian version online. This is how I typically manage my localization work ahead of time. The introduction of machine translation has changed my article management a bit, but that's another story…

Flags: needinfo?(michele.rodaro)

(In reply to Michele Rodaro [:michro] from comment #13)

No worry ;)
I visit this page https://support.mozilla.org/en-US/contributors/unreviewed# > "Most recent" tab
I check the latest changes and, if I find something (written by a technical writer, staff, or a trusted contributor) that I can edit before the original change is marked "Ready for Localization" and I have time, I edit the Italian version online without approving it, or I edit it offline, then, once the article is RFL, I edit the Italian version online. This is how I typically manage my localization work ahead of time. The introduction of machine translation has changed my article management a bit, but that's another story…

No doubt about it. Michele, you truly are one of a kind. Thanks (as always) for taking the initiative!

While we haven’t yet reached a decision on whether to support Beta (and Nightly) versions officially, I’m afraid we’ll need to rely on a workaround during the editing process for now.

What do you think about using an existing version that's already available when drafting the content? I realize this might not fully solve the problem during the review process, but at least it gives us a way to move forward in the meantime.

(In reply to Kelimutu [:kiki] from comment #14)

What do you think about using an existing version that's already available when drafting the content? I realize this might not fully solve the problem during the review process, but at least it gives us a way to move forward in the meantime.

Ciao Kiki, I'm sorry, but I don't understand what you mean by "an existing version that's already available". If you give me an example, maybe I can think about it better. You know, I'm getting older, and my neurons aren't working as well as they used to… :))

(In reply to Kelimutu [:kiki] from comment #14)

While we haven’t yet reached a decision on whether to support Beta (and Nightly) versions officially, I’m afraid we’ll need to rely on a workaround during the editing process for now.

The issue isn't whether to support Beta (and Nightly) versions officially. It's whether to include the version numbers in the "Customize this article" version picker, as I wrote on on Oct 16 here: https://github.com/mozilla/sumo/issues/2559#issuecomment-3412851058 (quote) The "Customize this article" version picker doesn't say "Beta" or "Nightly" anywhere. It just shows the Version number in the drop-down list. As Michele (michro) said, The purpose of the version picker has always been to automatically detect a user's Firefox version and show them the article content for that version.. (Another use is that editors can check their work when using {for} markup, by changing the version selector.) Having the Beta version (currently 145) or the Nightly version (currently 146) listed in the version picker doesn't mean we support pre-release versions. It does mean that we can update articles for changes that are coming in Firefox

(In reply to Michele Rodaro [:michro] from comment #15)

Ciao Kiki, I'm sorry, but I don't understand what you mean by "an existing version that's already available". If you give me an example, maybe I can think about it better. You know, I'm getting older, and my neurons aren't working as well as they used to… :))

Hey Michele, you're still impressive for someone your age! (:

Anyway, here's what I meant exactly: during the editing process, you can use any available version for testing purposes. So, for example, if you're drafting content specific to the upcoming version 147 (whish is not currently available), you can temporarily use 137 or 138 (or whatever’s already available) just for testing and previewing your edits.

I hope that makes things a bit clearer, but let me know if it's still unclear. Happy to explain further.

(In reply to Alice Wyman from comment #16)

The issue isn't whether to support Beta (and Nightly) versions officially. It's whether to include the version numbers in the "Customize this article" version picker, as I wrote on on Oct 16 here: https://github.com/mozilla/sumo/issues/2559#issuecomment-3412851058 (quote) The "Customize this article" version picker doesn't say "Beta" or "Nightly" anywhere. It just shows the Version number in the drop-down list. As Michele (michro) said, The purpose of the version picker has always been to automatically detect a user's Firefox version and show them the article content for that version.. (Another use is that editors can check their work when using {for} markup, by changing the version selector.) Having the Beta version (currently 145) or the Nightly version (currently 146) listed in the version picker doesn't mean we support pre-release versions. It does mean that we can update articles for changes that are coming in Firefox

@Alice Hey Alice, I understand. I used the term Beta/Nightly here to stay consistent with the language used in the proposal. Right now, we're facing an issue where we can’t even manually add an upcoming version without interfering with the automation, which, as you can imagine, complicates things.

What I’m trying to do at this point is get a clearer sense of how high of a priority this proposal is, so we can bring the full context to the platform team and advocate accordingly. With that in mind, would you mind circling back to my earlier question in c12? That’ll really help us move forward. Thanks so much!

Flags: needinfo?(alice.wyman)

Version 146 is no longer the issue since Firefox Beta 147 was just released. That's why I changed the bug summary from Add Firefox Version 146 ... to Add current Firefox Beta version to the "Customize this article" version picker.

Also, the related open github issue, Use product details to create product versions for Beta & Nightly links to this bug. To Emil: Is it that hard to implement a change to automatically add the release AND Beta versions and set the release version as the default, when a new Firefox release comes out?

To Kiki: Sometimes there will be many articles with new content for the next Firefox version, sometimes not. We need the option to add {for fx147} markup (for example) when an update is needed for the upcoming Firefox 147 version which is currently in beta, so that it can be approved ahead of time to allow for timely localization. You can watch the SUMO bugzilla list to see when [Version 147] updates are needed... however, sometimes the bugzilla summary doesn't include the Firefox version which includes the change that needs an updated SUMO article.

To answer your question about other articles: In addition to the articles with pending fx146 content I mentioned above in comment 4, comment 5 and comment 9, here are two others I found with the revision comment, To be published on 12/9, which is the Firefox 146 release date:

Both of these are new articles which I assume refer to a change that took place in Firefox version 146. Instead of waiting for the Firefox 146 release date to publish, a simple {for not fx146} (or corresponding {for not m146} for Android) could have been included that displays for users running version 145 and below, stating that the article contains content that applies Firefox version 146 and above. Flavius may be able to tell you more about upcoming changes.

Flags: needinfo?(alice.wyman)

(from comment #18)

Also, the related open github issue, Use product details to create product versions for Beta & Nightly links to this bug. To Emil: Is it that hard to implement a change to automatically add the release AND Beta versions and set the release version as the default, when a new Firefox release comes out?

Flags: needinfo?(eghitta)

(In reply to Alice Wyman from comment #18)

To Kiki: Sometimes there will be many articles with new content for the next Firefox version, sometimes not. We need the option to add {for fx147} markup (for example) when an update is needed for the upcoming Firefox 147 version which is currently in beta, so that it can be approved ahead of time to allow for timely localization. You can watch the SUMO bugzilla list to see when [Version 147] updates are needed... however, sometimes the bugzilla summary doesn't include the Firefox version which includes the change that needs an updated SUMO article.

To answer your question about other articles: In addition to the articles with pending fx146 content I mentioned above in comment 4, comment 5 and comment 9, here are two others I found with the revision comment, To be published on 12/9, which is the Firefox 146 release date:

Both of these are new articles which I assume refer to a change that took place in Firefox version 146. Instead of waiting for the Firefox 146 release date to publish, a simple {for not fx146} (or corresponding {for not m146} for Android) could have been included that displays for users running version 145 and below, stating that the article contains content that applies Firefox version 146 and above. Flavius may be able to tell you more about upcoming changes.

Thanks for your explanation, Alice. I think there's a reason the comment says to be published on 12/9. The content process has undergone many changes, and I believe publishing on the release date is the new norm nowadays. Let me loop in the content team to clarify if that's indeed the case.

Regarding your question to Emil, here's what I got from the platform team:

Add beta and nightly in the version picker. Automatically migrate nightly to beta and beta to stable after each product release and mark stable as default. This is the most complex b/c we need to introduce the concept of nightly and beta.

I'm clearing the NI for Emil for now, but feel free to ask follow up questions. In the meantime, I'll ask the content team to chime in to clarify their content process.

Flags: needinfo?(eghitta)
See Also: → https://github.com/mozilla/kitsune/pull/7120

Hi everyone,

Alice has already mentioned #7120. To clarify: this PR (that should resolve the issue) is merged and pending QA. If it goes well, it should land on prod in the next kitsune release (most likely after the holidays, but still).

Denys, thank you so much for working on that one. I'm glad we have a path forward for this issue.

The mentioned patch is now on prod, and the Beta (148) and Nightly (149) versions have been successfully added. The stable (147) version stays the default.

Alice, would you do the honor and close this bug as resolved?

Flags: needinfo?(alice.wyman)

Oh I was just about to leave a comment and close this ticket but I got a mid-air collision with the comment above.

With the new release beta & nightly versions are now available inside the version picker.

Status: REOPENED → RESOLVED
Closed: 4 months ago → 2 months ago
Flags: needinfo?(alice.wyman)
Resolution: --- → FIXED

I'll verify the bug is fixed. Thanks!

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.