Template talk:Unicode/Archive 1

This page is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Discussion

This template was created to allow easy switching to unicode fonts. This is useful for pages that require unicode to display correctly, such as those written in International Phonetic Alphabet. On some browsers, such as Microsoft Internet Explorer, unicode does not seem to be activated automatically, so this template lets you force it manually.

~~Until MediaWiki 1.4, we won't be able to use a single template more than 5 times in any one article, so this limits the use of this for the time being. MW1.4 should be up within a month (Nov. 2004).~~ I'm pretty sure you can go hog wild with templates now.

One might ask why bother to use a template for this. Simply:

The template code is easier to remember than the HTML font style specification, which must be entered fairly precisely for this to work.
The template code, although not completely transparent, is more transparent than asking new editors to use inline HTML CSS style tags. At least for many editors.
Using the template allows us to change unicode display properties for all articles that employ the template at once. This is useful as the prefered fonts for displaying unicode are somewhat disputable and will change as new, more complete unicode fonts continue to be developed. The way font specification works, we can provide a whole list of suggested fonts and the first one that is active on the user's machine will be selected.

When the page says Unicode, Internet Explorer will activate Unicode.

However, when the page says Arial, Internet Explorer will display Arial. While Arial does include e. g. basic Greek and Cyrillic, it does not include e. g. IPA extensions. These are displayed in Arial anyway when the page says so – that is, they are displayed as the famous rectangles.

David Marjanović | david.marjanovic_at_gmx.at | 00:44 | 2006/5/16

Fonts

The fonts currently in use are, in order:

{{Unicode fonts}}

Controlled by Template:Unicode_fonts.

I realize this is not preferable for everyone (I prefer Gentium over Code2000, and Lucida Sans Unicode over Arial Unicode MS), but the reason is simply that the current order will result in the most characters being displayed, and thus is imnhso the best choice for the Wikipedia. I highly recommend using a personal stylesheet (/monobook.css &c, class .Unicode) to enforce a "prettier" display where preferred. Jordi·✆ 12:46, 16 Mar 2005 (UTC)

Plane One fonts

Code2001, a Plane One font based on Code2000 is not listed, nor should other Plane One fonts be listed. In order to get fonts from higher planes than the BMP to display at all in Windows a font substitute must be provided, for which we can assume the user will have chosen a proper font. MSIE will then only use that font anyway, so there's no need to list them here. Jordi·✆ 01:23, 28 Mar 2005 (UTC)

Can you explain that in more detail, or provide a reference? I don't understand what you mean by font substitute. Thanks. (I'm a Mac user, but curious because I'm interested in how to make multilingual web pages work across platforms). —Michael Z. 2005-03-28 07:57 Z

Out of the box, Uniscribe (the set of services which allow for Unicode text on NT4, 2000, XP, and 2003) only supports the Basic Multilingual Plane ("Plane Zero") of Unicode. In order to get Windows to work with the higher planes, the proper use of Surrogate Code Points (U+D800 through U+DFFF) must be enabled (all Plane 1–16 characters are part of a Surrogate Pair).

The registry setting is HKLM\Microsoft\Windows NT\CurrentVersion\LanguagePack: a DWORD SURROGATE must be created with value 2.

This will not fix MSIE, however. For that browser two more settings must be changed: at HKCU\Software\Microsoft\Internet Explorer\International\Scripts\42 the user must enter a font for IEPropFontName and IEFixedFontName, and since MSIE then still will fail in most cases a third entry is needed at HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\LanguagePack\SurrogateFallback: for each Plane a fallback font can be set. Example Plane1=Code2001, Plane15=Code2001 etc.. I have heard that installing a Microsoft language pack for some languages will do these changes automatically, but have been unable to confirm. HTH, Jordi·✆ 10:45, 28 Mar 2005 (UTC)

Yeesh. I guess you have to use regedit, or whatever, to do that? Do know if you have to perform the first step for Plane 1 to work in Mozilla? —Michael Z. 2005-03-28 17:39 Z

