Bug 168290 – Web Inspector: RTL: number scripts are used inconsistently throughout the UI

• Status: RESOLVED
• Resolution: FIXED
• Component: Web Inspector

[Blaze Burg]

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.

[Radar WebKit Bug Importer]

<rdar://problem/30508263>

[Nikita Vasilyev]

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

[Blaze Burg]

(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.

[Blaze Burg]

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.

[Devin Rousso]

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.

[Blaze Burg]

(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.

[Blaze Burg]

Created attachment 304760 [details]
Patch

[Joseph Pecoraro]

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?

[Blaze Burg]

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.

[Blaze Burg]

Committed r214405: <http://trac.webkit.org/changeset/214405>