On Mon, Apr 7, 2014 at 5:46 PM, Brian Wolff
No you don't get more consistency by moving
back to an experience
where you let the browser determine fonts. However you do get a
situation where things are more likely to work for non-latin scripts
(and other issues that have been brought up, if I understand
correctly). Consistency and actually working for all scripts are
separate goals. If you can't satisfy both, you're going to have to
make one take higher priority than the other. I personally consider
the "Actually working for all languages" to be much more important
consideration than consistency.
I totally agree. I don't see how there is any indication this is
functionally broken or a major regression across languages, keeping in mind
the necessity of ULS et al still. What major language-related bugs have
been raised that would not be present regardless for most default
I see some cases, such as CJK, where users may not prefer the serif
headings, since serifs look closer to a brush script in those languages
than they do in Latin languages. That doesn't seem to be what we're
discussing though? When it comes to the body font settings and language
support, we've been able to remove some local overrides. Some others, like
Persian, had Common.css overrides long before the new version was released.
The general state of affairs before *and* after is that there aren't
great-looking, freely-licensed fonts with support across all languages and
which are widely installed on our most popular OS/device combos. We're
making incremental improvements here.
Wikitech-l mailing list
I don't speak any non-latin languages, so I'm not competent to judge.
I based my comment on a large number of complaints I'm seeing.
Including Erwin Dokter's email earlier in this thread, and comments on
wiki like: "I really really hate it. New fonts are really awful for
non-latin languages."