Wikipedia talk:Naming conventions (Norse mythology)

Moving "addendum" proposal to talk page for discussion prior to implementation

Proposed by Haukurth:

Addendum - Common Names

After this convention had been written and put to a vote it was pointed out that it was based very heavily on the Use English guideline and seemed to ignore the equally important Common Names guideline. This section is a small attempt to remedy this.

The part of the Common Names guideline most relevant to this guideline is this:

Many wikipedia naming conventions guidelines contain implicit or explicit exceptions to the "common names" principle. Some of these exceptions are due to technical limitations, for example "C Plus Plus" while "C++" is technically not possible as a page name.

This is quite true for this guideline. In particular the recommendation to use 'ö' instead of 'ǫ' is based on technical considerations. The guideline continues:

Other guidelines try to give recommendations for enhanced precision, cleaner disambiguation and/or solution of naming conflicts, which might lead to article names that are rather "the most obvious" than strictly spoken "the most used", for example Laurent-Désiré Kabila and not Laurent-Desire Kabila (which is more used on the Internet).

These are important points for the present guideline. In particular:

Enhanced precision is achieved by using diacritics when appropriate.
Cleaner disambiguation is sometimes achieved for the same reason. For example by using Máni rather than Mani (god).
The guideline does not recommend frequency searches on the Internet as a guide for choosing names.

Well, this is a deformation of an interpretation of the common names principle: it would be fairer to say, that you don't care about it, in other words: that this guideline is a plain exception - without trying to elaborate a quirky justification. It's not the only guideline that steered for exception in this sense "successfully" - wikipedia:Naming conventions (names and titles) does the same, and it is a known fact that I think that one of the worst wikipedia guidelines. At least the proponents of that guideline don't indulge in lame excuses.

In detail:

The use of diacritics is in no way a contribution to the principles laid down in wikipedia:Naming conventions (precision) - for Nidhogg you listed 4 or 5 variants using diacritics, none of them being more "precise" than another, or even more precise than "Nidhogg" or "Nydhogg" or "Nydhogg^r". There's no ambiguity it's all about the same dragon.
"Mani (god)" is perfect for disambiguation, that's why it is used at the Mani disambiguation page. I'm not even sure there's none of the other Mani's mentioned on that disambig page wouldn't be with an accent on the a in its native language. "Mani (god)" is perfectly unambiguous.
The "common names" guideline links to Wikipedia:Naming conflict, that other guideline that's constantly forgotten by those who wish to forget about the "common names" principle (that really goes hand in hand). The "Naming conflict" guideline effectively treats frequency searches on the internet.

--Francis Schonken 17:14, 15 December 2005 (UTC)[reply]

You are already on record as firmly opposing this convention, Francis. The part I added is entirely in keeping with the rest of the guideline and doesn't add anything which I think would have changed anyone's mind in the vote. I don't feel it's quite appropriate that you should remove it. You might as well remove some other part of the guideline - you don't like any of it. - Haukur 17:18, 15 December 2005 (UTC)[reply]

As for your material points:

It is, in my opinion, more accurate and more precise to use diacritics than to omit them. Many people feel the same way even though you don't.
Mani (god) is a bad location for the page since Máni is never referred to as a god in the primary sources. We could have Mani (Norse mythology) but that's annoyingly cumbersome. It's much cleaner to use Máni. If other Mánis turn up then we will, indeed, be back to using some disambiguation within parenthesis but that doesn't detract from the general point.
You've now introduced two more guidelines ("Precision" and "Naming conflict") which you want me to pay attention to. I'll try but the time I can spend on our forest of naming convention guidelines is limited. I'm currently, as you know, trying to do something for "Common Names". I see the "Precision" one is very incomplete and needs a lot of work. - Haukur 17:25, 15 December 2005 (UTC)[reply]

As for "lame excuses" I'm making no secret of the fact that this naming convention does not use "most common in popular sources" or "most common in Google searches" as its highest principle. The only reason I added the quotes from the Exceptions section of the Common Names naming convention was that you wanted me to take that convention into account. That convention explicitly stipulates that more specific conventions may form exceptions to it and suggests a few reasons why. I felt that this was exactly the case here so I quoted that part. Including this paragraph is not a big deal for me and I'm not going to fight over it. I'm reasonably happy with the convention as it is.

Far from being the outlandish extremist you paint me as I'm in the position of trying to reign in those who want to see Old Norse forms everywhere and Anglicized forms nowhere. On numerous occasions I have changed "Þórr" to "Thor" and just today I've been re-adding Anglicizations which had been removed or characterized as "misspellings". [1] [2] - Haukur 19:10, 15 December 2005 (UTC)[reply]

