Last modified: 2013-10-26 10:35:27 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T55734, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 53734 - Setting language to anything other than "en" changes default edit-window font from monospaced to sans-serif
Setting language to anything other than "en" changes default edit-window font...
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
UniversalLanguageSelector (Other open bugs)
unspecified
All All
: Normal major with 3 votes (vote)
: ---
Assigned To: Santhosh Thottingal
:
: 53759 53832 54210 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-04 05:40 UTC by p858snake
Modified: 2013-10-26 10:35 UTC (History)
19 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description p858snake 2013-09-04 05:40:04 UTC
Setting language to en-gb from en changes the default edit-window front monospaced.
Comment 1 Niklas Laxström 2013-09-04 06:04:29 UTC
I am unable to reproduce this bug with given information.
Comment 2 Nemo 2013-09-04 06:42:03 UTC
I can see this on en.quote, though in opposite direction (probably due to different OS defaults). What I did:

1) Chromium in incognito mode (logged out, without special fonts settings in the browser)
2) Open http://en.wikiquote.org/wiki/Special:Random?uselang=en-gb&action=edit and http://en.wikiquote.org/wiki/Special:Random?action=edit
3) Observe the first page carefully, or type something like ".... [newline] mmmm" in both to check if it is monospaced)

For me en-gb is non-monospaced while the default is.
Comment 3 Nemo 2013-09-04 09:47:07 UTC
Also on TWN, https://translatewiki.net/w/i.php?title=Gender&action=edit&uselang=en vs. https://translatewiki.net/w/i.php?title=Gender&action=edit&uselang=en-gb (logged in in Firefox and logged out in Chromium; note that as unregistered user it's only a view source text area).
Comment 4 Bartosz Dziewoński 2013-09-06 08:16:36 UTC
*** Bug 53832 has been marked as a duplicate of this bug. ***
Comment 5 Bartosz Dziewoński 2013-09-06 08:17:20 UTC
Is this being worked on? Just how hard is it *not* to change fonts?
Comment 6 Mormegil 2013-09-06 09:48:52 UTC
Copying my thoughts from bug 39560:

…and here we go again. The textarea on MediaWiki.org has “font-family:
sans-serif;” style inline when using Czech [cs], see e.g.
http://www.mediawiki.org/w/index.php?title=Project:Sandbox&action=edit&uselang=cs

