1680108 - Investigate the localization impacts of using a non-system font for the browser UI.

Status: RESOLVED FIXED

(Firefox :: Theme, task)

Description

[Mike Conley (:mconley) (:⚙️)]

Some things to consider:

Not all fonts are created equal. Vietnamese uses Latin characters with diacritics that are missing from the Metropolis font face. There are certainly other languages that use the Latin characters that will find that Metropolis doesn't contain the characters that they need.

In theory, we could fall back to a system UI font if we detect that the user is running a browser build for a locale that doesn't match an "allow list". Or perhaps we should match on the OS's locale. It's unclear.

This solution, however, falls over a bit when we consider that users might visit sites in locales that the built-in font face doesn't support. Suppose we use Metropolis for tab titles, and the user visits a Vietnamese site with characters in the <title> that don't exist in Metropolis. What do we do? We run into a similar situation with entries in the Library/Bookmarks/History menus, where we present text from a site.

If we used Inter instead of Metropolis, would our situation improve? This bug is about performing the research to evaluate the localization impact of switching to something like Inter or Metropolis as the default UI font.

One thing to consider, paraphrasing jfkthame:

[This proposal would] probably work fine for en-US and European people, so the (user) pain when there are rough edges will be mostly felt by already-marginalized communities whose voice we [already] don't hear very well.

So we need to be really thorough here.

Comment 1

[Francesco Lodolo [:flod]]

This solution, however, falls over a bit when we consider that users might visit sites in locales that the built-in font face doesn't support.

For this specific aspect, one other thing that might be worth considering is that more than 60% of en-US users (70% if you look at unique users) is located outside of US. So, extensive use of content in different languages is a given.

I've tried locally to create a webpage, showing the strings from about:rights across several locales, but I'm not sure how helpful that is to assess the issue. When a character is missing, it falls back to the next font in the font-family rule, and I used a very bold OpenSans for that. Metropolis fails on a lot of characters, including some used by tier1 languages (e.g. «» in French). Inter seems to be a lot better, but it doesn't support all languages either.

Comment 2

[Mike Conley (:mconley) (:⚙️)]

Hey flod,

If you want to try to demonstrate / develop some stress tests, I have a patch that updates both the UI and about:home to Inter as the default font here: https://hg.mozilla.org/try/rev/f1e3781b11539757f125a0a8dd794d0b21466908

Comment 3

[Mike Conley (:mconley) (:⚙️)]

Hey flod, jfkthame, are you able to think of any cases using the patch in comment 2 that might fall over for us, localization-wise?

Comment 4

[Jonathan Kew [:jfkthame]]

Not a localization-related point, but I'd be surprised if fragments like this:

 .tabbrowser-tab {
-  font: message-box;
+  font: "Inter", message-box;
   border: none;
 }

work as intended, because the font: shorthand doesn't accept just a font-family name, it needs a font longhand (including at least a size as well), or a system font keyword such as message-box. So I'd expect this property to be dropped as invalid.

Looking a bit at Inter, I'm a bit concerned whether it has been adequately reviewed by a wide enough range of non-European readers with different requirements for accents and other "unusual" characters. To my eye, the "horn" diacritic, for example, seen in words like "Lời hứa" (the beginning of the page title of https://www.mozilla.org/vi/firefox/privacy/, so I noticed it on about:home after visiting there) is so tiny as to be almost invisible in the Activity Stream items.

Also wondering how things like page titles on about:home will look if they're in non-Latin scripts (e.g. Arabic or Hebrew pages) where the title includes some "common" characters such as punctuation or numerals; those will get pulled from Inter, while the rest of the text will use the system's font, which may not match well. I'll try to look at some examples and see how they go.

Comment 5

[Francesco Lodolo [:flod]]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #2)

If you want to try to demonstrate / develop some stress tests, I have a patch that updates both the UI and about:home to Inter as the default font here: https://hg.mozilla.org/try/rev/f1e3781b11539757f125a0a8dd794d0b21466908

Is there a try build for this, possibly for macOS? One way to test it could be to use a language pack, although few locales are complete at this point.

One other concern is that we're not very good at catching issues in Nightly/Beta for localized build, because the population is too small. Can you think of a system to implement this that would allow us to quickly disable it, or disable it for specific locales?

Comment 6

[Mike Conley (:mconley) (:⚙️)]

