text:
MediaWiki talk:Common.css

Padding
Will an admin please change "padding-left: 16px" to "padding-left: 22px"? This will fix the audio links. Omegatron 12:51, 26 August 2006 (UTC)

 * Thank you. I also previewed a 16px image, and used that link instead (as I had gotten complaints about being too big.)  --Connel MacKenzie 01:43, 28 August 2006 (UTC)

Template documentation
Could you please add the following snippet (copied from Wikipedia), it's for the template documentation feature. Thanks. 16@r 18:29, 9 June 2008 (UTC)

 * Whereas Wikipedia puts template documentation on template pages, we put template documentation on template talk pages; so, I don't think we don't need that sort of CSS? (Or am I misunderstanding what you mean by "the template documentation feature"?) —Ruakh TALK 21:05, 9 June 2008 (UTC)

Ref highlighting
en.wiki uses CSS to highlight references with a light blue background when clicked, making it infinitely easier to find which one you clicked in a long list. I strongly urge Wiktionary to do the same. The code required is:

Cheers. --MZMcBride 19:28, 26 July 2008 (UTC)

 * Why? Where did you find a long list of references on Wiktionary?  Most entries for a word have one or two references only.  Unlike Wikipedia, we are a dictionary, and unlike topical articles, a word usually needs only a couple of references. --EncycloPetey 18:05, 31 July 2008 (UTC)
 * Yes, the page I tripped across was Transwiki:List of buzzwords, but it seems that <ref> tags really aren't commonly used in articles, so the code is really optional. I just remember clicking one of the refs on that page and getting lost in the list at the bottom. --MZMcBride 18:32, 31 July 2008 (UTC)
 * FWIW our most referenced entry mythos has 14 references. I've added the code to Help:Customizing_your_skin. --Bequw → τ 19:25, 24 August 2010 (UTC)

Should space-containing font-family names be quoted?
The CSS2 spec (W3C Recommendation May '98, April '08) states that "Font family names containing whitespace should be quoted." (§15.2.2) The CSS2.1 spec (W3C Candidate Recommendation July '07) agrees. (§15.3) So does CSS3, as far as I can tell (§3.2), though oddly it doesn't consistently follow this advice in its own example. All three do specify an interpretation of unquoted white-space containing names (leading whitespace is trimmed, internal whitespace is collapsed to SP), and that interpretation matches our needs, but it still seems that we should follow the recommendation to quote the names, right? Or is there a reason not to? —Ruakh TALK 14:15, 9 December 2008 (UTC)

 * As long as the whitespace consists of single spaces, it just isn't necessary.

 * The CSS specs say that these names “should be quoted.” Believe it or not, the CSS spec relies on a specific definition of should, referring to RFC 2119, which says “SHOULD  This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.” —Michael Z. 2008-12-09 16:44 z

 * Yeah, I know; the 2119 defs are very standard, and referenced in a whole bunch of other specs and RFCs. In our particular circumstances, what's our valid reason for ignoring that item? Why have we chosen a different course, and where did the careful weighing take place? —Ruakh TALK 18:56, 9 December 2008 (UTC)

 * It works in all cases, and it is common practice. I read and understand the relevant specifications, and have been practising this myself professionally for years.  If I spend some time, perhaps I can cite some professional works in support of this, but the spec doesn't require this. —Michael Z. 2008-12-09 19:39 z

 * After a quick look, I see that most guides recommend or insist on the quotation marks, but appear to be merely repeating or interpreting the spec.

 * But I found a more authoritative discussion, in a Cascading Style Sheets: The Definitive Guide by Eric Meyer, who is considered the guru on practical CSS. It also appears to be updated from earlier editions.

 * Under “Using quotation marks”, pp 96–97. Apparently quotation marks were required in CSS 2.0 if a font name has any non-alphanumeric symbols, but not in 2.1.  But Meyer writes that “As it turns out, the only required quotation is for font names that happen to match accepted keywords.  Thus, if you call for a font whose actual name is ‘cursive,’ you'll need to quote it.”  And generic-family names must not be quoted.

 * I leave off the quotation marks for readability and consistency, and to avoid mis-nesting quotation marks or quoting generic families. In Wiktionary, it's also easier to police no quotation marks than it is to confirm that they are on every family with spaces or every single family, and on no generic family.

 * But if you would rather quote family names with spaces, then I'm okay with that too. Whatever we choose, we should maintain it consistently. —Michael Z. 2008-12-09 20:32 z

 * Thanks for your research. IMHO, the book that you link to does advocate quotation marks around font names with spaces in it, e.g. when it says, “Quotation marks are needed in a  declaration only if a font name has one or more spaces in it, such as New York, or if the font name includes symbols such as # or $.” Still, if you're confident in your preference for omitting the quotes, I'm O.K. with that. —Ruakh TALK 01:12, 11 December 2008 (UTC)

Update. It looks like Firefox chokes on the unquoted font-family name "MPH 2B Damase"; its error console gives this message:
 * Expected end of value for property but found '2B'. Error in parsing value for property 'font-family'. Declaration dropped.

I'm assuming this is because CSS defines '2B' as a DIMENSION token rather than an IDENT token. I don't know whether Firefox is acting correctly here (nothing in the spec leads me to believe that unquoted font-family names must consist of IDENT tokens), but we might as well accommodate it. I'm modifying the stylesheet accordingly. —Ruakh TALK 21:34, 27 December 2008 (UTC)

 * Looks like a Mozilla bug. I don't know of any CSS units called B, but from looking at the spec, even “1em”, “2px”, etc., should be parsed as parts of font names in a font-family declaration.

 * I also quoted 'Hapax Berbère', mandatory due to non-ASCII character.

 * Can you tell if that's Firefox's only error in parsing the CSS? We have several fonts with figures in them, but that's the only one with a fragment beginning with a digit. —Michael Z. 2008-12-28 01:08 z

 * I just did a little test. Firefox/Mac 3.04 chokes on any part of a font name which starts with a figure.  So the entire line font-family: 1font, serif; is tossed, but font-family: '1font', serif; is kept. —Michael Z. 2008-12-28 01:21 z

 * Filed Bug 471300 for Firefox. —Michael Z. 2008-12-28 01:42 z

 * Okay, turns out that in CSS 2.1, any text fragment starting with a digit is treated as a dimension, for future compatibility with new units—so it is dropped as an invalid font declaration. Mozilla (and Opera and Safari/Webkit) are doing the right thing here—one just had to look elsewhere in the spec to realize this.

 * It's not specifically about the whitespace. Any font name containing a token resembling a dimension [\d.*] must be quoted. —Michael Z. 2009-01-01 20:22 z

 * To clarify, it's not "a token resembling a dimension", but rather a DIMENSION token. Tokens are defined by the language, and as I said above, CSS defines '2B' as a DIMENSION token. I don't make this stuff up. :-)  —Ruakh TALK 21:52, 3 January 2009 (UTC)

 * Funny. Bug was resolved as invalid because "you _should_ quote those font-family names". DAVilla 07:14, 6 February 2011 (UTC)

Armenian script
Can we change Template:Armn, please? Sylfaen might be the ugliest font devised for Armenian and it is a serif font, which contrasts with sans-serif ones of other languages. Also, it looks gigantic in translation lists with current size settings. If an admin brings Arial Unicode MS to the front in the source below, will it make the browser choose Arial Unicode MS by default? If so, please push back Sylfaen but do not delete it, as it is the only font coming with Windows by default having Armenian Unicode characters. Thank you.

 * Moved Sylfaen to the back. —Stephen 14:17, 26 December 2008 (UTC)

Sorry to bring this up again, but can a sysop change the set of fonts for Template:Armn to the following? This seems to be the optimum choice.

 * Changed Armenian fonts from "Arial Unicode MS, Arial AMU, Arian AMU, Chrysanthi Unicode, Code2000, TITUS Cyberbit Basic, Sylfaen" to "Arial AMU, Arian AMU, DejaVu Sans, Sylfaen, Code2000, Arial Unicode MS". —Stephen 22:50, 4 January 2009 (UTC)

Horizontal lists
Would anyone mind if I added the following styling information to accommodate lists formatted horizontally. This would allow a wiki list to be structured as a list, but displayed inline (with either a comma or space separator). This aids in Usability as one can navigate them more easily with screen readers and their ilk (see Wiktionary talk:Usability). One can even nest a horizontal list in a normal (ie vertical) list just fine. --Bequw → τ 23:19, 4 March 2010 (UTC)

Taml
I have increased Tamil by 25%, the font size was too small. Please check தமிழ் and தமிழ். --Anatoli 04:28, 3 June 2010 (UTC)

font-family /**/:inherit;
What's the effect of this? Some fonts look better with it, some not. --Anatoli 07:17, 3 June 2010 (UTC)
 * Basically, it makes all browsers ignore the fonts defined above, except for IE6. For most of the basic font declarations (IPA, latinx), we probably want this to be there. -- Prince Kassad 08:44, 3 June 2010 (UTC)

 * Thanks. Why do we want to ignore them? Are there browser/system specific fonts to be used instead? Sorry, if it's a stupid question. --Anatoli 22:07, 3 June 2010 (UTC)
 * Yes, we want the browsers to be using their own fonts for these. IE6 gets special treatment because it's too stupid/dumb-minded to do this. -- Prince Kassad 08:41, 4 June 2010 (UTC)

Hani, Kore, Jpan
I disagree with the reversal. Please explain why this was a problem. --Anatoli 21:08, 8 June 2010 (UTC)
 * Please see User talk:Prince Kassad -- Prince Kassad 21:25, 8 June 2010 (UTC)

Please Add Pashto in this list
/* Pashto-ps Template:Pashto */ .Phag { font-family: 'Pokhto', Tahoma, Pashto Kror Asiatype, sans-serif; }

--احمد-نجيب-بياباني-ابراهيمخېل 15:11, 14 June 2010 (UTC)

 * Added. Use Template:ps-Arab for Pashto words to apply these fonts. -- Prince Kassad 16:47, 14 June 2010 (UTC)

Non-gloss definitions
I think that we should add the following to the common.css:

This will italicize s and s. The reason why we should do this is (1) to be consistent with editors that already italicize this and (2) to set non-gloss definitions apart from gloss ones. —Internoob (Disc•Cont) 17:27, 26 July 2010 (UTC)
 * AFAIR I haven't seen much of (1), but I agree with (2) and the proposal. —msh210℠ (talk) 17:32, 26 July 2010 (UTC)
 * I agree with msh's entire comment, both parts parts represent my opinion. Thryduulf (talk) 18:09, 26 July 2010 (UTC)
 * (1) is a bad reason, on reflection. There will be inconsistencies with users that don't use templates or italic text if we do this. —Internoob (Disc•Cont) 18:55, 26 July 2010 (UTC)
 * In particular, Italian adjective forms made by don't use any template whatsoever. —Internoob (Disc•Cont) 23:37, 27 July 2010 (UTC)
 * Until the template produces visually different output there will be no incentive for anyone to learn to use it. So if we want to introduce this we can't wait until all uses are templated as it will be the introduction of this that drives the templating. Regarding the Italian adjective forms, could SB's bot go back to the entries it created and apply the template automatically Thryduulf (talk) 00:36, 28 July 2010 (UTC)
 * I just don't know anymore whether it's worth the trouble. Meh. —Internoob (Disc•Cont) 01:45, 28 July 2010 (UTC)
 * Personally I think it is, but I'm not going to be the one doing the coding. Thryduulf (talk)

 * What exactly is the problem that this is solving? Pingku 16:38, 28 July 2010 (UTC)
 * [[!]] now has a definition "Denoting excitement, surprise or shock"; [[exclamatory]] could have the same definition line (well, close). Does that mean that ! means the same as exclamatory? If so, perhaps I could end this sentence with exclamatory instead of an exclamation point! Like this exclamatory Nonsense exclamatory Users need to see that the "Denoting excitement, surprise or shock" definition is not a gloss that can not be put in place of the thing being defined, but rather an explanation of it. Italics are used in other dictionaries (or so I've heard) to distinguish the one kind of definition from the other, and that's the proposition here. —msh210℠ (talk) 17:09, 28 July 2010 (UTC)
 * [[!]] also now has a definition "factorial". This one is substitutable, so wouldn't get italicized. (I'm not sure it's the best definition for that sense, but that's another story.) —msh210℠ (talk) 17:11, 28 July 2010 (UTC)

 * Why is this the best solution? Pingku 17:27, 28 July 2010 (UTC)
 * Because most of the templates that do non-gloss definitions have <span class="use-with-mention"> in them. —Internoob (Disc•Cont) 22:35, 28 July 2010 (UTC)
 * And, from another perspective: I understand a number of other dictionaries do the same:italicize non-gloss definitions. —msh210℠ (talk) 15:23, 29 July 2010 (UTC)

 * I'd support that — in fact, I've always had that in my own monobook.css, and didn't remember until now that it wasn't the default! — but the current default format is a result of a vote (Votes/2006-12/form-of style), so maybe we shouldn't change it without another vote? I don't know. —Ruakh TALK 02:43, 29 July 2010 (UTC)
 * That vote seems to apply only to the mention, not the non-gloss definition around it. Nonetheless, I suppose you're right that we should vote on this. —msh210℠ (talk) 15:23, 29 July 2010 (UTC)
 * A problem: Some non-gloss-definition templates include the word in the CSS class and others do not. For example, template:plural of is essentially, whereas template:conjugation of is essentially  . If the CSS change affects not only   but also   (i.e. the one contained in the other) then we will wind up with different displays depending on which template is used. The solution IMO is to modify template:conjugation of (and any others that are like it) to be like template:plural of. —msh210℠ (talk) 15:23, 29 July 2010 (UTC)
 * I've now effected this change to template:conjugation of, but don't know whether any other templates are like it was. —msh210℠ (talk) 15:26, 29 July 2010 (UTC)
 * The  is not italicized in either case for some reason. —Internoob (Disc•Cont) 16:50, 29 July 2010 (UTC)
 * That reason is that the CSS specifies, overriding the previous  . —msh210℠ (talk) 19:56, 2 August 2010 (UTC)
 * I've brought this to [[Wiktionary:Votes/2010-08/Italicizing use-with-mention]]. —msh210℠ (talk) 20:13, 2 August 2010 (UTC)

Possible change to expandable tables
div.NavFrame div.NavHead:hover {background-color:#F6F6F6;} div.NavFrame div.NavHead:active {background-color:#E3E3E3;} I think this might make it a little more obvious that the tables are things to be clicked. Thoughts? --Yair rand (talk) 08:19, 20 August 2010 (UTC)
 * Could you produce a mockup so those of us who don't read css well enough to visualise what happens van see what it does please.Chers Thryduulf (talk) 13:21, 20 August 2010 (UTC)
 * I give my seal of approval Rossrobbe.jpg to this suggestion.
 * I'd suggest adding this to your monobook.css to see it because I don't know of a way to do this with inline CSS. —Internoob (Disc•Cont) 17:12, 20 August 2010 (UTC)
 * Normally one could embed CSS in an inline stylesheet, but it appears no browser supports pseudo-classes (eg :hover) for inline CSS. Why don't you mock it up at WT:PREFS? The  option (#20) has been free for at least 30 days. --Bequw → τ 05:56, 24 August 2010 (UTC)
 * Good idea. Proposed CSS addition now available for testing at "Change style of expandable tables" at WT:PREFS. --Yair rand (talk) 06:12, 24 August 2010 (UTC)
 * One thing: It doesn't work for the blue ones like . You would need  for it to work for them. —Internoob (Disc•Cont) 01:21, 24 August 2010 (UTC)
 * I like it. Could we add two more lines
 * so that the coloring doesn't change for (which isn't dynamic)?--Bequw → τ 20:28, 24 August 2010 (UTC)
 * That makes sense. --Yair rand (talk) 21:20, 24 August 2010 (UTC)
 * so that the coloring doesn't change for (which isn't dynamic)?--Bequw → τ 20:28, 24 August 2010 (UTC)
 * That makes sense. --Yair rand (talk) 21:20, 24 August 2010 (UTC)

 * Another thing: clicking on a link in the NavHead makes the :active go off, which is not really bad except it makes it look sort of unintelligent. —Internoob (Disc•Cont) 17:37, 27 August 2010 (UTC)

