| 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 个月前 |