Summary
Dynamic dates on the site are formatted with the visitor's browser/OS locale instead of the site's configured language (en). On a non-English browser they render in the wrong language. The compatibility table's sort order has the same problem through localeCompare.
All three cases rely on the JavaScript Intl default locale, while the site is single-locale en (i18n in docusaurus.config.js).
Observed
Downloads > Stable Releases, viewed in a Hungarian browser. Release dates render in Hungarian ("2026. augusztus 28., péntek 22") rather than English:
Affected code
1. Release list dates (downloads page)
|
const dateString = date.toLocaleDateString(undefined, { |
date.toLocaleDateString(undefined, {...}). A undefined locale means the runtime default, i.e. the browser/OS language.
2. Compatibility "Tested on" tooltip
|
content={`Tested on - ${date.toLocaleString(DateTime.DATE_FULL)}`} |
date.toLocaleString(DateTime.DATE_FULL) (Luxon). No locale passed, so it falls back to the runtime default.
3. Compatibility table sort order
|
compatRows.sort((a, b) => a.title.localeCompare(b.title)); |
a.title.localeCompare(b.title). No locale passed, so row collation shifts with the visitor's locale.
Proposed fix
Read the site locale once from useDocusaurusContext().i18n.currentLocale and pass it to each call:
- downloads:
toLocaleDateString(locale, {...})
- compat tooltip:
toLocaleString(DateTime.DATE_FULL, { locale })
- compat sort:
localeCompare(b.title, locale)
Sourcing from i18n.currentLocale keeps the value tied to the site config instead of a hardcoded string, so it tracks any future locale change.
PRs not open
Given the recent LLM contribution policy, as a new contributor, I have not opened a PR, since I used Claude for this. The proposed changeset is available on my fork for reference: https://github.com/dio-gh/pcsx2-net-www/tree/fix/release-date-locale
Summary
Dynamic dates on the site are formatted with the visitor's browser/OS locale instead of the site's configured language (
en). On a non-English browser they render in the wrong language. The compatibility table's sort order has the same problem throughlocaleCompare.All three cases rely on the JavaScript
Intldefault locale, while the site is single-localeen(i18nindocusaurus.config.js).Observed
Downloads > Stable Releases, viewed in a Hungarian browser. Release dates render in Hungarian ("2026. augusztus 28., péntek 22") rather than English:
Affected code
1. Release list dates (downloads page)
pcsx2-net-www/src/pages/downloads/index.js
Line 34 in 486a4b4
date.toLocaleDateString(undefined, {...}). Aundefinedlocale means the runtime default, i.e. the browser/OS language.2. Compatibility "Tested on" tooltip
pcsx2-net-www/src/pages/compat/index.js
Line 229 in 486a4b4
date.toLocaleString(DateTime.DATE_FULL)(Luxon). No locale passed, so it falls back to the runtime default.3. Compatibility table sort order
pcsx2-net-www/src/pages/compat/index.js
Line 43 in 486a4b4
a.title.localeCompare(b.title). No locale passed, so row collation shifts with the visitor's locale.Proposed fix
Read the site locale once from
useDocusaurusContext().i18n.currentLocaleand pass it to each call:toLocaleDateString(locale, {...})toLocaleString(DateTime.DATE_FULL, { locale })localeCompare(b.title, locale)Sourcing from
i18n.currentLocalekeeps the value tied to the site config instead of a hardcoded string, so it tracks any future locale change.PRs not open
Given the recent LLM contribution policy, as a new contributor, I have not opened a PR, since I used Claude for this. The proposed changeset is available on my fork for reference: https://github.com/dio-gh/pcsx2-net-www/tree/fix/release-date-locale