Use Windows date preferences in Add-on Store

[islambenmebarekdz-collab]

Link to issue number:

Fixes #19681

Summary of the issue:

The Add-on Store formats publication and installation dates with Python's %x. NVDA sets the process locale to its interface language, so the Arabic interface selects the Saudi Arabic calendar and displays Hijri dates even when the user configured Windows to use Gregorian dates.

Description of user facing changes:

Publication and installation dates in the Add-on Store now follow the user's Windows regional and calendar settings instead of the NVDA interface language.

Description of developer facing changes:

A reusable formatDateForSystemLocale helper formats dates through the existing winKernel.GetDateFormatEx wrapper with LOCALE_NAME_USER_DEFAULT. All Add-on Store date display paths use this helper.

Description of development approach:

The change replaces %x in the Add-on Store model, list view model, and details control. This retains localized short-date formatting while allowing Windows—not NVDA's UI locale—to select the user's preferred locale and calendar.

Testing strategy:

• Reproduced with NVDA's process locale set to Arabic_Saudi Arabia: 21 July 2026 formatted through %x as 07/02/1448.
• With the same Arabic process locale, the new helper formats the date as 21/07/2026, matching this Windows user's configured regional and Gregorian calendar settings.
• Added a unit test confirming that the helper delegates to Windows with LOCALE_NAME_USER_DEFAULT and the supplied date.
• Ran 20 matching localization and Add-on Store unit tests successfully.
• Ran runlint.bat and runcheckpot.bat successfully.

Known issues with pull request:

None known.

Code Review Checklist:

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