Another possible change to expandable tables
div.NavFrame { margin: 0px ; padding: 2px; border: 1px solid #aaaaaa; text-align: center; border-collapse: collapse; font-size: 95%; overflow: auto; width: auto; } div.Boxmerge div.NavFrame { border-style: none; border-style: hidden; } div.NavFrame + div.NavFrame { border-top-style: none; border-top-style: hidden; } to div.NavFrame { margin: 0px 0px -1px 0px ; padding: 2px; border: 1px solid #aaaaaa; text-align: center; border-collapse: collapse; font-size: 95%; overflow: auto; width: auto; } div.Boxmerge div.NavFrame { border-style: none; border-style: hidden; } This should (I think) remove the problem with stacked varying-width expandable tables. --Yair rand (talk) 08:57, 8 November 2010 (UTC)

Support for Buginese script
Can someone add Saweri font to the "Bugi" class. Saweri is a font that supports lontara only. the site --Kurniasan 00:15, 17 November 2010 (UTC)

Code2000
Can you please remove Code2000 from .IPA? It's unreadable.--Ancient Anomaly 15:57, 14 January 2011 (UTC)
 * I didn't remove it, but I moved it farther to the back of the list, so you have a lower chance of getting this font. -- Prince Kassad 00:33, 15 January 2011 (UTC)

Khmer fonts are too small
I find that Khmer script in Wiktionary is very tiny and illegible on my computer but they look normal on Cambodian web pages. Are we using the right fonts? --Anatoli 01:42, 8 April 2011 (UTC)
 * I think we are. The CSS specifies the Khmer OS font as the first choice, and that is a rather large font. I know the default Microsoft fonts are really tiny for some odd reason. -- Prince Kassad 07:52, 8 April 2011 (UTC)

 * Thank you. Downloaded from here. --Anatoli 11:44, 8 April 2011 (UTC)

NavTable gradients?
So technically gradients don't work in IE, but I figure if the current version just works without the possible improvement, then having something look a bit different in other browsers shouldn't really be a problem. I think expandable tables should really look a little more button-y, as I'm pretty sure that a very large chunk of the people who visit Wiktionary aren't aware that the translation tables are clickable/expandable, and thus miss out on the content. How does this look:

Translations

And when hovered over:

Translations

And when active (clicked):

Translations --Yair rand 19:46, 11 April 2011 (UTC)

 * I'd be down with that. —Ruakh TALK 22:05, 11 April 2011 (UTC)

Coloring mainspace redirects
Since redirects aren't really supposed to be used in the mainspace, I think it would make sense to apply different coloring to  links. Thoughts? --Yair rand 17:54, 19 May 2011 (UTC)
 * Who said they're not supposed to be? I say they are. I can easily see a "See also" section's including a link to a redirect to an appendix, or a "Synonyms" section's linking to a form that is synonymous with the headword, but is a hard-redirect form of a phrase entry. —msh210℠ (talk) 18:58, 19 May 2011 (UTC)
 * I thought mainspace redirects were prohibited by policy except for certain redirects to idioms for helping searches. Why would a synonyms section link to a redirect instead of linking directly to the entry? Could you give a specific example? --Yair rand 22:00, 19 May 2011 (UTC)
 * I actually just checked my last couple of thousand mainspace edits for "nym" or "syn" in the edit summary, as I recall adding a synonym just of this sort. Alas, I must have done so without using a good edit summary (as is my wont). So I'll give a made-up example instead. There's a log-standing difference of opinion and resultant difference in practice about how to word sense lines for Hebrew past-tense singular masculine third-person verbs, which is the form we use as the main form of the verb. I put the sense line in past-tense singular masculine third person; Ruakh uses an infinitive. (The same long-standing difference exists, though with a different tense et al., in Latin, by the way, and, I guess, in other languages.) Suppose the entry נפטר were authored according to my standard, so one sense line would read "(He/it) passed away, to passed on: ", and suppose that the links were to [[passed away]] and [[passed on]] rather than to pass away and pass on, and suppose further that those past-tense English forms were hard redirects (they're not, but they might be). That is an example of the sort I mean. It's very hypothetical, I know, but the point is that there are real such examples, though I can't think of any offhand. —msh210℠ (talk) 22:41, 19 May 2011 (UTC)

infl-table
I can't find any templates in the recent dump that use the span "infl-table". Have all of these been removed (the last discussion I can find is over a year ago)? If so great. Let's remove the pair of lines in Common.css (the default is inline, right, so the .infl-inline statement isn't needed either). --Bequw → τ 02:19, 15 September 2011 (UTC)
 * Removed. --Bequw → τ 12:35, 20 September 2011 (UTC)

Tibetan font size
Could someone please increase the font size for Tibt, to 185%? 120% is too small. I have to zoom in to see the stacked consonants clearly. Thanks. Hbrug 21:53, 29 October 2011 (UTC)
 * Sorry for the lack of response. It depends on certain system settings, and also the font you are using for Tibetan. The default one shipped with Windows, in particular, is extremely small, hardly legible, and practically unusable alongside Latin-script text. However, another font, such as Tibetan Machine Uni or Jomolhari-ID, will display in a better legible size by itself. -- Liliana • 17:31, 1 November 2011 (UTC)

Protocol-relative URLs
Hi. Please change the six instances of "http://" to "//" in MediaWiki:Common.css. This is related to this blog post. Thanks! --MZMcBride 08:39, 31 October 2011 (UTC)
 * Done. --Yair rand 09:36, 31 October 2011 (UTC)

Hide collapsible tables' content
Currently, the content of collapsible tables is displayed until the page finishes loading and the javascript runs. I propose that we add  to Common.css, which would hide the contents of collapsible tables immediately. This would have the side effect of flipping the problem for users who have a preference set to show the tables automatically expanded, as the tables would be hidden until the js runs and then expands them, but I think it would be an overall helpful change anyway. --Yair rand (talk) 09:28, 20 November 2012 (UTC)
 * We might also want to do this for quotations. --Yair rand (talk) 09:18, 25 November 2012 (UTC)
 * Support for both. — Ungoliant (Falai) 17:04, 27 November 2012 (UTC)
 * Does this actually slightly reduce the lag between requesting a page and having it be usable? How much reduction would that be for [[water]] (in percentage terms)? I'd be willing to test it if your connection is too fast, Yair. Almost any change that sped up entries with large translation tables would be beneficial, especially for those who are still using en.wikt as a monolingual English dictionary. This seems quite promising. DCDuring TALK 18:02, 27 November 2012 (UTC)
 * You can test by adding  to Special:MyPage/common.css. —Ruakh TALK 18:44, 27 November 2012 (UTC)
 * oppose. The effect of this is that users without JavaScript won't see the table contents at all, ever. -- Liliana • 19:10, 27 November 2012 (UTC)
 * The class  doesn't get applied for users without javascript enabled, so that's incorrect. --Yair rand (talk) 19:11, 27 November 2012 (UTC)
 * It doesn't? How does that work? -- Liliana • 19:50, 27 November 2012 (UTC)
 * The  element starts with the class , and a small bit of javascript in the head removes it and adds   in its place, all before the body starts loading. --Yair rand (talk) 19:54, 27 November 2012 (UTC)
 * Support both. But is there any reason we can't pull information from user preferences when hiding the content? --WikiTiki89 19:37, 27 November 2012 (UTC)
 * Afaik, neither Common.js nor Gadgets can run before the page finishes loading, so we don't have any way to run Wiktionary-specific JS early. All CSS runs before the body starts loading, however. --Yair rand (talk) 19:42, 27 November 2012 (UTC)
 * Support both —Μετάknowledge discuss/deeds 02:01, 29 November 2012 (UTC)

 * Oppose - I'm one of those who like the tables to be always visible, so this change would be aesthetically bad for me, and I don't see the current state of affairs as a problem or even a slight discomfort for the casual user. Isn't there some way of making the viewer's preferred situation, whatever it is, be immediately visible? --Pereru (talk) 11:42, 29 November 2012 (UTC)
 * No, there is not (as explained above in response to Wikitiki's comment). --Yair rand (talk) 11:44, 29 November 2012 (UTC)

 * @Pereru There actually is a very irritating inconvenience: section links don't work properly when the page shifts after loading. --WikiTiki89 12:14, 29 November 2012 (UTC)
 * What happens when you try them? (And, if the proposed change were carried out, wouldn't this irritating inconvenience now plague people who, like me, prefer to have the tables always open?) --Pereru (talk) 13:10, 29 November 2012 (UTC)
 * My opposition is of course basically aesthetic, which means I'm not going to be very sad if it's changed. I prefer things the way they are now, but if there's much support for the change (which looks likely, judging by the above votes) I'll remove my opposition. --Pereru (talk) 13:10, 29 November 2012 (UTC)
 * It's just a matter of deciding which group suffers the inconveniences. In other words, whichever is more common has to function more smoothly. I assume collapsed tables are more common since that is the default, but perhaps we can find some statistics? --WikiTiki89 13:54, 29 November 2012 (UTC)

 * @Pereru: If we do implement this change, you can override it for yourself by adding  to Special:MyPage/common.css. —Ruakh TALK 15:31, 29 November 2012 (UTC)
 * Well, I find it hard to measure a difference in loading speed, but it feels faster. The page finally snaps into place. As a result I am neutral on this, though I may use it,, at least for a while. It does increase the benefit of putting cognates under when the cognate section is long. DCDuring TALK  22:56, 29 November 2012 (UTC)
 * Done. --Yair rand (talk) 22:09, 4 December 2012 (UTC)

Fonts for Phli
Could someone please add 'Shapour' (released under GNU/GPL) for .Phli, before 'ZH Mono'? (I've tested the font) --Z 20:36, 18 January 2013 (UTC)
 * ✅ -- Liliana • 20:43, 18 January 2013 (UTC)

Hide the "Select fonts" button
Would anyone object if I added  to hide the "Select fonts" button at the top? The button is normally for setting which font is used for the main content, but since this is an English wiki, the only thing it does is offer an option to disable WebFonts entirely and a link to a Help page. --Yair rand (talk) 08:24, 23 January 2013 (UTC)
 * Done. --Yair rand (talk) 01:16, 30 January 2013 (UTC)
 * Please remove it, the WebFonts extension is no longer enabled. --Z 11:38, 13 June 2013 (UTC)
 * Done. --Yair rand (talk) 18:26, 13 June 2013 (UTC)

Classes for scripts/languages
Is there any particular reason that we are applying style for scripts/languages through classes, instead of using language and script codes directly? --Z 14:02, 5 July 2013 (UTC)
 * Maybe some backward compatibility with older browsers that do not support lang (I believe IE7 and older do not), in which case classes are used. However, if those classes are not used at all in Wiktionary, it is clearly useless. Also, maybe the new Universal Language Selector covers this? Dakdada (talk) 14:11, 5 July 2013 (UTC)

 * Historical reasons, mainly. As you can see, our classes are based on script codes. But some editors haven’t agreed to using extended language codes in the format, because browser support is mixed (if memory doesn’t fail me, Firefox’s default font display for, e.g.,   is different from  ).

 * Some editors also insist, probably prudently, on not breaking support for MSIE 6. I have been thinking we could leave the class system in place as legacy, but start to actively use :lang or attribute selectors on the lang attributes. As far as I know, nobody is bothering to confirm that anything here works in MSIE 6 at all, so the basis for this is speculative.

 * The  selector has some very important advantages, but as far as I can tell, we would have to explicitly select every language, and this wouldn’t be much help with language scripts. Since there is no   selector, we’d have to select , etc., and how do we select   vs.  ? I don’t think   works at all (but have not tested). Using an attribute selector "-Latn"] {} is possible, if we start using extended language codes, but doesn’t have the cascading advantages of  . —Michael Z. 2013-07-06 16:16 z

 * Also, romanizations should properly have attributes like "uk-Latn" in brief, or more properly "uk-Latn-t-uk-Cyrl", or "uk-Latn-t-uk-Cyrl-m0-ungegn" in detail, for Romanized Ukrainian. Editors have objected to this, because browsers only look at the  and assume it should be in Cyrillic. —Michael Z. 2013-07-06 16:27 z
 * The scripts also have a more practical advantage: they detach script from language and there are much less scripts than languages, so there are less definitions. It also makes it possible to make text a certain script without changing the language. So I think for the short term we should stay with using scripts, at least until the script templates are gone. 17:25, 7 July 2013 (UTC)
 * Sometimes we want to change the style for romanizations, such as using the unicode class for transliteration of Sanskrit, Avestan, etc. and smallcaps for transliteration of Ogham (users currently use and ), this could be solved by using the method you mntioned (currently we are tagging all transliterations with 'lang=""'). --Z 15:02, 14 August 2013 (UTC)

Comments and page size
I saw [//en.wiktionary.org/w/index.php?title=MediaWiki:Common.css&curid=274374&diff=21386489&oldid=21380010 this], so I just want to note that Mediawiki automatically reduces the code in this page (and others), therefor the size of comments should not be a concern: they just need to be readable for humans. See ResourceLoader. Dakdada (talk) 09:16, 9 July 2013 (UTC)
 * Yes, I noticed that as well. The software removes all redundant spaces and newlines so the end result is just one tightly packed long line. 12:19, 9 July 2013 (UTC)
 * That is true, but the immense spacing made the page hard to read for me, and probably to others as well. -- Liliana • 12:41, 9 July 2013 (UTC)
 * Yes: the only criteria needed here is human readability. By the way, is it not possible to put all those scripts styles in a subpage? Dakdada (talk) 13:28, 9 July 2013 (UTC)

 * Readability, and even more importantly self-documentation. It’s hard to identify orphaned CSS in here.

 * We should have a simple, standard style for writing the CSS, so we don’t work against each other formatting and reformatting the code. Better to pick one for consistency, and not spend our time debating the merits. CSS Tricks has a list of CSS style guides. —Michael Z. 2013-07-12 00:06 z

Need to change the font for Eastern Mari or Meadow Mari (mhr)
Compare (currently):

 * Mari:
 * Eastern Mari/Meadow Mari:
 * Western Mari/Hill Mari:

Eastern/Meadow Mari - the standard for Mari El font should look the same way as any Modern Cyrillic based language.

--Anatoli (обсудить/вклад) 04:35, 10 September 2013 (UTC)
 * Fixed. --Vahag (talk) 07:27, 10 September 2013 (UTC)

CSS style manual
I’ve gone through the CSS style manuals mentioned in the previous comments section. A few guidelines were common to most or all of the style guides:

 * Indent with two spaces per stop
 * One line space between each declaration
 * One selector per line
 * Opening brace on the same line as the last selector
 * Don’t omit optional semicolons
 * Closing brace on its own line
 * Closing brace indented to match the preceding style declarations
 * Alternatively, very short style rules may be all on one line

I have gone ahead and cleaned up the CSS according to these guidelines, and copied this style guide to the top of the CSS. —Michael Z. 2013-09-10 04:49 z

 * I’ve updated this to four spaces per tab stop, since that is what MediaWiki’s CSS editor does (sometimes). —Michael Z. 2013-11-22 05:56 z

Fonts for Arabic are disastrous
Would someone please remove or change the fonts chosen for Arabic-based texts? I mean that code: .Arab, .fa-Arab, .glk-Arab, .kk-Arab, .ks-Arab, .ku-Arab, .mzn-Arab, .ota-Arab, .pa-Arab, .ps-Arab, .sd-Arab, .tt-Arab, .ug-Arab, .ur-Arab { font-family: Geeza Pro, Tahoma, Arial Unicode MS, Code2000, Traditional Arabic, sans-serif; font-size: 125%; direction: rtl; unicode-bidi: embed; } Tahoma? Are you kidding me? It's very erroneous in displaying šadda combined with fatḥa or kasra. It's not even a complete Arabic font. Geeza Pro is an Apple font and I couldn't test it, but it appears to be not different from Arial (the normal Arial, not the Arial Unicode MS). Arial Unicode MS is very illegible and not widely available. I tested Code2000 in the past and wasn't very legible on Windows (Vista and newer). Traditional Arabic, as its name says, its style isn't normative and is also incomplete. Why are you choosing fonts anyway? The only other font that can display on small font-sizes, is Droid Arabic Naskh but it's not completely free from errors (in displaying الله ريال and sukūn mark appears as a dot not a circle on normal font-sizes). Scheherazade and Lateef are free from errors but require an increase in font-size (more than just 125%), which would be incompatible with other fallback fonts which would display the Arabic text a lot larger. So, let's remove that specification because the default display (on Windows at least) is a lot better than what you have specified. By the way, never choose Amiri, as it is one of the worst fonts, it's style is non-normative and not very legible on Windows. Additionally, Amiri font is not naskh as it claims, it's mostly riqʿa mixed with little naskh. --Mahmudmasri (talk) 23:06, 21 November 2013 (UTC)

 * If you can supply a sample text, I can provide a screenshot of Geeza Pro on Mac OS.

 * I don’t read Arabic, so we’ll have to wait for someone else to provide rationale for the font choices. I would be in favour of eliminating font declarations as much as possible, since modern browsers seem quite good at rendering text on their own. But there are cases where a particular font is necessary to display specific characters. Sometimes these only show up in minority languages or historical forms. —Michael Z. 2013-11-22 05:54 z

 * I think that we need to choose the best free compatibly licensed font for each script, that we can serve to clients to ensure that they see everything the way it is supposed to be displayed. I still haven't been able to understand how to get fonts from the Universal Language Selector to work. --WikiTiki89 06:02, 22 November 2013 (UTC)

 * The fonts work, but we have to figure out the font names first! I have updated the examples of Hebrew diacritics, and started collecting font info at the FAQ on MediaWiki. See which fonts there support Arabic. —Michael Z. 2013-11-22 18:25 z

must be referring to one of the test templates for Arabic verb conjugations - I asked him to check User:Atitarev/ar-conjug-I-test and User:Atitarev/ar-conjug-I-geminate-test (incomplete, only three verb forms!). See also Module_talk:ar-translit. There's an ongoing problem with Arabic diacritics - display (some are not visible or double) and order (two diacritics in a row). has addressed some of them. --Anatoli (обсудить/вклад) 03:30, 25 November 2013 (UTC)
 * No, that's not what I was referring to. --Mahmudmasri (talk) 05:46, 25 November 2013 (UTC)

 * The two diacritics in a row problem is also only a font problem. A font is supposed to still display it correctly, we have to find one that does. --WikiTiki89 04:17, 25 November 2013 (UTC)
 * You are wrong, a font won't display duplicated diacritics properly. --Mahmudmasri (talk) 05:46, 25 November 2013 (UTC)
 * I think what was meant was not duplicated diacritics, but that when there are two diacritics in a row, such as shadda and fatha, MediaWiki reorders them so that the fatha comes before the shadda. Some fonts do not display that correctly even though they should. --WikiTiki89 05:55, 25 November 2013 (UTC)

 * Thanks. It's good if it's only a font problem. Which font is used in (how can I tell)? Are Arabic verbs using it affected by the same bug? I've checked some, I haven't noticed a problem. See . It looks all right to me. The diacritics are rather clear. --Anatoli (обсудить/вклад) 04:44, 25 November 2013 (UTC)
 * He is wrong! A font won't display duplicated diacritics properly. Additionally, if some fonts did so, you still have to write one diacritics, as non-standard use of diacritics makes it practically impossible to search for words, as computers treat words as different only for a single diacritic difference. What is your operating system anyway? --Mahmudmasri (talk) 05:46, 25 November 2013 (UTC)

 * The default font for me does not display a fatha when there is also a shadda. --WikiTiki89 05:25, 25 November 2013 (UTC)

 * How do you see غَلَّفَ in the conjugation table of (perfect indicative/3rd person)? I can see them in the correct order: ḡayn, fatḥa, lām, šadda, fatḥa, fāʾ, fatḥa, with fatḥa sitting over šadda, as expected. --Anatoli (обсудить/вклад) 05:34, 25 November 2013 (UTC)

 * This also shows properly for me. I'm using Windows 7 and Windows XP. I don't see a problem with Tahoma at all. --Dijan (talk) 06:41, 25 November 2013 (UTC)

 * Do these appear with the fatḥa above šadda on Windows XP, using a browser other than Firefox? They shouldn't. Double check please. This is like a well known Tahoma fault. Here is a screen capture. --Mahmudmasri (talk) 08:36, 25 November 2013 (UTC)

Šadda+fatḥa or kasra would always appear faulty when displayed by Tahoma or some other bad fonts, whether they were displayed in User:Atitarev/ar-conjug-I-geminate-test or anywhere else. Anything marked with class="Arab" is displayed in Tahoma for Windows users.

Hebrew has no problems and Hebrew text is not cursive, therefore its potential complexities are much less than those of Arabic based texts.

Please, remove the specified fonts for Arabic based texts, because I already noted that default fonts of Windows, Apple and Linux already display Arabic based texts much better.

No rationale for forcing users to see Arabic based fonts in specific fonts when the defaults are more than sufficient. If someone had preferences, he should do so in his customized CSS page, not here. --Mahmudmasri (talk) 05:46, 25 November 2013 (UTC)

 * @Mahmudmasri I don't understand your point and negative comments. People are just trying to understand and help. Wrong fonts and badly displayed diacritics is not any participant's doing here. My OS is Windows 7, browser Mozilla Firefox 25. I'm not lying. I can see the above correctly - at . (Note that the problems with missing forms at User:Atitarev/ar-conjug-I-geminate-test are unrelated). --Anatoli (обсудить/вклад) 05:55, 25 November 2013 (UTC)

 * I didn't accuse you of lying. I wanted to know the operating system... By the way, hadn't I specified my own fonts at my customized CSS page, I would have seen it incorrectly, but I can still see it incorrectly when I log-out. On Windows XP the Arabic text displayed using Tahoma, as specified by the MediaWiki:Common.css here, can't appear properly (both of šadda+fatḥa and šadda+kasra appear as šadda+kasra only). --Mahmudmasri (talk) 06:08, 25 November 2013 (UTC)

These are specified already by the code I pasted above: .fa-Arab, .ks-Arab, .ota-Arab, .pa-Arab, .ur-Arab { font-family: Geeza Pro, Tahoma, sans-serif; }   /* Kurdish */ .ku-Arab { font-family: Geeza Pro, Tahoma, Microsoft Sans Serif, Arial Unicode MS, UT Cairo, UT Naskh, sans-serif; }   /* Pashto */ .ps-Arab { font-family: Pokhto, Tahoma, Pashto Kror Asiatype, sans-serif; }   /* Sindhi */ .sd-Arab { font-family: MB Sindhi, Tahoma, MBSarang Sattar, MB Bhitai Sattar, MB Lateefi, Ayaz Gul, sans-serif; }   /* Uyghur */ .ug-Arab { font-family: UKIJ Tuz, Microsoft Uighur, Scheherazade, Tahoma, Code2000, Lucida Sans Unicode, sans-serif; } --Mahmudmasri (talk) 06:22, 25 November 2013 (UTC)

It appears correctly in Tahoma (5.01.2x) in Safari 6.1, Chrome 31.0.1650.57, andFirefox 25.0.1 on Mac OS X 10.8.5.

Mahmudmasri, what web browser and version are you having problems in? Can you determine what version of Tahoma font you have? Does your Windows XP have the required updates?

Mahmudmasri is there a problem with Geeza Pro, or are you just speculating?

Can someone provide a sample text for testing fonts for Arabic support?

Can someone audit the MediaWiki ULS Arabic fonts? There is a list in the FAQ, but the support info is still incomplete. You’ll have to go through the Git repository to see which ones qualify. —Michael Z. 2013-11-25 15:31 z

 * You can test it out on the declension of :
 * In the final letter of these words, the vowel should appear above the shadda: ظِلٌّ ظِلٍّ الْظِلُّ الْظِلِّ
 * In the final letter of these words, the vowel should appear below the shadda or below the letter: ظِلًّا الْظِلَّ.
 * --WikiTiki89 15:53, 25 November 2013 (UTC)

 * Thanks. Here’s a test of the rendering on your machine. It’s set up to fail visibly instead of falling back to some other font. If you’re not on a Mac, I suggest you install a debugging font: Last Resort or Unicode BMP Fallback Sil. —Michael Z. 2013-11-25 16:46 z

 * Arabic font test on Safari 6.1-Mac.png Here’s a screenshot of the fonts that work on my Mac. —Michael Z. 2013-11-25 17:03 z
 * I mixed some stuff up when copy/pasting some of the sample text. I fixed in the text above, but can you redo the screen shot? --WikiTiki89 17:26, 25 November 2013 (UTC)

 * Okay; refresh to see the updated screenshot. —Michael Z. 2013-11-25 17:45 z

 * The only font in the screenshot that displays everything correctly is Arial Unicode MS. --WikiTiki89 17:50, 25 November 2013 (UTC)

"Wiktionary font", anyone? (Although this solution would be very time-consuming...) -- Liliana • 18:25, 25 November 2013 (UTC)
 * Why reinvent the wheel? I'm sure we can find an existing font that handles Arabic well and is released under a compatible license. I just haven't look for one yet. --WikiTiki89 18:29, 25 November 2013 (UTC)

 * Droid Arabic Kufi sample 2013-11-25 13.45.02.png's a good font: Droid Arabic Kufi
 * It is sans-serif and easy to read and displays diacritics correctly (at least for me). I have uploaded a screenshot (see right).
 * It is released under the Apache License, version 2.0. Read about it here. --WikiTiki89 18:53, 25 November 2013 (UTC)

 * But that Iranian Sans font looks good enough as well. --WikiTiki89 18:59, 25 November 2013 (UTC)

 * Okay, I think that table now represents all of the fonts for Arabic in our style sheet and available on ULS. I have also updated the ULS font info and my Mac screenshot here.

 * Which of these fonts are good enough to read Arabic? Which are not? We should update our font stack. I suggest that OS fonts go before ULS fonts, which will save readers the time and data transfer from downloading unnecessary font files.

 * Can anyone provide challenging text samples for other Arabic-alphabet languages? At least Kurdish, Pashto, Sindhi, and Uyghur, which seem to have different requirements because they have been given their own font stacks?

 * If anyone think additional fonts are needed, then find a freely licensed font, or make one, and submit a bug request on Bugzilla. —Michael Z. 2013-11-25 19:54 z

So it currently looks like the basic  font stack would be:

If other fonts break some characters, then they should be removed altogether, since the Iranian Sans web font should be usable by all. The order is favouring widely-installed fonts over obscure ones for consistency of appearance, local fonts over web fonts to save download time and data. —Michael Z. 2013-11-25 21:27 z

 * To be honest, font files are very small, they are no different from loading an image and they stay cached for a long time. --WikiTiki89 21:35, 25 November 2013 (UTC)

 * And what a dream the web would be if the browser had to finish loading an image before it could start layout and rendering text! Even better if it had to load and execute a JavaScript to find the image, first. Just the other day no images on WikiMedia sites were loading for me for several hours. And I am constantly cursing websites that lay out blank text, flash the page, repaint it, and sometimes crash my tablet’s browser because of web fonts, and they all only have one writing system on the page. The mission is just to make text readable, and there is no benefit to loading a web font if we don’t have to. It’s not like all of these open-licence fonts reinforce Wiktionary’s visual branding, or look particularly good compared to the fonts already on readers’ machines. —Michael Z. 2013-11-26 00:43 z
 * First of all, the text is still rendered with the backup fonts before the font is downloaded. It is also cached for a long time meaning you would only have to download it once per day or so. Or, if the font is already installed on the client's computer, the font is not downloaded at all. --WikiTiki89 01:27, 26 November 2013 (UTC)

 * Those are still reasons to prefer local fonts over web fonts. —Michael Z. 2013-11-26 03:23 z
 * And why is that? --WikiTiki89 03:48, 26 November 2013 (UTC)

 * 1. the text is still rendered with the backup fonts before the font is downloaded – So text in web fonts may be displayed and then change while I am reading. In local fonts it never will. Local fonts are better in this way.

 * 2. you would only have to download it once per day or so – So text in web fonts could delay page loading. In local fonts it won’t. Advantage local fonts.

 * 3. if the font is already installed on the client's computer, the font is not downloaded at all – I would paraphrase: web fonts are best when they are local fonts.

 * I’m not saying that web fonts are bad and should never be used. But for Wiktionary they have no advantages over OS fonts or reader-installed fonts. And they do have some potential disadvantages. We should stack web fonts below local fonts unless they show some clear advantage. —Michael Z. 2013-11-26 22:14 z

 * I rebuff all three points:
 * I normally the font is done downloading before you even blink, so that is usually not a problem.
 * No, because the text is still rendered in a backup font before the font is downloaded. The page will be displayed during the few milliseconds that the font is downloading.
 * A font cannot be a "web font", "OS font", or "user-installed font". A font is just a font. If a user has the specified font on his system, it will be used. If he doesn't but the font location on the web is specified in the CSS, the browser will download it. Otherwise the backup font is used. A user is just as likely to have a font installed that we have available as web fonts as he is to have one that we don't have. So I don't see any downside at all in having a "web font" be the first font on the list.
 * --WikiTiki89 01:34, 27 November 2013 (UTC)

 * Are there any fonts that don't work for us, but that would work if we performed straightforward de-NFC-ifications (e.g. swapping shadda with fatHa)? Because now that most of our non-English text flows through Lua, that's at least a possibility . . . —Ruakh TALK 21:43, 25 November 2013 (UTC)

I use Google Chrome 31. I'm not sure where to find the Tahoma version, but by entering the fonts folder, I clicked with the right button from the mouse on the Tahoma Regular file to see the properties and seeing the details tab, I read the file version to be (3.00), the Tahoma Bold ' s (3.14). Is that it? That screen shot displayed šadda+tanwīn fatḥa incorrectly as if it were šadda+tanwīn kasra. Usually, Windows has Arial as the default Arabic font which appears fine, why should we define fonts? If you still want to specify fonts, please remove the Droid Arabic Kufi as it is incomplete and has a non-normative style (kufi style not naskh). --Mahmudmasri (talk) 01:31, 26 November 2013 (UTC)
 * Iranian Sans appears somewhat like DejaVu Sans, but without errors, except that it appears slightly fuzzy, exactly as DejaVu Sans appears on Windows.
 * A note on Droid Arabic Kufi: It's a non-normative style and incomplete, so I advise against using it. Droid Arabic Naskh is the normative and the more complete version of Droid Arabic fonts.
 * I didn't speculate that Geeza Pro would be faulty, I just thought that its look would be quite similar to Arial, as I saw a picture for it on the internet.
 * Lucida Sans Unicode has no Arabic characters, at least that's the case for its Windows versions.
 * Arial Unicode MS is only installed for Windows users who have Microsoft Office which is not used by everyone and I don't have it.

 * Tahoma 3/3.14 come with Windows XP. Microsoft’s latest version is 5.25. Tahoma 5.01.2x came with my Mac OS X 10.8. I guess the Arabic glyphs got improved somewhere in between.

 * There’s no Arabic in my Lucida Sans Unicode, either. I have removed it from ug-Arab in the style sheet.

 * Arial Unicode MS also comes with Mac OS, since late 2007.

 * I’d rather not specify any fonts, but we have to if all of these Arabic characters are to work on all platforms. The raised characters in ظِلًّا at least don’t seem to work on my Mac with the default sans-serif only (first line of my screenshot). —Michael Z. 2013-11-26 03:23 z

 * So would you be ok with Iranian Sans? How about Droid Arabic Naskh? --WikiTiki89 01:42, 26 November 2013 (UTC)
 * Both are not completely free from from drawback and Droid Arabic Naskh still erroneously displays ريال folded on itself, but they are better than Tahoma. For example, the fonts specified could be something like   (only for basic Arabic characters used in Arabic language). Let Windows use Arial, Times New Roman or Simplified Arabic if Arial Unicode MS is missing and all are missing (in Linux), allow it to use Iranian Sans. --Mahmudmasri (talk) 01:54, 26 November 2013 (UTC)

Thanks Michael Z for your effort to demonstrate in many fonts. Looks like that wicked ظِلًّا (šadda+tanwīn fatḥa) rarely appear properly on browsers other than Firefox! Even Arial failed to render it on Google Chrome! But, Simplified Arabic was able to render it, but the problem is this font is only made for basic Arabic characters used in Arabic language without any extended coverage to other Arabic-based characters which I suppose that the intention MediaWiki:Common.css to use fonts covering all Arabic-based characters. The only one font to render all Arabic-based texts is Scheherazade, but it does not display clearly without ClearType and without enlarging the font-size too much. (Wikimedia has an error) I also noticed another error with Amiri apart from it is not a naskh style as it claims, it also displays الْظِلِّ / ظِلٍّ šadda+(tanwīn) kasra not near each other but the (tanwīn) kasra is displayed under the letter as if there was no šadda. The dilemma can be mitigated if we split the specification that sums all Arabic-based texts under one specification, because we won't have a practical solution. --Mahmudmasri (talk) 04:29, 26 November 2013 (UTC)

Attention! Wikimedia has an error
The common intuitive practice is to type first the šadda (since the vowel isn't added before geminating the consonant), then the fatḥa/kasra/tanwīn fatḥa/tanwīn kasra. Wikimedia projects change the order to first fatḥa/kasra/ḍamma/tanwīn fatḥa/tanwīn kasra/tanwīn ḍamma, then the šadda. Even if I attempted to write them according to the common practice and according to what may appear properly on more fonts! I'll use the Unicode points to force the intended rendering. I want to scream :) Arial and Times New Roman rendered the diacritics as expected. I knew there was something wrong, since OpenOffice rendered them normally! Would someone please (Michael Z?) check with Geeza Pro since I don't have Mac.

As WikiTiki89 noted: MediaWiki reorders them so that the fatha comes before the shadda --WikiTiki89

I forced the diacritics to display properly by writing the line as

And rendered from right to left:

--Mahmudmasri (talk) 08:21, 26 November 2013 (UTC)

 * I think Geeza Pro isn’t quite working. See this screenshot of the above table row.

 * By the way, sometimes Microsoft products hard-code fixes to work around their built-in fonts. On Wikipedia we had to have a little information campaign going to get editors to enter double tie bars like /t͡ʃ/ according to Unicode, rather than rendering correctly in the buggy Arial Unicode MS font. Eventually, the font got fixed, and Wikipedia still works. —Michael Z. 2013-11-26 23:08 z

 * Thanks for the screen shot. --Mahmudmasri (talk) 09:31, 27 November 2013 (UTC)

 * Yes, it's an old problem and we have to do some stupid workarounds. See Grease pit. I was also trying to tell you that some of the errors you saw on the conjugation test were not errors but rendering problems. It is difficult to communicate about this, since rendering of diacritics also depends on your OS, browser and preferences here. -Anatoli (обсудить/вклад) 10:52, 26 November 2013 (UTC)

 * There should be somewhere to file a bug. We simply shouldn't be suffering that much to write simple diacritic combinations. I also noticed that Wikimedia swapped some rarer Hebrew glyphs with other more popular characters, but it wasn't a huge issue, at least I though so, as it was like substituting וּ (&#xfb35;) with what looked the same as וּ (&#x05d5;&#x05bc;). --Mahmudmasri (talk) 12:56, 26 November 2013 (UTC)
 * That's because וּ (&#xfb35;) is not supposed to be used directly. Nothing in the Alphabetic Presentation Forms block is supposed to be used directly. Same with the Arabic Presentation Forms-A and Arabic Presentation Forms-B. --WikiTiki89 16:43, 26 November 2013 (UTC)

 * We did file several bug reports about the problem (see bugzilla), but Wikimedia cannot do anything to fix it. It is not a Wikimedia error, it is a problem with Unicode itself. When Arabic was originally encoded in Unicode, they had to put the letters and symbols in the correct alphabetic and orthographic order. The letters are in the correct order, but they put the shadda after the vowels, and this is what causes the problem. It is now too late for the Unicode order to be changed. Some new Arabic fonts are designed to work with the shadda and vowel in either order, but as far as I know, most free Arabic fonts are old and require that the diacritics be in the proper order. —Stephen (Talk) 13:17, 26 November 2013 (UTC)
 * Unfortunately, we have to use workarounds - templates and modules, which will fix the order. If diacritics are only used in headwords and inflections, it should be possible, IMHO. Some problems are harder than others. Hopefully we find enough skilled people. --Anatoli (обсудить/вклад) 13:36, 26 November 2013 (UTC)

 * Esperanto Wikipedia displays the sequences of cx, gx, hx, jx, sx, ux as ĉ, ĝ, ĥ, ĵ, ŝ, ŭ (respectively) and when they are written in the editor as ĉ, ĝ, ĥ, ĵ, ŝ, ŭ, they are always converted in the editor to cx, gx, hx, jx, sx, ux, but still display on page as ĉ, ĝ, ĥ, ĵ, ŝ, ŭ. Can't that method help? --Mahmudmasri (talk) 13:29, 26 November 2013 (UTC)

This is reminiscent of a very similar problem we had with Hebrew cantillation marks. If we look at the canonical combining classes of Arabic, we see this:

 * all Arabic consonants: 0
 * fathatan: 27
 * dammatan: 28
 * kasratan: 29
 * fatha: 30
 * damma: 31
 * kasra: 32
 * shadda: 33
 * sukun: 34

I believe this is an error. Normally, all diacritics that go above the consonant and all that go below the consonant should each share one combining class, as is the case with Latin diacritics. Unicode however assigned ascending combining classes for the Arabic vowel marks, so they will always be sorted into this specific order when normalization is performed. As such, the only way to specify a different order from the above is to use HTML entities. -- Liliana • 14:40, 26 November 2013 (UTC)

 * A better solution is not to reorder the diacritics, but to choose fonts that display them properly in either case. --WikiTiki89 16:19, 26 November 2013 (UTC)

 * I think we should do both. Certainly, putting the diacritics in the right order is good. Having a font that can display them even in the wrong order is also good. - -sche (discuss) 16:27, 26 November 2013 (UTC)

 * Waging war against Unicode is useless. Unicode is too big. --WikiTiki89 16:34, 26 November 2013 (UTC)

Also, I'm not sure that anyone is suggesting permanently making this change. Someday, most people will have fonts that really do treat the orders as equivalent. The goal here is to improve the user experience in the meantime. —Ruakh TALK 18:49, 26 November 2013 (UTC)
 * WTF? No one is suggesting "waging war against Unicode". The official Unicode position is that the two orderings are equivalent, and Unicode specifies rules for choosing one order over the other when performing normalizations (for equality-comparisons and so on). MediaWiki performs those normalizations in various places, e.g. when a page is saved; but if we undo that by changing the order in Lua (and using HTML entities to make it stick), that can hardly be considered a war on Unicode. At best it's a war on a minor MediaWiki feature.

 * Don't worry if I make silly comments once in a while. Anyway, I guess it's not a big deal. I do have one question though: How are things like Google Search affected by having HTML escapes rather than text in the HTML? --WikiTiki89 18:56, 26 November 2013 (UTC)

 * I'm sure that Google processes HTML escapes just fine; it would really be shocking if it didn't. (And I know from experience that it doesn't care about diacritic order; presumably it converts all inputs to NFC, or perhaps NFKC, before performing the comparisons.) —Ruakh TALK 21:22, 27 November 2013 (UTC)

I don’t fully understand this conundrum. Is the usual order of the characters a result of the way they are normally typed? Does that follow the order in which they are handwritten? Is the order that displays better in some fonts incorrect, or simply not customary? Does the order that displays more reliably display correctly in all fonts, or only in the “broken” fonts?

No, we should not go against the Unicode standard to work around font bugs. That is backwards, in effect forking Unicode, risking a situation where we make broken fonts work while breaking the display in good fonts, other in some present or future browser, database, or other system.

If, on the other hand, the proposed encoding method is good Unicode but awkward text entry, that could be workable. We can have a style guide that recommends the best technical way to enter text. And/or a bot that twiddles the characters. Or a text filter built into wikitext. Templates and Lua can help, but they are a supplement to wikitext, not a replacement for it. —Michael Z. 2013-11-26 22:55 z

 * Er, your first paragraph doesn't really make sense. I'm not sure if you're trying to push-poll, or if you're just so confused that you can't formulate the right questions.
 * In relevant cases, there are two possible orders:
 * The linguistically/logically correct order.
 * The order that results from taking the linguistically correct order and converting it to Unicode's 'Normalization Form C' (NFC).
 * Unicode requires renderers to treat the latter as equivalent to the former, but few present-day systems fully do that, with the result that you can sometimes take text that renders perfectly, convert it to NFC, and get back text that renders incorrectly.
 * (There's also a very rare case where NFC is just completely wrong and sucky, but I don't think that case affects Arabic. It comes up in a few places in the Hebrew Bible.)
 * For Unicode's take, see http://www.unicode.org/faq/normalization.html. You'll note that they don't deny that NFC orders diacritics in an illogical way; their contention is simply that it shouldn't matter how illogical the order is. Unfortunately, fonts have not caught up with this contention.
 * (And it's been this way for a long time. I'm confident that fonts and rendering systems will eventually comply with this requirement, but they're clearly taking their time.)
 * —Ruakh TALK 23:54, 26 November 2013 (UTC)

 * Thanks for the explanation. I have read some of the links and have a better understanding. I must have been confused, because I still don’t know what I would have been push-polling for.

 * More questions: does MediaWiki NFC-normalized wikitext, or only normalize the rendered text on the page? Is it possible to enter text with a combining grapheme joiner or something to preserve the logical order and/or make the older fonts work? —Michael Z. 2013-11-27 22:24 z

 * Re: what you would have been push-polling for: Your questions seemed to presuppose that the NFC order is "usual", and that alternative orders are "not customary" if not outright "incorrect"; but because you never explicitly referred to "NFC", it was hard to be sure, and therefore hard to reply coherently. (But I'm sorry: I failed to A as much GF as I should have.)
 * Re: MediaWiki: As far as I can tell, it performs this normalization on all text entry (even "Show preview" or "Show changes" reorders the diacritics in the edit-window), as well as on any text passed into or out of Lua. It does not seem to perform it on arbitrary rendered text — for example, inserting  between two diacritics does prevent it from reordering them, at least on preview — but the final substitution of   comes very late in the processing, and I haven't really investigated to see if there is an earlier pass that does do it and that   slyly bypasses. (For example, would something like   get reordered, if those were templates that generated those characters? I have no idea.)
 * Re: combining grapheme joiner: As of a few years ago, that had bizarre effects in all systems I tried it on. I rather doubt there's been much improvement on that point, since it's an even rarer case than NFC, but we can certainly try it out.
 * —Ruakh TALK 01:33, 28 November 2013 (UTC)

Conclusion
Arabic language is specified in Wikipedia with "ar" (corrected: "ar"), why can't we just specify Arabic with this class rather than the generic "Arab" which applies to all Arabic-based texts? --Mahmudmasri (talk) 09:27, 27 November 2013 (UTC)
 * 1) In case the Unicode reordering can't be fixed, we may use the method of displaying specific sequences of text in the editor in a specific manner, as in the case of Esperanto Wikipedia, displaying cx, gx, hx, jx, sx, ux as ĉ, ĝ, ĥ, ĵ, ŝ, ŭ (respectively), so that the erroneous Unicode order of (fatḥa/kasra/ḍamma/tanwīn fatḥa/tanwīn kasra/tanwīn ḍamma then šadda) be displayed properly as (šadda then fatḥa/kasra/ḍamma/tanwīn fatḥa/tanwīn kasra/tanwīn ḍamma), because some basic fonts which render almost all Arabic-based characters would be safely used. The font-family would be:
 * 2) In case the previous suggestion was regrettingly not implemented then we must split the font specification so that what applies for Arabic language would not apply for other languages that need other fonts which won't display Arabic properly. Please note that the style  of KacstOne is not normative, it is a mixture of naskh and riqʿa, also it has an error in displaying the šadda+kasra or šadda+tanwīn kasra, but I'm adding it as it is the only known Linux font for Arabic with the least errors, in case for some reason the browser couldn't download Iranian Sans font. Then the font-family would be:

 * Arabic is not specified with "ar" but with "ar", which in CSS is a "pseudoclass". Pseudoclasses are not supported in some browsers (apparently some not-too-old versions of Internet Explorer). --WikiTiki89 21:13, 27 November 2013 (UTC)

 * We should use as few fonts as possible, whether user fonts or web fonts, for consistent visual design, economy, and simplicity. As browsers’ and OSes’ language support improves, the number of fonts we specify should diminish towards 1, rather than increase towards one for each of 1,100 languages.

 * We should use one Arabic font for all Arabic-script languages, if it were possible. Anyway, we should perform an exercise like this one for each of our font specs, and remove all of the font names that don’t help anybody. —Michael Z. 2013-11-28 00:37 z

 * I lost half of the discussion (too much jargon and other reasons) but it may not be possible or necessary to use one font for each Arabic-script languages - as letters and styles are also different. Arabic uses more diacritics than others but only in dictionaries, books for children and learners, some think thank that Persian and Urdu should not use them at all and there's not much material with diacritics in this languages, even dictionaries uses diacritics separately from words to indicate pronunciation. Urdu is written with different fonts, it's using "nastaʿlīq", even though other common Arabic scripts are also common on the web. Uyghur is fully phonetic. Anyway, my point is, languages other than Arabic use diacritics rarely and use of double diacritics is even less common. The use of diacritics and fonts for Persian and Urdu, etc. can be decided separately.
 * Agree that tests should be conducted. I'm waiting for technical solutions, which I could apply to Module:ar-verb, which will use double diacritics quite often.

--Anatoli (обсудить/вклад) 01:07, 28 November 2013 (UTC)

 * Why is this discussion becoming longer than it should? Michael Z, I agree with what you wrote and when browsers develop much more, there won't be any need to specify fonts at all. The only practical solution was the number 2 suggestion, I guess. Please do not ignore it. I don't want to repeat again that what applies to what is used in Arabic language isn't applied to other languages written in Arabic-based script. The few fonts which challenge the Wikimedia's errors are fonts that don't render other characters used in other language other than Arabic language, so we can't use the generic "Arab" anymore even if we all wished in a perfect world but we can't and we can't use the few fonts for Arabic language with other languages written in Arabic-based script, and vice versa. --Mahmudmasri (talk)

 * Yes, okay. One font is an ideal, not a realistic suggestion. I would also encourage versatile fonts at the top of each stack, so that different languages are more likely to be rendered in the same font if it is available. Aren’t diacritics a matter of spelling? —Michael Z. 2013-11-28 04:44 z

 * That was what I tried to do, by putting first the fonts that are likely to be found on most operating systems... Taškīl is another spelling that is needed in cases like with a dictionary to explicitly demonstrate pronunciation. --Mahmudmasri (talk) 06:03, 28 November 2013 (UTC)

 * What I mean is putting the fonts that can be used for other Arabic-script languages first.

 * Aside from that, we want the best-quality, specialized fonts first. I don’t see any reason to prioritize fonts for their wide distribution. —Michael Z. 2013-11-28 15:12 z

 * Regarding Arabic language, the three of Arial Unicode MS, Simplified Arabic and Iranian Sans display, the basic Arabic letters and taškīl, equally fine. --Mahmudmasri (talk) 03:13, 29 November 2013 (UTC)

fatḥatān-alif or alif-fatḥatān
Split from above
 * As a side-note and a related qiuestion, the use of fatḥatān-alif (indef. accusative or adverbial suffix -an) has been bugging me for some time, e.g. (šukran) where alif (ا) is preceded by fatḥatān diacritic (it sits over rāʾ (ر), not alif), is considered standard by many Arabic grammarians but not all. Some write this combination in a different order:  (note that fatḥatān sits over alif, not rāʾ), which is alif-fatḥatān, which is also common on the web and was borrowed (incorrectly?) into Persian. If the rule fatḥatān-alif (in this order) is confirmed, then perhaps we should rearrange all entries and translations to follow this. According to, Persian uses the reverse order. The order of diacritics, including fatḥatān-alif will also affect the automatic transliteration by Module:ar-translit, which still needs attention. (It can correcly transliterate fully vocalised words only.) --Anatoli (обсудить/вклад) 01:07, 28 November 2013 (UTC)
 * Yes,, in Persian the rule is to strictly place the fatḥatān over the alif. That is the rule mentioned by the Academy of Persian Language and Literature and is mentioned in several Persian learning books, such as Basic Persian: A Grammar and Workbook (p. 13). I believe the same is true for Urdu, even though the tanween is used less often in Urdu than in Persian. --Dijan (talk) 09:49, 29 November 2013 (UTC)
 * Personally I have never encountered fathataan-alif alif-fathataan in fully vocalized text. I have only seen it in ordinary vowel-less text that has the occasional shadda and fathataan. --WikiTiki89 02:28, 28 November 2013 (UTC)
 * I'll let you know when I find discussions and rules described by native speakers. --Anatoli (обсудить/вклад) 02:35, 28 November 2013 (UTC)
 * I couldn't find the related discussion on Word Reference forum but you'll see that Wikipedia article on iʿrāb uses fatḥatān-alif order. Will check my grammar book later. I'm pretty sure it uses this order but not sure if it's actually described. As I said before, alif-fatḥatān is also common, even Yamli editor produces شكراً when you type "shukran". Also, some Arabs think that this is the case (adverbials and accusative) when a diacritic is usually written, which can be easily confirmed. --Anatoli (обсудить/вклад) 02:46, 28 November 2013 (UTC)
 * Sorry, I meant the other way around. I corrected myself above. --WikiTiki89 03:36, 28 November 2013 (UTC)
 * The tanwīn fatḥa is most often written by hand on the alef, also the same way on the internet, although some argue that the tanwīn fatḥa should be placed on the penultimate letter. --Mahmudmasri (talk) 02:47, 28 November 2013 (UTC)
 * I am more convinced about the latter, i.e. "tanwīn fatḥa (fatḥatān) should be placed on the penultimate letter" and the other being a common mistake (which may have also become the new rule). There seems to be too camps about this rule. I'll try to provide more info on this. --Anatoli (обсудить/вклад) 03:50, 28 November 2013 (UTC)

 * I couldn't get written confirmation on the order of diacritics yet ( vs  ) but my Oxford English-Arabic dictionary and "A Student Grammar of Modern Standard Arabic" both place tanwīn fatḥa on the preceding consonant, not alif. --Anatoli (обсудить/вклад) 01:36, 29 November 2013 (UTC)

 * If you think of it as applying to the penultimate letter, it would work correctly for most Arabic words after adding the accusative alif, but not for words that end in ء or ة. Words ending in hamza or taa marbuta take the double fatha without alif, and it is placed over the hamza or taa marbuta itself, not a penultimate letter: سحابةً, سماءً. Double fatha is like single fatha...it is placed over the consonant, not over the alif: رَا , رًا. —Stephen (Talk) 21:36, 29 November 2013 (UTC)
 * Thank you, Stephen. I haven't mentioned ة or ء because they are not controversial. Do you have a source, which would explain the official rule for spelling tanwīn fatḥa and alif? --Anatoli (обсудить/вклад) 23:55, 29 November 2013 (UTC)

 * Over the course of years, I have seen it many times. It’s hard to lay hands on it at the very moment when you want it. More often, it is demonstrated rather than stated, as in this youtube video. Often it is stated in a roundabout fashion, as in this pdf where, on page 3, they say "Fathatain generally has a long vowel letter Alif." The phrase "long vowel letter Alif" refers to the alif of prolongation, and that is what they call the alif in a word such as, and the alif of prolongation is really just a diacritic itself...it is not a letter that can carry a vowel point. In this forum post, the author states that "Alif always comes after the Fatha or Tanween Fatha on the previous letter." —Stephen (Talk) 02:28, 30 November 2013 (UTC)

No progress?
Months passed and no one seems to care to correct the style mistakes, even after giving numerous options. --Mahmudmasri (talk) 16:51, 17 January 2014 (UTC)
 * I just went ahead and added Iranian Sans to the Arabic fonts. --WikiTiki89 17:07, 17 January 2014 (UTC)

Follow up
The font Traditional Arabic [//en.wiktionary.org/w/index.php?title=MediaWiki:Common.css&diff=prev&oldid=25050550 needs to be removed], because, if for some reason, the Iranian Sans font wasn't downloaded by the browser, Traditional Arabic displays the Arabic text, which is small and incomplete. I got that complaint about the page سحر, then I made a test. Seeing the page without signing in, the Arabic text was displayed with Traditional Arabic. Why and who chose to add it anyway?! --Mahmudmasri (talk) 04:24, 21 November 2015 (UTC)

 * You can change size by using a command like this: font-size: 150% ... but if Traditional Arabic is incomplete, then it's no good. Currently the Arabic fonts are: Arial Unicode MS, Code2000, Traditional Arabic. What would you suggest?
 * My PC came with these Arabic fonts installed: Aldhabi, Andalus, Arabic Typesetting, Arial, Courier New, Microsoft Sans Serif, Sakkal Majalla, Segoe UI, Simplified Arabic, Tahoma, Times New Roman. I don’t know if PC's sold in Europe or Africa come with different Arabic fonts or not. —Stephen (Talk) 22:16, 22 November 2015 (UTC)

 * I checked on Wikipedia to see what they used. This is from Wikipedia:
 * —Stephen (Talk) 22:34, 22 November 2015 (UTC)

 * I have no problems at all and I'm customizing my fonts, but I wrote that someone complained and I checked to use Wiktionary without signing in, Iranian Sans wasn't downloaded. I also suggested before to have that list in order:

{ font-family: "Arial Unicode MS", Arial, "Iranian Sans", sans-serif; }
 * --Mahmudmasri (talk) 00:59, 26 November 2015 (UTC)
 * By the way, Traditional Arabic has a mixed reqʕa with naskh style. --Mahmudmasri (talk) 01:34, 27 November 2015 (UTC)

Broken style on iPhone and iPad
Just letting you know, if it's related, that formatted Arabic and Urdu fonts are not displayed correctly on iPhones and iPads (but Persian looks OK), the letters look disconnected. Whatever the reason was for using these fonts, it broke something else. --Anatoli T. (обсудить/вклад) 01:03, 26 November 2015 (UTC)

 * Which fonts did you use on which applications? And by the way, Urdu is usually preferred to be displayed in Nastaliq fonts. --Mahmudmasri (talk) 01:49, 26 November 2015 (UTC)

 * I didn't choose any fonts, I'm just saying what I observe. Agreed about Urdu but I haven't set up any fonts for Urdu. Wiktionary's templatised Arabic and Urdu are not displayed correctly on those devices. --Anatoli T. (обсудить/вклад) 07:01, 26 November 2015 (UTC)

 * Are you sure it has nothing to dow with your customized styles as this one, User:Atitarev/common.js? Does that happen when you are signed in? Do you a page as to demonstration the issue? --Mahmudmasri (talk) 23:25, 26 November 2015 (UTC)

 * No, it has nothing to do with User:Atitarev/common.js, it has no font settings. I have tried signing out with the same result. I don't have a demo page but you can try an iPad or an iPhone or ask someone. Untemplatised مجلة looks OK but looks disconnected. --Anatoli T. (обсудить/вклад) 23:34, 26 November 2015 (UTC)

 * Disconnected like that, م ج ل ة (letters can't be joined together) or like that, مـ جـ ـلـ ـة (letter-spacing is added which is incompatible with cursive scripts, or a kerning issue)? Does it happen with adding diacritics or in all cases? It may be an error related to the template:ar-noun and its hidden lua pages that I don't know where to find :) --Mahmudmasri (talk) 23:52, 26 November 2015 (UTC)
 * More like the former but letters are closer, as if ZWNJ is inserted between letters. It happens with diacritics and without, for all parts of speech. It may not be an easy task, perhaps it's better to make it noticeable at Grease_pit/2015/November. --Anatoli T. (обсудить/вклад) 23:57, 26 November 2015 (UTC)

 * Sorry that I can't help, but at least we defined the problem. --Mahmudmasri (talk) 01:29, 27 November 2015 (UTC)

Don't be sorry. I have opened a topic here: Grease_pit/2015/November --Anatoli T. (обсудить/вклад) 02:00, 27 November 2015 (UTC)
 * BTW, the "hidden" Lua page in question is Module:ar-headword, although I don't think it's an issue with that as there's nothing platform-specific in the code. Benwing2 (talk) 03:29, 27 November 2015 (UTC)

This appears to be a problem with Arial Unicode MS in the font list. If I set up a user css for myself then it works fine again on my iPad with this font removed. I think default Apple fonts like Damascus probably should go in the font list before anything Microsoft related because they have no MS equivalents and it seems the MS fonts that Apple includes may have problems. — Radixcc 📞 01:19, 10 July 2017 (UTC)

Teng, Lina
Note: the ISO-approved codes for Tengwar and Linear A have been added to Module:scripts. Both are expected to be encoded into Unicode soon (but have not been assigned fixed codepoints yet, it seems). Once they are encoded and supported by fonts, we can modify this stylesheet. - -sche (discuss) 02:18, 20 December 2013 (UTC)
 * We can assign empty styles to them for now. That way they're styled the same as Latn/None. 02:52, 20 December 2013 (UTC)

 * Why is it presumed that any styles will be necessary? Doesn’t your browser display all characters with a supporting font, if one is available? —Michael Z. 2013-12-20 17:58 z

 * The script codes which have been [//en.wiktionary.org/w/index.php?title=Module%3Ascripts%2Fdata&diff=24346137&oldid=24180296 added] in the past few days are: Afak and Aghb (not included in Unicode), Bass (proposed to be—but not yet actually—included in Unicode), Dupl and Teng (provisionally included in Unicode), Elba and Lina and Tang (said to be being added to Unicode, Tang perhaps more slowly than the others), Geok (already present in Unicode; see also Grease pit/2013/December), Hmng (proposed for inclusion in 1999 but not yet included in Unicode), and Maya. - -sche (discuss) 23:58, 21 December 2013 (UTC)
 * Just added: Inds, Mend. - -sche (discuss) 09:01, 23 December 2013 (UTC)

External links icons removed
Hello! If this CSS adds or modifies icons shown after external links, you'll be interested in knowing that such icons have been removed from MediaWiki core, a change which will reach this wiki in few days. You may want to consider whether you still need them. If you have questions, please ask at 63725. Regards, Nemo 09:45, 10 April 2014 (UTC)

Font support for Latin Extended-D
Quivira 4.0 provides complete support for the Latin Extended-D block, AFAIK, and is a free font. Is there a way of having en.wiktionary.org use that font display the characters in this range (U+A720–U+A7FF)? — I.S.M.E.T.A. 17:11, 30 June 2014 (UTC)

 * Out of curiosity, what languages or entries actually use those characters? --WikiTiki89 17:41, 30 June 2014 (UTC)

 * ꝯ (Old Portuguese and Translingual), perhaps others. — I.S.M.E.T.A. 17:47, 30 June 2014 (UTC)
 * Also, Old English uses ꝥ. — I.S.M.E.T.A. 10:27, 20 July 2014 (UTC)
 * Plus, Latin uses ꝑ (see ). — I.S.M.E.T.A. 21:43, 30 July 2014 (UTC)

(pinging: Keφr, Yair rand, CodeCat, Ruakh, Kenny, ZxxZxxZ from workgroup )

 * Is there a way to use a font only for specific Unicode blocks? Would it be worth creating a new script code roa-ptg-Latn or perhaps a more general Medieval Latin script code that would support characters like these? --WikiTiki89 17:59, 30 June 2014 (UTC)

 * How about just  for the characters "꜠| ꜠-ꟿ"? — I.S.M.E.T.A. 10:13, 20 July 2014 (UTC)

 * We have  for this already.  10:29, 20 July 2014 (UTC)

 * Can we add Quivira to 's list of fonts? — I.S.M.E.T.A. 10:31, 20 July 2014 (UTC)

 * Where in the list should it be added? 10:42, 20 July 2014 (UTC)

 * I don't understand the significance of the list order. — I.S.M.E.T.A. 21:56, 20 July 2014 (UTC)

 * It's a priority list. If the first font is not available, it tries the next, and so on. So where you place this new font will determine what priority it has. 22:14, 20 July 2014 (UTC)

 * I see. What are the character ranges covered by ? This is a list of the characters supported by Quivira 4.0; what priority that font should get ought, I should think, to depend on how exhaustively it supports  's characters ranges, compared with the other fonts in the list. — I.S.M.E.T.A. 23:44, 20 July 2014 (UTC)

 * I found 's character ranges; they are the same as  's. Those ranges are "0-z¡-ɏḀ-ỿ"; i.e., 0–z (U+00030–U+0007A: the Basic Latin block except for its final five characters, viz. ,  ,  ,  , and the DELETE control character at codepoint U+0007F), ¡–ɏ (U+000A1–U+0024F: the Latin-1 Supplement, Latin Extended-A, and Latin Extended-B blocks, except for the first thirty-three characters of the Latin-1 Supplement block, viz. thirty-two control characters and the NO-BREAK SPACE character at codepoint U+000A0), and Ḁ–ỿ (U+01E00–U+01EFF: the Latin Extended Additional block).   and therefore, by consequence,   do not cover either the Latin Extended-C block (Ⱡ–Ɀ = U+02C60–U+02C7F) or the Latin Extended-D block (꜠| ꜠–ꟿ = U+0A720–U+0A7FF). Would the solution to this font-support problem be simply changing the statement in Module:scripts/data for the characters covered by   from "0-z¡-ɏḀ-ỿ" to "0-z¡-ɏḀ-ỿⱠ-Ɀ꜠-ꟿ"? — I.S.M.E.T.A. 12:29, 30 July 2014 (UTC)

 * Probably, yes, if those character ranges are supported by the fonts currently set for Latinx. —CodeCat 15:51, 30 July 2014 (UTC)

Here is those fonts' support for those character ranges, according to KreativeKorp: In the light of this survey, I propose two things: Do those changes sound reasonable to you, CodeCat? And, if so, could you implement them, please? — I.S.M.E.T.A. 19:00, 30 July 2014 (UTC)
 * TITUS Cyberbit Basic — U+00030–U+0007A: complete; U+000A1–U+0024F: complete coverage of Latin-1 Supplement and Latin Extended-A, 183 of 208 characters in Latin Extended-B supported (U+00237–U+0024F unsupported); U+01E00–U+01EFF: 247 of 256 characters in Latin Extended Additional supported (U+01E9D–U+01E9F and U+01EFA–U+01EFF unsupported); U+02C60–U+02C7F: no coverage of Latin Extended-C; U+0A720–U+0A7FF: no coverage of Latin Extended-D — TITUS Cyberbit Basic leaves 218 characters unsupported.
 * Junicode — U+00030–U+0007A: complete; U+000A1–U+0024F: complete coverage of Latin-1 Supplement and Latin Extended-A, 185 of 208 characters in Latin Extended-B supported (U+00234–U+00236, U+00240–U+00247, and U+00250–U+0024F unsupported); U+01E00–U+01EFF: complete; U+02C60–U+02C7F: 5 of 32 characters in Latin Extended-C supported (U+02C60–U+02C70, U+02C74, and U+02C77–U+02C7F unsupported); U+0A720–U+0A7FF: 97 of 152 characters in Latin Extended-D supported (U+0A720–U+0A725, U+0A72A–U+0A72F, and U+0A788–U+0A7FA unsupported) — Junicode leaves 115 characters unsupported.
 * Code 2000 — U+00030–U+0007A: complete; U+000A1–U+0024F: complete; U+01E00–U+01EFF: complete; U+02C60–U+02C7F: 29 of 32 characters in Latin Extended-C supported (U+02C70 and U+02C7E–U+02C7F unsupported); U+0A720–U+0A7FF: 114 of 152 characters in Latin Extended-D supported (U+0A78D–U+0A7FA unsupported) — Code 2000 leaves 41 characters unsupported.
 * Microsoft Sans Serif — U+00030–U+0007A: complete; U+000A1–U+0024F: complete; U+01E00–U+01EFF: 247 of 256 characters in Latin Extended Additional supported (U+01E9C–U+01E9D, U+01E9F, and U+01EFA–U+01EFF unsupported); U+02C60–U+02C7F: 21 of 32 characters in Latin Extended-C supported (U+02C6E–U+02C70 and U+02C78–U+02C7F unsupported); U+0A720–U+0A7FF: 7 of 152 characters in Latin Extended-D supported (U+0A722–U+0A787 and U+0A78D–U+0A7FF unsupported) — Microsoft Sans Serif leaves 165 characters unsupported.
 * Quivira — U+00030–U+0007A: complete; U+000A1–U+0024F: complete; U+01E00–U+01EFF: complete; U+02C60–U+02C7F: complete; U+0A720–U+0A7FF: 134 of 152 characters in Latin Extended-D supported (U+0A794–U+0A79F and U+0A7AB–U+0A7F7 unsupported) — Quivira leaves 18 characters unsupported.
 * 1) that Quivira be added to  's font set, and that that list be reorganised thus:  ; and,
 * 2) that the statement in Module:scripts/data for the characters covered by   be changed from   to.

 * They do sound reasonable, but I don't know enough about font and character specific issues to make a good judgement on it. I'll make the change, but if it causes problems please (whoever reads this) revert and discuss it further here. —CodeCat 21:55, 30 July 2014 (UTC)

 * Thank you very much. — I.S.M.E.T.A. 22:01, 30 July 2014 (UTC)

 * Sorry to bother you with this again. The change seems to have worked in part, but not completely. I think the remaining display problems (for Latin and Old Portuguese) can be fixed by changing the script statement for  (in Module:languages/data2) and   (in Module:languages/datax) from   to  . Could you make these two small changes, please? — I.S.M.E.T.A. 17:55, 1 August 2014 (UTC)

 * I think that's a more radical change, I'm not sure if I should be making that singlehandedly. —CodeCat 18:12, 1 August 2014 (UTC)

 * Shall I start a discussion about this somewhere? Perhaps in the Beer Parlour? — I.S.M.E.T.A. 18:29, 1 August 2014 (UTC)

 * Switching the script codes of those two languages from codes that don't support all of their characters to codes that do would not, in and of itself, seem to be controversial; I would switch the codes myself if it weren't for the next sentence I'm about to write. The question that I can forsee might be controversial is: do we want to have entries like at all? We don't have entries for long s spellings, or for the joined-c-t spellings Doremítzwr was so fond of. OTOH, we do allow people to preserve the long s when typing up citations if they choose to, and if ꝑ were likewise preserved, there would be a need for a font to support it regardless of whether or not it got an entry. I suppose soliciting comments/views in the BP is the best plan. - -sche (discuss) 20:43, 2 August 2014 (UTC)

 * I remember finding and changing (to plain r) 2-4 instances of r rotunda in the past couple of years; I don't recall if they were in entry titles or in citations. - -sche (discuss) 20:46, 2 August 2014 (UTC)

 * Liliana brought up the issue of in the RFD discussion for ; I don't believe that  and  are analogous, but I suppose that discussion's best kept in one place (RFD). Re the r rotunda ( and ), that letter, as far as I'm aware, is analogous with  (assuming, as I do, that in every case  or  can be correctly converted to  or, respectively, without error), which means that I agree with you that r rotundae should not occur in entry titles (because entry titles with r rotundae should autoredirect to entry titles with ordinary ars); however, just like , they should occur in citations (provided the source text uses them), as in the case of the work I cited for , which is entitled Summa philoſophie naturalis magiſtri Pauli veneti nouiter recognita ⁊ a vitĳs purgata ac pꝛiſtine integritati reſtituta [sic]. Perhaps we disagree, but I hope that my rationale at least makes sense. Re the proposed Beer Parlour discussion, that may lead on organically from the RFD discussion; if it doesn't, I'll probably start the BP discussion after the RFD discussion has concluded. — I.S.M.E.T.A. 01:02, 3 August 2014 (UTC)

 * We can compromise and add "Latinx" as a second script for Latin. We won't use the characters in entry titles, but if we put them in quotations, the auto-detect script would (or should) identify "Latinx" characters and use that as the script only in those cases. --WikiTiki89 21:18, 2 August 2014 (UTC)

 * If we do that, then Latin script will appear twice on Category:Latin language. We probably don't want that, so we need to work around such things. I've been thinking about cases like this for a while and I think that it would be best if our data modules made a distinction between scripts for the purpose of listing the scripts of a language, and scripts to be available for autodetection, but not listed. So maybe an additional property like ? There are other cases that would benefit from that as well, like pinyin for Chinese. It's not really a proper script, but we do want autodetection to work for it. Of course, alternatively, autodetection could just try all scripts, but that would make it slower. —CodeCat 21:30, 2 August 2014 (UTC)

 * Honestly, that's not a big deal. We can add a way to override the text, or the module could check whether any scripts have the same name, or we could just leave it as "Latin and Latin scripts". Regardless, it's not a reason not to use right scripts in the mainspace. --WikiTiki89 22:09, 2 August 2014 (UTC)

 * I foresee a minor aesthetic issue with using  only for Latin Extended-C and -D characters occurring in Latin whilst using   for Basic Latin, Latin-1 Supplement, Latin Extended-A and -B, and Latin Extended Additional characters, sc. we may see an unsightly mismatch of fonts (e.g., a sprinkling of Quivira in the midst of Times New Roman at best, or maybe a far uglier mix of Tahoma and Code 2000). It's not a big issue, but it's certainly a disadvantage of using two scripts. What, OTOH, is the advantage of using the two scripts? — I.S.M.E.T.A. 01:19, 3 August 2014 (UTC)

 * The question that I can forsee might be controversial is: do we want to have entries like at all? - No. Hold on while I start an RFD discussion on the matter. -- Liliana • 21:35, 2 August 2014 (UTC)

N.b., since the recent version 4.1 update, Quivira now supports completely both the and  Unicode character blocks. doesn't currently encompass Latin Extended-E, but I assume it should. Accordingly, could someone who can please change the character statement for  in Module:scripts/data from "0-z¡-ɏḀ-ỿⱠ-Ɀ꜠-ꟿ" to "0-z¡-ɏḀ-ỿⱠ-Ɀ꜠-ꟿꬰ-ꭥ"? ? ? ? — I.S.M.E.T.A. 20:20, 8 September 2014 (UTC)

 * ✅ in [//en.wiktionary.org/w/index.php?title=Module%3Ascripts%2Fdata&diff=28963736&oldid=27964751 diff]. :) - -sche (discuss) 20:24, 8 September 2014 (UTC)

 * Thanks, -sche. — I.S.M.E.T.A. 02:21, 9 September 2014 (UTC)

hlist
At Beer_parlour/2014/September, it has been suggested that we could copy the rules for the class hlist from en.WP's w:MediaWiki:Common.css in order to improve(?) the display of Template:authority control. Please chime in there if you see a reason why this should or shouldn't be done. - -sche (discuss) 20:09, 16 September 2014 (UTC)
 * As the original requester; I (obviously) support this; I also note a similar request, above. The class would be available for other uses, too. You might like to copy the styles for the sister class plainlist, at the same time. Pigsonthewing (talk) 14:46, 17 September 2014 (UTC)
 * May I nudge people on this? Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 15:45, 21 April 2016 (UTC)

Script to force de-italicisation
Is it possible to have a  script added which is equivalent to   but with  ? This would allow de-italicisation inside templates like. — I.S.M.E.T.A. 08:59, 23 April 2015 (UTC)

CJK fonts
The fonts used the classes "Hans", "Hant", "Kana", "Hang" and more ones about CJK characters, like "SimSun" and "Gulim" are very old. Those are not hinted fonts. There are newer MS/non-MS fonts like "Microsoft YaHei" and "Malgun Gothic", or "Noto Sans CJK CN/TW/JP/KR" and so on. How about changing CJK fonts used in this CSS? -&bahn (talk) 11:28, 7 May 2015 (UTC)
 * The newer fonts have worse coverage of CJK and lack important characters. "Malgun Gothic" for one does not cover any Hanja, making it next to useless. -- Liliana • 11:31, 7 May 2015 (UTC)
 * I thought others (except Malgun) have enough coverage, and I can't stand those no-hinted fonts. -&bahn (talk) 14:05, 8 May 2015 (UTC)

Avestan
Could you add a font, Noto Sans Avestan, to .Avst ? font-family: Avestan, Ahuramzda, Noto Sans Avestan, sans-serif; --Octahedron80 (talk) 00:28, 14 October 2016 (UTC)
 * Done. Benwing2 (talk) 20:55, 14 October 2016 (UTC)

nowrap
It would be nice if the following class existed: css It exists on Wikipedia, and it would be useful in Module:IPA to keep slashes on the same line as the transcriptions they enclose. — Eru·tuon 00:43, 27 January 2017 (UTC)

Font precedence in .Hani/.Hans/.Hant
Current definition for Han classes uses regional subsets for Source Han Sans only. This is not recommended as they really just cover what a region has. Add their regional (but full) versions before the subsets, that is SC before CN and TC before TW (they seem to call it HW now, maybe change that too?).

The Noto/Source families are probably too far behind in the fallback list. These two families (which are really just one) provide better coverage and accuracy than Microsoft Yahei, especially for things involving unicode updates like 鿃. Consider moving the Microsoft Yahei to just behind Noto in the Hans/Hani list. --Artoria2e5 (talk) 01:22, 25 April 2017 (UTC)

Armenian italics
The selector for de-italicization of Armenian is missing css, which is needed for usage examples. — Eru·tuon 08:06, 14 May 2017 (UTC)
 * Did fix it? —Aɴɢʀ (talk) 13:38, 14 May 2017 (UTC)
 * Yes. Thank you! — Eru·tuon 16:42, 14 May 2017 (UTC)

Polytonic Greek
New Athena Unicode should be at the top of the font stack for the  class. It is the only font that I have tested that properly displays diacritics stacked on top of macrons or breves, like. I haven't specifically tested all the fonts in the current list though. — Eru·tuon 21:47, 8 August 2017 (UTC)
 * I concur. — JohnC5 00:46, 9 August 2017 (UTC)

I propose this code, with New Athena Unicode added at the beginning of the stack for css:

Also the rule contained the code css, which negated the effect of the previous statement, so I have removed it. — Eru·tuon 20:28, 13 September 2017 (UTC)

 * This font is kind of small. I wish there were a way to set font-specific sizes (i.e. sizes that would only apply if that particular font is actually being displayed). --WikiTiki89 21:21, 13 September 2017 (UTC)

 * I've noticed the same thing., any thoughts? — JohnC5 22:38, 13 September 2017 (UTC)
 * I hadn't noticed that, but I see it now. I'm not aware of any way to add font-family-specific display properties, but there could be one that I'm not aware of. I agree it would be useful. I suppose the only thing that can be done is to manually define the size of the class css in your own common.css, if you have the font. I did some searching and found the font-size-adjust property, but I can't test it because it's only supported by Firefox currently and I only have Chrome. — Eru·tuon 23:07, 13 September 2017 (UTC)
 * We shouldn't use it anyway if only Firefox supports it. Hopefully in the future more browsers will. --WikiTiki89 23:10, 13 September 2017 (UTC)
 * w3schools is a bad website. MDN is better. —suzukaze (t・c) 01:54, 21 September 2017 (UTC)
 * Thank you. That page's explanation actually makes sense. — Eru·tuon 04:10, 21 September 2017 (UTC)

I don't care too much, but it's a bit disturbing to have two different fonts for Ancient Greek and Modern Greek. --Barytonesis (talk) 13:51, 14 September 2017 (UTC)
 * I've actually had it that way for a while. It helps me distinguish the two languages and spot when someone has mistagged a word. — Eru·tuon 08:18, 20 September 2017 (UTC)
 * We also have similar situations in other languages. Like for example Cyrillic and Old Cyrillic have different fonts, so you get 🇨🇬, but 🇨🇬. --WikiTiki89 14:16, 20 September 2017 (UTC)

This font looks really good, thanks. --Barytonesis (talk) 12:47, 29 September 2017 (UTC)

Grease_pit/2017/August. —suzukaze (t・c) 01:03, 20 August 2017 (UTC)

Noto Sans Adlam
An Adlam font came out on October 25. It might be the only one in existence. Firefox seems to use it automatically, but I propose adding the following rules for css:

— Eru·tuon 22:26, 29 November 2017 (UTC)

Minor spelling
needs a space:. — Eru·tuon 09:08, 8 December 2017 (UTC)
 * ✅ —Mahāgaja (formerly Angr) · talk 13:30, 8 December 2017 (UTC)

Tibetian font size
I noticed some earlier discussion about this: it is currently set to 160% which causes irregular line heights (e.g. Shangri-La). Is it still necessary to override it for everyone? – Jberkel 17:41, 17 December 2017 (UTC)
 * I'm not seeing irregular line heights at Shangri-La, but I am seeing transliterations that are so small I can't see them unless I hold a magnifying glass up to the monitor. —Mahāgaja (formerly Angr) · talk 23:35, 17 December 2017 (UTC)
 * screenshot (OSX, Chrome). Fixing crappy fonts with global font size overrides is not the Right Thing. – Jberkel 11:10, 18 December 2017 (UTC)
 * "Microsoft Himalaya" is a gift horse... —suzukaze (t・c) 16:49, 16 February 2018 (UTC)

Heiti SC and Heiti TC
Some of the current font designations for Chinese characters are as follows:

/* Chinese (Han) */ /* Hani: generic */ /* Hans: simplified */ /* Hant: traditional */ .Hani, .Hans { font-family: PingFang SC, Heiti SC, DengXian, Microsoft Yahei, SimHei, Source Han Sans CN, Noto Sans CJK SC, SimSun, NSimSun, SimSun-ExtB, Song, sans-serif; }   .Hant { font-family: PingFang TC, Heiti TC, Microsoft Jhenghei, Source Han Sans TW, Noto Sans CJK TC, PMingLiU, PMingLiU-ExtB, MingLiU, MingLiU-ExtB, Ming, sans-serif; }

I'd like to focus on the inclusion in this list of Heiti SC and Heiti TC. My presumption here is that the fonts intended to be grabbed with this are those distributed with macOS; however, a Google Images search of those font names reveals that there are a number of fonts distributed for free under these names which are less-than-appropriate for their intended use on this wiki.

My discovery of this was prompted by a search for a particular Chinese radical, 丫, which Wiktionary decided to display to me by default with a carrot forming one of the strokes.

Given that PingFang, the default font included in those definitions, is also distributed with macOS, and does not seem to be subject to the widespread repurposing which Heiti is, I would like to suggest Heiti SC and Heiti TC be removed from this list—or at least significantly lowered in priority below other, more sensible fonts. 192.252.225.44 09:55, 31 March 2018 (UTC)

 * You shouldn't see Heiti (carrots or not) if your Mac has PingFang though. PingFang has higher priority... —Suzukaze-c◇◇ 23:24, 13 July 2018 (UTC)

 * If you're on a Mac, and have those fonts. If you're not on a Mac, or otherwise don't have those fonts, but have installed one of the other fonts with that distribution name, then you will. That's why the suggestion stands: Removing it or lowering its priority won't negatively affect Mac users, but it will improve the user experience for any other affected users. 76.10.186.58 19:09, 17 July 2018 (UTC)

 * Ah, I get what you mean now. —Suzukaze-c◇◇ 01:41, 18 July 2018 (UTC)

Japanese uses MS PGothic but it should use Meiryo
Hi, I want to say that Japanese uses MS PGothic for Windows Vista, 7, 8.0/1 and 10, but it should use Meiryo. Someone should modify common.css and change the Japanese font stack to be somethin’ like this:

 .Jpan { font-family: "ヒラギノ角ゴ Pro", "Hiragino Kaku Gothic Pro", Osaka, メイリオ, Meiryo, 游ゴシック, "Yu Gothic", "ＭＳ　Ｐゴシック", "MS PGothic", "Noto Sans CJK JP", "Droid Sans Japanese", sans-serif; } --190.74.162.186 21:28, 30 June 2018 (UTC)

 * . —Suzukaze-c◇◇ 21:50, 30 June 2018 (UTC)
 * I have the following code for large sizes (like headers) which will display a serif font rather than a sans-serif font, ’cuz it looks better with large sizes:

 h1 .Jpan, h2 .Jpan, h3 .Jpan, h4 .Jpan { font-family: "ヒラギノ明朝 Pro", "Hiragino Mincho Pro", "ＭＳ　Ｐ明朝", "MS PMincho", 游明朝, "Yu Mincho", "Noto Serif CJK JP", "Droid Serif Japanese", serif; } —186.88.111.3 18:44, 4 July 2018 (UTC)

Bolding of Arabic script
Bolding for Arabic was disabled like for many other scripts, but for those other scripts the bolding was replaced with a bigger font size, e.g. with: This needs to be done for the Arabic variants too. (Although I think re-enabling bolding would be better.)

 * Example without any template:
 * شتر را با ملاقه آب دادن.
 * Example with :

Relevant links:,. --V111P (talk) 22:35, 20 September 2018 (UTC)

Unbreaking WikiHiero
The MediaWiki devs recently broke the inline display of hieroglyphs, which a great deal of Egyptian entries relied on. See the Grease Pit discussion. Could an interface administrator add the following CSS rule to fix it? (I’d do it myself, but forgot that the admin and interface admin roles have been split.) Thanks! — Vorziblix (talk · contribs) 01:26, 2 November 2018 (UTC)

column-count classes
Can someone please add generic column-count classes? They would be helpful to have for use in templates and modules. -- 06:07, 2 December 2018 (UTC)

Javanese font-size
The Javanese script appears too small in this wiki. I propose the increase in font size up to 130%, similar to the Burmese script. Below is my proposed change. Thank you in advance. Wirjadisastra (talk) 14:31, 31 January 2019 (UTC)

Generic inline class
Can someone please add generic inline list class? I need one for a module. We have, but it comes with some extra stuff that I don't want. -- 00:05, 22 February 2019 (UTC)
 * -- 02:47, 22 February 2019 (UTC)
 * Your ping didn’t go through for some reason. I’ll add the class, and add this page to my watchlist while I’m at it so I don’t miss this sort of thing in the future. — Vorziblix (talk · contribs) 00:42, 24 February 2019 (UTC)
 * Thanks! -- 06:29, 24 February 2019 (UTC)

Font addition request
Please change .Lana { font-family: Lanna Alif, Noto Sans Tai Tham, sans-serif; to .Lana { font-family: HG_TaiTham_WBD_SJ, A Tai Tham KH New, Tai Tham LN, Lanna Alif, Noto Sans Tai Tham, sans-serif; Thank you! --173.68.165.114 04:26, 19 March 2019 (UTC)

Remove obsolete styles for audio
@Erutuon: With the new player on, audio fails to show the player properly. It seems the classes  and   are not only no longer needed but even blocking the implementation of the upcoming player.

Compare the current audio: with audio/sandbox, from which said classes have been removed (diff): with the new player enabled. The style for  seems still useful, but the rest (  and  ) seem completely unnecessary. Even  is probably better located at Template:audio/styles.css.

While I'm at it, the template could use a complete rewrite. We should probably abandon the table layout and the alternative format (there are only two articles using it, barcarole and crickets, in the latter of which it's not even working; for that purpose we have listen anyway) and replace it with incredibly simple code. Nardog (talk) 23:30, 28 July 2019 (UTC)
 * Removing unused styles and simplifying the template both sound good, though I'm not at all familiar with the workings of the template. I will try the   and   styles as those seem to have no effect under the default settings and break the new player. — Eru·tuon 20:47, 9 August 2019 (UTC)
 * I'm in favor of moving styles from this page to a TemplateStyles page if they only apply to text in a few templates. At the moment,  seems to only appear in  and  (see this search), so it's a good candidate. — Eru·tuon 20:59, 9 August 2019 (UTC)

inc bold Hani size
I had the discussions for this open for four entire months. —Suzukaze-c◇◇ 20:32, 11 August 2019 (UTC)
 * I don't know what's changed but one can now hardly make out Chinese characters with the new formatting, even worse for bold characters: . Why have the characters (and letters in general) become so small now? Even I have to set my browser's default zoom for Wiktionary to 125% to be able to see characters clearly, let alone beginners of Chinese. Wyang (talk) 07:47, 12 August 2019 (UTC)

 * 1. You could try to find out by looking at the page history.
 * 2.  is functionally identical to.
 * 3. Module:zh-usex has enforced a smaller font size of  from 2016  to today, 2019.
 * 4. The Chinese Wikipedia uses.
 * 5. You have a personal stylesheet at User:Wyang/common.css. (inb4 "what about you": correct!)
 * —Suzukaze-c◇◇ 23:21, 13 August 2019 (UTC)

look

 * Could I humbly request that you revert the edit this section is about. —Suzukaze-c◇◇ 02:45, 28 December 2019 (UTC)
 * Done. I guess now we'll find out what other people think of it. — Eru·tuon 05:40, 29 December 2019 (UTC)
 * Thank you. —Suzukaze-c◇◇ 05:47, 29 December 2019 (UTC)

Anatolian Hieroglyphs font
Victar has extracted some fonts from the Unicode character code charts. He requested that I add a CSS rule to specify the Anatolian Hieroglyphs font for, and I agreed after deciding that it is probably okay as long as we don't host the fonts here. If anyone has objections, please raise them here. — Eru·tuon 01:29, 5 November 2019 (UTC)
 * Hmm,, looking at I think   need to be bumped up to  . --  02:16, 5 November 2019 (UTC)
 * Actually, I found a better variant here. Could we perhaps change it to: css -- 03:22, 5 November 2019 (UTC)
 * Done. — Eru·tuon 03:23, 5 November 2019 (UTC)
 * Much appreciated! -- 03:25, 5 November 2019 (UTC)

Japanese ruby

 * see also Template talk:ja-usex

This is originally Template:ruby/styles.css, but not every Japanese entry with ruby annotations uses that template. suggests the code be moved here. --Dine2016 (talk) 07:53, 25 January 2020 (UTC)

Fonts for Burmese
Please change

to

Thank you. Ninja ✮ Strikers «☎» 04:46, 4 June 2020 (UTC)

 * Pyidaungsu font is the Standard Unicode font for Burmese and it's licensed with SIL Open Font License. Ninja ✮ Strikers  «☎» 10:57, 5 July 2022 (UTC)

different color for pages that don't exist
Would you guys please add different colors for the links to those pages that don't exist? Their links (whether unvisited or visited) currently have exactly the same colors as those of pages that do exist, which is misleading. I suppose their colors should be similar to red links (visited and unvisited), but somewhat different. Adam78 (talk) 16:07, 5 June 2020 (UTC)
 * Some notes in case someone wants to work on this. It is not a simple matter of adding CSS. There is a class that the MediaWiki software adds to links to pages that actually do not exist (redlinks, "new"), but none for links to these so-called "pages that don't exist", which actually do exist but don't have entries for a particular language. So, coloring these links to pages without entries requires getting a list of categories for those pages and checking if one of the categories for each page ends in "entries that don't exist". (If the link points to a language section, it can also check that the "entries that don't exist" category begins with this language name.) As for the OrangeLinks gadget, this requires JavaScript. Ideally the looking-up of categories for linked pages would be done once for both the OrangeLinks gadget and the "entries that don't exist" gadget because it probably often takes several requests to the server to get all the categories. — Eru·tuon 17:36, 5 June 2020 (UTC)

Sundanese font
Sundanese text only shows tofu box script, please change

to

Thanks. Ekirahardian (talk) 15:43, 31 October 2020 (UTC)
 * Finally done. — Eru·tuon 23:53, 9 April 2021 (UTC)

Aghwan
, I want to do this here. Why can't I edit the page? I am an admin. --Vahag (talk) 21:18, 3 January 2021 (UTC)
 * You'll need to be interface administrator to edit this page. I've added the styles you linked though. — Eru·tuon 00:06, 4 January 2021 (UTC)

IPA class
Hey! Can you add  to the IPA class? It is displaying fl as a ligature on macOS which causes the syllabic diacritic to be displayed separately from l.
 * Done. — Eru·tuon 23:52, 9 April 2021 (UTC)

Best typeface for Kashmiri
The current set of typefaces have multiple issues with rendering Kashmiri. First, the particular half-ya <ؠ> is not rendered by any font causing the continuous script to fail. Second, many letters which take diacritics (ux065B, ux065A) are not rendered with the appropriate medial form. While I've found just one typeface that deals with all these issues (Scheherazade), it is extremely small to read. There are some other typefaces which, while not 100% accurate for Kashmiri, render well without breaking off: Noto Naskh Arabic, Amiri and Mirza. Given that there is no hat is the suggested recourse here? — Sinonquoi (talk) 09:35, 4 August 2021 (UTC)

Better font for Ugaritic
Hi! Can an admin add "Oxford Ugaritic" (available here: Oxford Ugaritic) as our first choice font for Ugaritic? Current Ugaritic fonts have been created on the model of Sumerian cuneiform and don't look right. Thank you! Sartma (talk) 17:43, 7 January 2022 (UTC)
 * ✅ — Eru·tuon 18:15, 7 January 2022 (UTC)

Hatran
Can we add the font "Noto Sans Hatran" for script code Hatr? --Vahag (talk) 20:44, 19 January 2022 (UTC)

 * does this still need to be done? (If so, I'll do it.) I notice this page does not currently set any fonts for (or even mention) Hatr at all. - -sche (discuss) 01:16, 24 March 2023 (UTC)
 * @-sche, yes, please do it. Vahag (talk) 12:36, 24 March 2023 (UTC)
 * ✅. - -sche (discuss) 16:21, 24 March 2023 (UTC)

.Hani font
Hi! After Votes/pl-2014-04/Unified Chinese, the Chinese characters are lemmatised at the traditional forms, therefore, supposedly, characters without specifying trad/simp (i.e. ) should use the same fonts as   rather than. Most trad/simp pairs have different code points, but some characters share the same Unicode code point, which makes text with class="Hani" (especially the level one title) to display in simplified font, a situation which is inconsistent with the current practices and policies. Also note that the traditional glyph is usually the same or very similar to the Japanese and/or Korean glyphs, whereas simplified does not, so the choice would accommodate the other languages in CJK script better. A good example would be 角 (the difference is also briefly explained in the etymology) -- Wpi31 (talk) 13:59, 4 August 2022 (UTC)

 * any thoughts? Wpi31 (talk) 13:04, 8 August 2022 (UTC)
 * I would support changing to the same fonts as . — justin(r)leung { (t...) 06:49, 13 August 2022 (UTC)
 * Done. — Eru·tuon 21:39, 13 November 2022 (UTC)

Tagalog Baybayin Font
Hello, Can someone update the class  to have support the other fonts supported at Wikipedia? Change the Tagalog to here:

Thank you! Ysrael214 (talk) 13:42, 16 October 2022 (UTC)

 * I'll be tagging because maybe it doesn't notify. @Erutuon Thank you. Ysrael214 (talk) 01:12, 17 October 2022 (UTC)
 * @Erutuon Or maybe include this in the css instead? I don't know which css this is appropriate.
 * Because the Baybayin text just appear to be squares without the font downloaded. This will make Wiktionary provide support for it even without downloading the font itself. Ysrael214 (talk) 21:26, 19 October 2022 (UTC)
 * I've added the font list. The MediaWiki software doesn't allow us to use  in the stylesheet. — Eru·tuon 19:01, 20 October 2022 (UTC)
 * I've added the font list. The MediaWiki software doesn't allow us to use  in the stylesheet. — Eru·tuon 19:01, 20 October 2022 (UTC)

Remove styles
Now that Extension:TemplateStyles is available, I have added a dedicated stylesheet for the TOC limit template, which makes the template's implementation easier to understand and more self-contained. This means there's no need to keep the corresponding styles here in Common.css. Can someone with the right permissions make that change? Thanks, Waldyrious (talk) 16:25, 19 November 2022 (UTC)

Applying correct noto fonts for aii and tru
People read/write assyrian and turoyo with eastern and western fonts respectively, however wiktionary is using estrangela for both. Noto fonts are preferred since they're sans serif instead of serif which improves readability on phones/computers.

Would we be able to follow the same styling used here https://en.wikipedia.org/wiki/Syriac_alphabet#East_Syriac_Ma%E1%B8%8Fn%E1%B8%A5%C4%81y%C4%81 (uses https://en.wikipedia.org/wiki/Template:Script/Mdnh) and here https://en.wikipedia.org/wiki/Syriac_alphabet#West_Syriac_Ser%E1%B9%AD%C4%81 (uses https://en.wikipedia.org/wiki/Template:Script/Serto)?

I'm not familiar with this stylesheet but I assume the change would look something like this (provided the fonts are installed)

/* Serto form of Syriac */ .Syrc:lang(tru) { font-family: 'Noto Sans Syriac', 'Noto Sans Syriac Western'; }

and would also require adding this

/* Maḏnḥāyā form of Syriac */ .Syrc:lang(aii) { font-family: 'Noto Sans Syriac', 'Noto Sans Syriac Eastern'; }

(copying Antonklroberts in this since he does a lot of editing for aii)

Thanks so much ColumbaBush (talk) 12:20, 23 March 2023 (UTC)

 * ✅ (although I left the font which was previously set for Serto at the end of the new list as a fallback in case someone has it and not Noto Sans) - -sche (discuss) 01:12, 24 March 2023 (UTC)
 * @-sche Thanks so much, I really appreciate it. I'm using a mac (noto sans syriac east/west come with macOS and iOS, no installation required) and the font is still not rendering properly on wiktionary but it is in on wikipedia.  On wiktionary the lang attribute needs to be changed from   to   and   to   (for more info see "ISO 15924" here https://en.wikipedia.org/wiki/Syriac_alphabet).
 * When I made this change by tweaking the html in my browser the correct font immediately took effect.
 * How would we go about mirroring this change to wiktionary? For reference here's a discussion on wikipedia and some modules that handle naming:
 * https://en.wikipedia.org/wiki/Template_talk:Script#Syre,_Surj,_Syrn,_Syrc:_Syriac
 * https://en.wiktionary.org/wiki/Module:languages/canonical_names
 * https://en.wiktionary.org/wiki/Module:languages/code_to_canonical_name
 * Thanks again ColumbaBush (talk) 02:13, 24 March 2023 (UTC)

 * Try clearing your cache / hard-refreshing MediaWiki:Common.css, as described at the top of that page. When I look at ܐܘܢܓܠܝܘܢ, the headword line of the Assyrian Neo-Aramaic section does show up in a different font from the Classical Syriac section. (And I actually can't say I'm impressed with the legibility of any of the fonts, but I don't know — having looked before I made the change — that Wiktionary has any currently-active Syriac-script Wiktionarians who could give their feedback; User:334a hasn't edited in a few months. Maybe User:Shuraya: which fonts do you find most legible for Syriac script?) - -sche (discuss) 16:16, 24 March 2023 (UTC)
 * Thanks for the follow up. I tried that (cleared cache w/ a new incognito session in chrome) and it didn't work.  I think we're talking about a separate issue all together.
 * I should have changed the title of this section to "Applying correct noto fonts for aii and tru for macbooks and iphones" since on apple devices the noto sans syriac, noto sans syriac west, noto sans syriac east fonts come with the operating system which is not the case for windows/linux. This is an important detail because wikipedia is not actually serving these fonts so the browser ends up using these fonts only if they're available locally off the person's device.  You can confirm this by opening up devtools in your browser and it will tell you whether the fonts are being served off your device or being delivered over the network from the website.  We want to mirror exactly what wikipedia is doing so the fonts render properly on wiktionary when accessed from a macbook or iphone.  The way this is achieved is by correctly setting the   html attribute for assyrian and suryoyo (turoyo) respectively.
 * how it's currently on wiktionary
 * ܣܘܵܕ݂ܵܝܵܐ
 * ܣܶܪܛܳܐ
 * how it's currently on wikipedia ex. https://en.wikipedia.org/wiki/Syriac_alphabet)
 * ܣܘܵܕ݂ܵܝܵܐ
 * ܣܶܪܛܳܐ
 * Can you recommend how we can change the lang attribute for these two?
 * It would be really appreciated if we can accommodate this change. I'm struggling to get friends and family to contribute to aii wiktionary because the use of an incorrect font is alienating for them.
 * Alternatively if we want to guarantee that everyone, regardless of operating system is seeing the same 3 noto sans syriac fonts, we can download them from here https://notofonts.github.io/syriac/ and serve them over the network from wiktionary (however I don't know how feasible that is since a previous comment on this page mentioned  is not allowed.)
 * And yes, I completely agree w/ everything you said about the legibility of the serif fonts you're seeing. Those were designed way before a majority of reading/writing was done on the internet, so they understandably weren't optimized for the digital age.  The noto sans serif ones definitely are digital-first though.
 * ColumbaBush (talk) 23:21, 24 March 2023 (UTC)
 * It would be really appreciated if we can accommodate this change. I'm struggling to get friends and family to contribute to aii wiktionary because the use of an incorrect font is alienating for them.
 * Alternatively if we want to guarantee that everyone, regardless of operating system is seeing the same 3 noto sans syriac fonts, we can download them from here https://notofonts.github.io/syriac/ and serve them over the network from wiktionary (however I don't know how feasible that is since a previous comment on this page mentioned  is not allowed.)
 * And yes, I completely agree w/ everything you said about the legibility of the serif fonts you're seeing. Those were designed way before a majority of reading/writing was done on the internet, so they understandably weren't optimized for the digital age.  The noto sans serif ones definitely are digital-first though.
 * ColumbaBush (talk) 23:21, 24 March 2023 (UTC)
 * And yes, I completely agree w/ everything you said about the legibility of the serif fonts you're seeing. Those were designed way before a majority of reading/writing was done on the internet, so they understandably weren't optimized for the digital age.  The noto sans serif ones definitely are digital-first though.
 * ColumbaBush (talk) 23:21, 24 March 2023 (UTC)

 * Ah. Hmm... as long as Wiktionary is treating  and   as separate languages, I'm not sure we can or should change the lang= that   is tagged as being from   to  . If the issue is that we need to consider   and   separate scripts and not subsume them into , and then we need to change  's script (set by Module:languages/data/3/a) from   to  ), and set specific fonts for   and  , we can do that. (And if   is not working to apply fonts to currently-Syrc-script-tagged  , that's a broader issue that 'd need to be fixed, since we're also using that approach with   and other languages/scripts.) I'm going to ask in the WT:Grease pit for more input from other editors. - -sche (discuss) 19:02, 25 March 2023 (UTC)
 * Gotcha - thanks for the detailed breakdown.
 * I dropped a note in https://en.wiktionary.org/wiki/Wiktionary:Grease_pit/2023/March#different_fonts_for_different_Syriac-script_languages just to provide some additional details and to close the loop on this convo ColumbaBush (talk) 22:00, 25 March 2023 (UTC)
 * I'm not understanding all the conversation here, but  applies   only if   isn't installed. Similarly with the other list of fonts. That's probably not the intention. The more desirable fonts have to be first. — Eru·tuon 20:54, 25 March 2023 (UTC)
 * I changed the order of the fonts so the specifically Eastern and Western fonts will take priority over the generic Syriac font. If anyone had all three of these fonts installed, this will make the browser use Noto Sans Syriac Western and Noto Sans Syriac Eastern be used whereas before it would have been using Noto Sans Syriac. — Eru·tuon 21:00, 25 March 2023 (UTC)
 * This is a great point, presently  is providing   and   under the hood, however the changes you made should stay in lieu of a decoupling of the estrangela, western and eastern fonts currently taking place.
 * I left some more details abt this decoupling in https://en.wiktionary.org/wiki/Wiktionary:Grease_pit/2023/March#different_fonts_for_different_Syriac-script_languages ColumbaBush (talk) 21:53, 25 March 2023 (UTC)
 * There is a huge issue with the changes of the fonts however, all the text is way too big and the text are all bolden meaning there is no visual difference between bold and unbold. Antonklroberts (talk) 20:08, 2 April 2023 (UTC)
 * Aha, I see what you mean. For me, all the fonts on e.g. ܐܘܢܓܠܝܘܢ (which includes both some text in aii, a language for which the fonts were recently changed, and some text in syc and sog , for which the fonts have not changed) displayed at about the same (reasonable) size, and there was a slight difference between bold and unbolded text (looking at the usexes under the definitions here), and the aii text displayed in a different font from the syc and sog text for me (although none of the fonts were very legible), so I thought I was seeing the different fonts that were being set for aii vs syc . However, when I install Noto Syriac locally, I see the problem you describe, it's very large (although if you look at the usexes in the diff I linked above, there is a clear distinction between bold and unbolded text). This is tricky, because if we reduce the default font size to accommodate the larger size of Noto Syriac, it will also reduce the size of the text for users who don't have Noto Syriac and see the other (smaller) default fonts, making those even more illegible. I'm tempted to remove Noto, since I'm not convinced it's much more legible than the fonts that were being displayed before except by being bigger. - -sche (discuss) 20:57, 2 April 2023 (UTC)
 * I'm not sure it would help to remove Noto Sans Syriac and the rest, because it wouldn't stop the browser from using those fonts if they were the only ones with support for Syriac characters on a reader's device. It would help to prioritize other fonts that do work with the enlarged font size, or to remove the font size declaration. The ideal solution would be to set a lower font size only for Noto Sans Syriac, but apparently that's impossible. Font size applies to whichever font family a browser happens to choose, which could be one that's not even specified in the CSS. I'm not sure the Noto fonts are commonly installed enough on computers to disable the font size declaration though.
 * On Android the font size and font family declarations don't apply because mobile only loads MediaWiki:Mobile.css, not MediaWiki:Common.css, and Firefox seems to automatically apply Noto Naskh Arabic and Noto Sans Syriac Eastern to Arabic and Assyrian Neo-Aramaic. I guess the Noto fonts were pre-installed because I can't remember installing them (or even how to install fonts on Android). They both look pretty good at normal font size. Anyway, this illustrates how the browser will, if it's designed well, use the fonts that contain the right characters even if they aren't in a font-family declaration. — Eru·tuon 22:26, 2 April 2023 (UTC)
 * True. (And I agree, it is unfortunate we can't set sizes for specific fonts.) I meant to include this in my earlier comment, but here FWIW is what I see before and after installing Noto Sans Syriac (the upper language section is Assyrian Neo-Aramaic, the page is ܐܘܢܓܠܝܘܢ). Meh. Alright, I suppose we should just leave things as they are (with Noto Sans Syriac in the list). If anything, I guess the big size of Noto Sans Syriac may help legibility vs the small size of the other font. - -sche (discuss) 01:04, 3 April 2023 (UTC)
 * Yuck, that's so square and wide! Turns out I didn't have the plain Noto Sans Syriac installed. I had the Eastern, Western, and Estrangela versions installed, and they are slender even when bolded. I don't know where I got them; they are in the Early Access page and apparently I downloaded all the early access fonts. They are also apparently installed on my phone already. Anyway, I would recommend installing Noto Sans Syriac Eastern, Western, and Estrangela. The default Windows font Segoe UI Historic also looks nice, and has more variation in line thickness than any of the Noto ones, though it's a little smaller in letterforms and seems to be Estrangela style based on comparison with the Noto fonts. (I can't read Syriac.) — Eru·tuon 02:02, 3 April 2023 (UTC)
 * @Antonklroberts I'm trying to understand what you're seeing, can you post a screenshot to imgur like sche did? How things render depends on your operating system (ios, android, windows, mac, etc...), your browser and what fonts you have manually installed locally.  Anything that limits your productivity will have a huge, negative impact on the assyrian wiktionary, so it's important we have a bias to your concerns.
 * Also is your concern w/ the font-size or the font-weight? If the former, there's nothing that can be done abt that because the fonts available at bethmardutho weren't properly designed.  The noto sans fonts are the correct size and it's the other ones which are too small, so to compensate for that they set the font size to 1.3x the size https://en.wiktionary.org/wiki/MediaWiki:Common.css#L-1915 which gives the impression that the noto sans ones are too big and the other ones are normal.
 * One thing you can try is to remove any noto sans syriac fonts you manually installed (if any), and go to https://notofonts.github.io/#syriac. Then download the variable weight font I circled in red https://imgur.com/a/PS6zfQs and everything should look like this https://imgur.com/a/hOUnOLs (notice the correctness of the boldfacing.)  Later in the year, the updated versions of these fonts will be baked into ios, mac and android - but for now, or if you have windows/linux, you have to manually install. ColumbaBush (talk) 02:42, 3 April 2023 (UTC)
 * @Antonklroberts - Just wanted to add some more details - if you follow the instructions in the previous message and in addition download the eastern and western fonts from https://notofonts.github.io/#syriac that I circled here https://imgur.com/a/2EYVNSj, things should end up looking like this https://imgur.com/a/PzC9L7L. Does this look good to your eyes?
 * This will be the default experience later in the year for ios/android/mac without having to manually install the fonts, so it'd be helpful to know if this is missing the mark.
 * Thank you @-sche @Erutuon for all your work 💪. For elements in the category pages like https://en.wiktionary.org/wiki/Category:Assyrian_Neo-Aramaic_lemmas can we set the class to  ?  Right now it looks like this   so the intended font-family is not applied.  Same thing for https://en.wiktionary.org/wiki/Category:Turoyo_lemmas and https://en.wiktionary.org/wiki/Category:Classical_Syriac_lemmas as well.  Also we might want to add   to the font-family of .Syrc for consistency's sake.  Also, can we get away with removing this block https://en.wiktionary.org/wiki/MediaWiki:Mobile.css#L-58?
 * ColumbaBush (talk) 11:55, 3 April 2023 (UTC)
 * Why would we remove MediaWiki:Mobile.css? — Eru·tuon 20:11, 3 April 2023 (UTC)
 * im struggling to understand what the snippet's purpose is.
 * no other language class is overriding the default for  in the mobile stylesheet so it's kind of an extreme outlier.  also these docs say not to use it https://developer.mozilla.org/en-US/docs/Web/CSS/unicode-bidi but if there's a reason to have it there then we should keep it (i was just wondering what the reason was)
 * my guess would be this snippet is to support locally installed fonts that don't handle rtl properly however people don't really install fonts on mobile. also noto sans syriac comes with android/ios and it handles rtl properly.  the edit in which the snippet made its way into the mobile stylesheet was part of a large copy/paste from the non-mobile stylesheet so that's possibly "the why"  ColumbaBush (talk) 22:38, 3 April 2023 (UTC)
 * I don't know why a MDN writer thinks  is only for DTD designers. We use   to ensure punctuation is correctly positioned around right-to-left text that is nested within left-to-right text, or the reverse. For instance, without it and without the unnecessary left-to-right mark that is added after the link generated by the template,   would have the comma on the right side of the space, when it should be on the left because the comma and space are in English text. Compare ابج, ابج without   to ابج , ابج with it. There may be other values for   that aren't normally useful for web development, but   is working for us. I'm not clear on the difference between   and   or whether we could remove  , but the CSS that we use seems to work in most cases.
 * Basically the embed or isolate prevents the Arabic characters (which are strongly right-to-left) from changing the direction of the comma and space (which are weakly directional). — Eru·tuon 21:20, 4 April 2023 (UTC)
 * I don't know if anything has changed that would allow removing  now, but at the time it was added, it was needed (initial discussion, followup). - -sche (discuss) 22:10, 4 April 2023 (UTC)
 * Thanks for the details, I "see it" in your examples and agree w/ what you said abt the MDN doc.
 * Regarding the mobile stylesheet, why is  and   only being used for .Syrc https://en.wiktionary.org/wiki/MediaWiki:Mobile.css#L-58 but not other languages? ColumbaBush (talk) 00:18, 5 April 2023 (UTC)
 * It is being used for other languages, all the other languages starting on MediaWiki:Mobile.css, of which Syrc is merely the alphabetically last in the list. - -sche (discuss) 01:15, 5 April 2023 (UTC)
 * Oh man, I can't believe I misread that... I just quickly glanced at it and closed the window without trying to "read" it. Major human error on my part.  Thank you both for being patient w/ me while I was confused.   ColumbaBush (talk) 01:27, 5 April 2023 (UTC)

 * So should we make "Noto Sans Syriac" the default font for Syriac as a whole then for consistency? (Also, not sure if related or not, but on my particular computer right now, the Estrangelo Edessa font is causing the text to be disconnected for some reason.) --WikiTiki89 00:54, 19 April 2023 (UTC)
 * I would support that - ie updating .Syrc to
 * ColumbaBush (talk) 06:04, 19 April 2023 (UTC)
 * I'm not equipped to answer because I don't read Syriac script. Besides Assyrian Neo-Aramaic and Turoyo in Syriac script, which have their own fonts, what variety of Syriac script do the other Syriac script languages prefer and does Noto Sans Syriac look appropriate for them? Does it look better than the other fonts such that you'd want to use it over them? — Eru·tuon 14:36, 19 April 2023 (UTC)
 * when you said
 * the default font for Syriac as a whole
 * i thought you meant Classical Syriac, not Classical Syriac+Assyrian+Turoyo/Suryoyo
 * if you meant the latter, then no, i dont think we should make "Noto Sans Syriac" the default font for all 3 ColumbaBush (talk) 17:29, 19 April 2023 (UTC)

Thai fonts
Please change fonts in .Thai like this:

font-family: 'Leelawadee UI', 'Leelawadee', 'Arial Unicode MS', 'Code2000', sans-serif;

Because Leelawadee displays better mark stacking. Good for minor languages. Octahedron80 (talk) 01:00, 24 March 2023 (UTC)

 * ✅. I left the apostrophes off Leelawadee, in line with your initial request before you edited it, since it I see other single-word font names are also not put in apostrophes; if this causes problems, let me know. - -sche (discuss) 01:14, 24 March 2023 (UTC)

 * That's sufficient. Thanks. --Octahedron80 (talk) 01:37, 24 March 2023 (UTC)

Old Permic script (+ Glag & Xsux fonts)
please create  (Old Permic script) for the Old Komi language. Font:  : https://fonts.google.com/noto/specimen/Noto+Sans+Old+Permic.
 * PS: Please make  (Glagolitic) the   font in the first place:  . Also, reduce the font size to.
 * PSS: Add to  (Cuneiform), font   : https://www.hethport.uni-wuerzburg.de/cuneifont/. He is very good. --ZomBear (talk) 13:08, 28 March 2023 (UTC)

 * OK, I've added Old Permian to this list (it was already set as the script for Old Komi), with that font. For, which stages or varieties is the Assurbanipal good for? I see we are currently setting different fonts for Neo-Assyrian  , Hittite  , and Sumerian   (with commented-out lists for Old Assyrian, Neo-Sumerian, and Classical Sumerian  ). For Glagolitic, I'd like to check if other editors who edit or have knowledge of those scripts have any opinions / agreement / disagreement re changing the font or size; pinging User:Vorziblix, User:Mzajac, User:Mahagaja (I feel like there are more, but I haven't spotted them in the User language / User scripts categories). - -sche (discuss) 17:00, 28 March 2023 (UTC)
 * Pinging User:Sartma if you have any feedback on Assurbanipal or other  fonts. - -sche (discuss) 17:02, 28 March 2023 (UTC)
 * @-sche: I would not use Assurbanipal for generic Cuneiform (Xsux), since its glyphs reflects Neo-Assyrian cuneiform, which is the latest form of cuneiform and works exclusively for Neo-Assyrian and Neo-Babylonian. I suggested the fonts currently specified for Xsux and all other languages that use cuneiform, and I wouldn't change them. Individual users can specify different fonts in their User page common.css, if they want. I explain how to do that here. — Sartma 【𒁾𒁉 ● 𒊭 𒌑𒊑𒀉𒁲】 07:56, 30 March 2023 (UTC)
 * @Sartma I just suggested. If not, then okay. The editors of the respective languages know better. ZomBear (talk) 11:22, 30 March 2023 (UTC)

 * @-sche Thanks for Old Permian. As for the  (Glagolitic) - I found a better font, this   : https://fonts.google.com/noto/specimen/Noto+Sans+Glagolitic He's just perfect and great. Readability is excellent, even at 120-125%. This font should be the default, and not   as I wrote earlier. PS: It says here that the font   is Neo-Assyrian. --ZomBear (talk) 17:38, 28 March 2023 (UTC)
 * Sorry, I haven’t kept up on these issues. But do we not have the ability to serve web fonts yet, or specify them in CSS to load from some other free-licence repository? —Michael Z. 22:35, 28 March 2023 (UTC)

Broken Arabic text
Arabic text styling is broken and it is related to one of your edits. See — Fenakhay ( حيطي · مساهماتي ) 05:27, 7 September 2023 (UTC)
 * Actually, it is also the case for IPA. — Fenakhay ( حيطي · مساهماتي ) 05:29, 7 September 2023 (UTC)
 * Whoops, that was me forgetting to remove a brace when combining items; thankfully Surjection has fixed it. - -sche (discuss) 07:40, 7 September 2023 (UTC)

RFM discussion: December 2021–January 2022
Cuneiform script changed a lot over time, and the default fonts for cuneiform signs may be accurate for Sumerian, but they aren't for Akkadian and Hittite. This issue can be addressed by displaying separate fonts for each language. As far as I'm aware, this can only be achieved by spliting the cuneiform script code (Xsux) into three separate script codes. ObnoxiousCoder (talk) 01:17, 8 December 2021 (UTC)
 * Linguistically, I fully agree. But I don't know anything about how to execute this properly., do you have any script-handling wisdom? —Μετάknowledge discuss/deeds 21:29, 22 December 2021 (UTC)
 * No need for a split: css. —Fish bowl (talk) 22:03, 22 December 2021 (UTC)
 * , in that case, I think all you have to do is ping Fish bowl with the fonts you'd like to be assigned to each language. —Μετάknowledge discuss/deeds 07:16, 28 December 2021 (UTC)
 * , Nice, in that case I will discuss it with before taking a decision. ObnoxiousCoder (𒅀𒀀𒋾𒁺𒁍𒌒) 18:43, 28 December 2021 (UTC)
 * The issue here is that we should at the very least have the possibility to use one font for Sumerian/Old Babylonian, and another for Neo-Assyrian. It means that we should find a way to have Sumerian and Old Babylonian to use the same font. We can then leave a general "Akkadian" for Neo-Assyrian and all the other Akkadian dialects. What solutions do we have? Sartma (talk) 12:50, 7 January 2022 (UTC)
 * To clarify: I'm only talking about the possibility of having different fonts for quotes and examples (and maybe in the cuneiform spellings table?) not for the main headword. Headwords are given in Old Babylonian (and Romanised), so the current Monumental style works when we give the spelling in reconstruction pages and mentions/links. It would be great if we could use akk-obb and akk-nas (as per WT:List of languages/special) as language codes when needed, for example. Sartma (talk) 15:17, 7 January 2022 (UTC)

title: MediaWiki talk:Common.css