I've just noticed (by searching) that there are very many entries — probably dozens — that use the misspelling "occuring" in their definitions. Perhaps somebody has a bot that could deal with these cases? (Watch out for the actual misspelling-entry occuring though, where it should remain!) Equinox ◑ 16:27, 2 August 2009 (UTC)

What the hell is up with the page anchors lately? Whenever I edit a section, the page loads, then my browser (Safari/Mac) jumps to about 3 lines below the heading I was editing, completely losing the context. Even though it's happened dozens of times, I still sometimes randomly scroll up and down or just sit dumbly wondering what I am looking at. This is supremely fucking annoying. Does the stupid top notice have a new behaviour again? —Michael Z. 2009-08-04 17:31 z

Could it relate to MediaWiki:Common.js?diff=6887404, discussed at #Problems with section-linking when using {{temp}}? —Ruakh_TALK 18:42, 4 August 2009 (UTC)

I don't know what that is, but I removed all instances of {temp} in headings on this page, the problem hasn't gone away on this page. If I turn off Javascript, the brokenness goes away.

Who here has control over the sitenotice? —Michael Z. 2009-08-08 03:56 z

Hm, looks like the problem probably isn't in MediaWiki:Sitenotice, but in the three javascripts which are wrapped around it. Really, some basic functionality is broken here and constantly reminding me that someone is messing with our site without sufficient testing, and without being present here. How do we remove their crap until they get it right? —Michael Z. 2009-08-08 04:17 z

I've identified the behaviour better, by loading short pages and jumping to anchors right at the top of pages. It's easier to see when my machine is slowed with a busy CPU (but just as intolerable when its not).

The Wikimedia vote notice and our site notice both show up at the top of every page load, complete with "dismiss" buttons (even though I dismissed both a long time ago). Then the page loads (which can take several seconds on these talk pages), then my browser window jumps to an anchor, and only then the site notices disappear, making the body content shorter by about 75px. So after I jump to a heading, the page contents jump up by about 75 px. Sometimes there is a noticeable flash of heading, and other times it appears to take zero time, appearing as if the anchor jump was going to a random part of the page.

I'd rather look at the advertising than have the page jump in my face every time I do an edit. How do I un-dismiss the site notices?? Please. —Michael Z. 2009-08-08 16:21 z

I use in .css: #siteNotice { display:none; } and I don't see js doing anything (dismissed or not). Mind you I think it might still be jumpy but I haven't noticed anything that was enough to bother me. Might work for you.Robert Ullmann 16:36, 8 August 2009 (UTC)

I'll try that. But that would just hide the problem from me.

Now how do we go about eliminating the brokenness? I can try deleting MediaWiki:Sitenotice, but I can't locate where the global notice text comes from. —Michael Z. 2009-08-09 01:34 z

Hi everyone, I am looking for the template which one uses when you are wanting to make a big change to a page and don't want to get into an edit conflict. Could someone please tell me what this is. Thank you :) L☺g☺maniac chat? 15:03, 5 August 2009 (UTC)

{{inuse}}.​—msh210℠ 17:55, 5 August 2009 (UTC)

Thanks! :D L☺g☺maniac chat? 18:25, 5 August 2009 (UTC)

I've created {{BCSM}} that could be hopefully used as a substitute for L2 Serbo-Croatian. Should have done this long time ago. Anyhow, some of the question for tech-savvy folks:

• Would it pose a problem to have L2 language name as a template, for the bots and stuff? I imagine that the possible fixes would be pretty much trivial..
• Would it be hard to add the customization support? E.g. by default it would list "BCS" or "Bosnian, Croatian, Serbian" or whatever we decide it would list, but by customizing monobook or WT:PREFS option it could display e.g. Serbo-Croatian? :D I assume that this might introduce inconsistency in the alphabethic ordering for the folks who do so, but that is not a big deal anyway..
• Serbo-Croatian as a macrolanguage has a reserved code {{hbs}} we might use instead if necessary. Would it be a problem with section-linking (lang=) and stuff if {{BCSM}} were used? If necessary, we could agree on using the L2 ===BCSM=== only via {{BCSM}}, and linking to actual sections via {{hbs}}. --Ivan Štambuk 23:19, 6 August 2009 (UTC)

