Talk:Wikimedia Forum/Autonym font test with active Wikipedias

Test results

Please make clear which OS/browser combos the observations are relevant to. Many of us are not seeing the same thing you are. None of the font rendering problems you introduce with “now look...” affect Mac OS or iOS. I have tested in Safari 6.1/Mac, Safari/iOS 5, Firefox 25/Mac, and Chrome 31/Mac.

The bold and italic and letterspaced tests are out of scope. The font is not intended to be used this way.

Bold and italic are relevant where we use the "autonym" class to create list of languages in a navbox, as we were instructed to in a recent "Tech News" (for example navboxes for navigating between translations of the current page on the same wiki, i.e. outside the language sidebar of interwiki links : the language matching the current page will not render as a blue link but as bold text. Same problem if this navbox uses italic, or other incompatible styles. -- verdy_p (talk) 20:51, 20 November 2013 (UTC)

And some of these languages do not have native italic or bold forms. But I presume that the joining feature should be included for joining characters in any font.

I agree. But MediaWiki makes these script render as bold or italic depending on context. Bold is still used even if the text is Chinese for example, on a link for the current page. But Bold Chinese is unreadable (just like Bold Tibetan, and Bold Khmer). 89.2.191.39 20:40, 20 November 2013 (UTC)

In addition to the Slavonic Glagolitic (cu-Glag) and Gothic (got) characters, Autonym is missing the following. (Tested by importing the TTF version of Autonym 1.0.20131103 into Apple Font Book and using this page’s text as sample text.)

• All characters in ភាសាខ្មែរ (km)

I have no problems with Khmer rendering with Autonym font. Most probably you've selected another webfont in ULS for the Khmer language, and this other webfont is defective. Note that ULS will detect the lang="km" atribute, and will insert the CSS style="font-family: Your-Font-Selected-For-Khmer, sans-serif" in the span containing also the CSS class="autonym". The style inserted by ULS in that case will override the CSS class... -- verdy_p (talk) 20:51, 20 November 2013 (UTC)

• The first two characters in 客家語/Hak-kâ-ngî (hak)

Same remark as for Khmer. In both cases, you can setup your ULS font preferences for these languages by:

• selecting the language in ULS (or append the query string "?setlang=km" or "?setlang=hak" to the current URL of the page), then use the ULS in the Display settings, to selecti the Font for the currently select language
• then reselect your preferred language in the ULS tool (or append the querystring "?setlang=your-language-code" to the current page)

-- verdy_p (talk) 20:51, 20 November 2013 (UTC)

Autonym is also missing a number of capital letters which are necessary to display the names in title case as they appear in WikiMedia sites, but are not tested in this sample. Described on github. For example, the name čeština (cs) appears in nav menus as Čeština (Čeština).

Titlecasing or any casing transforms should NEVER be applied blindly to language names in forign languages. Foreign languages have specific semantic rules about casing. Use the result of {{#language:code}} as they are, without any case transforms. -- verdy_p (talk) 20:51, 20 November 2013 (UTC)

A Unicode left-to-right mark U+200E seems to have snuck in at the end of the link text “беларуская (тарашкевіца)‎”. —Michael Z. 2013-11-19 17:10 z

This does not come from this page. I'll look in the Template itself to see if one is present (some days during last october and at the begining of the month, MediaWiki was inserting these BiDi controls without alerting the user. These controls are hard to detect as they are completely invisible when editing the wikicode or even when using the new VisualEditor (I suspect this bug was introduced in an update of the VisualEditor, which also affected the normal Wiki code editor); such bugs are frequently encountered now when editing templates that test if parameters are empty or not, they cause these templates to no longer run correctly).

To detect these controls where they were unexpectedly inserted by MediaWiki itself (sic!) during some unknown edit operations, I need to look the debug console of the browser to view the HTML code (Chrome renders the HTML code using character entities like "‎" when there's such LRM control, this allows searching were they are present. Thanks for pointing me this caveat which is correctable to not easy to detect. -- verdy_p (talk) 20:51, 20 November 2013 (UTC)

I confirm that the LRM is within the string returned by "{{#language:be-x-old}}" from which you get "беларуская (тарашкевіца)" with the final LRM.

This string is not in my control, you'll need to file a bug in MediaWiki Bugzilla to have the Module implementing the #language parser function cleaned up from these unexpected LRM in its database of language names. Another effect of the recent bug in the MediaWiki code editor that has plagued many pages without users noticing them and causing lots of troubles in many pages. verdy_p (talk) 21:10, 20 November 2013 (UTC)

See my comment in https://bugzilla.wikimedia.org/show_bug.cgi?id=28428 about those damned invisible RLM and LRM controls inserted magically by the MediaWiki editor. -- 21:23, 20 November 2013 (UTC)

Bugs

Known bugs:

• Language names blurred and difficult to read using the hardcoded "Autonym" font on Windows computers