Move markdown lint disabling instruction below 2026.2 change log

[CyrilleB79]

Link to issue number:

Fix-up of #19354

Summary of the issue:

In the PR to start 2026.2 dev cycle, the new 2026.2 section has been created, but the markdown disable instruction has remained below 2026.1 section.

Description of user facing changes:

None

Description of developer facing changes:

Moved the instruction to disable markdown linting below 2026.2 section.

Description of development approach:

N/A

Testing strategy:

Not tested. A careful review should be enough.

Known issues with pull request:

None

Additional remark

It seems that internally at NV Access, you have a task list that you copy / paste in the initial description of each PR starting a new dev cycle. It would be the opportunity to update also this task list to mention that the linter command should be moved below the newly created section.

Code Review Checklist:

• Documentation:
  • Change log entry
  • User Documentation
  • Developer / Technical Documentation
  • Context sensitive help for GUI changes
• Testing:
  • Unit tests
  • System (end to end) tests
  • Manual testing
• UX of all users considered:
  • Speech
  • Braille
  • Low Vision
  • Different web browsers
  • Localization in other languages / culture than English
• API is compatible with existing add-ons.
• Security precautions taken.

[seanbudd]

I don't understand why this should be moved? everything under 2026.1 has invalid syntax we don't want to change to avoid translator work. We want to keep everything above that with the correct syntax.

[CyrilleB79]

I had probably not thought to it so much, but it seemed strange to me that during 2026.2 dev cycle, we still lint 2026.1 change log.

You may object that there won't be any change since 2026.1 is already linted. That's true as long as you don't change linter version. If you upgrade the linter, you may theoritically catch and fix new issues that would not have been caught with the previous linter version.

Maybe we should just change this directive's position when we actually upgrade the linter?

Feel free to close this PR if you feel it is not relevant.

[SaschaCowley]

I think that we should keep linting until the translation freeze. So the disable instruction should stay where it is currently for now, but we should move it above 2026.1 for the last planned beta, or when branching for 2026.3 (the latter is probably easier)

[seanbudd]

I think the easiest would just be to leave it though? I guess the only downside is if linting rules change we would need to move it up

[SaschaCowley]

We could just add a new <!-- markdownlint-disable --> when a version hits stable. I doubt there's a real performance penalty to having multiple of them in one file. I don't like the idea of just trusting that we'll remember to do it if/when lint rules change

[seanbudd]

We'd be forced to do it when lint rules change, for example with #19311. When updating markdownlint we'd either have to lint the old changes, which we wouldn't do out of habit, or move the comment

[SaschaCowley]

We'd be forced to do it when lint rules change, for example with #19311. When updating markdownlint we'd either have to lint the old changes, which we wouldn't do out of habit, or move the comment

That relies on us remembering to do so when we update Markdownlint. It seems safer to me to add a step to the release process to add a comment to the changes file when each section is frozen

[seanbudd]

It wouldn't be a matter of remembering, tests wouldn't pass. You'd be fixing the tests by moving the line

[SaschaCowley]

It wouldn't be a matter of remembering, tests wouldn't pass. You'd be fixing the tests by moving the line

Markdownlint fixes violations that it can fix safely. So when it's run as part of pre-commit.ci, it might modify sections that should be frozen

[seanbudd]

Ah fair enough, I'm convinced to move it each release

[seanbudd]

Thanks @CyrilleB79, I've opened a PR to fix up our template, and also consider moving it here to open source it