Hello, you have come here looking for the meaning of the word Wiktionary:Beer parlour/2011/December. In DICTIOUS you will not only get to know all the dictionary meanings for the word Wiktionary:Beer parlour/2011/December, but we will also tell you about its etymology, its characteristics and you will know how to say Wiktionary:Beer parlour/2011/December in singular and plural. Everything you need to know about the word Wiktionary:Beer parlour/2011/December you have here. The definition of the word Wiktionary:Beer parlour/2011/December will help you to be more precise and correct when speaking or writing your texts. Knowing the definition ofWiktionary:Beer parlour/2011/December, as well as those of other words, enriches your vocabulary and provides you with more and better linguistic resources.
This is an archive page that has been kept for historical purposes. The conversations on this page are no longer live.
Okay, so I've been away from Wiktionary for a while...Recently though, I've started creating more categories and doing other little things. What has irked me slightly though is looking through my deleted contributions list. So broadly speaking, this is my question:
Why the frigging hell are there so many deleted categories?! O.o
To be sure everyone's clear on what I do and don't get, here are a few points to elaborate:
Yeah, yeah...I get that "mainspace-isation" of appendices idea got lynched so I know why all the anime categories and shit are gone.
Okay, perhaps some topical categories I created shouldn't exist so in such cases I understand that too.
This is something I just don't get tbh...some categories I made deleted simply for being empty. Some of these were most likely created in a chain process. That is to say, I created a topical category listed on Special:WantedCategories then that in turn created a redlink to another category (which, in some cases due to lack of existing material on the subject in the language in question, may have been empty).
To add to Yair rand's comment, in case you don't already know — categories can't be moved, only deleted. Really, the deletion summary should point to the new category, but (somewhat understandably) not everyone bothers to do that, and (unfortunately) it's basically impossible to fix after-the-fact. —RuakhTALK02:51, 2 December 2011 (UTC)
I've on occasion deleted something, realized I should have included a good summary, so created/restored it and deleted it again. I assume the same can be done for a category.—msh210℠ (talk) 19:01, 2 December 2011 (UTC)
Okay, thanks for the replies.
@Purplebackpack89, I don't mean to sound rude but how should I know? Maybe that would be a good idea yea, but those Special pages are automatically generated, not created by contributors.
Xylo, the reason I'm asking is the first thing that came to mind is that the list is highly disorganized to the point of non-navigability. If they're automatically generated, maybe get better bots? I'm not faulting any one editor for the disorganization, merely pointing out that the problem would be easier to remedy if the category was organized Purplebackpack89(Notes Taken)(Locker)19:36, 2 December 2011 (UTC)
It's not a category, but a special page. It's not created by a bot, but built into the software. If you want to create a project page that you believe to serve the same purpose, but better, then please be my guest. —RuakhTALK20:24, 2 December 2011 (UTC)
Letter entries
Many of our letter entries are really useless.
Take for example Ế. It is defined as "The letter E with a circumflex and an acute accent." That is not a definition, it is an etymology. It's comparable to defining dictionary as "A word composed of ten letters." It doesn't convey any sort of meaning. Therefore, I propose we delete the whole bunch of letter entries which contain no content beyond that. -- Liliana•14:14, 4 December 2011 (UTC)
Most dictionaries do have letter entries summarising the origins and pronunciation of the letter (e.g. Chambers for E has "the fifth letter in the modern English alphabet, with various sounds, as in me, get, England, her, prey, and often mute, commonly indicating a preceding long vowel or diphthong"). Letters do not really have a "meaning". Equinox◑15:14, 4 December 2011 (UTC)
In case you haven't read the main page Liliana, I think this paragraph is of at least some relevance:
"Designed as the lexical companion to Wikipedia, the encyclopaedia project, Wiktionary has grown beyond a standard dictionary and now includes a thesaurus, a rhyme guide, phrase books, language statistics and extensive appendices. We aim to include not only the definition of a word, but also enough information to really understand it. Thus etymologies, pronunciations, sample quotations, synonyms, antonyms and translations are included."
Keep 'em, I've actually used these pages to identify weird letters I've found in entries by copying and pasting them into the search bar. Something like "The letter E with a circumflex and an acute accent." would provide useful information to me. Mglovesfun (talk) 18:15, 4 December 2011 (UTC)
I agree, although I admit I hadn't though of using that approach before. There are some characters I can read on some browsers, but cannot read on others. IPA characters often don't display in certain versions of browsers, but if I paste one into a Wiktionary search tool, the entry for that symbol would pop up. The same is true for weird central and south Asian scripts that almost never display for me. --EncycloPetey04:18, 9 December 2011 (UTC)
@Palkia: You must not have been comparing our English definitions with those contained in the better online English dictionaries. The quality of our definitions is often quite poor, often no better than Webster 1913 and often worse. We have expanded our coverage in peripheral areas without addressing the main goals that users usually have for their dictionaries. In English, for synonyms and antonyms I would recommend Dictionary.com; for definitions MWOnline; for quotations Wordnik (or Google); for statistics COCA, COHA, and BNC; for etymologies Online Etymology Dictionary, for pronunciations almost any online dictionary. We seem to have the edge in translations. DCDuringTALK21:04, 4 December 2011 (UTC)
Possessive Pronouns vs Possessive Adjectives
This has probably been mentioned several times, but I think Wiktionary really needs to resolve and decide on the issue of possessive pronouns vs. possessive adjectives, just for the sake of consistency if for nothing else. The words in question include 'my', 'your', 'his', 'her', 'its', 'our', and 'their'. As of now, most of them are listed as "possessive pronouns", but 'my', 'her', 'its', and 'our' are listed as "possessive adjectives", and there is some disagreement about what they should be called, as a few people have insisted that they are traditionally considered pronouns. Most dictionaries I have seen, on the contrary, consider these words possessive adjectives rather than pronouns, including Merriam-Webster, but a few do consider them pronouns. I'm on the side of the adjectives, or at least possessive determiner, because I don't see them standing in for nouns, as opposed to 'mine', 'yours', 'his', 'hers', 'ours', 'theirs', which are only pronouns.
The other reason it's important to resolve this issue is because the translations for other languages have discrepancies with their English entry equivalents as well. For example, French 'leur' and Italian 'loro' are considered to have a possessive adjective meaning- "their" (in addition to a separate function as a possessive pronoun, "theirs", but the difference is made clear). The authoritative dictionaries of these languages also list these words as having a possessive adjective use. If one clicks on a translation link to one of these from an English entry, where the word is only a pronoun, they'll end up at a Spanish page where it is an adjective and it might confuse them. Either way, some articles are going to have to be changed for these words to match up correctly.
(the reason I don't want to just edit these myself without consulting here is because I don't want people to get mad about changing a page for a common or important word) Word dewd54418:22, 4 December 2011 (UTC)
For English, good reasons can be given for any of "possessive adjective", "possessive determiner", or "possessive pronoun", and though my preference is ===Determiner===, I'd be fine with ===Adjective=== or ===Pronoun===. What I would not be fine with is forcibly transposing this classification into other languages. Whether their is an adjective or a determiner or a pronoun has little bearing on whether leur or loro is. —RuakhTALK18:46, 4 December 2011 (UTC)
Historically the first- and second-person forms are adjectives or determiners; they inflected as such in Old and Middle English. The third-person forms were historically the genitive form of the pronoun, but they later came to be inflected as adjectives or determiners as well by analogy (the situation in the Romance languages is similar, but only 'loro' and its varieties is a genitive, from Latin illorum). I prefer determiner to adjective myself, although I'm not quite sure how they can be distinguished. —CodeCat21:41, 4 December 2011 (UTC)
Keep in mind that this will not necessarily be the same for every language. For English, I agree with the comments above that Determiner is probably the best header, although I'd like to see a (possessive) context and a cross-categorization of the terms in a sub-category of pronouns for people searching that way. However, they inflect and act more like adjectives in Latin and in Romance languages like Spanish. So, in those languages they might have a different header. Words that translate each other between languages do not always share the same part of speech grammatically in the two languages. As an extreme example: the English word (deprecated template usage)year is a noun, but its Navajo translation is a verb. There isn't a noun for that term in Navajo. Any decision about how a set of words are to be classified must necessarily be a language-specific decision. It does not apply automatically to other languages because each language will have differences in grammar from other langauges. This includes differences in the parts of speech. --EncycloPetey21:47, 4 December 2011 (UTC)
From what I've seen, the distinction between adjectives and determiners is one of semantics and syntax, not about inflection. So we can't use the type of inflection to determine whether something is an adjective or not. The fact that in Dutch and several Romance languages the possessives can be preceded by a definite article may be significant, though. —CodeCat22:47, 4 December 2011 (UTC)
Regarding the issue of translation between languages: fair enough, we don't need to worry about that, I guess. But as for consistency within English, we can agree to allow them to be called just determiners, with a 'possessive' context added? I'm not overly concerned; it's just that I hope people won't take the dictionary less seriously by seeing half of these listed as pronouns and others as adjectives when they're the same part of speech. -Word dewd54320:05, 8 December 2011 (UTC)
The confusion here can partly be attributed to the loose use of the term determiner, which is widely used both as a lexical category (or POS) term (equivalent to noun, adjective, preposition, etc.) and as a functional term (equivalent to subject, object, complement, modifier, etc.). Our headings should be based on lexical category, not function. The lexical category of the items in question is pronoun. They are the dependent genitive case. As I is to Brett, my is to Brett's. This group of pronouns function as determiners in NPs, just as genitive NPs do. That doesn't mean either of them belong to the same lexical category as words like the, each, many, and all.--Brett13:04, 12 December 2011 (UTC)
Inclusion of Unish as a language.
Recently I blocked a user for adding an entry with an unrecognized language, Unish. There is no reference to it in Wiktionary and a brief look on the Net afforded me nothing. One of the authors of this presumably new constructed language contacted me on my talkpage regarding this. I am not familiar with the criteria required to include a new language in Wiktionary, so I am opening a discussion here. Jamesjiao → T ◊ C02:58, 5 December 2011 (UTC)
I'll listen to arguments, but would like to see an ISO 693-3 code, and I'd like see ISBNs of books written in (and preferably not on) Unish.--Prosfilaes05:00, 5 December 2011 (UTC)
It'd have to be approved, but asking for ISBNs of books written in (and not on) Unish is a pretty high standard, one that several of currently approved languages might not meet (and I might argue for removing them for that). It's not perfect, but it's a good sign this is a real language, and not just a project.--Prosfilaes13:09, 6 December 2011 (UTC)
Esperanto and Interlingua are on solid ground; I believe Ido and Volapük can also meet that qualification. (Not necessarily ISBNs for the older languages, but seriously printed material.) I don't believe that Occidental or Novial can. And I'm pretty sure that the only published material in Lojban is The Complete Lojban Language.--Prosfilaes13:58, 6 December 2011 (UTC)
I have to agree on Lojban, it seems pretty useless for our purposes and I have no idea who would use that language seriously. Occidental might have historic publications (haven't checked), Novial... dunno, likely not. Incidentally, these were only approved because we have Wikipedias in these languages, so yeah. -- Liliana•15:05, 6 December 2011 (UTC)
To be honest I have never seen that language outside the lojban.org website. It really seems to be just someone's pet project. -- Liliana•15:22, 6 December 2011 (UTC)
There are 2603 sentences in Lojban in tatoeba.org, which makes Lojban #35 out of 94 languages in tatoeba.org. Since Lojban is based on predicate logic, it could well be interesting to logicians. Ward Cunningham brings up (in his wiki) the question of whether Lojban could be useful for Artificial Intelligence. Duncan College at Rice University has offered a course, COLL 109, on Introductory Lojban, worth 1 college credit. Lojban has a formal grammar which enables one to (1) unequivocally determine whether a sentence is Lojbanic or not, and if the sentence is Lojbanic, then (2) it can only be parsed, unambiguously, in exactly one way. The formal grammar is "implemented", e.g., through a parser/translator available online under the name "jboski". Those two points make Lojban rather unique, even among artificial languages, and might offset the fact that it does not have much literature (as Ward's Wiki says, the language is at an "embryonic" stage (and whether it could "take off" is anybody's guess: IDK)). Anyway, since Lojban has its own Wiktionary, which could have articles linking to en.wikt, I think it would be in the interest of "diplomatic reciprocity" (?) for en.wikt to allow Lojban articles in its mainspace. —AugPi17:59, 12 December 2011 (UTC)
Looks like this is not getting approved, which is fair enough. The individual who wrote me isn't obviously motivated enough to engage in this discussion either. Just some further info on this language - their homepage ; the person I blocked but has now been unblocked under the condition that he/she does not make further entries in this language without engaging in this discussion first - User_talk:K11312. I have tried emailing this user, but it says that there is no valid email address associated with the account. I suggest giving them another week to respond before closing this discussion off. Jamesjiao → T ◊ C20:58, 5 December 2011 (UTC)
This is related to this topic, but might not be on this topic. Which category format are we supposed to use right now? This ] (without specifying the script) or this ] (specifying the script)? Jamesjiao → T ◊ C21:06, 5 December 2011 (UTC)
I would prefer the script specific ones seeing as the functionality has been added (or was it already there?) to {{topic cat}} to have a script parameter. Furthermore, they are certainly being used; someone (dunno who since I haven't been checking histories) has transferred/added lots of entries to the script-specific categories. Just look at this one that I created earlier: Category:cmn:Musical instruments in traditional script. It is a good idea IMO, as of course, a user may only be interested in trad. or simp. Mandarin. 50 Xylophone Playerstalk00:02, 6 December 2011 (UTC)
I think this (which category format to use for cmn) needs to be sorted first before looking at why "Category:cmn:Topic X in simp./trad. script"'s in "Categories needing attention". I am thinking that the sc parameter of subject qualifier templates such as {{physics}} should somehow produce a category for the corresponding script for cmn instead of just cmn:Physics, that is, if people here prefer to have separate categories for the two scripts. In summary, sc=Hans should produce "Category:cmn:Physics in simplified script", sc=Hant should produce "Category:cmn:Physics in traditional script" and sc=Hani should produce both!. Just a thought. With this sorted, we can then look at pulling those categories out from "Categories needing attention". Jamesjiao → T ◊ C01:32, 6 December 2011 (UTC)
I had a go at adding the function for Hans/Hant, but it didn't seem to work. Not sure why I didn't post it here straight away. Mglovesfun (talk) 10:09, 6 December 2011 (UTC)
I don't feel as though there is much to "sort" to be honest, James. Using the script-split categories seems just fine and as I said, they are being used; Special:WantedCategories is already flooded with them. Dunno if I'll be able to manage it but I think I'll just go and look at the template myself and seem if I can sort it out. Oh, and if I'm understanding what you're saying about the sc parameter correctly then as far as I can see it IS currently working so that sc=Hans should be used for simp. categories and sc=Hant should be used for trad. categories. 50 Xylophone Playerstalk17:04, 6 December 2011 (UTC)
Dammit...could someone take a look at {{topic cat}} and see if the can figure out a solution for me? This is what I did, which works fine but...apparently also seemed to uncategorise topical categories that were there for other reasons. For example, one that I fixed had the wrong topic specified in {{topic cat}} on the page but after I changed said template the category was no longer in the attention category even before I fixed it. 50 Xylophone Playerstalk18:23, 6 December 2011 (UTC)
First, to directly answer your question, really for consistency it should be in Music in trad. script, at least IMO. More generally, the way I see it I think it would be best to handle it in either of the following two ways:
Abolish the normal Mandarin topical categories altogether and just keep the script-specific ones.
Keep the normal Mandarin topical categories but only have them (perhaps only to a certain extent) as categories to contain the script-specific ones. That is to say (and yea, I know this example is something of a simpler case) a similar structure to what I organised for Category:Hungarian noun forms ; a category only to contain subcategories.
I'm confused about this discussion but I want to mention that Chinese categories shouldn't be renamed, deleted lightly, without checking what happened with the entries containing them. Renaming, deleting categories should be the last thing. Perhaps non-empty categories for any language should not be deleted/moved if the contained entries are not modified as well. --Anatoli(обсудить)22:34, 8 December 2011 (UTC)
I don't know what you mean if you are trying to refer to any specific incident but to make a general comment, trust me, I really don't mind working at stuff here like creating categories and fixing entry categorisation (for example, the transition from "Category:Topic x" as English category to "Category:en:Topic x", with "Category:Topic X" as something of a metacategory). So what I'm saying is, if any categories are to be renamed I'll gladly help when I can with the moving of entries from one category to the next. As for your confusion about the discussion, this is pretty much what the end up of it all is: The layout of Chinese (well, at least Mandarin but surely the same would be fine too for Min Nan and any other "dialects" that use trad. and simp. Han characters) topical categories that Liliana suggested, and I agree with is as follows:
I guess it doesn't change the point you're making, but it would be Music -> Musical instruments, not vice versa. Furthermore, as far as I can see if this mixture of "children" and "siblings" is a problem IYO then I hate to tell you but it still exists in a way. Just look at Category:Music; It has both siblings like Category:en:Music, Category:fr:Music, etc and true child categories like Category:Musical instruments, Category:Opera, etc as children. This script-split scenario is a special case in way and I think it would be alright to emulate the top level topical categories. Is it really that problematic? May I make a suggestion, and ask is it possible that something somewhere could be altered to separate the upper- and lowercase categories in the subcategory lists? That is to say, Category:en:Music would be indexed under "e", not "E" while Category:Musical instruments would remain sorted under "M" and not "m". That would sort out the top level categories at least.
As for the Mandarin subcategory scheme Liliana put forward, and I drew out, I realise that would not work as we are talking about
"Category:cmn:xxxx" vs. "Category:cmn:xxxx in simp./trad. script". Consequently, I have two suggestions:
Would there be some way to separate out the script specific categories and the true children into separate parts of the subcategory lists?
Would adding extra language codes (since I know we don't use solely ISO codes) for script specific things be out of the question? TBH,I'd prefer not to have to deal with this unless it could be handled well by a bot. What I'm getting at is, say we made "cmn-t" and "cmn-s" the codes for traditional and simplified Mandarin. Then, all the categories of format "Category:cmn:xxxx in traditional script" would have to be moved to "Category:cmn-t:xxxx". So of course, then all the entries would have to be edited too...so yea, that'd be an awful lot of work. 50 Xylophone Playerstalk22:50, 11 December 2011 (UTC)
I'm rather queasy about the use of an image of a convicted criminal here. Could some others have a look and give your opinion? After all, we're dealing with a human being, not an inaminate object. __meco13:43, 6 December 2011 (UTC)
I'm fine with it. The photo is already publicly available, and the caption is neutral and unemotional: it just says he is a convicted murderer. Equinox◑13:50, 6 December 2011 (UTC)
At the risk of side-stepping, I think this sort of debate should be on Wikimedia Commons rather than on here. w:personality rights is a bit tricky, looking at the USA section, it often conflicts with the first amendment so as non-legal experts, it's hard or impossible for us to form an opinion that might later turn out to be legally valid. Mglovesfun (talk) 15:26, 6 December 2011 (UTC)
I agree. (By the way, I think that ideally, our content should be legal outside the U.S. as well; obviously we don't have any legal obligation to protect our mirrors from violating the laws of their own respective countries, but it would still be nice to minimize such issues.) —RuakhTALK18:01, 6 December 2011 (UTC)
Guys.. I'm not raising the issue of legality. I'm simply pointing out that we could consider the human implications of this image and maybe try and find a way to do this which causes the least harm. Starting with, is this the mug shot we want to go with? Perhaps using an older image of a deceased person would be better? __meco19:43, 6 December 2011 (UTC)
I am with you, there are plenty of mug shots of long since dead people, no reason to use one of a living individual. I am also with Ruakh, when it doesn't negatively impact the goals of the project we should do our best to be easily accessible and mirror-able. - DaveRoss20:34, 6 December 2011 (UTC)
I am completely unbothered by our usage of this image — such mug-shots appear regularly in the news, even of people who end up not being convicted — but I would also be completely unbothered by you (or TheDaveRoss, or anyone else) changing it to an older image of a now-deceased person. —RuakhTALK20:38, 6 December 2011 (UTC)
The image has an emotional impact, and provokes questions in the reader's mind about its appropriateness, even if we have resolved those questions as moot. An image that is clearly historical or fictional would be better as a pure academic illustration of the concept, and not a very personal-looking portrait of this particular guy.
There's no reason to show a living person, nor a child molester, nor someone whose victims' family and acquaintances might actually try to use Wiktionary to look something up. —MichaelZ. 2011-12-07 04:45 z
This occurs because {{lad/script}} produces Hebr, so the -ero and -ar and so on are getting marked as right-to-left. I suppose the first question is — in what scripts do we want to include Ladino? If we only want Hebrew-script, then these categories should be deleted (problem solved), and if we only want English-script, then we should change {{lad/script}} to produce Latn. If we want both scripts, then either (1) we need to choose one as the default, and accept the use of sc=... for the other; or (2) we need to invent some language-code distinction between English-script Ladino and Hebrew-script Ladino. I have some thoughts, but I'd rather get input from someone who really knows Ladino. (I'm considered "Sephardi", but technically I'm actually Mizrakhi. My background is Persian, not Iberian. Not that I speak Bukhari, either!) —RuakhTALK21:30, 7 December 2011 (UTC)
FWIW, I've done some research into this... at least enough to make me abandon the idea of learning Ladino myself. Historically, the language was only written in Hebrew script, but this has started to change over the past 50 years. Many dictionaries and grammars are using a transcription into Latin characters rather than Hebrew script. However, there isn't a standardized transcription used, and even individual books on Ladino that I've read will explicitly state that their transcriptions are somewht dynamic with pronunciation, rather than strictly transcribing the written characters. So, the various dictionaries and texts in Latin scripts seldom match spellings of words. --EncycloPetey04:11, 9 December 2011 (UTC)
Nouns and proper nouns
I've been wondering for a while whether it is really a good idea to distinguish between common and proper nouns in headers and categories, and I can't really come up with any good reason why such separation is needed. I can think of several reasons, however, for why it would be good to merge them under a single ===Noun=== header:
Simpler entry structure for entries like e.g. Egyptian, where there is a common noun sense (person from Egypt) and a proper noun sense (language) and these are both really the same word with the same etymology
The distinction between common and proper nouns is not always clear, sometimes even disputed, with linguistic arguments and convention sometimes at odds. Non-distinctive labeling can thus spare editors quite a headache in some cases (language names and nationalities are those words which are most confusing). And what about names for people? Take Jane, for instance: in “I went to the park with Jane,” Jane is grammatically clearly a proper noun, right? But in “There's a Jane in the office, and two more Janes work at your school,” it seems that Jane is a common noun meaning any person whose name is Jane. It doesn't seem right to have a separate header (or even a separate sense) for this, because this usage possibility exists with all personal names, and indeed with all proper nouns. Nouns that are usually common can similarly be used like/as proper nouns, e.g. mother: “I went to the park with mother,“ whereas e.g. “my mother” or ”all mothers unite” clearly display commonness. Common nouns can be used to make completely transparent proper names on the fly, etc., etc.
For some languages, there are no grammatical features which indicate proper noun usage, yet the proper noun header is being thrust upon them, seemingly indicating a grammatical difference. These are e.g. the Slavic languages (barring perhaps Bulgarian/Macedonian, which have definite suffixes), Latin and Ancient Greek.
It seems to me to be more of a semantic distinction (though sometimes having some bearing on which words may be used alongside the main word, etc.). Compare e.g. the different categories of pronouns, grouped under the ===Pronoun=== header. What do you guys think? – Krun02:40, 8 December 2011 (UTC)
You just said what I always wanted to propose to the community. I completely agree. There is no grammatical difference between Noun and Proper noun in Armenian. --Vahag04:24, 8 December 2011 (UTC)
I can understand that this distinction doesn't matter much for some languages, but it certainly does for others like English. English proper nouns are almost never countable and can't be preceded by an article. Are there any other kinds of noun that are like that? —CodeCat18:10, 8 December 2011 (UTC)
That's incorrect, Codecat. Is Egyptian a proper noun? It can certainly be counted, and is always capitalized. "The Louvre" is certainly a proper noun and is preceded by an article. Granted, besides demonyms and such things I can't think of any proper noun that can be preceded by an indefinite article. Grammatically speaking, proper nouns are just nouns that have special uses. — — 18:53, 8 December 2011 (UTC)
I have always been against the distinction of noun and proper nouns, too. Many languages have virtually no proper nouns, and almost no language other than English observes this distinction. It has been my understanding that the main reason that proper nouns are distinguished in English is to explain capitalization. Monday in English is a proper noun, but lunes in Spanish is not. January in English is a proper noun, but январь in Russian is not. French is a proper noun in English, but français is not one in French. In many if not most non-Indo-European languages, there are almost no proper nouns except for names borrowed from other languages such as English. Yes, I have heard the argument that not all proper nouns are capitalized, but every example of an uncapitalized proper noun I’ve been given turned out to be a common noun. And that not all common nouns are uncapitalized, but all the examples of capitalized common nouns turn out to be the first word in a sentence, or part of a heading, or in fact a proper noun.
While it is true that proper nouns are said not to be countable, this is because of the feature of any proper noun that there is only one. But that rule is not a razor, it is only a clue. I think most proper nouns can be countable: there are many Steves, many Mondays, many Januaries; you have have multiple Sony’s, two Germanies, multiple Africas, lots of Coca-Colas. So that rule is just a red herring. As Ric points out, many common nouns may be uncountable, such as mass nouns like water, food, fish.
I recently got into an argument with an anon about the proper noun Civil War and the Navajo word for it which is not a proper noun. He could not understand how a proper noun in Engish would not also be a proper noun in Navajo. In Navajo, almost the only proper nouns are names borrowed from English. But Navajo does not recognized nouns versus proper nouns...only native words versus words borrowed from English. —Stephen(Talk)19:34, 8 December 2011 (UTC)
The capitalization rules are a modern innovation. It is thus a fallacy to think that "proper noun" originated as a concept to explain capitalization. Quite the reverse is true. In older English (older Modern English), nouns were capitalized far more frequently in random locations, and you can see this in many 17th and 18th century documents as a regular feature. Shakespeare's and Milton's capitalization would confuse any 21st century reader. And yet Locke wrote a lengthy discussion on the distinction between common and proper nouns in the midst of this, and did not rely on capitalization as any part of his argument. --EncycloPetey04:05, 9 December 2011 (UTC)
I agree with what is explained. I can add that the tradition about what a proper noun is is slightly different in different languages (e.g. in French, language names are never considered as proper nouns). Nonetheless, I consider this is an important distinction, and it should be kept, at least for languages using it. I also would add Surname and First name in addition to Proper noun, because they are very special cases. Lmaltier19:43, 8 December 2011 (UTC)
The distinction of proper noun and common noun is often explained as capitalisation but that in itself can make no sense at times. For example, in Dutch, there is a rule saying that a noun referring to a people should be capitalised if they are culturally united, and not otherwise. So Inuit is capitalised but indiaan is not. It's very arbitrary, and I don't think these words are proper nouns at all. At the very least, I would say all names for individual entities are proper nouns, like England, Julie, Mars and such. But after that I don't really know... Atlantic Ocean doesn't really seem like a proper noun to me, because grammatically it can easily be divided into an adjective + noun phrase. What makes it special is only that there happens to be one Atlantic Ocean, which is why we label it the Atlantic Ocean. For England, we don't really have a need to say the England, because grammatically 'England' already implies that it is unique. Now, you could say I don't know a Julie or I don't know any Julies, and here it seems like the word is countable. But I would say that in this case, 'Julie' has become a metonym for 'a person named Julie', just like a Picasso is a painting and not the person himself. —CodeCat21:29, 8 December 2011 (UTC)
The trouble is where to draw the line. If a word can be used “as a proper noun” and “as a common noun” (with such easily and automatically connectable senses as “this certain person called Julie” and “someone called Julie”), how do we determine what it “really is”, i.e. the primary function, proper or common? Arguably, it's fairly straightforward with people's names (or is it?), and even easier for place names, but what about e.g. Monday? I can see that it's actually marked simply as a noun now in its Wiktionary entry, although Easter Monday is marked as a proper noun, although there is no difference between these except that the repeat cycle for a regular Monday is shorter. Which function is primary in these? Example for proper noun usage (actually more than one sense): “Monday is the second day in the week” (meaning the general concept of Monday within the context of the week, also as a general concept), “I'll be back by Monday” (meaning the next Monday specifically, compare “by 2012”); for common noun use: “the following Monday”, “the first Monday in September”, “two Mondays from now”, “theres always a Monday after a Sunday” (all the same applies to Easter monday, Christmas Day, Christmas, etc.). This of course, also leads to the question of whether any of this matters for the header and categories of the word. The appropriate usage will usually be quite plain from the definition provided in the definition line, and can also be further illustrated by usage examples, quotations, and usage notes. I really don't see how “proper” in the header will offer any further clarification than the definition line. There are all kinds of other restrictions that semantics can impose on word alignment that we don't try (and fail) to clarify in the POS header, e.g. the difference between place names and personal names; consider these sentences: “I was in Montreal”, “I was talking to Julie”. They can't readily be reversed. They must be used in a specific way, but for semantic reasons. – Krun00:22, 9 December 2011 (UTC)
The distinction between any two parts of speech in English is fuzzy. This does not mean that there are not useable categories that have grammatical differences; it simply means that language is messy and does not always follow the strictures of grammarians. In "The meek shall inherit the earth;" the adjective meek is used as a noun. In "copper coffee kettle," the nouns copper and coffee function like adjectives in giving attributes to the following noun. Latin grammarians made no distinction between adjectives and nouns, and this division into two separate parts of speech is a fairly recent innovation. Similar blurry lines are easily found between adverbs and prepositions, and between certain verb forms and adjectives or nouns. This does not mean that we should abandon these distinctions, simply because the lines distinguishing them are not 100% clearly made. The important question is whether a different header will mark a signifiacnt difference in lexical content or in usage. In fact, proper nouns in English function quite differently from common nouns, and that's one reason we have far more arguments discussions about inclusion of proper nouns en masse than we do for common nouns. It;s also why we have more heated debates about defining proper nouns. See User:EncycloPetey/English proper nouns for a start on a page explaining both the philosophical distinction as well as rough notes begun for characterizing the differences in grammatical usage. --EncycloPetey04:05, 9 December 2011 (UTC)
I suppose my main question is whether the distinction is useful where we use it. I believe it isn't, and in fact gets in the way, complicating entry structure and moving debates from where they belong. I don't dispute the existence of proper nouns, but, as your think tank page makes clear as well, the lines are far from clear-cut, and individual lexemes (unique words) cannot all be cleanly put in one category or the other. Many (perhaps most) can be both, whether by metonymy (or another type of transparent derivation applying to all nouns otherwise of the one category), or by clearer sense distinctions (Albanian (“specific language” or “person from Albania”). Since we have a separate header for proper nouns (and the Noun header thereby implies “common noun”, which I don't actually like either), we cannot treat both cases under one header or the other. This is true of Monday and Julie as much as Albanian. It would mean e.g. that, for Julie, there would also need to be a (common) noun section if we were truly to be consistent. I however, find such a treatment to be impractical; I want to treat both under the same definition line (recognizing the potential automatic metonymy as inherent), hence under the same header. But since this (secondary) sense makes it a common noun, I find it wrong to place it under the ===Proper noun=== header, and that is why I think a simple ===Noun=== header for all nouns, common or proper, would be better. This does not mean that any information is really lost; even without the “proper” in the header it is quite clear that London (referring to the capital of England) is a proper noun, that is if you actually know what a proper noun is, which you also must know to be able to understand the ===Proper noun=== header. I think it would be much more useful to read a grammatical treatise on proper nouns, including a discussion of all the fine points, borderline cases/disputes, philosophical and grammatical considerations, etc., than to rely on (sometimes arbitrary/inconsistent) labeling in entries. We really should have some good general grammatical appendixes. – Krun11:41, 9 December 2011 (UTC)
In French, and in English too (I think), all proper nouns may be used as common nouns (the Winston Churchill of Germany, etc.) But this use does not make them common nouns, it's a figure of speech. Lmaltier18:21, 9 December 2011 (UTC)
It is true, I think, that all proper nouns (in most Indo-European languages at least) can be used as you describe. And on the contrary, it does make them common nouns in that instance (while not generally), although it clearly derives from another (perhaps the primary) sense of the word which happens to be a proper noun sense. – Krun18:51, 9 December 2011 (UTC)
To recap: I think the property of “proper” or “common” belongs to specific, narrow senses (semantic) and not to words, as a whole (lexical), and should therefore (and for the practical reasons stated above) rank below the true lexical properties (POS), just as the definition lines are under the POS header. – Krun19:27, 9 December 2011 (UTC)
POS is not a lexical property; it is a semantic property. That's why our senses are grouped under POS headers. I don't understand the distinction you seem to be making between "senses" and "words". When you say "word", do you mean "particular spelling"? For example, we currently list (deprecated template usage)eating as a verb form, adjective, and as a noun. All three derive from a single source and have similar lexical content; only the grammar distinguishes them. Do you think, therefore, we should eliminate the separation of those three headers because this is all one "word", and instead indicate adj., verb, noun individually for each sense? --EncycloPetey16:34, 11 December 2011 (UTC)
It's not obvious to me what's being proposed here. If the proposal is to completely ignore the distinction between proper nouns and common nouns, then I oppose. If the proposal is simply to demote this distinction to an inflection-line-note or a sense label, say {{context|proper noun}} or something, then I'd be O.K. with that. This distinction seems pretty comparable to the distinction between countable nouns and uncountable ones, or that between transitive verbs and intransitive ones; for neither of those distinctions do we use separate POS headers. —RuakhTALK20:52, 9 December 2011 (UTC)
The proposal is simply to merge the ===Proper noun=== headers into the ===Noun=== headers. I like your analogy with countability and transitivity and agree that this is a very similar case; in a context label for an individual sense is precicely where this information belongs. Of course, as with both countability and transitivity, the label may not always be needed; indeed I think in most cases it would be superfluous. Would we really put # {{context|proper noun}}{{given name|male}} or # {{context|proper noun}} The capital city of England? We could, of course, do that for all proper nouns, and although rather superfluous and a bit cluttering I would still like it better than the status quo. I would prefer, however, that such labels were only used when necessary for clarification of the sense in question or the difference between the various senses under the same header. – Krun22:17, 9 December 2011 (UTC)
Krun just asked me to see and comment in this discussion. I've read mparts of it and skimmed therest, and agree with EP's post of 04:05, 9 December 2011 (UTC) and Ruakh's of 20:52, 9 December 2011 (UTC).—msh210℠ (talk) 18:53, 11 December 2011 (UTC)
Merge the headers. Sorting senses into Noun and Proper Noun headings offers more problems than solutions, and needlessly complicates entries. Most or all professional dictionaries seem to be doing this already. —MichaelZ. 2011-12-11 18:49 z
The way I see it, there is either a difference between proper nouns and regular nouns or there is not. If there is a difference, then I don't see why you would want to merge the two. However, if the argument is that a {{context}} label is more appropriate, then fine. However, that raises all sorts of formatting headaches of its own, unless the intention is simply to ignore that aspect (as is sometimes the case around here), leaving people like me to spend the next few years slowly cleaning up the mess by hand (yet again). In the case of Mandarin entries, a context label requires a lot of information in order for the category sorting to function properly. For example, if one were to modify a proper noun entry such as 曲阿 with a context label, the context label would look something like:
If the noun and proper noun labels are simply merged without doing the appropriate context labels in some automated fashion (not a trivial task, I'm sure), this would create a lot of extra busy work for me. I'm still cleaning up the mess that was caused by moving away from zh-tw and zh-cn labels in Mandarin. -- A-cai23:27, 11 December 2011 (UTC)
It would be helpful to clarify the terminology, at least as it applies to English. The Cambridge Grammar of the English Language is, I feel, uncharacteristically vague about this point, but it makes some useful distinctions between proper names and proper nouns. "The central cases of proper names are expressions which have been conventionally adopted as the name of a particular entity -- or, in the case of plurals, like the Hebrides, a collection of entities" (p. 515). "Proper nouns, by contrast, are word-level units belonging to the category noun. Clinton and Zealand are proper nouns, but New Zealand is not. ... Proper nouns function as heads of proper names, but not all proper names have proper nouns as their head" (p. 516). Under this definition, I believe demonyms like Egyptian would not qualify as proper nouns, despite being capitalized, while language names like Egyptian would qualify.
I agree that common nouns and proper nouns are all types of noun, and belong under the same top-level heading. Mind you, I also think pronouns do too. In contrast, proper names are not types of nouns but rather are NPs or nominals.--Brett 12:53, 12 December 2011 (UTC)
--Brett12:53, 12 December 2011 (UTC)
A more confusing edge case: The Chinese have a splendid cuisine. Is Chinese a (singular) collective proper noun or a (plural) mass common noun? Does the cuisine belong to the one and only Chinese People, or by the subset of persons who live in China, or the subset of persons of Chinese ancestry? Even the speaker might not be making a distinction.
Disregarding such ambiguity for the moment, I think properness of nouns is an aspect of their usage, and not an inherent quality of a term. We can indicate that a term is usually a proper noun, or not. This may be self-evident from the definition itself (for example if the referent is clearly a specific entity), or from the use of a term like “specific.” Perhaps a usage label is helpful in some cases. Or perhaps we should always use a label, for clarity and categorization. —MichaelZ. 2011-12-12 16:17 z
I have created a vote. Please continue the discussion on the vote talk page and comment on the proposal as you find necessary. – Krun01:17, 13 December 2011 (UTC)
Good job writing this up there. —MichaelZ. 2011-12-13 17:22 z
Changing Proper noun to Noun is easy, but changing Noun back to Proper noun is difficult, fr.wikt experienced it: we introduced the distinction between common nouns and proper nouns, because it was considered really useful. The change took a long time, and many pages got a wrong POS for a while.
Again, it should be considered that all proper nouns may be used as common nouns, it's a figure of speech, and, in most cases, such a use does not deserve a mention here. In French, in such a case, the nouns are capitalized, because they are proper nouns, not true common nouns, even if used as common nouns. When the figure of speech becomes so common that they really become true common nouns, they usually lose the capital (e.g. hercule, bordeaux) (usually but not always e.g. une Granny Smith). I know that, in English, they always keep the capital and that this rule makes the distinction much more difficult, but it exists too. Lmaltier09:07, 18 December 2011 (UTC)
I have just noticed that some editors have been marking language names in other languages such as Catalan (Category:ca:Languages) and Spanish (Category:es:Languages) as proper nouns. They are not proper nouns in those languages, they’re just common nouns. I did not check other common nouns such as months, weekdays, or nationalities, or any other languages, but I suspect this problem is widespread and would require a lot of work to clean up...unless a bot could be made to do it. —Stephen(Talk)13:33, 19 December 2011 (UTC)
RecentChangesCamp 2012
Just a reminder RecentChangesCamp 2012 is coming up soon! :D Please consider attending. :) It is a great opportunity to network with your fellow Wiktionary contributors. :) Invite all your wiki friends. :) You may be eligible to apply for a a WMF Participation grant or a WM AU grant if you're from Australia or New Zealand. If you're considering coming from over seas and you're female, you may also be interested in the ADA Camp, which could help better justify the last minute trip to Australia. :D We'd love to see you at RecentChangesCamp. :D --LauraHale10:06, 8 December 2011 (UTC)
Well 'attempt' seems to be the operative word; if they pass the deletion process, what's the harm anyway? I agree that lung cancer in particular doesn't meet CFI, yet it'll probably pass. I'd argue it the other way, there's a frenzy about keeping SoPs that don't meet CFI. I'd welcome ideas that would make such terms includable. NB I don't mean I'd support any such idea, just that I'd like to at least see it. Having said that, I think that CFI should reflect what good editors do, and if things like lung cancer, nominative case, accusative case (etc.) are consistently considered valid by the community,I think CFI should reflect that. Mglovesfun (talk) 16:04, 9 December 2011 (UTC)
What Mg said (except his first sentence. For example, nominating things in bad faith would be a bad thing (not that that's what's happening)).—msh210℠ (talk) 18:27, 9 December 2011 (UTC)
If terms belong to the vocabulary of the language, either the general vocabulary or a technical vocabulary, they should be included, even when SOP (e.g. Atlantic salmon). CFI should be changed to reflect this principle. Lmaltier18:32, 9 December 2011 (UTC)
A word of warning, RFD is very different from a vote on CFI as to avoid deletion, there only needs to be a no consensus, which depending on the closing admin, let's say about 40% opposition to the deletion. For a vote to pass on the matter, there needs to be 70% or more support. Which is why, irritatingly from my perspective, it's easier to vote keep outside of CFI on deletion debates than it is to change CFI to have these things meet CFI anyway. Mglovesfun (talk) 18:36, 9 December 2011 (UTC)
This is because our voting process is biased towards the status quo. The lesson here, paradoxically, is that if you want your entry to be kept, the best chance of success is if you just go ahead and disregard CFI and create it anyway. —CodeCat19:01, 9 December 2011 (UTC)
I agree, but then voting can become a bit 'faddy', where a proposed idea can get a lot of support when it is proposed and later become quite unpopular. Mglovesfun (talk) 19:07, 9 December 2011 (UTC)
Almost all ordered processes are biased toward the status quo. That is what is required to maintain order. A process in an ordered system could be excessively or insufficiently oriented toward favoring the status quo or certain types of change.
There is no special reason to favor terms related to linguistics just because the community of active contributors is especially sensitive to the possible opaqueness or complexity of the accepted meaning of a term. I saw few defenders for the terms being added by an emergency medical services practitioner (apparent, anyway), which are likely to be more prevalent in a work community that does not normally commit its efforts to writing in scholarly journals and texts. I think it would be interesting to invite that contributor back to take a hard look at the linguistics and computing terms that we deem worthy of inclusion. This is already a very insular group. We don't need special defenses for our insular preferences. DCDuringTALK20:06, 9 December 2011 (UTC)
Yes: The wise Ypresians decided to do something and fast, lest the plague revisit them. (delayedreaction.blogs.com) Lmaltier08:51, 10 December 2011 (UTC)
I could find no evidence of the use of Ypresian as a demonym. The OEDlists (deprecated template usage)Ypresian, but only as a geologic adjective with the definition "Of, pertaining to, or designating the lowest stage of the Eocene in western Europe, lying above the Landenian. Also absol." Regrettably, however, I have no alternative to suggest, and can only suppose that a standard demonym exists formed on one of the Latin names for the city, viz. Ypra or Hyprae. — Raifʻhār Doremítzwr ~ (U · T · C) ~ 15:21, 22 December 2011 (UTC)
I provide the evidence above. But, unsurprisingly, it's very rare in English (as a demonym), this is the only use I could find. Lmaltier21:42, 23 December 2011 (UTC)
Oh, sorry; I overlooked the parenthesis. I think it's Yprois that Equinox was looking for; it's much more common. — Raifʻhār Doremítzwr ~ (U · T · C) ~ 20:29, 24 December 2011 (UTC)
You are right, it's much more common (but very uncommon nonetheless). I would have imagined that it was a French word only. Lmaltier07:46, 27 December 2011 (UTC)
That's the experimental thing that was being discussed above, to show only one language and eliminate the Contents from long pages and use tabs instead. Looks like an epic fail to me too. It displays no level 1 header at the top, which is confusing, and horizontally compresses all the content, which is very bad. Someone please make it go away. --EncycloPetey00:50, 12 December 2011 (UTC)
I agree with EP. The extra, poorly spaced hairlines all around the text are very distracting, the wasted horizontal space is bad, and a margin based on the length of the language name makes page layout completely inconsistent. Do not want. —MichaelZ. 2011-12-12 01:26 z
And I 'agree', if you will, with CodeCat. Sounds like I should be thankful. Or maybe I just need to clear my cache.—msh210℠ (talk) 01:33, 12 December 2011 (UTC)
I have two observations, one expanding on EP's point about Translingual's priority over English and one about the lack of a ToC to navigate long entries.
At the very least, we should be able to select whether the Translingual or the English section merits priority placement, perhaps by placement of a template. In addition to the programming effort, this would require that we establish some criterion for determining whether the Translingual or English section for an entry merited priority placement. I would also see risk in creating such a template, for it could be used to force the default display of a specific language for any entry in which it were placed.
For long English (or other language) sections, the lack of a ToC for the section makes navigation slower for experienced users and makes the scope of the entry less clear. I understand that it is not desirable to have both the right hand side ToC and the left-hand side tabs appearing at the same time. I don't know which of the two is more important from the point of view of the assumed target default user. Judging from the choices being made and accepted by our active contributors, that target default user seems to not be a native English monolingual user. DCDuringTALK11:52, 12 December 2011 (UTC)
Good idea (DCDuring, allowing the community to choose whether English or translingual should show by default). If that's not technically possible, and the community wants these tabs anyway, we'd have to decide which we want as default (English or translingual). The missing TOC is also a problem, but it'd be unwieldy with the tabs: so how about a minimal TOC (just L3, perhaps, or, in cases of multiple etymologies, L4s also) that ties in visually to the language tabs?—msh210℠ (talk) 18:00, 12 December 2011 (UTC)
I don’t know if what I’m seeing looks different from what the others see, since I still use the Monobook skin, but I think it looks pretty good. I could understand someone saying he kind of prefers that one over this one, or this one over that, but "godawful"? I like it. —Stephen(Talk)12:17, 12 December 2011 (UTC)
I like the new look too, and I'm using Vector. The number of times I want to compare two languages' entries for the same entry is miniscule compared to the number of times I don't want to. —Angr13:26, 12 December 2011 (UTC)
I think change is always a shock, a bit like when you move into a new house and the decor is awful, you soon forget about it and go on with your life. Mglovesfun (talk) 13:52, 12 December 2011 (UTC)
Admittedly not so good for me, as I like to format all the language sections of a page, so I know I have to click on every section one at a time to look for errors. But yes, I like it. Mglovesfun (talk) 14:01, 12 December 2011 (UTC)
If you have "Edit pages on double click" ticked under Editing Preferences, you can double click and open the entire page, including all languages. —Stephen(Talk)14:06, 12 December 2011 (UTC)
Why does this option have to abandon all the good features of the page index? Make the standard page index float at the top-right, only show sub-section links for the currently-selected language. You could even put a persistent “show all” checkbox at the bottom of the index, letting one easily toggle the behaviour instead of hiding away the option. —MichaelZ. 2011-12-12 16:27 z
Hm. Maybe better as a tiny triangle widget or something else minimal, to avoid adding page clutter. —MichaelZ. 2011-12-12 16:31 z
The one feature that seems just wrong about this is that, as a default, this format expends a substantial portion of screen space on a column for the language tabs. For much of its length, the column is simply white space for longer (usually English) language sections. I have spent a great deal of time trying to increase the amount of useful content that appears on the landing page. This seems to take a large amount away in one fell swoop.
Very few other websites that I have seen expend such prime real estate on navigation. Web pages have largely standardized on other placement of navigation, usually across the top in small type. If there is potentially an excessive proliferation of possible destinations, the widely accepted practice is sub-menus. I suppose it would require making some decisions about which languages merited inclusion in the top line of languages in the event that there are more than, say, 10 language sections. Perhaps none of our sacred slogans and principles offer us any basis for making such decisions.
The hairline border doesn't make any visual sense. It is, at best, a bit of extravagant eye candy that wastes even more horizontal screen space.
I think it would be a good idea to place the tabs horizontally in the place where the page name displays now. Since we use headword lines, we don't actually need the page name to be there anyway... —CodeCat22:47, 12 December 2011 (UTC)
Note: It is possible that some users are seeing tabbed languages without the styles applied, because their browser is still loading the old version of the CSS. If the language tabs on the left look like just unstyled links, you need to purge your cache for it to show up correctly. --Yair rand23:03, 12 December 2011 (UTC)
I quite like this new presentation. It has a strength in that it deals quite effectively with overlong entries. It also has weaknesses, one of the severest, IMO, being that it makes comparing homographic terms between languages more difficult. One solution to that is the inclusion of a show all / hide all toggle atop the column of language tabs; would that be possible? — Raifʻhār Doremítzwr ~ (U · T · C) ~ 00:09, 13 December 2011 (UTC)
Now when I try to look at another language, I lose the entire entry, can see nothing, and can not even reopen the English version. bd2412T22:09, 13 December 2011 (UTC)
You mean when you click on a language tab? What browser/OS are you using? Do you have any gadgets or prefs enabled? Did it work right at some point before? --Yair rand22:15, 13 December 2011 (UTC)
I've tried it with Safari, Chrome and Firefox - all with an identical look. BUT could the language names on the tabs be made smaller to allow more horizontal space for the substance of an entry. The more I use it the more I like it —Saltmarshtalk-συζήτηση15:35, 14 December 2011 (UTC)
Using IE. The problem still occurs. I go to a page and it looks normal (more or less); when I click on any language tab, the interior portion of the page (not the sidebars or top bar) goes blank. bd2412T18:32, 14 December 2011 (UTC)
Just making sure: You're talking about actual IE7, not IE8/IE9's "compatibility mode" IE7 simulator, right? (Compatibility mode gives a false positive for "onhashchange" in window, which I just added a workaround for.) --Yair rand02:06, 4 January 2012 (UTC)
I was actually talking about the compatibility mode, sorry. I was under the impression that it was the same as IE7. —Internoob22:44, 10 January 2012 (UTC)
That's because the fact-file box is in the wrong place: it should be in the ==Translingual== section. (The problem is less obvious when not using Tabbed languages, but it's a problem nonetheless.) If we do turn on Tabbed languages by default, such problems will certainly be fixed. —RuakhTALK04:57, 4 January 2012 (UTC)
Conference proceedings for eLEX2011: electronic lexicography in the 21st century
"This paper presents empirical findings from two online surveys on the use of online dictionaries, in which more than 1,000 participants took part. The aim of these studies was to clarify general questions of online dictionary use (e.g. which electronic devices are used for online dictionaries or different types of usage situations) and to identify different demands regarding the use of online dictionaries. We will present some important results of this ongoing research project by focusing on the latter. Our analyses show that neither knowledge of the participants’ (scientific or academic) background, nor the language version of the online survey (German vs. English) allow any significant conclusions to be drawn about the participant’s individual user demands. Subgroup analyses only reveal noteworthy differences when the groups are clustered statistically. Taken together, our findings shed light on the general lexicographical request both for the development of a user-adaptive interface and the incorporation of multimedia elements to make online dictionaries more user-friendly and innovative. "--Brett14:07, 12 December 2011 (UTC)
That is an interesting paper. Unfortunately, while they've found some results, they readily acknowledge that there's a confounder they have yet to identify. Seemingly, though, the following rank is from most to least important for users of online dictionaries: reliability of content, clarity, up-to-dateness of content, speed, long-term accessibility, links to the corpus, and, approximately tied for last, links to other dictionaries, adaptability, suggestions for further browing, and multimedia content. There's a fairly big drop between accessibility and links to the corpus, except for a definite cadre of users that ranked corpus links above everything but reliability. (As I said, they need to find the confounder.)—msh210℠ (talk) 17:18, 14 December 2011 (UTC)
Japanese transliteration - traditional or revised Hepburn transliteration?
Eirikr and I were discussing this earlier at his talk page, and to quote what he said:
My own sense is that all doubled two-morae vowel sounds ああ, いい, うう, ええ, and おお / おう should be romanized as a single vowel letter with a macron, provided that the second mora is not (1) part of the next word element / kanji character, nor (2) part of a declining stem, such as the end of -i adjectives or the -u in vowels. Examples:
あたらしい: atarashii - the second i changes during conjugation
とりい: torii - the second i is part of the next kanji character
ちいさい: chīsai
おおきい: ōkii - o + macron for the long "o", but for the long "i" here, no macron since the second i changes during conjugation
どう: dō
問う (とう): tou - the u changes during conjugation
おねえさん: onēsan
けいかく: keikaku
I tend to agree with him. In any case I would prefer if there would first be discussion and following discussion there be revisions. Haplology13:52, 12 December 2011 (UTC)
I also don't see the sense in using ū but not ā, etc. The rule should apply to all the vowels, except on morpheme boundaries in compounds, before inflectional endings, etc. I would understand, however, a system which more closely resembles the kana spelling, such that because う=u means that うう=uu, whereas ū, ā, etc. could mean ウー, アー, etc., and in that system おう would always be ou, and おお oo. The one thing that's really strange is えい. It is sounded as a long e (=ええ, エー), so why is that not romanized ē if おう is romanized ō? – Krun19:24, 12 December 2011 (UTC)
I have been romanising my translations as Haplology and I totally agree with this method. Yet, Ryulong has already changed the page - Wiktionary:About_Japanese/Transliteration, which I haven't reverted - notable examples are - okaasan and neesan. His point is that it is the revised Hepburn romanisation. One way or the other, we should discuss it first. --Anatoli(обсудить)19:38, 12 December 2011 (UTC)
The traditional form of Hepburn is extremely out of date. It was only used in the first edition of Hepburn's Japanese-English dictionaries (in 1867), and all subsequent editions have eliminated the "use a macron for every long vowel" form that makes up the traditional form since 1872. The "aa", "ee", and "ii" morphemes (in words of Chinese origin) have not been identified as ā, ē, and ī for nearly 140 years. The only vowels that get the macron, aside from when ー is involved, are ō and ū, and in the rare instances where this comes up on this project (obāsan, okāsan, ā, ē, and onēsan) it was a simple change that I made to fix this glaring error in Japanese phonology and academics.
However, I would not oppose using a form of romanization that differentiates between the ō in tōi (tooi) and the ō in Tōkyō (Toukyou).—Ryūlóng (竜龍) 23:55, 12 December 2011 (UTC)
Romanising Tōkyō is too common to replace it with Toukyou, it's used quite often in Japan on signs, like other macrons, it's also the alternative English spelling. I don't think changing obāsan, okāsan to obaasan, okaasan and onēsan to oneesan is fixing a glaring error but thank you for fixing others. There is a general agreement to use "ii" except for chōonpu cases. --Anatoli(обсудить)00:10, 13 December 2011 (UTC)
The Romanization guide of the MEXT is vague and it is not clear what is a long vowel. I totally agree with Eirikr in his way of Romanization cited above by Haplology. お母さん, お兄さん, お姉さん, and お父さん should be okāsan, onīsan, onēsan, and otōsan respectively. Just for your interest, there are a few sino-japanese words with a long i, such as 詩歌shīka and 弑逆shīgyaku. And remember, ordinary Japanese don’t know Romanization of Japanese well. They are only accustomed to Japanese input methods using Roman letters. Don’t believe them when they say 東京 is toukyou. We see ii very commonly such as in Niigata, perhaps because of the difficulty of distinguishing i and ī visually, but that doesn’t mean it is a correct usage. Japanese don’t care much about such differences, because Romanized Japanese is not an official writing anyway. — TAKASUGI Shinji (talk) 02:54, 13 December 2011 (UTC)
But ā, ī, and ē are no longer used, and have not been used since 1870, to transliterate the long a, i, and e as per the Hepburn dictionaries. Why should Wiktionary use a format that is heavily outdated and is not in use by any other Wikimedia project or any academics of the Japanese language for over one hundred years? I can show you the dictionary, and cite specific pages where "aa" (1, 468, 475), "ee" (82, 448), and "ii" (40, 53, 190, 191, 192, 193, 452, 453) are in use, and you will not find ā, ē, or ī in this book, because it doesn't include any wasei eigo. The only time that any of those vowels are indicated by macrons is if the ー is in use. The only modern publication that even comes close to using this format is the American National Standards Institute, but I do not think this was ever implimented and even then they omit I from the vowels that get macrons in native words.—Ryūlóng (竜龍) 09:42, 13 December 2011 (UTC)
We're having a bit of a confusion over at the English Wikipedia page as to what is and is not considered the romanization scheme. We have conflicting sources on the aa/ā issue in particular that we have been trying to iron out. The English Wikipedia, at least, has been using the form in the subsequent editions of Hepburn's dictionary, rather than what is apparently a form derived from his and is defined as the "modified" form there.—Ryūlóng (竜龍) 12:00, 14 December 2011 (UTC)
Regardless of what the discussion is here, I think it is better to include the kanji when describing the various long-vowel rules, thereby showing that 格子 and 子牛 are transliterated differently, even though both are こうし.—Ryūlóng (竜龍) 12:00, 14 December 2011 (UTC)
While that is fine, my issue is still with how Wiktionary deals with the long vowels a, e, and i in words of Chinese or Japanese origin, particularly as the Hepburn dictionary does not use the ā, ē, and ī forms after 1872. I am told the Kenkyusha dictionary, which uses a similar system treats the vowels differently from the original Hepburn dictionary, but I do not have access to this because it is not in the public domain.—Ryūlóng (竜龍) 09:48, 16 December 2011 (UTC)
(Chiming in a bit late here, was busy then sick, but I'm better now and have some time.)
Pulling in some more text from my Talk page, clarifying comments added in square brackets:
For Vowels: Judging from all the kerfuffle over at w:Talk:Hepburn_romanization, it's pretty clear that the terminology used to describe the different Hepburn variations is itself far from clear. Then reading the w:Hepburn_romanization page , it's clear that Hepburn himself was a bit confused -- long "e" in his first romanization system, Traditional Hepburn, was variously romanized as e or ē, which just seems sloppy, and for some reason long "i" alone of the vowels was never romanized as ī, which seems inconsistent with the other vowels.
The main WP article doesn't mention it, but the Talk page does describe use of i + macron in the Revised (or was that Modified? Or Revised Modified? Or Modified Revised?) Hepburn system, albeit with the only examples given of borrowed katakana words with the 長音符 .
If I understand you correctly, Ryulong, it sounds like you advocate using macrons only for the long "o" spellings おお, おう, or オー, and the long "u" spellings うう or ウー, and not using macrons for any of the long "e", "a", and "i" spellings. What is your reasoning for this? Is it purely borne of a desire to match what the Hepburn dictionary uses / has used? I confess I do not understand your position. w:Hepburn_romanization#Long_vowels illustrates that modified Hepburn uses macrons for all long vowel spellings other than "i", excluding cases where the second mora belongs to a separate morpheme. Is it your position that modified Hepburn is incorrect somehow? If so, could you explain?
One thing that bothers me about modified Hepburn is the inconsistency regarding long "i": if we are to use macrons to indicate long vowels, then why not for the long "i"? The morpheme boundary distinction makes sense to me, so いい(“good”) would always be transcribed as ii, since the second "i" mora is the declining adjectival ending and thus part of a different morpheme. However, for 新潟, the two "i" morae are part of a single morpheme, and thus the more consistent transcription would be Nīgata, using the macron to indicate the long "i". Essentially, this is my only suggested departure from modified Hepburn, as described at w:Hepburn_romanization#Long_vowels.
My main issue is that I don't have a copy of the Kenkyusha to determine what has happened since 1903. I only have documents such as this document from 1972 from the w:American National Standards Institute. And on why I promote the long o and long u only is because this is what I have become accustomed to on the English Wikipedia, at least until another editor there discovered that the page had been in error for five years.—Ryūlóng (竜龍) 20:57, 16 December 2011 (UTC)
Thank you for the explanation, Ryūlóng. That helps me see a bit better where you're coming from.
Looking at the ANSI document, I note tha0t this advocates using the macron for long single-morpheme vowels, such as ああ ā and ねえさん nēsan given as examples under Table 2. (The document also has some internal consistencies, such as romanizing し as shi in some places and as si in others, but given the flow of the text, my impression is that si is a leftover from an earlier version that was missed during editing.)
I just checked the from my work account (login required), and it seems they don't use either traditional or modified Hepburn as described on the WP pages, but rather use their own romanization scheme that seems to be based on traditional Hepburn. Examples from their 新和英大辞典（第 5 版） ("New JA-EN Big Dictionary, 5th Edition", published July 2003, and the only dictionary on the site that uses rōmaji) of the differences I've found from modified Hepburn as described at w:Hepburn_romanization#Long_vowels, and from other general best practice:
Romanization based on traditional Hepburn, i.e. not using macrons for long "a" or long "e" in native Japanese words, though resolving Hepburn's possible confusion where long "e" was inconsistently accounted for:
No spaces between independent morphemes, no capitalization of proper nouns:
新潟県中越大震災 (にいがたけんちゅうえつだいしんさい): niigatakenchūetsudaishinsai -- A more ideal romanization even just using traditional Hepburn might be Niigata-ken Chūetsu Dai Shinsai.
Non-Hepburn handling of long "o", where おお is marked as "oo" and おう is marked as "ō":
Poking around the site, I can find nothing that describes or explains their romanization system. I presume that such is probably included in the introductory pages of the dead-tree version, but I do not have access to that.
For my part, Kenkyusha's romanization scheme strikes me as more arbitrary and less consistent than I am comfortable with. I find that I again come back to the opinion that single-morpheme long vowels should be indicated with the macron instead of using doubled vowels, as a slight change to modified Hepburn. (Incidentally, this appears to be more consistent with spelling conventions for other languages that use long vowels, such as Māori or Latin.)
I actually find the arbitrary choices that have been made in the 5th edition to be exactly what I'm looking for in a romanization scheme, except for the spacing and capitalization issues.
I've recently come across some Library of Congress documents that say they use the "Modified" Hepburn scheme utilized by the Kenkyusha's 3rd edition (1983) and they use ā for ああ in "ああしたい". However, this other ALA-LC document (1997) Library of Congress publication uses "aa" for the same phrase.—Ryūlóng (竜龍) 04:57, 17 December 2011 (UTC)
Does the new tabbed languages view have some sort of hierarchy of languages for the sake of deciding which language gets displayed as default? Above people have discussed the problem of Translingual appearing rather than English, but at adobar I notice that Spanish appears rather than Catalan, despite Catalan being earlier in the alphabet. Is this intentional? —Angr17:56, 12 December 2011 (UTC)
I would like this to be selectable as a preference. I often work in one language specifically, and it would be useful if that language could be set as the default while I'm doing that. —CodeCat19:26, 12 December 2011 (UTC)
The hierarchy goes like this, in order of priority:
If the user arrives at an entry being directed to a specific section (from a link like ] or {{l|enm|foo}}) it goes to that section, otherwise:
If there's a translingual section it goes to that.
If there's an English section it goes to that.
If the language of the most recently viewed non-English/Translingual section is available, it goes to that.
If there's a language targeted through targeted translations it goes to that.
Otherwise, it goes to the first language on the page.
What do you mean by "the most recently viewed non-English/Translingual section": most recently viewed in any entry?—msh210℠ (talk) 18:36, 13 December 2011 (UTC)
Now that tabbed languages has been enabled, it works pretty well, even if there is some room for improvement. One problem I see is that a lot of languages other than English use plain links to link to words in that language. With tabbed languages, it will link to the English section instead, and this may confuse users. We already have a template that can link to a specific language section, which would be {{l|nl|wat}} to link to wat#Dutch. But this template still isn't used in most articles, which could create a usability issue if tabbed languages is enabled for all users. Do you think we should make this template required instead of optional? And can a bot be used to fix any links? —CodeCat19:23, 12 December 2011 (UTC)
I think {{l}} should definitely be used everywhere a plain link is used, though a ] might be used in running text if editors prefer. – Krun20:17, 12 December 2011 (UTC)
This shouldn't come up in running text, because then it's either an English word (where #English is not really needed), or else it's a mention (and should be using {{term}}). The only exception I can think of is quotations, where we occasionally linkify words for various reasons. —RuakhTALK20:25, 12 December 2011 (UTC)
So the assumption then is that a bare link is supposed to link to the English section, and when the word in question is not English, it's an error? I imagine this would be mostly in lists of terms like derived terms, see also, alternative forms and so on. On the other hand, for consistency it would be better to use {{l}} all the time, even for English, because it makes it much easier for a bot like AutoFormat to spot the mistake. —CodeCat20:36, 12 December 2011 (UTC)
Oh, I agree that we should always use {{onym}} or {{l}} in lists of terms. But in running text we frequently linkify English words — for example, one sense-line at ] links to ] — and I don't think those would benefit from {{l}}. —RuakhTALK21:07, 12 December 2011 (UTC)
First we build a website where different-language terms are on the same page, now we're adding a complicated interface that lets us pretend they're not on the same page. Doing this will break the most fundamental wikitext construction, the link.
Please rethink this whole undertaking. If there's a problem with multiple language terms appearing on the same page, then why don't we put them on different pages? —MichaelZ. 2011-12-12 20:33 z
I agree with you completely and I think it would be much better if every language had its own page. But it would take a lot of work to make that work right, and most people like to keep things as they are... —CodeCat20:36, 12 December 2011 (UTC)
I'm not sure we agree. I'm implying that this project will make Wiktionary worse. —MichaelZ. 2011-12-12 20:51 z
In that case you might want to take a page from lawyers, by not asking rhetorical questions when you don't know what answers you'll get. :-P —RuakhTALK21:03, 12 December 2011 (UTC)
In any case, using separate pages for different languages would only make the need for {{l}} even more obvious. —CodeCat21:31, 12 December 2011 (UTC)
If you move the contents of café#French to fr/café, slap a navbar of tabs on the top of the English entry at café, then you'll have what you want, without any javascript. It goes without saying that we'd have to agree on a major change to the whole project before this could happen. Forgive me for not also mentioning that creating a separate website interface, based on a completely different mental model of pages and links, for some portion of editors, would have drawbacks. —MichaelZ. 2011-12-12 21:43 z
I just want to make it clear that I would like {{l}} (or optional #Language in the link) to be standard for English words as well, since, when an English word is being linked to, it would be desirable to skip long TOCs (under the non-tabbed system) and the Translingual section (under both systems), since Translingual sections come before English ones. Also, such explicit linking would be more machine readable (e.g. for import of Wiktionary into projects with a database structure that splits up entries by language). – Krun22:59, 12 December 2011 (UTC)
FWIW, I already use {{l}} in every case (partially to skip unnecessary TOCs) and I'd support requiring it as standard. — Raifʻhār Doremítzwr ~ (U · T · C) ~ 00:04, 13 December 2011 (UTC)
So the basic link to ] in an entry becomes obsolete, and we have to use {{l|en|term}} every time? You're breaking basic wikitext linking for all editors, for the benefit of a cobbled-together interface that's optional, and presumably will only be used by a minority of editors. No, thank you. —MichaelZ. 2011-12-13 00:24 z
Trading ease of viewing for ease of editing doesn't seem like a good alternative, though. Using {{l|en|term}} makes Wiktionary more usable because it brings users closer to what they want to see. —CodeCat00:36, 13 December 2011 (UTC)
Yup. I find it very frustrating when I click a link (a word in the definition, synonym, etc.) and subsequently find myself at the top of a big page, having to scroll down, often through multiple language sections. This often happens with Icelandic, but also quite a bit with the shorter words in English, where there are many language sections and the TOC is very big, or in entries with a Translingual section. – Krun01:30, 13 December 2011 (UTC)
Shall we have a straw poll to gauge support for such a standard requirement? — Raifʻhār Doremítzwr ~ (U · T · C) ~ 11:55, 13 December 2011 (UTC)
Straw poll
Please sign below with {{subst:support}}. Sign as many as apply to you.
Please don't sign until 22:00 on 14 December (UTC), so as to allow for editing of the options until that time. Do edit the options until that time, heavily.
NOTE: All of these options are excluding from the discussion links that are generated by other templates (like {{term}}).
Support (though I actually use {{onym}} rather than {{l}}; same difference). But the only reason I'm voting this way here is that I'm only voting below on links in lists, which are mentions (though not italicized), so special markup makes sense. For links that are uses, such as in "A large cat", I think ] is preferable; it's just that I'm also fine with plain ] for that case, so that preference doesn't show up in my votes. —RuakhTALK18:56, 18 December 2011 (UTC)
Support — Since {{l}} specifies the proper script automatically. — Raifʻhār Doremítzwr ~ (U · T · C) ~ 02:36, 22 December 2011 (UTC)
My support below is for {{l}} or ], as individual editors decide.
I support the use of language-targeted linking to generate all links in definitions to English entries if Tabbed Languages is enabled by default for all users.
Support, for links in non-English entries only. No. If I understand the hierarchy of rules correctly, a plain ] will to an English or Translingual section (if present), so no need for targeted linking.—msh210℠ (talk) 17:26, 18 December 2011 (UTC)
I support the use of language-targeted linking to generate all links in definitions to English entries if Tabbed Languages is disabled by default for all users.
I support the use of language-targeted linking to generate all links in lists to English entries if Tabbed Languages is enabled by default for all users.
I support the use of language-targeted linking to generate all links in lists to non-English entries if Tabbed Languages is enabled by default for all users.
Support for Latin-script targets, because a ] goes (if I understand the hierarchy of the script's rules correctly) to an English or translingual section if present. I don't support this for other-script targets, since (again if I understand correctly) then target will be the section linked from (unless targeted translations is in force).—msh210℠ (talk) 17:26, 18 December 2011 (UTC)
Support. Unlike msh210, I especially support it for non–Latin-script entries, because then we want the appropriate script template to be used (e.g., {{onym|he|...}} invokes {{Hebr}}). But even for Latin-script entries, we want the lang=fr in our generated HTML. (Plus what msh210 says.) —RuakhTALK18:56, 18 December 2011 (UTC)
Good point about script templates. I use {{Hebr|]}} myself, but I suppose {{l}} is easier to use (if more burdensome on the servers).—msh210℠ (talk) 19:41, 18 December 2011 (UTC)
I support the use of language-targeted linking to generate all links in lists to English entries if Tabbed Languages is disabled by default for all users.
I support the use of language-targeted linking to generate all links in lists to non-English entries if Tabbed Languages is disabled by default for all users.
Support. I especially support it for non–Latin-script entries, because then we want the appropriate script template to be used (e.g., {{onym|he|...}} invokes {{Hebr}}). But even for Latin-script script entries, we want the lang=fr in our generated HTML. (Plus what msh210 says.) —RuakhTALK18:56, 18 December 2011 (UTC)
I don't think there is really a need to differentiate between whether tabbed languages is enabled or disabled. In both cases, there will always be some users wanting to use tabbed languages, and we should be able to accommodate them too. —CodeCat19:38, 13 December 2011 (UTC)
What is intended by the phrase "links in definitions to non-English entries"? Since "links that are generated by other templates (like {{term}})" are excluded, this can't mean form-ofs . . . can someone point to an example entry that has such a link? —RuakhTALK20:49, 13 December 2011 (UTC)
I just realised something else. If we make the use of {{l}} required so that all links always link to a specific language, then it should naturally be required for all templates that generate links to do this as well. This means that the language parameters of {{term}}, {{form of}}, {{plural of}} and such would be required as well, unless all these templates are made to default to English (a bot should be able to trace erroneous uses that lack a language parameter). Maybe for definitions, a new template {{d|term}} can be used instead of {{l|en|term}} for ease of use, since the assumption is that it always links to a definition in English? —CodeCat21:02, 13 December 2011 (UTC)
Is the intention to enable tabbed languages as an option for registered members, or the default for registered members, or admins, or the default for all? (I'm an admin, and I've turned off the tabs display.) —MichaelZ. 2011-12-13 21:56 z
Well, it's been an option for all registered users for a while. The intention (of some) is that it be the default henceforth, and for everyone.—msh210℠ (talk) 23:15, 13 December 2011 (UTC)
Thank you for giving your opinion. I suggest you try showing the tabbed interface to someone who is not a Wiktionary regular, and asking them whether it is simpler/easier to use than the normal "stacked" display. --Yair rand05:10, 14 December 2011 (UTC)
That is a great idea. —MichaelZ. 2011-12-15 16:17 z
Don't forget a point: readibility of internal pages is already bad, because of the heavy use of templates. Contributors coming from Wikipedia are expected to know the normal link syntax, not this l template. Why making things more complex unnecessarily? The current complexity is discouraging for new editors. Lmaltier20:05, 16 December 2011 (UTC)
I agree with Lmaltier here. Using normal ] syntax should not break anything. This tabbed languages proposal (as I understand it) would mean that plain ] links would only show the English term, and this sounds a lot like breaking the current functionality.
That said, I also support the idea of more advanced editors using {{l}} or ] to link to entries in specific languages. As Krun and others have pointed out above, the use of plain ] links can impede usability when the destination page is quite long. -- Eiríkr Útlendi │ Tala við mig20:22, 16 December 2011 (UTC)
I think the default of automatically going to English if it exists is kind of annoying. It often 'surprises' me and catches me off guard when I expect to be taken straight to the language I was working in. —CodeCat23:32, 18 December 2011 (UTC)
Feedback from user-noneditors
I was prompted by Yair rand's call for user-noneditor feedback on the new tabbed-languages interface (see his post hereinbefore, timestamped: 05:10, 14 December 2011) to gather such feedback from my friends and coresidents. I surveyed eight people, asking each of them to look at ], first as an anonymous user and then logged in on my account, and then to tell me which presentation they preferred and why. That is a tiny and probably unrepresentative sample, so obviously I don't expect my findings to be authoritative, but perhaps they typify the perspectives of users who aren't affected by the often conflicting priorities of editors. So, without further ado…
All eight surveyed preferred the tabbed-languages interface to the stacked interface. Strength of preference was directly correlated with enthusiasm, with frequent Wiktionary users strongly preferring the change, whilst those who cared little expressed but a slight preference.
The tabbed-languages interface was felt to improve presentation by making it far easier to find the information for which one is looking, offering a clearer separation between languages, getting rid of enormous (and usually unwanted) tables of contents, combating "information overload", reducing the need for scrolling, generally looking "cleaner", and in many cases allowing whole entries to fit on a single computer screen (thereby eliminating scrolling).
Perceived drawbacks to the change in interface included its sacrifice of horizontal screen space, its obfuscation of the comparison of homographic cognates, and its hindrance of serendipitous term-searches. (This third drawback is of especial significance to our Random entry tool on the occasion that it brings up an entry with multiple language sections (which isn't that often, but is a pretty big deal for entries for CJKV characters); however, the random entry tool is, IMO ATM, virtually useless.)
Three of those asked suggested moving the language tabs from the side of the page to its top in order to free up horizontal space, although reflective discussion amongst them concluded that that solution was also problematic (especially in the case of an entry with very many language sections); either way, the "double toolbar" presentation was deemed odd, though perhaps unavoidable.
One person complained that the dark-grey–on–light-grey presentation of the names of unselected languages offered too little text/background contrast, at times making the names difficult to make out. She suggested that all the language names be written black, with emboldenment being the only distinction in the presentation of the text of the selected language and the unselected languages.
Finally, one other person gave a fairly detailed description of the kind of interface she would prefer. In it, the language tabs would occupy more or less the same position that they currently do in the tabbed-languages interface. Differently, however, the language tabs would be the size, colour, and general presentation of the section names shown in the stacked interface's tables of contents; only the selected language's (or, potentially, languages') subsections would be shown — otherwise, they would be hidden, with only the language names displayed. To mitigate the loss of horizontal space, long language names (such as (deprecated template usage)Old High German) could be allowed to flow onto two lines in the list of tabs / table of contents.
That's the feedback I got, for what it's worth. I hope it's of some use to this discussion. — Raifʻhār Doremítzwr ~ (U · T · C) ~ 04:38, 21 December 2011 (UTC)
Three of those asked suggested moving the language tabs from the side of the page to its top in order to free up horizontal space, although reflective discussion amongst them concluded that that solution was also problematic. I am not sure if you are familar with the Windows user interface, but it has an interesting solution to the problem: if there are more tabs than can fit in a row, the tabs are evenly distributed across multiple rows. This would be an excellent solution to the problem and shouldn't be too hard to implement. -- Liliana•13:03, 21 December 2011 (UTC)
It can be difficult because scripts may have no easy way to find out how wide each tab is supposed to be, because it depends on the font. —CodeCat15:19, 21 December 2011 (UTC)
I don't know a lot, but can't you just make the tabs simple text with a border around them, so they can naturally wrap to the next line? That should be the easiest way. -- Liliana•15:35, 21 December 2011 (UTC)
The main enduring problem with moving the tabs to the top that they realised was that, the more language tabs there are, the harder it becomes to single out one's intended language quickly; presumably, multiple rows will only exacerbate the problem. Instituting variable language-tab widths is also problematic, since it would give languages with long names (such as Isthmus-Mecayapan Nahuatl and Wangaaybuwan-Ngiyambaa) far greater visual prominence than languages with short names (such as Ido and Lao). — Raifʻhār Doremítzwr ~ (U · T · C) ~ 14:41, 22 December 2011 (UTC)
I'd like to reiterate the criticism of how unselected language tabs are shown -- grey on grey is not very good visibility. Bold black text on a white background for the active tab sounds good, as does unbolded black text on a light grey background for unselected tabs. -- Eiríkr Útlendi │ Tala við mig16:56, 21 December 2011 (UTC)
I've changed the styles a bit so that the text color of the unselected tabs are a bit darker and the backgrounds are a bit lighter. (I made the borders a bit lighter, too.) --Yair rand22:09, 21 December 2011 (UTC)
Also, I'd like to point out that at some point the WMF is probably going to roll out the Athena skin here, which does away with the sidebar altogether. That's probably still a long way away, though, so I'm not sure it makes sense to start planning for that now... Either way, we're usually much more pressed for vertical space than horizontal space. --Yair rand22:18, 21 December 2011 (UTC)
Thanks, Yair. Would it be possible to make the text for unselected tabs even darker? It's dependent on viewing angle on my monitor, but the current text and background colors are still rather close together. -- Eiríkr Útlendi │ Tala við mig22:41, 21 December 2011 (UTC)
I've darkened the color a little bit more, from this to this, but there's only so far it can go without losing the "inactive" effect. --Yair rand22:28, 26 December 2011 (UTC)
The mention of multiple tabs reminded me of an entertaining old UI article on Tabbed Dialogs. —MichaelZ. 2012-01-04 05:32 z
Tabbed languages for the horizontally challenged
If discussion on the new language tabs is happening elsewhere - please say where. As I become used to this layout I like it! Could consideration be given to making the language names on the tabs smaller (esp those not at the focus). This would allow more space for the meat. But well done for those behind the change. —Saltmarshtalk-συζήτηση10:24, 14 December 2011 (UTC)
I rather like this layout too, although it is most unfortunate that so much horizontal space is wasted. But there is already a Beer Parlour section where it is being discussed here. – Krun10:50, 14 December 2011 (UTC)
Romanian vocative case?
I've noticed that the standard templates for declining Romanian nouns produces a table that includes nominative/accusative and genitive/dative, but omits the vocative case, which is present in Romanian. I understand the reasons for this may be that it is not used as often in proper or formal speech, as its use has a "directness" about it in addressing people that comes across as rude or unrefined if the speaker is not intimately acquainted with the person they're addressing. Nonetheless, it is still a legitimate part of the language's grammar, a remnant from Latin, and I was wondering if this should be incorporated, if just for completeness, academic curiosity or for use in more informal situations, as it will still be heard fairly often in conversations. (For example "om"- "omule!", "băiat"- "băiete!", "văr"- "vere!", "soră"- "soro!" and even proper nouns or names like "Ion"- "Ioane!") Maybe there should be some usage note to describe its use? Or should it just not be included at all?
Word dewd54319:04, 14 December 2011 (UTC)
It should definitely be included! As for it being a remnant of Latin, some of the forms you describe (particularly the feminine -o) seem rather to be the result of Slavic inluence. Probably it's both, i.e. Slavic influence strengthened an existing phenomenon and added to it. Regardless, this should be included; we must be as complete as possible. – Krun15:01, 15 December 2011 (UTC)
I agree. Of course I meant it was probably a higly modified remainder of that, with some forms clearly under heavy Slavic influence. But anyway, as I'm not acquainted with programming that into the templates, does anyone know how to do this? Also, since not every word has a vocative case that can be used, should it be an optional feature than can be added? Word dewd54402:02, 16 December 2011 (UTC)
They exist only in the special Appendix: namespace. You could compare it to a printed dictionary, which would not have reconstructed words in the main body, but might have an appendix on the last 20 pages or so describing the reconstructions. -- Liliana•15:23, 15 December 2011 (UTC)
There is something that occurred to me lately. Everywhere on Wiktionary we provide links to inflected forms, such as linking to goes in the headword line of go, linking to gaat in the conjugation table of gaan and so on. But is there really a point in that? Those pages are usually just form-of pages with no information except 'this is a certain inflected form of (headword)', and that's something the user would already know if they linked there from the headword's page. So I wonder why we link to those pages? Wouldn't it make more sense to just list them as plain words? —CodeCat16:26, 17 December 2011 (UTC)
I sometimes find it very useful. It tells me at a glance what the form is, such as 3rd-person singular present indicative. Saves me from having to pore over a big table to pick out my form. —Stephen(Talk)16:37, 17 December 2011 (UTC)
In addition to pronunciation, inflected forms may also have (1) illustrative quotations specific to that form, (2) form-specific senses, much like plural-only nouns (this varies by language and part of speech). In any case, listing the forms without a link would make the user have to type in the entry name to get to the form page to find what's there, and I can't see that this would be an improvement over providing a link in the text. --EncycloPetey19:37, 17 December 2011 (UTC)
I think, though, form-specific senses should be listed at the lemma form, anyway, or at least separately mentioned there with a separate link to the specific form (Say "(plural-only senses)Seewords."). Otherwise how is a user to guess that the sense even exists? —RuakhTALK15:30, 18 December 2011 (UTC)
The links to the inflected forms from the lemmas are useful to contributors for determining whether the inflected form have been entered in the appropriate language.
I don't think that users come to inflected form pages very often from inflection tables. Rather they come from casually typing in the form that is on their mind, possibly directly from a passage they have just read.
If you are asking about why we link to the inflected form rather than the lemma under most circumstances, I think the inflected-form links are often the result of laziness or lack of knowledge about pipes, especially by casual contributors. OTOH, I can think of instances where the inflected form may be desirable. For example, in etymologies an inflected form is sometimes useful because it shows a spelling that is closer to that shown by a successor in the derivation chain than the lemma does. But even there the stem could be shown and the link still be to the lemma.
As more experienced users (us) have ways such as popups of getting to underlying entries rather than inflected forms, it is tempting to ignore the fact that most users are usually more interested in definitions (therefore the lemma) than in inflected forms. (If there is evidence to the contrary on the prevailing interests of users, I would like to see it.) I think veteran users should think carefully about whether a given link is better to the lemma or an inflected form. Furthermore for links to English sections care should be taken to link to the best section (Etymology n or PoS). DCDuringTALK15:19, 18 December 2011 (UTC)
More specific linking works for stable entries. However, it does entail one rub that I've run into in the past -- as entries are edited, subsections within a single language are much more likely to change than the language headings themselves. I can be reasonably certain that a given term in a language will remain under that language, and thus linking like ] will most likely be a successful and stable long-term solution. However, I am much less certain that any given etymology (or sometimes even POS, such as the not-so-distant discussion about adjectives vs. adjectival nouns in Japanese) will remain where it is, so pointing a user specifically to the internals of a language's entry from some other page is much less tenable, and presents a much uglier maintenance issue -- if that entry is edited and the etymology and/or POS are altered or reordered, I have no automatic way of telling that I need to change a link on some other page, and that link may now either point to the wrong etyl/POS or point to just the term.
Some other similar systems assign unique identifiers to subsections that remain stable even if the page is reordered, so long as that specific subsection is not deleted. I don't think MediaWiki allows for this, unless editors add such uniquely identifying link targets to each page manually. -- Eiríkr Útlendi │ Tala við mig17:22, 19 December 2011 (UTC)
We should not list directly to a POS section...ever. As Eirikr has pointed out, POS headers do change, so the links can change. Further, there is no guarantee that a single language will continue to have a set number of POS headers; there is the possibility that one etymology for one noun will because two etymologies for two nouns, are that the reverse will happen and two sections will be merged. Even if the etymology remains stable, a new sense for a noun might pop up where one did not exist before, creating a problem with linking the POS. So, pointing to a language section is the only stable way to point (and even that can have issues, as with the whole BSC deabte). --EncycloPetey17:45, 19 December 2011 (UTC)
Open Call for 2012 Wikimedia Fellowship Applicants
I apologize that you are receiving this message in English. Please
help translate it.
Do you want to help attract new contributors to Wikimedia projects?
Do you want to improve retention of our existing editors?
Do you want to strengthen our community by diversifying its base and increasing the overall number of excellent participants around the world?
The Wikimedia Foundation is seeking Community Fellows and project ideas for the Community Fellowship Program. A Fellowship is a temporary position at the Wikimedia Foundation in order to work on a specific project or set of projects. Submissions for 2012 are encouraged to focus on the theme of improving editor retention and increasing participation in Wikimedia projects. If interested, please submit a project idea or apply to be a fellow by January 15, 2012. Please visit https://meta.wikimedia.orghttps://dictious.com/en/Wikimedia_Fellowships for more information.
Polish Wiktionary has headers in a language of your preference!
The Polish Wiktionary has developed an interesting feature. All of the headings appear in your preferred language. If you don’t know Polish very well, you can see all the headers in your usual language. See, for example, pl:społeczeństwo. It looks like each header calls a template, such as temp:etymologia. —Stephen(Talk)16:19, 21 December 2011 (UTC)
That is pretty amazing, but it would require us to translate all the headers. Do we have the staff to do that? -- Liliana•16:31, 21 December 2011 (UTC)
I don't quite see the point. I mean, sure, I've looked at Wiktionaries in languages I don't know once in a while, but very seldom. I imagine that people who don't edit a Wiktionary look at unfamiliar languages' Wiktionaries even less often than I. They're really meant for people who know the language. I don't think we ought to offer our headings in languages other than English.—msh210℠ (talk) 19:39, 21 December 2011 (UTC)
I do look at other language wiktionaries and I think the feature is worth considering, it's great, actually. If mean that Wiktionary should serve people from any background. Don't know if it envolves a lot of work, though. --Anatoli(обсудить)22:51, 21 December 2011 (UTC)
I think it looks like a lot of work for very little benefit. When I look at pl:społeczeństwo and see headers in English, I still don't see anything particularly useful to me as someone who reads no Polish. I recognize the pronunciation because I know IPA when I see it - having the header in English doesn't help me there. Seeing "definitions" and "examples" in English doesn't help because I can't read them anyway. I don't need the English headers to recognize the inflections and translations - I'd know that's what they were even if the headers were still in Polish. In short, seeing the headers in English doesn't let me as a non-Polish speakers know anything more about the word społeczeństwo than seeing the headers in Polish would have. —Angr23:12, 21 December 2011 (UTC)
It's easy to comment lightly on this if you stay in your comfort zone and use the English Wiktionary alone - your native language. When I look up words in Vietnamese or Thai Wiktionary I have trouble identifying parts of speech as I don't know all their names. If I look at Vietnamese vi:bó or Hindi hi:हिन्दी, I want, at the very least to know whether it is a verb or a noun before I try to understand examples or grammar. It may be too much initial work, I have no idea but the benefits are there. --Anatoli(обсудить)02:30, 22 December 2011 (UTC)
I don’t think it entails any translation work. I think it uses little MediaWiki files such as MediaWiki:Delete that are found on each Wikipedia and Wiktionary, so that the translations are actually provided by the Wiktionary of that particular language. That is, the English headers you see in the Polish Wiktionary are generated by us here in the English Wiktionary. —Stephen(Talk)05:02, 22 December 2011 (UTC)
I thought the problem with doing that is that it breaks page caching (not sure). Anyone know anything about that? --Yair rand06:33, 22 December 2011 (UTC)
I've gone through and internationalized all the Vietnamese Wiktionary's headers (other than the language headers, which are more complicated there) and various common inline templates into English and Spanish. I'll add more languages if time permits. Unlike the Polish Wiktionary's implementation, we're using the MediaWiki: namespace. Compare bó (vi) to "bó" (en) and 人 (vi) to "人" (es). – Minh Nguyễn (talk, contribs) 12:28, 2 January 2012 (UTC)
Removing the naming distinction between different types of categories
I just came across Category:en:Onomatopoeia and I wondered why it wasn't an etymology category. But then I realised that it's not only an etymology category, because words that were coined as onomatopoeia might still be. And so now I wonder why we really distinguish different types of category so rigidly. We've had many votes and moves simply to move categories from one naming scheme to the other. And honestly I think it's getting a little silly. On the Dutch Wiktionary there is no distinction: there is nl:Categorie:Werkwoord in het Engels ("Verb in English") for English verbs and nl:Categorie:Natuurkunde in het Engels ("Physics in English") for physics-related terms. So I'd like to propose that we just use one single naming scheme for all language-specific categories, no matter what they are supposed to contain. —CodeCat23:12, 21 December 2011 (UTC)
I'm aware of that, but that's really just a technicality. If we can first find a consensus on whether we need to change this, then we can maybe worry about how. —CodeCat23:21, 21 December 2011 (UTC)
Part of the problem is that it's not really clear what a category is supposed to contain, either a priori (figure out what categories we want and why, figure out what they should contain in order to serve that purpose) or from the names (see what a category's name is, figure out what it should contain). Is Category:Verbs in English for English verbs (have), or English words relating to verbs (verbification), or both? Is Category:Physics in English for words used in physics (center of mass), or words used about physics (astrophysics), or both? I think we should start from the a priori side: what classes of pages is it useful to have categories for? (N.B.: when I say that it's "not really clear" I mean both that it's not clear to me, and that it doesn't seem to be clear to the community as a whole; there may be some people with specific opinions and clear ideas in their heads, but I don't think there's anything resembling clear consensus.) —RuakhTALK00:07, 22 December 2011 (UTC)
If all the category names were of the same type, we could settle possible problems about their content (or existence) separately. Now all such attempts lead into Kafkaesque arguments. I don't think the names of categories can ever accurately describe what's in them. I'd vote for short, simple names for all (en:Type for everything is my favorite). The content can be described on top of the category: "This category contains English verbs", etc. Newcomers are not likely to know at once what a category is, let alone bother about the difference between topics and parts of speech. When I came here, I didn't know or care about the difference between a category, appendix, or glossary. Dividing categories into two types with different names just makes it more complicated. --Makaokalani17:02, 22 December 2011 (UTC)
But really, the current situation is clearly unsatisfactory. We link some languages and unlink others by totally arbitrary and subjective criteria, and as seen on Wiktionary talk:Translations/Wikification, this causes repeated debates and fierce fights about whether to link one language or not. That can't happen in a serious dictionary like we are.
Really, we should decide on either linking all languages, or unlinking all. Any of these are better than the current situation. Of course, both options have arguments for and against:
Unlinking all languages
Arguments in favor:
Anyone who wants to know about a particular language can always look it up in the search bar
It makes template matters greatly easier, thereby reducing server load
It reduces the potential for confusion, as a new reader may not know where to click if both the language name and the translation are bluelinked
Arguments against:
The argument above could also be used to unlink all words in definitions, and we're obviously not going to do that
At least in monobook and vector the search bar is a bit out of the way
Linking all languages
Arguments in favor:
Linking language names makes it easier to look them up, as it requires just a click
Even language terms like German may be useful to the casual reader
Arguments against:
It is still not entirely consistent, as language names cannot link to themselves (for example, the French translation of French)
If not all entries on language names exist, it creates a rather "colorful" mix, ex. on water.
The bluelinks can be confusing if the language sense doesn't exist in the respective entry
I prefer not linking the names, but if we do, it may be better to link to Wikipedia instead. If someone sees a name in a translation table, they will already know that it's a language, so our simple definitions won't help them much. Most likely they will be looking for more encyclopedic information, such as where the language is spoken and what family it belongs to. — This unsigned comment was added by CodeCat (talk • contribs) at 14:24, 26 December 2011 (UTC).
Whilst I generally oppose language-name–linking, arguments 1 and 2 against it could be rendered void by (1) using {{l}} for all language-name links, and (2) creating the entries for the language names in question. — Raifʻhār Doremítzwr ~ (U · T · C) ~ 16:40, 26 December 2011 (UTC)
A little background, {{en}} contains only English (aside from stuff wrapped up in noinclude) while {{ca}} contains {{{l|]}}}. Effect: {{ca}} displays Catalan, while to remove the wikilink, one uses {{ca|l=}}. On the deletion debate WT:RFDO#Template:language, it has been called into question whether this additional feature adds enough value for it to be kept. The only real use it automatic linking whilst subst:ing, which is mainly used in translation tables. In the past I've personally used it for descendants as well. I believe (and I'd like confirmation from someone more advanced than me) that removing the wikilinks all together should improve server performance (pages will load faster, things like that). Mglovesfun (talk) 10:40, 31 December 2011 (UTC)
I don't want all languages unlinked, just remove the links from the templates themselves. I'm not proposing that a bot change every instance of ] to Catalan. Mglovesfun (talk) 13:32, 2 January 2012 (UTC)
I would suggest that the language names link to the category for that language, instead of the entry for the language name in English. I think that would be more relevant in these cases. In principle I would favour unlinking all languages, but in cases like water (good example!), where I haven't even heard about most of the languages, it is very nice to have a link to something that can tell me more about that language (and categories, as far as I can see, tend to have many relevant links to further reading about that language). Jon Harald Søby23:42, 6 January 2012 (UTC)
Support. (I would also be O.K. with linking all languages, but I think that linking none is preferable. But the linking-only-uncommon-languages approach has had bizarre consequences that simply are not tenable.) —RuakhTALK00:56, 7 January 2012 (UTC)
I weakly support, because of the server-load issue and the low utility of such links (i.e. who looks up a language name in a dictionary if he knows it's a language name? In an encyclopedia, maybe, but that's not what we currently link to).—msh210℠ (talk) 23:58, 8 January 2012 (UTC)
I want all language templates to be linked
I want everything to stay as it is
Support Additionally, there are a number of languages with similar names that are regularly confused, such as Scots and Scots Gaelic. --EncycloPetey00:08, 9 January 2012 (UTC)
I have another opinion not accounted for here
I don’t care
Support, though I guess this more or less constitutes an abstention. — Raifʻhār Doremítzwr ~ (U · T · C) ~ 20:12, 6 January 2012 (UTC)
I think it would be more convenient, for anyone trying to make sense of this straw poll, if you were to summarize your own position. (Unless you're actually in the "I don't care" camp. I had to make a guess, when I split "I don't care / I have another opinion not accounted for here" into separate sections.) —RuakhTALK00:56, 7 January 2012 (UTC)
Nope, "I don’t care" is more appropriate, I think. :-) — Raifʻhār Doremítzwr ~ (U · T · C) ~ 01:22, 7 January 2012 (UTC)
Requests for verification AKA RFV, its template text
The text of the template {{rfv}} is IMHO incorrect, in disalign with common practice at RFV. It reads as follows:
"If the information here cannot be verified or does not meet our inclusion criteria then it will be deleted. ..."
But RFV is not for verification of any information (such as pronunciation and etymology) and any failure to meet inclusion criteria (such as sum-of-partness aka compositionality).
This goes back to 2006, when the template text read as follows:
"It has been suggested that this entry does not meet Wiktionary's criteria for inclusion. ..."
I propose something like this:
"If this entry cannot be attested, by showing that it meets attestation criteria, it will be deleted."
The proposal refers to entry rather than to an entry or a sense, as it pertains to {{rfv}} rather than {{rfv-sense}}.
MG has edited the template so that it reads "If the definition or definitions here cannot be verified or does not meet our inclusion criteria then it will be deleted." This is still wrong, as not any inclusion criteria are concerned. I still propose what I have proposed above, using "this term" instead of "this entry":
"If this term cannot be attested, by showing that it meets attestation criteria, it will be deleted."
Oppose -- Liliana • 03:01, 5 December 2011 (UTC)
Support —CodeCat 11:54, 16 December 2011 (UTC)
More specific linking works for stable entries. However, it does entail one rub that I've run into in the past -- as entries are edited, subsections within a single language are much more likely to change than the language headings themselves. I can be reasonably certain that a given term in a language will remain under that language, and thus linking like ] will most likely be a successful and stable long-term solution. However, I am much less certain that any given etymology (or sometimes even POS, such as the not-so-distant discussion about adjectives vs. adjectival nouns in Japanese) will remain where it is, so pointing a user specifically to the internals of a language's entry from some other page is much less tenable, and presents a much uglier maintenance issue -- if that entry is edited and the etymology and/or POS are altered or reordered, I have no automatic way of telling that I need to change a link on some other page, and that link may now either point to the wrong etyl/POS or point to just the term.