Althought you are outlandish (Iceland is far away from anywhere English speaking), I do not think you are an extremist. In this case I support Francis, I do not think guideline need this extra section. --Philip Baird Shearer 22:13, 5 January 2006 (UTC)[reply]

Thank you. I, too, am fine with the guideline as it is. One thing I find outlandish about living in London is how warm and bright the winter is. I've never seen green grass during winter before. - Haukur 22:43, 5 January 2006 (UTC)[reply]

Mediate?

This debate about whether to use ligatures in article titles is the best example of a long-running unresolved debate I've seen anywhere on Wikipedia. Why don't you take it to mediation? --James S. 09:51, 17 January 2006 (UTC)[reply]

Dispute notice

Apart from previous discussions above (and in the archives), see User talk:Haukurth#What changed --Francis Schonken 22:00, 10 June 2006 (UTC)[reply]

It is well documented that Francis doesn't like this convention. Still the strawpoll showed considerable support for it but also that not everyone likes it. It therefore falls into the category of convention. It is no less or more disputed than before so I am removing the new tag. Stefán Ingi 23:48, 10 June 2006 (UTC)[reply]

more disputes

may I direct someone's attention to Talk:Ragnarök where the rant-first-ask-questions-later-(if-at-all) du jour is going on? I am tired of these aggressive article-by-article style warriors. dab (ᛏ) 19:08, 24 July 2006 (UTC)[reply]

Making an informative summary

I suggest that the lead section here (and the paragraph at Wikipedia:Naming conventions) be replaced with the following, which summarizes this article and gives useful information by itself rather than requiring the reader to read the article:

When one particular Anglicized form for a name is overwhelmingly most common and well known to the average English speaking person, it is used for the article title, e.g. Odin, Thor. When no particular Anglicized form can be said to be in common use in everyday English and English speaking scholars use the standardized Old Norse spelling, use the standardized Old Norse spelling except replace the o-ogonek character (ǫ) with the character 'ö'. We should endeavour to supply every variant of Anglicized spelling somewhere within the article, in the first paragraph when that is practical.

--Coppertwig (talk) 19:47, 8 March 2008 (UTC)[reply]

Revisiting o-ogonek

Arising from a discussion on my talk page, I propose we do away with the exception in our use of standardized Old Norse spelling for all but those articles (Thor, Odin, Valhalla, valkyrie) where anglicizations are overwhelmingly more common - and use the o-ogonek (ǫ) as well as the other alt. chars. Computer technology has now caught up with book publishing and the character is well supported, so it is no longer true that scholarly publications in English often replace it with ö, and we should in my view follow suit. There are two ways to proceed in the case of articles whose names are spelled with this character in standard Old Norse orthography, such as Jǫrð or Sonargǫltr: either use it in the text but leave the article title at the ö spelling or also move the articles to the ǫ spelling. If the articles are moved, redirects would of course need to be provided from both ö spellings and non-diacritic spellings, and I think it would be useful to add an explanatory note or a header template to all such articles explaining the character. I am not sure the gain in accuracy warrants moving the articles, since the character is untypeable; if there is an alt + code for it on the Windows keyboard, for example, I am unaware of it. But that is of course what redirects are for. I do think we should be using it in article text, for reasons of accuracy and to a small extent because explaining what it is in context is part of our encyclopedic mission. (I wish the texts in which I first saw it as a child had explained what it was and how it is pronounced.) It was excluded from this policy for purely technical reasons that appear to no longer be valid. Yngvadottir (talk) 16:28, 15 March 2014 (UTC)[reply]

ǫ: The character can be inserted into text with the Latin character set box. There is one minor technical issue, which is that it isn't completely respected by search. For example, if you type "Tłı̨ch" into the search bar, you get Tłı̨cho as a partial result, while "Tłı̨chǫ" fails to match. It still comes up in the search bar because it also shows any diacriticless match - so "Tłı̨chó" also appears. This is not a constraint, really, and should not determine our decision. Further, it's clear using "ǫ" would in no way hinder navigation. However, ö should be retained in names like Ragnarök for which the original pronunciation is not known. I think users can be driven by their own curiosity to an explanation of the character. ᛭ LokiClock (talk) 02:34, 17 March 2014 (UTC)[reply]

Support total conversion of ö > ON ǫ, including article names. Per our earlier discussion on Yngvadottir's talk page. I've tried to make all potential redirects in the articles I've written or rewritten, and this seems to be the case with most of the articles. I also support a template; maybe something that says something like "This article may employ unfamiliar characters such as the o-ogonek (ǫ), eth (ð), or thorn (þ). For more information regarding characters and their use in Old Norse, please see Wikipedia:Naming conventions (Norse mythology)". While we're at it, perhaps Wikipedia:Naming conventions (Norse mythology) should be moved to Wikipedia:Old Norse and should handle Old Norse orthography in general. We also need to introduced a section on the o-ogonek here. :bloodofox: (talk) 03:46, 17 March 2014 (UTC)[reply]

Damn Google Devs, Thou Hast Betrayed Our Trust. I am forced to report with a heavy heart that Android 2.x as well as the latest Android 4.x devices, using the default browser from Google, fail to display o-ogonek. These are dominant in smartphones and tablets, and by my rough calculations there are ~10 million of our readership that use Android 2.x devices, plus ~50 million that use Android 4.x devices, and growing quickly (they are cheaper than Apple iStuff). This new problem is on top of the problem we already knew about, which was ~20 million people still stuck with IE6/IE55/PocketIE4/Firefox3/Netscape4/similar on ancient hardware. Those old devices will rapidly dwindle during 2014... but the Android 4.x devices will rapidly grow during 2014. Bloodofox, Yngvadottir, LokiClock, we cannot use o-ogonek yet, sorry.

p.s. I wish I had known this earlier, but only found the hint that Android might suck this morning, and tested a couple of devices. Linux, which is the "father" of Android, supports o-ogonek just fine... and in fact, Android with a third-party browser like Firefox installed (to replace the default Google Chrome browser) shows the o-ogonek just fine... so I literally had zero worries about Android supporting o-ogonek, and concentrated on the older stuff. Sigh. There is one bright spot in all my bad news; Chrome (and also Android for that matter) are forcibly auto-updated from the Google mothership. If at some point in the future, Google *were* to decide to support o-ogonek in their mobile version of Chrome, this new feature would be available in all 60+million devices overnight. We already know that o-ogonek support is technologically possible, since Firefox-on-Android does it just fine. Thus, although o-ogonek for wikipedia articles is deferred, there is hope that Google will see the light, and when they do, we can switch over to using o-ogonek the same week google deploys the feature. (Assuming that iPhones don't also fail to support o-ogonek... guess we better check.) Anyhoo, sincere apologies for getting people's hopes up. I will keep investigating, but doubt there is a way out here. 74.192.84.101 (talk) 18:04, 17 March 2014 (UTC)[reply]

iPhones display ǫ as of the 3G at latest. Perhaps someone could file a support ticket with Android and this can be resolved? ᛭ LokiClock (talk) 22:32, 17 March 2014 (UTC)[reply]

I have some problems with taking this approach further. When the problem is users with outdated software, we don't know if it's even possible for the user to upgrade. Android delivers updates automatically, it's clear how to update, and compatibility with the device can be insured by the coders. With the older browsers the technical problem became apparent after the technology had been adopted. This is not the case for Android. A new browser can come around all the time with incomplete support. There is no expiry date on the inaccuracy of the encyclopedia if the goal is to be beholden to lazy product developers until the Android too becomes old technology and vanishes, and the next browser that fails to support ǫ after that. Unlike these older browsers, the Android browser is still actively supported, and it's within their means to fix this issue and for users to acquire this fix. For new technology, a lack of support may indicate a feeling of a lack of obligation, which is vindicated by a lack of unsupported content. What's considered unsupported is not what could potentially be realized with the software if it weren't for a barrier, but what breaks that people are going to do no matter what. Changing Old Norse articles wouldn't be responsible for creating a failure of support articles, as this lack of support already exists because of languages that are without ogonek-less alternatives in a faithful orthography. ᛭ LokiClock (talk) 23:09, 17 March 2014 (UTC)[reply]

LokiClock, I understand your point, that we could be in a catch-22 sort of situation. If browser-vendors today believe they can ignore o-ogonek, because no webpages require them to display o-ogonek, then browser-vendors of the future may also continue to ignore o-ogonek.

However, my understanding is that the ONLY modern platform which fails to support o-ogonek is the Chrome-variant for Android, which relies on the basic Roboto or Droid (font) package. As soon as either 1) google upgrades the font-packages via auto-download to all 70+million android-devices with Latin Extended B support, or alternatively/additionally 2) the w3c support for WOFF and other downloadable-on-the-fly-from-the-webserver font technologies are fully supported, we can start using o-ogonek the next day.

That might be six months, or it might be longer, but it won't be forever. Maybe we can help speed that up, on our end, or by joggling Google's elbow somehow. What I don't understand, is what you are suggesting we do, either as wikipedians, or as just general internet-citizens-slash-humans. Can you give me a bit clearer of a picture, what you are suggesting, please? 74.192.84.101 (talk) 03:21, 18 March 2014 (UTC)[reply]

