Wiktionary:Beer parlour/2016/October

Well, "@" as a general symbol of the Internet has entered the popular consciousness in a way that :// certainly hasn't. Equinox ◑ 17:23, 11 October 2016 (UTC)

As said in the RFD discussion, :// is actually a SOP of : (delimiter used after ftp, http, smtp...) and //, which already has a networking sense. --Daniel Carrero (talk) 17:30, 11 October 2016 (UTC)

Then pretend I said "in a way that : and // certainly haven't". Equinox ◑ 17:32, 11 October 2016 (UTC)

Sure. --Daniel Carrero (talk) 18:04, 11 October 2016 (UTC)

I'm thinking of creating a module to generate German pronunciation from spelling, sometimes with the help of pronunciation respellings (e.g. Phonem probably has to be respelled something like Phoném to indicate the unexpected stress). I don't actually know whether this is reasonably possible for German but I assume it probably is in most cases. (Note that there's already a module of sorts in Module:de-IPA that purports to do this, but it's really horrible.)

I'm looking for knowledgeable German speakers to add test cases to Module:de-IPA/testcases. This is module code but don't be alarmed; adding test cases is very easy, just follow the examples.

The only special symbols so far I've created are:

1. acute accent (e.g. á é í ó ú ä́ ö́ ǘ) for unexpected primary stress; expected stress should be on the first syllable except for certain prefixes like ge-, be-, ver-, etc.
2. grave accent (e.g. à è ì ò ù ä̀ ö̀ ǜ) for secondary stress, unless it's somehow predictable
3. slash to separate compounds joined together (e.g. Buch/stabe)

Note that there's already a module that does this quite well for French (Module:fr-pron), despite the vagaries of French spelling; see the test cases in Module:fr-pron/testcases. There's similarly a Russian pronunciation module Module:ru-pron, with test cases Module:ru-pron/testcases. Both of these I rewrote entirely based on early versions (respectively by User:Kc kennylau and User:Wyang). Benwing2 (talk) 23:09, 8 October 2016 (UTC)

This really should be preceeded by a thorough discussion of our German pronunciation practice, which I consider in dire need of overhaul, which is usually met with roaring silence. Korn (talk) 00:09, 9 October 2016 (UTC)

Fine with me. I didn't realize that there was a problem. What do you think we should use instead? Benwing2 (talk) 02:37, 9 October 2016 (UTC)

Not a native speaker but I disagree with some test cases:

The final "r" being completely silent. It's light and I think /ɐ̯/ should be used for the sound, Uhr is a correct test case.

Qualität has no 2-ary stress.

Reichstag probably needs a respelling to make it obvious that -tag is long in this compound word. It worked for Auswahl, though. --Anatoli T. ^{(обсудить}/^вклад) 05:16, 9 October 2016 (UTC)

• Here are the things we need to discuss and find consensus on. I cannot answer most questions because they're southern issues.

1. Which pronunciations do we put down? We need at least three national standards. (Germany has at least two standards, though.) Maybe more? And in which form? What do we define as standard? For a start, my definition is: "Standard are those features which are not avoided by speakers in the most formal setting." This includes for example ⟨Chemie⟩ /ʃeːmi/, ⟨wichtig⟩ /vɪxtɪk/. And I do not think the artificial language of newsreaders is a good representation of the varying different standards. That language mostly excludes /ʃeːmi, vɪxtɪk/.
2. Where I'm from (north) and live (Berlin area), there is no /ə/ phoneme, unstressed vowels get deleted or are phonetically fully identical with /ɪ/ as , or even with northern accent (which is not considered standard). The merger itself absolutely standard, I wouldn't be surprised if a good deal of northerners would normally parse as /-ər/. Is this a negligible phænomenon of a specific (big) region or do we need to address it? Is there actually a different situation elsewhere?
3. Unstressed vowels can surface as and in Austria commonly, /ə/ is in some parts of the south. Will Austrian dialects be represented with ⟨ə, ɐ⟩, ⟨ɛ, a⟩, both or a mixture, what about ? Korn (talk) 08:02, 9 October 2016 (UTC)
4. Switzerland is rhotic, Austria and Bavaria are facultatively rhotic, some parts of Germany are traditionally rhotic. Where and how do we represent what?
5. Even German German is traditionally rhotic in some places where it is no longer general. /stark/ is , or . Which to include? What about ?
6. Austro-Bavarian does nor palatalise fricatives after liquids, so that /furxt/ is instead of e.g. , which is the local standard where I live. How standard is it? Do we represent it?
7. Same question for /xs/ which is in Germany and in Austro-Bavarian.
8. Also /x/ in general. Switzerland and at least parts of Austria only have one phone , the north has three , Berlin only knows . What to include?
9. We need to discuss the shown vowel qualities of both lax high vowels and /a/, which might be tense high vowels and respectively in the south. (Wikipedia says that is the realisation for Austrian standard, it should be the same for Switzerland.) /a/ is in Germany, which to pick?
10. Further, the northern third of Germans has phonemic backness: /a, ar, aː/ are . Ignore or include? But ⟨Maß⟩ and ⟨Mars⟩ are identifiable minimal pairs here, but as I'm told not in other regions.
11. Is /aɐ̯/ actually used? Do we favour /aɐ̯/ or /aː/?
12. The last consensus was not to show aspiration. I think this is a mistake.
13. I would consider /pf-/ and the presence of an /ɛː/ in most words to be nonstandard for here. I.e. if someone native to my area would use it, I would consider it so foreign to be wrong. /(p)f/ is easily represented. Do we double e.g. /ʃpɛːt/, /ʃpeːt/?
14. What to use for /v/ which is not truly in many regions?
15. What to do about fortis/lenis? As far as I'm aware, in the south, lenis consonants are unaspirated voiceless with tensed but unvibrating vocal cords, while fortis consonants are longer and more forcefully pronounced. I'm not a friend of /d̥, p̊, g̊/ for dogmatic reasons, but this is the least we can do.
16. Consonant length instead of ambisyllabic consonants in the south in general. Having ⟨Katze⟩ as /kat.tse/ is perfectly normal for Austria and Switzerland. If its absence is markedly foreign, we should include it. Cf. audio file at Mitte.
17. Fortis-lenis levelling is said to be absent in Austria/Switzerland. (I only know it for Switzerland.)
18. /r/ is , which to use where? I'm strictly opposed to using in broad transcription.
19. Beyond automatic additions, which regional non-standard forms are worth adding/allowing? Northern standard realises /v/ as in several instances, e.g. /ʃvyːl/ is inavriably , /tsvo/ as . Is there any point in prohibiting any pronunciation at all?
20. Do we include a superdialectal broad form or one for each? I.e. /bitːər/ + (Austria), (Germany) or /bitːər/ (Austria) + /bɪtər/ (Germany)? Korn (talk) 09:34, 9 October 2016 (UTC)

That's what I can think of off the top of my head. If we start adding stuff automatically, we might as well do the whole shebang and do it right. Korn (talk) 08:02, 9 October 2016 (UTC)

ps.: A lot of motivation behind this, aspiration for example, is that I assume we want to represent a native pronunciation that people can emulate, and mix and match simply makes you sound like a foreigner. It's one thing to speak German with Bavarian features if you're a Bavarian, but if you're a Slovene who comes to Berlin and tries to adapt the local language while erroneously using non-regional features, people will not interpret it as Bavarian but as Slovene. It's like mixing Geordie and Texas. Sure, it's English, but if a dictionary wouldn't tell me the difference, I'd consider it a shoddy bad work. Korn (talk) 08:12, 9 October 2016 (UTC)

Lots of what you're trying to represent is dialectal features. Fundamentally, though, we for the most part avoid doing this because it's a huge can of worms, as you've demonstrated. For British English, for example, we pick the most standard form (RP) and represent it, and don't even try to represent all the numerous dialects. Similarly for German, that would mean choosing the standard as usually found in most dictionaries, which is similar AFAIK to what we already have. As for things like aspiration, I agree we shouldn't show it because we're trying to represent a broad phonemic representation rather than phonetic detail that is more likely to be dialect-specific. We don't represent aspiration in English, for example. In general we should follow the lead of other dictionaries. If you want to show some dialectal renderings in addition to the standard, that is fine but we don't need to force ourselves to do that by default. Similarly, for example, we show "General American" pronunciation for American English even though that differs significantly from e.g. Southern or New York English. For French what we actually show is something like a 100-year-old Parisian standard that doesn't very accurately represent anyone's speech any more but is what is conventionally found in dictionaries. Benwing2 (talk) 15:53, 9 October 2016 (UTC)

Small thing first: We absolutely and commonly show aspiration for English. cat, water, take, and I don't think aspiration was ever contested for English. We just don't have many pages with narrow transcriptions.

And yes, this is about dialects because there is no non-dialectal German. The standard is not a thing, there are the standards and these need to be represented and we need to discuss how. To give the broadest æquivalent, we're normally only showing the German version of GenAm (Germany). We need to discuss whether we show it the right way and we need to discuss how we want to represent the æquivalent to RP (Austria) and GenAus (Switzerland). And if we don't show them, we're simply not that good a dictionary. The standard 'found in most dictionaries' is some form of representation of the standard of non-southern Germany, simply because that is the largest area by far. It has little relevance to people not living in that area and people in Austria often don't have a opinion of it either - not that this is relevant to us.

While lack of aspiration is non-standard in most of Germany, presence of aspiration might be non-standard in Austria and Switzerland. Those things are features speakers using either standard would want to get right in order not to sound less capable. I repeat that a mixture of standards shows a lack in proficiency. It is for that reason that I think the features demarking the standards need to be represented, if we want to produce something useful. And this is where my questions aim: 1. We need to stop being so stupidly German-centric. 2. We need to find out which features make an actual difference between the different standards. 3. We need to find out how to represent them. Korn (talk) 17:03, 9 October 2016 (UTC)

Very well then, I am fine with "only showing the German version of GenAm". That's my exact point. We simply don't have the resources to consistently represent a large spectrum of dialectal variants. That's why you're getting the "silence". Are you volunteering to personally do all the work to get this done? If not, who's gonna do it? Remember that "the perfect is the enemy of the good". Benwing2 (talk) 20:08, 9 October 2016 (UTC)

I feel that we should stay broadly consistent with the Wikipedia page on Standard German phonology. As far as deviations from this (ideal) standard go, perhaps we could include pronunciations specific for certain cities that would implicitly represent the accent of a wider region. Crom daba (talk) 20:51, 9 October 2016 (UTC)

• So you would be fine with not including RP for English? I'm not sure that's the right spirit. And we don't need to represent a 'large spectrum of dialectal variants'. There's four German speaking countries, amongst which there are 3-5 different standards. I think we won't break a leg by adding 2 broad ones with 2-3 narrow versions each. And adding German phonology is one of the things I wanted to do on Wiktionary, but every time I tried to make the entries a little less misleadingly generalising, @Kolmiel pops up, reverts my edits and barks at me to get consensus first. Which I can't keep because people can't be arsed to have a discussion. Catch-22, thanks very much. As for the Wikipedia article, according to Kolmiel, about half of its information is currently verboten. Also, who's going to do the work is perfectly irrelevant for making rules on what's to be included and what not. Certainly nobody's gonna do anything if it keeps getting reverted, innit. Korn (talk) 22:58, 9 October 2016 (UTC)

I think our pronunciation practice is fine. Keeping it simple and intelligible to at least a mentionable minority of users. What is very wrong is to say that the "northern German standard" has no relevance to southern Germany, Austria, Switzerland. This is nonsense. Bavarian and even Austrian radio news are now commonly read in a distinctly northern accent, with -ig pronounced -ich and everything. Swiss television has even hired what must be German readers to speak over their reports. Apart from that, I guess Korn will have his anyway and everything will be messed up. Do what you want. I don't care that much. Kolmiel (talk) 23:08, 9 October 2016 (UTC)

It's not right to argue about dialectal differences before the basic stuff is implemented. Regional standards can be implemented later using the same module using phonetic respellings, something like "|phon=wichtik|reg=at" (just an example), if you want to use the Austrian pronunciation of wichtig. Get your priorities right, people and help Ben fix the module! --Anatoli T. ^{(обсудить}/^вклад) 06:55, 10 October 2016 (UTC)

Regional standards cannot be implemented later, since, which is my point, this is implementing a regional standard. It's simply the biggest and the one exerting most influence because of its prevalence. Starting with one first is nothing I am opposed to. What I'm opposed to is not labeling it and having it come to pass without prior thorough discussion of its ambiguities. And, as in any discussion, excluding information - not by not entering it but by prohibiting its entering - without a proper case made for it. Korn (talk) 12:17, 10 October 2016 (UTC)

Korn, I don't object to labeling the German standard as "German standard" or whatever. But you seem determined to gum up the process to the point that nothing gets done. How about, as Anatoli suggests, we try to implement this German standard rather than just arguing? It's easy to change the module at any point to e.g. use r instead of ʁ, and changing the test cases isn't hard either. We've done it plenty of times in Russian, for example. Benwing2 (talk) 13:50, 10 October 2016 (UTC)

@Korn: Has there been a similar system developed for German to the enPR/AHD? If there is or if you create one, we could that {{de-IPA}} go from the lemma to dePR. Then for any dialect whose transcription you'd like to add, we can have a function to create that dialect from the dePR representation. I think that before anything can be done in terms of broad dialectal coverage, someone needs to make some big tables of correspondences since your lists of changes are a bit overwhelming and difficult to understand. —JohnC5 14:39, 10 October 2016 (UTC)

The creation of exactly that kind of thing for German is what I wanted to initiate! I wanted people to discuss which variants to include and which values to put for the variables. I was assuming that Wiktionary had some person who'd know more about southern German than I do (which isn't that much) and that this would be a thing done with in no time. Korn (talk) 17:46, 10 October 2016 (UTC)

Evidently you will have to be the one to do it, if you want it done; no one else appears to have the experience or interest. However, I really don't think this is necessary to get done before helping me create the test cases I've requested above. Benwing2 (talk) 18:28, 10 October 2016 (UTC)

You miss the point. I would have done this long time ago, but people kept removing my edits. The point is not so much that I want people to do anything, the point is more that I want some consensus that these things can be done. ps.: And of course it is relevant to decide what the expected results of test cases should be before test cases are added. I have no idea what you want your module to put out and I'm surprised, for example, that the module expects ⟨Quatsch⟩ to be instead of . Korn (talk) 19:19, 10 October 2016 (UTC)

I don't know why people are removing your edits; they would seem fine to me. As for Quatsch, I simply copied the pronunciation found on that page; it should be fixed there if it's wrong. Benwing2 (talk) 19:31, 10 October 2016 (UTC)

And here the circle closes. Because this is exactly the kind discussion I wanted to have. This isn't wrong, this is one of two options (/). And we must decide whether the expected result of the test case should be one, the other, or both. We can not not decide. Do you see my point now? We can't put any test cases without deciding one way or another what we want tested. Korn (]) 21:14, 10 October 2016 (UTC)

@Korn You think you're getting your point across but you're not, instead of helping, you seem to be sabotaging, involuntarily. You can use test cases for STANDARD German (Northern, Germany-centric, Bühnendeutsch, whatever). Any deviations or variants could use phonetic respellings and regional labels. --Anatoli T. ^{(обсудить}/^вклад) 21:35, 10 October 2016 (UTC)

I am obviously not getting my point across because not a single person has yet understood what I'm saying. Bear with me one more time, I'll try to make it absolutely clear. To repeat: 1. There is more than one standard. There is not the standard. 2. I am fine with starting out with one of the standards, and have it be the northern one. 3. EVEN THEN the northern standard sometimes has multiple valid realisations. MULTIPLE. Not 'one and some deviations', multiple. equally. valid. standard. realisations. of. equal. standardness. To give another English analogy: If I were to say: 'Received Pronunciation realises ⟨ol⟩ in one of two ways, and , which one do we use?' - And all I'm hearing instead of a reply is: 'Nobody cares about this, just put the RECEIVED PRONUNCIATION.' If you don't want to pick one form, what do you want to do? Put a picture of a dancing elephant instead of letters? Korn (talk) 21:50, 10 October 2016 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Just choose ONE standard, choose a label for it. You do realise that showing multiple realisations may be difficult, right? Consider this simple example of two standard pronunciations of the same word

• ähneln (IPA follows)
• ähneln (phonetic respelling: ehneln) (IPA follows)

Benwing will come up with some tricks, I'm sure.--Anatoli T. ^{(обсудить}/^вклад) 22:01, 10 October 2016 (UTC)

Do you notice how 'just pick one' is the first actual reaction to the point I get AT ALL? How this is actually some form of guideline or method that allows to actually enter test cases with any form of consensus? How this is a jolly lot more than refusing the very question? Korn (talk) 22:07, 10 October 2016 (UTC)

It seems like you're downplaying the pre-eminence of the Northern standard (known elsewhere as Standard German), it's the "artificial language of newsreaders" that dictionaries, learning materials and radio broadcasts use. Dialects may be used in the most formal of settings, but as evidenced by your 20 points, they are not standardised. Crom daba (talk) 22:13, 10 October 2016 (UTC)

Newsreaders are using , and with equal standing, depending on nothing else but personal inclination. So are news readers speaking a non-standardised dialect now? Should we do away with the whole concept of German pronunciation because it isn't regulated to the last iota and replace it with dancing elephants? Or should we just be productive for a fraction of second, pick one, or give a guideline for the editor to pick, and get on with the module? Which this discussion does not seem capable of at all. This issue is not nearly as big as to merit this discussion in the slightest. This is ludicrously blown out of proportions. I would have just gone and entered something by now, but, and this is the critical point, there's this history of something being removed if I cannot point at some form of consensus. Which apparently just cannot be achieved because people for some reason keep thinking I'm discussing in order to enter medieval Cimbrian as standard German. Korn (talk) 22:29, 10 October 2016 (UTC)

