To my surprise, w:Sanskrit shows that Sanskrit is an official language in one region of India and that it has native speakers. Yet we class is as an extinct language, so one of us is wrong. Renard Migrant (talk) 18:07, 1 September 2015 (UTC)[reply]
The Wikipedia page says "The Mattur village in central Karnataka claims to have native speakers of Sanskrit among its population. Inhabitants of all castes learn Sanskrit starting in childhood and converse in the language." This really seems no different from the status Latin would have had maybe a hundred years ago in some places. --WikiTiki8918:11, 1 September 2015 (UTC)[reply]
@Wikitiki89: For that matter, Latin is in this category. To be sure, there are Latin speakers and even those who are exposed to it from birth (through Catholic Mass) but it is effectively a dead language. —Justin (koavf)❤T☮C☺M☯03:25, 2 September 2015 (UTC)[reply]
The vote is now open. (I presume pinging users I have seen working with etyls would be politeering? (Why is this not a word?)) Anyway, if you have an opinion, please participate in the vote, thank you! Neitrāls vārds (talk) 21:55, 1 September 2015 (UTC)[reply]
Manual inflection tables: positional or named parameters?[edit]
For manual inflection tables, each form is specified separately rather than generated through stems, rules and other logic. I am wondering whether it's preferred to have such templates with numbered/positional parameters to specify each form, or named ones? Named has the advantage that you don't have to remember which parameter is for which form, but it's also a lot more to type. —CodeCat14:08, 2 September 2015 (UTC)[reply]
I think such a template should have named parameters if there are many parameters or if there are likely to be parameters skipped in some cases, because (in both those cases) people using the template will have a hard time keeping track of positional parameters. I think such a template should have positional parameters if some of its uses will be of only the first not-many parameters, because people using the template will not want to write named parameters' names. Thus, where both those criteria apply, the template should have both named and positional parameters, like {{{so|{{{1}}}}}}. (I don't see the harm in doing things that way even if not both the criteria apply.)—msh210℠ (talk) 21:53, 8 September 2015 (UTC)[reply]
For most of them, yes, I think so. But since this question (whether to use positional or named parameters) is decided when writing each template, and there may be some — I suspect there are — which are often used without all their parameters, it is appropriate to note (and, if writing guidelines, to build into the guidelines) the criteria I mentioned.—msh210℠ (talk) 21:56, 9 September 2015 (UTC)[reply]
Introducing the Wikimedia public policy site[edit]
Hi all,
We are excited to introduce a new Wikimedia Public Policy site. The site includes resources and position statements on access, copyright, censorship, intermediary liability, and privacy. The site explains how good public policy supports the Wikimedia projects, editors, and mission.
It seems like policy that favors the survival of WMF and the projects. And they can't go it alone so they have to ally and coordinate with other parties. DCDuringTALK19:28, 2 September 2015 (UTC)[reply]
@DCDuring: I don't think they're worried about not surviving. It probably has to do with ensuring that people in every country are allowed to have access to WMF resources. Even though this is highly desirable for the WMF and its projects, it isn't a task that the WMF itself should be taking on (see my other responses below). --WikiTiki8914:02, 3 September 2015 (UTC)[reply]
@Wikitiki89 The survival question in the short run is just the intermediary liability issue, which could easily bankrupt WMF as well as create a chilling effect. All four of the other thrust are longer-term survival matters: maintaining the economic model (eg copyright) and a political model to enable WMF projects to serve superordinate goals that make contributors feel they are working for a higher cause in lieu of monetary compensation. The superordinate goals also help garner support from other elements in society. DCDuringTALK17:58, 3 September 2015 (UTC)[reply]
@DCDuring: Ok, maybe I'm wrong about the survival question, but the point I was trying to make still stands: this isn't a task that the WMF itself should be taking on. --WikiTiki8918:04, 3 September 2015 (UTC)[reply]
Very few organizations of any size and weight in the world get to ignore public policy matters. WMF has selected issues that are close to its core mission. I would be unhappy if they got involved in other causes, no matter how much I agreed with them, eg, certain environmental issues, official corruption, nuclear proliferation. DCDuringTALK21:34, 3 September 2015 (UTC)[reply]
The second you make a political statement, you alienate everyone that disagrees. The WMF foundation's core mission is to make information available to everyone, and alienating people is not the right way to achieve that. WMF projects need to be able to thrive even in places where free speech is a foreign concept and governments looking over people's shoulders is taken for granted. --WikiTiki8921:57, 3 September 2015 (UTC)[reply]
I think WMF would lose a lot of very committed people if it were to fail to push its values as best it can and many others would lose some of the feel-good that keeps them contributing, weakening their commitment to the projects. DCDuringTALK00:47, 4 September 2015 (UTC)[reply]
@Wikitiki89: I'm confused... Are you saying the WMF and broader Wikimedia community of editors and supporters shouldn't be in favor of copyright reform and protecting readers' privacy? I don't see what is inappropriate here. —Justin (koavf)❤T☮C☺M☯21:22, 2 September 2015 (UTC)[reply]
@Metaknowledge: They don't have to, but they should. The NPOV philosophy of WMF projects loses a lot of credibility if the organization behind these projects is making political statements, regardless of what these political statements are. @Koavf: The editors can be in favor of whatever they want, but the Wikimedia organization itself should remain publicly neutral, even if every single one of the editors shared the same opinions. --WikiTiki8914:02, 3 September 2015 (UTC)[reply]
Thanks for pointing out the GitHub thing. We don't have a hardcore adolescent geek culture here, despite occasional outbreaks of the kind of humor that can be offensive. I also haven't seen much of it in other WMF projects, so there shouldn't be as much occasion for a Code of Conduct. We did manage to deal with that kind of thing without resorting to a formal code of conduct and banning. I do expect that there will be pressure to adopt such a thing however though the policy thing seems to deal solely with public policy, not internal policy. DCDuringTALK23:45, 2 September 2015 (UTC)[reply]
Special categories for Euro & Brazilian Portuguese forms[edit]
@Wikitiki89: Spanish is almost entirely phonetic (with some caveats about c/k/s/th/z sounds running together) so there are very few--if any--orthographic differences. I could imagine some eye spellings becoming somewhat popular in regions but I don't know of any. In fact, I don't know of any Spanish spelling differences like the American/British differences between colo(u)r/hono(u)r/etc. —Justin (koavf)❤T☮C☺M☯04:04, 4 September 2015 (UTC)[reply]
I cringe every time someone says any languages' orthography is "almost entirely phonetic". This seems true on the surface, but breaks down when you take a deeper look, especially at not-completely-standard varieties. --WikiTiki8914:04, 4 September 2015 (UTC)[reply]
@Koavf: The first two things that come to mind for Spanish are:
Voicing assimilation of "s": mismo is pronounced [ˈmizmo] rather than [ˈmismo], etc.
In some dialects the dropping of syllable-final "s" affects the quality of the preceding vowel and creates a phonemic distinction between, for example, todo [ˈtoð̞o] and todos [ˈtɔð̞ɔ].
@Wikitiki89: Sure, or the peninsular distinction--pronouncing "s" as "sh". But the spelling is a virtual free-for-all as in English. I don't know of any language anywhere near the size of Spanish where spelling can be inferred from sound and vice versa as well. —Justin (koavf)❤T☮C☺M☯15:40, 8 September 2015 (UTC)[reply]
@Wikitiki89: Well, we may have been saying the same thing the entire time but my point was that although Spanish--like any language--is not perfectly phonetic, it is far more regular than the language that we are using right now. Especially when one considers that Spanish has about 600 million speakers. As a general rule of thumb, the language is phonetic but with some necessary explanation. I don't think it's really cringe-worthy when someone says, "Turkish is phonetic" because that is a meaningful statement. Maybe not a perfect one but still a useful one for understanding that spelling is very standardized and maps to pronunciation in a predictable way. (In point of fact, this reminds me of when I worked in a bookstore and a Turk asked me in which "ay-zul" a book was--she meant "aisle".) —Justin (koavf)❤T☮C☺M☯15:56, 8 September 2015 (UTC)[reply]
First of all, English is much more phonetic than people give it credit for; there are just a lot more rules to learn. Second of all, the fact that you just said that Turkish spelling is standardized, proves that it is not a phonetic language for speakers of less standard dialects (a truly phonetic language would not have a standard and everyone would write in their own dialect, which is almost the case for Serbo-Croatian). Third of all, there is big difference between "far more regular than [English]" and "almost entirely phonetic". --WikiTiki8916:49, 8 September 2015 (UTC)[reply]
@Wikitiki89: What I meant that if you hear Turkish, you will know how it's spelled and if you see something spelled in Turkish, you will know how to pronounce it. Not anything about a standard register. This is not even close to true for English and if you have a huge panoply of rules to remember, then you don't have very phonetic spelling--that's what makes spelling phonetic. If you hear English and try to transcribe the sounds using the ISO-standard Latin alphabet, you can get all kinds of spellings and many of them not close to proper English. This is not true for Spanish. In fact, this is empirical: we could take native and non-native speakers and have them transcribe sounds or guess how words are spelled and we would find that they would be much more accurate for Spanish or Turkish than for English. That's all I'm claiming and I think that anyone wouldn't make a more over-reaching claim about any language being perfectly phonetic or without variation over time and space. —Justin (koavf)❤T☮C☺M☯17:28, 8 September 2015 (UTC)[reply]
You're right that if you see something spelled in standard Turkish, you will know how to pronounce it in the standard language (and not counting the exceptions that I presume exist but do not know about, having never studied Turkish). I don't know what you mean by transcribing English with the "ISO-standard Latin alphabet", but the average English speaker would be able to accurately transcribe spoken English into written English, even when this speech contains words not previously known to the listener. A non-native English speaker who is not very proficient would not be able to. But the same goes for Spanish and (I presume) Turkish. If you heard a Spanish speaker say [ˈtɔð̞ɔ], you might mistakenly transcribe it as todo, depending on your familiarity with this class of dialects. You might also hear [ˈla.o] and not know whether to transcribe it as lado, lago, or lavo. --WikiTiki8917:56, 8 September 2015 (UTC)[reply]
Acehnese was formerly written in Arabic script, per WP and Philip A. Luelsdorff, Orthography and Phonology (1987, →ISBN, page 136. Banjarese either formerly was or still is written in Arabic. Old Javanese was written in Javanese script. I'll update the modules accordingly.
The Algonquian translation I have simply removed (wrong script and part of speech).
The Chinese-script-Chamorro was a typo (of the language code cmn as ch, clearly mnemonic for "Chinese").
I have some words from two languages of the Russlanddeutsche which I would like to add, but we need to decide how to encode them.
The Volga Germans speak primarily Rhine Franconian dialects[1] (with some Russian loans like Erbus(“watermelon”)),[2] similar to the Pennsylvania Germans. We could treat Volga German under the code gmw-rfr which we recently created for the Rhine Franconian varieties of Germany proper (at which point it would probably make sense to also merge Pennsylvania German into that header). In favour of this are the arguments that Volga German, Penn. German and Palatine German have remained very similar despite their geographically separate development, and having separate headers will result in many pages looking like Wasser does now. Some references, like the Pfälzisches Wörterbuch, do treat Volga German, Penn. German and Palatine proper as one language with a huge variety of dialects (since both Volga German and Palatine proper have quite a few dialects). Alternatively, we could treat Volga German as its own language (say, gmw-vog). In the past, we have tended to give lects their own codes if they developed independently due to geographic isolation, even if they didn't develop to be very different: hence not only Pennsylvania German but also Transylvanian Saxon, Hunsrik, Alemán Coloniero and other lects have their own codes separate from their parent varieties. And there is another argument: Volga German is not entirely Rhine Franconian; it developed in communities made up of people from all over (Alsace, Baden, East Central German areas, Sweden, etc), and hence it is in practice a mish-mash in which Rhine Franconian is merely the most dominant element (this is also true of Penn. German).[3][4] Several references treat Volga German as its own lect, though most of them comment on its similarity to Penn. and/or Palatine German. See User:-sche/Volga for a sample and comparison.
The Russian Mennonites spoke Mennonite Low German, a.k.a. Plautdietsch. At the momet, our only ==Plautdietsch== entries are from American communities; I'd like to include historical texts from those communities while they were still in Russia, and texts from the communities which remain in Russia, under the same L2. Plautdietsch is distinguished from German- and Dutch- Low German by some phonological changes (especially to k) which hamper mutual intelligibility, but within Plautdietsch the distinction between American and European is only as notable as the distinction between Chortitzaer and Molotschnaer, and the references I can find treat the American and Russian (and Chortitzaer and Molotschnaer) varieties as the same language. See User:-sche/RMLG for a comparison: the principle distinction is that American MLG has [c], written 'kj', where Russian MLG has [tʲ], written 'tj'. To re-iterate, I'd like to add Russian Mennonite Low German under our existing Plautdietsch header with {{label}}s and {{a}}s, rather than giving it its own header.
Note that there are and historically were other Germans in Russia (e.g. Swabian speakers in some places), but I'm content to leave them undiscussed for now because I don't have words from them yet. (I intend to start a thread about the Danube Swabians later.) - -sche(discuss)21:48, 4 September 2015 (UTC)[reply]
^ Journal of the American Historical Society of Germans from Russia, volumes 15-16, (1992). The word stems from Russian арбуз(arbuz), and has been retained even by communities that left Russia for Kansas (Russian words in Kansas: Russian words current among [Volga Germans] in Kansas, in Dialect Notes, volume 4) and Argentina (Veröffentlichungen des Instituts für Volkskunde der Unviersität Wien, volume 4 (Verlag A. Schendl)
^ Peter Rosenberg, Die Sprache der Deutschen in Rußland
^ Fred C. Koch, The Volga Germans: In Russia and the Americas, from 1763 to the Present
I'd lean in favor of a separate language code for Volga German, for the reasons you mention. (Is it never written in Cyrillic?) And I'm in favor of treating pdt as one language with a Russian dialect and an American dialect—or rather, a North American dialect, since isn't Plautdietsch also spoken in Canada and Belize? —Aɴɢʀ (talk) 08:04, 5 September 2015 (UTC)[reply]
No; modern Plautdietsch in both the Americas and Europe blends elements of the Chortitza and Molotschna varieties. For instance, early references note that /tʲ ~ c/ (from original */k/) originated as a Chortitza feature, but it is now found everywhere. Also, in the early period Molotschna had [uː] in words like 'Fru' and 'Hus' while Chortitza had [yː], but the references I looked at noticed speakers of both varieties using the other's form. One says that before WWII, "the Chortica rounded front vowel [yː] was replaced by the Molotchna long back vowel [uː], as in [fryː] - [fruː]", while another says that after the war, the "dominierende [Molotschnaer] Varietät setzte sich gleichwohl nicht in allen primären Merkmalen durch, sondern nahm z. B. aus der rezessiven [Chortitzaer] Varietät den Umlaut langes yː statt langem uː (fryː statt fruː 'Frau', hyːs statt huːs 'Haus')". (It has been suggested that the switch to the otherwise less prestigious but older and more original Chortitza form was a way of defiantly resisting Russian pressure to become more Russian.) - -sche(discuss)18:03, 5 September 2015 (UTC)[reply]
re Cyrillic: I would expect Russian-language texts to mention individual Volga German words in Cyrillic the same way English texts mention Russian in transliterated form, but I can't even find examples of that, searching the web for Cyrillizations of common words, like "бам|баам|ман|манн" поволжские немцы. The printed as well as the handwritten texts in the language that I've seen are in Latin script, and the one Russian-language reference I have prints all the Volga German words in Latin script. - -sche(discuss)21:39, 8 September 2015 (UTC)[reply]
I have added "Mennonite Low German", "Chortitza", "Molotschna", and "Russian Mennonite Low German" as alt names of pdt and will add content from Russia/Ukraine-based communities under that code soon. I have not yet added a code for Volga German. I recognize that the weight of precedent regarding European languages is behind giving it its own code, and I have a weak preference for that myself. I worry that it does show "our" bias ("our" meaning not just Wiktionary, but the various generally European- or American-authored reference works on the languages themselves which we consult), however: that various mutually-intelligible shades of European languages are often treated as distinct while mutually-intelligible shades of African languages are often handled as single languages. - -sche(discuss)21:39, 8 September 2015 (UTC)[reply]
Greetings! The Individual Engagement Grants program is accepting proposals from August 31st to September 29th to fund new tools, community-building processes, and other experimental ideas that enhance the work of Wikimedia volunteers.
Whether you need a small or large amount of funds (up to $30,000 USD), Individual Engagement Grants can support you and your team’s project development time in addition to project expenses such as materials, travel, and rental space.
There is less than one week left to submit Individual Engagement Grant (IEG) proposals before the September 29th deadline. If you have ideas for new tools, community-building processes, and other experimental projects that enhance the work of Wikimedia volunteers, start your proposal today! Please encourage others who have great ideas to apply as well. Support is available if you want help turning your idea into a grant request. I JethroBT (WMF) (talk) 15:31, 24 September 2015 (UTC)[reply]
I've thought about this for years, and haven't floated the idea before for fear of starting an ugly shitstorm of useless argument, but it's continued to bug me.
Wiktionary is not for biographies, but we have a lot of words that derive from proper nouns. It would make sense to me to include definitions for those base terms that have gone on to form other words. I'm not proposing lengthy biographies, just who a person is with a link to their Wikipedia article, and only for the form of their name which has been productive.
We have entries for Hemingwayesque and Hemingwayan, so we should include a biographical definition at Hemingway (e.g. "Ernest Hemingway (1899–1961), American writer and journalist") and list the derived terms. Keeping with the current rules, we don't need an entry at Ernest Hemingway nor Ernest Miller Hemingway, as they are not productive terms and don't forms other words.
Similarly, we have the word Obamacare, so we should include a short biographical definition at Obama (but not at Barack Obama, nor Barack H. Obama, etc). Notably, Obama already has a biographical entry in defiance of the "no biographies" rule.
We have the term Darth Vader, as in "the Darth Vader of", but because of strict adherence to the "no biographies" rule, there is no definition for the fictional character w:Darth Vader himself. As such, the entry is ridiculous, redeemed only slightly by squeezing the fictional character into the etymology. You don't need to go to the discussion page to know there's been some weird argument that has lead to the elephant-in-the-room definition list. The attributive use derives from the fictional character, so he should also get an entry at Darth Vader (but not Vader, nor Anakin Skywalker unless they also have derived terms).
Darwin has a lengthy list of derived terms but the entry awkwardly squeezes mention of Charles Darwin into the "A surname" definition.
You can have "a Picasso" (a work of art by Pablo Picasso), so Picasso himself should get an entry at Picasso. And under the Spanish heading I see he's snuck in.
Sorry to kick up this argument again, but it seems like a no-brainer to me, and in many cases it's what's already seems to be happening. If a name is productive, that form of the name should be allowed a definition. If nothing else, it will allow some consistency for what is already being added. If there are too many odd cases, we could restrict it to only those people who are "notable enough" to have Wikipedia entries. And again, only the productive/attributive form of their name, not the Wikipedia article name. Thoughts? —Pengo (talk) 00:10, 8 September 2015 (UTC)[reply]
@Pengo: This issue is completely legitimate and probably thorny. We have commonly-used derivations like "Orwellian", "Kafkaesque", and "Dickensian" but I also added this change to Volapük and had it removed. Maybe constructions like this need to have a kind of secondary citation threshold: not only must someone coin the term "koavfesque" but someone also needs to comment on that usage ("It seems that the sorry state of public infrastructure is being described by both conservatives and liberals as 'koavfesque', meaning truly pathetic and dilapidated...") Does that make sense? —Justin (koavf)❤T☮C☺M☯02:49, 8 September 2015 (UTC)[reply]
I see nothing ridiculous about providing an etymology for Darth Vader noting the origin of the name as a fanciful coinage for a fictional work. bd2412T03:20, 8 September 2015 (UTC)[reply]
We have reasonable dictionary definitions for several people who are known just by their surname. Hitler is a reasonable example. This sort of thing is good to have in a dictionary. We should have more of them. SemperBlotto (talk) 07:42, 8 September 2015 (UTC)[reply]
Sure, but that's kind of my point, that we have an entry for "a Picasso" but, by our current guidelines, Picasso himself shouldn't have a sense.
I had another read of the CFI guidelines. I thought there was some kind of ban on biographical entries (perhaps because of the Darth Vader kerfuffle, or perhaps because it basically doesn't mention them at all), but the guidelines only exclude names of people that are made up of 2+ words:
No individual person should be listed as a sense in any entry whose page title includes both a given name or diminutive and a family name or patronymic. For instance, Walter Elias Disney, the film producer and voice of Mickey Mouse, is not allowed a definition line at Walt Disney.
So really this only excludes Darth Vader, which is kind of a bit silly and arbitrary, but otherwise biographical entries are basically ignored by CFI. Perhaps they could be made more explicitly allowed, with some notability guidelines.
I think I'm in the minority, but my feeling has always been that we should WP-link to famous names like Einstein from our entries (under "See also", or conceivably "Derived terms") without attempting to "define" them ourselves. People are individuals who bear a name, not a sense or meaning of the name. People are not semantic. Having said that, I have come across hybrid "encyclopaedic dictionaries" (Oxford has or had one) that do include such entries, but I've found that they tend to be poor dictionaries and even worse encyclopaedias. Okay, we don't have the lack-of-paper problem, but WP is always going to be superior on encyclo coverage, and we should exploit that rather than doing some dubious weak copying of a fraction of its entries. Equinox◑01:25, 9 September 2015 (UTC)[reply]
Of course people are semantic. It's just that names are often not unique globally, so their meaning is context dependent. But that's nothing new; every noun preceded by the is also context dependent. Names can be considered to have an inherent definite article in them. Some languages actually do use a definite article with names, too. —CodeCat01:51, 9 September 2015 (UTC)[reply]
Bearing in mind my suggestion that "people are individuals who bear a name, not a sense or meaning of the name", would you then support a sense at Smith for every individual mentioned attestably (e.g. 3 mentions! CFI) as "Smith"? That's gonna be a long entry. Equinox◑02:10, 9 September 2015 (UTC)[reply]
BTW, the "several Picassos" thing is almost a red herring to me, since you can pluralise surnames qua surnames (e.g. "I'm going to see the Smiths"). This then just becomes the combination of two rules: (i) you can pluralise a surname, (ii) a surname can stand in for a work by a person who bears that name. Equinox◑01:26, 9 September 2015 (UTC)[reply]
@CodeCat For me, the evidence that the person's name has become "semantic" in language is when his or her name is used as a base of other words or meanings. E.g. "Darwinian" or "Hitlerite". I don't think you can argue very strongly that "Darwin" or "Hitler" are just names with no particular meaning any more, evidenced by the fact their names have branched off into new words. So we should try to capture what that base word (name) lends to its derived terms. We're certainly not trying to replicate Wikipedia. All cases I've seen link there with about as much text as a Wikipedia disambiguation page listing. See any of the above examples. But having the fictional character "Darth Vader" under "See also" for "the Darth Vader of..." is just silliness to me. Having it under "Derived terms" would be the wrong way around, and an attempt to downplay a main meaning of the term. Pengo (talk) 16:09, 9 September 2015 (UTC)[reply]
@Equinox I feel that someone could list "a Picasso" or "a Rembrandt" in any list of random items and it would be understood to specifically mean a painting by that painter by most English speakers, and that someone might legitimately look up "Rembrandt" or "Rembrandts" trying to understand its meaning, e.g. having seen it without enough context to guess what it meant, perhaps confusing it for "a Remington". So perhaps the pluralization part is a red herring, but it still seems dictionary-worthy from a "what does this usually mean in English" viewpoint, and doesn't apply equally to all surnames. Pengo (talk) 16:09, 9 September 2015 (UTC)[reply]
Agreed: Obama (Obamacare), Dickens (Dickensian), Picasso (Picassian), Darwin (Darwinian), Popper (Popperian), Kuhn (Kuhnian) should have a succinct biographical sense lines, or they should have ", especially ..." parts of the surname sense line. Here's what dicts do:
@Equinox: What is the rationale for excluding these? (They are not excluded by the current CFI.) Is it the redundancy to Wikipedia? If so, should Nile be reduced to "a specific river" to minimize redundancy? Is there at least one dictionary that does such a minimization of "Nile"? --Dan Polansky (talk) 09:49, 13 September 2015 (UTC)[reply]
If I take your "People are not semantic" above as the rationale or part of the rationale, do we really mean that referents of proper names are not semantic and should therefore be excluded or reduced? I saw that position before. Applied to extreme, each geographic name would have a single sense line saying just "a geographic name"; even "a specific river" would be too specific; and each astronomical name would say "astronomical name" instead of "an autumn constellation of the northern sky" (Perseus). If this position that referents must be excluded or obscured as far as possible is accepted, I don't see why it should be only accepted for biographical names and not for geographic names or astronomical names. --Dan Polansky (talk) 10:55, 13 September 2015 (UTC)[reply]
Re: "would you then support a sense at Smith for every individual mentioned attestably": That's a good point. As a practical matter, we do not want to include a sense line for every attested human individual. That's why the name as referring to the individual should overcome additional hurdles, such as that it gave rise to an adjective or that it is broadly understood to refer to that individual when used out of context. Other hurdles can be come up with. The hurdles are not specified in CFI, but CFI allows editors discretion in deleting proper names and their senses, via RFD of course. --Dan Polansky (talk) 11:12, 13 September 2015 (UTC)[reply]
I have some words from Sathmar Swabian which I'd like to add, but as with the Russia German languages I mentioned above, we need to decide how to encode them. The Sathmar Swabians inhabit a region on the border of Hungary and Romania, having migrated there from Swabia, and they speak a dialect of Upper Swabian which has remained very similar to the varieties of Schussenried and Otterswang in Germany. As I noted above re Volga German, we have on the one hand tended to give lects their own codes if they developed independently due to geographic isolation, even if they didn't develop to be very different (see e.g. Pennsylvania German, Transylvanian Saxon, etc). On the other hand, the variation which does exist between Sathmar Swabian and Upper Swabian proper is comparable to the variation between Upper Swabian and other dialects of Swabian (which are incidentally usually the sources of the differences), which we don't split, and of the four people who are said to be the main scholars of the language, Moser and Stephani speak of it as 'the Sathmar dialect (Upper Swabian)'. (I can't determine the stance of the other two scholars, Fischer and Wonhas. De.WP implies that Fischer considered it a dialect, but I don't see where it's covered in his comprehensive Schwäbisches Wörterbuch, perhaps because I'm missing some obvious terminological difference or perhaps because he doesn't actually include it.) I have a weak preference for treating Sathmar Swabian as its own language, but compare my comments in the section above, re Volga German, about "bias". You can gauge the similarity of the lects yourself at User:-sche/Sathmar. - -sche(discuss)01:24, 9 September 2015 (UTC)[reply]
How to deal with formations that have no overt phonetic or orthographic form?[edit]
There are many cases where a suffix has been reduced to zero, but its effects can still be seen through other grammatical processes. For example, in Northern Sami, the present participle has no actual suffix, and is characterised purely by strengthening the consonant grade. The Estonian genitive case has no actual suffix, but is apparent through consonant gradation, and because the stem-final vowel is not deleted as in the nominative. I am wondering how we could create entries for these. There's no actual suffix to use as the page name, but detailing the function and (especially) etymology would be useful nonetheless. So how should I do this? —CodeCat23:39, 8 September 2015 (UTC)[reply]
I would suggest an appendix, such as Appendix:Arabic verbs, which details Arabic verb classes, some of which are characterized by the doubling of the middle root letter, which is very similar to the issue you are dealing with with Northern Sami. --WikiTiki8914:33, 9 September 2015 (UTC)[reply]
Uralic morphology is almost entirely suffixing though, so such an appendix wouldn't give much extra value. The difficulty here is only that the actual suffix has eroded due to sound changes, leaving some other effect as a residue. But the suffix is still "real" and its identity can be etymologically established, unlike the vowel changes of Arabic. For the Northern Sami present participle for example, the present participle can be traced to a suffix *-jē, which has disappeared after a sound change that deleted intervocalic -j- with compensatory lengthening of the preceding consonant, and changes to the vowels. While there is no actual suffix, there is still conceptually a suffix that causes this effect when attached.
My own thought is to use the entry - for cases like this. It could also be used, for example, to explain the zero plural suffix in sheep (which goes back to Proto-Germanic *-ō). —CodeCat19:11, 9 September 2015 (UTC)[reply]
But you can't really say it's a suffix anymore at that point, rather a morphological feature. There is no longer any suffix in the plural of English sheep, even if the singular and plural are derived from previously distinct suffixes. You could say that in Russian, there is a null suffix in the nominative of masculine nouns, which also causes epenthetic vowels when it follows a consonant cluster. So I guess you could treat this Northern Sami thing as a null suffix as well, but you would have to think about whether that actually makes sense. Even if Uralic morphology is almost entirely suffixing, an appendix would still be useful. It does not have to be exactly like the Arabic one, since this is a completely different situation; the reason I compared it to Arabic is that some verb forms (such as form X) can be simply analyzed as prefixes (اِسْتَـ(ista-)), while others (such as form II) are characterized solely by the doubling of the middle root letter, which cannot be represented as an affix or infix in any way that makes sense. For Northern Sami, you could create an appendix detailing verb conjugation and participle formation (if it is all suffixes as you say, this page would be short and sweet), and for Estonian you could create an appendix detailing noun morphology (which would also be short and sweet). --WikiTiki8919:59, 9 September 2015 (UTC)[reply]
Zero suffixes are sometimes theoretically justified, but I'd think they pretty clearly should not be dictionary entries. A separate appendix page could be useful in some cases though, I suppose. --Tropylium (talk) 20:19, 9 September 2015 (UTC)[reply]
I personally don't very much like it, but I could be convinced of its usefulness. In the case of снос(snos) and similar, I think it would be better to just say "From сноси́ть(snosítʹ)". --WikiTiki8922:03, 9 September 2015 (UTC)[reply]
This is a very good reason to have entries for such derivations. We certainly would want derivation lists and categories for them. I think Cinemantique's solution is pretty good, and I think I'll use it as well unless there are bad objections (as well as good alternatives). —CodeCat23:07, 9 September 2015 (UTC)[reply]
Categorizing zero derivatives sounds like a good idea (including things like bug, drink), but surely this can be done without treating zero suffixes as entries. That's kind of the point after all; these are forms that are morphosyntactically treated as derived while being lexically underived.
Note that this is a distinct issue from stem alternations or the like as allomorphs of productive inflectional suffixes — in those cases there's full reason to have a suffix entry in the first place, and given out habit of linking allomorphs to the same entry, there should be no obstacle to doing something like {{suffix|stem|suff|alt2=∅}}. But then again, since when do we link inflected forms to their suffixes anyway? --Tropylium (talk) 07:09, 10 September 2015 (UTC)[reply]
If we're going to do this, -∅ does seem like the logical notation to use (or at least, to display; perhaps we could rig it up so that the link went to the appendix: -∅). But we do have to be careful when deciding where to do this; I agree with WikiTiki that it would be inaccurate to describe English "sheep" as having a suffix. - -sche(discuss)01:11, 10 September 2015 (UTC)[reply]
I like the idea of explaining the suffixlessness, but using a -∅ seems overly jargony to me. Why not write a plain English explanation as has been done above, and add it to the entry (either as a line in the etymology or in a "Grammar notes" section), saying something like what has been said from above, "The present participle has no suffix, and is characterised purely by strengthening the consonant grade" or something more easily understood. If this text needs to be repeated on many entries then make a {{suffixless}} template and use that. I don't know how common -∅ notation is, but I suspect it's not common enough to help casual readers of Wiktionary. Pengo (talk) 13:54, 13 September 2015 (UTC)[reply]
Empty suffix looks like an inferior idea. To derive Russian снос as сносить + -∅ looks most curious to me. Suffixing is a process of adding something; if nothing is added, no suffixing takes place. google books:"empty suffix" does not seem to find many hits from linguistics; most seem to be computer science. --Dan Polansky (talk) 19:12, 13 September 2015 (UTC)[reply]
We already have "New Latin" for Latin words coined in modern times. But Ancient Greek words are also made anew, often for scientific purposes, by combining ancient elements. Should there be a separate "New Ancient Greek" etymology language for these, to match how we treat Latin? —CodeCat22:48, 12 September 2015 (UTC)[reply]
In taxonomy, at least, Greek is Latinized before being incorporated, so that even terms composed of Ancient Greek parts are really Latin (although there are a number of taxonomic names that show Ancient Greek nominative endings, I've never seen one that used Ancient Greek genitive endings instead of Latin). I'm sure this is true throughout the sciences. Chuck Entz (talk) 01:16, 13 September 2015 (UTC)[reply]
Ancient Greek was not used in the scientific community and therefore the statement that "Ancient Greek words are also made anew, often for scientific purposes" is false; words may be made from Ancient Greek roots but not actually reflect words in Ancient Greek. The same is true of many scientific coinages from Latin nowadays, but until the 19th century most of them originated in New Latin texts. Therefore there would really be no use for this. —Μετάknowledgediscuss/deeds01:38, 13 September 2015 (UTC)[reply]
It's not just the roots that are Ancient Greek though, the derivational rules used to create the combination are also Ancient Greek. Everything about the words is Ancient Greek, except that they're not used in Ancient Greek. They are Ancient Greek words coined for the sole purpose of deriving loanwords from them. Does that make them words or not? Not in the usual sense, but to say that they are "not words" doesn't seem right either. They're like limbo words. —CodeCat02:55, 13 September 2015 (UTC)[reply]
Well, no, not everything. As Chuck already pointed out, they are almost always Latinised. In any case, we document words that are used, and those in limbo can never have entries, and thus never be an etymon. It's like reconstructing a word in a protolanguage for a modern concept just because all the descendant languages use cognate terms for it; it could be done, but has no lexicographical validity. —Μετάknowledgediscuss/deeds03:57, 13 September 2015 (UTC)[reply]
Examples? I think the idea is worth entertaining (though I'd unlikely be expert enough to weigh in). But I feel we really need some examples of potential modern Ancient Greek words for any meaningful discussion. —Pengo (talk) 13:34, 13 September 2015 (UTC)[reply]
I think we're talking about two different things here. I'm talking about Ancient Greek words that are coined to serve as a base for derivations in various languages. Things like hypothermia. I am aware that these words have never been actually used in Ancient Greek, but to ignore their existence altogether seems wrong too. —CodeCat15:15, 13 September 2015 (UTC)[reply]
Something like that, yes. They are not reconstructed terms though, since we know they weren't used. Reconstructions are assumed to have been used, just unattested. —CodeCat15:53, 13 September 2015 (UTC)[reply]
@CodeCat: Normally we would pick the language which coined "hypothermia" first, and that one gets a list of descendants. Otherwise what would we do with television? Create a "New Ancient Greek-Latin hybrid" language to list its cognates? I think the real issue here is that there's no consistent way to list and/or tag cognates, especially when the language it was originally coined is not clear, i.e. when there's no clear descendent-relationship. Other than listing descendants, what other benefits are there to New Ancient Greek? Are Ancient Greek grammatical rules applied to hypothermia (or other such terms) which are reflected in multiple descendent languages [and wouldn't those rules be the same just for 'thermia', θέρμη(thérmē), anyway]? —Pengo (talk) 01:19, 14 September 2015 (UTC)[reply]
A userpage appearing without ever being created is quite surprising at first. Since it is clearly self-advertizing, it has nothing to do here but it also seems to be undeletable. Thank you 08:10, 13 September 2015 (UTC)
(edit conflict) The actual page is on Mediawiki, but it shows up on every Wikimedia wiki that doesn't have a page by that name. The only way to get rid of a global user page here would be to create a page (even a blank one) to replace the global page locally. That said, I'm not sure that global page is actually advertising, though it probably doesn't meet the standards in WT:USER. We haven't really worked out how to respond to global user pages, yet. Chuck Entz (talk) 08:16, 13 September 2015 (UTC)[reply]
In fact it's not really advertizing (at least not "classical" advertizing), but if the page was directly created here, it would certainly have been deleted for being "promotional material" (and perhaps the user blocked indefinitely), as far I can see. Am I wrong? Bu193 (talk) 08:28, 13 September 2015 (UTC)[reply]
Intransparent headwords for Ancient Greek entries[edit]
I noticed a bot introduced intransparent headwords into headword lines of Ancient Greek entries. For Εὐριπίδης, the transparent headword was Εὐριπίδης while the intransparent is "Εὐρῑπίδης". Can User:Benwing, the owner of the bot, point me to the discussion that lead to that change? Thank you. --Dan Polansky (talk) 13:24, 13 September 2015 (UTC)[reply]
No, Dan isn't a troll- he takes himself way too seriously for that. As far as he's concerned, he's the last barrier standing between Civilization As We Know It and Tyranny And Chaos. On occasion, that's not that far from the truth. The problem is that he's so used to seeing himself as this principled Defender Of Truth, that he often can't see it when his own personal grudges take the place of his principles. Chuck Entz (talk) 21:13, 13 September 2015 (UTC)[reply]
@Chuck Entz: I apologise for my outburst. I should've written something like what was written by Μετάknowledge in Wiktionary talk:Votes/pl-2015-09/Using macrons in headword lines of Ancient Greek entries#Status quo ante, viz. “your statement of status quo ante is inaccurate. This [discussion] is pointless, and the issue belongs only among Ancient Greek editors, who already have a clear consensus (as you can see from the response [herein]). You are clueless about what has been going on”. @Dan Polansky: Perhaps you don't realise how profoundly irritating it is to have an editor completely unfamiliar with a language-editing community's practices (I have never seen you make a non-trivial edit to Ancient Greek content) come in, revert a completely routine and uncontroversial edit, demand an essay in justification of that edit, begin litigation when that demand is refused, and then dismiss the response of an editor from that community (when he finally concedes) as “a joke”. Your meddlesome, holier-than-thou manner endears you to no one. — I.S.M.E.T.A.20:34, 15 September 2015 (UTC)[reply]
@Dan Polansky: I'm a little confused. Is the claim that using macra lacks transparency? We put diacritics outside the normal written orthography in the headword all the time (like Latin macra). Why is this a problem? —JohnC515:06, 13 September 2015 (UTC)[reply]
It has been the case in Latin that macra should be used within Latin entries for a long time. The use of macra has been specified in WT:ALA and WT:AGRC for quite a while. Any entries that do not contain macra are ill-formatted and should be updated. The status quo has always been for their use. —JohnC519:17, 13 September 2015 (UTC)[reply]
As for Latin, my memory must have failed me; I now recall that macrons were used as long as I can remember. My mistake. As for Ancient Greek, let us have a look at WT:AGRC. This revision from 6 May 2012 tells me, on a slightly unrelated subject, that "Vowel length marks (i.e. the macron and breve) should not be used outside of Ancient Greek entries", which is relevant for the appearance of Ancient Greek in Euripides, which "I'm so meta even this acronym" protected to have his way contrary to WT:AGRC from 6 May 2012. Meanwhile, someone changed WT:AGRC to no longer state that. I admit that the same revision states that 'Secondly, headline templates, such as {{grc-noun}} have a "head" parameter, which can take vowel marks.' I admit my mistake since WT:AGRC suggests allowed use of these on the headword lines. Nonetheless, I point out that this was not an actual widespread practice before the bot run, as far as I remember (but do I remember this correctly?). Be it as it may, it may well be that there never was any controversy about the use of macrons in headword lines of Ancient Greek entries, and that I am quite mistaken here. Whatever the case, the vote should clarify that. --Dan Polansky (talk) 19:39, 13 September 2015 (UTC)[reply]
FWIW, I (as well as ISMETA and ObsequiousNewt) have been using macra in AG for a full year now and the new {{grc-decl}} requires them for correct functionality. —JohnC519:53, 13 September 2015 (UTC)[reply]
I've been using macrons in grc exactly the same way as in Latin (i.e. everywhere except page names) ever since Module:languages/data3/g was edited here in January 2014 to automatically strip them in links. Breves have been stripped since October. I see no reason not to take advantage of this functionality, nor do I see any way in which doing so is "intransparent". —Aɴɢʀ (talk) 13:52, 14 September 2015 (UTC)[reply]
There are a bunch of translations labeled as "Waray" (code wrz) with the code for Waray-Waray (war). These are two distinct languages. Can they all be switched to one or the other, or is there a mix of both languages that need careful separation? DTLHS (talk) 20:32, 14 September 2015 (UTC)[reply]
Wiktionary:Votes/Timeline (current revision: 29123778) has not been updated with new finished votes since 2013. The page is a bit messy, so I am thinking of maybe cleaning it up as a whole when I have the time. I am creating this BP discussion, as opposed to an RFC, because that's a personal project that I intend to do myself, not a request for others. (but if someone else beats me to it, that would be great, too).
Here's a list of what I intend to do. Please say whether you support doing it that way or if you'd rather it done differently.
Using the table format (which is being used in votes from 2004 to 2008) in all of the votes.
Merging the sections "Archived votes" and "Policy votes", since the division seems pointless in the first place and the former has plenty of "policy votes" to boot. (not to mention that "Archived votes" and "Policy votes" are ordered in opposite directions)
Editing the date: leaving just year-month (as in, "2008-12") as it's done since 2009 and not year-month-day like it was done between 2004-2008 (using multiple time formats). Maybe I'd use a single date template to format it consistently across the whole page.
Probably more things that I haven't brought up before but would post here before proceeding. Anything that's inconsistent and can be fixed easily. One minor thing:
I oppose using a table format in Wiktionary:Votes/Timeline. The current list format is nice enough, and easier to create for any archiver. People started to use the format on WT:VOTE itself (at the bottom), which makes archiving WT:VOTE easier. Keep things simple. --Dan Polansky (talk) 08:38, 20 September 2015 (UTC)[reply]
As for "Policy votes", that is a selection that I created in 2010. It is admittedly out of date, but there is nothing to be "merged"; it would have to be removed. As it is now, most people will see it is out of date, I think, and it still adds some value. I think it would better to update it; a guide for it is at Wiktionary_talk:Votes/Timeline. --Dan Polansky (talk) 08:38, 20 September 2015 (UTC)[reply]
Based on the multi-language system of Template:list:chess pieces/pt (which I had created pre-Lua), I created a system of tables that can be used in multiple languages.
That's true. Category:English list templates has 91 members as of now. Many of those are lists of geography/places (countries, continents, oceans, states) which are probably better off the way they are, as lists rather than tables. The table of chess pieces has the advantage of being a simple eight-member group; lists with varying/unpredictable number of members (canids, religions, blues, reds) also probably should not be converted to tables either. --Daniel Carrero (talk) 14:35, 16 September 2015 (UTC)[reply]
Assuming we are going to start using this system for other tables in the future, (Disclaimer: I'm not proposing converting every list into a table, it's just that maybe there are other tables that it would be a good idea to have, after the chess thing.) I've been putting those in categories named like this:
Is this a good name? Obviously this is the best I could think of, but "auto-table" really does not explain that much, so I'm very open to other ideas. Or maybe it's a pretty good name anyway. --Daniel Carrero (talk) 07:51, 17 September 2015 (UTC)[reply]
I was curious about belpuga, because it is an entirely ordinary seven letter word apparently found (but marginally) in but one language, as far as Google Books can tell. So I downloaded the page titles, counting small all-lowercase words, to see what density we have of the possible space.
ASCII [a-z], one letter: 26 (possible 26)
ASCII two letters: 521 (possible 676)
ASCII three letters: 4656 (possible 17576)
ASCII four letters: 22800 (possible 450,000)
ASCII five letters: 71184 (possible 12 million)
ASCII [a-z][aeiou] or [aeiou][a-z]: 228 (possible 235) (missing qo, iq, iy, ub, uc, uj, uq)
ASCII [a-z][aeiouy] or vice versa: 259 (possible 276) (additionally missing qy, yc, yh, yj, yk, yp, yq, yv, yx, yz)
ASCII three letters, including [aeiou]: 3956 (possible 8315)
ASCII three letters, including [aeiouy]: 4170
[[:lower:]]: 630 (possible 1984 Unicode 8.0 characters, or 1492 excluding MATHEMATICAL Unicode characters)
lower * 2: 2239
lower * 3: 13089
(I don't know if :lower: would count the latest Unicode 8.0 characters, so maybe someone has added them.) I don't know how much this reflects us and how much anything in the world of languages. If anyone cares about noting alphabetic characters, there may be 800 characters that need some sort of "xxth character of the XXX alphabet".--Prosfilaes (talk) 23:28, 15 September 2015 (UTC)[reply]
Change the appearance of the "favourite languages" in translations[edit]
I don't know what this feature is called, but it's the one that shows translations of languages you select, in the top bar of the translation box, even when collapsed. I think this format isn't so useful, because there's no room for more than one or two languages. I think it would preferable if, instead of collapsing the box altogether, the box just collapsed smaller, and showed only the translations for the languages you selected. So in collapsed state, it shows favourite translations, and expanding it shows all of them. I'm thinking of something similar to how the inflection box works on muitalit. —CodeCat01:00, 18 September 2015 (UTC)[reply]
Should Min Nan entries in Pe̍h-ōe-jī have definitions (e.g. in pe̍h-ōe-jī), or should they be like the pinyin entries for Mandarin words (e.g. in pīnyīn), where the character form(s) of the romanization are linked? (This is probably a question about whether POJ is a main script used for Min Nan.) Justinrleung (talk) 01:18, 18 September 2015 (UTC)[reply]
(e/c) I think the main question is: do people communicate using POJ, or do they just use it to transliterate? As I understand it, one wouldn't normally write a letter or a book in Pinyin, Romaji, etc. when the audience was native speakers, except perhaps in dictionaries or language-education materials. In other words it's more about the characters/writing system than about the subject matter. It would also seem to me that texts intended to demonstrate how familiar subject matter looks when written in the script would also be about the writing rather than about the subject matter. There's a book, for instance, that has the Lord's Prayer in hundreds of different languages and scripts- I would consider it strictly on the mention side of the use/mention distinction. Chuck Entz (talk) 01:42, 18 September 2015 (UTC)[reply]
Since we include usage from throughout recorded history, that might not be a problem in itself, if it was in sufficient use at one time, though we have to be careful to avoid giving brief, failed experiments undue weight, and to be clear about the difference between historical and current usage. Chuck Entz (talk) 02:25, 18 September 2015 (UTC)[reply]
@Suzukaze-c Thanks for the link. However, a concern I have is that the current format for Chinese entries might make it redundant to have definitions in both the Chinese character entry and the POJ entry. Also, does that mean POJ entries should be linked in translation boxes? Justinrleung (talk) 00:22, 20 September 2015 (UTC)[reply]
I was just merging one section of the Translation section for "chaperone"/"chaperon". The German section has 11 terms - I think this is unhelpful - the user will eventually have to look at 11 pages to find out which might be the best. An editor should really do this for them by restricting translations to normally one (and occasionally two). In this case, IMHO, the reader would find Anstandsdame and then go to that entry to find those other terms, where their nature (dialectal, idiomatic, slang, insulting, … ) could be explained. — Saltmarshσυζήτηση-talk09:23, 18 September 2015 (UTC)[reply]
Earlier today, I attempted to add {{also}} to Northwest Territory and Northwest Territories, each linking them to the other. Seem to make perfect sense: people would confuse the defunct American jurisdiction with the still-existent Canadian one. The wording at Template:also seems to leave the door open for something like this, yet I was reverted (rather rudely, I might add) by User:Ungoliant MMDCCLXIV, who informed me that this template is only to alternate capitalizations and diacritics, without providing any actual reasoning why it should be limited to those things. Is there any good reason for constraining, and if not, can we allow use of Template:also in this relatively small case of proper nouns that are unrelated except for the fact that one is the plural of the other? Purplebackpack89
This is what the header See also is for, however {{also}} is for similar titles and I think it makes sense sometimes to have the disambiguation right at the top and not almost at the bottom in a see also section. How would you handle aliterate and alliterate? Renard Migrant (talk) 09:44, 20 September 2015 (UTC)[reply]
The good reason for placing a limit on what it included in {{also}} is to attempt to maintain its utility in its original intended purpose: helping users find what they wanted despite limited keyboarding skills or understanding of scripts with different diacritics. Homonyms in Pronunciation perform a similar function, though limited to same-language items. That {{also}} is placed above any L2 section suggests that its primary use is for resolving cross-language/cross-script confusion. The principal exception is that we use it for items in the same language that have different initial capitalization. Under the logic of the headings structure of our entries that would seem to be a mistake.
If someone were to want add to this confusion by including other kinds of confusions in those allowed in {{also}} above the first L2 or by using {{also}} within L2 sections, I'd like to see a proposal and a vote. DCDuringTALK11:12, 20 September 2015 (UTC)[reply]
@Purplebackpack89: Why is that? Because you can't afford it? Because you don't like the salesperson? Because you are unfamiliar with the research that shows that folks, when faced with a choice of ten items are less likely to make a selection or purchase of an item than when there are three? Or is it because you are aware of other research that contradicts this. DCDuringTALK15:33, 20 September 2015 (UTC)[reply]
I don't buy into it because it believe it to be not entirely true. I don't believe that {{also}} reaches its maximum utility by being limited in use. Correct me if I'm wrong, but your argument seems to be somewhat that if it was added to more entries, it wouldn't be as useful to the entries it was on originally (or at least before September 19, 2015). I disagree. I think if you add {{also}} to more entries, there is added utility for the entries it is added to, and consistent utility for the entries it was on before. Purplebackpack8916:19, 20 September 2015 (UTC)[reply]
I oppose this as well. But I should note that I have on occasion included {{also}} inside language sections. In these cases, there was possible confusion between different words in the same language, for example between c and č or e and é. —CodeCat14:51, 20 September 2015 (UTC)[reply]
Support. This is already how the template is used in practice. I've used it with malternative and mallternative, two words that have completely different meanings, but a variance in spelling of a single letter, and thus might reasonably be confused. It makes sense to disambiguate words that might reasonably be confused due to having very similar spellings. Placing an {{also}} template at the top of the entry is a simple, unobtrusive way to point readers in the right direction. Burying a link in a "see also" section probably isn't as helpful, since a reader who takes a wrong turn is likely to be unfamiliar with the structure of Wiktionary entries, and thus won't know to look in the "see also" section. This really shouldn't be controversial. Ultimately, it's about increasing the ease of use of this site for readers -Cloudcuckoolander (talk) 20:07, 20 September 2015 (UTC)[reply]
IMO, we are not yet to a point of near-consensus that would allow a good vote.
AFAICT, we have a few locations we can use to direct users to an entry with slightly different spelling:
{{also}} above the first L2 header (first and only choice for items with letter-by-letter correspondence (excepting diacritical marks and type case) to headword, but on different pages, in different languages.
{{also}} at the beginning of any L2 header (for items in the same language subject to confusion.)
{{homophone}} under Pronunciation header (first and only choice for words in the same language, with same pronunciation, but different spelling and derivation.
Under Alternative forms header (first and only choice for variations of the headword that fit under the same Etymology heading)
Under See also header {first choice for items that are not search targets for users coming to the page and L2, but which provide additional information of possible use to some users).
It would be nice if the solution for first L2 headers also worked for other L2 headers and worked under tabbed languages.
It seems to me that the use of {{also}} above first L2 would not work for languages that appeared below the English L2 section. It would also be conceptually different from the class of items under 1 above. Position 5 doesn't make much sense because it occurs too far down on large pages. The alternative forms and pronunciation headers don't fit the facts of the case. That makes me conclude that option would be the right choice in general. In other cases aesthetics might lead us to combine 1&2 and place it above first L2. DCDuringTALK00:45, 21 September 2015 (UTC)[reply]
Makes no sense. "See also" L3-section or L4-section is not for syntactic or morphological relations. {{also}} (previously {{see}}) is used to connect syntactic forms regardless of language. Regardless of language does not mean cross-language; it means that it does not matter whether it is within a single language or not. --Dan Polansky (talk) 08:37, 27 September 2015 (UTC)[reply]
I support to use {{also}} to conect "alliterate" and "aliterate". "Northwest Territory" and "Northwest Territories" is syntactically near enough to be connected with "also" as well, I think. --Dan Polansky (talk) 08:37, 27 September 2015 (UTC)[reply]
If they click on the accusative, they'll go to a form-of entry. If they click on the nominative, they'll go to the lemma, with all the important information, and the chances of there being a nominative entry are much higher than for an accusative entry. This is similar to the issue of higher-level taxonomic names, which are notmally derived from the genitive form of a generic name. I've been known to say "from X, the Y form of Z", but that can be a bit unwieldy.Chuck Entz (talk) 06:17, 20 September 2015 (UTC)[reply]
Some mention accusatives and some don't. The thing is, even if you had a policy for this (and some might say that's a step too far) you'd have to implement it by hand and that could take years. A bit like orphaning the abbreviation headers, there are thousands of them and they all need to be fixed manually. Renard Migrant (talk) 09:48, 20 September 2015 (UTC)[reply]
I think we should cite etyma in their lemma forms; this means saying that bœuf comes from bōs (not from bovem) and that chanter comes from cantō (not from cantāre). It just makes it easier for people to find the informative entry at first click. One possible compromise I've seen in some entries is to link to the lemma form but display both the lemma and the relevant inflected form, e.g. {{m|la|bos|bōs, bovis|ox}} or {{m|la|canto|cantō, cantāre|to sing}}. I'm not thrilled with that, as it strikes me as pedantic, but I can live with it. —Aɴɢʀ (talk) 13:48, 20 September 2015 (UTC)[reply]
I think that when the process is regular, we do not need to specify this on every page and we can just link to the nominative. In this case, French bœuf is regularly derived from the accusative of Latin bōs, because (almost) all French nouns derived from Latin are derived from the accusative. The same would especially be the case for French verbs (we should say that French prendre is "from Latin prehendō", not that it is "from Latin prehendere") because the French infinitive represents the whole paradigm just like the Latin first-person singular present represents the whole paradigm. In the case of irregular derivations from the nominative, we can specify that, for example, French fils derives "from Latin nominative fīlius". As for the English word beef, since it derives from (Old) French, and (Old) French regularly derives from Latin accusatives, we can simply say "from Old French buef, from Latin bōs". If English had taken the word directly from a Latin accusative, then we would have to specify. --WikiTiki8914:12, 20 September 2015 (UTC)[reply]
My practice is to link to the lemma but display the true antecedent. So I’ll have bovem and cantāre. Less clicking. Users should be able to spot the accusative forms and infinitive forms in the declension tables. --Romanophile (talk) 14:16, 20 September 2015 (UTC)[reply]
What about the other direction? I imagine it might be useful for ====Descendants==== sections to mention that they are generally derived from the accusative. --Tropylium (talk) 14:23, 22 September 2015 (UTC)[reply]
Not necessarily: regional sounds broader, as in maybe northern England as opposed to, say, Scouse. In other words, regional would encompass a number of dialects in a larger area, while dialectal would be in isolated dialects here or there. Of course, there's also the pejorative sense of dialect at play here: my usage is regional, yours is dialectal because it's in some obscure, out-of-the-way backwater that I don't care about... ;) Chuck Entz (talk) 14:16, 22 September 2015 (UTC)[reply]
That's how I understand it too. Polari is a dialect, but not regional. I can't think of anything that would be regional but not dialectal – even British English, Indian English, US English etc are dialects of a kind. (And that's another problem with regional – are we talking about a town or a continent?) Smurrayinchester (talk) 14:58, 22 September 2015 (UTC)[reply]
DARE documents a lot of differences in frequency of usage and pronunciation of words by region in the US, some at the level of city (NY, Chicago), parts of states, states, some over much larger areas (Southern US). I don't think that these vocabulary differences are sufficient to make a dialect. AFAICT linguists typically recognize only Appalachian English, and, sometimes, southern English as dialects. DCDuringTALK15:54, 22 September 2015 (UTC)[reply]
Labov et al's Atlas of North American English→ISBN describes layers of dialects in America, from 'South', 'Mid-Atlantic', 'Inland North dialect' and other broad dialects to 'New York City dialect' and other small dialects with are in some cases subsets of the broad dialects. I can imagine some people making a distinction between 'dialectal' and 'regional'; but the categories reveal that insufficiently many people imagine that there is a distinction, and they are in practice used interchangeably, with dialects described as regional (see in particular Category:Classical Hebrew and Category:Biblical Hebrew!) and the distinctive speech of regions (accurately IMO and per Labov) called dialectal. I favour making "regional" an alias of "dialectal". I wouldn't object to having "regional" display as such but categorize as "dialectal". I find the label to be uselessly vague, though: specify which regions, and then you needn't add a vague "regional" label, and if it's desirable that all regional/dialectal entries go into a single category, then make each label double-categorize into the specific category and the regional/dialectal category, rather than appending "regional" to only a small handful of the many entries that have regional (Southern US, Northern England, etc) tags. - -sche(discuss)15:35, 23 September 2015 (UTC)[reply]
The template {{calque}} has parameters to provide the source language term as well as the terms in the calquing language that the new term was made from. This is problematic, because it makes it impossible to provide more detailed etymologies using more fine-grained templates like {{compound}} or {{affix}}. In fact, many calques are also compounds, but are not categorized as such. I think it would make more sense and work better if, instead of putting this in antibody like now
I've now modified {{calque}} so that it works fine when no positional parameters are given. The entries that still do have them are at Category:calque with terms. There's quite a lot to do, and they can't be done by bot because it's not a given that {{compound}} should always be used. grammatical alternation for example is definitely not a compound. But then, we have never been very strict on what a compound is, some people treat anything made up of different parts as a compound. —CodeCat19:58, 27 September 2015 (UTC)[reply]
When did it become policy that you can't add a category to another category? This is unfair to users who can't code (i.e. most of us). Anyone should be allowed to put a category into another category, and we should not be forced to use User:CodeCat's confusing, elitist and generally unnecessary module system. Purplebackpack8921:29, 22 September 2015 (UTC)[reply]
Editing Wiktionary should be easy enough that we shouldn't compare it to surgery. You should be able to edit nearly all aspects of Wiktionary, including putting categories into other categories, without knowing how to code a module. Coding modules is really advanced stuff. Purplebackpack8921:34, 22 September 2015 (UTC)[reply]
If you are talking about your recent edit war with CodeCat about Category:Penutian languages, maybe you should wait WT:RFDO#Category:Penutian languages to end. Perhaps the problem is not that using modules is the "hard" way to use categories, I'd argue that templates/modules actually make the category system easier to manage as a whole, it is just that the category in question is not part of the system because nobody created a code for "Penutian". Assuming that the category fails RFDO it will get deleted; if it passes you would just have to insert it normallly into the category system. The proper code would not be {{langcatboiler}}, but {{famcatboiler|qfa-pen}}, provided that the category passes RFDO, then a code qfa-pen would be created for it. --Daniel Carrero (talk) 21:54, 22 September 2015 (UTC)[reply]
I'm arguing about modules in general, and I totally disagree that it's easier. It's so much easier to use HotCat to add categories to other categories than it is to edit modules or add templates. FWIW, I am also concerned that User:CodeCat has too much OWNership of the categorization system of this project; particularly when CodeCat has forced us to use modules instead of just HotCatting everything like most other projects do. Purplebackpack8922:03, 22 September 2015 (UTC)[reply]
@Purplebackpack: Most languages/families alreay have a code so it works for them; Penutian is the odd one out, still under discussion. I suggested above: That is clearly a disputed/proposed language family, wait for the RFDO discussion to end before using that category further. But you'd rather use that category (and "Terms derived from Penutian languages", etc.) now, before discussion? I wouldn't advise to do that manually. That's a lot of work for a category under discussion: You would have to edit Category:Terms derived from Wintuan languages, Category:Terms derived from Chinookan languages and others as subcategories of Category:Terms derived from Penutian languages individually or leave the work unfinished. The purpose of the module system is doing or undoing all that at once with few edits to the modules.
For better or for worse, when you complain about @CodeCat, I demand credit, too, since pre-Lua I created {{poscatboiler}}, {{langcatboiler}}, {{famcatboiler}} and a good chunk of the category structure in use now. Though lots of other people contributed to the system as well, with edits and also votes and discussions. (I admit my coding was a mess, often in the form of large templates, and it made people's lives difficult editing them. I apologize to everyone who tried to edit the templates and remember this.) One thing I think is an improvement is that you know what to expect in a category system that is structuralized through templates: before the creation of a number of standardized subcategories, language categories like Category:English language had entries, appendices, templates and indexes randomly placed directly in it instead of in the subcategories, for example. Also many categories "Category:XYZ nouns" were NOT in "Category:Nouns by language, a number of categories were using different names for the same language (Category:Nynorsk language vs. Category:Norwegian Nynorsk language) and so on. --Daniel Carrero (talk) 22:52, 22 September 2015 (UTC)[reply]
"The purpose of the module system is doing or undoing all that at once with few edits to the modules." If you can't code and/or can't find modules, the number of edits it takes isn't particularly relevant. With HotCat (and even without it), I can add a category to a large number of pages relatively quickly, as HotCat is relatively easily to use and doesn't require coding. Also, Dan, while you may have had a role in our current confusing system, you revert me (and other uses) far less in this area than CodeCat does. Purplebackpack8923:54, 22 September 2015 (UTC)[reply]
I should make myself clearer. "The purpose of the module system is doing or undoing all that at once with few edits to the modules." That is in cases where you want to change how the system works, not just simple tasks like adding or deleting categories, which often don't require any change to the modules themselves.
Even if you did your edits with HotCat in a perfect and consistent way, we can't guarantee everyone will do it. Modules make the category system consistent. Consistency is important: Category:English nouns is a subcat of Category:English lemmas, not a subcat of Category:English language, and that is true for all languages. But what if people want to change this? What if User:Example wants Category:German nouns to be a subcat of Category:German language? My point is: There are dozens of thousands of categories, that is an increasingly complex system by itself. In my opinion, User:Example should not be able to place Category:German nouns under Category:German language while leaving all other "X nouns" categories unattended. If that is to change, then all "X nouns" would have to change together. That is why we are using modules now. What's your opinion on this? --Daniel Carrero (talk) 10:15, 23 September 2015 (UTC)[reply]
My opinion, Dan, is that you're ignoring the main drawback of module use: that most people either don't know what a module is and/or are unable to edit them even if they do. Yes, using HotCat or other manual categorization methods may have a lack of standardization, but it's far less complicated. I could probably add or remove a category from every single category we've got in less time than it'd take me to learn to code. Purplebackpack8914:32, 23 September 2015 (UTC)[reply]
I am not ignoring that modules are complicated to people who don't know how to edit them. (I am one of those people, I can make templates using MediaWiki code, but I know virtually nothing of Lua.) I am explicitly supporting the consistency of modules in favor of the freedom of editing any category individually, on the grounds that categories are far more useful (at least IMO) in this multilingual system if all languages follow exactly the same categorization system. You say: "manual categorization methods may have a lack of standardization", but that downplays the fact that the categorization system without templates (as it was without poscatboiler and some votes and discussions) was a huge mess, with some examples that I already mentioned in this discussion. I also find it hard to believe that everything could be solved manually, like adding "Category:Nouns by language" and "Category:X lemmas" manually to all the 1,567 "Category:X nouns" categories, without having any categories using different language names. Surely there would be some problems solved with higher priority and others left unattended? Do you have interest in the whole categorization system or just a few of the existing categories? You said: "most people either don't know what a module is and/or are unable to edit them even if they do." What do you want to edit in modules? Or: What problem are you trying to solve where you would use HotCat rather than modules? --Daniel Carrero (talk) 15:52, 23 September 2015 (UTC)[reply]
That does not answer my questions. Be more specific. You only have 42 edits to categories but apparently since the beginning you had known how to use {{poscatboiler|gul|verbs}}, for example, so fitting new categories into the existing system does not seem to be an issue. What did you want to recategorize or create ever since we created modules? --Daniel Carrero (talk) 16:54, 23 September 2015 (UTC)[reply]
I have some questions:
Can we direct User:Purplebackpack89 to the documentation for the relevant part of our infrastructure?
Can we direct him to the the documentation for how to accomplish specific tasks?
Can we tell him where the system for accumulating user requests, issues or questions and the response thereto?
No truly professional sysytem with a user/contributor interface would have so little documentation accessible from users PoV. If we can't have a truly professional system, then why do we place so much of the project in the hands of coders? Why do we accept so much regression in the features of the software. It seems as if many of the software projects simplify user-interface and other matters to match the skill level and "tidiness" preferences of the coders. DCDuringTALK22:20, 22 September 2015 (UTC)[reply]
Re: Question 3: What gives some assurance that the problem is actually solved and how it is solved (any regressions?) rather than oversimplified, ignored, or deleted?
Question 1: By looking at the code of other family categories. Random suggestion: Category:Italic languages. (or by asking other people)
Question 3: No assurance; this is a volunteer project. Though I'm curious: Did you have a request, issue or question that was posted in GP and later oversimplified, ignored or deleted? --Daniel Carrero (talk) 23:38, 22 September 2015 (UTC)[reply]
re: "this is a volunteer project" That seems to be interpreted as coders doing whatever they want, whether asked or not, conforming only to standards of their own invention. Other users are simply to conform to the changes. Those users are also volunteers and they have stayed away from or left this project in droves. DCDuringTALK01:22, 23 September 2015 (UTC)[reply]
What do you want to change in categories? I don't see people complaining that way about complex templates other than categorization ones, such as {{en-noun}} and {{context}} (and previous incarnations, such as {{obsolete}}). What would people do if they wanted to change {{en-noun}} some way but didn't have the skills to do it? {{poscatboiler}} and related templates are great; but I'm just saying my opinion. If a number of people really hate them so much, why don't you nominate them for deletion? --Daniel Carrero (talk) 10:15, 23 September 2015 (UTC)[reply]
And Question 2, which is the "how to code" question? Also, having coding issues actually makes things harder for people like you and CodeCat who can code, because not only do you have to do your coding, you have to do the coding of everybody who needs coding done. Purplebackpack8923:54, 22 September 2015 (UTC)[reply]
And let me remind you: this is a general beef I have with categorization requiring coding. Penutian wasn't the first time I ran into this wall, and I'm definitely not the only person to run into this wall. Purplebackpack8923:59, 22 September 2015 (UTC)[reply]
Nominate {{poscatboiler}} for deletion. I'd vote oppose, but you have the right to pursue what you think is best. Or hire someone to create something better if you can't code. Or make a list of everything you think is wrong with the template so that can be discussed/fixed. --Daniel Carrero (talk) 10:15, 23 September 2015 (UTC)[reply]
How 'bout I just nominate all modules for deletion, and we go back to manual categorization? Your "solutions" essentially require that I acquiesce to coding being necessary for categorization on this project. I'm not willing to do that. I shouldn't be asked to. Purplebackpack8914:32, 23 September 2015 (UTC)[reply]
"...require that I acquiesce to coding being necessary for categorization on this project" No. What is the difference between presenting an opposing idea in a discussion and "requiring that the other person acquiesce" to something? On that logic, I could accuse you of making me acquiesce to your ideas right now, too. But the fact is that I am not trying to "manipulate" you into changing your mind. I am presenting my points and I am asking you to discuss yours, especially after you have explictly complained of your edits being reverted or what you have to say being ignored. What else do you want? Ultimately, nominating {{poscatboiler}} for deletion as I said may have sounded sarcastic, but that was not the case. If a template is problematic, creating a deletion discussion would be the natural thing to do. Even though I think it's a great and helpful template, you can do whatever you want. --Daniel Carrero (talk) 15:52, 23 September 2015 (UTC)[reply]
Formatting proposal: always put cognates in a separate paragraph[edit]
Back in June I complained that lists of cognates make etymologies messy and hard to read. Several other editors seemed to agree, but there wasn't a consensus for any change that I can see. So I'd like to propose something much milder and less intrusive: cognates must always be in their own paragraph, separate from the explanation of the term's origin. See landschap for an example. —CodeCat00:16, 24 September 2015 (UTC)[reply]
Support. Some etymologies have the evolution chain and the cognates intertwined (i.e. “from Fooese foo (cognate to Barese bar, Voynichean cthar), from Klingon kplar (cognate to ...)”. How can these be dealt with? — Ungoliant(falai)01:11, 24 September 2015 (UTC)[reply]
They should probably be detwined and made into a paragraph. Of course, there's nothing that says there can't be more than one paragraph of cognates, so one could have one for close cognates and another for more distant ones. —CodeCat01:27, 24 September 2015 (UTC)[reply]
I also support, though I would like to know more about this issue. Would we format multiple cognate paragraphs to begin with a word to indicate from what level the cognates come? If so, is the cognate paragraph labeled by the parallel cognate or the shared etymon? Also, do we represent collateral forms under the list of cognates? —JohnC516:15, 24 September 2015 (UTC)[reply]
Would it be possible to make a template for this, something like {{cognates|fi=...|eu=...}}, or do you think there would be too much variation? DTLHS (talk) 01:42, 24 September 2015 (UTC)[reply]
I Support. And I am huge fan of consistency, so in cases (like neap etym_2), will the one cognate be in a separate paragraph ? What should be the proper way in this instance? Leasnam (talk) 11:44, 24 September 2015 (UTC)[reply]
That template would be possible and is an interesting new way to use template parameters, but I don't think we should use it for this because cognates need to be arranged in a logical and structured order which makes sense in terms of the etymology and the template would have no way of knowing how to arrange them. --WikiTiki8914:40, 24 September 2015 (UTC)[reply]
Well it does still matter, but you may be right that it would not apply in many cases because the words did descend in their natural paths to all the listed cognates. --WikiTiki8915:38, 24 September 2015 (UTC)[reply]
Support: saying they "must always" be in their own paragraph seems needlessly firm to me. There's always room for exceptions to be made. But in general it seems like a good idea. WurdSnatcher (talk) 16:18, 24 September 2015 (UTC)[reply]
Support, seems reasonable. Also WT:ELE is currently lacking any mention of cognates. I realise they don't have their own header, but this is the place users ought to be able to look for guidance on how to add them to an entry. —Pengo (talk) 01:49, 26 September 2015 (UTC)[reply]
When an etymology is very long, this would be helpful, but when an etymology is very short ("From Proto-Algonquian *foo, whence also Penobscot foo."), a paragraph break seems unnecessary and excessive. It would also make entries with different levels of cognates (as Ungoliant describes) messy. - -sche(discuss)05:21, 26 September 2015 (UTC)[reply]
I agree with this point. "Must always" seems a bit overly firm here. We could consider e.g. separating cognates if the etymology runs to more than one line long? --Tropylium (talk) 22:42, 28 September 2015 (UTC)[reply]
Depends on the window size (which further depends on one's screen resolution), of course. But we should probably aim for downward compatibility. Is it possible to find out what is the median non-mobile user's screen width? Off the cuff I'd guess 1024 px? and allowing for other screen uses, about 600-800 px might then be a reasonable range for "a line". --Tropylium (talk) 20:20, 1 October 2015 (UTC)[reply]
I oppose that "cognates must always be in their own paragraph" since it makes etymology sections take more vertical space, especially the short ones. I am quoting, including "must" and "always". --Dan Polansky (talk) 11:45, 26 September 2015 (UTC)[reply]
I support the option to use separate paragraphs, but would not be comfortable enforcing it if, for instance, there are only one or two examples. Ƿidsiþ14:31, 30 September 2015 (UTC)[reply]
I inform you about a project I am trying to build for fr.wiktionary and es.wiktionary. It's name Wikiproject Siriono and it's about a language spoke in Bolivia named Siriono. I am a French linguist who study this language since five years now for my PhD in linguistics and I want to export my database into Wiktionary. Then, as the project is wrote, I plan to go to Bolivia to train the speakers to access and manage the entries in the Spanish edition of Wiktionary. My database is made with FieldWorks Language Explorer and include translation from Siriono to local bolivian Spanish, French and English. I don't know nothing about the structure of the English edition of Wiktionary, so I will not try to create a bridge for this edition, but I am willing to collaborate if someone from here want to. In my opinion, it's just a basic formatting for xml datas and a language check, as English is not my mother tongue. Plus, if there is here someone who speak Spanish and want to be part of the team that will go to Bolivia next year, there's still room for a name. I want to work mainly if only on the Spanish Wiktionary so better if it's someone that know this project well. Hope you will find interesting and your welcome to comments, critics and fix mistakes in the proposal if my English is to vague or incorrect. Yours, Eölen (talk) 17:51, 24 September 2015 (UTC)[reply]
@Eölen: Very exciting project! I've copy edited the proposal as requested (hopefully I haven't added any errors). The only part I wasn't sure about was the line "...and be host in family during one month." I wasn't sure if you meant "and his family will host for one month" or maybe "a local family will host the team for one month" so I left it (I'll let you fix it). Looks like a very worthwhile project and wish you the best with it. —Pengo (talk) 03:04, 26 September 2015 (UTC)[reply]
@Pengo: Thank you very much! You did a great job! I will clarify this sentence. A local family will host the team, in one separated house I built in the village, next to their house. I don't have relatives there! I am very grateful you helped to fix the language and improve the writing. I hope this project will go well, I am still trying to define precisely how to schedule it and I am still looking for a volunteer for the team! Thanks again! Eölen (talk) 04:25, 26 September 2015 (UTC)[reply]
I've always been annoyed when etymologies say "compare", with a bunch of words in other languages, because it's so meaningless. Why am I supposed to compare them? Am I supposed to note their superficial similarity? Is their meaning interesting? The number of syllables? Do I win a meerkat if I compare them? Obviously the insinuation is that there is some connection, but why does the entry not just say what the connection is? Are they cognate? Or otherwise related? Then say so.
Then say so.—how about you go speak to your cat like that?
I guess I'll have to be the first to disagree, since those were my two entries that you just defaced. Like I said when I reverted your edits, at least mine were helpful, which is more than I can say for yours. If you don't find this information useful—don't use it. If you don't find it interesting—ignore these sentences. And let other people make whatever sense they make of those things. They don't break any rules, the connections pointed out are factual and real.
But you didn't point out any connection. You said "compare", which means nothing. Things can be compared to show the absence of connections, too. And Wiktionary isn't a free-for-all where you can just put anything you think is interesting. Things have to serve a purpose and fit into our formatting rules. A "compare with" heading does neither. And for the record, I didn't "deface" "your" entries. I edited the entry, and the entry was Wiktionary's from the moment you made your edit. —CodeCat00:27, 26 September 2015 (UTC)[reply]
There is a place for "compare" in etymologies, because establishing the exact relationship between words isn't always possible, but there are plenty of cases where there seems to be some kind of connection. I would rather have "compare" in many cases than to either have a long explanation of why the term is of interest, but maybe not a cognate, or to eliminate anything other than that which is rigorously proven to be a cognate. As with anything open-ended, this can certainly be abused: I don't really want to see a bunch of Mongolian terms in English entries because they pass some kind of Pan-Turkist's Rohrschach test. But then, I don't really want to see Norwegian, Swedish, Danish, Icelandic and Faroese cognates because one of the languages was included and partisans for the others felt they deserved equal treatment.
As for the two cases at contention: I agree that having a number of terms in other languages under a separate "Compare with" header is overkill, though they all probably trace back to the same Pali term through some combination of borrowing and inheritance. On the other hand, removing A Chinese term from a Sino-Vietnamese etymology that's made up of the same characters as those cited in the main part of the etymology seems like overkill, too. It's a matter of proportion and degree of relevance, which can't be tidily summed up in some kind of rule. Chuck Entz (talk) 01:20, 26 September 2015 (UTC)[reply]
It's more the wording that annoys me than anything else. I have no problem with listing cognates or related terms, but then say what they are. Don't use "compare" and leave people guessing at what the idea is. Related terms should be called related terms, because then you know what they are. —CodeCat01:38, 26 September 2015 (UTC)[reply]
I agree. I assume cf. is shorthand for "see also this other word which sounds a bit similar so maybe its etymology is correct for this word too or at least had an influence on its formation, who knows?", or more briefly: possibly cognate with or possibly influenced by or formed in a similar way with a different meaning etc, which are the kinds of phrases I'd prefer.
Similarly Related terms is also fairly meaningless, and it annoys me that we have no standard way (afaik) to, for example, mark a related term as "adjective form of this noun", etc. —Pengo (talk) 02:11, 26 September 2015 (UTC)[reply]
For related terms, I was talking about putting them in etymologies. Just as we have "cognate with" lists, there's also "related to" lists, which are much preferable to the nondescript "compare". —CodeCat02:18, 26 September 2015 (UTC)[reply]
Compare makes perfect sense. It means, look for similarities or analogies. "Compare" does not state what the connection is since that would be too wordy, and since that is often obvious once you actually start doing the comparing. It looks like I largely agree with Chuck Entz above. --Dan Polansky (talk) 11:51, 26 September 2015 (UTC)[reply]
Compare is used for cognates in other language and also cognates in the same language, or words that aren't cognates but follow a similar pattern in their formation. You're free to be pissed off abut it, it's your life, but I'd like a Wiktionary where not only what CodeCat thinks is important, and other people can make some decisions too. Renard Migrant (talk) 14:24, 26 September 2015 (UTC)[reply]
Of course, because whenever I think something can be improved, that must automatically be interpreted as my attempts to force my will through. Because we all know that leaving problems unsaid works so well. At least now that I've said this, it's clear that some people agree with me. So how can you even think it's about what I alone think is important? Do those other people not count? —CodeCat14:40, 26 September 2015 (UTC)[reply]
I agree with CodeCat, "compare" only means something if you already know what the relationship is or know enough about linguistics to deduce what's meant. It makes sense in paper dictionaries where you have to save space, but here we can be clear. Why not say "possibly cognate with" or "may be related to" or whatever? It seems like Wiktionary tries to be as confusing and off-putting as possible sometimes. Why use such stilted, unnatural language? Are we trying to communicate info to each other and other linguistics enthusiasts? Or are we trying to educate ordinary people? If we're trying to educate ordinary people, "compare" is pointless obfuscation about as useful as a "Meronyms" section. WurdSnatcher (talk) 14:30, 26 September 2015 (UTC)[reply]
“I would rather have "compare" in many cases than to either have a long explanation of why the term is of interest, but maybe not a cognate, or to eliminate anything other than that which is rigorously proven to be a cognate”—this.
@WurdSnatcher Educate ordinary people? I didn’t know that was the aim of the project. I would be curious to know how many people here would say they contribute because they’re trying to educate ordinary people. I’d say ordinary people don’t care about dictionaries at all—they use them once or twice a year to look up a word or two. And when they do that, they’re certainly not interested in things like, say, the etymology of the word at all. Should we start removing all etymologies then?
“Why use such stilted, unnatural language?”—oh wow, that’s rich, coming from someone championing the interests of ordinary people and proposing to use “possibly cognate with” instead of “compare with”. I didn’t even know what a ‘cognate’ was until a couple of months ago. How are ‘ordinary’ (whatever that means anyway) people supposed to know that? “Compare with” is certainly more natural than “possibly cognate with” or, god forbid, ‘cf.’
“It makes sense in paper dictionaries where you have to save space, but here we can be clear.”—there’s another thing we need to try and save, whether we’re talking about paper or online dictionaries. That thing is people’s time. And that is the reason why “compare with” is preferable to “possibly [insert an obscure linguistic term that only linguists understand]”, or etymology sections spanning half a dozen sentences. This is especially true if we’re keeping in mind the interests of those ‘ordinary’ people, who just want to quickly figure out what that obscure word they’ve just heard means.
@CodeCat Are you going to nitpick my use of the word ‘my’ in front of the word ‘entry’ now? The entries might not be mine, but can I at least keep the messages to my unworthy person? With m’lady permission, of course. Thank you. And while my messages are still mine, the way that I see it is that I get to call things whatever I want (as long as I’m not employing insults, and I’m not), so ‘deface’ you did. I like the word, and it describes accurately the nature of your edits.
By the way, here’s an idea for you. This is how books used to be censored in tsarist Russia: [[13]]. Maybe next time you don’t like something in an entry you could just replace that part with dots, like in the book pictured. You still get to censor things (which you seem to enjoy doing), but don’t do as much damage in the process. Pfftallofthemaretaken (talk) 19:34, 26 September 2015 (UTC)[reply]
Wow, that was quite a bit of bile there. I'm not really sure that was merited in response to anything. I do not mean to lecture you, but no user really has chief control over any entry outside of his or her user namespace. Code may often be rather brusque when she makes changes to things, but the reason we are having this discussion is to decide how we, not she and not you, will handle this issue in the future. I really don't want us to be so angry about such a small matter, so I would ask all parties involved please calm down just a touch.
Compare has always seemed like shoddy explanation to me personally, but not enough that I think it should be removed wholesale. I normally understand compare to act as a stub for bigger and better things!
P.S. I can whip up a template like {{redacted|US}} or {{redacted|tsarist}} that will place black bars or dots over text respectively. It wouldn't be too hard, really. (N.B. the preceding joke is meant solely for the purpose of humor and not to antagonize, mock, or promote one side's argument in any way. Please do not get bent out of shape about a silly suggestion.) —JohnC522:32, 26 September 2015 (UTC)[reply]
I agree that removing "compare" along with all the terms is probably bad. But at the same time, it's often not possible for a random person to improve things, because this means knowing just what the connection being alluded to is - exactly the vagueness that is making me complain about "compare" in the first place. If I see "compare", I have no way of knowing whether the words are cognates, unless I have knowledge of those particular languages (e.g. Germanic). For Chinese, I would have no clue what to replace "compare" with; only the person who added it there presumably knows. Preventing that situation is better than having to tediously fix it afterwards, hence my revert to Pfftallofthemaretaken's edits. —CodeCat23:10, 26 September 2015 (UTC)[reply]
@JohnC5 After reading your message I realized I was wrong and amended mine accordingly.
"I do not mean to lecture you, but"—"but that's exactly what I'll proceed to do."
"I normally understand compare to act as a stub for bigger..."—I sincerely hope that this isn't what this project is all about.
"...but the reason we are having this discussion is to decide how we, not she and not you, will handle this issue in the future."—really? I thought we were having this discussion because one particular editor wished to communicate to the rest of us what she's "always been annoyed" by.
But anyways, I agree that the situation could use some defusing, so let's all play a game. The rules are as follows. I will now revert CodeCat's edit of the entry on bảo đảm and put back "compare with Chinese 擔保" that I originally put there. These are the same two characters that are used in the hán tự spelling of the word, but in reverse order. I'm sure there's a name for it in linguistics, but haven't the faintest idea what that term might be. So I'll use "compare with". Now, whoever reverts that edit will have to explain why they didn't also remove all the instances of compare in the Etymology section of the entry on father—as the section invites us to compare that word with 15 other words, in 15 different languages! I don't know about everyone else, but I'm curious what's gonna happen. Because, after all, maybe those reverts that I mentioned in my original reply here were just personal... Pfftallofthemaretaken (talk) 08:21, 27 September 2015 (UTC)[reply]
The way I see it, "compare" is not the ideal, but sometimes details are simply not available or the editor writing the etymology is not aware of the details and does not want to spend too much time researching them. You can look at it as an invitation for anyone who cares enough to do some research and replace "compare" with something more informative. --WikiTiki8916:29, 28 September 2015 (UTC)[reply]
I agree. And I didn't see the abovementioned entry edits (so don't know whether they were removal of "compare" lists or what), but don't think that "compare" lists should be removed. Clarified, certainly. Removed, no.—msh210℠ (talk) 18:03, 1 October 2015 (UTC)[reply]
One point, tho not directly related to the kerfuffle at hand, is that a lot of our "compare" stretches seem to date from before we had much in the way of protolang appendices, and seem to fulfill the role of listing cognates. This at least I think can be done much more efficiently with the appendices (which would also help with the occasionally seen complaing that our etymology sections take too much space).
I do not oppose "compare" if given context, e.g. if we say that "Barese X is borrowed from Proto-Fooian Y", then it seems pretty clear what adding a "(compare Classical Foo Z)" is doing. But yeah, a completely hanging "compare Zoinks Ø" seems unhelpful. --Tropylium (talk) 22:38, 28 September 2015 (UTC)[reply]
I see a bot replacing {{etyl}} with {{inh}}, e.g. in diff. The resulting markup combines what was etyl and term into a single template, like {{inh|cs|sla-pro|*čьlověkъ}}. I don't really like this. Everyone happy? --Dan Polansky (talk) 11:24, 27 September 2015 (UTC)[reply]
Yes. I've been waiting a long time for someone to finally do this. I find it really annoying to have to separate the {{etyl}} and {{m}} templates, and half the time I find myself putting the etymon directly in {{etyl}}, and then I have to go back and fix it. Using {{inh}} makes life much easier. —Aɴɢʀ (talk) 12:12, 27 September 2015 (UTC)[reply]
Well, {{inh}} isn't meant as a drop-in replacement for {{etyl}} and {{m}}. It's meant specifically for inherited terms, as its documentation notes. For borrowed terms, you'd use {{bor}}. There are also cases where terms are neither inherited nor borrowed. For example, foxhound does not inherit from Proto-Germanic *fuhsaz or *hundaz but it can be said to be derived from Proto-Germanic nonetheless. I intended "inheritance" to mean specifically cases where the actual morphological formation was inherited. In other words, inheritance can be traced until the point that the actual word "foxhound" came into existence. —CodeCat13:16, 27 September 2015 (UTC)[reply]
Good idea. Funnily enough the French template étyl has done this almost since its inception many years ago. The only issue with bot replacements is sometimes you get "Borrowed from {{etyl|la|fr}} {{m|la|<word here>}}" which for obvious reasons, shouldn't used {{inh}}. Renard Migrant (talk) 14:52, 27 September 2015 (UTC)[reply]
I haven't done wholesale bot replacements. The ones I did were always pairwise: for only one given source language and current language. That way I could make sure that the current language was in fact a descendant of the source. I've also only replaced instances where the source is the first to appear in the etymology, and only when the preceding word is "From" or empty, never "Borrowed" or anything else. On top of that, I've so far avoided language pairs where the current language might have reasonably borrowed from the source as well as inherited from it, i.e. Romance borrowings from Latin. The Germanic languages have generally not borrowed words from older stages, so they are safe. I've also skipped cases where reconstructed terms end in -, because those are likely to be stems or roots rather than fully-formed words. Roots have no descendants, only derived terms which have descendants. —CodeCat15:13, 27 September 2015 (UTC)[reply]
Side note: it's often a hard to tell if a word's history was derivative formed in proto-X → develops into word in X or root inherited in early X → derivative formed within the history of X. I would suggest that at least in cases where we can only clearly establish a proto-root and a language-specific derivative, it's safest to analyze them as a derivative within the language, and only linking the root of the derivative to the proto-root. --Tropylium (talk) 22:28, 28 September 2015 (UTC)[reply]
I seem to remember cleaning up a couple of cases (maybe not with this specific template) where the language code was an etymology-only subset along the lines of NL. and the module tried to use it for the mention. You would need to allow for this before converting such cases. Chuck Entz (talk) 15:54, 27 September 2015 (UTC)[reply]
Is the bot checking to make sure there's no borrowing along the way (e.g., if an English word from Latin via a French/Norman borrowing says only "from Latin foo", or if an English word from Hebrew via Yiddish says only "from Hebrew foo"), CodeCat?—msh210℠ (talk) 17:57, 1 October 2015 (UTC)[reply]
Well, so far I've only done Dutch and the Finnic and Samic languages. I don't have any immediate plans to do more. That said, this script and template are only for inherited terms, so I wouldn't use it for English from Latin because English didn't descend from Latin. —CodeCat18:03, 1 October 2015 (UTC)[reply]
Proposal: Drop "explained" and make it "Wiktionary:Entry layout"[edit]
Bonus, less important, reason:
2. Speaking for myself, if the title is shorter, it would invite me for typing the full name of the policy in discussions or on my personal browser more often if I want to ("WT:Entry layout" or "Wiktionary:Entry layout"). Conversely, if the title is longer, it makes me more likely to use the shortcut only ("WT:ELE"). I am willing to bet this would be true for other people, too. Not that big of a reason, (it boils down to "'explained' makes the title longer!") but it's good to mention it, as secondary to the question above.
I did not use RFM this time because that's a major policy. In any event, if other people agree with the name change in this discussion, I plan to follow up with a vote to close the deal.
Note:
WT:EL was the shortcut to Wiktionary:External links and was used in three places: a 2006 discussion, a 2014 discussion and as a proposed shortcut to ELE itself. IMO that's unused enough that the shortcut could be changed; I renamed it to WT:EXT to free it for this proposal
WT:ELE is definitely going to be kept, since it has been a widely used shortcut. We can use WT:ELA (Entry LAyout) as an alternate three-letter acronym, though personally I prefer just WT:EL. (Also, in Portuguese, ele = he, ela = she.) --Daniel Carrero (talk) 16:37, 5 October 2015 (UTC)[reply]
Come read about the findings and next steps as WMF’s Community Resources team begins to implement changes based on your feedback. Your questions and comments are welcome on the outcomes discussion page.
Ancient Greek words have a tendency to form compounds that are not directly derivable from their component words—not in the same way English compounds are.
In-depth explanation
There are a few very common types of compounds that show up:
two-part [usually proparoxytone] adjectives that take the form stem-stem-ος, and have a meaning "with X Y". Example: βραχύβιος, meaning "with short life". This type actually has an English analog in words like short-lived, but unfortunately Wiktionary does not appear to have a consistent treatment of these words.
Occasionally third-declension words will not take the thematic suffix; I denote this type 1b.
Occasionally adjectives will have an active meaning, in which case they will have a paroxytone or oxytone accentuation. Most instances I've found have had a substantive sense. I label this type 1c.
two-part [oxytone] adjectives that take the form stem-stem-ής, and have a meaning "X-Y-ing". The second stem is usually a verbal stem.
verbs in -έω, and nouns in -ία, which are probably derived from one of the above but often appear without them (which is not to say that e.g. **βραχύγραφος didn't exist, but it was never attested.) Proper type 3 compounds never derive from a verb/noun such as **λογέω/**λογία (though one may exist.) Other suffixes may appear here; the most common is -ικός.
two-part [proparoxytone] adjectives in -τος. These usually (but not always) correspond with an oxytone adjective in -τός. Both have a meaning roughly corresponding to that of a participle, but do not always agree in voice.
Other instances of suffixes attached to compounds that cannot be explained by separation. 5a: -ιος [ppx], creating adjectives; only seen on noun and adjective stems. 5b: -εια [ppx], creating nouns; only seen on verb-stems?
The stem can be either a noun-stem (of any declension) or a verb-stem. If it is a verb-stem, it will be in the o-grade if possible (or, failing that, the zero-grade) for types 1 and 3, the e-grade or (more often) zero-grade (sometimes both are attested) for type 2, and the e-grade for type 4 (and 5b?)
The following is a demonstratory list.
βραχυβάμων(brakhubámōn) - from βῆμα, with regular alteration of -μα(-ma) to -μων
There is also an analog in English: words of the form X-Yed, like quick-witted. However, the treatment of these words with respect to etymology is not entirely consistent, and the most common manner is apparently to create a separate lemma, e.g. witted, called an adjective but described as a suffix. Which may be the most accurate manner in which to describe such a morpheme, I'm not sure, although I do think at least it should include a hyphen.
With respect to Ancient Greek—after making this list and pondering my findings, I have come upon the conclusion that the best practice is to mark the etymology with {{compound|stem|stem|suffix}}, or {{compound|stem|stem}} when the "suffix" is really just the thematic ending (i.e. type 1 above) or no ending (type 1b.) Verbs that change grade should probably get separate pages, e.g. -λογος (although the POS of this is uncertain—perhaps "adjective" is best?). Harder is the zero-grade—perhaps entries such as -τραφής?
@User:ObsequiousNewt: It depends on whether you want to emphasize the compounding process or the suffixing process; "quick-witted" contains both processes, and compounding seems more marked to me in this term. And then, you need to know whether you want to have the terms categorized as compounds. I don't see anything wrong about "{compound|stem|stem|suffix}}", really. --Dan Polansky (talk) 16:07, 3 October 2015 (UTC)[reply]
I'm not sure what you mean by emphasizing. The end result is probably indistinguishable on the page. What you seem to be suggesting is to make {{compound}} work like {{affix}}, minus differences in the parameters. But I already checked in the past whether this would work, and it won't. Not everything beginning with - is a suffix, and not everything ending with - is a prefix. Those cases don't work with {{affix}} either, no, but that template was created anew so there were no issues with backwards compatibility. With {{compound}} on the other hand... —CodeCat22:46, 3 October 2015 (UTC)[reply]
Proper nouns and capitalization across all languages[edit]
We have established through many discussions here in the BP that proper nouns are defined by their usage and semantics and not by their capitalization. Most of these discussions, however, focused mainly on English. I am wondering whether we have a consensus that this also applies to all other languages that distinguish capitalized and uncapitalized nouns. I know that many of us believe that we should not distinguish between proper and common nouns at all, but as long as we do, we should do it consistently. Let's do a poll on whether we agree with the following principle: For all languages, usage patterns and semantics should take priority over capitalization and punctuation in determining whether a noun is common or proper. --WikiTiki8915:32, 29 September 2015 (UTC)[reply]
“For all languages, usage patterns and semantics should take priority over capitalization and punctuation in determining whether a noun is common or proper.”
Please state whether you agree or disagree. If you disagree, please explain why and, if possible, include an example of when you believe this should not apply.
Agree. The usefulness of distinguishing is lost if capitalization is used as the distinguisher, as there would be no need to look up the part of speech. --Andrew Sheedy (talk) 23:22, 30 September 2015 (UTC)[reply]
Agree. Capitalization does not necessarily tell whether something is a proper noun; rather, capitalization habits are to an extent adjusted based on the perception of grammarians of whether something is a proper noun or not. In particular, "Frenchman" is not a proper noun. However, I am not clear what role punctuation might have in something being a proper noun; what language would that pertain to? On another note, I don't think we should necessarily be consistent across languages: If English grammarians deem names of languages to be proper nouns, I am okay with marking them so in English, while marking them as common nouns in Czech as per Czech grammatical tradition. --Dan Polansky (talk) 10:01, 3 October 2015 (UTC)[reply]
This becomes problematic when you get into dead languages. Academic consensus for Latin, Ancient Greek, etc. is to capitalize proper nouns, even though actual writing only had one (upper) case. —ObsequiousNewt (εἴρηκα|πεποίηκα) 16:12, 29 September 2015 (UTC)[reply]
I think you misunderstood. What I am saying is not about how we should capitalize nouns, but about how we should classify them. In other words, that we should ignore the capitalization when deciding whether to put ===Noun=== or ===Proper noun=== as the POS, but still follow the established capitalization practices for deciding where to put the entry. --WikiTiki8917:17, 29 September 2015 (UTC)[reply]
Disagree. Semantics are not always easy to determine. Wikitiki89 recently turned the famous sense of перестро́йка(perestrójka, “perestroyka”) into a proper noun, so he is making a case now.
There is no convention or precedence of treating lower case words as proper nouns in Russian. Lower case words can never be proper nouns in Russian, regardless of semantics, and I see no need to introduce this. Specific rules and conventions with different languages should not be ignored. I oppose treating differentiation of proper/common nouns the same way we do for English. E.g. language names, ethnicities, month and weekday names are common nouns and are spelled in lower case in Russian but some political terms are proper nouns, made so by the Soviet Communist government.
I am not too interested in making points on the topic. Suffice that I expressed my opinion on the matter but I may join the discussion later on. --Anatoli T.(обсудить/вклад) 01:28, 1 October 2015 (UTC) (I've reformatted your post slightly, Anatoli.—msh210℠ (talk) 17:46, 1 October 2015 (UTC))[reply]
Disagree. I have no reason to think that semantics and/or usage is the usual standard by which proper vs. common noun is determined in every language (that has proper and common nouns). Maybe for some languages it is indeed orthography (e.g. capitalization) or something else. I think this should be decided by each language's editors.—msh210℠ (talk) 17:44, 1 October 2015 (UTC)[reply]
These might vary by language (I didn't mean to imply that they are universal). The general idea is that proper nouns usually cannot take determiners or adjectives, cannot change their number, and cannot be possessed (unless these features are already part of the lemma, or unless the proper noun is being commonized). As far as semantics, they generally refer to one specific thing, rather than a class of things. --WikiTiki8917:35, 29 September 2015 (UTC)[reply]
We should be consistent across languages, though. If day or month names are common nouns in some languages, we should treat them that way in all languages. This, by the way, is one huge reason for treating proper nouns and common nouns the same on Wiktionary: the distinction is semantic, and can be determined by analysing the referent, so the result is the same for all words with the same referent in all languages. They are a subset of nouns, not separate from nouns. —CodeCat23:39, 30 September 2015 (UTC)[reply]
That's not necessarily true though. Some languages might handle certain concepts with common nouns that other languages handle with proper nouns. In most cases, you would be right, but there will be exceptions. --WikiTiki8901:11, 1 October 2015 (UTC)[reply]
You aren't seriously suggesting applying the same POS rules across languages? In some languages, adjectives are verbs. In others, they're nouns. In still others, they're neither. I'm sure there are similar discontinuities in assignment of terms to the proper-noun POS. Chuck Entz (talk) 02:31, 1 October 2015 (UTC)[reply]
"Who" is proper in English too. It refers to the specific person whose identity you are asking about. It also fits all of the criteria WikiTiki noted above: it can't take determiners or adjectives, can't change number, and can't be possessed. —CodeCat17:27, 1 October 2015 (UTC)[reply]
What about indefinite pronouns like someone, anyone, whoever, etc.? They don't refer to a specific person. In many languages (e.g. Italian and Portuguese) possessive pronouns can take determiners (il mio padre / o meu pai), and as for pronouns taking adjectives, what about "poor me" and "lucky you"? —Aɴɢʀ (talk) 19:54, 6 October 2015 (UTC)[reply]
Good point. I realized that right after I posted that. I think indefinite pronouns would be a separate category altogether, still unlike common nouns (and even they can sometimes be "commonized" into a common noun: e.g. "this particular someone"). "Possessive pronouns" are determiners and are not really pronouns, much like English possessives such as "John's" are determiners and are really no longer proper nouns. And in case anyone was going to mention "o João", this is one of the reasons I said "usually" and not "always". --WikiTiki8920:43, 6 October 2015 (UTC)[reply]
Can you give an example of a proper noun that meets all these criteria? I'm struggling to think of one. Even terms that are universally agreed upon as proper nouns violate these rules in at least some edge cases. Germany: "the Germany of my youth", "beautiful Germany", "the two Germanies", "Merkel's Germany". John: "the John I knew and loved", "good old John", "Which are of the Johns do you mean?", "my darling John". White House: "the White House", "the rebuilt White House", "they wanted their own White Houses", "Hoban's White House". Allah: "a vengeful Allah", "the groups worship totally different Allahs", "thy Allah and the Allah of thy fathers". Smurrayinchester (talk) 13:30, 6 October 2015 (UTC)[reply]
You seem to have missed my parenthetical remark "unless the proper noun is being commonized". Practically any proper noun (in English at least) can be turned into a common noun with a slightly different meaning. --WikiTiki8915:32, 6 October 2015 (UTC)[reply]
I'm often not sure whether to make something a common or proper noun, e.g. medical syndromes. Can't think of examples right now, but suppose there's a "small face syndrome": it refers to one specific thing and has no plural; it also isn't uncountable (because it's "the syndrome", not "some syndrome"); I would probably make it a proper noun but it feels odd since it's somehow nothing like Paris. Equinox◑14:21, 1 October 2015 (UTC)[reply]
I feel that this is better decided on a language basis, by each of their contributor communities individually. That said, I support this as a default guideline. — Ungoliant(falai)14:36, 1 October 2015 (UTC)[reply]
If this is such a hazy question, then why do we need to determine the proper/common status of all nouns anyway? For a user interested in onomastics specifically, the unambigous cases like placenames or personal names will be clearly identifiable in any case. --Tropylium (talk) 20:10, 1 October 2015 (UTC)[reply]
Should we display the active votes in the watchlist?[edit]
Do you think it would be a good idea displaying this box in the watchlist of all users to increase awareness of votes?
I believe this could be accomplished by editing MediaWiki:Watchlist-details. Maybe we should have some way for each user to opt-out displaying the vote box in the watchlist, but I'm not sure how to do that.
I don't mind making the votes more visible, but I don't like the idea of pushing the actual watchlist even further down the screen; already the "preamble" takes up so much space that only a few lines of the actual watchlist make it onto the first screen on my computer. Is there a way of making it the version that gets displayed in the watchlist smaller, maybe a horizontal list separated by mid dots? Alternatively, what if we adopted the same idea as the Beer Parlor month-subpages, and had a single page that new votes were moved through (I mean using the "move" function), so that each vote page itself was added to the watchlist of everyone who watched that central page, and each vote would thus show up in everyone's watchlist every time it was edited, the same way that new BP month subpages show up in your watchlist without you ever doing anything to watchlist them? (Contrast how, currently, if you watchlist WT:VOTE, you only see the one edit when a new vote is listed on that page; you aren't updated when the vote starts, and when people vote, unless you watch each individual vote page.) - -sche(discuss)21:01, 29 September 2015 (UTC)[reply]
"I don't mind making the votes more visible, but I don't like the idea of pushing the actual watchlist even further down the screen"
Since that box floats to the fight, maybe the box could stay side-by-side with the watchlist instead of pushing it down further?
"Is there a way of making it the version that gets displayed in the watchlist smaller, maybe a horizontal list separated by mid dots?"
Yes, that could be done and it's not very difficult to do.
"Alternatively, what if we adopted the same idea as the Beer Parlor month-subpages, and had a single page that new votes were moved through (I mean using the "move" function), so that each vote page itself was added to the watchlist of everyone who watched that central page, and each vote would thus show up in everyone's watchlist every time it was edited, the same way that new BP month subpages show up in your watchlist without you ever doing anything to watchlist them? (Contrast how, currently, if you watchlist WT:VOTE, you only see the one edit when a new vote is listed on that page; you aren't updated when the vote starts, and when people vote, unless you watch each individual vote page.)"
That sounds great. But I'm not sure how I would do that; can it be done, in the first place?
The bad consequence of this is that, where before I only had to edit one page to move votes to the bottom, now I need to edit two. I don't really like the change. OTOH, if the change makes it easier for people to watch active votes, that's fine. I still think that regularly glancing at WT:VOTE with its less than 10 items at each point of time is an easy way to not miss any votes. --Dan Polansky (talk) 10:07, 3 October 2015 (UTC)[reply]
I initially disliked the box, considering it clutter. Knowing the human tendency for habituation, I left it a couple of days before commenting. I'm fine with it now, and I think it's a good idea. I support this addition. — I.S.M.E.T.A.13:30, 3 October 2015 (UTC)[reply]
I agree with Equinox. There is no good conceptual logic to placing it on the watchlist page, but it does place one of our wiki-citizenship duties squarely in front us better than any page I can imagine. DCDuringTALK18:37, 3 October 2015 (UTC)[reply]
![[13]](https://upload.wikimedia.org/wikipedia/commons/e/ea/Grech_old_russian_censorship.jpg){kind=link}
4 
0 
0