WebFonts must load content language's font not interface lang's font
Closed, InvalidPublic
Actions

Assigned To

None

Authored By

	Logicwiki
	Dec 28 2011, 4:41 PM

Description

I use Tamil interface on all wikis. When i visit Oriya wiki logged in, the webfonts menu shows tamil fonts instead of Oriya ones. I think its safe to assume that user who has chosen non English interface, has the particular languages' fonts installed locally and WebFonts must load based on langauge on page(by default,use default lang of wiki).

Otherwise like Narayam, it must support both userlang and wikilang, but wonder if thats needed really. I prefer the first option.

Version: unspecified
Severity: normal

Details

Reference: bz33401

	Title	Reference	Author	Source Branch	Dest Branch
	optimize_revision_T354015.py: New change	repos/sre/schema-changes!7	marostegui	T354015	main

Customize query in GitLab

Event Timeline

• bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:59 PM

• bzimport added projects: MediaWiki-extensions-WebFonts, I18n.

• bzimport set Reference to bz33401.

• bzimport added a subscriber: Unknown Object (MLST).

Logicwiki created this task.Dec 28 2011, 4:41 PM

I think its safe to assume that user who has chosen non English interface

to be read as

I think its safe to assume that user who has chosen non English / "non wiki default content lang" interface

Let's agree on the basics here: when there is a "lang" tag, and web fonts is active, it should apply the appropriate font for each supported and tagged language. Right? (I don't expect any disagreement here.) this is te behaviour I expect of the current version of WebFonts.

If you're seeing anything else, as you are reporting, there are two possibilities:

the content is not tagged correctly - it should be content language by default for content
WebFonts is not doing things as we think it should

Let's determine what's going on and fix it.

I agree with your expectation. IIRC there was even a webfonts.all test where a sample page loaded webfonts for all supported languages with lang tags and that test passed.

http://translatewiki.net/wiki/WebFonts_assessment/autotesting2 -- If am right, passes for me too on same browser - with a comment, On the article page, all fonts render, but on the edit or,my,saz fails and displays squares inside edit box. (My guess is i have fonts for others, and they are displaying for local). Branch it to new bug if you could reproduce the same.

Coming to Main bug

Am putting below the snippets of source i get when am logged in.

<title>ଉଇକିପିଡ଼ିଆ</title>

<div lang="or" dir="ltr" class="mw-content-ltr">

html lang is set to ta, my interface renders Lohit-Tamil by default, if I reset the font it renders everything in TSCu_Paranar (My local tamil font)

Even though title tag doesnt have any lang code, am able to see the oriya text on the title bar render properly.

Body Content div has or as lang tag bug everything else on page are squares.

Anonymous

When am anonymous, things work perfectly fine during when both <html lang="or"... and <div lang="or" dir="ltr" class="mw-content-ltr">. Title doesnt have lang code here too, but works fine.

PS: For testing this bug I renamed all my oriya ttf files and cleared my font cache using fc-cache

Assuming this works fine, should the UI have both Tamil & Oriya Font as checked to inform the user 2 webfonts are being used to render the page? This can be lower priority and thought along with UI redesign.

(In reply to comment #3)

I agree with your expectation. IIRC there was even a webfonts.all test where a
sample page loaded webfonts for all supported languages with lang tags and that
test passed.

http://translatewiki.net/wiki/WebFonts_assessment/autotesting2 -- If am right,
passes for me too on same browser - with a comment, On the article page, all
fonts render, but on the edit or,my,saz fails and displays squares inside edit
box. (My guess is i have fonts for others, and they are displaying for local).
Branch it to new bug if you could reproduce the same.

This is always reproducible but there is no fix. We can apply only one webfont to a text area. If the text area got 5 words in 5 languages, we cannot apply 5 fonts to text area. For these kind of purpose a rich text interface is needed , Something like a visual editor, But textbox cannot handle this.

PS: For testing this bug I renamed all my oriya ttf files and cleared my font
cache using fc-cache

nope, renaming wont work. You need to move the fonts out of your system font directory and user font directory. fc-cache is not for clearing cache, but to recreate the cache. And font file names are irrelevant to fontconfig. It reads the fonts and understand the ttf name, glyphs availability etc.

I am closing this, may be you can open a specific bug about UI. But I dont think we need to list all the font loaded to a page in the webfonts menu.

WebFonts must load content language's font not interface lang's fontClosed, InvalidPublicActions