(In reply to Francesco Lodolo [:flod] from comment #5)

Is there a try build for this, possibly for macOS? One way to test it could be to use a language pack, although few locales are complete at this point.

Here you go: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Yjh-GV15TR2t00jsRfSSwg/runs/0/artifacts/public/build/target.dmg

Comment 7

[Mike Conley (:mconley) (:⚙️)]

(In reply to Jonathan Kew (:jfkthame) from comment #4)

Not a localization-related point, but I'd be surprised if fragments like this:

 .tabbrowser-tab {
-  font: message-box;
+  font: "Inter", message-box;
   border: none;
 }

work as intended, because the font: shorthand doesn't accept just a font-family name, it needs a font longhand (including at least a size as well), or a system font keyword such as message-box. So I'd expect this property to be dropped as invalid.

Yeah, I think that's a leftover from a less aggressive version of the patch I was writing. I ended up using a * rule, which applies the font face universally across the UI, and I think I probably should have just removed this.

Looking a bit at Inter, I'm a bit concerned whether it has been adequately reviewed by a wide enough range of non-European readers with different requirements for accents and other "unusual" characters. To my eye, the "horn" diacritic, for example, seen in words like "Lời hứa" (the beginning of the page title of https://www.mozilla.org/vi/firefox/privacy/, so I noticed it on about:home after visiting there) is so tiny as to be almost invisible in the Activity Stream items.

Thanks - that's exactly the sort of thing that I'm hoping to suss out with this bug. I'm hoping we can identify concrete examples of these concerns with Inter to present to UX and Product.

Comment 8

[Francesco Lodolo [:flod]]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #6)

(In reply to Francesco Lodolo [:flod] from comment #5)

Is there a try build for this, possibly for macOS? One way to test it could be to use a language pack, although few locales are complete at this point.

Here you go: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Yjh-GV15TR2t00jsRfSSwg/runs/0/artifacts/public/build/target.dmg

Doesn't seem to work on 10.15.7 (19H15). The icon has a prohibition sign overlayed, and it seems to require macOS 11.0 or later.

Comment 9

[Mike Conley (:mconley) (:⚙️)]

:/ Bizarre... I presume you've tried bypassing the macOS security check in System Preferences?

You might need to just build the patch locally: https://hg.mozilla.org/try/rev/f1e3781b11539757f125a0a8dd794d0b21466908

Comment 10

[Mike Conley (:mconley) (:⚙️)]

Ah - I may have accidentally given you the link to the AArch64 build. Try this one:

https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/I9SVX-KvTP-NvVwlb2ApEA/runs/0/artifacts/public/build/target.dmg

Comment 11

[Francesco Lodolo [:flod]]

Attachment: Application menu

I've tried Vietnamese, since it's probably one of the hardest on the font.

Line height or spacing seems different, with Inter using up more space. IIRC, that happens also for English. In the picture I've aligned the first separator.

As Jonathan pointed out, some accents seem really tiny (ẩ, ổ), but only a native speaker could tell if they're readable enough.

Comment 12

[Francesco Lodolo [:flod]]

Attachment: Full home with addressbar

Weirdly enough, Inter seems to take up significantly less vertical space in the address bar?

Comment 13

[Francesco Lodolo [:flod]]

BTW, if you want to test a language on that try build, you can try adding a langpack (some strings might be missing, but it shouldn't completely explode)
https://mozilla-l10n.github.io/documentation/products/firefox_desktop/firefox_l10n_faqs.html#how-can-i-test-a-different-locale

Comment 14

[Francesco Lodolo [:flod]]

Trying asking a couple of our Vietnamese localizers to take a look at the screenshots.

The two screenshots above show the menu displayed with a different font than default. Could you tell us if you could spot any issue, or if the font is readable?

Comment 15

[Minh Nguyễn]

Attachment: Tầng một.png

Above: “Tầng” in SF UI
Below: “Tầng” in Metropolis

In Metropolis, a grave is positioned above and to the left of a circumflex instead of above and to the right. This is a valid treatment often seen in handwriting and fonts designed specifically for Vietnamese. However, it will run into certain preceding capital letters, such as T. Either there needs to be more letter spacing or the grave needs to be positioned higher. Placing the grave above and to the right doesn’t look as polished, but it remains reliably readable and it’s still more sophisticated than the Times New Roman approach of stacking the acute directly above the circumflex.

Comment 16

[Minh Nguyễn]

Attachment: đắng đằng đẳng.png

Above: “đắng đằng đẳng” in SF UI
Below: “đắng đằng đẳng” in Metropolis

On their own, the acute, grave, and hook require squinting. Above a breve, they’re virtually indistinguishable. Relatively few pan-Latin fonts pass this stress test, since they tend to have smaller diacritics than Vietnamese specialty fonts. Still, it would be great to have parity with SF UI, which is (barely) discernible when set at the same size as the tab in this screenshot.

Comment 17

[Minh Nguyễn]

(In reply to Minh Nguyễn from comment #15)

Created attachment 9194166 [details]
Tầng một.png

Above: “Tầng” in SF UI
Below: “Tầng” in Metropolis

Sorry, I meant Inter above, not Metropolis. I didn’t realize multiple fonts had been considered.

Overall, my general impression is that the font metrics leave it somewhat less readable than macOS’s default SF UI, but the shapes aren’t unreasonable stylistically. The Vietnamese alphabet leaves very little room for maneuvering at the small sizes used in Firefox’s UI. If there’s any chance of tweaking the font’s metrics to better distinguish the grave, hook, and acute tone marks, it would be worth taking the time to get those details right, even at the expense of consistency. That said, I’m not a native speaker of Vietnamese, so I’d be interested in seeing Thanh’s feedback too.

Comment 18

[Mike Conley (:mconley) (:⚙️)]

We have concluded that there are a number of potential localization impacts from switching the default font in the main browser UI. In particular, the fallback behaviour when characters are missing from Inter can result in a regression in readability for certain locales / characters. We will not be doing this for now.