Created attachment 301468 [details] SCREENSHOT (RTL) I believe we need to put all user-visible numbers without special meaning (like HTTP 404) through the Intl API, which produces hindi numbers as expected when using Arabic. See dashboard screenshot.
<rdar://problem/30508263>
Are the numerals on the screenshot really "hindi numbers"? I’m trying to educate myself and these look like Eastern Arabic to me. https://en.wikipedia.org/wiki/Eastern_Arabic_numerals https://en.wikibooks.org/wiki/Hindi/Numbers
(In reply to comment #2) > Are the numerals on the screenshot really "hindi numbers"? I’m trying to > educate myself and these look like Eastern Arabic to me. > > https://en.wikipedia.org/wiki/Eastern_Arabic_numerals > https://en.wikibooks.org/wiki/Hindi/Numbers Oops, you are right.
On macOS, number fields with steppers also produce these numerals. So in the Settings tab we need to support that if WebKit supports it, and otherwise leave in western numerals. As for the Visual Styles Sidebar, we should probably stick with western numerals for anything related to CSS because the underlying assumption is that the editors map directly to CSS property declarations. There are also some other values not localized properly like Zoom 100%, which should appear as %100 in Turkish locales. We can fix that in a separate bug if needed.
Created attachment 304681 [details] Patch Is there a good way to test this? I tried setting my system language to Arabic and it didn't really change anything.
(In reply to comment #5) > Created attachment 304681 [details] > Patch > > Is there a good way to test this? I tried setting my system language to > Arabic and it didn't really change anything. You need to do this, then relaunch Safari. Engineering builds do not use UIString localizations, but the JS Intl APIs will pick up the new LC_LOCALE and format number differently. It's easiest to see some numerals by making a timeline recording.
Created attachment 304760 [details] Patch
Comment on attachment 304760 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=304760&action=review r=me > Source/WebInspectorUI/UserInterface/Views/DataGridNode.js:387 > + return "\u200b"; // Zero width space to keep the cell from collapsing. Maybe we should make a named variable for this in Utilities.js (like emDash). > Source/WebInspectorUI/UserInterface/Views/TimelineOverview.js:754 > - this._timelineRuler.formatLabelCallback = (value) => value.toFixed(0); > + this._timelineRuler.formatLabelCallback = (value) => value.maxDecimals(0).toLocaleString(); I understood all the other changes, but why the toFixed -> maxDecimals here?
Comment on attachment 304760 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=304760&action=review >> Source/WebInspectorUI/UserInterface/Views/DataGridNode.js:387 >> + return "\u200b"; // Zero width space to keep the cell from collapsing. > > Maybe we should make a named variable for this in Utilities.js (like emDash). OK. There are some bidi override characters we might need to use too. >> Source/WebInspectorUI/UserInterface/Views/TimelineOverview.js:754 >> + this._timelineRuler.formatLabelCallback = (value) => value.maxDecimals(0).toLocaleString(); > > I understood all the other changes, but why the toFixed -> maxDecimals here? I found it clearer to understand.
Committed r214405: <http://trac.webkit.org/changeset/214405>