The fonts(default and options) for each language is based on bug reports/requests from community.

Whether noto font can "replace" the current fonts for languages as requested by community is not really a question the team can answer.

See https://www.mediawiki.org/wiki/Universal_Language_Selector/WebFonts#Selection_of_fonts

But WMF Language Engineering team is in contact with Google team, we even had face to face meetings in 2012.

We do have a story card to add these fonts as optional fonts https://wikimedia.mingle.thoughtworks.com/projects/language_engineering/cards/3621 - of course this has to be done by per language investigation and communication with community.

(In reply to comment #1)

The fonts(default and options) for each language is based on bug
reports/requests from community.

This is not persuasive.

First, it is not always clear what is being requested. For example, the first request-url for Amiri cites https://bugzilla.wikimedia.org/41359. The request in comments #7 and #10 is simply for the font to be made available by the extension, not loaded automatically. But then there are comments #11, #16, and #18:

As there are problems with including the fonts. I request the extension to
be disabled, because it is of no use now on the AR wikis.

Hi, WebFonts might be causing long pages to overload; can it be made into
a gadget?

Now, the webfont extension is displaying the Amiri webfont for all users,
because of some rendering issues related to Windows perhaps, I suggest
showing the webfonts only for users who selected them.

Second, you did not anticipate the performance impact of loading web fonts, and thus could not have represented it fairly to the community. The requests from the community were thus made in ignorance of the trade-offs involved.

Third, with all due respect to the autonomy of, say, the Arabic Wikipedia, I do not think that they can decide how Arabic font should be rendered in articles on the French Wikipedia. In fact I would imagine that the requestors would be surprised to discover that their request was used to underwrite this decision. The Noto font family could be used on each wiki to provide support for all languages which are not the primary content language.

(In reply to comment #2)

First, it is not always clear what is being requested.

Second, you did not anticipate the performance impact of loading web fonts,
and
thus could not have represented it fairly to the community. The requests from
the community were thus made in ignorance of the trade-offs involved.

Third, with all due respect to the autonomy of, say, the Arabic Wikipedia, I
do
not think that they can decide how Arabic font should be rendered in articles
on the French Wikipedia. In fact I would imagine that the requestors would be
surprised to discover that their request was used to underwrite this
decision.

The first point is always a risk and it often takes endless back and forth communication and evaluations to come to some understanding. You would already know this. The languages other than the one for which the performance impact was already analysed, i.e. languages with open requests for fonts, we are going to rely heavily on the guidelines that Santhosh has been putting together:

https://www.mediawiki.org/wiki/Universal_Language_Selector/WebFonts#Selection_of_fonts

The Noto font family could be used on each wiki to provide support for all
languages which are not the primary content language.

This means the Noto fonts would also have to be evaluated similarly. If you think we could address things beyond the items in the previous link, you could suggest them directly on the page. It would be of immense help to add more perspectives. Thanks.

@Nemo, the script coverage document is out-of-date. You can see that it has massively expanded: https://code.google.com/p/noto/source/detail?r=237

(In reply to Ori Livneh from comment #4)

@Nemo, the script coverage document is out-of-date. You can see that it has
massively expanded: https://code.google.com/p/noto/source/detail?r=237

That's not very useful. Can we have a pretty table like these?

• https://www.gnu.org/software/freefont/coverage.html
• https://sourceforge.net/p/dejavu/code/HEAD/tree/trunk/dejavu-fonts/langcover.txt

(In reply to Nemo from comment #5)

That's not very useful. Can we have a pretty table like these?

• https://www.gnu.org/software/freefont/coverage.html *

https://sourceforge.net/p/dejavu/code/HEAD/tree/trunk/dejavu-fonts/langcover.
txt

If there isn't one already, perhaps the sources can be adapted: http://math.sut.ac.th/lab/software/texlive/texmf-dist/doc/fonts/gnu-freefont/tools/report/range_report.py

Found by chance today: https://wikimedia.mingle.thoughtworks.com/projects/language_engineering/cards/4421?version=2

CC Yurik given https://gerrit.wikimedia.org/r/#/c/165698/1 (http://unifoundry.com/unifont.html )
No response on https://code.google.com/p/googlefontdirectory/issues/detail?id=297 :(

In T61983#646308, @Nemo_bis wrote:

CC Yurik given https://gerrit.wikimedia.org/r/#/c/165698/1 (http://unifoundry.com/unifont.html )
No response on https://code.google.com/p/googlefontdirectory/issues/detail?id=297 :(

And https://code.google.com is now https://github.com/google/fonts/ , and your issue has been lost in the process.

In T61983#1384904, @jayvdb wrote:

And https://code.google.com is now https://github.com/google/fonts/ , and your issue has been lost in the process.

Reported: https://github.com/google/fonts/issues/65
We should probably not rely on upstream projects which trash bug reports, BTW.

Note that the Noto family now uses (in its latest versions) the SIL Open Font Licence (OFL) for all fonts, instead of the Apache Licence that was used only for generic scripts but not for all fonts already using OFL.

But it is still open sourced, free for use (at no cost), free for distribution (at no cost), free for derivations, and the OFL licence page has a FAQ saying explicitly is compatible with OSI licences, GNU licences (except the commericalisation of fonts alone, their inclusion in commercial products is allowed but people won't pay for the fonts themselves except the minimal delivery cost for physical supports, or network usage, or mailing costs, as already permitted since always by the GPL), MIT and BSD like licences.

Tge family is effectively sponsored by Google, but technically supervised by Monotype, with contributors from around the world signaling the issues and helping resolving the issues, or donating/enhancing glyphs for the project, or checking metrics and composition/layout for complex scripts, and helping to debug the hinting for low resolution devices, or improving the visual quality of strokes (notably the overall blackness, and readability with small tunings)

The whole collection is already available on the web with webfonts, and highly supported by Android devices (which now have better support for international text than Windows, including the support for colorful emojis, something that Windows still does not support in its native text renderers...)

The remaining issues are being solved, notably improving the monospace fonts for wider coverage, but in our wikis, data input using monospace fonts is now deprecating (it has never worked correctly for international text). As well the serif style still lays a bit behind (but this is true for most other fonts, and serif vs. sans-serif is non-sense for many scripts that have other distinctions (notably Arabic which is fully supported by Noto n its two major typographic traditions)

The coverage for CJK in Noto is really excellent, including with 7 weights (which are preferably selected instead of using straight vs. italic styles, as italic is really poor in CJK), and full support for 4 linguistic variants (SC, TC, JP and KR).

There are still issues in some complex South-East Asian scripts, but much less than other fonts. Many minority languages were tested for each script and not just a few major languages.

These fonts shjould be made avbailable on Wiki servers using webfont delivery or instant use on many PCs. Webfonts are supported by all major browsers, except very old unmaintained ones (such as IE<6 on old unsupported versions of Windows). All modern smartphones and tablets support these webfonts (and there's also the possibility to install them)

Beisde the opensource project there's a dedicated presentation page for the fonts:
https://www.google.com/get/noto/
see the FAQ, licence, coverage pages including maps and lists of languages.

The remaining issues are being solved, notably improving the monospace fonts for wider coverage, but in our wikis, data input using monospace fonts is now deprecating (it has never worked correctly for international text).

I am not aware of any explicit deprecation process.

These fonts shjould be made avbailable on Wiki servers using webfont delivery or instant use on many PCs.

This is likely not going to happen. We had to disable webfonts by default (with some exceptions) some years ago because Ops considered the bandwidth use too high and Performance considered the delay in page rendering too long and we were not able to make our case that it does not matter if the user cannot read the page.

To not sound like I am shifting the blame: our code could have been faster and better at targeting the users who need it most. But at that point we also had to consider other priorities. See also T135465: Stop tofu detection and applying webfonts.

Also, technology has moved on and nowadays it could be easier to address the issues mentioned above, but it also means more users are getting sufficient font support out of the box with their devices. It's hard to justify working on this task when we are not getting a stream of "I cannot read this page" complaints – which does not mean it does not happen, only that it doesn't get reported.

Perhaps, if design wanted to consider unified typography across languages with the help of webfonts technology, this could be an option.

On a related note, per T184664 Noto fonts will soon be available when rendering SVG images.

please see T184664#3895870

noto fonts are now installed on mediawiki app servers

In T61983#3895884, @Dzahn wrote:

please see T184664#3895870

noto fonts are now installed on mediawiki app servers

As this is now the case, is there anything else holding up the inclusion of Noto fonts as possible ULS webfonts?

noto fonts are now installed on mediawiki app servers

As this is now the case, is there anything else holding up the inclusion of Noto fonts as possible ULS webfonts?

These things are unrelated and don't affect each other.