Do you think this situation is unique for German? The standard German phonology is described many times and is used in many places. Dictionary publishers won't get stuck on variations. If I were like you, we would still be arguing, if the Russian часы́ (časý) should also include the pronunciation as many native speakers, including educated ones or even newsreaders, would choose to pronounce, especially from the South or from Ukraine. The standard and the most common Russian pronunciation of the word is . A suggestion: just use for stark but be consistent about it! BTW, you even have a chance to choose your favourite accent, being an active German editor and thus - one of the few dictionary makers. We'll have to trust your judgement but someone may dispute your decision (which is also OK!) but we need to have something happening. --Anatoli T. ^{(обсудить}/^вклад) 23:49, 10 October 2016 (UTC)

Korn, we all do want to get on with the module. I'm still not sure which changes of yours are getting reverted. I think the number of actual issues involved in rendering standard Northern German will be small, and in doubt, err on the side of being more conservative. Hence use not , and maybe instead of . But overall these are minor issues, not the major issues that are involved in trying to handle multiple dialects. In many cases I think people will defer to your judgment -- similarly, I've largely deferred to Anatoli's judgment because he's a native Russian speaker and has very good linguistic intuitions. Occasionally we have had discussions over how much detail to render or how to handle things like palatalized affricates, but these have not been grave. Benwing2 (talk) 00:05, 11 October 2016 (UTC)

Yes. Yes. These are minor issues. Which is exactly why it's so frustrating that it takes a page-long conversation before somebody says something productive like 'just pick one' or 'in doubt use the more conservative one'. This is exactly the kind of thing I asked about and you (plural) could have said: 'I get that there's pluricentricity, but foreigners abroad are taught German German, so I think it's best if we start with the biggest variety of that. Put something you feel adæquate for now and if there's variation in there, just use the more conservative one', right after I posted my 20 points and we would have been done with this two days ago. Anatoli, with all due respect, which I do have for you, all of you, the reason that dictionary publishers don't get stuck on variations is probably that they just decide for one instead of making a hub-bub about the raising of the question. And that in all other publications, pages don't get torn out by random passer-bys who disagree with that choice. I think we're all somewhat annoyed by this kerfuffle, I hope this isn't dampening anyone's good spirits. Korn (talk) 07:49, 11 October 2016 (UTC)

The status quo: CFI allows for Esperanto, Ido, Interlingua, Interlingue (Occidental), Lojban, Novial, and Volapük to be in mainspace; all other constructed languages must have their entries in appendices.

The problem: I suspect some of them have so little material that nearly all our entries would fail RFV. (In fact, Klingon is not allowed in mainspace, but its durably archived corpus probably rivals that of Lojban, for example.)

Proposed solution: Constructed languages with small corpora shouldn't be in mainspace. Esperanto without a doubt, and probably Ido and Volapük as well should stay. The others should be moved to Appendix space like Toki Pona and Quenya. I would like to get some feedback before I start a vote on this. —Μετάknowledge^{discuss/deeds} 21:12, 9 October 2016 (UTC)

I agree that Esperanto, Ido, and Volapük should probably stay. For the other languages, I share the concern that the corpora may be too small. I'm not very familiar with Interlingua, Interlingue, or Novial, but for Lojban, very common words like .i and la appear to be citeable from Usenet, but I can't seem to cite an ordinary word like muvdu. —Mr. Granger (talk • contribs) 15:47, 10 October 2016 (UTC)

It wouldn't bother me to have only a dozen or so entries for one language, if that's all that can be cited. The problem is creation of entries based on dictionaries or whatever other criteria when the words don't meet CFI. A bit like users who enter a load of -phobia entries, I see these as about the same. Renard Migrant (talk) 15:58, 10 October 2016 (UTC)

So should we have a policy that words from these languages can be deleted on sight if no citations are provided? DTLHS (talk) 16:04, 10 October 2016 (UTC)

My own view is that we shouldn't have languages in appendices at all. Either they should be in mainspace or nowhere at all. —CodeCat 17:08, 10 October 2016 (UTC)

Why? —Μετάknowledge^{discuss/deeds} 19:55, 10 October 2016 (UTC)

• @Ungoliant MMDCCLXIV, in case you're interested in contributing. —Μετάknowledge^{discuss/deeds} 23:12, 16 October 2016 (UTC)

We have a dozen or more natural languages from which only 1-3 words meet CFI, so there is no inherent problem in having languages which have only a few entries after the razor of CFI has been used to shave them, as Renard says. But I agree with Metaknowledge that it makes little sense to allow some sparsely-attested artificial languages in the mainspace but not others. - -sche (discuss) 04:25, 20 October 2016 (UTC)

Comment, because Klingon was mentioned: in previous discussions, it has been noted that Wiktionary cannot include many words in Klingon, Dothraki, and some other languages (Quenya?) without running into legal/copyright problems. - -sche (discuss) 04:25, 20 October 2016 (UTC)

It's generally asserted that durable citations are required to pass RfV. I think this requirement is needlessly bureaucratic and should be abolished. While it might be preferable to have durable citations, I don't think it's imperative. Here's why:

1. In today's world, a greater percentage of content is on not-necessarily-durable website rather than print media or durable websites.
2. Compare to books. We don't link to every book we have, and we don't unfrequently cite rare books where Joe Avg is unlikely to ever obtain a copy.
3. Some things don't stay up forever, but many things do. Instead of assuming that something will eventually disappear, we could assume that it won't (FWIW, Wikipedia makes the latter assumption; it doesn't require durable references)
4. If the quote that uses the word in one or more sentences is already on Wiktionary, do we necessarily need a link to anything anyway? Purplebackpack89 05:14, 10 October 2016 (UTC)

We should expand what is considered as "durable", but not reject it. We still need quotes that we can check up on later, and won't simply disappear (as many of Wikipedia's links do). I can think of times when someone misread a source and only later, by looking at the same source, could we determine what it actually said for the purpose of citing it. —Μετάknowledge^{discuss/deeds} 05:28, 10 October 2016 (UTC)

We can't just accept any words from random websites or else there's some danger that we will get flooded with things that would otherwise go on AP:LOP. You said elsewhere: " used a lot on the Internet, and, since it's a word that postdates the decline of print media, that oughta be good enough." but by your own count, there are 744 Google hits for that term, which I consider a small number. Only 744 hits seems indicative of a minor trend in using that term. Do you have any specific criteria in mind? I wonder if all English words that are used (not just mentioned) on more than, say, 10,000 websites are likely to appear in books anyway. --Daniel Carrero (talk) 05:34, 10 October 2016 (UTC)

744 may seem like a small number compared to 10,000, but it's a big number compared to 3, which is the floor for number of durable citations we need. If something appeared in 20 or 30 non-durable websites, I think we ought to consider having it. As for your concern about protologisms, those tend to be weeded out more by the at-least-a-year rule than by the durability rule. Purplebackpack89 05:38, 10 October 2016 (UTC)

Sorry, I understand your point but I don't find it very convincing. You may wish to create a vote with the proposal "include words that have 700+ uses on the internet" and see if many people support it. But in my opinion 1 durable citation is worth at least 10,000 non-durable citations... Actually, you may ignore my arbitrary math, I just meant that non-durable citations are really worthless (again, IMO) except maybe in very large numbers. --Daniel Carrero (talk) 07:20, 10 October 2016 (UTC)

10,000 to 1? Really? Why do you think non-durable citations are so worthless? Is it reliability? There are plenty of websites that most would consider "reliable" that aren't durable. By contrast, some of the durable things we have aren't necessarily all that reliable. Purplebackpack89 17:53, 10 October 2016 (UTC)

Because if something is written in 3 books (especially 3 books easily accessible through Google Books), chances are the attested word is "set in stone" -- we won't have to worry about it and we won't have any trouble verifying it and reading the page for further context that may not be available in the quotation. If something is attested from a site that might disappear tomorrow, chances are we are going to have a headache when checking the quotation and attesting the term. But feel free to convince me otherwise if you want. --Daniel Carrero (talk) 18:05, 10 October 2016 (UTC)

But if something is common enough as to have 700+ uses on the internet, surely citing would be as easy as choosing another new source from the 700+ were a previous source to disappear? —suzukaze (t・c) 20:28, 10 October 2016 (UTC)

Sure, but that introduces an endless maintenance need that maybe can be avoided for most words. If a word is used so often on the internet that Wiktionary arguably needs to include it, what are the chances that the word already exists, too, in books and other durably archived sources? Do you know any specific words that Wiktionary might include by citing websites that can't be included by citing durably archived sources? --Daniel Carrero (talk) 20:34, 10 October 2016 (UTC)

Minority languages with obscure publications, conlangs, internet slang no one in their right mind would publish, etc. This is the phrase "to speak Teochew" in the Teochew dialect of Min Nan Chinese. It only has four pages of Google results. —suzukaze (t・c) 20:37, 10 October 2016 (UTC)

These are good examples, thanks. They are about the phrasebook, though. I believe there's no doubt that these sentences can be composed, so attestation is less important for them than for most single words. We could have a new policy like "allowing entries for translations of all accepted English phrasebook entries, in all languages, even if said translations have 0 Google hits." --Daniel Carrero (talk) 20:48, 10 October 2016 (UTC)

BTW, the "hot word" policy is relevant in a lot of cases. Equinox ◑ 15:48, 10 October 2016 (UTC)

I think there are loads of revisions we could potentially make here. For one, in actual fact WT:CFI doesn't say anything about copy citations up into entries. It's just assumed that that's what we do. But as someone once put it, nothing is specified, so nothing happens. CFI doesn't say you have to copy up the citations, so you don't have to. Of course best practice is to copy them up because then everyone can see them, but with hundreds of items tagged with rfv at a time, I'm certainly happy for anything that's definitely citable to go without the citations being copied up (citations yes, citations copied up, no). Renard Migrant (talk) 15:56, 10 October 2016 (UTC)

Nobody's really ever wanted to define durably, and I think we should. As someone said, what about taking screenshots of websites and adding them to Commons? Commons is likely to last as long as this wiki is, why shouldn't that count? Renard Migrant (talk) 16:05, 10 October 2016 (UTC)

Commons itself might last, but the image theoretically might be deleted. But I do think that's actually a good idea. The more realistic issues are that images can be tampered with, and screenshots especially (in fact Google Chrome allows you to actually change the content of any web page right in your browser, maybe other browsers have this feature as well). And if we start including anything from the internet, we'd have to come up with more rules to limit typos and misspellings and other nonsense. And the three different authors rule would be difficult to follow if the authors are anonymous. --WikiTiki89 16:16, 10 October 2016 (UTC)

Maybe we can upload screenshots to enwikt, but not to Commons. I believe our current quotations and possible future screenshots are fair use, which Commons does not accept. If the website has a CC license or is in public domain, Commons might accept it. --Daniel Carrero (talk) 17:38, 10 October 2016 (UTC)

I see those options as essentially equivalent. --WikiTiki89 18:03, 10 October 2016 (UTC)

Why even go that far? If we have the quote of it being used in a sentence and we put that on Wiktionary, shouldn't that be good enough? Purplebackpack89 17:53, 10 October 2016 (UTC)

Copying errors. --WikiTiki89 18:03, 10 October 2016 (UTC)

Because it's not durably archived. Someone might want to check the original for any of several reasons, and it may not be there. You take a screenshot and there's something to check. Renard Migrant (talk) 19:43, 10 October 2016 (UTC)

IMO, copying errors is too narrow a reason to dictate our entire attestation policy. Purplebackpack89 20:17, 10 October 2016 (UTC)

What about having multiple editors verify the text of a quote before accepting it? Even if it changes we have the affirmation of multiple people of what the text used to say. —suzukaze (t・c) 20:29, 10 October 2016 (UTC)

That does not sound too good. Just imagine if all our current quotations required to be checked by other people. It's hard enough to "finish Wiktionary" and ideally attest all senses as it is. If there are any copying errors, they are going to be found eventually, if the website does not vanish first. --Daniel Carrero (talk) 20:51, 10 October 2016 (UTC)

I suspect the reason why we have this policy is to avoid drowning in Internet ephemera, it's not a perfect filter, but removing it would necessitate creating more policies regarding exactly what kinds of words we want and how to define them, which would increase rules lawyering and decrease the quality of the dictionary. Crom daba (talk) 21:14, 10 October 2016 (UTC)

It stops people coining words on their on social media account then citing those social media accounts as sources. Renard Migrant (talk) 11:06, 11 October 2016 (UTC)

People are already able to do that through Usenet, aren't they? --Daniel Carrero (talk) 11:33, 11 October 2016 (UTC)

I think we're kidding ourselves into think that durable citations keeps only bad words out and keeping only good words in. Purplebackpack89 18:27, 11 October 2016 (UTC)

Does anyone actually think that, though? Renard Migrant (talk) 20:56, 11 October 2016 (UTC)

After some thought, I decided to support getting citations from the internet. English already has a social-media-ey place called Usenet from which we are allowed to get citations of internet slang and a number of random neologisms, but there are not a lot of Portuguese-speaking folks on the Usenet, so our coverage of modern Portuguese terms may be not as good. Maybe other languages too, I don't know.

Here are some Portuguese words that seem to be common enough on the internet but I was unable to find 3 citations for them on Google Books.

• cospobre -- a very poorly done cosplay
• democracídio -- "democracide", the act of killing the democracy
• flopar -- to fail
• nerfar -- to nerf (video game sense)
• Olindar -- to spend time in Olinda, Pernambuco
• qnd -- abbreviation of "quando" (when)
• shippar -- to ship (fictional character relationship sense)
• SQN -- abbreviation of "só que não" ("only not"), added at the end of a sentence
• trisal -- polyamorous relationship consisting of three people
• upar -- to upload

Also:

• exactly 1 trillion and a half emoticons can be attested from websites, if nobody minds

--Daniel Carrero (talk) 17:54, 11 October 2016 (UTC)

• Usenet is considered durably archived because multiple sites, financially stable, with a long history, actually have the archives. It is not a precedent for proprietary social networking sites, which may disappear or become inaccessible when the owner does or when the owner is in a tight financial bind. It would be better to look for what would get the multiple institutions with Usenet archives to add other classes of text data. DCDuring TALK 18:05, 11 October 2016 (UTC)

• Apparently, the Library of Congress is/was preserving an archive of Twitter: . The OED occasionally cites tweets. Equinox ◑ 18:07, 11 October 2016 (UTC)

  The US Library of Congress ("LoC") was to be the recipient of a donation by Twitter of a few years of public Twitter postings. BYU also thought they would have that corpus among their offerings. BYU no longer mentions Twitter and I haven't found any discussion on the LoC site of the Twitter data. The discussion seems to have bogged down. They did not seem too eager to support unlimited access. DCDuring TALK 00:18, 12 October 2016 (UTC)

  Then so should we.

• Another thought from a probably perspective: if a word is used 500 times on the internet, what are the odds that 498 or more of those citations will disappear from the Internet in 10 years' time? Purplebackpack89 18:27, 11 October 2016 (UTC)

Maybe I'm short sighted, but if a word is 700 times on the internet, do we have any method to sieve out the automatic copy paste to make sure it's not used 2x350 times? Korn (talk) 19:17, 11 October 2016 (UTC)

This discussion was rooted in the belief that, to satisfy attestation, somebody would still have to find three different quotes spanning a year and all that... Purplebackpack89 20:00, 11 October 2016 (UTC)

Yes, and upload a screenshot (a small cropped version, I hope) of the website to enwikt to ensure that we have the source content if the website vanishes. Should we have an additional rule of only attesting entries from websites if they have a lot of Google results in the first place? Just by creating an entry, we fill the Wiktionary mirrors with the same entry, thereby increasing the number of Google results to some extent. --Daniel Carrero (talk) 20:12, 11 October 2016 (UTC)

What does 'exactly 1 trillion and a half' mean? 1,000,000,000,000.5 or 1,500,000,000,000? And really exactly? Renard Migrant (talk) 20:56, 11 October 2016 (UTC)

Please don't take it literally. What I meant was: "An arbitrarily large number of emoticons can probably be attested if we accept citations from random websites." But, I thought it was clear that 'exactly 1 trillion and a half' means 1,500,000,000,000: that is "1 trillion and a half trillion". --Daniel Carrero (talk) 02:12, 12 October 2016 (UTC)

The screenshot idea is problematic. It's easy to manipulate them, you'd need a complicated scheme to find them when you want to ('cause you can't put them in the entry), I'd take a lot of time so people probably won't do it, you can't use screen readers (except maybe if we use PDFs), etc. Instead I suggest using w:Wayback Machine, see also w:Help:Using the Wayback Machine, the archiving can be done with a click and some Javascript and it's even bottable. We can limit sites that disallow archiving. Another way to limit problematic sites is to limit to something like sites that are in the 100,000 (maybe too big) top most popular in a certain country as measured by w:Alexa Internet rank or something else. I agree that checking search engine hit counts is a good idea. —Enosh (talk) 08:50, 12 October 2016 (UTC)

Also w:Wikipedia:Link rot, this problem feels pretty well covered. —Enosh (talk) 08:59, 12 October 2016 (UTC)