The comments on Narayanan's answer to this android.stackexchange question suggest Android has a specific fallback typeface which can be replaced to extend Unicode support. Do you have an Android device, and could you test and see if this works with, say, Deja Vu Sans?

As Wikipedians, we have an obligation to accurately represent academic subjects in their current form. This has a negotiated precedence over the obligation to be accessible to the bulk of readership. The previous decision is not necessarily still justified, and I think more negotiation is needed before we resolve not to change to ǫ. If you're asking whether as internet citizens we should be cutting off an existing user base from this aspect of accessibility, I'm saying since there's no way we can expect to attain accessibility, accuracy and obligation can't be negotiated here, so accuracy's precedence should be applied strictly.

It could, in fact, be forever before the problem's solved, not just an indeterminate amount of time. We clearly are in such a catch-22 situation, as what is the present was once that potential future. The problem has a simple, well-known solution, which is to base a closed operational typeface on Deja Vu Sans and remove the Bitstream components, or otherwise use a dense Unicode typeface. This is not done because that would be not invented here. Since this is a corporate policy issue, not a software development issue, we can expect this problem to be recurrent. There is no stated goal of complete Unicode coverage, only an apparent effort to (slowly) attain broad multilingual support, so we can assume that Unicode blocks consisting mainly of linguistic, mathematical, or other academic characters are not in the projected coverage, and that there will be no personnel assigned to achieve the necessary coverage. This is the usual history of such projects which do not include full a dense Unicode glyph set at the outset - ignoring the problem of multilingual support and proper rendering.

The original motivation for accommodating the problem involved the fact that the browsers being used had outdated browser rendering engine design or other barriers to the development of a solution. If you're suggesting our general policy is to not make a change to the manual of style if the most widely used software doesn't support it, then since in this case the problem does not have any intrinsic terminating point, we must set an arbitrary point at which we will no longer accommodate it. I suggest that point is now, and that the original motivation for accommodation has completely expired, while others may wish to place it after Chrome for Android falls into disuse. On the other hand, if WebFont support is expected soon, and this page suggests that it's already due in 4.4 in I'm guessing the same portion that it's supported by Chrome, I would say that's a reasonable terminating condition as well, even on condition of a significant percentage of users coming to use this version. ᛭ LokiClock (talk) 04:18, 19 March 2014 (UTC)[reply]

This page suggests support has been around since Chrome for Android 18. If that's true, maybe we need to be nudging the Wikipedians who do the web font business, rather than Google. We could still nudge Google about making this work compatible with Android 2.0 users. ᛭ LokiClock (talk) 04:33, 19 March 2014 (UTC)[reply]

Briefly, 'we cannot rely on DroidFallback.ttf, because 1) the user may already need a custom version of that file to support Tamil rendering or other localization needs... and wikipedia would have to overwrite their settings... thus screwing up their device, and 2) besides, it seems to require a rooted/jailbroken phone, which most users won't do.

On the philosophical point of accuracy versus accessibility, it is not black-and-white. Wikipedia has trouble with accuracy in general, and using accurate fonts I would suggest is the least of our problems. :-) Philosophically, though, in the case of o-ogonek (and "newer" characters like Wynn or "really new" characters like Indian Rupee Sign U+20B9) the question is a tradeoff. Do we have an alternative to the 20B9 symbol? Sure, the 20A8 symbol, which has been around "forever" and works just fine. Except in the article about the character, we should continue using the old symbol, despite the anachronism, because in this case accuracy isn't impacted (the *meaning* is effectively the same ... cf "housecat" versus generic "feline"), and thus accessibility can come to the fore. Case by case, is my position, in other words.

What is the case-by-case situation for the o-ogonek, then? Your comment that "there is no way we can expect to attain accessibility" is not quite correct. There are two ways: first, we (meaning a delegation of wikipedians led by Jimbo for instance) could pull some 'political' strings, and get google to send an autoupdate to all android devices, adding support for various special characters that the goog "forgot" to support in the default Android browser. (Technical note: on the http://lucasfonts.com/webfonts page the "Android Browser" near the bottom is the one that matters... "Chrome for Android" is something different! Firefox for Android is also something different, and it already supports o-ogonek.) As you point out, the original decision to avoid o-ogonek was because of IE6 and other old rendering-engines; that issues was severe a few years ago, but is now below 5% of the readership. Thus, our current problem is Android Browser... and in theory, Google *could* fix it, any time they wished. Before we went grovelling to the WP:GOOG, though it would be smart of us to get a wider idea of 'missing' glyphs that would improve wikipedia (Wynn/etc). That way, we only have to grovel once, and we also bring in additional voices on our side, not just those concerned with Old Norse and the o-ogonek.

The *second* way that we might achieve accessibility && accuracy does not require any special effort on the part of third-party vendors of software and/or hardware, and that is for wikipedia to start using webfonts. Unfortunately, there are a bunch of competing standards. Microsoft made the first, EOT, all the way back with IE4, but firefox/apple/etc refused to use that, and instead tried to force WOFF as the W3C standard (which went poorly). Android refused to support either, but *does* support pure TTF/OTF files as webfonts. Working around the different standards, for CSS2/CSS3 and EOT/WOFF/TTF and such, is theoretically possible. See this 2009 post which explains some early tricks; note that it is only for desktops (neither android nor iOS are mentioned), but it does give the basic idea. Theoretically, if the WMF devs were to start supporting font-face on pages where it is needed, we could have any unicode character we wanted on over 99% of browsers. In other words, this option#2 would give us almost perfect accessibility (~99% rather than ~95% with option#1), and it would be for *all* unicode chars we wanted to support, not just o-ogonek.

There are technical hurdles, unfortunately. As long as we were careful to 'subset' the custom-wikipedia-font, aka just include a handful of unsupported-in-the-wild characters like o-ogonek, and after that, have the browser fall back to a pre-installed set of glyphs, the download-size would be minimal, even across pokey mobile-internet connections. The difficulty here is that the "font-face" magic is NOT well-supported. For instance, in the http://lucasfonts.com/webfonts page, they are forcing my browser to use TheSansOfficeLF5 fontface in my browser's choice of WOFF/EOT/SVG format... and the rendering is screwed up! The word "typeface" for instance, has the righthand edge of the letter "p" completely cut off, making it look like an "F" which has fallen down a notch. This is almost certainly not a bug in the fontfile in question... it is a bug in my browser-version && OS-version, and the way it handles WOFF (or maybe SVG). So the bottom line is, "font-face" magic is the long-term solution... and we can implement it ourselves, this year if we wished... but it is an esoteric feature, not well-tested in the majority of browsers, so there WOULD be problems.

So my suggestion, at the moment, is that we see if we can locate somebody experienced with TTF/EOT/WOFF stuff in relation to Android's default browser, who knows how to subset a font. Then, we pick a suitable fontface from here, Open-source_Unicode_typefaces, which has a proper free as in freedom license, and supports o-ogonek out of the box, and create a miniature fontface with just the o-ogonek character. We can use some online format-converters to get TTF/EOT/WOFF/SVG versions of the minifont, and then test the font-face trick, to see what happens in various browser/OS combos. Maybe we can try at WP:VPT to seek such a person? Or the computer-section of the refdesk. Anyways, although I don't think we should give up yet, I do think that we want to avoid using o-ogonek in body-prose and article-titles, until we have figured out whether we can make option#1 (coerce google into DTRT) or possibly option#2 (make our own wikipedia-webfont) actually happen, and what the hidden pitfalls might be. I don't think the problem will take forever to be solved... but I don't expect it to happen by itself, unfortunately. Hope this helps. 74.192.84.101 (talk) 15:20, 21 March 2014 (UTC)[reply]

LokiClock, it looks like option#2 is very possible. https://www.mediawiki.org/wiki/Extension:UniversalLanguageSelector#Adding_fonts 74.192.84.101 (talk) 19:26, 21 March 2014 (UTC)[reply]

[3], if anyone wants to go character shopping. Code2000 has pretty good coverage. Latin Extended-B and Latin Extended-D are the blocks of our primary interest, while Latin Extended-C has characters like Latin alpha used in written languages. ᛭ LokiClock (talk) 12:23, 22 March 2014 (UTC)[reply]

It looks as if we have to wait for Android phones to support the o-ogonek. This gripes me out, to use the vernacular. But it is becoming an increasingly frequent browser for readers to use to access Wikipedia. Yngvadottir (talk) 21:45, 18 March 2014 (UTC)[reply]

Not guaranteed to be historically accurate, but quite fitting for this situation. http://www.housebarra.com/EP/ep04/12norsecurse.html TFIW. 74.192.84.101 (talk) 15:20, 21 March 2014 (UTC)[reply]

You know, there are people in the SCA with a better grasp of Old Norse than that. That's actually an example from the earlier days of the internet - the qs should be ǫ. Yngvadottir (talk) 15:26, 21 March 2014 (UTC)[reply]

Archives