| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
i18n(ar): complete the Arabic locale and localize dates and prices Arabic now has full key coverage: 0 missing, and the 20 values still matching English are brand names and URLs. Getting there took three passes, because the gaps had three different causes. 305 keys existed but held untranslated English — the entire Library feature among them, which is why it read as completely untranslated. Another 221 were absent from en.json altogether: the code called t() with a key no locale had, so i18next fell through to the English defaultValue in the call and rendered that forever, in every language. Those are added to en.json too, so the other twenty locales can now translate them. And the onboarding sidebar rendered step titles straight from the English step definitions instead of through t(), while its sibling component did the same lookup correctly. Dates and numbers move to lib/format, which loads the dayjs locale centrally. That fixes a bug predating this branch: all twelve dayjs call sites extended relativeTime locally and none imported a locale, so "2 hours ago" was English in all 22 languages. Several call sites also hardcoded 'en-US', assignment timestamps used 'en-UK' — not a valid tag, so it silently fell back to the browser default — and the thumbnails branched on `i18n.language === 'fr' ? 'fr-FR' : 'en-US'`, giving French dates to French and English to everyone else. Numerals are pinned to Latin digits and the Gregorian calendar for Arabic and Persian, behind one function. Intl.NumberFormat('ar') resolves to Arabic-Indic digits on most ICU builds and ar-SA defaults to the Hijri calendar; neither suits a screen where prices and analytics sit next to Latin-digit values from the API, and Arabic regions are split on this anyway. Month names and relative times still localize. Also translates the sixteen aria-labels in the dashboard navigation, which were the last hardcoded strings in those files — screen reader users were hearing English labels in every language. | 1 个月前 | |
i18n(ar): complete the Arabic locale and localize dates and prices Arabic now has full key coverage: 0 missing, and the 20 values still matching English are brand names and URLs. Getting there took three passes, because the gaps had three different causes. 305 keys existed but held untranslated English — the entire Library feature among them, which is why it read as completely untranslated. Another 221 were absent from en.json altogether: the code called t() with a key no locale had, so i18next fell through to the English defaultValue in the call and rendered that forever, in every language. Those are added to en.json too, so the other twenty locales can now translate them. And the onboarding sidebar rendered step titles straight from the English step definitions instead of through t(), while its sibling component did the same lookup correctly. Dates and numbers move to lib/format, which loads the dayjs locale centrally. That fixes a bug predating this branch: all twelve dayjs call sites extended relativeTime locally and none imported a locale, so "2 hours ago" was English in all 22 languages. Several call sites also hardcoded 'en-US', assignment timestamps used 'en-UK' — not a valid tag, so it silently fell back to the browser default — and the thumbnails branched on `i18n.language === 'fr' ? 'fr-FR' : 'en-US'`, giving French dates to French and English to everyone else. Numerals are pinned to Latin digits and the Gregorian calendar for Arabic and Persian, behind one function. Intl.NumberFormat('ar') resolves to Arabic-Indic digits on most ICU builds and ar-SA defaults to the Hijri calendar; neither suits a screen where prices and analytics sit next to Latin-digit values from the API, and Arabic regions are split on this anyway. Month names and relative times still localize. Also translates the sixteen aria-labels in the dashboard navigation, which were the last hardcoded strings in those files — screen reader users were hearing English labels in every language. | 1 个月前 | |
refactor(web): convert physical direction utilities to logical ones Machine-applied output of scripts/codemod-logical.mjs across the app, plus the handful of transforms it cannot do safely. ml-/mr- become ms-/me-, pl-/pr- become ps-/pe-, left-/right- become start-/end-, and text-left, border-l and the rounded corners follow. This is a pure rename: every pair emits identical CSS under dir=ltr, verified against tailwindcss 4.2.1, so left-to-right rendering is unchanged and any visual diff there is a bug rather than a judgement call. Transforms carry a physical sign, so renaming them is wrong. Toggle knobs, hover nudges and sliding panels get explicit rtl: pairs, and motion x-offsets multiply by the direction factor from useDirection. The step wizard folds text direction into its slide axis so "next" always moves toward the inline end. Flyout menus needed a real fix rather than a rename. HoverMenu positioned itself with `left: rect.right + 8`, which is fine with the sidebar on the left but placed the menu past the viewport once the sidebar moved to the right edge — in Arabic the menus simply did not appear. It now anchors to whichever edge it grows away from, which also avoids needing the menu's width before it renders. The admin list tooltips had the same bug. Inline styles stay physical wherever the value comes from a measured DOM rect: those are already in viewport coordinates, so converting them would flip twice. Only static design offsets moved to logical properties. Also removes the dead nx-* classes on the 404 page. They came from a Nextra template and never existed in this project's Tailwind build, so they emitted nothing — including the ltr:/rtl: pair, which looked like RTL support but was not. | 1 个月前 | |
refactor(web): convert physical direction utilities to logical ones Machine-applied output of scripts/codemod-logical.mjs across the app, plus the handful of transforms it cannot do safely. ml-/mr- become ms-/me-, pl-/pr- become ps-/pe-, left-/right- become start-/end-, and text-left, border-l and the rounded corners follow. This is a pure rename: every pair emits identical CSS under dir=ltr, verified against tailwindcss 4.2.1, so left-to-right rendering is unchanged and any visual diff there is a bug rather than a judgement call. Transforms carry a physical sign, so renaming them is wrong. Toggle knobs, hover nudges and sliding panels get explicit rtl: pairs, and motion x-offsets multiply by the direction factor from useDirection. The step wizard folds text direction into its slide axis so "next" always moves toward the inline end. Flyout menus needed a real fix rather than a rename. HoverMenu positioned itself with `left: rect.right + 8`, which is fine with the sidebar on the left but placed the menu past the viewport once the sidebar moved to the right edge — in Arabic the menus simply did not appear. It now anchors to whichever edge it grows away from, which also avoids needing the menu's width before it renders. The admin list tooltips had the same bug. Inline styles stay physical wherever the value comes from a measured DOM rect: those are already in viewport coordinates, so converting them would flip twice. Only static design offsets moved to logical properties. Also removes the dead nx-* classes on the 404 page. They came from a Nextra template and never existed in this project's Tailwind build, so they emitted nothing — including the ltr:/rtl: pair, which looked like RTL support but was not. | 1 个月前 | |
i18n(ar): complete the Arabic locale and localize dates and prices Arabic now has full key coverage: 0 missing, and the 20 values still matching English are brand names and URLs. Getting there took three passes, because the gaps had three different causes. 305 keys existed but held untranslated English — the entire Library feature among them, which is why it read as completely untranslated. Another 221 were absent from en.json altogether: the code called t() with a key no locale had, so i18next fell through to the English defaultValue in the call and rendered that forever, in every language. Those are added to en.json too, so the other twenty locales can now translate them. And the onboarding sidebar rendered step titles straight from the English step definitions instead of through t(), while its sibling component did the same lookup correctly. Dates and numbers move to lib/format, which loads the dayjs locale centrally. That fixes a bug predating this branch: all twelve dayjs call sites extended relativeTime locally and none imported a locale, so "2 hours ago" was English in all 22 languages. Several call sites also hardcoded 'en-US', assignment timestamps used 'en-UK' — not a valid tag, so it silently fell back to the browser default — and the thumbnails branched on `i18n.language === 'fr' ? 'fr-FR' : 'en-US'`, giving French dates to French and English to everyone else. Numerals are pinned to Latin digits and the Gregorian calendar for Arabic and Persian, behind one function. Intl.NumberFormat('ar') resolves to Arabic-Indic digits on most ICU builds and ar-SA defaults to the Hijri calendar; neither suits a screen where prices and analytics sit next to Latin-digit values from the API, and Arabic regions are split on this anyway. Month names and relative times still localize. Also translates the sixteen aria-labels in the dashboard navigation, which were the last hardcoded strings in those files — screen reader users were hearing English labels in every language. | 1 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 |