Re "we can limit sites that disallow archiving": this changes over time. The archives of some of my own past domains have been hidden on Archive.org when a cybersquatter has taken over and applied a more restrictive robots.txt. (The same is true of Google's Usenet archive, where you can apply to have your old posts hidden; but I think we have assumed Usenet to be archived by more people than just Google.) Equinox ◑ 13:21, 12 October 2016 (UTC)

w:Wikipedia:Link rot basically suggests: "Don't delete a citation just because the link is now broken! Search for copies of the citation instead! You can even use internet archives!" Is this something we can implement on Wiktionary? Basically, we would not need screenshots, we would only trust that all current citations are correct, but if a link is broken, we can fix it ourselves or we can open an RFV to verify an existing citation that is a broken link. We may want to use a separate request page for that, like WT:Requests for citation check or something. We could have the rule that if a citation can't be double-checked at a later date, it is invalidated. (like when a new robots.txt disables old, archived pages)

As a related subject, should we be able to accept citations from movies, video games, musics, for attestation purposes? I would be happy to accept citations from Brazilian movies because I'm under the impression that sometimes the characters use dialectal/regional speech that may be difficult to find in books. When something is written on a video game or movie (as opposed to said out loud), we could upload a screenshot, I suppose. The fact that a screenshot is easy to manipulate is not a huge issue, is it? Text citations are the easiest thing to manipulate, and we can't disallow text citations based on that. We will just have to be able to keep double-checking citations when we want. If a certain video game disappears forever from all computer systems (which sounds unlikely to me), we may even choose to invalidate citations and delete screenshots taken from it. --Daniel Carrero (talk) 13:54, 12 October 2016 (UTC)

We do have a handful of citations from games (e.g. deathmatch), films (hubba hubba), and songs (bootylicious). In some cases these are the simplest way to find a word (e.g. hip-hop slang) or the earliest practical citation. I don't think it's much harder to get hold of these media than a book. They seem pretty "durable". Equinox ◑ 13:57, 12 October 2016 (UTC)

Maybe WT:CFI should say it explicitly? "We accept citations from books (visit Google Books!), Usenet, video games, music, movies..." --Daniel Carrero (talk) 14:02, 12 October 2016 (UTC) Nevermind, it does. Except video games and songs, though. --Daniel Carrero (talk) 14:05, 12 October 2016 (UTC)

@Equinox: In fact, much easier many times--you can just search for the song and stream it in seconds. I think that adding some kind of mass media real world usage is superior to hypothetical but illustrative examples (e.g.) —Justin (koavf)❤T☮C☺M☯ 14:02, 12 October 2016 (UTC)

There is, of course, the issue that songs mostly don't come with lyrics (unless perhaps on the album sleeve), so it's hard to prove that a particular word and spelling is what the song contains. But that probably needs a separate discussion: this indentation is getting crazy. Equinox ◑ 16:23, 12 October 2016 (UTC)

I agree with Daniel's above suggestion to allow citations from anywhere, trust current citations as correct, and fix them if challenged and/or as needed. Purplebackpack89 15:37, 12 October 2016 (UTC)

If we want to accept citations from the internet for attestation purposes, I believe the right place to edit would be WT:CFI#Attestation, as described below.

Currently, that section contains these items (I'm not copying the vote references):

We could add a new item and move a portion of text below the list, this way:

Maybe we can use WT:RFV to check for review of existing citations, but that page is already too large and unwiedly. It's more than twice the size of WT:RFD, or WT:RFM, or WT:RFDO, or WT:RFC. For this reason, I think it's better to create a new page to check for existing citations. Maybe it should be called... I don't know. Maybe WT:Requests for citation review (WT:RFCR) or something else. --Daniel Carrero (talk) 00:33, 13 October 2016 (UTC)

I support expanding CFI to include Internet citations in some form or other. This would make it ten times easier to cite slang terms, especially ones like savage that have common meanings that would dominate a Google Books search (note that that example is missing a slang sense because I haven't been able to easily find citations). Andrew Sheedy (talk) 01:42, 13 October 2016 (UTC)

I support in principle, but we need to spend a lot of time and effort to construct a viable policy. The above is totally insufficient and I oppose it. --WikiTiki89 15:21, 13 October 2016 (UTC)

Do you see any specific problems with the currently proposed text? --Daniel Carrero (talk) 15:38, 13 October 2016 (UTC)

It's not the text, it's that we need to figure out a system, and the system described in your proposed text is insufficient to weed out garbage and does not specify any limits on how frequently or infrequently internet citations need to be re-checked. It contains no protections against sites that are frequently edited. The problem is that this is actually a hugely significant change and so it requires a great deal of careful thought and discussion before we arrive at a workable system. --WikiTiki89 15:52, 13 October 2016 (UTC)

Sure. I hope this is a good start. I think it would be a bad idea to have any time limits to re-check entries, people can do it whenever they want and use the proposed WT:Requests for citation review when necessary. Additionally, maybe bots can crawl all the links and search for 404 and other errors, and tag entries automatically. Also, if we consistently fill the accessdate= parameter of web quotations, then years later we may search for the earliest accessed entries to see if they are still OK. If a certain hosting service is disabled, like the old Geocities, we should be able to find all citations that use it, to see if we can fix them or should invalidate them.

Should we have protections against sites that are frequently edited? If we use wikis for citations, we may link to the edit histories. If there are no edit histories, we may search in the internet archives or invalidate that citation if all else fails. We should probably ban citations from Wiktionary discussions themselves, to prevent a circular logic: if we allowed citations from our discussions, then basically only 2 citations from external sources would be needed at all times, because we would easily fabricate the third, which I believe would be unfortunate.

I think we should only accept citations when it's clear who is the author, not only to credit them, but because I'm afraid those Tumblr articles with "Source: Tumblr" and nothing more are deeply unprofessional. This would probably weed out many random clickbait articles like "20 Signs You Spend Too Much Time Building Dictionaries". In fact, we probably should ban all clickbaits and advertisements altogether, because I don't want the word "delicious" to have a citation reading "You should eat a delicious Big Mac™." This would be bad in citations from magazines and newspapers, too, unless maybe if they are from ages ago and the word is used in a meaningful way. --Daniel Carrero (talk) 16:31, 13 October 2016 (UTC)

What's to prevent people requesting re-checks of the citations every other day? That's one reason we need limits. As for editable pages, with or without histories, there will frequently be errors (not just typos, but misuses of words, and other such things) that are later corrected, so the fact that we are able to point to some particular revision does not make that the right revision to point to. In print media, there is a lot more proofreading going on, which is why we don't have to worry about it so much, but on the internet it becomes a problem. And even just having the ability to edit pages after posting makes it less likely that authors will proofread themselves before posting. --WikiTiki89 17:15, 13 October 2016 (UTC)

But RFV, RFD, RFDO, RFM and RFC don't have a rule like "don't create new requests every day!", and we don't seem to have that problem. I double-checked the introduction of the aforementioned request pages now. Wiktionary:Voting policy contains "No topic should have a new vote more than once a day (24 hr period)."

WT:RFV includes: "Those who would seek attestation after the term or sense is nominated will appreciate your doing at least a cursory check for such attestation before nominating it"... Based on it, we may require people to check the internet archives by themselves before making a new request for citation-checking.

I take your point: "the fact that we are able to point to some particular revision does not make that the right revision to point to". Wikis or not, basically all pages on the the internet are editable by their authors. Maybe we should have greater quality standards and ignore one-off uses of words... If a typo like "esaclator" appears even in a book, we won't create a new entry esaclator because of it. We are able to tell the different between mistakes and actual words, right? Or maybe not? --Daniel Carrero (talk) 17:46, 13 October 2016 (UTC)

RFV doesn't need a rule at the moment because once something is attested it cannot become unattested. RFD/RFDO, however, does have a rule that you can't nominate something that has already passed RFD (without a substantially new reason or there having been a change of practice or policy since the last RFD). At RFC, you wouldn't nominate an entry that has just been cleaned up because it is already clean. With this new internet stuff, however, something can be attested one day and unattested the next, but it would be too time-consuming to re-check the same word every day. As for editable pages, if someone spells selfie as selfy, we might use it to attest selfy as an alternative spelling, but then the author comes back the next the day and corrects the spelling to selfie because it was really just a mistake. How are we to know? I would say we need some sort of standards such as only using content that is professionally proofread or something like that. --WikiTiki89 18:19, 13 October 2016 (UTC)

I'm not sure I agree with attesting entries only from content that is professionally proofread. I assume we would want to use sentences with random orthography and abbreviations like h8 = hate to build up our database of internet slang and text messaging slang. That's one kind of thing we are already able to find in Usenet. Usenet is not professionally proofread.

For non-internet slang cases, yes, we may want to implement a number of quality standards. We might have a specific rule saying that a nonstandard spelling that was later fixed becomes invalid as a citation.

I'm still not sure that we need a time limit. I could even suggest having an explicit time limit of 30 days or something if people really want it, even though I don't see the need.

But let's see how it would work out with an example: Suppose we visit http://www.snopes.com/luck/chain.asp (Snopes is professionally proofread, I believe) and get one citation from that page. In the first large paragraph, the first sentence is: The practice of circulating letters to other parties beyond their original recipients has existed for centuries, so pinpointing the exact origin of chain letters is problematic.. We could attest pinpoint using that sentence.

Suppose that tomorrow I visit the page again, and witness a very unfortunate turn of events: the owners of Snopes decided to close the website forever. I believe I would have to search for archives to see if we can keep the citation. If I don't find any suitable archives, I may create a citation review request.

If Snopes is not closed and the citation still exists in the original page, or if I already found an usable archive, there's no need to request a citation review. In which circumstances would someone be able to create a new request over and over for the same entry every day? --Daniel Carrero (talk) 19:03, 13 October 2016 (UTC)

The way it's worded right now, absolutely not. In principle should we include more things common on the Internet but uncitable by our current CFI, yes we should. I would favor replacing 'clearly in widespread use' which I suspect is getting as the same thing, as other things that are in clear widespread use would pass the three citations rule anyway. Let's rewrite that line. Renard Migrant (talk) 19:12, 13 October 2016 (UTC)

Usenet is not modifiable, so it's less of an issue. I never said "time limit", I just said "limit", which can be any sort of limiting factor. Professionally proofread is an example of something we can use to limit garbage, that doesn't mean it's the only thing we can do. Another thing discussed was increasing the citation requirements to 700, but that is probably beyond our research capacity. Right now we're in the brainstorming phase, so please don't make any concrete proposals any time soon. --WikiTiki89 19:29, 13 October 2016 (UTC)

It's fine, I said "time limit" because I understood it as some specific limit to avoid new requests every day. Sure, I would probably support the general idea of having some limits. In WT:RFV#Acela Republican (to be archived at Talk:Acela Republican), Purplebackpack89 said "I got 744 ". I think the idea proposed was that a word with 700+ words deserves to be included somehow, but even if we accepted it, it's not necessary to add the 700 citations here.

By "please don't make any concrete proposals", you mean I shouldn't create a vote, right? Because, in my opinion, a vote right now would be pointless, but I believe we could still discuss what could be the CFI text to be edited, even if partially. I don't have time to do it right now, though. --Daniel Carrero (talk) 19:43, 13 October 2016 (UTC)

No, I mean we don't need to be looking at specific CFI text yet. Not until we have a thorough understanding of how the new system is going to work. How do you very that the 700+ hits are of the correct sense of the word? And that they actually are uses of the word? You need to check them all. --WikiTiki89 19:50, 13 October 2016 (UTC)

I don't see a huge difference between saying: 1) "Let's have a rule saying that professionally proofread text is required." (no CFI text proposed) and 2) "Let's add in CFI: Professionally proofread text is required." (CFI text proposed).

I take your point that Usenet is not editable.

About the 700+ hits thing, you are going to have to ask that to PB89. --Daniel Carrero (talk) 19:57, 13 October 2016 (UTC)

The difference is that it's an idea. It's not a whole proposal, it's only a part of the bigger picture. And it's also not necessarily a good idea, it's just an idea. It needs to be discussed first. Also, proposing the actual CFI change draws too much attention to the language, which distracts from the content itself. --WikiTiki89 20:02, 13 October 2016 (UTC)

Ok, I understand. --Daniel Carrero (talk) 20:05, 13 October 2016 (UTC)

Would it help to require six citations instead of the usual three when citing from the Internet? In other words, we'd count them as only having half the value of a citation from a published work (and thus you could use 1 quote from a book and 4 from the Internet to meet the requirements). That might decrease the possibility of typos and spelling errors being used in citations. Andrew Sheedy (talk) 01:23, 14 October 2016 (UTC)

Maybe, that seems worth discussing. Some of the limits discussed above still should apply, IMO. If someone writes "selfy" and later fixes it, (in a wiki or otherwise), as mentioned above, I don't think it would serve as a good citation for selfy, even if we require 6 citations.

I think CFI or a separate page should list in a comprehensive way what are the known durably archived sources, like this:

• Books
• Usenet
• Video games (which games? all of them?)
• Songs
• Google Scholar (I guess?)
• etc.

--Daniel Carrero (talk) 14:03, 14 October 2016 (UTC)

A quote from the man who created the Dead Media Project:

• 2001, Bruce Sterling, Digital Decay‎, retrieved February 7, 2012:
  Originally delivered as the keynote address for Preserving the Immaterial: A Conference on Variable Media at the Solomon R. Guggenheim Museum on March 30, 2001

  Bits have no archival medium. We haven't invented one yet. If you print something on acid-free paper with stable ink, and you put it in a dry dark closet, you can read it in two hundred years. We have no way to archive bits that we know will be readable in even fifty years. Tape demagnetizes. CDs delaminate. Networks go down.

-- DCDuring TALK 15:52, 16 October 2016 (UTC)

• Are most websites reasonably expected to fade away in a few decades? (some defunct hosting providers like Geocities and hpg.com.br come to mind, because naturally when they were disabled, websites hosted by them were disabled too) Archive.org looks reliable enough, ...there's always the threat that changes in a website's robots.txt will delete the archives of that specific website within Archive.org, but we could simply reject any citations if they can't be found on the archives anymore.

  I don't know what will happen in 200 years, but if by any chance the copyright laws remain the same, apparently all that remains of today's internet will be in the public domain, and future internet archivers should have more freedom to keep it if they want. (correct me if I'm wrong) --Daniel Carrero (talk) 20:51, 18 October 2016 (UTC)

As discussed above, these are some of the suggested rules. I hope I didn't forget anything important:

• Requiring 6 citations from the internet, instead of 3. (I'd probably oppose that as unnecessary. But it's okay if people want it.)
• A given citation needs to be publicly available in order to count. It can either link to the original page or to live archives. If no archives can be found anymore, the citation does not count anymore.
• We should probably have a separate page like WT:Requests for citation check if a given citation can't be found either on the original page or the internet archives anymore, to request people to keep searching before considering a citation invalid.
• If we are citing a text that was later edited to remove the cited word, then our citation is invalid because the author was probably fixing a mistake. This includes revisions of text in wikis.
• Only allowing citations if the author is known, either by the real name or by nickname. This is intended to weed out random memes and articles with unknown authorship. This should also weed out those fake quotations like "Wiktionary is awesome --Albert Einstein", in which the quoted author never actually said it. For wikis, we can probably use "contributors" and link to the history or something.
• New idea: Disallow any clickbait websites that require you to click "next >>" 14 times in order to view a full article. Reason: For a bit of quality, please. Cracked.com is fine, in my opinion. (Sorry, that's subjective and probably needs discussion. We may want to disallow Cracked.com if this rule is implemented.)
• Disallow any citations from ads. We don't want the entry delicious with a citation like "Eat a delicious Big Mac."

Rationale:

• With the popularity of the internet, there are terms that can't be found just in books and other durably-archived sources, so allowing citations from the internet would allow our coverage to be more complete. This probably includes some internet slang, text messaging slang and emoticons. I listed some Portuguese words above.

--Daniel Carrero (talk) 23:16, 20 October 2016 (UTC)

Planned, running, and recent votes

(see also: timeline, policy)

Ends	Title	Status/Votes
Dec 24	Word of the Year	11 18 2
Dec 27	Updating COALMINE rule	9 14 1
Jan 21	A few users for debureaucratization	3 4 1
(=3)		(=63)

Please let me know how many votes is a good maximum number of votes created by the same person at a given time.

Of the 12 "planned, running and active votes", I created 8. Actually, only 9 of those are actually active (because they already started and didn't end yet), of which I created 6... which is a little more than 1 vote per week.

"A little more than 1 vote per week" has been my actual rule of thumb for some time. --Daniel Carrero (talk) 19:34, 10 October 2016 (UTC)

I think it's also important to make sure votes are well-conceived. I would say that a lot of failed votes is a sign that something is wrong. A single failed vote isn't necessarily a problem but too many failed votes is just a waste of time on everyone's part. Benwing2 (talk) 19:38, 10 October 2016 (UTC)

Of my votes created in 2016, 18 fully passed, 6 at least partially passed and 14 failed. --Daniel Carrero (talk) 19:55, 10 October 2016 (UTC)

• Of clean, well-crafted votes that don't require midstream revision or additional provisos not strictly speaking part of the proposal, I'm sure that we could do one a week. If the votes were open for five weeks, we could be reasonably sure that the realistic potential population of voters would have a chance to consider the proposals, even if they only came by once a month. Some care should be taken to avoid having too many votes at times when contributors may not be available, eg, beginning of semester, summer vacation. DCDuring TALK 00:07, 12 October 2016 (UTC)

  Sure! I've been trying to learn from my mistakes, for example nowadays when I want to edit WT:EL, I prefer to propose a change to small portions of text at a time, because a vote trying to review whole large sections is usually very difficult to pass.

  Unfortunately, even after multiple people supported the creation of a vote, sometimes people bring up new problems after the vote has started. Usually, these votes would just fail, (but most of my 2016 votes have passed) which may result in a better votes in the future for the same things. I think it's OK when people edit ongoing votes to fix minor grammar mistakes, though.

  It seems that in practice, most BP discussions that are not about syllable categories are unlikely to get new answers after a week or so. By the second week, sometimes I feel the urge to think: "Well, consensus or not, this discussion is as good as it will ever be. It's over." I've been waiting some more time just in case, but when nobody comes, I secretly think: "I knew it!" --Daniel Carrero (talk) 15:37, 13 October 2016 (UTC)

  In general, others are not be as interested in a proposal that you make as you are, usually because the proposal solves no problem that they have. Also many problems that they do have may not get addressed until they create some technical problem, at which point they are addressed (not necessarily solved, sometimes replaced by worse problems or inconveniences) without a vote.

I don't think it's OK that "minor" grammatical mistakes are fixed on the fly. They should not occur. Each such "fix" may change the proposal substantively in unintended ways. Presumably many who read the proposal once would have to reread it to determine whether the change was in fact "minor". The result will be that few indeed will read the proposal until the proposal text becomes stable. That is why we have BP discussions. (Other fora are not acceptable substitutes IMO.) Having votes that are uninteresting, eg, trivial, and imperfectly drafted will lead to simplified voting heuristics, such as "Always vote no" or more selective versions. DCDuring TALK 21:22, 13 October 2016 (UTC)

• Most of my votes are to edit policies rather than solve technical problems. Maybe you could count proposals such as "install a new extension", "implement a new namespace shortcut" or "create a new user rights group" as technical problems, which clearly require votes. Most tech problems don't require votes.

  I think it's OK if a policy-edit vote is uninteresting. When I create BP discussions and suggest creating votes, I believe I have never heard this specific complaint: "Don't create it, it's uninteresting!" But I understand that it may be a reason for a certain vote to have a noticeably low turnout.

  If someone attempts to edit a vote that already started with the purpose of fixing a grammar mistake, I suggest you revert them if you want, but if multiple people prefer the revised version of that specific vote anyway, please cater to them. Grammar mistakes happen. If it's so serious, we can withdraw the vote and try again. --Daniel Carrero (talk) 19:19, 14 October 2016 (UTC)

  IMO generally, policy should be written when there is disagreement regarding de facto practice. It should be pruned regularly to reduce creep. Clarifying policy often leads to quibbles, and discussions about doing rather than doing, and (ime) discussions about discussions about doing. I would say votes are the last resort when something has stopped people from doing. So, uhm, 1 every year or two, if you must. - Amgine/ ^t·e 05:18, 1 November 2016 (UTC)

  I wish to keep discussing about the number of votes to reach an agreement. I do heartily agree with this: " should be pruned regularly to reduce creep." But sorry, I disagree with this: "policy should be written when there is disagreement regarding de facto practice". I believe policy should be also written to inform new users who are not aware of consensus.

  I believe 1 or 2 votes per year is really too low; why bother voting then? I've been focusing on suggesting updates to WT:EL: see this diff for changes in the last year. They require votes, otherwise anyone could edit the policy with abandon. Voted and approved policies are often solid policies. --Daniel Carrero (talk) 10:18, 1 November 2016 (UTC)

  When a new contributor is not able to discover how to do something, and therefore asks someone how to do it, and questions on doing that something happen often enough to disrupt the workflow, then maybe it needs to be documented. This is not the same as writing policy. - Amgine/ ^t·e 16:49, 1 November 2016 (UTC)

Are things like at ease and à gauche best categorized as adjectives, adverbs or prepositional phrases? There are tons of things in CAT:English prepositional phrases and a few in CAT:French prepositional phrases; many more putative prepositional phrases are found in CAT:French adverbs, for example. Where is the boundary to be drawn? Benwing2 (talk) 19:36, 10 October 2016 (UTC)

I don't know a thing about the traditions of French grammar or lexicography.

Putting prepositional phrases into the word classes adverb and adjective is not traditional, but neither is treating prepositional phrase the way we do. Most dictionaries have them as run-in entries where they do not require their own word class. Grammarians would say that prepositional phrases can be used as adverbs or adjectives, but would not put them in the corresponding word classes.

In principle, every English prepositional phrase is just that. Recategorization would just be a matter of replacing the categorizing inflection-line templates. Merging the Adverb and Adjective PoS headers would require rewording definitions one at a time. It's not the kind of thing that most of our contributors are capable of or interested in. One would probably get disagreement as to the desirability of even the category change. DCDuring TALK 09:28, 11 October 2016 (UTC)

I like prepositional phrase as it covers both. Renard Migrant (talk) 11:04, 11 October 2016 (UTC)

I would keep in mind that things that look like they're used as adjectives may not necessarily be adjectives. This is stronger in French with its postposed adjectives than in English with preposed adjectives. Compare, for example, "this house here" to "cette maison ici". "ici" looks exactly like an adjective in this position, but is it? Care should be taken when judging prepositional phrases to be adjectives this way. —CodeCat 17:49, 12 October 2016 (UTC)

A year ago, there was Wiktionary:Beer parlour/2015/September#Formatting proposal: always put cognates in a separate paragraph, which has majority support. I've been implementing this in entries ever since, but now User:Victar has started reverting me. I pointed him to the prior discussion, but he dismissed it, claiming that as he created the page he's entitled to choose how he wants to format it. This isn't true of course; there's no ownership of pages, anyone can edit anything, and decisions are made by consensus. Since this matter has no consensus and there's only two parties involved, there's two ways out: edit war into eternity or form a wider consensus. I'm choosing the latter option. So I'm asking now, how should the cognates be formatted: in their own paragraph or not? —CodeCat 17:37, 12 October 2016 (UTC)

Your proposal was simply that, a proposal. It was not ratified as formatting guideline, and as such, it shouldn't be enforced with the same blind vigor. If we're simply talking about a matter of personal preference, which it is, than I have the right to have my own, and yes, I think especially as the creator of the entry. I strongly believe that creating separate lines for cognates unnecessarily pushes down the whole of the content. --Victar (talk) 17:51, 12 October 2016 (UTC)

Indeed, in that discussion it seems that a large portion of people expressed the opinion that having cognates in a separate paragraph should be an option, especially when the Etymology section is big, but not a requirement. If I had contributed to the discussion, that's probably what I would have said, too. —Aɴɢʀ (talk) 18:48, 12 October 2016 (UTC)

Can someone please protect this page? There's a bunch of Czechs who seem to think it's ok to ignore Wiktionary's descriptivist approach and repeatedly inserting all kinds of POV appeals to authority. There's also some warring on the talk page because one of them posted in Czech, which is inappropriate for a discussion on the English Wiktionary. —CodeCat 19:12, 12 October 2016 (UTC)

I don't have the time to check that entry right now, but I see some kind of edit war ongoing. Please someone review that. I added "autoconfirmed" protection. Is it OK or does it need admin-level protection? Also, someone pretty please give CodeCat's admin rights back, thanks. --Daniel Carrero (talk) 19:21, 12 October 2016 (UTC)

It needs admin protection, they just did another edit. —CodeCat 19:25, 12 October 2016 (UTC)

Weird. That person who edited the entry now is not even autoconfirmed. --Daniel Carrero (talk) 19:28, 12 October 2016 (UTC)

@Daniel Carrero Well can you do it please? They're still at it. —CodeCat 22:47, 12 October 2016 (UTC)

 Done --Daniel Carrero (talk) 22:50, 12 October 2016 (UTC)

Thank you! —CodeCat 22:53, 12 October 2016 (UTC)

@Daniel Carrero or anyone else: can you also protect dceřinná společnost and vyjímka? It's the same issue, they've just started messing with other pages instead. —CodeCat 23:24, 12 October 2016 (UTC)

For future reference: note in particular the edit history of these three entries. They consist almost entirely, from the moment Dan Polansky created them, of some editor changing it to "misspelling" and/or adding "incorrect" POV notes, and then various more experienced editors putting it back. —CodeCat 23:27, 12 October 2016 (UTC)

 Done. Again, I'm just trusting you on these ones, because I don't speak Czech. If others want to review my page protections, I welcome them. --Daniel Carrero (talk) 23:30, 12 October 2016 (UTC)

I don't speak Czech either, but their edits and arguments seem like just an appeal to authority to me, ignoring Wiktionary's descriptive nature. I trust Dan's judgement more than any of theirs, since he's a native speaker and a knowledgeable Wiktionary editor. Another Czech editor has now provided further statistics to show that tchýně is widely used. —CodeCat 23:33, 12 October 2016 (UTC)

I understand. Yes, I see your point and I think you're right. I see that now you asked Dan Polansky to weigh in on Talk:tchýně, which is good. --Daniel Carrero (talk) 23:35, 12 October 2016 (UTC)

Well, it would have been polite, if you (plural):

1. pinged us in this talk, so we could react here
2. pointed us to relevant descriptive pages explaining what is considered "descriptive"
3. would not consider and (indirectly) call us less experienced, considering the fact that some of us are in wikiverse longer than you
4. started the discussion instead of blind reverting without even stating the reasons which obviously led to the reverting and it didn't have to if clear explanation was provided
5. followed the way how to make a consensus

Very impolite behavior of you to de facto here-newcomers, shame on you, this is not how users should be treated.

You have a chance to remedy at least the second and fourth point now though...

@CodeCat: I don't think it is OK to ignore any rule as long as I know it. So it is heavily unfair what you have written in the second sentence of your opening post in this section, because none of you bothered to point us to such rule (as I've mentioned above). Not even speaking that none of you followed the consensus making process, so as we say in Czech "sweep in front of your doorstep first".

Anyway, this whole situation is obviously one big misunderstanding mostly because of lack of the communication (fortiori proper) from the local folks towards us. I can not obviously speak on behalf of other involved Czechs, but I'm pretty sure they would like me prefer the discussion instead of dragging the rope there and back.

So it would be constructive if you (plural) at first explained and described reasons why you (plural) keep putting "alternative spelling" instead of "misspelling" in those entries. (And no, simple wordcount statistics is not a reason.) Instead you should for the beginning at least clearly describe these two terms, so we could move forward.

PS: Please also mind the "lost-in-translation" factor, which may be a big stakeholder here.

— Danny B. 01:43, 13 October 2016 (UTC)

Actually simple word count is a reason. Descriptive linguistics is all about describing language as it is used, not as people think it should be used.--Prosfilaes (talk) 12:33, 13 October 2016 (UTC)

Maybe we don't understand whot is meaned by alternative spelling. For me is alternative situation when I should use e.g. both encyclopaedia or encyclopedia in written text. But this is not this case, when I use tchýně in czech text, it will be considered as mistake. When I use it in the school, I got worse mark.

We provided sources from university, from linguistic-oriented blogs, from newspaper etc, but because this error is very common, is this more than sources? OK, if i aply the same for inglish, i shuld writ as i hear and it wil be only altenative speling. JAn Dudík (talk) 18:19, 13 October 2016 (UTC)

That's what the usage note is for. Also, I added the tag "proscribed", perhaps no one will object to that? --WikiTiki89 18:21, 13 October 2016 (UTC)

On the talk page, I suggested using {{nonstandard spelling of}}, but no one's responded to that suggestion yet. —Aɴɢʀ (talk) 18:42, 13 October 2016 (UTC)

I object to both proscribed and nonstandard; for more, see Talk:tchýně. google:"tchýně" shows how incredibly widespread this form is. The usage note in tchýně covers the matter, upholding descriptivists standards while at the same time accurately reporting the absence from Pravidla ("Rules") for those who find that fact relevant. --Dan Polansky (talk) 13:05, 15 October 2016 (UTC)

If you only count the Czech speakers involved, it is largely one me against multiple others. This is probably because Czechs are brought up in a prescriptivist language culture. Many Czechs seem to think that if a spelling is absent from a regulatory list of approved forms, then it is "incorrect". That is one reason why the idea that consensus should only be made by the natives of a particular language leads to poor results. Instead, my position is that consensus is to be sought among all eligible English Wiktionary editors, whether they know any Czech or not. Since even English, Dutch and Portuguese editors with no knowledge of Czech can distinguish prescriptivism from descriptivism. --Dan Polansky (talk) 13:15, 15 October 2016 (UTC)

@Dan Polansky: What do you think "proscribed" means? It means that many Czechs think it's wrong. --WikiTiki89 15:46, 17 October 2016 (UTC)

Wiktionary:Glossary#P does not tell me what "proscribed" means. As far as I am concerned, "proscribed" label could be removed Wiktionary; it is suggestive of prescriptivism. Is there any English dictionary that uses the label? --Dan Polansky (talk) 17:30, 17 October 2016 (UTC)

What about going to Wikipedia and labeling W:Homosexuality article with "proscribed" box, meaning "many Americans think it is wrong"? Makes sense? --Dan Polansky (talk) 17:32, 17 October 2016 (UTC)

We are describing the fact that prescriptivism exists in Czech. --WikiTiki89 18:05, 17 October 2016 (UTC)

Agreed? Homosexuality should get a nice red box "proscribed" in Wikipedia to indicate that anti-homosexualism exists in the U.S.? --Dan Polansky (talk) 18:13, 17 October 2016 (UTC)

That's not Wikipedia's style. Anti-homosexualism is discussed in the entry (or should be, I haven't checked). --WikiTiki89 18:18, 17 October 2016 (UTC)

I don't see why it should be our style. In tchýně, I have used the usage note to indicate the term is not on the approved word list; the information is there. That is analogous to Wikipedia having no prominent box "proscribed".

Let me quote Ruakh from Template talk:proscribed: 'The problem with labeling a sense as "proscribed" is that, as Metaknowledge implies, it makes it sound like we are proscribing it. I prefer to write "sometimes proscribed" or "often proscribed", which I think makes it a bit clearer that we're talking about other people's proscriptions. And probably "condemned" or "criticized" would be better than "proscribed". —RuakhTALK 19:42, 13 September 2012 (UTC)'

I agree with Ruakh: it sounds like we are proscribing it. And we the dictionary are not proscribing anything. Given the current circumstances, I support deprecation of label "proscribed". --Dan Polansky (talk) 18:21, 17 October 2016 (UTC)

I agree with Ruakh as well, and if you had asked me to change it to "often proscribed", I would have done so. But I don't think it should be removed. Tags like this are already our style, it's no different from a "(dated)" tag. Why doesn't Wikipedia need to put a big red box at the top of w:Floppy disk saying "Dated"? --WikiTiki89 18:40, 17 October 2016 (UTC)

It is different from dated in that there is nothing prescriptivist about dated or archaic. Put differently, label dated is not an imperative in disguise. The whole disagreement is not about provision of information since, again, I stated in the usage note that the spelling is absent from the mighty uberlist, but rather about the prominence and tone of the labeling. In any case, "often prosribed" would do a bit to alleviate my anti-prescriptivist concern.

Furthermore, since German zumindestens is actually being proscribed by language teachers, should it be marked as "often proscribed"? Should all vulgar terms also be labeled "often proscribed", since they indeed are often proscribed? And since ain't is often proscribed, shall it be so labeled? You have to clarify how far do you intent to spread the badge of shame that is "proscribed". --Dan Polansky (talk) 18:52, 17 October 2016 (UTC)

I think labels such as "colloquial", "vulgar", and "slang" already imply that it is proscribed. There is no reason not to have both the tag and the usage note. For some dated terms as well, we tag them as dated and also include a usage note specifying when it was used. --WikiTiki89 18:58, 17 October 2016 (UTC)

Assuming the above, which I don't but anyway: then why not use the the definition line "informal form of" or "colloquial form of" and be done with it? --Dan Polansky (talk) 19:05, 17 October 2016 (UTC)

Do those actually apply to this word? --WikiTiki89 19:35, 17 October 2016 (UTC)

They seem to: tchýně is how people very often pronounce the word, whereas tchyně is on the uberlist of the continental regulators. "tchýně" is how people very often write the word when not subjected to the rigor of zealous copyeditors; this is probably so because Czech has a rather phonetic spelling and "tchýně" matches the pronunciation. The other Czechs have to be "on guard" when writing lest they commit an "error".

Now, I cannot prove that people very often pronounce the word as "tchýně". I can only demonstrate that conspicuously many "tchýně" make it into printed works in Google books and to the world wide web, compared to "tchyně". --Dan Polansky (talk) 19:48, 17 October 2016 (UTC)

But anyway, "often proscribed" is so much better than "proscribed". Until we get "proscribed" removed entirely from the dictionary and become fully descriptivist again, it is okay, I guess. --Dan Polansky (talk) 20:00, 17 October 2016 (UTC)

I don't think the word "colloquial" can apply to alternative spellings. And to me, an "informal" spelling is something like thru. --WikiTiki89 20:07, 17 October 2016 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Elsewhere, I proposed to use informal and discontinue colloquial, so I am certainly okay with informal. "thru" seems much more informal to me than "tchýně", but I am no native English speaker. Interestingly, M-W's thru does not seem to say "informal" or "non-standard". --Dan Polansky (talk) 20:15, 17 October 2016 (UTC)

I clicked on the link to this article given in the entry you linked to, which has some interesting information. Based on that, I assume that they don't mark it as informal because thru was technically attested before through. However, at the end of the article it says: "All that said, thru is still considered an informal variant of through, despite its history and the AP's limited approval." --WikiTiki89 20:37, 17 October 2016 (UTC)

Very interesting link; thank you. I wonder why they do not mark "thru" informal straight away. Be it as it may, they do not mark "thru" non-standard or "often proscribed", right? Does any dictionary do that for thru? And then, what do schoolteachers think of thru?

I would love to follow the model of the modern Anglo-American lexicography and mark "tchýně" as "informal form of" or the like. --Dan Polansky (talk) 20:45, 17 October 2016 (UTC)

But I'm not sure that thru has an equivalent usage pattern to tchýně. Most people when they write thru recognize that it "should" be spelled through but choose to ignore that fact for whatever reason (space limitations, laziness, stylistic considerations, etc.). I would think that most people who use tchýně do it either by without knowing that tchyně is the more widely accepted spelling, or simply by mistake without thinking about it, or perhaps because they are insistent on spelling words phonetically. Am I correct about that? --WikiTiki89 20:54, 17 October 2016 (UTC)

I don't know see any meaningful distinction above. Again, "thru" does not seem any less informal than "tchýně"; indeeed, the article you linked above mentioned that, when drive-thru was proposed to be placed on signs, at "an editor's conference in 2014, there was an audible gasp in the room when this was mentioned : the decline of English in action!". If thru signifies the decline of English to many and still can be labeled informal rather than often proscribed, I don't see any evidence to suggest that tchýně should be "often proscribed". It is better than "proscribed" but I disagree with it, find it prescriptivist, and hope it will be gone. If I could edit tchýně, I would remove "often proscribed", thereby returning the entry to the status quo ante. I am thinking about trying my luck and getting rid of "proscribed" altogether from Wiktionary, but do not see too good chances: descriptivism is very fragile and I actually found it surprising that it was upheld so well until now. --Dan Polansky (talk) 21:13, 17 October 2016 (UTC)

Are there any entries at all that need "proscribed" as a label before the definition? I agree with Dan Polansky's reasoning that this label is an imperative in disguise, and it indicates that we, the English Wiktionary, are proscribing a word or a sense.

For example, in my experience as native speaker of Portuguese from São Paulo, Brazil, basically everyone writes mozzarella as mussarela, (there are pizzerias everywhere selling pizza de mussarela, and markets sell slices of queijo mussarela by the kilogram). But one source online states that both Aurélio and Houaiss (two important dictionaries) use muçarela. This is because of a prescriptivist rule stating that words borrowed from other languages and then adapted to our orthography always use "ç", not "ss" in the middle of a word. I wouldn't want to add "proscribed" at the beginning of mussarela, because it would seem like we are prescribing it. --Daniel Carrero (talk) 12:47, 18 October 2016 (UTC)

canonize/canonise is a typical example of -ise/-ize definitions being assigned to one entry and not duplicated over both. Given that one entry has to be chosen, by whatever method, to host the definitions, the treatment should otherwise be as symmetrical as possible. Presently this is not the case. While canonise is labelled "UK" or "British", no label is anywhere attached to canonize, giving the impression that canonise is a deviation from the norm. What is the best way to redress this -- given, as I say, that it is accepted that only one of the entries, in this case canonize, can host the definitions? Mihia (talk) 20:10, 12 October 2016 (UTC)

In actual practice, spellings like canonize are hardly used in British English, except by non-natives and American companies such as GM and Ford I suspect. DonnanZ (talk) 16:08, 13 October 2016 (UTC)

I agree, and I am aware of that, but the question is how best to indicate this in the entry for, say, canonize. In practical layout terms, where does the "US" label go? Mihia (talk) 17:43, 13 October 2016 (UTC)

Some British publishers do use the -ize spellings, notably the Oxford University Press, which is why British spelling using the -ize variants is known as Oxford spelling. It shouldn't be labeled simply as "US" (the way center or color should be) but should be labeled {{lb|en|US|Oxford}} or the like. —Aɴɢʀ (talk) 17:49, 13 October 2016 (UTC)

OK, but where should the label go? Mihia (talk) 19:19, 13 October 2016 (UTC)

I think having usage notes on every -ise/-ize verb would get pretty tedious. Can this be managed through context labels alone? Renard Migrant (talk) 19:28, 13 October 2016 (UTC)

I think so. I'd say the actual definition should be at only entry, and the other entry should be marked as an alternative spelling, with the appropriate context labels. The problem is which entry to make the primary one. In the past, some have suggested using Google Books Ngrams to see which is more common across English as a whole (i.e. without specifying en-US or en-GB); in this case, that would be canonize. But I don't know whether there's a consensus to use that method. —Aɴɢʀ (talk) 19:48, 13 October 2016 (UTC)

Which entry to make the primary one may be another problem, but it is not one that I am concerned about here. All I am concerned about in this thread is practically how to label the "primary" entry (the one hosting the definitions), to show that it is US, UK, or whatever. Mihia (talk) 20:57, 13 October 2016 (UTC)

-ize spellings can be labeled {{lb|en|US|Oxford}} and -ise spellings can be labeled {{lb|en|non-Oxford}}. The form called the alternative spelling can use a from= parameter instead of {{lb}}, like this. —Aɴɢʀ (talk) 21:23, 13 October 2016 (UTC)

I see ... you have just put the label against every definition at canonize. I do not personally feel that this is a very satisfactory solution (in fact, I had more or less discounted it, as I suppose I should have made clear). I suppose it may be tolerable with just three definitions, but if you look at an entry like color/colour (let's assume it is agreed to merge the definitions, and not get into that debate specifically here), it would be tremendously tedious to have to repeat the national labels against every definition, along with the various other labels on top. I was looking for a neater solution. Mihia (talk) 22:12, 13 October 2016 (UTC)

Just noticed (don't know why I didn't notice before) that "colour" and "color" actually put the national labels just once, next to the headword. Perhaps that is the way to go ... Mihia (talk) 22:16, 13 October 2016 (UTC)

That's {{term-label}}. —CodeCat 22:18, 13 October 2016 (UTC)

OK, thanks, I changed it to use "term-label". I think that is better, unless anyone has any other suggestions about how to handle this ... Mihia (talk) 22:30, 13 October 2016 (UTC)

I wasn't aware of {{term-label}}. That is a good idea. —Aɴɢʀ (talk) 19:51, 14 October 2016 (UTC)

Sometimes, when I propose a new thing, it's something that I've been thinking for years. This is one of those times.

Proposal #1: Redirect many separate single character codepoints that basically mean the same thing. I believe it would be useful to create an exact, comprehensive list of the group of characters affected, if possible. I mean hard redirects, the ones that use #REDIRECT.

Proposal #2: For every redirected character, add {{character info/new}} in the main entry with the codepoints of all redirected characters. (or maybe another template if there are too many redirects for a single entry)

Here's a partial list. This assumes that all characters (including emojis bellow) are attestable. These are all the examples I could remember for now. Please add more if you remember any, discuss if you want, etc. (there are no Han characters in this list, apparently we prefer soft redirects for the traditional/simplified variants at least)

1. redirect (when possible) all specialized Roman numeral characters
   • Ⅲ → III
2. redirect all fullwidth and halfwidth letters and symbols (I started a discussed recently about it here)
   • Ｘ → X
   • ＄ → $
   • ￤ → ¦
   • ﾃ → テ
   • ﾢ → ㄲ
3. redirect all subscript and superscript characters
   • ₖ → k
   • ⁶ → 6
4. redirect all small caps characters (except when they have a separate meaning in IPA or something, like ᴀ)
   • ꜱ → S
5. redirect all combining characters when possible (already voted and approved here in 2011)
   • (combining acute accent) → ´
6. redirect single-character digraphs (already voted and approved here in 2011)
   • DŽ → DŽ
7. redirect single-characters that stand for multiple punctuation marks
   • ‼ (double exclamation) → !!
8. redirect some specific characters for units of measurement
   • ℃ → °C (or maybe soft redirect into both ° and C)
   • µ ("micro-" sign) → μ (small mu) (it seems the "micro-" sign is used a lot in our entries, though)
   • K (Kelvin) → K (the sofware already redirects this one automatically, it appears)
9. some random spaces like "EM SPACE" and "THREE-PER-EM SPACE" appear to be impossible to use in page titles, but they at least should probably have character boxes in Unsupported titles/Space, in my opinion
10. redirect Arabic presentation forms, I guess (I don't even speak Arabic, ignore if blatantly wrong)
    • ﺏ, ـب, ـبـ, بـ (EDIT: I don't know how to write this, but ب should be the main entry, I believe)
11. concerning w:Hangul Compatibility Jamo and w:Hangul Jamo (Unicode block), redirect one to the other, I suppose
    • ᄊ, ᆻ → ㅆ (we are already redirecting from normal to compatibility entries? shouldn't it be the other way around?)
12. it may be just me, but I'm not too happy with the small katakana word boxes -- I would redirect them and add {{character info/new}} to the full word entries
    • ㌒ → キュリー
13. redirect all pieces and components of single characters
    • ⎛, ⎞, ⎜, ⎟, ⎝, ⎠ (parentheses pieces) → ( ) (although these could redirect to either ( or ) I guess -- the ( ) feels more like the "main entry" to me)
14. redirect all "ornament" versions of other characters
    • ❨, ❩ → ( ) (see comment in the item above)
15. redirect all vertical writing versions of other characters
    • ⏜, ⏝ (vertical parentheses) → ( ) (see comment two items above)
16. redirect all fancy typography
    • ❣ (heart-shaped exclamation mark) → !
17. redirect all emojis that basically are the same thing
    • ⏳ (hourglass with flowing sand) → ⌛ (hourglass)
18. specifically, redirect emojis that mean the same thing but differ in color
    • 💜, 💛, 💚 (fancy colored hearts) → ♥
19. specifically, redirect emojis that are basically the same expression of emotion
    • 😭 (LOUDLY crying) → 😢 (crying)
    • 😙 (kissing face with smiling eyes) → 😗 (kissing face)
    • see the huge list from Unicode (link) for yourself, let me know if there are any problems with this one
20. redirect characters and emojis that mean the same thing but are arbitrarily rotated or inverted with no additional meaning
    • ⦰ (reversed empty set) → Ø (unless the reversed one has any actual, separate meaning)
    • ⌐ (reversed not sign) → ¬ (unless the reversed one has any actual, separate meaning)
    • ⛉ → ☖ (white shogi piece)

Also, I think we should SOFT redirect these, because they are basically SOP and consist of multiple entries:

1. number + period
   • ⒈ → 1 + .
   • ⒉ → 2 + .
2. number + comma
   • 🄂 → 1 + ,
3. number + parentheses
   • ⑴ → 1 + ( )
4. letter + circle (...which sounds controversial, because the circle is just a typography thing; well, some like Ⓣ do have a separate, attestable meaning)
   • Ⓑ → B + ○ (alternative idea: redirect Ⓑ → B as a single character)
5. number + circle
   • ① → 1 + ○ (alternative idea: redirect ① → 1 as a single character)
6. random fractions... my point is: in my opinion, we don't need entries for random fractions
   • ½ → 1, /, 2

--Daniel Carrero (talk) 20:48, 12 October 2016 (UTC)

Support these sorts of redirects for anything where there is no distinction made when writing by hand as opposed to using Unicode (meaning that I'm hesitant to support #10, though I don't oppose it either). I'm not sure I support #19, at least for common emojis, due to the fact that some have slightly different connotations even if they are very similar. It would be very helpful, BTW, to include the list of all variations of an emoji in all entries for them, just as that page you link to does, since the way they are perceived can change depending on what version is used. Andrew Sheedy (talk) 01:58, 13 October 2016 (UTC)

Apparently, the separate "start", "end", etc. Arabic letter varieties only exist for compatibility purposes, for this reason I'm under the impression that these redirects would be fine. (correct me if I'm wrong)

If people want to keep a separate entry for each emoji, that could probably work, too. But there are just too many for the same things, in my opinion. --Daniel Carrero (talk) 18:32, 13 October 2016 (UTC)

I oppose the systematic creation of redirects. --WikiTiki89 15:23, 13 October 2016 (UTC)

I'm thinking of creating a vote for a new page called WT:Single-character redirects and starting with only the ones about Latin script letters and punctuation, then adding the others later if other people agree. We can link CFI to the new page. The specific redirecting rules that were already voted and approved in Wiktionary:Votes/2011-06/Redirecting combining characters and Wiktionary:Votes/2011-07/Redirecting single-character digraphs can be kept in the new page. --Daniel Carrero (talk) 18:32, 13 October 2016 (UTC)

One thing I wish to add: If we find 3 citations with "!!", are we citing the codepoint "DOUBLE EXCLAMATION MARK" ("‼") or two exclamation marks together ("!!")? I agree with Andrew Sheedy's remark about "these sorts of redirects for anything where there is no distinction made when writing by hand as opposed to using Unicode". When the distinction only exists in the text encoding as opposed to being an actual linguistic distinction, I believe it's a good idea to create redirects.

In my opinion, having a separate entry for Ａ (fullwidth A) is like having another entry for italic A, other for boldface A, other for sans-serif A, etc.

In my opinion, having a separate entry for 🄐 does not make a lot of sense either, because it's basically a SOP of A and ( ). 🄐 is an entry whose meaning can be perfectly understood from the sum of its parts, and it appears to currently exist only because Unicode has a codepoint for it. --Daniel Carrero (talk) 19:03, 14 October 2016 (UTC)

‼ should be treated like ligatures such as fi. In fact, I don't even think we should have entries for them at all. --WikiTiki89 21:03, 14 October 2016 (UTC)

If my proposal of creating certain redirects as described above passes, then the single-character ‼ can be redirected to !!, but if the latter should not exist, then the redirect could point to !. Per WT:CFI#Repetions, we are able to have a lot entries with repeated letters like suuure, so for consistency I believe it makes sense to create a few entries for repeated punctuation marks like !! and !!!. --Daniel Carrero (talk) 21:51, 14 October 2016 (UTC)

Minor comment: if you'd like to save smallcaps that mean something specific in phonetic transcription (#4), that logic immediately axes the redirecting of superscript letters (#3), which are regularly used in phonetic transcription for "overshort" sounds, such as the release of an affricate or a diphthong. (I'm also not sure how many smallcaps that aren't used in phonetic transcription there are, but it's not many.) --Tropylium (talk) 01:47, 16 October 2016 (UTC) 

Thank you for the comment. Yes, I support keeping separate entries for all superscript letters that have a separate meaning. Apparently, some superscript numbers like ¹ and ² already have separate meanings and thus merit separate entries under that logic.

But, I would suggest converting the entry ³ into a redirect. The 1st definition is "superscript three", which is not a semantic, meaningful definition, it just describes the typography of the glyph. The 2nd definition is "cubed", whose meaning is taken from 3 + Appendix:Superscript. Any superscript number (or letter) is cubed, so it's not a special meaning of "3". In my opinion, having an entry ³ meaning cubed is like having an entry ×3 meaning "times 3". --Daniel Carrero (talk) 03:22, 16 October 2016 (UTC)

To suggest implementing the point #2 of this proposal, I created Wiktionary:Votes/2016-10/Redirect fullwidth and halfwidth characters. --Daniel Carrero (talk) 13:39, 21 October 2016 (UTC)

Does anyone object to adding this into the category hierarchy? Perhaps someone can think of a better wording? I mean it to house "___ terms coined by _____" categories ( so far only Latvian has such categories, but I'm thinking of making a {{coined by}} template to automate such a categorization ) together with "___ terms coined in the Simpsons/the Economist/Usenet" or whatever else we feel the need to categorize. Thoughts? Crom daba (talk) 13:41, 14 October 2016 (UTC)

Excellent idea! That said, I would limit the categories for individual coiners to a predefined list of people and add the rest to a catch-all category, otherwise we will end up with a lot of terms coined by _____ categories with only one or two terms. — Ungoliant ^(falai) 12:07, 18 October 2016 (UTC)

This edit has the desired visible effect. Please advise whether it is the correct use of templates, or whether the result ought to be accomplished in some other way. Mihia (talk) 21:05, 14 October 2016 (UTC)

I think {{term-label}} is meant to be used after the headword. For alternative forms, we actually have a dedicated template {{alter}}. --WikiTiki89 21:09, 14 October 2016 (UTC)

Thanks, {{alter}} does not specially understand the parameter "non-Oxford" or do the links or the brackets. I can almost replicate the "term-label" results like this, but I'm not sure if this may be more of an abuse of templates than just using "term-label". Also, the brackets come out in italics which they strictly shouldn't. Mihia (talk) 10:45, 15 October 2016 (UTC)

We could create Module:en:Dialects and create abbreviations for {{alter}} to recognize, the way Module:hy:Dialects and Module:grc:Dialects do for those languages. Otherwise, I'd just use {{q|non-Oxford British English}}; that way the parentheses aren't italicized but the contents are. —Aɴɢʀ (talk) 11:02, 15 October 2016 (UTC)

OK, thanks, I plan to use canonise/canonize as a model for definition-merged -ise/-ize entries, in terms of layout and labelling, so if there's anything you or anyone else finds unsatisfactory about the way those entries are currently set out, please say. Mihia (talk) 12:46, 15 October 2016 (UTC)

@Angr: I was recently surprised by the fact that there isn't a module for English dialects yet! I think I'll start it. — Eru·tuon 02:46, 16 October 2016 (UTC)

@Erutuon: That's fine, but wouldn't it be better to have {{alter}} call on the same dialect list that {{lb}} and {{alternative form of|from=}} already call on, i.e. Module:labels/data/regional? It seems redundant to have two lists. —Aɴɢʀ (talk) 07:27, 16 October 2016 (UTC)

@Angr: The same could be said about Module:grc:Dialects: I have added some Greek dialect labels from there to Module:labels/data/regional. I agree that it's redundant, but I'm not sure how to solve the problem. — Eru·tuon 18:09, 16 October 2016 (UTC)

@Erutuon: Couldn't {{alter}} be rewritten to use Module:labels/data/regional instead of, or in addition to, Module:XXX:Dialects? —Aɴɢʀ (talk) 09:16, 18 October 2016 (UTC)

@Mihia: I added Oxford to Module:en:Dialects, but wasn't sure what Wikipedia article to link to for non-Oxford. If you'd like to add that label, go ahead. — Eru·tuon 03:02, 16 October 2016 (UTC)

@Erutuon:. Thanks. I believe that "non-Oxford" should link to https://en.wikipedia.orghttps://dictious.com/en/Oxford_spelling. I don't understand in practice how what you have done affects the entries canonise or canonize. I would be grateful if you could explain exactly what needs to change in those articles to take advantage of it, or make the edit yourself if you prefer. Mihia (talk) 20:39, 16 October 2016 (UTC)

@Mihia: The labels in Module:en:Dialects can be used in the template {{alter}}, by adding a blank parameter after the word, and then adding the label in the next parameter (or multiple labels, one per parameter). I did that at canonize. — Eru·tuon 20:49, 16 October 2016 (UTC)

@Erutuon: I see, thanks. Would it be possible to change the text to read Non-Oxford British English, to be consistent with other templates, and also to put this label in brackets? In other words, for the appearance of the whole thing to be like the version here? Mihia (talk) 21:01, 16 October 2016 (UTC)

@Mihia: Yes. Go ahead and edit the display part of the data label in the en:Dialects module. That will change the link text for the label. — Eru·tuon 21:04, 16 October 2016 (UTC)

Ooops, I'm not sure about the brackets part. That falls into the realm of the {{alter}} template and Alternative forms module. I think brackets are not used because for Ancient Greek and other languages that are transliterated, this would result in two consecutive parentheses – for instance, ὄνῠμᾰ (ónuma) (Aeolic, Doric) – which is ugly. There may be a solution, but it would be more complicated... — Eru·tuon 21:09, 16 October 2016 (UTC)

As Erutuon has pointed out, there is another long-standing request for brackets at Template talk:alter. Anyone fancy doing this? It is beyond my skill level. Mihia (talk) 19:33, 18 October 2016 (UTC)

@Mihia: I finally got familiar enough with Lua to fix the problem. See Template talk:alter (I pinged you there too). — Eru·tuon 23:03, 26 January 2017 (UTC)

@Erutuon: Thank you! Mihia (talk) 23:15, 26 January 2017 (UTC)

Some time ago, User:DCDuring suggested that an |i= parameter be added to these templates so links to taxonomic names could be italicized according to standard practice for such names. That was never done, but he started adding it to the wikitext in entries in anticipation of someone getting around to doing it eventually. This wasn't a problem, though, since templates ignore undefined parameters. Then User:CodeCat decided to convert these templates to use a Lua module. Even that would be fine, since Lua adds useful capabilities that can be exploited later. She also incorporated Module:parameters, which lets you specify which parameters can be used in a template. That's where things went off the rails. Aside from maybe half a dozen unrelated errors, all of the 462 entries currently in Category:Pages with module errors are due to the previously-ignored |i= parameter.

CodeCat had said that the luafied versions would work exactly like the un-luafied versions to start with. I don't know about you, but 450+ module errors seems like a big difference to me. It's not that Module:parameters is inherently evil, but in this case I would suggest it's been misused. Sure, I found a small number of typos that needed to be fixed, but that could have been done without breaking over 450 entries.

As I see it, we have four main options, in order of ease of implementation:

1. Do nothing. Not recommended, because this has replaced links to Wikipedia, Wikispecies and Commons with alarming red error messages in close to 460 entries, and it's hard to spot real errors among the three pages of these errors.
2. Change the templates to have Module:parameters ignore the |i= parameter
3. Implement the |i= parameter. That's what I would recommend, because the codes governing taxonomic names explicitly say that at least genera and species should be italicized, and the system overhead is negligible.
4. Remove the |i= parameter from all 450+ entries. Why? They were added in good faith and could serve a useful purpose.
5. Pork. Sorry, I just wanted to see if anyone was paying attention.

What would everyone prefer? Chuck Entz (talk) 01:14, 15 October 2016 (UTC)

Option 3 sounds like the best to me too. If there's some kind of obstacle to option 3, then option 2 seems like an acceptable temporary fix. —Mr. Granger (talk • contribs) 01:25, 15 October 2016 (UTC)

• I for one am willing to go for the pork option, if pork is a misspelling of fork. That would mean substituting a non-Lua template for {{pedia}}, {{specieslite}}, and {{comcatlite}} that supported italics in those entries that needed it, genus and subgeneric entries. At some future date we could add the ability to de-italicize portions of the taxa that should not be italicized like "subsp.", "subg.", "var.", etc. I am fairly sure that CodeCat will never work on that feature, having bigger fish to fry. I don't like my fish fried anyway; it's bad for my heart. DCDuring TALK 02:02, 15 October 2016 (UTC)

I did option 2 (it's a trivial line of code), I tried doing option 3 but I think it better that someone who knows what he/she's doing handle it properly. Crom daba (talk) 02:50, 15 October 2016 (UTC)

@Crom daba: I looked at the code for Module:wikipedia, and then at Module:links, and finally at Module:script utilities. Those are the modules that it uses to create links to Wikipedia. Apparently italics and bold are not supported (see § tag_text), so there is no way to make the links to Wikipedia articles on species names be italicized without removing boldface. That's quite irritating... — Eru·tuon 02:05, 16 October 2016 (UTC)

Those modules are of "our" own creation. The lack of functionality is a self-inflicted wound. DCDuring TALK 15:29, 16 October 2016 (UTC)

Thanks to @CodeCat:, the change has been made. A look at ] will show another class of interproject links that make a fork of the templates worth considering. A WP entry like w:Argentina (plant) or a commons link like [[commons:Category:Argentina (Rosaceae)}} have mixed character formatting. They should be Argentina (plant) and Argentina (Rosaceae) respectively. In general the taxonomic authorities prescribe that only a genus and subgeneric names and epithets should appear in italics in text.

They also prescribe that such items should appear in ordinary typeface when embedded in italic running text, so templates that force italics or regular text force the appearance of such taxa to deviate from the prescription. We might not care about prescriptions, but these prescriptions usually followed in scholarly works and often in popular science and nature books. DCDuring TALK 18:11, 18 October 2016 (UTC)

I created a function to apply correct italics to species, subspecies, and variety names on Wikipedia (in w:Module:eFloras, which is used in a reference template). A similar thing could be created here – though the parameter that triggers it would have to have a name besides |i= (|genus=, |subspecies=, etc. or something else?). It could detect the abbreviations subsp., ssp., var., and f., and words in parentheses, all of which should not be italicized, and then apply italics to everything but them. Either that, or we manually enter link text with correct italics in every case. Thus, it would take Cupressus arizonica var. glabra and display it as Cupressus arizonica var. glabra, and the previously mentioned Argentina (plant) would display correctly as Argentina (plant). The parameter |i= could still be used in cases where the whole title should be italicized. — Eru·tuon 19:55, 18 October 2016 (UTC)

Cool. That's exactly the kind of thing I was hoping for. Some questions remain in my mind:

1. Is it worthwhile to attempt to provide for a piped alternative formatting for whatever cases that the logic you have implemented on WP doesn't cover every situation we find? Have you found any exceptions at WP?
2. We might discover other taxon elements that should not be italicized, eg, "morph.", perhaps "×". Would this be updateable by altering data in a Module?
3. Should this be implemented here within the project-link system or with separate templates and/or modules for the big-box and inline versions the templates for pedia, species, and commons?

None of these are likely insurmountable and all but the last may be ignorable. DCDuring TALK 21:04, 18 October 2016 (UTC)

@DCDuring: I haven't encountered any exceptions in the logic that I used in w:Module:eFloras, but it's unlikely there will be any, because the floras and lists that the eFloras template creates references to are all plants, and there is a fair amount of regularity in botanical names. For instance, all plant families end in -aceae, so the module searchs for that and makes sure it's not italicized. The logic has to be different here on Wiktionary, because more than just plant names are involved, and the automatic italicization would have to be explicitly turned on in links to species, subspecies, variety, etc. pages and not turned on for links to family pages, which aren't ever italicized.

It would be easy to add or remove elements to the module, if we discover any more that should not be italicized. There should just be a list of testcases somewhere (with one example each of genus, subspecies, form, etc.) that we can look at to check that the code is doing what it's supposed to.

I'm not familiar with the structure of these interwiki link templates and modules, but I think I'll start work on a module that does the simple task of this automatic italicization, which can then be used in whatever interwiki link modules require it. — Eru·tuon 23:14, 18 October 2016 (UTC)

I greatly appreciate your undertaking this. DCDuring TALK 23:22, 18 October 2016 (UTC)

Module:italics is now complete and seems to work. It has an array of things that shouldn't be italicized, and it's pretty easy to add another one if you think of any. The documentation page has a set of testcases that show how the module handles some of the un-italicized elements that we talked about. If there are no problems, someone can add this function to the interwiki link modules; not sure what the parameter that turns it on should be called, though. — Eru·tuon 01:19, 19 October 2016 (UTC)

My choice: "taxi=". DCDuring TALK 11:09, 19 October 2016 (UTC)

That might be fine, though I wonder: would there be any examples of page names with parentheses that should be italicized but are not taxonomical? I was thinking maybe the titles of plays, but I couldn't find any that are linked to. — Eru·tuon 15:53, 19 October 2016 (UTC)

Examples: plays like Antigone (Sophocles play), which are named after characters and therefore have a disambiguator. Or Richard II (play), which is named after a real person. These currently don't have Wiktionary entries, or they are not mentioned in definitions (see Antigone; there's no entry on Richard II) yet, but perhaps they will be in the future, and then they would have to be italicized in the same way as genus or species names. — Eru·tuon 16:57, 19 October 2016 (UTC)

For a broader reference for the parameter name how about "seli", for "selective italics"? DCDuring TALK 00:22, 20 October 2016 (UTC)

Frequently I see people quoting Google hit counts -- the numbers that come up at the top of the first page of results -- as if they were an exact measure of how many times a word or phrase is used on "the Internet". Unless and until someone can give a clear explanation of how these numbers are generated, they need to be treated with the greatest caution or scepticism. A common behaviour is that a largeish number (say 10,000) comes up, but a much smaller number (say 200) appear to actually exist in the sense that a web page containing that exact word or phrase can be retrieved. There is a variable cutoff point at which Google's "page through the results" runs out, even for search terms that obviously will genuinely have very large numbers of results, but the way this works is entirely opaque. It is not hard to find egregious examples. For example, a search for "a it of" (in quotes) supposedly yields 2,510,000 results, of which 98 are actually retrievable. A search for "goodgrief" supposedly yields 5,690,000 results, of which virtually every one of the retrievable set is actually "good grief" and not "goodgrief". Mihia (talk) 03:22, 16 October 2016 (UTC)

Indeed, what I usually do is click several times "to the right", on results page 10, then 15, etc., to see whether a much smaller number appears. For google:"goodgrief", clicking to the right ultimately lands me on Page 16, where it says "Page 16 of about 146 results". I have to admit that we have to be careful with these numbers.

Where possible, it is better to use Google Ngram Viewer to get frequency numbers. This works not only for English but also for Spanish, German, Russian, Italian, French and Hebrew.

Czech is not in Google Ngram Viewer, so either we have to make do with the Google numbers, or use an academic corpus of Czech. --Dan Polansky (talk) 05:29, 16 October 2016 (UTC)

• Number of hits also doesn't tell you anything about meaning. Something with 500 hits may have 490 hits as a username and 9 as a brand name. Renard Migrant (talk) 12:27, 18 October 2016 (UTC)

I agree with the above sentiment about result count not conveying meaning, so they are only valuable to the extent that common sense is applied to their consideration. Some notes about the result count number: the number is an estimate unless the rc=1 parameter is used, even then it will only be actual up to one million results. Also, the fact that results beyond page 16 or so do not display is that Google only returns 1000 results for any search, the fact that they aren't displayed does not mean they do not exist. In cases where there are even fewer than 1000 despite a large number it is likely at least in part due to the condensing process that results are put through after the ranking which combines and removes some "duplicate" results. - TheDaveRoss 13:10, 18 October 2016 (UTC)

FYI, I have started Wiktionary:Requests_for_deletion/Others#Template:nonstandard_spelling_of. I think the template should only exist if we have a reasonably clear idea of what we mean by "nonstandard"; I don't have such a clear idea. --Dan Polansky (talk) 06:35, 16 October 2016 (UTC)

A zero derivation is one that does not lead to any changes in the word, the part of speech is just switched over without any changes. English uses zero derivation a lot, so it's especially important there. However, we don't currently categorise or otherwise mark such derivations. In fact, the majority of such cases are lacking an etymology altogether. I'm wondering how we can best handle zero derivations more explicitly. When it comes to suffixes, we categorise by suffix, so the nature of the derivation is generally clear from the nature of the suffix (and if there are multiple homographic suffixes, we can disambiguate with id=). It's clear that -ify creates verbs, for example, while -age makes nouns. For zero derivations this is less clear, so we should probably add a part-of-speech qualifier to the category name. So embrace would get a second etymology which would categorise into something like Category:English noun zero derivations. We'd presumably create a template for the occasion too. —CodeCat 17:26, 17 October 2016 (UTC)

Late response, but: It needn't be listed under a separate etymology. That's certainly one way to do it; the other is to stick under the etymon's etymology section with "And the noun sense derived therefrom circa 1720, first attested referring more specifically to" vel sim.​—msh210℠ (talk) 15:30, 27 November 2016 (UTC)

This is definitely worth doing, IMO. As Msh210 says there need not be a separate etymology section. Further I think such separate etymology sections for zero derivations should be eliminated and replaced by a zero-derivation template, as CodeCat suggests, with a parameter for date of first attestation of the derived term. If such a parameter is missing, it seems to me to be worth categorizing the entry appropriately to draw attention to possible uncertainty in the order of derivation. It will be a lot of work to determine which PoS comes first. We should start with those for which the attestable zero-derivation occurred in EME or later. DCDuring TALK 16:25, 27 November 2016 (UTC)

I propose prohibiting deleting user talk pages, especially, their own one unless it is very necessary or a link to the archive is clearly shown on their talk page.

Talk pages are the best and fastest way to study a user, to see what they are up to or have been up to, what their expertises are, how communicative they are, what usergroups they belong to etc. Also, talk pages usually do not contain garbage but rather discussions that may be useful to others to read in order to not ask the same question. --Dixtosa (talk) 17:35, 19 October 2016 (UTC)

• Support: Non-admins should be allowed to see the history of all user's talk pages, except for graffiti and outing edits. Purplebackpack89 19:34, 19 October 2016 (UTC)
• Support --Daniel Carrero (talk) 19:36, 19 October 2016 (UTC)
• I would even go so far as to say that the pages should not be emptied either. All the discussions should be either on the page or archived on a subpage. This would ensure that all the content is searchable. --WikiTiki89 19:40, 19 October 2016 (UTC)
• Support. I've expressed support for this before, at Wiktionary:Information desk/Archive 2014/January-June#Geequinox. Archiving talk pages seems unobjectionable, and I'm even okay with emptying them, but I think deleting them should be avoided. —Mr. Granger (talk • contribs) 19:46, 19 October 2016 (UTC)

There is currently a page deletion reason "userspace page deleted on user's request". Would the use of this be restricted? Would users have to provide evidence that the page "should" be deleted at some kind of forum? Equinox ◑ 19:47, 19 October 2016 (UTC)

This deletion reason is for userspace sandboxes, notes, etc. Deleting them is fine, in my opinion. It does not apply to talk pages. --Daniel Carrero (talk) 19:49, 19 October 2016 (UTC)

There is a difference between a userspace page and a user-talk-space page. --WikiTiki89 19:49, 19 October 2016 (UTC)

I think I have deleted user talk pages when marked with this reason by users. I think others have too. So needs to be clarified. Equinox ◑ 19:50, 19 October 2016 (UTC)

Ok, I should have said that there should be such a distinction. --WikiTiki89 19:51, 19 October 2016 (UTC)

• Oppose Admins need to have the authority to delete whatever they think needs deleting. SemperBlotto (talk) 19:53, 19 October 2016 (UTC)

  Except the main page. --Daniel Carrero (talk) 19:54, 19 October 2016 (UTC)

Oppose. A contributor’s userspace is his castle, and as long as it’s not harming the project or other users, I don’t see a problem with allowing him to bulldoze and rebuild one of the castle’s towers. Concerning some of your points:

• Talk pages can be used to study users: which is why users who don’t want to be probed should be given the option of getting rid of their talk page.
• Talk pages contain useful content: if a discussion is important for Wiktionary, it should take place or be archived in a public page, not in someone’s talk page.

— Ungoliant ^(falai) 20:09, 19 October 2016 (UTC)

I've been archiving my talk page for years, under the impression that it's what everybody does, and that people would want to read it. If it turns out we can delete our talk pages, I'm thinking of maybe deleting mine. --Daniel Carrero (talk) 20:26, 19 October 2016 (UTC)

@Ungoliant MMDCCLXIV I think it's generally held around here, including by you, that users must consent to allowing their actions to be "probed" as a condition of participating. It's less "bulldozing and rebuilding the castle's towers"; that would be just blanking the page. Deleting the page and its history is more akin bulldozing the castle's towers while demanding that all record the towers ever existed be burned. Purplebackpack89 03:23, 20 October 2016 (UTC)

Actions in public pages must be kept for probing. — Ungoliant ^(falai) 11:04, 20 October 2016 (UTC)

Talk pages are public pages. When they aren't deleted, anyone can read them. Purplebackpack89 14:01, 20 October 2016 (UTC)

By public, I mean they are not inherently connected to an individual user. — Ungoliant ^(falai) 15:11, 20 October 2016 (UTC)

A lot of discussions start from someone's talk page and only very few of them reach to the "public pages".

Overall, I think it is far more important for Wiktionary that each user can have some idea about any other user and can access to useful information than the right to have own talk page deleted for some lame reasons. --Giorgi Eufshi (talk) 16:27, 20 October 2016 (UTC)

• Support. I find that talk pages are helpful for figuring out who to talk to about what. Andrew Sheedy (talk) 01:50, 20 October 2016 (UTC)
• Support: Let us preserve discussions at least in page histories. And I find it especially troublesome when admins delete talk pages of banned users. Let transparency reign supreme. --Dan Polansky (talk) 13:23, 22 October 2016 (UTC)

If this proposal passes, what to do when a user deletes their own talk page? Would another person restore it and perhaps archive it for them? --Daniel Carrero (talk) 14:51, 22 October 2016 (UTC)

restore and admin-protect it. --Dixtosa (talk) 15:07, 22 October 2016 (UTC)

And how do non-admins post to an admin-protected talk page? Chuck Entz (talk) 00:46, 23 October 2016 (UTC)

I have seen this option in protection summaries "move=only admins". I thought there would be "delete=only stewards". Dixtosa (talk) 05:49, 23 October 2016 (UTC)

The system gives us only two types of protection: against editing and against moving. We have a choice of what level of user we can protect against, but those are the only two actions. I don't know about stewards, but bureaucrats have no special powers beyond the ability to add or remove privileges- the ability to block, protect and delete comes from being an admin, not a bureaucrat. I'm sure stewards have all of the above on any wiki they go to and globally, but I don't know if they can set protections against admins- I think they would have to remove a given admin's ability to delete anything rather than being able to protect a given item from deletion by all admins as a class. As I understand it, it took action by the developers to institute admin-proof protections when there was a dispute at de-WP a while back. Chuck Entz (talk) 08:10, 23 October 2016 (UTC)

By delete, do you mean delete, or do you mean erase the contents of? I don't think there's a big problem in the latter case, as long as the page history is still accessible. Andrew Sheedy (talk) 00:36, 23 October 2016 (UTC)

I don't see the problem. How is this different from any other case of an admin abusing his deletion power to delete something out of process? --WikiTiki89 13:39, 24 October 2016 (UTC)

Hi everyone,

I have an opinion but I am not sure it is valid enough so I wanted some input from fellow Wiktionarians to check my reasoning. This is my problem: as far as I know to attest a word it suffices to use a citation from a Usenet group - the rationale is that Google archives it "durably". And I was thinking if that is so, then this also applies to words that appear in Google Groups but not necessarily in the Usenet. I suppose Google archives Google Groups also "durably" so the word is also durably archived and then it should satisfy that part of our strict Criteria for Inclusion. Does anyone have an opposing opinion? My intention is to include a word here and propose it as a FWOTD candidate but I'm not sure it passes the "durability" part of CFI. Hope to hear from you soon, cheers all, --biblbroks_{дискашн} 19:41, 19 October 2016 (UTC)

I'm not sure that it's specifically Google's archives that make Usenet durably archived, but rather because Usenet is archived independently by various organizations, and Google just happens to provide a convenient searchable interface. This is much the same as Google Books, the books aren't durably archived by Google, but by libraries; Google just gives us convenient searchable access. --WikiTiki89 19:45, 19 October 2016 (UTC)

Then wouldn't the wording " this naturally favors media such as Usenet groups, which are durably archived by Google." (at Wiktionary:ATTEST) be somewhat incomplete? IMO it should read similar to "... which is durably archived by Google and various other organizations." Otherwise it gives an impression of Google's archives as a sole contributor to the "durability" part of the criterion. I am not sure if this is of much importance but I remember some discussions few years ago about these "durably"/"permanent recorded media" stuff. Or was it something like that? OTOH, I much more vividly remember a dispute over Request for Verification with a contributor whose argument was that Google searches weren't a proper way to base a word's attestation. At that time I was busier with winning the "RFV contest" of one particular phrase than deciphering the true meaning of CFI even to myself let alone to that editor. If I understood the durability more properly it might have helped. The editor eventually received a perma-ban. --biblbroks_{дискашн} 20:32, 19 October 2016 (UTC)

The best search term for Wiktionary discussions about this is "durably archived".

We value Google for its convenient online access. The print corpora they have (Books, News, Scholar) are durably archived because the recorded documents are of print media which are physically archived somewhere, not necessarily convenient of access, eg, Otago Daily Times is probably in multiple NZ libraries, but few, possibly none, elsewhere. An analogous situation exists with respect to Usenet: multiple archived copies, but only Google offers convenient access. DCDuring TALK 00:52, 20 October 2016 (UTC)

@biblbroks: You are right: the CFI text is misleading. We are still in the process of cleaning up CFI. The whole durably-archived business is something of a gray area. --Dan Polansky (talk) 13:17, 22 October 2016 (UTC)

Should the deletion reason "Userspace page deleted on user's request" be changed to "Userspace page deleted on owner's request" (or similar)? It just struck me, seeing I'm-so-meta delete DTLHS's tracking page that Wonderfool had completed, that it might sound as though any user could request deletion of any other user's page. Equinox ◑ 21:25, 20 October 2016 (UTC)

Probably. --WikiTiki89 21:30, 20 October 2016 (UTC)

I changed it now. I don't think we could actually use "deleted on user's request" as a reason to let one person delete another user's page, but having even excess clarity shouldn't hurt. --Daniel Carrero (talk) 21:52, 20 October 2016 (UTC)

Thanks. (If they are the page owner, why don't they have the right to delete it on demand?) Equinox ◑ 00:35, 22 October 2016 (UTC)

Do you mean that maybe a non-admin should have a "Delete" button for their own userpages? There's a Wikipedia policy saying that they wouldn't want to implement that, because a person in bad faith could move pages to their userspace and then delete them. I think there were more reasons, too, that I don't remember right now. --Daniel Carrero (talk) 01:22, 22 October 2016 (UTC)

I was really talking about your anti-deletion comment in "Deleting user talk pages" above. But only as a speculative aside. Equinox ◑ 01:47, 22 October 2016 (UTC)

IMO, people should be completely free to delete their user pages that are not talk pages. At one point, I tried to delete my own talk page on that wiki called explain xkcd, but someone reverted it and said that it is not allowed. I'd prefer if you and other people never deleted their user talk pages, but I'd feel weird reverting or archiving others' talk pages if they want them deleted, and it's certainly not a blockable offense, so even if we implemented the rule that nobody can delete their own talk pages, I'm not sure if we would just ignore you or other people if they don't want to comply. --Daniel Carrero (talk) 02:14, 22 October 2016 (UTC)

Mainly to address some complaints in Wiktionary:Votes/pl-2016-07/Pronunciation 2, I'd like to edit the first sentence of WT:EL#Pronunciation.

This is a minor edit, and I'm thinking this won't need a vote. @Dan Polansky, it seems you are usually the first person to defend having votes to edit policies, not counting myself. Do you think that this needs a vote?

Current text:

Proposed text:

Changes:

• Removing "Ideally, every entry should have a pronunciation section, with the phonetic transcription and an audio file.".
• Adding "The pronunciation section includes the IPA transcription, audio pronunciations, rhymes, hyphenations and homophones."
• Moving "Note that pronunciations may vary widely between dialects." to the end of the first bullet point.

Rationale:

• Arguably, the "every entry should have ..." part " is useless clutter. We don't want that statement in every section "ideally, every entry should have an etymology section" and such. (as pointed out in the vote)
• The "every entry should have ..." part is false. There are some languages that shouldn't have a pronunciation section (e.g. sign languages, which have a Production section instead, and many ancient languages whose pronunciation is unknown). (as pointed out in the vote, too)
• Arguably, the part "Note that pronunciations may vary widely between dialects." fits better the text that is explaining the IPA transcriptions, instead of the introduction.

--Daniel Carrero (talk) 21:56, 20 October 2016 (UTC)

I oppose explicit mention of IPA. Also, I don't see the point of saying "Note that pronunciations may vary widely between dialects." Why not just drop it? --WikiTiki89 22:00, 20 October 2016 (UTC)

Sure, we can change "IPA transcription" to just "transcription". I agree with your second point, too: we can just drop the "Note that pronunciations may vary widely between dialects." I always like when we're able to remove any statements from WT:EL that are comments rather than regulations. --Daniel Carrero (talk) 22:08, 20 October 2016 (UTC)

@Daniel Carrero: The meta-principle states that "Any substantial or contested changes require a VOTE". The proposed change is not very substantial and is so far uncontested. While I prefer to always have a vote, a vote does not seem required by the meta-principle in this case. But if you want to use this BP discussion as a basis for changing WT:ELE, you should wait a couple of days before you change WT:ELE to allow other people to provide input. --Dan Polansky (talk) 14:57, 21 October 2016 (UTC)

OK, sounds good to me. If nobody objects, I'll do the change without a vote, then, after waiting some time. --Daniel Carrero (talk) 01:39, 22 October 2016 (UTC)

Taking Wikitiki89's first message into consideration (which I support), the exact proposed text is going to be this:

--Daniel Carrero (talk) 01:59, 24 October 2016 (UTC)

I edited the policy as suggested. Feel free to discuss/revert/etc. --Daniel Carrero (talk) 07:54, 31 October 2016 (UTC)

User:Angr edited d'où to use Unicode apostrophes instead of plain ASCII apostrophes in various places. What's the desired behavior here? Our entries are named using ASCII apostrophes so I think we should stick with ASCII apostrophes. Benwing2 (talk) 23:30, 20 October 2016 (UTC)

I don't see any harm in it. We use all kinds of things like macrons and accents in headwords that we don't include in the entry name- this is just an extension of that. It may even be beneficial in cases where the search engine doesn't recognize the plain character and the fancy character as the same thing: it means that spellings with both the plain and fancy character are in the entry for the search engine to find. Chuck Entz (talk) 02:26, 21 October 2016 (UTC)

It would be ideal if Unicode apostrophes replaced ASCII ones across all French entries for consistency. I don't much like the idea of some entries have one type and some having the other. Andrew Sheedy (talk) 02:37, 21 October 2016 (UTC)

I always change them back to straight apostrophes, as these are the ones that appear on keyboard. They sometimes get corrected in Microsoft Word to curly ones but that's it. Renard Migrant (talk) 12:49, 21 October 2016 (UTC)

I've been under the impression for years that our usual practice is to use typewriter apostrophes in entry titles and curly apostrophes in headword line displays, not just for French but for all languages that use apostrophes. I understand the rationale behind using typewriter apostrophes in entry titles, but curly apostrophes look prettier, so I prefer using them for display whenever possible. What should definitely always be the case, though, is for there to be a hard redirect from the curly version to the typewriter version, e.g. d’où → d'où, because French Wiktionary always uses curly apostrophes, and the only way to make sure our entries link correctly to theirs is for en:d'où to link to fr:d'où, which hard-redirects to fr:d’où, which links to en:d’où, which hard-redirects back to en:d'où. —Aɴɢʀ (talk) 13:19, 21 October 2016 (UTC)

’ in entries seems to be incredibly rare, making me think there is no such unofficial policy. Renard Migrant (talk) 17:28, 22 October 2016 (UTC)

Personally, I would be quite pleased if a bot went through and replaced all ASCII apostrophes with Unicode ones (aside from actual page names). I agree with Angr's reasoning. Andrew Sheedy (talk) 00:33, 23 October 2016 (UTC)

Equally, my preference follows Rendard's: the ascii apostrophe is available to editors without issue or complication, unlike (in most cases) the unicode apostrophe. (That is, this is make-work which will result in on-going make-work to correct future editors.) - Amgine/ ^t·e 05:07, 1 November 2016 (UTC)

I'm thinking that it would be much easier, and less work (I mean, less ongoing work), if we did not use a bot, but rather had Module:links and Module:headword automatically do replacements: for link text, replacing plain apostrophes with the single right quotation mark (curly apostrophe), and for URLS, replacing curly apostrophes and other symbols with the plain apostrophe. We have also been talking about this at Wiktionary talk:About Ancient Greek. I mean, we used to have to add macron- and breve-full Latin as alternative link text (for instance, {{m|la|Roma|Rōma}}), but now the links module automatically replaces macroned and breved letters with the plain equivalents when creating links. Why not have modules also do apostrophe replacement? It would be so much easier. — Eru·tuon 21:19, 29 October 2016 (UTC)

Please don't, the fact it benefits no-one should be reason enough to not do it. Renard Migrant (talk) 14:07, 30 October 2016 (UTC)

FYI, I created Wiktionary:Votes/2016-10/Removing label proscribed from entries. Let us postpone the vote as much as discussion requires, if at all. --Dan Polansky (talk) 19:43, 21 October 2016 (UTC)

Morrebbero does not seem to be showing up in the conjugation as an alternative to morirebbero. (3rd person plural conditional.)— Pingku^dimmi 03:29, 22 October 2016 (UTC)

I'd like to make Wiktionary:Voting policy a full-fledged policy at some point, instead of just a think tank. One thing I'd like to remove is this:

"No topic should have a new vote more than once a day (24 hr period)."

Rationale:

What does this rule even mean? If a person creates a vote about Greek romanization today, can't I create another vote about Gothic romanization on the same day, because it's the same "topic"? Does anyone want that? If not, let's just remove that rule.

--Daniel Carrero (talk) 13:07, 22 October 2016 (UTC)

You're right about the need for change. The period for no additional votes on the same topic (broadly construed) should be 30 days. DCDuring TALK 14:06, 22 October 2016 (UTC)

Or to simplify these determinations, we should limit the number of proposals a single individual could make to, say, one a month or one a week. As we already have a policy against sock puppets, that way, at the very least, someone with many proposal would at t least have to find stooges to introduce additional votes. DCDuring TALK 14:10, 22 October 2016 (UTC)

I'm currently the only one above a certain number of votes created per month. Personally, I don't think I would like to find stooges to create votes for me, thank you -- sometimes I do the opposite, creating votes for proposals that were introduced by other people. I wish more people created votes for things that need to be voted. Anyway, what you talked about could be seen as variations of the rule that I proposed to remove, but that would be a long shot. It's easier just to remove it and then discuss and introduce whatever other proposals concerning how many votes may be created, which is something that we discussed recently. --Daniel Carrero (talk) 14:21, 22 October 2016 (UTC)

Yes, I certainly see the advantage to you of getting inertia on your side. DCDuring TALK 14:31, 22 October 2016 (UTC)

What is the advantage to me of getting inertia on my side? --Daniel Carrero (talk) 14:45, 22 October 2016 (UTC)

I agree that it should be removed. But I also think that when a single person creates too many votes in a week, that is not so good and should be avoided. --Dan Polansky (talk) 14:19, 22 October 2016 (UTC)

Strong discouragement has proven insufficient to avoid the creation of too many votes by an individual. DCDuring TALK 14:31, 22 October 2016 (UTC)

By contrast, I saw Daniel Carrero respond to disagreement by reducing the number of created votes a lot. My rule of thumb is that there should never be more than 10 votes running and listed, and that is where we have been lately. In any case, "at most one new vote a day" is too lenient if applied to a single person since that would be 30 votes a month. The wording should go since it does not do anything useful anyway. --Dan Polansky (talk) 14:55, 22 October 2016 (UTC)

Procedural note: I would like to remove "No topic should have a new vote more than once a day (24 hr period)." from Wiktionary:Voting policy without a vote. Rationale: This is a think tank policy and as such, I believe there's some leniency in editing it with abandon. By contrast, the whole section "Voting eligibility" was voted and approved at Wiktionary:Votes/2010-04/Voting policy and I would probably oppose changing any regulations in that section without a vote. --Daniel Carrero (talk) 15:03, 22 October 2016 (UTC)

I removed "No topic should have a new vote more than once a day (24 hr period)." as suggested above. Feel free to revert/discuss/etc. --Daniel Carrero (talk) 07:55, 31 October 2016 (UTC)

Can we revert this please, or (sigh) have a vote on it? I think it's a good rule and 24 hours should be the very minimum. Equinox ◑ 14:10, 31 October 2016 (UTC)

I reverted it per your request; the 24-hour rule is back in the policy. If we are going to vote on removing it anyway, shouldn't we define a higher and thus more useful limit? Like 1 vote per week? --Daniel Carrero (talk) 14:20, 31 October 2016 (UTC)

Instead of imposing any kind of limits, why don't we simply have a rule that there needs to be a discussion in which at least a few editors express their desire to have a vote on the topic? That way no vote can be created merely on the whims of a single editor. --WikiTiki89 13:41, 24 October 2016 (UTC)

At the moment, we have this related but more lenient rule in Wiktionary:Voting policy: "Votes should not usually be called for on Wiktionary:Votes. They should be the result of prior discussion located elsewhere (the Beer Parlour)."

As you may remember, I oppose this: "why don't we simply have a rule that there needs to be a discussion in which at least a few editors express their desire to have a vote on the topic".

Personally, I have this political position: The right to create new votes is a fundamental right, and anyone must be free to create new votes if they want, with or without prior discussion. (except maybe this: people who aren't eligible to vote probably should not be able to create votes -- but we may want to cross that bridge when we come to it) In practice, probably most voted proposals require discussions as you can't just propose a new thing without everyone being on the same page, but formally requiring discussions for all votes would, in some cases, be a bureaucratic hindrance, or maybe a more serious problem.

• If a new vote is most certainly going to pass, no new discussion must be created to check if a vote is needed. Chances are, the proposal was already discussed before at some point, and the old discussions may be linked in the vote.
• @Dan Polansky created this vote about the "def" template a few months ago. From what I understood, he did it because if the vote did not exist, people would probably be adding {{def}} to new entries without the vote. Sometimes, passing votes are needed to show consensus for a new thing and failed votes are needed to show lack of consensus for another thing. We don't need to create discussions to prove that there is lack of consensus for a new thing; rather, the proposers of the new thing need to show consensus on their side.
• Votes to remove clutter from policies (like this) or formalize what we already do (like this) don't need, or barely need a discussion to check if the vote can be created.

If a new discussion is created proposing a new vote but nobody or few people bother to answer, that is good enough to me and we can create the vote, rather than insisting for people to reply. If a new non-discussed vote is created but which should have been discussed, the vote is probably going to fail anyway, and with comments about what exactly is wrong with the vote -- which probably takes about the same effort as replying and pointing problems at a pre-vote discussion. Sometimes, even when a vote that was discussed a lot before its creation, people point out new problems listed while the vote is ongoing, so pre-vote discussions are not a guarantee of creating perfect votes.

In all cases, even when no new discussion is required to check if a vote can be created, a new BP discussion may be created alongside the new vote, to inform people that the vote exists.

As long as we are fundamentally able to create votes if we want to, I'm fine with having restrictions like this: a maximum number of votes created per person during a certain period of time. --Daniel Carrero (talk) 17:06, 24 October 2016 (UTC)

Why is creating votes without prior discussion a fundamental right? If you're the only one who wants to vote on something, how do you expect it to even pass? We have the right to not have our time wasted by bad votes. What's so hard about starting a discussion and asking about whether we need a vote? --WikiTiki89 17:28, 24 October 2016 (UTC)

I said: "probably most voted proposals require discussions". Do you believe that 100% of votes created require pre-vote discussions? Where's the disagreement? What are the bad votes you are talking about? --Daniel Carrero (talk) 17:40, 24 October 2016 (UTC)

Suppose we say that the right to start a BP discussion on an issue is a fundamental right. If there is no support for something in a BP discussion, there isn't much point in going to the trouble of starting a vote. bd2412 T 17:43, 24 October 2016 (UTC)

Yes, I agree with you, but on most votes, not all votes. In my message from 17:06, 24 October 2016 (UTC), I listed some cases that in my opinion, should be exceptions. Do you think that 100% of votes created require pre-vote discussions? --Daniel Carrero (talk) 20:20, 24 October 2016 (UTC)

Exceptions would be procedural votes like bot and adminship approvals. The ones you listed above should not be exceptions in my opinion. --WikiTiki89 20:32, 24 October 2016 (UTC)

I agree that Wikitiki's are good exceptions and that Daniel's are not. DCDuring TALK 20:57, 24 October 2016 (UTC)

That's OK. Should we create a vote with a proposal like "Votes may only be created as a result of a discussion in which at least a few people supported creating a vote, except for nominations of bots, administrators, and bureaucrats.", to be added at Wiktionary:Voting policy? --Daniel Carrero (talk) 23:15, 24 October 2016 (UTC)

"At least a few" needs to be more specific. DCDuring TALK 23:27, 24 October 2016 (UTC)

Maybe 3 people? @DCDuring, would you like to create a vote with the proposal: "Votes may only be created as a result of a discussion in which at least 3 people supported creating a vote, except for nominations of bots, administrators, and bureaucrats."? Or maybe another number of people?

I may create the vote if people want, even though I'd vote oppose. I'm okay with either requiring 3 people to start this vote (for consistency?) or just creating it at once. Please, do whatever you want. The idea is not mine, I'm just offering to help with implementing others' ideas, which is something I like to do often. But I would also oppose implementing this requirement somehow without a vote, because it's a serious limitation on the ability to create further votes. Not to mention that it sounds like a bad idea to me, because it's needlessly bureaucratic and I don't see what problem it fixes, but I guess I can live in a system that I disagree with if it will make others happy. --Daniel Carrero (talk) 04:52, 25 October 2016 (UTC)

Votes are usually attended by more people over a longer period of time than BP discussions which always show the same dozen names and do not usually survive the end of a month. Votes are a way to create consensus for things which people just don't care about, to force a hand. Binding such a method which might be the last escape from an utter lack of input to the presence of input seems like introducing a bug to our system. Korn (talk) 13:07, 25 October 2016 (UTC)

I agree with Korn. --Daniel Carrero (talk) 17:32, 25 October 2016 (UTC)

@Daniel Carrero re: "would you like to create a vote with the proposal...?" No. I'd like to see if there are others who agree and think it's worth a vote. I think that, by itself, it is not worth a separate vote. If we added some other "common-sense" reforms to our voting process, like quora, there might be something worth having folks stop adding and improving content and instead evaluate the proposal and its elements, considering how the elements work together. I'd also like to save my proposal-of-the-week for something better that might come along. DCDuring TALK 17:50, 25 October 2016 (UTC)

@DCDuring: you mentioned quora. Do you mean, requiring a minimum number of participants in an ongoing vote, in order to successfully close the vote? --Daniel Carrero (talk) 18:11, 25 October 2016 (UTC)

OK, I already brought this up but it bears repeating in light of the dubious category CAT:Catalan terms derived from Old Provençal. The terms in this category are largely inherited terms and express the completely wrong notation that Catalan derives from Old Provençal. The intent was clearly to derive Catalan from Old Occitan, but even then I think this is wrong. This brings up two issues:

1. Can we please rename Old Provençal to Old Occitan?
2. What's the "old" language that Catalan derives from? We don't seem to have "Proto-Gallo-Romance".

Benwing2 (talk) 17:04, 22 October 2016 (UTC)

We treat Old Provençal as a synonymous name for Old Occitan, and Provençal as a synonymous name of Occitan. And the two related categories are... Old Provençal and Occitan. Yeah. There was a decision on this many years ago, I dunno, 2010, and Old Provençal won out. There is a Category:Old Catalan language and I've seen references to Gallo-Romance rather than Proto-Gallo-Romance. Like, some say that the Oaths of Strasbourg are written in Gallo-Romance rather than Old French (but that's another debate). Renard Migrant (talk) 17:25, 22 October 2016 (UTC)

As a user I would find it highly preferable if the ancestor of X, and X alone, was Old X and not Old Y. Korn (talk) 17:45, 22 October 2016 (UTC)

How is that supposed to work when Old X is the ancestor of multiple modern languages? Old Irish is the ancestor of Irish, Scottish Gaelic, and Manx. Old English is the ancestor of English and Scots. Old Norse is the ancestor of some 10 languages, not one of which is called "Norse". —Aɴɢʀ (talk) 08:51, 23 October 2016 (UTC)

But Provençal is no-way, no-how the same as Occitan. Provençal is a dialect of Occitan, as are Languedocien, Auvernhat, Gascon, etc. As for Old Provençal vs. Old Occitan, Wikipedia and AFAIK all modern scholarly sources use "Old Occitan" for the basic reason that the language is ancestral to all of the modern Occitan varieties (except maybe Gascon), and is not specifically an old version of Provençal. IMO we need to change the terminology. Anyone else agree? Benwing2 (talk) 18:35, 22 October 2016 (UTC)

I agree. —CodeCat 01:10, 23 October 2016 (UTC)

I support renaming pro Old Occitan. —Aɴɢʀ (talk) 08:51, 23 October 2016 (UTC)

Oh yes, consensus can change and I support it for broadly the same reasons (though I'm not massively clued up on Occitan vs. Provençal). Renard Migrant (talk) 11:27, 23 October 2016 (UTC)

I too agree. Leasnam (talk) 17:15, 25 October 2016 (UTC)

• Attention @-sche... —Μετάknowledge^{discuss/deeds} 00:01, 25 October 2016 (UTC)

Old Provençal was the historic name, and was still slightly more common as of 2008 (and in general Provençal was several times more common than Occitan). Wikipedia also says Provençal was the older name, but it lemmatizes Occitan and Old Occitan, saying "in the English-speaking world, the term Provençal has historically also been used to refer to all of Occitan, but is now mainly understood to refer to the variety spoken in Provence." Perusing Google Books, it does seem like "Old Occitan" is more common in the most recent books (2010-2016). To add clarity as to the scope of pro and add consistency between the names of oc and pro, I'd support renaming it to "Old Occitan", though my feelings on the matter are not strong. Keep the old name as an alt name, obviously. - -sche (discuss) 21:02, 25 October 2016 (UTC)

Yesterday, I was pinged to Wiktionary:Beer parlour/2014/August § Old Provençal or Old Occitan?, a 2014 discussion which supported a rename; I was going to start a new BP thread to be sure there was still support 3.5 years later (since the rename will directly affect hundreds of entries), but I see from this thread (only 1.25 years old) with mostly-different participants that there is.

With regard to commonness: Ngrams suggest Old Provencal was somewhat more common even as late as 2008 (and significantly more common before then), although it was trending down and Old Occitan trending up. When I search Google Books for works published in the ten years since Ngrams' cutoff, I find 20 using "Old (Provençal|Provencal)" (and 23 irrelevant ones using "old Provençal" as in "old Provençal saying", etc), and 18 using "Old Occitan" (including one that explicitly supports a rename, "also called Old Provencal and today known as the Old Occitan language"), neck and neck. Wikipedia calls it "Old Occitan", but Glottolog calls it "Old Provençal". The only English reference work on it that I found published in the last twenty years calls it "Old Occitan".

But several other concerns have been raised in the 2014 discussion and in this one, as breaking the tie in favour of "Old Occitan".

I'll start renaming it. - -sche (discuss) 14:13, 20 January 2018 (UTC)

@-sche: There are a few module errors (for instance, in tres) because Module:descendants tree can't find an Old Occitan section. Is there a method to change all the headers, Descendants entries, and translations to the new name? — Eru·tuon 06:12, 22 January 2018 (UTC)

I've been changing them with AWB, working from a list of all occurrences of the string "Old Provençal" in the last database dump. There are about 400 left, which I should finish today. :) (A bot could also have done it, and if there had been more than a few thousand entries I would have requested that, but there would have been a few false positives where "Old Provençal" was correctly mentioned as e.g. the thing that "OProv" is an abbreviation of.) - -sche (discuss) 15:35, 22 January 2018 (UTC)

I have used AWB on English Wikipedia, and there are a couple of tasks here on Wiktionary that I really don't want to do by hand: adding syllable breaks in the sequence IPA^(key): /iə/ when it's not a diphthong and correcting some {{R:Smyth}} references. — Eru·tuon 01:34, 23 October 2016 (UTC)

Done. Benwing2 (talk) 01:46, 23 October 2016 (UTC)

I used search, but I still don't know what AWB is. Since @Erutuon: thinks it would help with syllable breaks, and hence counting syllables, I'd like to know what it is. Where can I look ? Bcent1234 (talk) 13:42, 25 October 2016 (UTC)

@Bcent1234: AWB stands for AutoWikiBrowser, and it's described at Wiktionary:AutoWikiBrowser. Actually, it can't exactly help with counting syllables. Module:syllables can count syllables, when someone adds it to Module:IPA. I was using AWB to add syllable breaks to /iə/, which is listed as an English diphthong in Module:syllables, because it is a diphthong in New Zealand English, but is a disyllabic sequence in most other dialects (and in most of the existing IPA transcriptions on Wiktionary). Anyway, this was a complicated explanation. If a syllable break isn't added, words containing the disyllabic sequence /iə/ would be counted as having at least one less syllable than they actually have. In short, AWB can't exactly help with counting syllables, but it can help to modify IPA transcriptions so that the syllable-counting module will work correctly. — Eru·tuon 16:59, 25 October 2016 (UTC)

Wiktionary:Votes/2016-07/Request categories is going to end in 4 days. Current results: 8 supports, 4 opposes, 3 abstentions. Total: 15 people voting.

I believe that we should simply close the vote at 23:59, 27 October 2016 (UTC) as scheduled, instead of postponing the vote, because it was already created as a 2-month vote and the current turnout is pretty good. With 15 people voting, it's unlikely that a lot more people would vote even if we postponed it. That said, ongoing votes that are very close to 66.6% support are noticeably unpredictable. Currently, the vote would pass, but 1 new "oppose" could cause it to fail. --Daniel Carrero (talk) 02:16, 24 October 2016 (UTC)

La Joconde is the French name of the Mona Lisa. Formerly this name sat under Joconde, but the headword displayed la Joconde (lowercase, although the French Wikipedia article capitalizes La in La Joconde even in the middle of a sentence). So far I've adopted three different solutions for similar instances:

1. I hard-redirected Joconde to La Joconde.
2. I left Seine as-is.
3. I changed Cap to use {{only in|Le Cap|lang=fr}} (a hard redirect wasn't possible because there was also an English defn of this term).

What's the correct way of handling these cases? I don't like the current solution of having the headword disagree with the page name. Benwing2 (talk) 04:49, 24 October 2016 (UTC)

The way you don't like is the way the Irish editors have agreed to list country names in Irish, which almost always have the definite article. For example, the entry name for the Irish word for "France" is Frainc, but the headword line says An Fhrainc. —Aɴɢʀ (talk) 13:03, 24 October 2016 (UTC)

Le Touquet (for which we have no entry) is actually the name of the place Le Touquet, so « aller à Paris » but « aller au Touquet » (for non-French speakers, see au). Not sure about Le Cap as I hadn't heard of it. Head word disagree with the page name is not always wrong and it's used in English entries as well. La Joconde I have no idea and I'd have to research it, instinctively the article isn't part of its name but perhaps on researching it it will turn out to be. Renard Migrant (talk) 21:13, 24 October 2016 (UTC)

We have (deprecated template usage) The Hague and there are probably more similar names. (I've added "Le Touquet" by the way.) SemperBlotto (talk) 01:56, 25 October 2016 (UTC)

p.s. A Google ngrams search of "Mona Lisa,the Mona Lisa,The Mona Lisa" shows it to be used with the definite article about half the time. SemperBlotto (talk) 01:59, 25 October 2016 (UTC)

(e/c) In English we are equally inconsistent:

• We have The Hague, where Hague has a "see also The Hague".
• But we have the Gambia under Gambia, with headword "Gambia" and The Gambia a hard redirect (whereas Wikipedia has the country under w:The Gambia).
• Yet we have the Netherlands under Netherlands with headword "the Netherlands" (not "Netherlands").
• Finally, for river names, we have e.g. Rio Grande with headword "Rio Grande" and no mention anywhere of the fact that it is normally "the Rio Grande"; similarly for Thames.

Arguably the different treatment of rivers stems from the fact that most rivers in English are preceded by "the" whereas cities, states and countries usually aren't. The English example suggests we ought to have the Seine in French under Seine with headword "Seine" and similarly for other French rivers, and maybe the same for countries, since rivers and countries in French normally take le/la/les. Benwing2 (talk) 02:25, 25 October 2016 (UTC)

The article is not an inseparable part of these terms though. You could say "The second Rio Grande estuary". Here, the article modifies "estuary", and there's also an adjective in between. —CodeCat 17:09, 25 October 2016 (UTC)

This test isn't probative. You can say "the second Hague tribunal" even though we generally agree that "The Hague" is the name of the city. Benwing2 (talk) 20:17, 25 October 2016 (UTC)

Then The Hague is different, and is actually an inseparable unit, unlike Rio Grande. —CodeCat 20:28, 25 October 2016 (UTC)

I don't understand what you're saying. Are they different simply because someone says they're different? They both behave syntactically the same. Benwing2 (talk) 20:45, 25 October 2016 (UTC)

But they're not the same, and this is one instance where they aren't. You might say "The Rio Grande conference" but not "The Hague conference", you actually say "The The Hague conference". The article is an inseparable part of The Hague, it's not actually syntactically an article. —CodeCat 20:47, 25 October 2016 (UTC)

You don't say "The The Hague conference". That would be rather strange. Do a Google search on "a Hague" and "the second Hague" and "the only Hague" and you'll see what I mean. Benwing2 (talk) 22:17, 25 October 2016 (UTC)

"the the hague", with quotes, gets almost 10000 hits on Google. —CodeCat 22:22, 25 October 2016 (UTC)

And "the the rio grande" gets 258,000. What does that prove? Benwing2 (talk) 23:12, 25 October 2016 (UTC)

Currently, transliterations are shown with brackets around them. I propose to remove the brackets, which gives a cleaner look with less visual clutter. —CodeCat 22:39, 24 October 2016 (UTC)

They are? Where? абелево кольцо- where are the brackets? DTLHS (talk) 02:06, 25 October 2016 (UTC)

They are written between parentheses, though. The entry bracket asserts that parentheses count as brackets. --Daniel Carrero (talk) 02:11, 25 October 2016 (UTC)