/* For template documentation */.template-documentation{clear:both;margin:1em000;border:1pxsolid#aaa;background-color:#ecfcf4;padding:5px;}
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"?) —RuakhTALK21:05, 9 June 2008 (UTC)Reply
Latest comment: 13 years ago4 comments3 people in discussion
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:
/* Highlight clicked reference in blue to help navigation */ol.references>li:target{background-color:#DEF;}sup.reference:target{background-color:#DEF;}
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. --EncycloPetey18:05, 31 July 2008 (UTC)Reply
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. --MZMcBride18:32, 31 July 2008 (UTC)Reply
Should space-containing font-family names be quoted?edit
Latest comment: 13 years ago6 comments2 people in discussion
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? —RuakhTALK14:15, 9 December 2008 (UTC)Reply
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.” —MichaelZ. 2008-12-09 16:44 z
Yeah, I know; the rfc: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? —RuakhTALK18:56, 9 December 2008 (UTC)Reply
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. —MichaelZ. 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[1]. 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. —MichaelZ. 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 font-family 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. —RuakhTALK01:12, 11 December 2008 (UTC)Reply
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.
—RuakhTALK21:34, 27 December 2008 (UTC)Reply
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. —MichaelZ. 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. —MichaelZ. 2008-12-28 01:21 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. —MichaelZ. 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. :-) —RuakhTALK21:52, 3 January 2009 (UTC)Reply
Latest comment: 15 years ago2 comments1 person in discussion
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.
/* Armenian [[Template:Armn]] */.Armn,.HY{font-family:Sylfaen,ArialUnicodeMS,sans-serif;font-size:15px;}
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.
/* Armenian [[Template:Armn]] */.Armn,.HY{font-family:ArialAMU,ArianAMU,DejaVuSans,Sylfaen,Code2000,ArialUnicodeMS,sans-serif;font-size:15px;}
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". —Stephen22:50, 4 January 2009 (UTC)Reply
Latest comment: 14 years ago1 comment1 person in discussion
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#Horizontal lists).
/* Style for horizontal UL lists */.horizontalp,.horizontalul,.horizontalli{display:inline;}.horizontalul{padding:000.2em;margin:0;}.horizontalli{padding:00.1em00.1em}/* [[CSS filter#Negation pseudo-class hack]] since IE <8 doesn't support pseudo elements and IE 8 doesn't support :last-child psuedo class. */html:not([dummyparam]).horizontalli:after{content:",";}html:not([dummyparam]).horizontalli:last-child:after{content:".";}
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 Kassad08:44, 3 June 2010 (UTC)Reply
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. --Anatoli22:07, 3 June 2010 (UTC)Reply
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 Kassad08:41, 4 June 2010 (UTC)Reply
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)Reply
[[!]] 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)Reply
[[!]] 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)Reply
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)Reply
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 (Wiktionary:Votes/2006-12/form-of style), so maybe we shouldn't change it without another vote? I don't know. —RuakhTALK02:43, 29 July 2010 (UTC)Reply
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)Reply
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 <span class='use-with-mention'>Plural form of <span class='mention'>[[{{{1}}}|{{{2}}}]]</span>.</span>, whereas template:conjugation of is essentially <span class='use-with-mention'>{{{3}}} of</span> [[{{{1}}}|{{{2}}}]].. If the CSS change affects not only .use-with-mention but also .use-with-mention .mention (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)Reply
That reason is that the CSS specifies .use-with-mention .mention, .defn-form-of .lemma { font-style: normal; font-weight: bold; }, overriding the previous .mention { font-style:italic }.—msh210℠ (talk) 19:56, 2 August 2010 (UTC)Reply
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)Reply
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)Reply
Latest comment: 13 years ago3 comments2 people in discussion
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? --Anatoli01:42, 8 April 2011 (UTC)Reply
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 Kassad07:52, 8 April 2011 (UTC)Reply
Latest comment: 13 years ago2 comments2 people in discussion
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:
Latest comment: 12 years ago4 comments2 people in discussion
Since redirects aren't really supposed to be used in the mainspace, I think it would make sense to apply different coloring to .ns-0 .mw-redirect links. Thoughts? --Yair rand17:54, 19 May 2011 (UTC)Reply
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)Reply
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 rand22:00, 19 May 2011 (UTC)Reply
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: a polite way to refer to a death by natural causes", 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)Reply
Latest comment: 12 years ago2 comments1 person in discussion
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)Reply
Latest comment: 12 years ago2 comments2 people in discussion
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. Hbrug21:53, 29 October 2011 (UTC)Reply
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)Reply
Latest comment: 11 years ago21 comments8 people in discussion
Currently, the content of collapsible tables is displayed until the page finishes loading and the javascript runs. I propose that we add .client-js .NavContent{display: none; } 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)Reply
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. DCDuringTALK18:02, 27 November 2012 (UTC)Reply
The <html> element starts with the class client-nojs, and a small bit of javascript in the head removes it and adds client-js in its place, all before the body starts loading. --Yair rand (talk) 19:54, 27 November 2012 (UTC)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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? --WikiTiki8913:54, 29 November 2012 (UTC)Reply
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 {{rel-top}} when the cognate section is long. DCDuringTALK22:56, 29 November 2012 (UTC)Reply
Latest comment: 10 years ago4 comments2 people in discussion
Would anyone object if I added #pt-webfont{display:none;} 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)Reply
Latest comment: 10 years ago4 comments3 people in discussion
Is there any particular reason that we are applying style for scripts/languages through classes, instead of using language and script codes directly? --Z14:02, 5 July 2013 (UTC)Reply
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)Reply
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 en-Latn, because browser support is mixed (if memory doesn’t fail me, Firefox’s default font display for, e.g., ru-Cyrl is different from ru).
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 :lang() 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 :lang(*Latn) {} selector, we’d have to select :lang(de), :lang(en), :lang(fr) {}, etc., and how do we select sh-Latn vs. sh-Cyrl? I don’t think :lang(en-Latn) works at all (but have not tested). Using an attribute selector |[lang*="-Latn"] {} is possible, if we start using extended language codes, but doesn’t have the cascading advantages of :lang(). —MichaelZ. 2013-07-06 16:16 z
Also, romanizations should properly have attributes like |lang="uk-Latn" in brief, or more properly |lang="uk-Latn-t-uk-Cyrl", or |lang="uk-Latn-t-uk-Cyrl-m0-ungegn" in detail, for Romanized Ukrainian. Editors have objected to this, because browsers only look at the uk- and assume it should be in Cyrillic. —MichaelZ. 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. —CodeCat17:25, 7 July 2013 (UTC)Reply
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 {{unicode}} and {{smallcaps}}), this could be solved by using the method you mntioned (currently we are tagging all transliterations with 'lang=""'). --Z15:02, 14 August 2013 (UTC)Reply
Latest comment: 10 years ago4 comments3 people in discussion
I saw 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 mw:ResourceLoader. Dakdada (talk) 09:16, 9 July 2013 (UTC)Reply
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. —CodeCat12:19, 9 July 2013 (UTC)Reply
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)Reply
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. —MichaelZ. 2013-07-12 00:06 z
Need to change the font for Eastern Mari or Meadow Mari (mhr)edit
Latest comment: 10 years ago2 comments2 people in discussion
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. —MichaelZ. 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). —MichaelZ. 2013-11-22 05:56 z
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)Reply
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. —MichaelZ. 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. --WikiTiki8906:02, 22 November 2013 (UTC)Reply
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. —MichaelZ. 2013-11-22 18:25 z
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. --WikiTiki8904:17, 25 November 2013 (UTC)Reply
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. --WikiTiki8905:55, 25 November 2013 (UTC)Reply
Thanks. It's good if it's only a font problem. Which font is used in {{ar-conj-head}} (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)Reply
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)Reply
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)Reply
Š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)Reply
@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)Reply
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)Reply
These are specified already by the code I pasted above:
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. —MichaelZ. 2013-11-25 15:31 z
You can test it out on the declension of ظل(“shadow”):
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: ظِلًّا الْظِلَّ.
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. —MichaelZ. 2013-11-25 16:46 z
Arabic font test
Font
Source
Arabic specimen
Arabic specimen with diacritics forced to appear in correct order (currently prohibited by Wikimedia)
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. --WikiTiki8918:29, 25 November 2013 (UTC)Reply
Droid Kufi Arabic, sizes 11 and 14 in normal, bold, oblique, and bold obliqueHere'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).
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. —MichaelZ. 2013-11-25 19:54 z
So it currently looks like the basic .Arab 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. —MichaelZ. 2013-11-25 21:27 z
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. —MichaelZ. 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. --WikiTiki8901:27, 26 November 2013 (UTC)Reply
Those are still reasons to prefer local fonts over web fonts. —MichaelZ. 2013-11-26 03:23 z
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. —MichaelZ. 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.
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 . . . —RuakhTALK21:43, 25 November 2013 (UTC)Reply
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.
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.
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)Reply
Tahoma 3/3.14 come with Windows XP. Microsoft’s latest version is 5.25.[2] 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.[3]
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). —MichaelZ. 2013-11-26 03:23 z
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 { font-family: Arial Unicode MS, Arial, Times New Roman, Simplified Arabic, Iranian Sans, sans-serif; } (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)Reply
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)Reply
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:
ظل ظِلٌّ ظِلٍّ الْظِلُّ الْظِلِّ ظِلًّا الْظِلَّ
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. —MichaelZ. 2013-11-26 23:08 z
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 וּ (וּ) with what looked the same as וּ (וּ). --Mahmudmasri (talk) 12:56, 26 November 2013 (UTC)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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. 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. —RuakhTALK18:49, 26 November 2013 (UTC)Reply
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? --WikiTiki8918:56, 26 November 2013 (UTC)Reply
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.) —RuakhTALK21:22, 27 November 2013 (UTC)Reply
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. —MichaelZ. 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.)
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 w:combining grapheme joiner or something to preserve the logical order and/or make the older fonts work? —MichaelZ. 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 <nowiki/> between two diacritics does prevent it from reordering them, at least on preview — but the final substitution of <nowiki/> 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 <nowiki/> slyly bypasses. (For example, would something like {{bet}}{{dagesh}}{{kamats}} 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.
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:
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 language is specified in Wikipedia with |class="ar"(corrected: |lang="ar"), why can't we just specify Arabic with this class rather than the generic |class="Arab" which applies to all Arabic-based texts? --Mahmudmasri (talk) 09:27, 27 November 2013 (UTC)Reply
Arabic is not specified with |class="ar" but with |lang="ar", which in CSS is a "pseudoclass". Pseudoclasses are not supported in some browsers (apparently some not-too-old versions of Internet Explorer). --WikiTiki8921:13, 27 November 2013 (UTC)Reply
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. —MichaelZ. 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.
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 |class="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? —MichaelZ. 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)Reply
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. —MichaelZ. 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)Reply
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) (š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: شُكْراً(šukran) (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 Dijan (talk • contribs), 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)Reply
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. --WikiTiki8902:28, 28 November 2013 (UTC)Reply
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)Reply
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)Reply
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)Reply
I couldn't get written confirmation on the order of diacritics yet (شُكْرًا(šukran) vs شُكْراً(šukran)) 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)Reply
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)Reply
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)Reply
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)Reply
The font Traditional Arabic 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)Reply
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)Reply
I checked on Wikipedia to see what they used. This is from Wikipedia:
<span class="script-arabic script-Arab" dir="rtl" style="font-family:Scheherazade,Lateef,Arial,'Arabic Transparent','Droid Arabic Naskh',Amiri,'Microsoft Sans Serif','Segoe UI','Sakkal Majalla','Microsoft Uighur','Arabic Typesetting',sans-serif,serif;"></span>}}—Stephen(Talk)22:34, 22 November 2015 (UTC)Reply
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:
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)Reply
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)Reply
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)Reply
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)Reply
Latest comment: 10 years ago4 comments2 people in discussion
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)Reply
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? —MichaelZ. 2013-12-20 17:58 z
The script codes which have been 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 Wiktionary:Grease pit/2013/December#Georgian_script), Hmng (proposed for inclusion in 1999 but not yet included in Unicode), and Maya. - -sche(discuss)23:58, 21 December 2013 (UTC)Reply
Latest comment: 10 years ago1 comment1 person in discussion
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 bugzilla:63725. Regards, Nemo09:45, 10 April 2014 (UTC)Reply
Latest comment: 9 years ago32 comments5 people in discussion
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)Reply
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? --WikiTiki8917:59, 30 June 2014 (UTC)Reply
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. —CodeCat22:14, 20 July 2014 (UTC)Reply
@CodeCat: I see. What are the character ranges covered by Latinx? 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 Latinx's characters ranges, compared with the other fonts in the list. — I.S.M.E.T.A.23:44, 20 July 2014 (UTC)Reply
@CodeCat: I found Latinx's character ranges; they are the same as Latn'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). Latn and therefore, by consequence, Latinx 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 Latn from "0-z¡-ɏḀ-ỿ" to "0-z¡-ɏḀ-ỿⱠ-Ɀ꜠-ꟿ"? — I.S.M.E.T.A.12:29, 30 July 2014 (UTC)Reply
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
@CodeCat: Here is those fonts' support for those character ranges, according to KreativeKorp:
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.
In the light of this survey, I propose two things:
that Quivira be added to Latinx's font set, and that that list be reorganised thus: Quivira, Code 2000, Junicode, Microsoft Sans Serif, TITUS Cyberbit Basic; and,
that the statement in Module:scripts/data for the characters covered by Latn be changed from "0-z¡-ɏḀ-ỿ" to "0-z¡-ɏḀ-ỿⱠ-Ɀ꜠-ꟿ".
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. —CodeCat21:55, 30 July 2014 (UTC)Reply
@CodeCat 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 la (in Module:languages/data2) and roa-opt (in Module:languages/datax) from "Latn" to "Latinx". Could you make these two small changes, please? — I.S.M.E.T.A.17:55, 1 August 2014 (UTC)Reply
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 suꝑficiālis 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)Reply
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)Reply
@-sche: Liliana brought up the issue of ſ(“the long ess”) in the RFD discussion for suꝑficiālis; 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 R or r, 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 suꝑficiālis, which is entitled Summa philoſophie naturalis magiſtri Pauli veneti nouiter recognita ⁊ a vitijs 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)Reply
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. --WikiTiki8921:18, 2 August 2014 (UTC)Reply
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 detection_scripts? 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. —CodeCat21:30, 2 August 2014 (UTC)Reply
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. --WikiTiki8922:09, 2 August 2014 (UTC)Reply
@Wikitiki89, CodeCat: I foresee a minor aesthetic issue with using Latinx only for Latin Extended-C and -D characters occurring in Latin whilst using Latn 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)Reply
The question that I can forsee might be controversial is: do we want to have entries like suꝑficiālis at all? - No. Hold on while I start an RFD discussion on the matter. -- Liliana•21:35, 2 August 2014 (UTC)Reply
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)Reply
Latest comment: 8 years ago1 comment1 person in discussion
Is it possible to have a Norm script added which is equivalent to Latn but with font-style: normal;? This would allow de-italicisation inside templates like {{n-g}}. — I.S.M.E.T.A.08:59, 23 April 2015 (UTC)Reply
Latest comment: 8 years ago3 comments2 people in discussion
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)Reply
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)Reply
Latest comment: 7 years ago1 comment1 person in discussion
It would be nice if the following class existed:
.nowrap{white-space:nowrap;}
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·tuon00:43, 27 January 2017 (UTC)Reply
Latest comment: 6 years ago1 comment1 person in discussion
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)Reply
Latest comment: 6 years ago13 comments5 people in discussion
New Athena Unicode should be at the top of the font stack for the polytonic 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·tuon21:47, 8 August 2017 (UTC)Reply
Also the rule contained the code font-family/**/:inherit;, which negated the effect of the previous statement, so I have removed it. — Eru·tuon20:28, 13 September 2017 (UTC)Reply
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). --WikiTiki8921:21, 13 September 2017 (UTC)Reply
@Wikitiki89, JohnC5: 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 .polytonic 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·tuon23:07, 13 September 2017 (UTC)Reply
Latest comment: 6 years ago1 comment1 person in discussion
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 .Adlm:
/* Adlam */.Adlm{font-family:NotoSansAdlam,sans-serif;}/* no italics */.Adlm,.Adlm*{font-style:normal;}
Latest comment: 6 years ago4 comments3 people in discussion
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? – Jberkel17:41, 17 December 2017 (UTC)Reply
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) · talk23:35, 17 December 2017 (UTC)Reply
Latest comment: 5 years ago4 comments3 people in discussion
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.4409:55, 31 March 2018 (UTC)Reply
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.5819:09, 17 July 2018 (UTC)Reply
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:
@Suzukaze-c: 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:
Latest comment: 5 years ago1 comment1 person in discussion
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!
Latest comment: 5 years ago1 comment1 person in discussion
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.
Latest comment: 4 years ago3 comments2 people in discussion
@Erutuon: With the new player on, {{audio}} fails to show the player properly. It seems the classes audiolink and audiofile are not only no longer needed but even blocking the implementation of the upcoming player.
with the new player enabled. The style for .client-js .audiometa seems still useful, but the rest (.audiolink * and * .audiofile *) seem completely unnecessary. Even .client-js .audiometa 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)Reply
@Nardog: 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 removing the .audiolink and .audiofile styles as those seem to have no effect under the default settings and break the new player. — Eru·tuon20:47, 9 August 2019 (UTC)Reply
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, .audiometa seems to only appear in {{audio}} and {{ja-pron}} (see this search), so it's a good candidate. — Eru·tuon20:59, 9 August 2019 (UTC)Reply
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: [6]. 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)Reply
1. You could try to find out by looking at the page history.
Latest comment: 4 years ago5 comments2 people in discussion
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 .Hluw, 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·tuon01:29, 5 November 2019 (UTC)Reply
Latest comment: 3 years ago2 comments2 people in discussion
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)Reply
@Adam78: 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, |class="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·tuon17:36, 5 June 2020 (UTC)Reply
Latest comment: 3 years ago2 comments2 people in discussion
@Erutuon Hey! Can you add font-variant-ligatures: no-common-ligatures; to the IPA class? It is displaying fl as a ligature on macOS which causes the syllabic diacritic to be displayed separately from l. — This unsigned comment was added by Fenakhay (talk • contribs) at 05:37, 9 April 2021 (UTC).Reply
Latest comment: 2 years ago1 comment1 person in discussion
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)Reply
Latest comment: 2 years ago2 comments2 people in discussion
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)Reply
Latest comment: 1 year ago4 comments3 people in discussion
@Erutuon Hi! After Wiktionary:Votes/pl-2014-04/Unified Chinese, the Chinese characters are lemmatised at the traditional forms, therefore, supposedly, characters without specifying trad/simp (i.e. .Hani) should use the same fonts as .Hant rather than .Hans. 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)Reply
Latest comment: 1 year ago4 comments2 people in discussion
Hello, Can someone update the class .Tglg to have support the other fonts supported at Wikipedia? Change the Tagalog to here:
/* Tagalog */.Tglg{font-family:'Noto Sans Tagalog','Tagalog Stylized','Baybayin Lopez','Tagalog Doctrina 1593','Noto Sans Hanunoo','Code2000',sans-serif;}.Tglg,.Tglg*{font-style:normal;}
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)Reply
Latest comment: 11 months ago28 comments5 people in discussion
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.
Done (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)Reply
@-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 lang="aii" to lang="syc-Syrn" and lang="tru" to lang="syc-Syrj" (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:
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)Reply
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 lang html attribute for assyrian and suryoyo (turoyo) respectively.
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 @import url() 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.
Ah. Hmm... as long as Wiktionary is treating aii and syc as separate languages, I'm not sure we can or should change the lang= that aii is tagged as being from aii to syc. If the issue is that we need to consider Syrn and Syrj separate scripts and not subsume them into Syrc, and then we need to change aii's script (set by Module:languages/data/3/a) from Syrc to Syrn), and set specific fonts for Syrn and Syrj, we can do that. (And if .Syrc:lang(aii) is not working to apply fonts to currently-Syrc-script-tagged aii, that's a broader issue that 'd need to be fixed, since we're also using that approach with .Xsux:lang(sux) 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)Reply
I'm not understanding all the conversation here, but 'Noto Sans Syriac', 'Noto Sans Syriac Western' applies Noto Sans Syriac Western only if Noto Sans Syriac 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·tuon20:54, 25 March 2023 (UTC)Reply
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·tuon21:00, 25 March 2023 (UTC)Reply
This is a great point, presently 'Noto Sans Syriac' is providing Western and Eastern 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.
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)Reply
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)Reply
@-sche: 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·tuon22:26, 2 April 2023 (UTC)Reply
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)Reply
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·tuon02:02, 3 April 2023 (UTC)Reply
@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)Reply
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.
im struggling to understand what the snippet's purpose is.
no other language class is overriding the default for unicode-bidi 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)Reply
I don't know why a MDN writer thinks unicode-bidi is only for DTD designers. We use unicode-bidi: embed 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, {{m|ar|ابج}}, {{m|ar|ابج}} 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 unicode-bidi: embed; to ابج, ابج with it. There may be other values for unicode-bidi that aren't normally useful for web development, but unicode-bidi: embed is working for us. I'm not clear on the difference between unicode-bidi: embed and unicode-bidi: isolate or whether we could remove direction: rtl;, 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·tuon21:20, 4 April 2023 (UTC)Reply
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)Reply
@-sche, Erutuon, ColumbaBush: 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.) --WikiTiki8900:54, 19 April 2023 (UTC)Reply
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·tuon14:36, 19 April 2023 (UTC)Reply
when you said
the default font for Syriac as a whole
i thought you meant Classical Syriac, not Classical Syriac+Assyrian+Turoyo/Suryoyo
Done. 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)Reply
PS: Please make Glag (Glagolitic) the BukyVede font in the first place: font-family: 'BukyVede', 'Segoe UI Historic', Dilyana, sans-serif;. Also, reduce the font size to font-size: 135%;.
OK, I've added Old Permian to this list (it was already set as the script for Old Komi), with that font. For Xsux, which stages or varieties is the Assurbanipal good for? I see we are currently setting different fonts for Neo-Assyrian Xsux, Hittite Xsux, and Sumerian Xsux (with commented-out lists for Old Assyrian, Neo-Sumerian, and Classical Sumerian Xsux). 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)Reply
@-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)Reply
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? —MichaelZ.22:35, 28 March 2023 (UTC)Reply
This discussion is no longer live and is left here as an archive. Please do not modify this conversation, but feel free to discuss its conclusions.
Split Cuneiform script by language (Akkadia, Sumerian and Hittite)
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)Reply
@ObnoxiousCoder, Metaknowledge, Fish bowl, Erutuon: 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)Reply
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)Reply
to this suggestion.
Done -- Liliana • 20:43, 18 January 2013 (UTC)
Support. —Suzukaze-c◇◇ 21:50, 30 June 2018 (UTC)
Oppose I had the discussions for this open for four entire months. @Wyang, Erutuon —Suzukaze-c◇◇ 20:32, 11 August 2019 (UTC)