Yeah, you must use regedit (or import a registry file: here's mine, for Code2001). The first step is needed for all applications including browsers like Opera or Mozilla, the other steps are for MSIE only (and programs which use IE internally). Jordi·✆ 18:04, 28 Mar 2005 (UTC)

Thanks for the patient explanation. —Michael Z. 2005-03-28 18:17 Z

Template:IPA

I modified the template based on Template:IPA to look like:

{{{1}}}

The "class" bit allows a stylesheet to override the template, and the {{IPA fonts}} seems to apply here too. dbenbenn | talk 15:14, 20 Jan 2005 (UTC)

Template:IPA fonts includes Gentium font, which doesn't have a very wide range of characters. For example, it has Cyrillic letters for only the Russian language (I think you can manage Bulgarian with it too). It's not suitable for the intended application of Template:Unicode. —Michael Z. 2005-02-8 15:54 Z

Deficiencies with the unicode template

The unicode template does not work with all characters. For instance there's character #7778 the Ṣ character (an upper-case S with a dot beneath it) used in the Tucson, Arizona article, and character #7791; the ṯ character (a t with a bar underneath) used in the Hebrew alphabet article. Quite by chance, I have discovered that the polytonic template, intended for use with Polytonic Greek, actually does the job with both of those, so I've used it for Tucson, and also (in one place only as yet - there's a lot more to do) for Hebrew alphabet. Should the unicode template be upgraded to cover these sorts of characters? rossb 14:51, 25 Feb 2005 (UTC)

Yes, please. It would be confusing to keep using Template:Polytonic for non-polytonic characters. Template:Unicode should support as wide a range of characters as possible.

The danger is promoting a font that has these characters, but is missing some others. Is there a resource with a detailed listing of which characters are supported by what fonts? Alan Wood lists Unicode ranges, but some fonts have only partial support for some ranges.

The real solution is to promote upgrading from MSIE to a modern browser, like Firefox; then we won't have to waste time screwing around with these technical templates. —Michael Z. 2005-02-25 17:03 Z

I suspect that there's extremely little future in trying to urge the use of an alternative browser on the vast majority of users who've had MSIE delivered as standard with their PCs, not to mention those who may be using a PC provided by their place of work, and have no ability or authority to install new software. I hear there's a new version of MSIE coming out this year - maybe it will support unicode better? By the way I wasn't volunteering to upgrade the template myself - I don't have that sort of expertise! rossb 17:16, 25 Feb 2005 (UTC)

As users have become more Internet-savvy, more have started adopting Mozilla browsers. Slow but steady. As far as designing web sites goes, I would love for MSIE 7 to have better unicode and web standards support, but I'm not going to hold my breath.

I won't be updating this template either. —Michael Z. 2005-02-25 23:09 Z

I've also used the polytonic template in the article Sütterlin to display some ligatures that the unicode template couldn't cope with. rossb 13:26, 28 Feb 2005 (UTC)

See Template talk:polytonic for a list of articles where I've used the polytonic template in this way. rossb

When I first made this template, there weren't any more specific things out there, for polytonic, IPA, etc. I think the best use for this template is as the home of the most standard, inclusive unicode fonts possible, for use in cases not by now covered by their own specific templates. If your case is small and isolated, and covered by this template, then by all means use it. If your case becomes larger, you might want to create a new template for whatever character set is critical for your documents. Use your judgement in terms of proliferating templates. I wouldn't suggest continuing to hijack polytonic for other cases if this is in danger of becoming widespread practice (i.e. more than a few cases).

The principle I would follow in font selection is orderly degradation. The first font in the list for this template should be the most character-inclusive available. Each subsequent font should cover a subset of the characters in the previous font, not a partially overlapping different set of characters. This way the degradation is at least orderly and predictable, which to my mind is preferable.

I'm confident the problem will be solved with IE7, but I don't know when that will come out or become standard among MS people. Mozilla and Firefox are not going to conquer IE anytime soon, particularly as the cracker/virus community now begins to take advantage of their growing prevalence, sometimes more vulnerable coding, and usually less frequently applied patches. That's all I'll say on that, so any further comment is free to take over as the last word. --Chinasaur 08:17, 22 Mar 2005 (UTC)

So taking your approach (which seems very reasonable) that the first font in the list should be the most inclusive, I wonder who will be able to take on the task of specifying a more inclusive font for the Unicode template. On the basis of my limited information, the first font used in the Polytonic template would seem to be more inclusive, but maybe it leaves out some characters that the unicode template currently addresses. I wouldn't say that I have a small and isolated case - or at least not a very specific case such as those that the Unicode and IPA templates were aimed at - I've just fairly randomly come across a variety of extended Latin characters that were giving problems - so maybe the Unicode template ought to be addressing this. rossb 09:12, 22 Mar 2005 (UTC)

There will always be special cases, which may have to be handled with specific formatting, or even characters that don't occur in any default system font. Maybe it's best to keep creating more specific templates, so that all examples in different places can be managed centrally (template:sutterlin, or template:latin_ligatures?). Sometimes you will just have to use an image to illustrate an example (e.g. ligature, A iotified (a specific form), hryvnia (in future Unicode version)). —Michael Z. 2005-03-22 20:35 Z

As a final suggestion, it is probably possible (though far from optimal) to use TeX for some of these cases if fonts just won't do it and you don't want to deal with images directly. I'm not sure what we allow inside the <math> brackets though. For even further TeX support look into WikiSophia. --Chinasaur 17:47, 27 Mar 2005 (UTC)

Now that the Unicode template has been updated, I've adopted it in various articles for which I'd previously used the Polytonic template as described above. rossb 08:53, 1 Apr 2005 (UTC)

Problems at yogh

Take a look—I'm not sure what's wrong, but the template isn't working there. IE doesn't show the character, and I know I have Arial Unicode MS. —Simetrical (talk) 23:24, 27 Mar 2005 (UTC)

Whoops, I found the problem. Arial Unicode MS doesn't have the character. So what now? We can't leave 90% of the Internet with boxes. —Simetrical (talk) 23:28, 27 Mar 2005 (UTC)

Code2000 has them. Unfortunately bumping Arial Unicode MS down again may break more than it solves. I'll look into a solution for yogh. Jordi·✆ 01:00, 28 Mar 2005 (UTC)

Continued at Talk:Yogh. Jordi·✆ 01:11, 28 Mar 2005 (UTC)

Characters still not supported

As of today, the template still does not cater for:

the Romanian S with comma below, Ș/ș
yogh Ȝ ȝ
the Vector or Cross Product symbol ⨯ — see X.

rossb 06:29, 11 Apr 2005 (UTC)

Nope, it supports them, but you have to have the correct fonts installed. Nothing the template can do about that. —Simetrical (talk) 20:02, 18 Apr 2005 (UTC)

FYI, on a stock WinXP system, Firefox shows the Romanian esses, but not the others.

Each of the fonts probably supports a different range of characters. Only the intersection of the ranges will be displayed reliably on most Windows systems, but only one of the fonts will be used on a particular Windows system. If these three characters are all that breaks on your Windows installation, then you're probably doing very well. —Michael Z. 2005-04-18 20:27 Z

Can someone who's sure they've got all the right fonts installed check to see whether or not this ☿ shows up as the little squiggly for Mercury (planet)? I added {{Unicode| }} to it, but it still doesn't show up on my sqween. In case you're uncertain, it should look like this:

. Tomer ^TALK 01:26, Jun 6, 2005 (UTC)

Works fine in Safari and Firefox/Mac for me. —Michael Z. 2005-06-6 02:23 Z

I've verified w/ a friend of mine that they work...so I apparently just need to update my fontset. -Tomer = 68.190.162.144 04:00, 6 Jun 2005 (UTC) (I can't log in for some reason)

FWIW that's working fine in IE6 for me also, as are the three samples above. I'm assuming that's Code2000 doing the work since that's the first on the list which I have installed here. What we could do with is some way of knowing what sub-ranges various fonts support, then we could recommend the best for vanilla Unicode, IPA, and various languages. --Phil | Talk 14:06, Jun 6, 2005 (UTC)

Certain blackletter characters don't seem to work correctly, and I suspect this might somehow be the template's fault. Specifically, I know that I have characters like 픸 on my system, because they show up in Firefox, but the Unicode template doesn't make them visible in IE. Is there any way to check which of my fonts is providing me with the ability to see the extra blackletters? —Simetrical (talk) 06:14, 15 Jun 2005 (UTC)

Blackletter is in Plane 1, which I don't think any of the fonts listed in the template support. Code2001 supports Plane 1, but only Plane 1, so it wouldn't be a suitable font choice for IE. Maybe we need another template for Plane 1 fonts? There are probably some MathML fonts that support it too. DopefishJustin (･∀･) June 28, 2005 23:38 (UTC)

You can forget about Plane 1 and higher with Windows. The only way to get characters outside the BMP to work in Windows is by editing the registry, even if you do have the correct fonts. And then MSIE is limited to that one font for the entire plane: it simply won't change to a different font even if the declared font is empty.

At least other browsers (Opera & Firething) can handle the higher planes normally, but still only if the registry hacks are in place. Jordi·✆ 18:42, 15 July 2005 (UTC)

Nonsense, Plane 1 characters (for example in Darius I of Persia) work fine for me in Windows 2000 and Windows XP with Firefox, no registry changes necessary. Code2001 needs to be installed, of course. DopefishJustin (･∀･) 17:49, July 19, 2005 (UTC)

On closer inspection, the SURROGATE registry entry is set. I always install all language packs so I suppose that could have set it. I don't think it's unreasonable to expect people who want to view exotic characters to have language packs installed, though. UTF-8 (which is what Wikipedia uses) doesn't make use of surrogates, though, so I'm not sure what relevance a setting for surrogate display would have. IE is still hopeless without additional changes, unfortunately. DopefishJustin (･∀･) 18:00, July 19, 2005 (UTC)

You still need surrogates in UTF-8: if you don't, ̰ (Gothic A) displays as Ã¾. There is then still an issue with UTF-8 encoding and higher planes in Internet Explorer, regardless of the surrogate setting. UTF-8 characters outside the BMP (chars U+10000 and up) encoded using NCRs will only work if the user sets the MSIE encoding to "User defined", or the server is broken to send "x-user-defined" (which breaks all other browsers). And even then you run into issues if the SURROGATE bit is not set.

Since we CANNOT rely on Wikipedia visitors to have the surrogate flag set, nor can we rely on them having a font capable of displaying Plane One (I know of only three such fonts), I stand behind my words.

FYI, the surrogate bit is not only for MSIE: it is for ALL Windows applications. Firething and Opera won't be able to display Plane One characters either if surrogate=0. Jordi·✆ 18:30, 19 July 2005 (UTC)

"UTF-8 (which is what Wikipedia uses) doesn't make use of surrogates" indeed but the windows api isn't utf-8 based. So it has to be converted to UTF-16 for passing to the windows display routines. If surrogate support isn't enabled (i'm unclear why MS didn't enable it by default, possiblly some compatibility issue) then afaict you can't use non-bmb characters with the windows text system period. Plugwash 12:49, 12 March 2006 (UTC)

Built-in?

It seems to me that while this template is a good idea, it would be vastly more useful and convenient if it was handled at the level of the MediaWiki software; that is, make MediaWiki aware of the ranges of characters that can be displayed unassisted by IE, and have it put any others in s with a CSS class of "unicode" when generating the HTML for the page, and then specify the Unicode font list in the stylesheet. This would have several advantages: editors could enter Unicode characters in an article and it would "just work" without having to do anything extra, all existing non-template-using articles would work with no conversion effort, the article markup would look much cleaner, the server hit of using nested templates everywhere would be eliminated, and the HTML generated would be more compact due to not duplicating the font list every time. The same IE problem affects any site using MediaWiki (including the other Wikimedia projects and Wikipedia languages) so it seems reasonable to centralize it; since the font list would be in the stylesheet it could of course be customized by individual MediaWiki users. DopefishJustin (･∀･) 18:17, July 15, 2005 (UTC)

One major complication i see with this is that combining diacritics etc often won't work over such boundries. So doing this automatically would mean a much greater knowlage of unicode to know at which points its safe to insert a font switch. Plugwash 12:51, 12 March 2006 (UTC)

Code2000 occupying all fonts

Since installing the Code2000 font, all Unicode characters like IPA characters or numerical symbols are represented with that font. I must say Code2000 is far away from rendering good characters - how can I change my Firefox / Windows XP to regulary use Arial Unicode instead for all characters that are representable with Arial Unicode? --Abdull 22:01, 14 August 2005 (UTC)

Change your Firething font settings: it should allow you to pick a font for each Unicode range (the Mozilla suite does, as does Opera). This template does not affect any browsers except for the broken MSIE. Jordi·✆ 03:50, 15 August 2005 (UTC)

Something broken in MediaWiki?

Howcome all the {{Unicode|foo}} references are coming out as {{{1}}} (like so: foo )? Something appears to be rather broken! — OwenBlacker 15:07, August 20, 2005 (UTC)

the second font-family

Why, user:Naive cynic, did you say "rv - only Internet Explorer needs this"? (In reference to the reversion from what I changed on 8/20 or 8/21.)

If Internet Explorer does need it, well--many people use Internet Explorer, and we shouldn't exclude them from enjoying Wikipedia. And what harm can come to others (non-IE users) by putting the /* and */ around the whole of the second font-family: segment?
Which is better? "/* font-family: inherit */", or "font-family: /**/ inherit;"? To me, as I read it, neither looks functional. And if the second one is functional neither way, it should just be deleted. Why include the comment-out?
The "font-family" attribute, or whatever it's called, is already extant immediately preceding, so if we don't remark out the second one the only way that w3.org suggests, why even include it?

~~Therefore, I'm deleting the whole of that second part. There's no need to have it.~~ I see why the font-family: inherit; should be there, just in case there is no suitable font, and the default font will suffice. So why the comment-out? -- D. F. Schmidt (talk) 06:46, 22 August 2005 (UTC)

This unusual comment uses another bug in Internet Explorer to hide the rest of the line from IE 6. See also Template talk:IPA#Technical details. -- Naive cynic 07:15, 22 August 2005 (UTC)

Usage of this template

It seems as this may be a reply to a couple of the discussions started on this page, but I've made a comment on the talk page of the font listing that would likely be of interest to maintainers of this template, as well: Template talk:Unicode fonts#Use of this template. —Gordon P. Hemsley→✉ 10:13, 25 September 2005 (UTC)

Font declaration has been moved to Common.css

The way Template:IPA, Template:Unicode, and Template:Polytonic do their job has been changed. They should continue to work as before. Sorry if this causes any inconvenience.

The font declarations for these three templates have been moved to the style sheet at MediaWiki:Common.css. This reduces the size of Wikipedia pages' code, by as much as 100kB in the case of IPA. The respective font declarations are applied to HTML entities with one of the following attributes (capitalization counts). The three templates in question have been updated, so they will continue working as before.

class="IPA"
class="Unicode"
class="polytonic"

The only disadvantage of the new scheme is that only admin users are able to edit the font declarations in Common.css (or is it an advantage?). But you can override the font declaration for yourself by editing your own Wikipedia user style sheet. See Template talk:IPA#Applying custom styles to IPA text. Alternatively, you can use a browser like Mozilla Firefox, Opera, or Safari, in which Unicode text just works.

The reason for this change is that the Mediawiki software no longer allows comments in inline style sheets, because Microsoft Internet Explorer's incorrect parsing is unsafe and can be used for cross-site scripting attacks. See Wikimedia bug no. 3588.

Similar font declarations applied to any tables or divs on Wikipedia should have one of the above-mentioned class attributes added instead.

The style sheet code in Common.css looks like this:

/* Support for Template:IPA, Template:Unicode and Template:Polytonic. The inherit declaration resets the font for all browsers except MSIE6.  The empty comment must remain. */
.IPA {
        font-family: Chrysanthi Unicode, Doulos SIL, Gentium, GentiumAlt, Code2000, TITUS Cyberbit Basic, DejaVu Sans, Bitstream Vera Sans, Bitstream Cyberbit, Arial Unicode MS, Lucida Sans Unicode, Hiragino Kaku Gothic Pro, Matrix Unicode;
        font-family /**/:inherit;
}
.Unicode {
        font-family: TITUS Cyberbit Basic, Code2000, Doulos SIL, Chrysanthi Unicode, Bitstream Cyberbit, Bitstream CyberBase, Bitstream Vera, Thryomanes, Gentium, GentiumAlt, Visual Geez Unicode, Lucida Grande, Arial Unicode MS, Microsoft Sans Serif, Lucida Sans Unicode;
        font-family /**/:inherit;
}
.polytonic {
        font-family: Athena, Gentium, Palatino Linotype, Arial Unicode MS, Lucida Sans Unicode, Lucida Grande, Code2000; 
        font-family /**/:inherit;
}

Please discuss this at Template talk:IPA#Font declaration has been moved to Common.css. —Michael Z. 2005-10-4 15:40 Z

Font problem with y with macron

y with macron, ȳ, Unicode 233 hex, which is used in Old English morphology, appears as a box on my computer even though it is enclosed in Template Unicode. The same problem occurs with Template IPA: ȳ

I use MSIE 6.0, and my fonts include Arial Unicode MS, Microsoft Sans Serif.

The problem appears to be that Arial Unicode MS appears before Microsoft Sans Serif in MediaWiki:Common.css, but Arial Unicode MS doesn't support codes 218-24F. --teb728 19:26, 6 November 2005 (UTC)

Sounds like you need to create a new template with a font list geared towards your type of text. Just copy this one and edit the copy appropriately after checking the fonts. Plugwash 23:41, 7 April 2006 (UTC)

Actually you will wan't to work from an old (pre migration to main CSS) version of this template and then if its used a lot discuss putting the list in main CSS with the admins.

I created {{unicode2}} which favours fonts that support all chracters in the Latin Extended B range. This should solve your problem. —Ruud 20:18, 2 May 2006 (UTC)

{{unicode2}} is a bad name for a template. Why not something like {{unicodeLatinExtendedB}}? --cesarb 23:45, 2 May 2006 (UTC)

We probably want to have templates for each language in the future, so the  is set correctly, as well as select better fonts for IE users, making {{unicode2}} obsole with {{oldenglish}} and {{middleneglish}}. But if the name really bothers you, you're free to rename it (although I suggest to keep it as short as possible). —Ruud 00:29, 3 May 2006 (UTC)

Test: ȳ —Ruud 03:45, 3 May 2006 (UTC)

Thanks for the new template. I note (for completion of this section) that {{unicode2}} has been renamed to {{latinx}}. --teb728 05:50, 20 May 2006 (UTC)

Adding a mk: language link

Can you please add the Macedonian language link (mk:Уникод), so Macedonian editors who come here would know that we already have such a templete. Thank you. --B. Jankuloski 23:25, 27 May 2006 (UTC)

Done. —Ruud 02:04, 28 May 2006 (UTC)

Between this template and IAST template

...which one is more suited to render transliterated devanagiri script words on most computers? --Babub^{(Talk|Contribs)} 14:48, 19 July 2006 (UTC)

The need for the Unicode template to display Devanagari is no longer as much of an issue as better support for Unicode is more widespread. The Unicode template is rarely used on the Hinduism pages that use Devanagari. The IAST transliteration method can be shown via the IAST template if IAST is used. The template I see most often on the Hinduism pages for Sanskrit is some variant of this: ([[Sanskrit]]:{{lang|sa|गणेश पुराणम्}}; {{IAST|gaṇeśa purāṇam}}) which displays:

(Sanskrit:गणेश पुराणम्; gaṇeśa purāṇam)

Notice that no explicit Unicode tage is used. The LANG tag argument is just the raw Unicode character value. The IAST template and the Unicode template do different things. IAST is one of several incompatible transliteration methods for Devanagari. So using the IAST tag specifies which of the alternative methods is being used. Also note that IAST is a transliteration method for a writing system (Devanagari) which is used for multiple languages such as Hindi, Sanskrit, etc. Sanskrit is a language that can be written using various writing systems, such as Bonji, IAST, Devanagari, etc. Buddhipriya 02:38, 24 February 2007 (UTC)

‽

Maybe we should include the ‽ in this. Randfan

Need support from admin

I need admin support in creating "Template:Unicode" at Marathi Language Wikipedia (wiki language code mr) as it is,from english wikipedia for following reason . Only the difference is we do not want you to protect immidiately, after neccessary translations if any admins at Marathi wiki can protect the same.

We at Marathi Language Wikipedia are translating articles related to Devanagari and portions of Sanskrit article of english wikipedia are also being translated.

So earliest help from admin is requested.

Mahitgar 07:37, 9 November 2006 (UTC)

You don't need an en admin to do this (although you do need an mr admin). Add the following to mr:MediaWiki:Common.css:

.Unicode {
        font-family: Code2000, TITUS Cyberbit Basic, Doulos SIL, Chrysanthi Unicode, Bitstream Cyberbit, Bitstream CyberBase, Thryomanes, Gentium, GentiumAlt, Visual Geez Unicode, Lucida Grande, Arial Unicode MS, Microsoft Sans Serif, Lucida Sans Unicode;
        font-family /**/:inherit;
}

and create the mr template Unicode as

<span class="Unicode">{{{1}}}</span>

Hope that helps. --ais523 08:38, 9 November 2006 (U T C)

It seems that the relevant section was already in mr:MediaWiki:Common.css, so I've created mr:Template:Unicode for you. Hope it works... --ais523 08:44, 9 November 2006 (U T C)

DejaVu font

I would like to encourage to add the DejaVu Sans font to the Unicode template, like:

.Unicode {
        font-family: Code2000, Code2001, "Free Serif", "TITUS Cyberbit Basic", "Doulos SIL", "Chrysanthi Unicode", "Bitstream Cyberbit", "Bitstream CyberBase", "DejaVu Sans", Thryomanes, Gentium, GentiumAlt, "Lucida Grande", "Free Sans", "Arial Unicode MS", "Microsoft Sans Serif", "Lucida Sans Unicode";
        font-family /**/:inherit;

Deriving from the free Bitstream Vera font the DejaVu project (see http://dejavu.sourceforge.net/) tries to fill all missing Unicode characters. It grows with each revision and therefor became the default font of the Fedora Linux distribution.

Greetings, Andreas 09:04, 15 July 2007 (UTC)

deprecate

This template should eventually be deprecated. There is no dichotomy "unicode vs. non-unicode". Out-of-the-box support of frequently used Unicode characters is quite good these days, and for obscure Unicode ranges, there is often no single font. You need to select different fonts for {{cuneiform}} and for {{coptic}}, yet both are Unicode fonts. I appreciate the historical necessity of this template, and we should certainly keep it around as a fallback option, but most cases should now be addressed by {{lang}} and friends. dab (𒁳) 10:18, 24 July 2007 (UTC)

Template update

I would like to suggest a template update. At the moment, on the English Wikipedia the S-comma is displayed as such ș (image), which as you can see, it looks pretty odd. On the Romanian Wikipedia (the S-comma is a Romanian character), this problem has been solved (here's an image of how the character looks on the Romanian Wikipedia).

This is the code of the Unicode template from the Romanian Wikipedia, which causes the character to be displayed normally:


<span class="Unicode" style="font-family:TITUS Cyberbit Basic, Code2000, Doulos SIL, Chrysanthi Unicode, Bitstream Cyberbit, Bitstream CyberBase, Bitstream Vera, Thryomanes, Gentium, GentiumAlt, Visual Geez Unicode, Lucida Grande, Arial Unicode MS, Microsoft Sans Serif, Lucida Sans Unicode;">{{{1}}}</span>

Making this change is important because the S-comma is the grammatically correct character of the Romanian alphabet, not S-cedilla, which is still used by many people, and it is important to encourage people to use the correct one. Diego_pmc ^Talk 21:26, 18 September 2008 (UTC)

It doesn't look like that on my machine (Safari, Opera & Firefox/Mac). Perhaps you have a font with the incorrect glyph for the character installed on your machine. Please do some testing before you override other people's display. Cheers. —Michael Z. 2008-09-18 22:49 z

transliteration vs transcription

The Academy of the Hebrew Language prescribes these [1] guidlines (from p.3) for Hebrew transliteration. Since this isn't IPA, do I assume correctly that the Template:Unicode is the correct choice for representing this code? Dan Pelleg (talk) 23:02, 24 March 2009 (UTC)

messed up

This template no longer forces a consistent font, so that it look bad on screen. The template hasn't been changed; it the problem perhaps in the html unicode tag? kwami (talk) 07:39, 19 August 2009 (UTC)

Never mind! It's a problem with WP beta. kwami (talk) 07:42, 19 August 2009 (UTC)

Used idle for a purpose?

In Advertising (at least today's version [2]), the template is used like this: {{unicode|}} (early in the source text). Is this useful for some reason? -DePiep (talk) 19:28, 19 November 2010 (UTC)

Font override

I'm trying to override the fonts used in this template by using custom CSS. My code is:

html, body, .Unicode, .IPA {
  font-family: Torid !important;
}

It works with normal text, but not when this template is used; e.g. {{Unicode|Ᵹ}} renders as Ᵹ, using Arial Unicode MS (which lacks insular G) instead of my font.

Does anyone know what I am doing wrong here? Laricaney (talk) 15:35, 15 February 2011 (UTC)

You need to add the !important; keyword. I added it in your code above. — Edokter (talk) — 16:15, 15 February 2011 (UTC)

It worked, thanks! Laricaney (talk) 16:55, 15 February 2011 (UTC)

font list

FYI, the font list for the .Unicode CSS is now is MediaWiki:Common.css/WinFixes.css. Took me awhile to track that down, so I thought I'd save others the time.

As an aside, the order of these fonts was decided several years ago. Is there any need to review and possible update it? ⇔ ChristTrekker 20:27, 27 June 2011 (UTC)

Patently useless

This template is essentially useless, as there is no guarantee that it will cause the desired character to be displayed in one's browser. For example, I'm running Linux with the GNOME desktop. All I see in place of the template are little rectangles with flyspeck-sized hexadecimal digits, supposedly representing the hexadecimal value of the Unicode character. Maybe it can be made to work with a limited set of font files that Wikipedia visitors may or may not have available on their machines, and may or may not know how to utilize to get the characters to display. A better approach would be to use in-line graphics, perhaps SVG icons, derived from PostScript or True Type files that contain the character to be illustrated. — Quicksilver^{T @} 22:37, 29 November 2011 (UTC)

It is not useless. A guarantee is overasked. It does, quite good, provide a best possible solution for situation wiki cannot guarantee, but can only foresee. If your situation does not show the right glyph sometimes, that says: "too little Unicode fonting", not "drop Unicode fonting". -DePiep (talk) 22:54, 29 November 2011 (UTC)

Plus, note that the associated CSS with the fontstacks is located in MediaWiki:Common.css/WinFixes.css, and that file is only loaded if you have... Windows. So this template would indeed have no effect on Linux. (And we expects Linux to show everything perfectly.) — Edokter (talk) — 23:36, 29 November 2011 (UTC)

AIUI the template is a reaction to deficiancies in IE (not sure if these have been fixed in later versions). Most other browsers will automatically search other fonts if the glyph they need isn't in the currently selected font. Of course if you don't have a suitable font at all you won't get the glyph on any OS. Plugwash (talk) 13:32, 2 December 2011 (UTC)

These font declarations are probably going to be trimmed, sorted and moved back to Common.css to make it multi-platform again. Most of these font are never found on Windows machines anyway (except for those few geeks that install them). — Edokter (talk) — 13:44, 2 December 2011 (UTC)

Why trim the list? If someone does have a superior font installed, why not use it? The fonts specified should be those with the best coverage, in order of coverage, period. If it's uncommon and most people don't have it installed, so what? The browser will continue down the list until it finds the best one that is installed. ⇔ ChristTrekker 14:20, 5 December 2012 (UTC)

I expressly do not want graphic replacements of text. It breaks copy-and-paste. In cases where illustration of a glyph appearance is needed, sure, provide an image. But not in text. ⇔ ChristTrekker 14:23, 5 December 2012 (UTC)

suggestions for extending/improving this template outside the BMP

The fonts selected here are woefully inadequate outside the BMP. I was hoping to do something to make the emoticons (and other symbols) I frequently use show up in more browsers, but since {{Unicode}} (currently) specifies "Arial Unicode MS", "Lucida Sans Unicode" as its fonts, I'm out of luck. Those fonts have terrible coverage in the blocks I'm interested in.

The two fonts that seem to do pretty well in the three SMP-1 blocks I care about are Segoe UI Symbol and Brampton. They cover 458⁄533, 63⁄76, 34⁄70 and 129⁄533, 57⁄76, 7⁄70 of them, respectively. In the case of Brampton that's still not great, but yet far, far better than anything else I have installed (only a couple have even one or two characters).

What I'd like to suggest is a {{unicode1}} template for SMP-1 that specifies a different class, with different fonts. Alternatively, extending this template with a plane parameter. By default it would be plane 0, the BMP. ⇔ ChristTrekker 14:17, 5 December 2012 (UTC)

I think the underlying problem is that the vastness of Unicode is inherently unsuited to specifying a single list of fonts to handle every required character set.

Rather than attempt to make one size fit all with this template, or create the same problem with a similar untargeted unicode template, I suggest that you create a template specifically suited to the range(s) of characters that you want to handle. (If the characters are only used on one or two pages, you could of course simply apply a font-family style attribute using  tags manually.)

See {{Script}} and, for example, {{Script/Coptic}}, for an existing series of subtemplates which seek to do this.

In case the browser already has a suitable default font, it might also help to specify a generic fallback as the last item in the font-family list, e.g.

<span style="font-size-adjust:0.54; font-family:'P22 Declaration Script','American Scribe','National Archive', Ovidius, 'Ovidius Script', Horizon, 'Final Frontier Old Style', Charcoal, Virtue, sans-serif;">...</span>

— Richardguk (talk) 17:48, 5 December 2012 (UTC)

{{Script}} mixes up scripts and languages. It should not do when used for this purpose. -DePiep (talk) 19:05, 5 December 2012 (UTC)

I'm not sure I'm following what you're saying about {{script}} being problematic. I glanced very briefly at it, and abstracting the font choice away from the technical underpinnings of Unicode and instead toward the language/script being used, seems fairly reasonable. ⇔ ChristTrekker 19:53, 5 December 2012 (UTC)

We only need the script name to serve the right font-family. {{Script/Coptic}} is a good example because Coptic is a script name (so we can look for fonts that are good in Coptic script, which is in two blocks btw). But sister template {{Script/Slavonic}} is named after a language (Slavic_languages, there is no Slavonic script), which can be written in many scripts (Serbo-Croatian has both Latin and Cyrillic as official writing system). In short: to supply a good font-family in a template, we need to know the script and find matching or specialised fonts.

Now to help the edtiors that use the {{script}} template, we could accept a language-id as input when that leads to a single script (and font-family from there). Still, that should be unambiguous. Basically this can be done in a single #switch set.

As the template is now, there are exceptions and forkings for languages too which complicates the logic unnecessarily.

If a language class is required for other reasons, that can be added independent of the font-family. -DePiep (talk) 02:48, 6 December 2012 (UTC)

It is worse. {{Script}} sets the lang= value once or twice, and not always the same. First in the subtemplate (sometimes), second (always) in the second half of the main template (#switch lang=... part). -DePiep (talk) 03:50, 6 December 2012 (UTC)

I agree with your initial statement. Unicode is too big for just one font. If you are suggesting something along the idea of a {{UnicodeBlock}} template (or |block= with this template) instead, I can see that. It does however require that users have even more technical knowledge of Unicode than my original "plane" suggestion. ⇔ ChristTrekker 19:53, 5 December 2012 (UTC)

In general, individual Unicode blocks and/or planes will not necessarily correspond to particular scripts or fonts. Conversely, some scripts and fonts are likely to be scattered across more than one block or even across more than one plane. So the script-based approach is generally more robust – and also more comprehensible to editors interested in the relevant subject, who might not know or care about the underlying code points. — Richardguk (talk) 20:20, 5 December 2012 (UTC)

OK, true. So are you suggesting something like {{unicodelatin|ʧ}} or {{unicode|ʧ|script=latin}} to deal with obscure Latin (in this case) characters, that in turn sets a style class that has good coverage over all Latin blocks of Unicode? This does seem to be what {{script}} does; I still don't understand DePiep's objection. What happens with characters not associated with a particular script in the usual sense, like the emoticon block? ⇔ ChristTrekker 21:51, 5 December 2012 (UTC)

Well the example you give uses the character ʧ U+0207 LATIN SMALL LETTER TESH DIGRAPH which is part of the IPA extensions Unicode block, so {{IPA}} might be sufficient. If you instead want to display characters not generally related to IPA, the best approach would depend on the details. But {{Script}} is designed to handle a range of scripts, with a subtemplate for each. So you could, perhaps, edit {{Script}} to handle an additional script name. But the template currently only uses four-letter ISO 15924 script codes and it's not clear to me whether an four-letter ISO code exists for your intended purpose. Can you clarify what range(s) of characters you want to display? — Richardguk (talk) 22:50, 5 December 2012 (UTC)

Sorry about the IPA char; I used Character Map in Windows and plucked something random from its "Latin" Unicode range. Mea culpa. As for specific ranges, see the links in my original post.

I've done just a bit of reading about ISO 15924, and maybe the "Zsym" code could be utilized here. Connect it with a font that has good coverage of dingbats, and it's done.

If arbitrary codes could be used, I was thinking that a code per "subject" would perhaps be useful. For example, font Foo might have good coverage of all symbols, but an uninspired design, while font Bar only covers the sports-related dingbats with really nice glyphs. If we allowed {{script/sports}} you could show the nicer one, but someone else could still use {{script/symbol}} for the same char and have it appear correctly. Just a thought, but probably moot if it's sticking to ISO 15924 codes. ⇔ ChristTrekker 23:30, 5 December 2012 (UTC)

Certainly "symbol" (and, in its looser senses, "dingbat") would be too broad a classification to be any more helpful than the general class applied {{Unicode}}, so more specific subsets such as "sports" would make sense. However, as you've seen, that would depart from the ISO scheme and is not a script in the ordinary sense, so {{Script}} would also be inappropriate. Perhaps each group of symbols needs a separate template, or {{Unicode}} could have a parameter added so that it used a subtemplate if a particular type of symbol were specified. But it's still difficult to judge without knowing the specific character ranges, proposed font-family list and which articles would be affected. If the symbols are very obscure and part of a relatively small block, creating new templates might cause more confusion than simply styling the symbols manually with  tags. Are you sure that there is a big enough problem at present to justify template changes? — Richardguk (talk) 00:22, 6 December 2012 (UTC)

On IPA: {{IPA}} is used for IPA characters as is the topic here. IPA is not defined as a separate script in Unicode. Those weird IPA characters are in special blocks, see Phonetic symbols in Unicode, but regular Latin, Greek and Cyrillic characters are used too. It seems to me that for IPA, the problem is solved. -DePiep (talk) 02:48, 6 December 2012 (UTC)

I'm working in the {{script/sandbox}}. Basic trick: write font-family in subpage {{Script/Cyrs}}. Tests in {{Script/testcases}} for Cyrl, Cprt, Cyrs. Not yet finished, but basics are there. -DePiep (talk) 04:36, 6 December 2012 (UTC)

I see {{IPA}} doing essentially the same thing as {{script}}, the only difference being that IPA≠"script" so it's outside the definition of {{script}}. 😒 Though I understand that reasoning, it bothers me a bit because it introduces a technical redundancy through (debatably) over-narrow scope. Is there a template for using specific fonts for mathematical symbols? ⇔ ChristTrekker 14:10, 6 December 2012 (UTC)

I'm not sure how widely the proposed template(s) would be used. What I do know is that I use the symbols fairly often, and going around multiple places later to clean up font choices in spans is a real drag. I like to think that having a template for using them well would encourage their use, and since they are potentially very handy, I see that as a good thing. ⇔ ChristTrekker 14:10, 6 December 2012 (UTC)

You two talking describes all issues very clear, IMO. Let me classify the issues (situations), as I see them.

Presumption: we want to use {{script}} to allow for preferred fonts in rare character sets. We can accept a first parameters to identify that char set. So far, it is broadly defined and we like that. Article code would look like: {{script|Domino tiles|<tile 5-1><tile 1-4>}} and use a suggested font.
For Unicode defined scripts i.e., a writing system for a language (ISO 15924 script codes and Unicode, below in Template:Unicode navigation are: 1. a few generic character sets like diacritics. 2. ~80 modern scripts, used today. 3. ~25 ancient and historic scripts. All identified by an ISO alpha-4 code.
Unicode defined symbols: math, playing cards, music, etc. Unicode does not use an ISO alpha-4 code for them (although they do exist, like Zmth for mathematical notation).
Language and style variants, like Nastaliq (calligraphic Arab).
Useful groupings like the IPA.

Our job is to serve the preferred (and fall-back) font-family to each situation.

It would be great if the average editor can enter a meaningfull (any meaningfull) id into {{script}} and then will be served the specific font-family (out of sight). So my inroads in the sandbox is: allow any input, derive an internal script code for that (ISO 15924, or "Unicode block Sora Sompeng", and return the right font-family. -DePiep (talk) 16:53, 6 December 2012 (UTC)

I've started a template based on the ideas generated so far. It's just the template; corresponding classes need to be added to the CSS for it to actually do anything. Basically, I went through some of the "major" symbol blocks I'd been thinking about (Miscellaneous Technical, Miscellaneous Symbols, Dingbats, Domino Tiles, Playing Cards, Miscellaneous Symbols and Pictrographs, Emoticons, Transport and Map Symbols, Alchemical Symbols) and grouped them by subject area. It's only a first attempt, but I think you can see where it's going. ⇔ ChristTrekker 14:49, 6 December 2012 (UTC)

I see. So one can use class=... (and add the class) instead of style=font-family:...? I've asked this at WP:VPT.

Other templates: {{music}} is about this, but works totally different (you won't like it). It's old and using graphs. And there is {{lang}}. -DePiep (talk) 15:24, 6 December 2012 (UTC)

You can put the style (font choices) inline, but if at some point in the future you change your mind (e.g. Windows 10 comes out with a better font included) all your old stuff is stuck using your old choice. If you used a class, you change the definition there and everything everywhere gets the update. If you're only talking about one template it's not too bad, you'll only miss the places where it was subst'd in. But if you've used this font choice in 30 templates, you have 30 places to update (and you still miss those who subst'd). ⇔ ChristTrekker 15:37, 6 December 2012 (UTC)

OK then. In your situation you'd have to change the classes, inmy plan you'd have to change the subtemplates (both could be 100). I too do not want specific templates for each character set-to-font-family (like {{IPA}} is now). -DePiep (talk) 16:57, 6 December 2012 (UTC)

Eh, but exactly where is that list class-to-fontfamily administered? ~-DePiep (talk) 00:23, 7 December 2012 (UTC)

I'd reckon mediawiki:common.css. I'm using User:ChristTrekker/vector.css for testing right now. All the fonts are the same; I haven't made any effort to hunt down SMP-1 fonts and figure out best coverage. What I should probably do is, for all the character groups, generate a complete list of the characters in each. ⇔ ChristTrekker 13:12, 7 December 2012 (UTC)

Yep. The good news is: this is WP, it doen't have to be right 1st version. If you have the right font-family for say Domino tiles, that could be put into class while all the others (like mahjong tiles) keep using the "Unicode" generic class. It's just that the class encoders don't like instable propositions. So what we need is stable a font-family per script/block/subset. -DePiep (talk) 23:39, 7 December 2012 (UTC)

You may want to check on my progress. I've listed the major character groupings (in my interpretation of course), and have started to evaluate fonts. Feedback encouraged. ⇔ ChristTrekker 20:23, 11 December 2012 (UTC)

I've been following the discussion from the sideline, and I think I should say something. Currently, the template only targets XP, as it has less-refind support for unicode then Vista/7/8 and other OSes. For anything else, nothing special is done and the browser is responsible for proper font support. Now, to the idea of UnicodeSymbol, I like the idea, but I feel it is headed for disappointment. That is because at it's core, it will depend on the user being required to install specialized fonts. Any solution should not work on the premise that it might work for some users that happen to have a certain font installed; it should work for all users without any user intervention. Currently, the only technical option to offer this is webfonts. Any CSS font declarations that only work for those with the fonts installed is simply not a viable solution. — Edokter (talk) — 22:48, 12 December 2012 (UTC)

First, my work does not target XP. My thought at this point is to create a new template that is universally available. Other than that, I don't disagree. The idea is to give the user the best experience he can realistically hope to have. (I stop short of saying it should work for all users; that's flatly impossible.) For now, it's still partly in the conceptualization phase, with tentative implementation (which is thus far influenced by my MSWin use) that may change. I don't object to using web fonts, and feel they should definitely be considered as options in the font stack. I've installed a couple libre fonts for testing; if they are available gratis as web fonts that would be fantastic. OTOH, I don't want to require web fonts, as many browsers currently in use don't support it. ⇔ ChristTrekker 23:36, 12 December 2012 (UTC)

Errr, to clarify, this template could be extended with the ideas I've been working on. But the new CSS would go in a non-XP-specific place, not loaded via the browser-sniffing JS it currently is. ⇔ ChristTrekker 23:38, 12 December 2012 (UTC)

(edit conflict)Happy to read you, Edokter, in this. I have to do research. -DePiep (talk) 23:43, 12 December 2012 (UTC)

We really need to come to a consensus about this. Do we want to implement this idea, and if so, in this template (who will do it?) or a new one? Who will add classes to common.css? ⇔ ChristTrekker 21:50, 20 December 2012 (UTC)

Anyone still following this thread? Or development? ⇔ ChristTrekker 19:47, 31 December 2012 (UTC)

Support seems to be in favor of adding the new functionality here rather than creating another template. Any additional opinions? ⇔ ChristTrekker 16:20, 14 January 2013 (UTC)

Request

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Can someone please make the proposed changes here and in mediawiki:common.css? This involves adding a subject parameter here, about two dozen .UnicodeSubject classes in the CSS, and some logic here to make the CSS class be .Unicode by default but .UnicodeSubject if a valid subject is specified. The list of subjects, and related list of fonts to use, are listed. The fonts used by .Unicode can be supplied as last-choice fallbacks, as well. ⇔ ChristTrekker 16:15, 15 May 2013 (UTC)

@ChristTrekker: Sorry for the delay. It's likely that this is still waiting because the request is not completely clear. Please clarify what exactly is needed, preferably by making sandbox copies of the template and CSS which can be copied and pasted over. Thanks — Martin (MSGJ · talk) 20:06, 21 May 2013 (UTC)

See Template:Unicode/sandbox, Template:Unicode/doc/sandbox, and User:ChristTrekker/vector.css (additions for Mediawiki:Common.css). ⇔ ChristTrekker 13:50, 23 May 2013 (UTC)

Okay, I have made the changes. Can you check if everything is working okay and let me know of any problems? — Martin (MSGJ · talk) 14:10, 23 May 2013 (UTC)

I see it has {{ucfirst:{{lc:{{{subject}}}}}}}. Is that different from {{ucfirst:{{{subject}}}}}? -DePiep (talk) 14:20, 23 May 2013 (UTC)

And how can this produce: UnicodeUI, UnicodePoliticsReligion for class names, wrt capitalisation? -DePiep (talk) 14:26, 23 May 2013 (UTC)

The goal is just to standardize them somehow—I think it's enough to ask people to spell them right; we should correct for capitalization. {{ucfirst:{{{subject}}}}} won't deal with cases where someone puts, for example, |subject=CHEM. And, my mistake, I overlooked the UI and PoliticsReligion cases. (Too anxious to push this forward after waiting for five months, I guess.) That was one of the earlier subjects I'd thought of, when I was trying to keep the number of them relatively small. Since there are about two dozen now, it's probably okay to split to .UnicodePolitics and .UnicodeReligion, though if anyone prefers the combined group with .UnicodePoliticsreligion for a class name I guess I don't object. The other should just be changed to .UnicodeUi. In any event, Mediawiki:Common.css will need an update. ⇔ ChristTrekker 17:22, 23 May 2013 (UTC)

1. Your standard suggestion is good.

2. My {{ucfirst:{{lc:{{{subject}}}}}}} says that the code is double up. Twice the same. As I said; it does lc and uc again and again.

3. No reason for this to split up PoliticsReligion. Just manage the capitals.

4. My UnicodeUI, UnicodePoliticsReligion examples say you won't get an uppercase UI from that {{lc:}} thing. Ever. So your UnicodeUI class won't get hit ever. Try entering: subject=UI

-DePiep (talk) 19:46, 23 May 2013 (UTC)

Ahum: somehow input CHEM produces CHEM. What is this? I do not ever wonna have to do with this. -DePiep (talk) 20:28, 23 May 2013 (UTC)

Right—as it stands, the "UnicodePoliticsReligion" and "UnicodeUI" classes never get used. I goofed. I don't understand what you mean about it doing "lc and uc again and again" though.

The code I supplied was designed to give an initial capital, so that "UnicodeSubject" was an easily-readable class name. At this point, there are several options to fix this.

My earlier suggestion, rename the classes, splitting PoliticsReligion into two and fixing UI. Just a css change.
Similar, rename the classes, but not splitting PoliticsReligion. One class name not very readable. Just a css change.
Just remove the "ucfirst" bit. Class names would be like .Unicodeemoticon. Not very readable. Changes template and css.
Remove the "ucfirst" bit and reformat to something like .Unicode_emoticon. More readable. Changes template and css.
Remove the "ucfirst" and "lc" both. Requires editors to use exactly the right param value, but we could keep unusually-capitalized names like "UnicodePoliticsReligion". Just a template change.

Your thoughts? I think User:MSGJ would make one or both edits for us, so I don't know if being concerned about having to touch two pages rather than one is even relevant. ⇔ ChristTrekker 21:53, 23 May 2013 (UTC)

Oops: I found out. {{ucfirst:cheM}} → CheM (not Chem as intended). So your nesting is to the point: set all to lc first.

Propose: all to lc for simplicity (and if I get it well, not an uncommon class-naming habit).
Add hyphen for readability: class name would be Unicode-animal
Could we make it to be: class="Unicode Unicode-animal" (or class="Unicode-animal Unicode"). That would give the basic Unicode class as a fall-back. Otherwise, that class is not invoked at all when a subject is entered (maybe even misspelled). The sequqnce may say something about the priority.
Yes, do split PoliticsReligion. No problem when they have the same font-family set. Should we add "Culture" too?

-DePiep (talk) 09:34, 24 May 2013 (UTC)

The order of the classes says nothing about the priority. I think it is more stylistically common to write the “superclass” (i.e. Unicode) before the “subclass” (e.g. Unicode-ui). Gorobay (talk) 13:17, 24 May 2013 (UTC)

Both classes affect the same thing (font-family), the styled elements would have the same specificity, and the classes are not meant to be used in conjunction (i.e. the style rule isn't .Unicode.Animal { /* style info */ }) to get higher specificity, so I think which gets applied would depend on the last definition read in the CSS, not the style attribute by the browser. ⇔ ChristTrekker 16:06, 24 May 2013 (UTC)

Ok then: in this the proposal is class="Unicode Unicode-animal". -DePiep (talk) 18:39, 24 May 2013 (UTC)

It's not necessary to use both—the .UnicodeSubject classes already contain the same fonts as .Unicode does as last resorts. Which characters would you suggest putting in a "Culture" group? Are you thinking Cultural, political, and religious symbols in Unicode without the ones already listed in Politics or Religion? ⇔ ChristTrekker 16:10, 24 May 2013 (UTC)

They may have the same font-family today, but your solution implies a maintenance task ("make sure font-families are copied"). So I suggest to keep the two-class option. -DePiep (talk) 18:39, 24 May 2013 (UTC)

Which characters in the culture group?: I/we do not put them in there, the article editor does, most likely! My point is, that when an editor wants to use that class (|subject=), he/she would be better helped with that subject name. Political/religious subject might not cover all. (simply said: "politics" and "religion" does not cover all the intended characters). -DePiep (talk) 18:51, 24 May 2013 (UTC)

But we—speaking as the template maintainers—need to decide which fonts to apply to which classes. We do that by surveying the coverage of fonts over the characters in each group. So we need to know which characters "culture" nominally covers so that we can suggest the right fonts. ⇔ ChristTrekker 13:25, 28 May 2013 (UTC)

I thought this way: cultural, political and religious characters all get the same font-families, covering all of them. The class names are split up to give more intuitive class-options. The editor does not have to know or decide whether a symbol is "political" or "cultural" - both will work out fine. But hey, this single issue can be dropped without much harm. -DePiep (talk) 14:09, 28 May 2013 (UTC)

Subject example table

I've added a table that should show the examples in three options. I must say that my browsers (Firefox, Safari) on top of WinXP do not show a difference between any of these three. -DePiep (talk) 14:18, 30 May 2013 (UTC)

Most probably becuase you don't have any of the needed fonts installed. I already wasn't a fan, but this proves my point. This is quite a pointless addition. — Edokter (talk) — 18:29, 30 May 2013 (UTC)

No it does not disprove anything (only two specific sitiations, right?). The "maybe" does not solve anything. My point was and is: I, DePiep, do not have done the full testing. Jee, IE was not even involved. -DePiep (talk) 22:53, 30 May 2013 (UTC)

I see significant differences. Anyone who cares about glyphs of this sort will likely have a supplemental font installed. This template helps those users. I would be interested to hear from a Mac user, as Apple's emoji font is likely the most mainstream of those listed here. ⇔ ChristTrekker 19:16, 3 June 2013 (UTC)

I think that is a pretty bold assumption. I believe those user constitute less then 0.1% of our readers. I hove done some testing on my own, on XP and all major browsers. With XP's default fonts, the difference is zero; I see all squares. I also have a gazillion other fonts installed, including FreeSans and the like, so that says something. The fact is that XP's default fonts are simply outdated. I then updated the basic fonts to those from Windows 8. Low and behold... all tables showed the correct glyphs! Not suprisingly, as those fonts are twice in size. The moral is, your OS will hunt for the correct font and use the appropriate glyph when available. Otherwise, you're just out of luck. So this template adds nothing in functionality. That is the reason I cleared out the multitude of fonts for .Unicode a year ago, as they simply did not do what was expected of them. I am inclined to do the same here; the massive extra load of CSS in Common.css, loaded by all users, does not justify the few users that might have the proper font. — Edokter (talk) — 19:38, 3 June 2013 (UTC)

re Edokter: thanks, I am getting the essense of CSS better again.

re ChristTrekker: maybe you saw the improvements/differences on your own computer: which probably has all the fonts. That is not a full test I say.

Also, ChristTrekker, you wrote someone will likely have a supplemental font installed. That says it: that is not the way WP works.

I must add, CT: I admire you tough working in this, I hope it can add to WP in other ways. -DePiep (talk) 19:56, 3 June 2013 (UTC)

DePiep, yes, I do have some of the fonts installed. I have not done testing in the sense of "does the average user perceive an improvement", though. It really depends on how good the UA's font-subst algorithm is, and the fonts the user has installed. Speaking from a technical standpoint, there's no reason (that I know of) we couldn't use webfonts, then it wouldn't matter if it is installed locally or not. ⇔ ChristTrekker 22:07, 3 June 2013 (UTC)

re CT: you've lost me. I do lots of Unicode things, but I never have "installed" (or "downloaded") a font. I only just programmed the template test. I am interested in good fonts, but only as far as the WP-reader is. I won't go into the Edokter-wiseness on how "installed fonts" and classes work. -DePiep (talk) 23:15, 3 June 2013 (UTC)

Edokter, on this Win7 system, Firefox's font matching does not find suitable glyphs for all the characters on its own, even though I know I have fonts installed that contain the glyphs. With this template applied as it is now, the display is improved. This is evidence that font-matching "gives up" before it checks all available fonts. Regarding "massive extra load", it's a one-time download of another 3870 bytes. That could be trimmed by eliminating the Arial and Lucida from the end of each stack, as they are essentially worthless in this context. ⇔ ChristTrekker 22:07, 3 June 2013 (UTC)

3.8 KB is a lot in terms of CSS, cached or not. Considering the share of raeders that would benefit from it, it is wasted bandwidth. There is also a lot of duplication, so maybe one fontstack for all may be better suited. — Edokter (talk) — 22:42, 3 June 2013 (UTC)

I am intent to remove the huge fontstack from Common.css. I am appealing to all to present some test cases on a per-platform basis that proves this code is needed. The ammount of CSS is not in any way justified for the intended effect. At least, it should be reduced to one line (.UnicodeSymbol) stating only the most common fonts available. — Edokter (talk) — 21:43, 22 June 2013 (UTC)

The problem is that all the common fonts have horrible support for these characters. (The only ones that are included in a default OS install are Apple Color Emoji and Segoe UI Symbol, and they are helpful in only a handful of the character categories here. FreeSerif and FreeSans come in the Linux distro I checked, but they are highly variable.) That's the whole point of extending this template to use additional CSS classes that specify alternate fonts—fonts that have good support for those characters. Simply removing the fallbacks ”"Arial Unicode MS", "Lucida Sans Unicode"“ from each stack would save quite a bit of bandwidth, and have virtually no negative impact. If you're determined to make a drastic slash based only on "standard fonts", my recommendation would be

.UnicodeAnimal, .UnicodeAstro, .UnicodeChem, .UnicodeCommunication, .UnicodeDentistry, .UnicodeEducation, .UnicodeEmoticon, .UnicodeEnclosed, .UnicodeEvent, .UnicodeFood, .UnicodeGame, .UnicodeMap, .UnicodeMedicine, .UnicodeMoney, .UnicodeMusic, .UnicodePerson ,.UnicodePicto, .UnicodePlant, .UnicodePolitics, .UnicodeRegion, .UnicodeReligion, .UnicodeSport, .UnicodeTechnology, .UnicodeTime, .UnicodeUi, .UnicodeWarning, .UnicodeWeather { font-family:'Apple Color Emoji', FreeSerif, 'Segoe UI Symbol'; }

That would allow the template to continue to be used as extended, and logged-in users could put the current stacks in their personal CSS to get the full effect. ⇔ ChristTrekker 22:07, 25 July 2013 (UTC)

I conclude as Edokter does, finally. I see no demonstration of this usage per platform. -DePiep (talk) 23:59, 25 July 2013 (UTC)

Removed

The font stacks have been removed and the template reverted. Usage was virtually nil, and did not justify the bloat in Common.css. If this is to have a future, its implementation needs a drastic overhaul... if there is a need to begin with. While unicode seems a good platform for symbols, this implementation was no better then using Webdings. — Edokter (talk) — 09:59, 27 July 2013 (UTC)

Well of course usage was virtually nil. It was still practically a brand-new feature. The only way to "implement this properly" is to let time pass until more fonts contain the characters, so that we don't really have to do anything. Which may take a decade or two. 😛 But for the record, you are incorrect in your analogy to Webdings. The two problems are completely different things. I still disagree that a one-time bandwidth usage isn't worth the benefit, but I guess that's not my decision. ⇔ ChristTrekker 17:40, 29 July 2013 (UTC)

Is this template still necessary?

The template page indicates that it is only for Windows XP; since XP will be unsupported soon, shouldn’t we remove it? We have no excuse for supporting a defunct operating system after its deadline. ï¿½ (talk) 19:54, 21 March 2014 (UTC)

XP will not simply cease to function after April 8. Its install base is still significant, along with IE8 and all browsers that are still being released for XP. Let's give it some time. — Edokter (talk) — 22:25, 21 March 2014 (UTC)

@Edokter: Do you think this is still useful now we're in 2016? This was only for IE6, right? —Ruud 22:28, 25 February 2016 (UTC)

@Ruud Koot: Maybe a WP:TFD request to test the waters?Jo-Jo Eumerus (talk, contributions) 22:39, 25 February 2016 (UTC)

I'd trust Erwin's judgement on this a little more than the average voter at TFD ;) —Ruud 22:45, 25 February 2016 (UTC)

MS ended support for XP over a year ago, so the template has little use, other then assigning the Unicode class, which is handy for those wanting to use their own Unicode font. But I think the font assignment (in Common.js) has outlived its usfullnes. -- [[User:Edokter]] {{talk}} 17:10, 26 February 2016 (UTC)

If nearly all browsers do proper fallback substitution then this template is just adding a lot of unnecessary clutter to 60 000 articles. And as this template isn't even used consistently anymore more nowadays (people don't notice anything going wrong if they don't use it) then the "someone might want to use a different font for Unicode characters" scenario seems a little far-fetched as well. So should we just replace this template with {{{1}}} and have a bot substitute it? —Ruud 21:40, 26 February 2016 (UTC)

I think a TfD is is in order proposing this approach. -- [[User:Edokter]] {{talk}} 10:04, 27 February 2016 (UTC)

@Jo-Jo Eumerus and Edokter: I've nominated this for deletion at Wikipedia:Templates for discussion/Log/2016 March 16. —Ruud 21:08, 16 March 2016 (UTC)

Template-protected edit request on 24 March 2016

This edit request to Template:Unicode has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please undo the recent edit removing all functionality of this template ([3]), as there is not yet a consensus to turn this into a pass-through and substitute. See the ongoing TfD. That would need to be closed as consensus to delete before this edit would be appropriate. ~ Rob^Talk 17:14, 24 March 2016 (UTC)

Was it not this change that removed the functionality and you want reverted? Bazj (talk) 17:29, 24 March 2016 (UTC)

Done Bazj (talk) 17:35, 24 March 2016 (UTC)

@Bazj: You appear to have linked the same thing I did? Either way, looks good now. Thanks! ~ Rob^Talk 17:47, 24 March 2016 (UTC)

BU Rob13, You're right. I was looking at the diff in the popup where they appear different. Follow the link through and they're the same. Bizarre! Bazj (talk) 14:20, 26 March 2016 (UTC)

Template-protected edit request on 11 April 2016