I don't like this proposal, as it introduces an inconsistency with everywhere else on Wiktionary for no benefit I can see. I am not sure what problem it solves, and in answer to your specific points:

1. Not a huge problem, though it would be irritating, At the moment every language heading is a good enough label for that language, with Template:BCSM I'd have to add an explicit "change Template:BCSM to <something else>" if I wanted to display things to users (WT:RAND is an example of this). Alphabetic ordering would become harder, for pretty much the same reason, and if you allow its output to be customisable then people are likely to make the mistake of sorting it under the label they can see rather than the default label. The alphabetic ordering is a useful feature on pages like a with lots of languages and anywhere else (like on many categories) that we have a large list of languages.
2. Not hard, but not terribly desirable - what would be the advantage of such customization? - the people who "get offended" by whatever heading is chosen will still know that the incorrect heading is being shown to everyone else.
3. If we were to stick to using only the templates for titles and links there would be no problem, but making people stick to that is probably difficult unless they are established BCSM contributors, they won't notice or will forget that this heading is different from the other ~660 languages on Wiktionary.

Conrad.Irwin 08:14, 8 August 2009 (UTC)

Well this is a very specific case, and I think that the issues (and "issues") solved by this greatly outweigh all the potential technical and practical drawbacks. OK, let's drop the header-customization entirely.

So the only problem would be a special if-clause in the bot code to handle {BCS} when parsing the database, and people possibly forgetting that we are using a special {BCS} header.

We could also drop the template completely, and force it simply as a wikilink ] (like we do now for some obscure languages) in the L2. Now that I think about it, I like this option the best. (we can always change it later if there is a need).

So the proposal is L2 ==BCS== (always wikilinked), with {{hbs}} language code. Thoughts? --Ivan Štambuk 10:43, 9 August 2009 (UTC)

BCS, BCSM, BDSM are all confusing for an average mortal user. We need a simpler header that will not make such user's head explode, and an agnostic one at that, not implying those languages are the same (this way it can pass the vote, unlike the "Serbo-Croatian" L2). So think, Štambuk, think. --Vahagn Petrosyan 11:54, 9 August 2009 (UTC)

How about ==Bosnian/Croatian/Serbian== L2s, and BCS in the translation tables (to reduce space usage)? It's a bit cumbersome, but it looks the most neutral to me. --Ivan Štambuk 12:02, 9 August 2009 (UTC)

How would someone looking for the Serbian translation of fox know it’s under some BCS? Not gonna work. By the way, you may be interested what dbachmann thinks of the situation (at the bottom). --Vahagn Petrosyan 13:42, 9 August 2009 (UTC)

You're killing me. How about making the Bosnian/Croatian/Serbian translation as sth like " *Serbian: see BCS ? We could generate them by a bot (or javascript?) in every translation box that has a BCS translation.

Dbachmann's comment are deeply insightful, as always. I am very glad that he started editing here again! --Ivan Štambuk 14:14, 9 August 2009 (UTC)

That may work. But are you sure BCS would be acceptable for the opposing party? I mean, c'mon, If you're putting things under one header you automatically say they are the same language, be it Serbo-Croation or BCSian. You could catch one of those nationalists and experiment on him, for starters. As sad as it is, we must convince/manipulate Ullmann’s minions to agree, otherwise they can always sabotage the vote. --Vahagn Petrosyan 14:43, 9 August 2009 (UTC)

For starters, it would be one less "genocidal term" to worry about, which appears to be hopelessly politically contaminated and concordantly manipulated by some of the opposers. The proposed policy even now does not claim or discuss anywhere whether they are "the same language" or not - it is only on formatting the 3 standards at one language header (the difference is subtle, but important because that way we evade accusations for "Yugounitarism"). As for the evidence on whether the 3 standards are one language in a non-sociolinguistic sense (Mir Harven: "languages have nothing to do with linguistics"), I've collected some testimonies by professionals that will doubtless shed some affirmative light on that issue. --Ivan Štambuk 15:06, 9 August 2009 (UTC)

I'd have thought that something like "Bosnian, Croatian, Serbian" would be more palatable than "Bosnian/Croatian/Serbian"; the former implies only that all are covered in the section, whereas the latter implies that these are three names for the same thing. (An implication which, mind you, is not accurate: even if you accept that BCS are one language, that doesn't mean that "Bosnian", "Croatian", and "Serbian" are actually equivalent names for it. English is one language, but "American English" and "British English" are not synonymous.) —Ruakh_TALK 15:08, 9 August 2009 (UTC)

L2s can be "Bosnian, Croatian, Serbian" and the translations can be separate and, yes, duplicated; but all three could point to the same "Bosnian, Croatian, Serbian" header. I can imagine this being acceptable to the opposers of the current policy. --Vahagn Petrosyan 15:21, 9 August 2009 (UTC)

That would be acceptable to me too. Duplications at the translation tables are far less of a problem than the duplications in the main namespace entries, as you just edit them once. --Ivan Štambuk 15:26, 9 August 2009 (UTC)

Plus, three translations would link to three wiktionaries (sr.wikt, hr.wikt and bs.wikt), like now. Also, if we kept only Serbo-Croation, some users looking for Croatian or Bosnian may not think of looking under "S" and go away disappointed. --Vahagn Petrosyan 15:33, 9 August 2009 (UTC)

Yay, one less problem to worry about! Now we have to wait that the vote expires so that I can rewrite the draft policy. It will be a bit weird to have categories such as Category:Bosnian, Croatian, Serbian language, but what can one do.--Ivan Štambuk 15:44, 9 August 2009 (UTC)

Why does it have to be Category:Bosnian, Croatian, Serbian language? The {{hbs-noun}} or {{sh-noun}} or whatever, could put the word automatically in all three Category:Bosnian language, Category:Croatian language and Category:Serbian language. This kind of duplication will not require any effort from you whatsoever and will show that we do not merge the languages. --Vahagn Petrosyan 16:13, 9 August 2009 (UTC)

But then we'll have to add a special case for all the other automatic-categorization templates such as context labels, {proto}, {etyl}, {suffix} etc, that would sort the lang=hbs/sh to all the 3 corresponding categories. Also, there could be some "principal" problems with adding Croatian-only words/spellings to Serbian language cat, or Serbian Cyrillic spelling to Croatian cat... Unless we add a set of special parameters (e.g. "b|c|s") that will denote which of the (standard) languages the word belongs to, which should be possible but it'll be quite annoying in practice. --Ivan Štambuk 16:33, 9 August 2009 (UTC)

Anything in Burmese ("my") just appears as boxes; what font am I lacking? Mglovesfun (talk) 12:53, 14 August 2009 (UTC)

Quoth ]:

    .Mymr {
        font-family: Padauk, Myanmar3, Myanmar2, Myanmar1, ParabaikSans, MyMyanmar, sans-serif;
        font-size: 130%;
        }

—Ruakh_TALK 15:11, 14 August 2009 (UTC)

Entry Fus-ha won't appear listed in Category:Languages under letter F. I wonder why? Anatoli 11:34, 16 August 2009 (UTC)

I figured it out, no worries. Anatoli 12:01, 16 August 2009 (UTC)

cansuchTRANSLATIONSbe importedfrom wp?

Possibly, but you need to be very careful which words you try, the wikipedia interwiki is very crude and not really reliable enough to trust without another source. Conrad.Irwin 22:43, 17 August 2009 (UTC)

Exactly. For example, an interwiki link may be between a singular and a plural, or between words with slightly different meanings. This technique is safer for proper nouns such as this one, but it's not 100 % safe, especially when you don't understand the script at all. Lmaltier 21:26, 22 August 2009 (UTC)

I thought about an idea to help Wiktionary generate original research on differences in words and wondered if others have had this idea as well. Would there be a way to combine a mapping system (like m:WikiMiniAtlas) with a database (perhaps at toolserver) to produce and display word differences on a map like the one at popvssoda.com? Not only would geographic differences in synonym usage be interesting but also finding where different pronunciations or senses of a word are used. I'm sure there's more possible uses as well. If it could be designed, it would provide another way for casual users to improve the dictionary without having to edit a page. --Bequw → ¢ • τ 07:30, 17 August 2009 (UTC)

how2NOT hav"(plural , diminutive , diminutive plural s)"displayd?--史凡>voice-MSN/skypeme!RSI>typin=hard! 10:21, 17 August 2009 (UTC)

Better now?​—msh210℠ 16:39, 18 August 2009 (UTC)

• coool,ta!:)
• etyl:somuch2learn+'dbe directlyfromLatin2,no ref.books here:/
• 'dBrab. bemade i/aCATEGORY?--史凡>voice-MSN/skypeme!RSI>typin=hard! 05:00, 19 August 2009 (UTC)
  • Don't see why not. We have other dialectical categories, such as European French (a subcategory of Regional French), British English (a subcat of Regional English), and Regional Dutch, so....​—msh210℠ 19:56, 23 August 2009 (UTC)

Can you review latest edits by DerbethBot before I run it normally? --Derbeth ^talk 11:40, 23 August 2009 (UTC)

I'm attempting to create this template to be used for example quotations in Ancient Greek entries. However, I've run across a problem, which I'd like some input on. It doesn't seem to take on the level in which it is used. For example, the hollowing doesn't work:

# sense
## subsense
## {{grc-cite|stuff....}}

In this case, the template puts the quote and everything else to the left, as if there were no number signs preceding it. I was thinking that there could be a "level" parameter, which would place the number signs inside the template itself. However, this would require code like:

# sense
## subsense
{{grc-cite|stuff....|level=2}}

This does work (I've tried it), but I was wondering what folks thought about it, and if there's perhaps a better solution. Many thanks. -Atelaes λάλει ἐμοί 01:43, 26 August 2009 (UTC)

One option is to move the * out of the template and into the entry's own wikicode, and to replace the template's : wiki-markup with the corresponding HTML-style markup. With that approach, the template's source would then look something like this:

{{#if:{{{year|}}}|'''{{{year}}}''', <nowiki/>|}}
{{#if:{{{1|}}}|{{{1}}}, <nowiki/>|}}
{{#if:{{{2|}}}|''{{{2}}}'', <nowiki/>|}}
{{#if:{{{3|}}}|{{{3}}}, <nowiki/>|}}
<dl><dd>{{polytonic|{{{4}}}}}
   {{#if:{{{5|}}}|<dl><dd>{{{5}}}</dd></dl>|}}
</dd></dl>

only without all the whitespace that makes it readable. It makes the template-code rather ugly, but I think it would make the entry-code quite readable, which is probably more important (provided the template is well documented). —Ruakh_TALK 03:29, 26 August 2009 (UTC)

Your solution is basically what I ended up doing for the {{cite meta}} family, although for Citations etc. I found it was best to just pass the whole first-line indent as a parameter, e.g. {{grc-cite|level=##*}} or {{grc-cite|level=**}}, etc. I do think that the first-line indentation should also be in the straight wikitext. Unfortunately, that does result in some ugliness: ##*{{grc-cite|level=##*}}. But not doing this makes the wikitext significantly less readable for both machines and humans, IMO. -- Visviva 04:05, 26 August 2009 (UTC)

I started getting the following error message with attempted edits:

Sorry! We could not process your edit due to a loss of session data. Please try again. If it still does not work, try logging out and logging back in.

I tried logging out and then back in, but to no avail. Is this just a minor hiccup that will be corrected soon? Bendono 13:48, 26 August 2009 (UTC)

Strike that. Seems to have fixed itself now. Bendono 13:58, 26 August 2009 (UTC)

I've had that problem in the past, but usually a simple repeat of the save was sufficient. More recently I have had to log and log in. Today even that wouldn't help. I'd love to know if there is a way of reducing the likelihood of this repeating or whether it is a symptom of a problem with my set up. DCDuring TALK 14:12, 26 August 2009 (UTC)

I get it if I write an entry before logging in, then open another tab and log in there, and finally try to save my original entry. Equinox ◑ 23:51, 30 August 2009 (UTC)

I'll look out for a comparable condition the next time it occurs. Thanks. DCDuring TALK 01:05, 31 August 2009 (UTC)

At Wiktionary talk:About_Hebrew#font_size_with_vowels, two of the main Hebrew editors (there are only a few more than that) agreed on a change to template:infl that affects Hebrew entries; now we want someone else to do the work for us, please.  :-)  Specifically, the headword is in a larger font, and the inflected forms should be, too, to increase legibility. Anyone feel up to this?​—msh210℠ 18:53, 26 August 2009 (UTC)

(Specifically, each thing that looks like this:

'''{{wlink|w={{{6}}}}}'''

needs to be changed to look like this:

{{{{{sc|Xyzy}}}|{{wlink|w={{{6}}}}}|lang={{{1}}}|face=head}}

.) —Ruakh_TALK 20:12, 26 August 2009 (UTC)

O.K., I've made the changes, after some testing. Hopefully nothing explodes. —Ruakh_TALK 21:21, 27 August 2009 (UTC)

BTW, I'm pretty sure that either the job queue is broken, or Special:Statistics reports it wrong. —Ruakh_TALK 21:23, 27 August 2009 (UTC)

The job queue is run by several servers within the partition (en.wikt is in p2); the report is the queue on the server that happens to gen the page. So it isn't entirely useful. Robert Ullmann 15:11, 29 August 2009 (UTC)

This should almost certainly be face=bold, leaving it to the font template do to the right thing (bold, or a bit larger, or both). {{Hebr}} does "big" for both head and bold.

More seriously, this introduced doubled calls to Xyzy or the script template in some cases (which do exist):

{{head|ru||sc=Cyrl|link a|foo|link b|foo}}

August • (August) (link a foo, link b foo)

Wait a second, that shouldn't even work! There are two calls to Xyzy (and Cyrl) nested. They've changed the recursion rules again? (sigh). It does produce some bad results, as in the following:

{{head|he||link a|foo|link b|foo}}

August (link a foo, link b foo) (with infl "fixed", note the second link does exactly what is called for)

Which wraps the link in big tags twice. All of which explains why I've been thinking about this since setting up infl but not doing anything about it.

The best thing to do I think is leave it as is now, (except for using face=bold instead), and I'll work out a subfunction to do it "right". Robert Ullmann 13:15, 30 August 2009 (UTC)

I created {{slink}} as a subfunction (note it incorporates {wlink}—it has to—so it is more efficient, not less ;-). This does mean that some nasty tricks, like using |attribute|foo''' or '''bar| will not work (should just be |attribute|foo|or|bar anyway ;-) will get broken. Maybe I should go hunt for them?

Oh, and you get section links now. Robert Ullmann 15:01, 30 August 2009 (UTC)

I am trying produce the character formed from a y with an umlaut and an acute accent (as shown for u in ǘ), this is a transliteration of the Greek ΰ. Can anyone help please? —Saltmarsh^{απάντηση} 14:59, 29 August 2009 (UTC)

ÿ́ or ÿ́ like so? Robert Ullmann 15:06, 29 August 2009 (UTC)

thanks —Saltmarsh^{απάντηση} 06:30, 30 August 2009 (UTC)

For what kind of user is such a transliteration a help? If they are learners past having bought their first textbook, they should not need the gloss. Who would know how to use the gloss? DCDuring TALK 19:56, 29 August 2009 (UTC)

This is for the transliteration of Greek words here - I am not sure that ΰ exists in the Greek language but if it occurs in a word it should be Romanised. —Saltmarsh^{απάντηση} 06:30, 30 August 2009 (UTC)

Yes, it exists: πραΰνω (praÿ́no, “mitigate”). —Stephen 00:11, 31 August 2009 (UTC)

Just looking at the recent changes, we have three of these! Template:palæontology, Template:palaeontology and Template:paleontology. I'm assuming this is a classic redirect situation? Mglovesfun (talk) 15:58, 29 August 2009 (UTC)

Okay, done, two of them were unusued anyway, false alarm. Mglovesfun (talk) 16:02, 29 August 2009 (UTC)

Understandably, this looks weird. My rationale for bringing up this issue can be found hereat. This follows on from our general tendency to allow individual entries to diverge as much as is natural, possible and favourable. I think that this tendency is best accommodated by accommodating such policy/spelling reforms. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 01:32, 30 August 2009 (UTC)

Ok, a couple things. First of all, let me point out that none of these templates should be used in any of the entries noted. This is completely incorrect use of contags. The word "archeopteryx" (and all of its spelling variants) is used outside of the field of paleontology. Discipline contags like this are supposed to be used when a word is used in a specific and unique way only in a certain field. Ultimately, these words could perhaps be categorized as something (maybe "paleontology, but I think "birds" would be better). In any case, Doremítzwr, I think you're mistaken about our tendency to allow entries to vary as much as possible. Quite the contrary. In fact, I think it would be far more accurate to say that we generally want entries to conform to strict standards as much as possible, and grudgingly permit them to vary when they absolutely must. In any case, Mglovesfun's solution is acceptable, in that it makes the contags all display and categorize identically, but an even better solution would be to change the template calls in all the entries to be identical (that is, if the templates were appropriate to be used at all), so that even the code was conformant. -Atelaes λάλει ἐμοί 02:53, 30 August 2009 (UTC)

OK, but if we’re going to allow only one spelling, then it ought to be {{palaeontology}}. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 23:19, 30 August 2009 (UTC)

At COCA "paleontology" gets 258 hits to 3 for "palaeontology". I was unable to do a search for the ligature form since they don't include ligatures. This is a superior source to b.g.c. for current usage because the results are not distorted by current reprints of books that use rare, obsolete, and archaic spellings. Even on date-unrestricted search bgc favors paleontology over palaeontology by a 5 to 1 margin. What would the facts in support of the "ae" spelling be? DCDuring TALK 23:39, 30 August 2009 (UTC)

The British National Corpus: palaeontology, 50 vs. paleontology, 16. Obviously, COCA will yield more hits for the spelling that’s common in America, whereas BNC will yield more hits for the spelling that’s common in Britain. Besides, the etymological arguments are more important than appeals to usage frequencies IMO. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 23:49, 30 August 2009 (UTC)

Also, FWIW, the OED’s entry for “palaeo- | paleo-, comb. form” includes this parenthesis on the (deprecated template usage) paleo- and (deprecated template usage) pale- forms:

• (now chiefly N. Amer.)

They’re Their research, it seems, conflicts with yours. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 00:05, 31 August 2009 (UTC)— Edited to remove a stupid error; thanks DCDuring.

Actually, Wiktionary policy (might not be written policy, but nonetheless) is that whenever there's conflict between American and British spellings, the first editor to edit the thing in question uses whatever is most comfortable to them, and we stick with that. So, the spelling should be "paleontology", as it was the first template created. -Atelaes λάλει ἐμοί 00:28, 31 August 2009 (UTC)

So much the worse for "they're research". Their UK bias/preference is showing. If there were a good large, publicly available contemporary corpus of non-US English (It would be nice for other matters if it also included spoken material.), it would be easier to resolve such matters without the arbitrary first come, first served rule. I am only grateful that ligatures can rarely be justified in the UK. DCDuring TALK 01:01, 31 August 2009 (UTC)

On re-rereading Doremtizwr's comment, I note with alarm his proposed introduction of etymological considerations into choice of form. It would seem to be a form of prescriptivism that has no home here under our current practice and values. DCDuring TALK 01:14, 31 August 2009 (UTC)

I meant considerations such as the homography of pale- (from the Ancient Greek παλαιός (palaiós, “old”)) with (deprecated template usage) pale- (from the Latin palea (“chaff”)). This happens a fair bit with spellings that reduce (deprecated template usage) æ/(deprecated template usage) ae and (deprecated template usage) œ/(deprecated template usage) oe to (deprecated template usage) e. The best example of the confusion wrought by this is ped- (from the Ancient Greek παῖς (paîs), παιδ- (paid-, “child”)) vs. (deprecated template usage) ped- (from the Ancient Greek πέδον (pédon, “~soil”)) vs. (deprecated template usage) ped- (from the Latin pēs, ped- (“foot”)). I don’t see how taking such considerations into account could, by any stretch of the imagination, be alarming. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 01:36, 31 August 2009 (UTC)

I alarmed by the introduction of the irrelevancy of etymology into matters of current usage and usability. It is yet another form of prescriptivism, whose rejection is one of the values of this enterprise that I most cherish. DCDuring TALK 02:19, 31 August 2009 (UTC)

Well then, it seems that we disagree irreconcilably. Consider, as it seems is your wont, whether a wholly permissive dictionary which eschews all prescription is what our user base actually wants. Usage guides are popular and logomachies are common for a reason. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 02:35, 31 August 2009 (UTC)

Such things have their uses. Let a thousand flowers bloom. They are not suitable for the ambitions of WMF projects, however. I cannot see how any one POV on such matters can be acceptable. It is certainly not consistent with the value system. But perhaps adherents of some tendentious points of view can capture control of this free resource and run it as they will. DCDuring TALK 03:32, 31 August 2009 (UTC)

In simple Internet usage, paleontology is used more than six times as frequently as palaeontology (10,200,000 vs. 1,650,000). —Stephen 02:16, 31 August 2009 (UTC)

But the very idea that such facts are relevant seems to be what is in question. I had thought that the weight of evidence was what mattered. Perhaps I was misinformed. DCDuring TALK 03:32, 31 August 2009 (UTC)

I think we should be descriptivist in what we present to users, but there are a range of considerations in how we ourselves write. If an editor wanted to delete the entry for ain't, I'd object; and if an editor used ain't in entries, I'd also object. If paleontology is the more common spelling, I think that speaks mainly to the general predominance of American spellings; and so far, we've followed a "keep-the-peace"–type practice of ignoring said predominance, and instead treating American and British spellings as equally acceptable. As such, I agree with Atelaes that {{paleontology}} should be preferred because it was created first (and not because it's more common on the Web), and the other ones should ideally be deleted. (Though admittedly, this does make it a bit awkward when this tag is added to a sense-line whose definition uses British spellings.) —Ruakh_TALK 17:01, 31 August 2009 (UTC)

The choice of spellings communicates more than one thing to users. It constitutes a kind of recommendation. It can be interpreted as how we position ourselves in terms of formality or UK/US orientation or egg-headedness. Letting our impact on users be determined by our "reward" system for volunteers (I'd rather have cash, Amazon credits, health benefits, or even barnstars.) is an example of the absence of user focus that seems to pervade our choices. We do not control how users react to these things (nor do they). According to Google News, the paleo- spelling is on all fours with the palaeo- spelling in UK and Australia. The paleo-spelling is overwhelmingly dominant in US and Canada (9:0). It even might be more common in India (small sample: 3:1).

I wonder if there is a reasonable way of marking a word that we might use in definitions, context tags, or elsewhere which is subject to a significant regional difference. Also, how could we invite users to note such things? DCDuring TALK 18:29, 31 August 2009 (UTC)

(from the left) palæontology is of course very difficult to type on a keyboard anyway. More templates make it more difficult for novice editors, that's the reason why we try and avoid making new ones when something to do the same job already exists. As I always say, you're free to go on another website, or use your own user page for personal projects, but we are trying to establish a good quality dictionay here. PS

"This follows on from our general tendency to allow individual entries to diverge as much as is natural, possible and favourable."

Who is this? Mglovesfun (talk) 18:36, 31 August 2009 (UTC)

(also from the left) It would be possible to do something in JavaScript; attach a suitable class to the occurrences of such words/phrases, and then render them differently depending on a) browser language detected via navigator.language / navigator.userLanguage (so as to display differently for en-US, en-UK, etc.); b) user selection via some unobtrusive little JS menu, maybe up in the top right corner; c) settings for logged-in users done in some other way. How much resistance there would be to putting that in the default skin I don't know. -- Visviva 11:53, 5 September 2009 (UTC)

Great! That was the kind of thing I was hoping for. I like ‘b)’; what do you make of the box to the right? Is that suitable? Presumably it can be set up only to display applicable toggles, so that if the only variably-spelt word an entry contains is, say, center/centre, then the only toggle in the box will be  -er • -re — right? It’s also probably unnecessary to have two different toggles for the ae–æ–ai–e and e–oe–œ–oi tetrachotomies or for the e-e–ee–eë and o-o–oo–oö trichotomies, since it’s unlikely that a person will want to see amœba but encyclopaedia (and not encyclopædia), or whatever. Yeah, this could definitely be the way to go. The spellings could be changed through templates named something like {{S:xion}} and {{S:ize}} (with S: standing for spelling just like the R: in our many such named templates stands for reference). Does all that seem practicable and a good idea to you? † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 00:07, 10 September 2009 (UTC)

My principal concern is with the default presented to anons and those registered users who have yet to have been clued as to the workings of WT:PREFS or the more obscure customization possibilities. It would be nice if we used some IP type information to customize spellings of definitions, contexts, usage notes and also, help pages, Wiktionary pages, etc, by default for anons, but principal namespace is the first priority. DCDuring TALK 01:10, 10 September 2009 (UTC)

The real value of this would be if it could be instituted for our un–logged-in users. If that could be done, then there would almost certainly be far less of the perennial tension surrounding spellings (at least from me). TBH, if this flexibility only worked through the PREFS, it would be but a minor improvement. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 01:15, 10 September 2009 (UTC)

Most English language browsers will give "en-US" or "en-UK" as the navigator.language. (I was surprised that these are the only variants available for Firefox). So we wouldn't have to actually sniff their IP (which people might find unnerving, or annoying if they were e.g. using a US-English browser in Hong Kong), we can just get the browser language information, and if not English, default to whatever. -- Visviva 07:14, 10 September 2009 (UTC)

Well, IMO anything that goes beyond a standard regional difference is beyond what we could plausibly handle in the default skin. So I was thinking in terms of a little dropdown menu with just "US", "UK", "Australia", "Canada" etc. Obviously this would result in "-ise" spellings being shown even to "-ize"-favoring British types, but there's no straightforward way around that that I can see. I very much doubt if you could get consensus for a menu such as shown (though it might be interesting to try :-P ). -- Visviva 07:14, 10 September 2009 (UTC)

What are the problems with that kind of toggle box, exactly? There are plenty of problems with choosing spellings by region… † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 23:44, 10 September 2009 (UTC)

I very much like this idea. Would it be implemented only for context templates, or would we try to use it in running text as well (like we have {{,}})? We could, for instance, create {{s:center}} and {{s:centre}} so that whichever is used in the running text of a definition line, the display would be how the user (or the navigator's language) desires it. --Bequw → ¢ • τ 14:09, 11 September 2009 (UTC)

I reckon in running text, too. That way we avoid stupid stuff like “molluscs/mollusks”, as in the first definition of octopus. IMO, {{S:er}} or {{S:re}} (with one as a redirect to the other) would be a better idea, since most of these spelling differences fall into patterns, and such nomenclature avoids the bewildering proliferation of S:-prefixed templates (so we’d write “centre” as cent{{S:re}}). What do you think? † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 14:43, 11 September 2009 (UTC)

Yeah, that's better. I like it. --Bequw → ¢ • τ 14:47, 12 September 2009 (UTC)

Using the automated translation boxes, sometimes an error message shows up: "Could not find translation table...Please improve glosses." What do I do? Should I add the translation manually? Ailurophile 17:55, 29 August 2009 (UTC)

• Yes, the error occurs because two of the translation boxes have the same, or a very similar, title (so you could improve the glosses by making them more distinct). I hope to fix this issue at some point, but for now it serves as a reminder that each gloss should match only one definition (and they should thus not be overly similar to each other). Conrad.Irwin 14:16, 30 August 2009 (UTC)

  Conrad, is it possible to generate a clean up list for these? DCDuring TALK 18:44, 30 August 2009 (UTC)

Urm, probably, but I'll have to think about it. Conrad.Irwin 22:58, 6 September 2009 (UTC)

I wish I could think of a way to estimate how many of these there are. Have there been many questions about this? DCDuring TALK 23:17, 6 September 2009 (UTC)

I can't recall ever having seen this issue raised before. --EncycloPetey 23:45, 6 September 2009 (UTC)

It's come up four-five times, probably split between here, the early WT:BP chat, my talk page and WT:EDIT. I am totally at fault for it causing issues as I should not have taken the lazy way out to start with. (Although in an ideal world all the glosses would be unique). Conrad.Irwin 23:49, 6 September 2009 (UTC)

You might call it lazy or you might call it economical. If the numbers are that low, we can address the problem as it arises. The glosses so identified can stand improvement. There are lots of things you can productively spend your time on that are more important than this. DCDuring TALK 00:42, 7 September 2009 (UTC)

should help. Please let me know if you get the new message ("Glosses should be unique"). Conrad.Irwin 01:03, 11 September 2009 (UTC)

In order to canalize good willings I propose to deploy a template like w:Template:Navigation_things_to_do or in French fr:Annexe:Quoi_faire_sur_Wikimédia. JackPotte 23:53, 29 August 2009 (UTC)

Wiktionary:Things_to_do needs a some work before that template will be useful. Conrad.Irwin 14:36, 30 August 2009 (UTC)