Skip to content

Review 2026.1 changelog/documentation changes#19319

Merged
SaschaCowley merged 24 commits into
masterfrom
docsFor2026.1
Dec 9, 2025
Merged

Review 2026.1 changelog/documentation changes#19319
SaschaCowley merged 24 commits into
masterfrom
docsFor2026.1

Conversation

@SaschaCowley

Copy link
Copy Markdown
Member

Must be a squash merge

Changes from this PR to the previous release:

  • Files to check: user_docs/en/userGuide.md, user_docs/en/changes.md developerGuide.md
  • Compare this branch to the previous release
  • Comparison command:
    git diff release-2025.3.2...docsFor2026.1 -- "**/en/*.md" "**/developerGuide.md"

Common mistakes to check for:

  • Issue/PR reference in changes file is incorrect
  • Incorrect spelling.
  • Shortcuts added without code markdown (e.g. NVDA+d)
  • List items not indented by a multiple of 2 spaces (regex ^ ( )*\*)
  • Double spaces (regex [^ ] )
  • Inconsistent use of single vs double quote. (regex ' )

@SaschaCowley SaschaCowley marked this pull request as ready for review December 3, 2025 06:30
@SaschaCowley SaschaCowley requested review from a team as code owners December 3, 2025 06:30
Comment thread user_docs/en/changes.md Outdated
Comment thread user_docs/en/changes.md Outdated
Comment thread user_docs/en/changes.md Outdated
Comment thread user_docs/en/changes.md Outdated
Comment thread user_docs/en/changes.md
Comment thread user_docs/en/changes.md Outdated
Comment thread user_docs/en/changes.md
Comment thread user_docs/en/changes.md
Comment thread user_docs/en/changes.md
Comment thread user_docs/en/changes.md Outdated
@CyrilleB79

Copy link
Copy Markdown
Contributor

The API-breaking changes and Deprecation sections are quite big.

I wonder if there would be a way to reorganize them, e.g.:

  1. Making 4 groups: symbols removed with no replacement, symbols removed with a suggested replacement, deprecated symbols with no replacement and deprecated symbols with a suggested replacement
  2. Or perform thematic grouping (more than it is already now)

Just a question, I have no strong requirement nor suggestion on this.

@CyrilleB79

Copy link
Copy Markdown
Contributor

Also, I do not know if it should land in this PR. But the release blurb is incomplete.

@SaschaCowley SaschaCowley marked this pull request as draft December 3, 2025 22:25
@seanbudd seanbudd added the conceptApproved Similar 'triaged' for issues, PR accepted in theory, implementation needs review. label Dec 4, 2025
@SaschaCowley SaschaCowley marked this pull request as ready for review December 4, 2025 02:40
@SaschaCowley SaschaCowley requested a review from seanbudd December 4, 2025 02:40
Comment thread user_docs/en/changes.md Outdated
Comment thread user_docs/en/changes.md Outdated
Comment thread user_docs/en/changes.md Outdated
Comment thread user_docs/en/changes.md Outdated
Comment thread user_docs/en/changes.md Outdated
Comment thread user_docs/en/changes.md
Comment thread user_docs/en/changes.md Outdated
Comment thread user_docs/en/changes.md Outdated
Comment thread user_docs/en/changes.md Outdated

@Qchristensen Qchristensen left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reads well, good work

Comment thread user_docs/en/changes.md
@SaschaCowley

Copy link
Copy Markdown
Member Author

@CyrilleB79

I wonder if there would be a way to reorganize [the API-breaking changes and Deprecation sections]

I thought about creating two tables:

  • Removed symbols (module, symbol, suggested replacement); and
  • Deprecated symbols (module, symbol, suggested replacement).

However I don't think we've done anything like that in our changes files before, and I'm not sure how easy folks would find it to read.

  1. Making 4 groups: symbols removed with no replacement, symbols removed with a suggested replacement, deprecated symbols with no replacement and deprecated symbols with a suggested replacement

This could also work.

  1. Or perform thematic grouping (more than it is already now)

I don't think this is practical. Many of the changes are quite broad.

Regardless, I think if we do decide to do this, it is probably fine to be done in a subsequent PR. @seanbudd what do you think?

@seanbudd

seanbudd commented Dec 8, 2025

Copy link
Copy Markdown
Member

I would avoid making major reworks to the changes file in a separate PR. I think we should try to get it roughly right in the first beta as it's our signal to add-on to devs (and translators) to start work.
I think tables of the 4 categories cyrille provided might be optimal - if so, also update the changes template.

@SaschaCowley

Copy link
Copy Markdown
Member Author

I think tables of the 4 categories cyrille provided might be optimal - if so, also update the changes template.

Can you clarify what you mean by this? Cyrille proposed 4 lists. I proposed 2 tables.

@seanbudd

seanbudd commented Dec 8, 2025

Copy link
Copy Markdown
Member

I'm proposing 4 tables based on Cyrille categories and your formatting

@SaschaCowley

Copy link
Copy Markdown
Member Author

@seanbudd can you explain further what you mean? What would be the point of using my tables (which include suggested replacements) for symbols removed/deprecated with no replacement?

@seanbudd

seanbudd commented Dec 8, 2025

Copy link
Copy Markdown
Member

cleaner formatting and more consistent navigation?

@SaschaCowley

Copy link
Copy Markdown
Member Author

I've just spent a while trying to reformat the changes for developers in a way that remains readable and keeps all the essential information, and I can't come up with anything that is consistent and better than what we've already goot. @seanbudd can I merge this without rewriting the changes for devs?

@CyrilleB79

Copy link
Copy Markdown
Contributor

I've just spent a while trying to reformat the changes for developers in a way that remains readable and keeps all the essential information, and I can't come up with anything that is consistent and better than what we've already goot. @seanbudd can I merge this without rewriting the changes for devs?

Yes, no need to spend more time on this.
Thanks for having tried to find a better presentation though.

SaschaCowley added a commit that referenced this pull request Dec 9, 2025
Related to #19053
Related to #19298

### Summary of the issue:

The on-device AI image descriptions introduced into NVDA tend to
experience halucinations, especially when used on material other than
photographs.

### Description of user facing changes:

* Descriptions retrieved with this feature are now prefixed with "Could
be"
* The settings and temporary enable dialogs now warn the user that the
feature is experimental and not to use it in high-stakes situations
* The User Guide includes a slightly longer disclaimer about the feature

### Description of developer facing changes:

None

### Description of development approach:

Used a template string when outputting the AI slop so that a
hedge-phrase can be used.
Wrote up a warning message for the user guide. Shortened it slightly and
inserted into the settings panel and temporary enable dialog.

I have not updated `changes.md`, as that would just create merge
conflicts. I will do it in #19319.

### Testing strategy:

Ran NVDA. Checked that the settings panel speaks the warning and that
the warning is visible. Checked that the warning is shown in the temp
enable dialog.

### Known issues with pull request:

Doesn't address the underlying issue.
The language used for this feature also seems confusing and
inconsistent, but that is out of scope for this issue.
@SaschaCowley SaschaCowley merged commit 8373197 into master Dec 9, 2025
6 checks passed
@SaschaCowley SaschaCowley deleted the docsFor2026.1 branch December 9, 2025 04:02
@github-actions github-actions Bot added this to the 2026.1 milestone Dec 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

conceptApproved Similar 'triaged' for issues, PR accepted in theory, implementation needs review.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants