Please note that bug 49935, bug 50836 and bug 33018 might be related but are not the same! They are probably adding to the delayed page load I'm noticing but fixing those bugs wont solve the underlying problem of needlessly loaded webfonts described in this bug!

This looks like a duplicate of bug 49935, which also started with a report about RecentChanges.

Have you read comment 1 Nemo? I explicitly stated it is *not* a duplicate of those bugs.

The linked bugs are about optimizing performance of loading of webfonts.
This bug is about not loading them at all if not necessary.

While the existing bugs might account for suboptimal code, they can't speed up font loading itself (which might take considerable time on slow connections and waste valuable data volume on limited/expensive mobile connections).

(In reply to comment #3)

Have you read comment 1 Nemo?

Not before writing mine; I had a mid-air collision, as timestamp hints.

I explicitly stated it is *not* a duplicate of
those bugs.

That's not enough to actually *make* it not a duplicate ;) but devs will know.

(In reply to comment #0)

Actually the language names are shown fine without the need for
additional fonts, that's how it worked for years now.

I can imagine that this would be the statement to be challenged - I always had some squares etc. displayed for some rather exotic languages/scripts, so I'm not sure if the loading is really "needless" if those are now displayed correctly.

If I get you correctly, I'm tempted to change the bug summary from "ULS loads many webfonts needlessly on page load" to "ULS should not load webfonts only because of entries in the 'Other languages' list" (which would enhance funtionality and turn this into an enhancement request).

No, I think your proposed summary doesn't fit my concerns well. Actually I have several reasons for that:

1. As pointed out I'd also be happy (if not happier) with a more general solution (e.g. turning of usage of webfonts completely as a user setting, or even solving bug 46306).
2. There are also other cases were loading of webfonts would not be really necessary, e.g. pages which include many translations (like [1]), which are hidden from the user anyway but get initially loaded (including webfonts) on page load.
3. Since this will always delay page load (even after the performance issues described in the mentioned bugs are solved) and potentially wastes bandwidth and data volume for many users (as pointed out in comment 3), this is no enhancement but should be considered a bug.

[1] http://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard/User_problems

I see. Would the proposal in bug 51102 tackle most of this problem?

If it was implemented in a way that webfonts can be disabled for all languages at the same time this would be an appropriate solution I assume.

Since I'm not familiar with the implementation details of ULS:
Would the proposed solution in bug 51102 (allow to select if and what webfont is used for HTML elements with lang="xy" attribute set) disable webfonts everywhere in the UI or are there places webfonts are applied by ULS where this would not suffice?

I don't think there is consensus that loading webfonts for interlanguage links is always useless.

I see few options:

1. do nothing
2. exclude those elements from webfonts (there is similar system as for input methods)
3. produce a special small font that contains all the glyphs needed to display all the native language names

Both 2) and 3) are problematic because there are many other places besides interlangugea links where language names are present (the many non ULS language selectors, translatable pages etc.). Those would need continuous maintenance.

I would prefer 1), since it is simplest and has the least amount of maintenance needed. If the reason for creating this bug is that loading the fonts is slow, we can fix this by improving the performance of ULS (one performance fix was already deployed today).

I would dupe this to bug 50836.

We're going to develop a font that will be able to display all the autonyms used in ULS, including autonyms used in MediaWiki. This will reduce the number of web fonts that have to be loaded for pages with many interlanguage links, and will also ensure a complete display of the currently used autonyms in ULS.

Tracked as https://mingle.corp.wikimedia.org/projects/internationalization/cards/1865. No guarantees on delivery yet, because it's not planned for development, but I think that in about two months we should have something for this.

Going to dupe to bug 40874.

• This bug has been marked as a duplicate of bug 40874 ***

I tend to reopen this bug because the autonyms were only part of the problem and I used this list only as an example since it was most obvious.

Actually(especially on Commons) there are many other places were various translations of the same text are offered by various translation templates. Most of the time one is only interested in his/her native language (or maybe English), therefore loading of webfonts wouldn't be necessary in this case either. The proposed solution for bug 40874 won't solve the problem, though.

The easiest solution would still be to either

• offer an option to completely disable ULS when the user knows he does not need it (bug 46306)
• offer an option to easily disable all webfonts (bug 51102)

To account for the fact that the newly developed font will mitigate the worst part (loading of almost all webfonts at one time when visiting a page with many translations) I lowered the importance of this bug.

I'm told this was partially fixed.

(In reply to comment #9)

I see few options:

1. do nothing
2. exclude those elements from webfonts (there is similar system as for input

methods)

3. produce a special small font that contains all the glyphs needed to

display
all the native language names

(2) was done, as far as I understand.
https://ganglia.wikimedia.org/latest/graph.php?c=Bits%20caches%20esams&m=cpu_report&r=custom&s=by%20name&hc=4&mc=2&cs=9%2F19%2F2013%2012%3A3&ce=9%2F19%2F2013%2019%3A59&st=1379658930&g=network_report&z=medium is the effect of https://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Log&diff=83904&oldid=83899 i.e. https://gerrit.wikimedia.org/r/#/c/85014/ which deployed https://gerrit.wikimedia.org/r/#/c/84779/ i.e.
https://github.com/wikimedia/jquery.webfonts/commit/e71774efe38e0638eb6b847f27d207314ca6c0e8
https://github.com/wikimedia/jquery.webfonts/commit/0cbf6df025363e6917c29949b149a69d625984ad
https://github.com/wikimedia/jquery.webfonts/commit/4b646585071b9af8de34b460e801179b56eae76c
https://github.com/wikimedia/jquery.webfonts/commit/82dda43f8b6d39cc372833070524c66f7a3aea06
among which the commit(s) in question must be.

Oh, and (3) is tracked at bug 40874 so we can close this AFAICS.

(In reply to comment #13)

I'm told this was partially fixed.

(In reply to comment #9)

I see few options:

1. do nothing
2. exclude those elements from webfonts (there is similar system as for input

methods)

3. produce a special small font that contains all the glyphs needed to

display
all the native language names

(2) was done, as far as I understand.

I found a more detailed explanation in the last [[mw:MLEB]] announcement: «Web fonts are no longer loaded for autonyms in the interlanguage area. This is a temporary change to improve performance; a more comprehensive fix may be done in the future.»