https://bugzilla.wikimedia.org/show_bug.cgi?id=56433
Ori Livneh <o...@wikimedia.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
CC| |o...@wikimedia.org
Resolution|WONTFIX |---
--- Comment #11 from Ori Livneh <o...@wikimedia.org> ---
(In reply to comment #10)
> (In reply to comment #8)
>
> > I suppose my comment was ambiguous. Do you think UniversalLanguageSelector
> > (ULS) is currently in good enough shape, with acceptable performance for
> > Wikimedia wikis?
>
> I do think it's fine to keep ULS deployed and to iteratively improve it, so
> closing as WONTFIX (if new information surfaces that justifies at least a
> discussion about that option, feel free to reopen).
Reopening, in light of bug 59958.
UniversalLanguageSelector's strategy is to search the document for occurrences
of nonlatin text and to load an appropriate font for each alphabet it
encounters, minus some manual exemptions. The criterion employed by
UniversalLanguageSelector is: if there exists a class of users for which the
text may not render correctly, load the font.
Other approaches exist. Instead of loading fonts automatically, you could
provide a prominent user interface element that the user may click on to
indicate that some text is not rendering correctly. You would then load the
font and set a cookie to make the font-loading behavior stick. This approach
would eliminate false positives -- that is, cases in which ULS decides to load
fonts even though they are not required or desired. It would also mean that
users that have configured a specific local font for their language would not
need to update their preferences to indicate that their choice should not be
overridden.
Another approach would be to use information available at run-time to determine
the probability that a user requires additional fonts to render text on the
page. This would entail checking whether the user-agent string matches against
a list of platforms which are known to require support. It could also entail
using JavaScript to programmatically inspect the appearance of text on the page
to determine which alphabets may require additional support before they can be
displayed correctly.
The strategy of these alternative approaches is to do nothing by default before
establishing some probable cause. This minimizes the impact on page performance
and appearance by restricting the loading of fonts to the subset of users that
plausibly require them.
The ULS team chose the first, blanket approach, because it is easiest to
implement. It is also easy to see that it avoids false negatives. If you load
the fonts for everybody, you can be sure you didn't miss anyone.
The choice was predicated on the assumption that the impact of loading fonts
where they are not needed would be minimal. There appears to have been no
serious attempt to validate this assumption by quantifying the impact on
usability and performance. We know now that the impact was not assessed
correctly, because (to cite one example) it saturated bandwidth on the
production cluster, requiring repeated manual interventions.
The need to quantify the impact has not gone away. My contention is that the
"when in doubt, load font" strategy taken by UniversalLanguageSelector is the
wrong strategy to take, and that its impact on user experience is severe.
I therefore ask for the team's permission and support to disable font loading
temporarily, so we can collect enough data to estimate the impact of
UniversalLanguageSelector on site performance. This would provide us with the
data we need to determine whether the extension's architecture needs to be
revisited.
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