My guess is I9dd87f44 (or
https://github.com/santhoshtr/jquery.webfonts/commit/1f67cf2bf9ac435a6772eb66f080b118c0e10661).

I switched my preferences to make the textarea always use monospaced font,
which seems to stop ULS from messing with the textarea for now.
Comment 7 Helder 2013-09-06 10:30:56 UTC
This is not exclusive to "en-gb". If I change the "uselang" parameter to any of "pt", "pt-br", "zh", "ru" or "ml", I get "sans-serif". The only code which seems to result in monospaced font is "en".
Comment 8 db [inactive,noenotif] 2013-09-08 09:17:01 UTC
*** Bug 53759 has been marked as a duplicate of this bug. ***
Comment 9 Ori Livneh 2013-09-08 19:40:53 UTC
In jquery.webfonts.js:

    if ( !fontFamily ) {
        // If there is no explicit font for this language, it will
        // inherit the webfont for the parent.  But that is undesirable here
        // since language is different. So inherit the original font of the
        // element. Define it explicitly so that inheritance is broken.
        // element
        fontFamily = webfonts.originalFontFamily;
    }

The logic you're seeing is this:
- There's no font to apply for this language.
- If we don't specify a font, the element could inherit a webfont from a parent.
- So we have to explicitly specify the default font.
- The default font is the font-family for body, which is 'sans-serif'.

The catch is this: most browsers do not apply inherited font-family styles to form elements by default, as a way of protecting the consistency of input interfaces.

To prevent this special-casing of form elements, you have to explicitly specify:

input, select, textarea {
  font-family: inherit;
  font-size: inherit;
  font-weight: inherit;
}

References:
http://www.komodomedia.com/blog/2006/10/css-trickery-part-5-inheritance/
http://stackoverflow.com/questions/6520689/font-family-is-not-inherited-to-the-form-input-fields

The easy way to fix this would be to exempt form elements in the if ( !fontFamily ) { /* ... */ } block in jquery.webfonts.js.

If we move in the direction of explicitly specifying fonts, it would be arguably better / more correct to specify that form elements should inherit font styles. But the existence of this bug demonstrates that this would be surprising to users.

I think it'd be best to fix it in jquery.webfonts.js and then start a separate bug thread to discuss the second option.

I also note that I think the if ( !fontFamily ) ... check is overzealous; it should only explicitly apply the default font stylings to elements are descendants of elements that have a WebFonts specified. DOM manipulation is expensive, even if it is a no-op from the perspective of the page's appearance. It should be possible to be a bit cleverer about inheritance and only apply the defaults when absolutely required.
Comment 10 Santhosh Thottingal 2013-09-09 16:48:05 UTC
The monospace font style applied to the form fields comes from the user agent(browsers) and not from any style sheets. The monospace is undefined for many scripts like non-latin languages. I need to find a solution, that does not affect latin script, but make sure font is actually applied for scripts that does not have monospace defined.

Put it in otherwords, if the language is any script where monospace is not defined, what we see is expected result. But surprising to languages with monospace as the bug report says.
Comment 11 Gerrit Notification Bot 2013-09-17 16:37:19 UTC
Change 83972 had a related patch set uploaded by Nikerabbit:
Fix monospace font usage for input fields for latin scripts

https://gerrit.wikimedia.org/r/83972
Comment 12 Niklas Laxström 2013-09-17 16:38:31 UTC
*** Bug 54210 has been marked as a duplicate of this bug. ***
Comment 13 Andrey Kiselev 2013-09-18 08:18:36 UTC
Parser always replaces font-family to sans-serif for <span lang="chu-Cyrs" style="font-family: Bukyvede, 'Times New Roman'>.
Comment 14 Andre Klapper 2013-09-18 10:48:08 UTC
Andrey: No idea who your problem is directly related to this bug report... Small testcase welcome (e.g. on a page on test2.wikipedia.org) so others could try to reproduce.
Comment 15 Rainer Rillke @commons.wikimedia 2013-09-18 10:52:07 UTC
(In reply to comment #13)
A closing doublequote (") is missing in your sample. The correct example:
<span lang="chu-Cyrs" style="font-family: Bukyvede, 'Times New Roman'>abc</span>
Comment 16 Rainer Rillke @commons.wikimedia 2013-09-18 10:52:46 UTC
<span lang="chu-Cyrs" style="font-family: Bukyvede, 'Times New Roman'">
abc
</span>
Comment 17 Andrey Kiselev 2013-09-18 11:35:44 UTC
(In reply to comment #14)
> Andrey: No idea who your problem is directly related to this bug report...
> Small testcase welcome (e.g. on a page on test2.wikipedia.org) so others
> could
> try to reproduce.

https://test2.wikipedia.org/wiki/Bug_53734
Comment 18 MF-Warburg 2013-10-07 03:52:21 UTC
Any estimations as to when this can be fixed? It's quite annoying when editing tables and other stuff where it's desirable to put the correct amount of whitespaces in order to better see through the code.
Comment 19 Niklas Laxström 2013-10-07 06:09:39 UTC
This is being tracked in Mingle: https://mingle.corp.wikimedia.org/projects/internationalization/cards/3719

We have an open patch in Gerrit: https://gerrit.wikimedia.org/r/#/c/83972/

The patch is waiting for more testing and integration tests. The integration test task is currently assigned to Amir, who comes back to work later this week.
Comment 20 Gerrit Notification Bot 2013-10-14 05:51:04 UTC
Change 89624 had a related patch set uploaded by Amire80:
WIP: Edit area monospace font test

https://gerrit.wikimedia.org/r/89624
Comment 21 Gerrit Notification Bot 2013-10-14 06:14:12 UTC
Change 89624 abandoned by Amire80:
WIP: Edit area monospace font test

Reason:
Will make another commit.

https://gerrit.wikimedia.org/r/89624
Comment 22 Gerrit Notification Bot 2013-10-14 06:23:13 UTC
Change 89624 restored by Amire80:
WIP: Edit area monospace font test

Reason:
trying to rebase

https://gerrit.wikimedia.org/r/89624
Comment 23 Gerrit Notification Bot 2013-10-22 05:09:54 UTC
Change 83972 merged by jenkins-bot:
Fix monospace font usage for input fields for latin scripts

https://gerrit.wikimedia.org/r/83972
Comment 24 Gerrit Notification Bot 2013-10-22 05:10:49 UTC
Change 89624 merged by jenkins-bot:
Edit area monospace font test

https://gerrit.wikimedia.org/r/89624
Comment 25 Niklas Laxström 2013-10-26 09:20:48 UTC
Is this bug fixed now?
Comment 26 Jesús Martínez Novo (Ciencia Al Poder) 2013-10-26 10:35:27 UTC
Works for me now on mediawiki.org. Thanks!

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links