Last modified: 2012-01-12 12:50:42 UTC
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.
> 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. <html lang="ta" dir="ltr" class="client-nojs" xmlns="http://www.w3.org/1999/xhtml"> <title>ଉଇକିପିଡ଼ିଆ</title> <!-- bodycontent --><div lang="or" dir="ltr" class="mw-content-ltr"> 1. 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) 2. Even though title tag doesnt have any lang code, am able to see the oriya text on the title bar render properly. 3. 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 <!-- bodycontent --><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.
