Hello, you have come here looking for the meaning of the word Wiktionary:Beer parlour/2011/April. In DICTIOUS you will not only get to know all the dictionary meanings for the word Wiktionary:Beer parlour/2011/April, but we will also tell you about its etymology, its characteristics and you will know how to say Wiktionary:Beer parlour/2011/April in singular and plural. Everything you need to know about the word Wiktionary:Beer parlour/2011/April you have here. The definition of the word Wiktionary:Beer parlour/2011/April will help you to be more precise and correct when speaking or writing your texts. Knowing the definition ofWiktionary:Beer parlour/2011/April, 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.
It's a little hard to spot "Category:Mechanics" and "Category:Energy" within the list of members of Category:Physics due to the new order that involves sorting everything under uppercase letters. I suggest reverting to the old order, if possible. --Daniel.07:49, 1 April 2011 (UTC)
An easier idea: use a sortkey for the language subcategories that makes them sort somewhere else, preferably near the end. -- Prince Kassad07:58, 1 April 2011 (UTC)
I think our ideas are virtually identical. I never meant to literally revert the change by undoing the whole update to MediaWiki 1.17 that apparently caused it, or something like this. --Daniel.08:09, 1 April 2011 (UTC)
Or: Move all English topic categories to begin with en:, so we don't have to deal with English topic cats having other language subcategories at all. --Yair rand08:11, 1 April 2011 (UTC)
Hm? If we didn't have other language categories inside the English categories, the lower-down topic categories wouldn't have anything to get lost in. We might still have the non-prefixed categories, but they wouldn't really be used. --Yair rand08:31, 1 April 2011 (UTC)
In this case, non-prefixed categories would be used to link between categories of various languages. (Say, if someone wants to go from Category:ja:Biology to Category:ru:Biology.) This use would be in conflict with the "Other languages" box, of course, but I'd like to be one step ahead and think that the box could be automatically populated by the non-prefixed category for better coverage, forming a nice symbiosis. --Daniel.08:45, 1 April 2011 (UTC)
But then, we'd have other language categories inside the top-level topical categories. It doesn't fix the problem at all, it just moves it to another location. -- Prince Kassad08:39, 1 April 2011 (UTC)
The problem I mentioned in the first message is the confusing mixture of language versions of one category (Category:pt:Physics, Category:es:Physics) and English subcategories (Category:Mechanics, Category:Energy). It could be entirely solved by either Kassad's idea or Yair's. --Daniel.08:45, 1 April 2011 (UTC)
One solution that came to mind some time ago is to remove non-English categories from Category:Physics, leaving them nonetheless accessible from the collapsible table at the top entitled "Other languages", as they already are. Thus, de:Category:Physics would no longer be a subcategory of Category:Physics. This could be executed by a single edit to a template, {{topic cat}} I think. --Dan Polansky09:01, 1 April 2011 (UTC)
But the table is incomplete. It will never be complete either, as it's infeasible to add 7,000+ languages there. -- Prince Kassad09:05, 1 April 2011 (UTC)
The table can be made complete by editing {{nav table}}. Why is it infeasible to add more than 7,000 languages to the table? Consider that, theoretically, the same number of languages is meant to be added to translation sections in great many English entries. --Dan Polansky09:35, 1 April 2011 (UTC)
Well, the table would take a sizable amount of time to expand, and about twenty seconds to scroll through, so it could be a bit of an inconvenience. It might add a bit to the loading time, too, but it is a possibility we should consider. The translations sections of English entries aren't all that large a problem since it can be helped by targeted translations. --Yair rand09:58, 1 April 2011 (UTC)
When an entry has many translations, they are already relatively difficult to be navigated. However, with the advent of targeted languages, it's now thankfully easier to spot the right ones. In addition, simply the fact that the many translations are useful information that was proudly added by our contributors is a good enough reason to make people wait for the time to load long pages, at least until the next big idea (Separate translation pages with parts accessible with JavaScript, anyone?) to handle lots of translations.
The great majority of foreign-language versions of topical categories that could exist don't exist, so you (Dan) apparently are literally asking for each instance of the {{nav table}} to contain thousands of black redlinks whose only purpose (apart from teaching what are the languages that exist, or merely the majority that we accept as categories) is reassuring that, yes, most topical categories weren't created yet. We only have little more than 850 language categories, though the current nav table of approximately 270 languages (if I could count right) is already infeasible enough, and would be much, much worse if expanded to 850 or 7000 categories. --Daniel.10:25, 1 April 2011 (UTC)
I support adding en: to English topical categories, and placing them in a parent category for all languages, so that the topical categories of other languages no longer appear in the categories for English. —CodeCat09:55, 1 April 2011 (UTC)
I too support this. We voted on it in 2009 (or early 2010) and it was a no consensus with something like 65% support rate. --Mglovesfun (talk) 19:11, 1 April 2011 (UTC)
Ditto. 65% sounds like a high support rate; isn't the requisite threshold really close to that? Something like ⅔ (~66.7%) or ⁷⁄₁₀ (70%)? — Raifʻhār Doremítzwr ~ (U · T · C) ~ 20:39, 1 April 2011 (UTC)
I agree: 65% sounds like a high support rate. However, for comparison, this vote failed with ~68% of support. On the other hand, if another vote on the proposal of adding "en:" to English topical categories were created, well... Notably, most of the opposers of Wiktionary:Votes/pl-2009-08/Add en: to English topical categories (12 "Support", 7 "Oppose", 1 "Abstain") have been absent from Wiktionary, or have been making few contributions lately, so their probability of voting again is obscure. They include EncycloPetey, Carolina wren, Razorflame and Robert Ulmann. --Daniel.07:34, 3 April 2011 (UTC)
Restructuration of foreign languages
We are always striving to make Wiktionary easy to use for anyone. Of course, I do realize we're currently quite far away from that goal, which is why I, and you too, strive to make suggestions that make Wiktionary easier to use.
Now, foreign languages have an unique problem. Since words occuring in multiple languages are lumped in one entry, finding the language you want can be difficult especially for newcomers. Take, for example, the entry der: a Swedish speaker, or perhaps learner, wants to find out what "der" means. For that, he first has to scroll past the table of contents, then he will arrive at the Danish, Dutch, etc. entries, which is absolutely not what he is interested in. To find his language, Swedish, the reader would have to scroll all the way to the bottom, but most people have already closed the browser window at this point. (Using the ToC does not make it better, as that will make the screen end up somewhere between Latin and Limburgish.)
My suggestion is revolutionary, requires major changes, but ultimately makes Wiktionary easier to use: I propose to split up entries by language, using prefixes for the target language. So you'd have Danish:der, Dutch:der, Latin:der, etc. Now, let me tell you why this is a brilliant idea:
Finding your favorite entry will be much easier, as long as you specify language and word, you'll always end up at the information you want, and not at a page with several languages you're not actually interested in.
The prefix system makes adapting the search function pathetically easy. It just has to look for words starting in the language name.
This system allows us to make "language portals" of some sort, akin to the French Wiktionary portals. These could have useful grammar information, helpful entries, and other informational material to readers, maybe even tips on how to contribute.
Large pages, like a, would benefit a lot from this. This also helps 56k readers (of which there are still many in the world, mind you).
Of course, this would first require a lot of work to split up the old entries. But the end result is totally worth it and will help us to become a more popular resource on the Internet and possibly even in print.
I think the problems with the current system could be fixed by tabbed languages. How exactly do you suggest that the search system work in your proposal? And would each of these be separate namespaces? --Yair rand10:04, 1 April 2011 (UTC)
I don't see how the "French portal" could be better than the simultaneous existence of WT:AFR and a good set of appendices; and I don't see why the French portal would necessarily benefit from the proposal as a whole.
In addition... If your hypothetical Swedish speaker can't take the time to notice that a Swedish section of der is available below the Danish, Dutch, etc. sections of that entry, he most certainly won't take the time to find out the difference between the individual pages Danish:der, Dutch:der and Swedish:der. --Daniel.10:42, 1 April 2011 (UTC)
How is typing : more convenient than typing #? Bear in mind that the vast majority of pages, I would wager, have only one language section, yet every page would require the language prefix. Also, this change would make it much more difficult to compare the same word when it is shared by multiple languages (e.g., (deprecated template usage)lapsus linguae). I oppose this "revolutionary" suggestion that "requires major changes" when the benefits seem so small when compared with the burdens. — Raifʻhār Doremítzwr ~ (U · T · C) ~ 12:18, 1 April 2011 (UTC)
Oppose, I think that this is a very bold change with a high potential to break a lot of things. On the other hand the tabbed browsing approach seems harmless, can easily be switched off, and will essentially provide much the same improved readability effect. Matthias Buchmeier13:04, 1 April 2011 (UTC)
Tabbed browsing doesn't reduce the total size of the page though. It still all has to be downloaded, because the filtering is done in the browser. —CodeCat14:17, 1 April 2011 (UTC)
If you want to reduce the total size of the page the filtering out of non-desired languages doesn't help much. If you look at the page source, you will immediately recognize that the page-size is mainly bloated due to advanced html-formating/scripting features like CSS class-tag long mime-type lists for the audio files and so on. So in order to improve the speed on slow network-links the most effective solution is to provide some minimalistic rendering option switch' inside the Mediawiki-software, rather than splitting the pages into languages. Matthias Buchmeier15:04, 1 April 2011 (UTC)
Don't forget that providing information about all languages in the same page allows an easy comparison of senses between languages, detection of false friends and of small differences in uses, etc. This is a something very useful, and not found anywhere else. The main drawback is that some pages will become too large to be loadable (imagine a description for 5000 languages in the same page). This case will be exceptional, but solutions will have to be found. I think that, in these exceptional cases, a solution might subpages by language (or subset of languages). Lmaltier18:55, 1 April 2011 (UTC)
I can imagine a description for 5000 languages, but I don't think it will happen, given the limited number of languages in the world, our practice of not just copying dictionaries, and the distribution of spellings among languages. Simply listing letters--i.e. a is used as a letter in English, Afrikaans, Danish, German, etc.--instead of having an entry for each letter, would massively shrink some of our biggest pages.--Prosfilaes19:20, 1 April 2011 (UTC)
Yes, letters is the typical case. And each language must be studied separately: for pronunciation, but also for the gender (e.g. h was used to be feminine in French, but is now masculine), for derived terms (from A to Z), etc. Lmaltier20:52, 1 April 2011 (UTC)
Subpages for entries?
Hi all. I had a similar idea a few days ago, and posted it to the Grease pit. Yair rand pointed me to this thread, so I'm moving it here to add to the discussion. Please comment :) --Waldir00:22, 10 May 2011 (UTC)
Has it ever been discussed to use subpages to separate entries? It would make linking much easier: for example, right now if I want to link to the Dutch noun "do", I'd have to visit the page and copy the link do#Noun 5 (which is unguessable, and worse, prone to change). What if instead we could link to do/nl#Noun or do/Dutch#Noun? This would have the following benefits:
Links could be guessed without visiting the page
The probability of a link becoming obsolete/pointing to an incorrect entry would be greatly reduced (not to zero, though, since for instance there are two English noun meanings for "do")
The subpages would then be transcluded to the main page, which is easily done/maintained with a bot.
Of course, the obvious problem is that such a major change would imply replacing all links not only here but on other projects too. It might look like we'd need to do the other projects automatically by, say, linking to the entry on the project's language (if it exists). But actually, since all subpages would be transcluded in the main page, the users would still reach the correct page; only the section links would be (potentially) broken. And even these wouldn't, for entries with meanings in a single language (which are the majority, I suppose?). So the update could be done progressively without major disruption.
Another minor problem would be the titles that contain slashes. They're not many (an early listing can be found here), so I believe a proposal currently being discussed on on Wikipedia could be used to workaround that.
Oh, thanks. I tried searching for "subpages" and didn't find much. Seems like this idea is that unusual after all. I do believe that this method could work better than that proposal, since the idea is to keep all entries in the main entry page, as they are right now; the only difference is that this would be done through transclusion instead. And this could work together with the tabbed languages script, to address the long pages issue (in usability, not download speed). On the other hand, it would allow linking to short pages. Besides this, the three advantages I listed above would sill stand.
Currently, if an English word was inherited from Indo-European, we add the entry to the derivation categories of Middle English, Old English, Proto-Germanic and Proto-Indo-European. This creates a lot of redundant categories, even though nothing 'special' really happened throughout the word's history. It was simply retained over thousands of years of evolution into the modern language. So I would like to propose that we only add entries to the most recent categories, and those of languages from which it originates through a means other than natural evolution. So the word kettle for example would be added to Middle English derivations, but not Old English or Proto-Germanic (because this is the natural evolution of the word) but it would be added to Latin derivations because the word was borrowed from Latin into Germanic. A completely 'native' word like foot would only be in Middle English derivations. The entire chain of etymology would be shown in the entry as usual, but only the most recent ancestor would actually be categorised. —CodeCat15:52, 1 April 2011 (UTC)
I immediately see a drawback: some modern English words were present in Middle English and in Old English before that, others were present in Middle English — but are of unclear etymology before that. If I today want a list (or category) of English words derived from Old English, I look at Category:Old English derivations. If your proposal were instituted, I could look at Category:Middle English derivations, but this category would be adulterated with words of unclear derivation (possibly not Old English) — and words derived from languages other than Old English. A modern English word might also clearly derive from an Old English word, but be entirely unattested in Middle English. What would happen in this case? Assume natural evolution and place the word into Category:Middle English derivations, although it is unattested in Middle English? Said briefly, I see several drawbacks. What are the benefits?
I find it also a bit arbitrary to place the words into the category of the most recent parent language as opposed to for example the oldest common ancestor (Old English for English, Old High German rather than Middle High German for German) or oldest known ancestor. Finally, recall the discussions that have happened over whether we should even have Middle English as separate from modern English. - -sche(discuss)03:12, 2 April 2011 (UTC)
Yeah, the problem is that not very many people seem to care about how many of our words were used in Middle English (though I'm sure some do), whereas the question of how much of our vocabulary is inherited from Old English is a very active one. The change from Middle to Modern English is gradual and relatively uneventful, whereas the change from Old to Middle English is drastic and marked by the imposition of a whole new stratum of borrowings, the loss of gender and case system etc. Hence, the fact that a modern word ‘came from’ Middle English is relatively trivial compared to the question of whether or not it survived the Norman invasion. Plus I agree with pretty much all of what -sche says above. Ƿidsiþ12:13, 2 April 2011 (UTC)
I see your point... do you think it might be more useful then to categorise only the oldest language in which it was created and from which it naturally evolved? So that foot would be categorised in Proto-Indo-European derivations but become in Proto-Germanic? Loanwords would then be categorised as derivations of both the languages they were borrowed from and into. —CodeCat12:36, 2 April 2011 (UTC)
Upcoming votes
I've created a few upcoming simultaneous votes based on discussions created by me in the last few months. The first one of these is scheduled to start in three days.
Very frequently I see Serbian or Croatian terms changed to Serbo-Croation and vice-versa. I never know if this is vandalism, well-meaning error or the correct thing to do. Normally, I neither revert the edits not mark them as patrolled. I have read the introduction to Wiktionary:About Serbo-Croatian but know nothing of these languages. Am I doing the right thing? (I don't want to start another war) SemperBlotto10:46, 3 April 2011 (UTC)
Horribly hard to say; the current consensus among editors of the English Wiktionary - I choose those words very carefully by the way - is that Serbo-Croatian is a single language and that Bosnian, Serbian and Croatian are really regional variations. I say "editors of the English Wiktionary" as I'm not convinced that this is the consensus among outsiders, such as people who live in the region and linguists.
Not unique to {{sh}}, could be applied to Catalan/Valencian, Urdu/Hindi, English/Scots and many more; too many mention without missing a lot more out. Mglovesfun (talk) 14:14, 3 April 2011 (UTC)
Wiktionary:Votes/pl-2009-06/Unified Serbo-Croatian asked whether only sh should be used as a language (to the exclusion of bs, sr, and hr), and ended in no consensus but a majority supporting. So there's IMO nothing wrong with converting a bs, sr, and/or hr entry to a sh one (assuming no information is lost during the conversion). Also IMO nothing wrong with doing the reverse. At some point we'll need to have a rule, I suppose, but right now AFAICT editors can do what they will. OTOH, the usual rule of "keep an entry the way it is if there's no specific reason to change it" would seem to apply.—msh210℠ (talk) 14:17, 3 April 2011 (UTC)
As there is no consensus for excluding such language sections, there is something wrong with removing sections for accepted languages: no Serbo-Croatian section should be removed, but no Croatian, Serbian, Bosnian section should be removed either. If you want to add a section, just add it, but other existing valid sections must be kept. Lmaltier17:44, 4 April 2011 (UTC)
Your suggestions would lead to needless editing anarchy and content redundancy, not to mention inevitable multifarious inconsistencies that would emerge from maintenance of such disorderly pile of what is more or less the same lexical data. We have enough problems cleaning up after those poor souls who took your advice on this matter in the past. Please don't encourage new "recruits" by such public display of support for futile cloning efforts. --Ivan Štambuk22:34, 4 April 2011 (UTC)
This is the only way to discourage edit wars. You encourage taking a position in a very polemic subject and you forget NPOV. A few days ago, we had a comment on fr.wikt stating that Serbo-Croatian entries should not be allowed, because it's not a language. I replied that we accept Serbo-Croatian sections as well as Serbian, Croatian, Bosnian sections, because Wikimedia also accept them in the list of wiktionaries. And this policy does work. Tolerance in the real world is a good thing. Lmaltier05:51, 5 April 2011 (UTC)
It's not about tolerance, Lmaltier (how about being tolerant to Serbo-Croatian speakers?). There is no phobia against Serbs, Croats, Bosnians or Montenegrins and there is no point in using Serbo-Croatian as an umbrellaa to cover all of these languages if the redundancies are not removed. The sh contributors have been removing the duplicates to make the maintenance easier. --Anatoli06:30, 5 April 2011 (UTC)
NPOV is a bad thing to bring up, as you have to have some view on the topic, or else completely ignore it. Saying that Bosnian, Croatian, Serbian and Serbo-Croatian should coexist is a point of view. Mglovesfun (talk) 07:28, 5 April 2011 (UTC)
My point of view is to allow Serbo-Croatian (while describing special cases and language specific usages) and disallow the split into separate BCS languages. We have language specific policies created and maintained by the actual contributors. Let them decide. In my observation, people who bring up the coexistence don't actually work on these languages or are rare visitors and don't know what's involved in maintaining this and how much lexical similarity there is. For example, creating an entry in Bosnian alone may cause users to think that the Serb and Croatian word is different, so a mirror entry would be required with all the flections, examples, whatnot. I mentioned "tolerance" meaning it has little to do with the recognition of the official status of Bosnian, Croatian and Serb. Let's use these terms for politics, for linguists, let's use "Serbo-Croatian". BTW, in Europe there is a demand for Serbo-Croatian interpreters, they no longer cringe at the word. --Anatoli08:21, 5 April 2011 (UTC)
As I understand it, Wiktionary makes no claims about what is and isn't a "language", it has simply decided to treat all relevant languages/dialects from the area under a Serbo-Croation header. Ƿidsiþ08:27, 5 April 2011 (UTC)
The whole notion of a language is completely subjective and arbitrary. There are no languages in the real world: only words with meanings that are used by individuals to convey information. Languages are convenient abstractions fabricated by linguists in order to describe macroscopic properties of verbal interactions among individuals (i.e. how words change in their meaning or certain phonetic properties). As an all-inclusive dictionary, the first of its kind, Wiktionary's focus is on words alone, and not on divides drawn among groups of them by external subjects. We draw our own "borders" on the basis of criteria such as pragmatics and usefulness of presentation. The problem are the folks who relate the arbitrary and convenient abstraction of a language to the also arbitrary and inconvenient abstraction of a nation-state. Borders between languages are as imaginary as those between countries - if you try really hard, you can perhaps convince yourself that they really exist - it's just that you cannot see them or touch them, and the only way to enforce them is with violence (what does one see at borders? Men with guns). That approach of course does not work in the cyberspace because there is no overarching authority to enforce the decisions (except, perhaps, a decree from the Foundation :). It's most unfortunate that certain groupings and splits of words into languages affect the feelings of some, but that's a necessary rather than a deliberate and premeditated evil. --Ivan Štambuk08:46, 5 April 2011 (UTC)
Yes, roughly like that. From Wiktionary:About_Serbo-Croatian: "Today, each of those states regulates its own standard language, the prestigious literary idiom, termed Croatian, Bosnian, Serbian and Montenegrin, respectively. Those 4 different standard languages are however based on the same dialect - Neoštokavian - are mutually intelligible, and have almost identical grammar and most of the lexis. ...
The term Serbo-Croatian on Wiktionary acts as a generic container to all 4 national varieties". --Anatoli08:35, 5 April 2011 (UTC)
That bit of Wiktionary:About Serbo-Croatian is so polemically prescriptivist that the only word for it is "mistaken". The "standard language" or "prestigious literary idiom" of each state is termed Standard Croatian, Standard Bosnian, Standard Serbian, Standard Montenegrin. People who don't use the term "Serbo-Croatian" feel no compunctions about applying the terms "Croatian", "Bosnian", "Serbian", and "Montenegrin" to non-standard varieties based on other dialects besides Neoštokavian. —RuakhTALK18:01, 5 April 2011 (UTC)
Isn't this kind of the same as the difference between the two varieties of Norwegian? Maybe we should look to them to see how this can be solved. —CodeCat10:41, 5 April 2011 (UTC)
Perhaps both sides are irreconcilable. There have been endless fights. As mentioned above, we had votes but no agreement was reached. --Anatoli12:32, 5 April 2011 (UTC)
They are not irreconcilable. There is a controversy on this subject (not only here). Choosing one of the options is taking a position, which is forbidden by the NPOV principle. The only way not to take a position is to allow the addition of sections for all these languages and to forbid the removal of correct sections for all these languages. Lmaltier17:03, 5 April 2011 (UTC)
In case of two forms of standard Norwegian, it was decided a few years ago (there was a long discussion in the BP, look it up if you're interested) that these two are "sufficiently distinct", so it's best to keep them separate. Despite the fact that there do exist dictionaries that cover both forms in a single volume. The problem is that we provide comprehensive coverage, including details such as pronunciation and inflection, and subsuming both under a single entry would introduce enough problems that it's best to keep them separate. In case of Serbo-Croatian varieties, the differences between variant words (variant as in color/colour) are minor and very regular (predictable), and the since we're dealing with 4 literary standards (Bosnian/Croatian/Serbian and newly-invented Montenegrin) redundancy is much greater than in case of Norwegian. Interestingly some folks that were pro unified Norwegian were contra unified Serbo-Croatian, despite the fact that the latter makes much more sense than the former. --Ivan Štambuk14:09, 5 April 2011 (UTC)
I don't touch Serbo-Croatian, but if I did, I would be very unhappy about having to maintain four different language sections independently. Not to mention it's ridiculous to have both Serbo-Croatian and each of BCS. Image what if a reader came by and saw a Croatian section, a Serbian section and a Serb-Croatian section all for the same word? What impression would this give them of how professional we are? And what if they appeared to contradict each other, heaven forbid!? For this reason, I support unified Serbo-Croatian. If we think that NPOV is being violated, we could use the ==Bosnian, Croatian, Serbian(, Montenegrin)== header that somebody has proposed before. —Internoob (Disc•Cont) 04:10, 6 April 2011 (UTC)
In the last half year, I have tried to improve the Swedish entries here. I have manually added main entries for many frequently used words, and semi-automatically I have added what I believe to be all missing form entries listed in these main entries. For example, in förtroende (a Swedish noun) all eight slots in the blue declension box are now links to existing form entries. There are now 20,000 Swedish gloss definitions and 80,000 form-of definitions. The ratio 1:4 is reasonable for Swedish. For any given Swedish text, I think 85-90 % of all words are now covered by Wiktionary. But to be a useful Swedish dictionary, the gloss definitions would need to be around 100,000 or five times more than today. If volunteers spend 3 minutes on each entry (which would be really fast), we can theoretically add 80,000 entries in 4000 man-hours (100 fulltime weeks of 40 working hours, or two full man-years). So apparently, this would take a lot more time than we have volunteers for. What methods are there for working faster? How were so many gloss definitions created for Italian, Mandarin, Serbo-Croatian and Finnish? Did they start out with existing dictionaries that could easily be uploaded? --LA202:43, 4 April 2011 (UTC)
There is no magic, just lots of work. If you have a list you want to add, just save the basic template and add your entries, here's a template for nouns:
==Swedish==
===Noun===
{{sv-noun|g=c}} <!-- change gender -->
# ] <!-- add translation(s) into English -->
It's more important to add the basic lemma forms, the other forms are optional but the method woould be the same. Chinese gloss definitions provide links to individual chracacters, which was a lot of for some people in the past, currently more work is done on complete words made of multiple characters. Talk to User:Tooironic about Chinese. Not sure now who created the majority of Hanzi entries. Check with User:Hekaheka if she has any special tricks for Finnish. --Anatoli05:34, 4 April 2011 (UTC)
The inflected forms of French, Italian etc. nouns, adjectives and verbs are mostly added by bots. The same could be done (not by me) for Swedish (and many other languages). SemperBlotto07:08, 4 April 2011 (UTC)
At least none that are represented here on Wiktionary. I have looked around our categories and did not find another such pair. -- Prince Kassad08:54, 5 April 2011 (UTC)
Arguably both Chinese and English could be called both languages and language families, but we don't call either both. - DaveRoss10:34, 5 April 2011 (UTC)
What protologism? Egyptic (Egyptian), Basquish (Basque), Anglean (English) and Hayerenian (Armenian)? Doesn't sound like a good idea to me. --Daniel.20:43, 7 April 2011 (UTC)
Well, it would at the very least solve the language conflict problem. It isn't a nice idea, but people have done it in the past and some of these terms went to be used by other authors afterwards. Basque does not need a proto, it has an internationally accepted alternate name (Vasconic). For the others, we would have to be creative: either Hayic or Arminan for Armenian, and possibly Kemetic for Egyptian. -- Prince Kassad20:50, 7 April 2011 (UTC)
Successful prior experience would be a good argument in favor of protologisms. Kassad, please provide an example of this being done in the past. --Daniel.20:57, 7 April 2011 (UTC)
I strongly oppose the proposal in its current form, as in this revision. (But you probably intend someone to modify the proposal to actually achieve the simplification that you speak of.) You are proposing to extend the section that governs brand names to also apply to company names. I have never understood why a term of commercial interest should per default be excluded. I have never seen a plausible argument for the claim that Wiktionary is exposed to a significant risk of being used for commercial promotion via inclusion of brand names and company names. I do not understand the phrase "X has entered the lexicon"; it means nothing to me. --Dan Polansky09:05, 6 April 2011 (UTC)
If what you want to achieve is a simplification of brand name rules, you should do just that instead of trying to cover brand names and company names under same rules in the same vote. The task of simplifying the rules for brand names is hard enough (because of the likely opposition); adding more to the plate seems unwise. I am all for simplifying rules for brand names, but I oppose governing company names by the complex rules for brand names, even after their simplification. I think we are luckly that company names are as yet not regulated by a formal vote. --Dan Polansky09:31, 6 April 2011 (UTC)
Okay, now we're at a legitimate starting point. It could definitely use more eyes.
Part of the process of simplification is to unify different categories. The current splintering is going to lead to a CFI longer than the tax code. What I'm most worried about is that trying to pin down the criteria for company names will lead to the whole thing being rejected. DAVilla09:37, 17 April 2011 (UTC)
Poll: Including company names
I would like to ask your opinion in an informal poll on whether at least some companies should be included in Wiktionary. This is not so much about the inclusion of a company name alone but rather about the inclusion of a company together with its name: Microsoft is now included as a common noun but not as a proper noun, so Microsoft corporation is now excluded from Wiktionary. Detailed comments on which companies and which company names should be included are welcome: this is a combination of a poll and a discussion.
Currently included are IBM (sense line International Business Machines), BMW (sense line Bayerische Motoren-Werke , a manufacturer of motor vehicles), Intel (sense line Intel Corporation, a US-based multinational corporation that is best known for designing and manufacturing microprocessors and specialized integrated circuits; has an etymology), Nokia (sense line Finnish mobile telephone company and brand name), Boeing (sense line An American aerospace company, which created many commercial airplanes.), Sony (sense line An international electronics and media company based in Tokyo, Japan; has an etymology), and more. Some deleted companies include Microsoft (see Talk:Microsoft#Deletion debate). --Dan Polansky09:53, 6 April 2011 (UTC)
Some companies should have dedicated sense lines in some entries.
Agree. In particular, I want the following entries to have the company included on a sense line: IBM, BMW, Intel, Nokia, Boeing, Sony, Verizon, Motorola, Google, Microsoft. I am not so sure about General Motors; I tend to see it excluded. --Dan Polansky18:16, 6 April 2011 (UTC)
No company should have a dedicated sense line in any entry.
I can't think of any exceptions offhand, but will be glad to move this to the preceding subsection if I do.—msh210℠ (talk) 18:09, 6 April 2011 (UTC)
Agree I suppose this poll is meant to lead to a possible change to the CFI? I'm not necessarily opposed to such a change. But the poll is worded in such a way as could imply support for breaking the CFI, and I do not support that. (I mean, in general there are times that the CFI are just wrong, and we have to break them; but on this point specifically, I'm O.K. with the CFI, and think we should follow them until and unless we change them.) —RuakhTALK18:18, 6 April 2011 (UTC)
The poll does not take any stance on whether CFI should be broken. The purposes to which the poll can serve are in part left open. The purposes include informing further proposed changes to CFI. The findings of the poll may be used by various people in various ways. In case of doubt, anyone can state that they do not support breaking current CFI until it is changed via a vote. I am not going to state that, as I have little respect for top-down unvoted-on regulations whose introduction to CFI is supported neither by a vote nor by a poll nor even, it seems, by a discussion in Beer parlour. (Correct me if I am wrong and there is in fact a discussion that proposed the current regulation of company names.) --Dan Polansky18:48, 6 April 2011 (UTC)
You explicitly choose not to oppose breaking the current CFI; and I think this poll could easily be read, if option #1 wins, as "See! This rule doesn't have support! We should ignore it!". In fact, you seem to be pre-emptively taking the view that we should ignore it, and viewing this poll as an alternative to following the CFI. If anything, this just reinforces my "Agree" vote. —RuakhTALK19:26, 6 April 2011 (UTC)
You seem to be confusing what I am likely to do with what the poll does. The poll asks questions about what people would actually like Wiktionary to do, rather than speculating about what an unvoted-on passage of CFI means. The poll makes certain actions easier, but it does not call for these actions. The poll does not ask "Should CFI for company names be ignored?" but rather " Some companies should have dedicated sense lines in some entries ". Nonetheless, I have called for ignoring CFI for company names several times before the poll, and I feel neither guilty nor ashamed for accepting the consensus principle and rejecting the things-sneaked-into-CFI-reign-supreme principle. --Dan Polansky07:55, 7 April 2011 (UTC)
You seem to be operating under the principle that there is some purpose to this poll, that this poll will have some sort of effect: otherwise, why have it? I, therefore, am operating under the same principle. To me, there seem to be two possible intended effects: (1) this could lead to some sort of vote to change the CFI; or (2) this could be used as justification for flouting the CFI. Since you refuse to disavow the latter, I have to take that possibility into account in my "vote". —RuakhTALK12:40, 7 April 2011 (UTC)
As option 1 reads "Some companies should have dedicated sense lines in some entries" and most people choosing it are doing so without clarifying what companies and what entries they mean, I don't see how it's useful at all.—msh210℠ (talk) 19:34, 7 April 2011 (UTC)
I have other preference or position, such as indifference or indecision.
Discussion.
This is not the right question. We should include all words, and this should not depend on the sense of the words (except that some attestation rules might be slightly different depending on the sense, in order to prevent abuse). Company names should be included when they can be considered as attested words, when enough attestations independent of the company can be found (e.g. IBM). All senses of these words should be included (e.g. for IBM: the company, or a computer from the company). But they should not be included when it's difficult to consider them as words (e.g. Société nationale des chemins de fer belges) or when the only uses found originate from the company. Lmaltier17:08, 6 April 2011 (UTC)
I think it is a good question. It makes it possible for you to agree with the first option as long as at least one company name is a word according to your understanding of "word", and as long as you want that company included on a sense line. From what you have written, it seems that you actually want at least one company included on the sense line--IBM--so you actually agree with the first option, just that for some reason you do not want to indicate this under the corresponding option. The question asked in the poll does not prevent you from stating a tentative decision procedure for inclusion in your comment, which you have done. You may provide details, such as whether you think "Nokia" should be included on a sense line in "Nokia". If a majority of editors thought that no company should have a dedicated sense line, that would be a significant discovery made via this poll. --Dan Polansky18:04, 6 April 2011 (UTC)
For company names which are words in the typographic sense, it's easy. Nokia is a word in this sense, and it's very easy to find external attestations. Lmaltier20:23, 6 April 2011 (UTC)
If that is so, I do not see what prevents you from agreeing that "Some companies should have dedicated sense lines in some entries". As you can seen from the poll, some people want to see every single company excluded, and this is also what currect CFI for company names seems to do. You cannot so easily learn this by asking other questions. --Dan Polansky08:06, 7 April 2011 (UTC)
Lmaltier, you keep saying this but it doesn't solve anything. All you are doing is shifting the debate to how we define a ‘word’, which is exactly the same debate as we are already having over what to include. This is a semantic quibble. Ƿidsiþ20:16, 6 April 2011 (UTC)
Yes, and I agree with Widsith that "what is a word" is not the right one: it merely shifts the debate without addressing it.—msh210℠ (talk) 20:31, 6 April 2011 (UTC)
Remember our basic principle : all words, all languages (1st sentence of CFI). I believe that this is the right question: which company names may be considered as words. Semperblotto does not state anything else above. Lmaltier20:56, 6 April 2011 (UTC)
Sure hat's the basic principle, and sure the question is then what's a word. But that question has — rightfully — devolved into issues of attestation and idiomaticity. Shifting back into "what is a word" mode is restarting with naivete with no point that I can see.—msh210℠ (talk) 21:20, 6 April 2011 (UTC)
In my opinion, if the final result doesn't end up with a policy that does fit with "Is this a word?", there's something wrong with it. ("It's not really a word, it's just a name made up by the company and used by people around/connected to the company. If that's not the case (ie it's used among people not connected to the company), then it is a word.") --Yair rand21:45, 6 April 2011 (UTC)
Exactly. And the question addressed here is focusing on the total exclusion (or not) of some words/senses of words, because of the sense. This is why I would reword it to focus on attestation. Lmaltier05:49, 7 April 2011 (UTC)
If I understand you right, you agree with the first option, but disagree strenuously with the second option? And the reason this is "not the right question" is that it doesn't already presuppose your first-option-supporting point of view? —RuakhTALK12:44, 7 April 2011 (UTC)
Yes, I agree with the first option, but what is important is the reason for including or not including them. Lmaltier17:59, 7 April 2011 (UTC)
Um, did something go wrong with the script? It's supposed to be just a tiny grey triangle next to the definition that can expand into a menu. Did something break? --Yair rand08:34, 7 April 2011 (UTC)
At the very least, I support the possibility of making it easier for me to edit definitions. However, was that change approved by the community? It caught me by surprise, but I may have missed discussions. --Daniel.08:40, 7 April 2011 (UTC)
It seems to do what it is intended to do, yet I find it outright annoying. I find this sort of interactive-for-dummies interface annoying; I accidentally move mouse over the little gray triangle and things start popping in front of me. I want this to be undone. Wiktionary should be a wiki rather than a WYSIWYG interactive thing, IMHO anyway. --Dan Polansky08:41, 7 April 2011 (UTC)
Wiktionary should be a wiki rather than a WYSIWYG interactive thing, not only for me but also for other editors, per default and not only when I choose a setting. Let's see what other editors think. --Dan Polansky08:49, 7 April 2011 (UTC)
The current "WYSIWYG interactive thing" is good enough for me, but a lack of "things popping in front of me" may hypothetically be better. Currently, I have to move the mouse to the arrow, then click on the "Edit definition" that is in a different place; thus the status quo is not simple enough. Not to mention that there is an annoying bug: once you edit a definition, you have to reload the page if you want to edit it again. --Daniel.08:59, 7 April 2011 (UTC)
I don't understand what you mean. The same definition? You mean if one decides that they don't want the definition they inputed, and want to have it as something different? There's a "undo" button for that in the top left for that. Or do you think that the ability to press the "Edit definition" button more than once for the same definition is necessary? --Yair rand09:04, 7 April 2011 (UTC)
The "undo" button stops working after one clicks on "Save Changes". I think that the ability to press the "Edit definition" button more than once for the same definition, after saving a change, is necessary. In other words, it is unnecessary to have the additional feature of disabling the "Edit definition" button just because a definition was edited. For comparison, there is an button in every entry and discussion page of Wiktionary, including the ones changed by the editor. My programming language teachers were prone to repetitively remind their students that users don't always take the most practical path, that in this case would be editing a definition only once in one's life, perfectly. (If everyone was able and willing of doing that, we wouldn't need that button anyways.) --Daniel.09:34, 7 April 2011 (UTC)
I think that the gadget is a definite improvement to the Wiktionary interface, both viewing and editing-wise. When the remaining bugs are fixed, it should be enabled for some representative period of time (e.g. 1 week) so that one can gather statistics (from edit summaries) how many new users (IPs) edited with it, so that we can have hard numbers quantifying its potential benefits. --Ivan Štambuk17:19, 7 April 2011 (UTC)
I didn't detect any consensus yet, even for the experiment which Ivan has proposed. User interface changes should not occur without some kind of consensus. Significant changes should first be experimental, once authorized. Once the experiment is complete and results analyzed and discussed, we can see whether there is a consensus that does not need a vote or determine whether a vote is appropriate. Frankly, I don't see why this needs to be said. DCDuringTALK18:21, 7 April 2011 (UTC)
What do y'all think of maybe (1) enabling this for admins by default and (2) in the little popup-y box, including a link to an information/discussion/disablement page? That way we can test out the change, Yair rand can get feedback, and we can all determine how and whether it can be improved to the point that we want to enable it for all users by default. (Obviously any non-admins who want to try it out could still "opt in", but only admins would be forced to "opt out".) By the way, to make clear — I'm not suggesting that people should feel free to make user interface changes "opt out", even just for admins, without discussion and agreement first. I'm only suggesting a way forward for this specific change. —RuakhTALK18:39, 7 April 2011 (UTC)
How hard is it to put it on the gadgets page instead of having a one-off method for enabling/disabling it? An alpha test among some set of users as Ruakh suggests seems desirable to make sure that it the worst bugs have been caught before beta-testing it on a wider population of users as Ivan suggested. We should first try eating the dog-food before giving it to the dogs. DCDuringTALK19:04, 7 April 2011 (UTC)
(Sigh...) I've re-added the option for definition side boxes to WT:PREFS, added a gadget to turn it on, and removed the gadget to disable it. In my opinion, the script (at least the parts of it that I enabled by default, which was only definition editing and example sentence adding) already have gotten enough testing for it to be used by default. I've received a lot of positive feedback about the tool over IRC over the past month, and I think the tool is ready for use. Dan Polansky's objections seem to be against the concept of having tools that make it simpler to edit without requiring people to go to the edit screen as a whole ("Wiktionary should be a wiki rather than a WYSIWYG interactive thing"), which the overwhelming majority of the community disagrees with. Short-term analyses of anonymous use of the tool isn't likely to work, since it can take up to thirty days before the old cached JS is cleared and the new JS is actually displayed. (Note: Just in case some people weren't aware, discussion of the script began at WT:BP#Tabbed Languages, Definition side boxes, and Sense IDs.) --Yair rand02:34, 8 April 2011 (UTC)
Sigh, indeed. There is no amount of discussion among Wiktionary insiders that conveys information about how users respond to the interface. Hypothetical user advantages are mere bits of rhetoric. Thus, until we have an acceptable means of testing, we will always be faced with the risk that our interface changes will only cause bad results. We lack the most basic things, like baseline user satisfaction and behavior data. Thus, until this lack of user data and a valid testing method is corrected, or we find a substitute for such data, such as accepting other websites as models or accepting the authority of user-interface design experts, interface changes should be limited to those our core user group can opt into or out of. DCDuringTALK04:22, 8 April 2011 (UTC)
By "interface changes should be limited to those our core user group can opt into or out of", do you mean they should be limited to those that are opt-in options and opt-out default-on options, or that they should be limited to default-off options that can be turned on or off by the core user group? --Yair rand04:30, 8 April 2011 (UTC)
Default-off seems like the best option unless there is a contrary vote. Votes are unfun so I can't imagine that we would ever do default-on in practice. Once we have contributor data that says a high share (1/2, 3/5, 2/3, 7/10, 3/4) of active users have opted in, then it might make sense to help new contributors by making it default-on. DCDuringTALK04:47, 8 April 2011 (UTC)
Um, do you think your suggested process for improvements is likely to result in a successful, easy to use/edit interface? --Yair rand08:07, 10 April 2011 (UTC)
Re: "Dan Polansky's objections seem to be against the concept of having tools that make it simpler to edit without requiring people to go to the edit screen as a whole": Not exactly: I am really happy that Mediawiki makes it possible to edit a single section rather than the whole screen. But with a bit of correction and clarification, yes, I want to edit a wiki rather than a thing whose data structures are frozen because some sort of GUI interface depends on them.
I still edit using the wiki syntax, but browsing is much more efficient without those monstrous TOCs and a bunch of sections in languages I'm not interested in. The GUI interface generated by the javascript isn't that good, I agree, and needs some polishing. This type of interface is the natural next step of evolution whether you like it or not. IMO all users should, after browsing the site for some time (e.g. more than 10 entries), be presented with some sort of options dialog enabling them to filter languages they're interested in, choose between wiki and GUI editing, and similarly. Then, we can make default whatever most folks choose to use, without needless voting bias of our close-knit community of veterans. The current state of interface reminds of old MSDN: it used to list examples of usage of a certain API in all the programming languages it was available to at once. Later they added check-boxes to filter languages you're not interested in, and now they have tabs that remember your preferred language of choice. --Ivan Štambuk07:34, 10 April 2011 (UTC)
This probably isn't going to influence anything here, but I figure I should point out that the Wikimedia Foundation Board just approved a resolution to (among other things) "urge the Wikimedia community to promote openness and collaboration, by ... Supporting the development and rollout of features and tools that improve usability and accessibility". --Yair rand08:07, 10 April 2011 (UTC)
The resolution should influence things. All we need to do is decide on what gives us reason to believe that any one purported improvement will in fact be good for usability among infrequent registered users, unregistered users, new users, and new would-be contributors. Unfortunately almost all we know is about users like us. If we are to take the resolution seriously, we should devote our efforts to getting user information, to learning about usability in general and about wiki usability in particular, and to identifying improvements that have been clearly successful at other wikis. We might also seek to learn from non-wiki sites, especially the social media sites. I'd be interested in what others have found from reviewing the usability initiative concerning tools or data that help in these regards.
In the absence of knowledge, then presenting choices along the lines Ivan suggests, which can only work for registered users, is an excellent step. If that is all we can do, then we should devise means of encouraging users to register. DCDuringTALK13:47, 10 April 2011 (UTC)
I disagree that this would be the course of action most likely to result in an improved interface at this point. While it might make sense at some later time to figure out how to fine-tune the usability and editability of the project and make sure it isn't so much affected by what Wiktionary regulars think of as being simple to use for everyone, right now we're dealing with a system that is virtually impossible to edit and navigate, and you don't need a team of usability experts and a pile of studies and user data to be able to tell that an Edit definition button makes it easier to edit definitions than requiring a user to navigate through kilobytes of incomprehensible gibberish. The new (and old, for that matter) WT:EDIT modules will probably undergo significant changes over time, but we should at least have some way of doing the more basic editing actions, without involving enormous amounts of wikitext. --Yair rand18:07, 10 April 2011 (UTC)
Re: "...right now we're dealing with a system that is virtually impossible to edit and navigate, ...": These sort of implausible statements make me even more distrustful of what you are trying to do. I have been navigating and editing Wiktionary using wiki markup for years, and it worked quite well for me. Looking at your mainspace contribution, though, you seem to prefer to play around with Javascript instead of contributing content and editing content. I really do not think that your lack of content contribution has to do with "virtual impossibility to edit Wiktionary". Re: "... we should at least have some way of doing the more basic editing actions, without involving enormous amounts of wikitext ..." What? Do you imply that, currently, editing definitions requires editing "enormous amounts of wikitext"? Does editing etymologies require editing "enormosus amounts of wikitext"? Your picture of how hard it is to edit Wiktionary seems really distorted. --Dan Polansky10:16, 12 April 2011 (UTC)
Mm-hm. Sure. See, this conversation is getting really difficult as I seem to be going under the delusion that there's not a single person on this project who agrees with you that Wiktionary is easy to edit and that the interface doesn't need real improvement, and that no one even comes close to having this view. What craziness is going through my head. Let's fix this whole mess by proving me wrong, shall we? (See box below.) --Yair rand10:30, 12 April 2011 (UTC)
You apparently do not see any problem with your extravagant claims. You equate my opposition to your extravangant claims with "Wiktionary is easy to edit and needs no improvement", which my opposition to the claims does not amount to. I see no ability on your side to critically evaluate what you say. Now you start some sort of a poll in a thread that is already running for five days, a slightly deceptive technique if you ask me. If you want to create a fair poll, do so: create a new section heading that starts "Poll: " or the like, formulate a clear question, and let us see what the responses are going to be. --Dan Polansky11:06, 12 April 2011 (UTC)
What is your position, then? You said above that "Wiktionary should be a wiki rather than a WYSIWYG interactive thing", which, as far as I can tell, equates "wiki" with the edit screen. Should the edit screen continue to be the primary method of editing, in your opinion, or not? If so, you seem to think that the editing system is satisfactory and needs no improvement. Am I wrong about this? (And re the box below, that's not a poll. I just want to know if there is at least one person who agrees with you that the WT:EDIT project should not be pursued. Should I re-post it at the bottom of the BP?) --Yair rand11:14, 12 April 2011 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ My position is that not each section and each type of content should be turned into a thing edited per default via interactive GUI. I have supported the interactive editing of translations, which was enabled, created or co-created by Conrad Irwin. (I don't remember which is the case.) I do not know what "WT:EDIT" project amounts to. The shortcut "WT:EDIT" refers to "User talk:Conrad.Irwin/editor.js", which does not describe any project and its scope. If you can refer me to a section of that page that describes a project that I allegedly oppose, I can have a look at it. I have opposed your proposal in another thread (#Tabbed Languages, Definition side boxes, and Sense IDs, 2 March 2011), in which you have proposed introducing (a) tabbed interface for a tab per language, (b) the editing tool discussed in this thread (User:Yair rand/editor.js), (c) sense IDs. --Dan Polansky11:30, 12 April 2011 (UTC)
The script associated with WT:EDIT (User:Conrad.Irwin/editor.js) contains a framework for a Wiktionary semantic editor, with a lot of code to make it simple to add modules to the editor. Currently enabled modules include the translations adder, the translations balancer, the tgloss editor, the definitions adder, and the rhymes editor. (WT:EDIT#Coding lists a bunch of ideas for modules, one of which I've successfully built into User:Yair rand/editor.js.) The aim is to make it possible to edit without wading through piles of wikitext on the edit screen. --Yair rand11:41, 12 April 2011 (UTC)
If there is a project that you want to implement and that you seek agreement for, you should describe the project a bit at some location that belongs to the project. "User:Yair rand/WT:EDIT project" might be such a location, or "User:Yair rand/Easy editing project" or whatever. The first heading of User:Conrad.Irwin/editor.js is "Usage"; the table of contents can only be found three page-downs below, so going to sections that are located below is a bit painful. The section "Coding" contains a subsection "Features", which does not speak of editing of definitions, but what it speaks of is "(Add example sentence/quotations buttons)". I do not see any statement of aim to turn each Wiktionary section into a GUI editable thing. So again, if there is a project that you are picking on and pushing, it should be better described on a subpage in your user space; some 200 words should do the first job, and should not be too much work, especially compared to the amount of coding that you already did. --Dan Polansky12:04, 12 April 2011 (UTC)
I'm not really sure what you're saying; WT:EDIT already exists. Re the name, Cirwin suggested a while ago that WT:EDIT could be moved to Wiktionary:Editing UI, but I don't really see any problem with the current location. --Yair rand13:20, 12 April 2011 (UTC)
I really don't like the location "User talk:Conrad.Irwin/editor.js". I have started editing there, but the namespace suggest I actually should not. If this is the project page for WT:EDIT, the page should still state that (a) there is a project, (b) what the project is trying to do, soon and eventually, (c) do so under a dedicated heading. --Dan Polansky14:28, 12 April 2011 (UTC)
Anyone who agrees with Dan Polansky's view that Wiktionary is simple to edit and that the interface does not need improvement, please add your name below
...
No, I don't think it's 'easy' just by the nature of what Wiktionary is. Wiktionary is complicated. That said, I don't think we should make these tools default but rather an opt-in thing, raise awareness about them, and this is the best place to do that. --Mglovesfun (talk) 10:51, 12 April 2011 (UTC)
Are the objections to this tool specifically, or to javascript tools on by default in general? Are you hoping that at some point down the line someone will make a better tool for editing definitions? I would like to know if the community is opposed to the WT:EDIT project, and if it is, then I should cease putting in effort to making it better. --Yair rand10:58, 12 April 2011 (UTC)
Re: "...Dan Polansky's view that Wiktionary is simple to edit and that the interface does not need improvement": I have not said this, but my view does come within two shooting distances of the statement. The interface may benefit from an improvement here and there; Wiktionary is reasonably simple to edit. Phrasing good definitions and finding the right slicing into senses and their definitions is hard, much harder than using Wiktionary's current editing interface. --Dan Polansky11:12, 12 April 2011 (UTC)
Just poking my head in here as a relatively new user: Wiktionary is quite difficult for the average Joe-not-a-linguist to add information to, possibly even more so than Wikipedia, in respect to formatting and the use of templates. If one's contribution isn't completely correct and formatted, there's a good chance it'll be reverted with no explanation in the following thirty minutes. With that said, I am wholeheartedly in favor of making features which unambiguously make it easier to edit at least optional, if not default. — lexicógrafa | háblame — 12:30, 12 April 2011 (UTC)
Are you even listening to yourself? Not three inches up the page you've put a huge boxy div, font-size 18px, line-height 32px, asking people to say whether they agree with your straw-man presentation of Dan Polansky's general view on the Wiktionary edit interface, which is supposedly "that Wiktionary is simple to edit and that the interface does not need improvement". Nothing there about this specific script, nothing there about whether such improvements should be on by default. If you don't want people to respond to that, then maybe you shouldn't have made it so huge? —RuakhTALK14:47, 12 April 2011 (UTC)
Oh. I kind of figured that the box would look like an invitation to add one's name the the list inside the box, and didn't realize that the comments after were in direct response to that. Well, I feel ridiculous. I've collapsed the box, it was probably a bad idea. I guess a proper poll could be started, as soon as I figure out what the disagreement is about, since it's starting to look like I'm completely misunderstanding what Dan Polansky's objections are, though I'm not sure about that... Dan Polansky, are you objecting to any further expansion of WT:EDIT (ie adding more modules on by default), or just these specific tools, or just to having tools in certain areas, or ...? --Yair rand15:15, 12 April 2011 (UTC)
What about you describe in 200 words on the pseudo-home page of the project what the WT:EDIT project is trying to achieve? I am scared of the idea of etymologies and definitions being editable using a GUI gadget by default. I do not oppose any such expansion that is not enabled by default. I will oppose expansions considered for default enablement on a case-to-case basis, yet currently I am inclined to oppose further GUI gadgets. However, given that I am only a single person, a quick poll could show that I am in a very small minority, which would end this discussion anyway. --Dan Polansky15:30, 12 April 2011 (UTC)
The page WT:Glossary says that "en" is English, "dat" is the Darang Deng language, "est" is Estonian, "pl" is Polish, among few other language codes.
I can think on a number of possible reasons to display this information there, but frankly WT:Glossary simply isn't a good place to look for language codes. Most aren't listed anyway, making it thankfully incomplete. I suggest removing all the language codes from there to make it cleaner. --Daniel.13:54, 7 April 2011 (UTC)
I have a proposal for organizing our coverage of palindromes. Since this involves converting two huge appendices into dozens of smaller big appendices, I thought it would be better to explain it here, rather than at WT:RFM or WT:RFC. The idea is:
Splitting Appendix:Palindromic words and Appendix:Palindromic phrases into a set of one appendix per language. As a result, for example, Appendix:Portuguese palindromes would contain all palindromic words and phrases in Portuguese, thus deprecating the current system of having to seek palindromes in Portuguese by looking into two separate huge lists of all covered languages.
Sounds good to me. The current pages can link to the new appendices IMO. (Even better IMO, can redirect to Appendix:Palindromes (currently a redirect to Appendix:Palindromic words), which can, in turn, link to the new appendices.)—msh210℠ (talk) 16:23, 7 April 2011 (UTC)
Good point. I agree. The deletion summary for the current appendices should mention such category, so people looking for the old page can find the new ones.—msh210℠ (talk) 17:18, 7 April 2011 (UTC)
Notably, the 16 playing cards that begin with "ace", "jack", "queen" and "king" are defined while the 36 ones that begin with "two", "three", "four", "five", "six", "seven", "eight", "nine" and "ten" are not.
I would like to know the opinions of people on what to do with them, so I have one specific question:
In your opinion, how many of the following 52 entries (4 suits, 13 cards per suit; joker isn't included) should be defined as English names of playing cards?
Except that any that has a secondary meaning (two sense lines in English) should keep that sense line and should have {{&lit}} for the playing-card sense. (I suppose this really belongs in the "Some of them" section.)—msh210℠ (talk) 19:39, 7 April 2011 (UTC)
The basic idea of "None, except..." is clear enough for the purposes of this poll, but it is ambiguous in practice. If someone cares to prove that every listed card has a secondary meaning, then your choice naturally would automatically be read as "All of them"; however, now it logically means "Some of them" indeed. --Daniel.19:48, 7 April 2011 (UTC)
DCDuring, as the creator and only current voter of this section, please change the header or clarify what it means. In the meantime, it would be better if other people who want exactly 12 or 16 bluelinks voted for "Some of them", which covers everything from 2 to 51 entries. --Daniel.20:07, 7 April 2011 (UTC)
I would include them if they can carry some useful lexicographical information, yet they either are semantic sums of parts or they border on being so. For instance, "king of spades" is translated into Finnish as "patakuningas" and into Czech as "pikový král", so the order of words is reverse. Having "king of spades" is certainly a convenience for a translator, who does not need to look up some appendix for how names of cards are formed in various languages. The thing might be expressed in English as "spade king", but it is not. I might lean to inclusion also considering that 52 entries is not all too many, but I do know what flood of other entries made on this model this would open. I have documented the formation of these sort of phrases by placing examples into fragments of example sentences, as "piková dáma" in pikový entry. --Dan Polansky11:14, 8 April 2011 (UTC)
To help decide what should be included to override the CFI, we could have little votes for specific groups of words, expression and combinations, even if they are SoP, like this with the result attached to the category page. What do you people think? --Anatoli06:15, 21 April 2011 (UTC)
Idiomaticity of individual words.
Wiktionary:Criteria for inclusion#Idiomaticity gives megastar as an example of an idiomatic expression, because it (mostly) only uses one specific sense of mega- and one specific sense of star. The implication is that even individual words are subject to the "idiomaticity" criterion, and could be deleted as NISOP.
I think this is more or less false; there are various edge cases where we've decided to exclude certain NISOP wordlike entities, but always the core of the argument was that the entities weren't actually single words. (For example, we exclude brother's on the grounds that it's not a single word, but rather a word (brother) plus a clitic ('s).) I don't think that applies to megastar, which would be a single word even if it were NISOP.
I think this needs to be fixed, but I'm not sure exactly how. Anyone have any thoughts?
Our current solution has just been to ignore this section of CFI all together, at the very least since I started contributing in 2009. I'd like it changed just because it's plain wrong, but ignoring it is a good old fashioned simple solution, and it's worked fine until now. Mglovesfun (talk) 20:40, 7 April 2011 (UTC)
I dunno, I think most of that section is O.K.; it's just the "megastar" part that bothers me. I mean, even without that part it could be taken as applying to individual words, but that's the only part that implies that it should be taken that way. (Unless there are other problems I haven't noticed . . .) —RuakhTALK21:49, 7 April 2011 (UTC)
In my ideal dictionary certain words would not be included except in some kind of lesser status, like in an appendix or as a run-in entry. Examples would be many of the words created by affixation (fewer by compounding) using productive affixes and combining forms. Only if a meaning were not decodable from the components would it merit a full-fledged entry. Accordingly, I find the idea behind the section appealing. Why we need to have all of the members of Category:English words prefixed with un-, Category:English cardinal numbers, and Category:English ordinal numbers is beyond me. However, I doubt that we could implement it in our processes without a further increase in unproductive discussions and more inconsistent implementation. Further, we seem to always find advocates for the principle at least of, say, including all cardinal numbers, however impossible that is, and for including all attestable cardinal numbers, as a fallback position.
If someone else would take the trouble to propose a scheme for efficiently excluding "non-idiomatic" words, I would be happy to entertain the possibility that it would not lead to endless unproductive debate. DCDuringTALK04:00, 8 April 2011 (UTC)
I'm actually O.K. with a hypothetical idea of sometimes excluding words that are NISOP, but current, vote-approved practice is not only to include all NISOP words, but even to include all NISOP phrases that are sometimes written as single words (link), and all regular inflected forms of single words (link). I consider it more important that the CFI reflect accepted common practice than that the CFI or accepted common practice be perfect. —RuakhTALK14:27, 8 April 2011 (UTC)
I would just remove this from CFI altogether:
For example, mega- can denote either a million (or 220) of something or simply a very large or prominent instance of something. Similarly star might mean a celestial object or a celebrity. But megastar means "a very prominent celebrity", not "a million celebrities" or "a million celestial objects", and only rarely "a very large celestial object" (capitalized, it is also a brand name in amateur astronomy).
The most telling part of CFI#Idiomacity is the first sentence: "An expression is “idiomatic” if its full meaning cannot be easily derived from the meaning of its separate components." While this sentence is not without problems, the discussed paragraph does not help to fix these problems. --Dan Polansky10:40, 8 April 2011 (UTC)
My general beef with CFI is that where there's a consensus among editors, often CFI doesn't reflect this and says, in fact, we should be doing something else. I think that's to a large extent because votes are long and getting 70% is often going to be difficult, hence our solution of just ignoring whatever CFI says and carrying on regardless. Which I seem to dislike more than most editors. Mglovesfun (talk) 16:40, 8 April 2011 (UTC)
The threshold of 2/3 is being discussed alongside of 70%, for votes that are not about voting and similar meta-things. While at least one admin has mentioned even the threshold of 80%, that does not make any sense to me. An admin that would use the threshold of 2/3 when closing a vote would be doing nothing too revolutionary, AFAICT. I was mentioning the threshold of 70% alone some time ago, but after some research I realized there is not much precedent for pushing that threshold as the common practice, so now I am usually mentioning the pair of 2/3 and 70%. --Dan Polansky17:06, 8 April 2011 (UTC)
Probability arithmetic would suggest that the smaller the number of voters the higher the voting threshold to achieve the equivalent level of certainty about the "will of the people". DCDuringTALK18:05, 8 April 2011 (UTC)
The general principle is all words but common sense should prevail: if a bot creates trillions of pages for infinite series (such as numbers), the project will be closed. Therefore special attestation criteria are required for such cases. Another case is about words that anybody can create for their own use, such as brand names, company names, etc. In such cases, precise attestation rules are also required.
But we should keep the principle all words. If most dictionary exclude many words, especially those easily understandable from their components, it's only because their limited space available is better used for other words. These considerations don't apply here.
About the idiomacity criterion: I would remove it altogether, and replace it by is the word or phrase part of the vocabulary of the language?: blue bicycle is not an element of the vocabulary, while good morning, even if not idiomatic, is an element of the vocabulary of English, because this phrase must be learned by people learning English. Lmaltier20:19, 8 April 2011 (UTC)
I'm not hypothetically against the exclusion of unidiomatic single words like Zirkusschule (Talk:Zirkusschule) but I can't see how it would work in practice. How do you exclude some and yet keep others? Do people want headache and birdcage to not overtly meet CFI? I sincerely doubt it. So I'd like to see unidiomatic words meet CFI. That was in my amendment to CFI that I proposed in 2010, which failed. Mglovesfun (talk) 13:11, 11 April 2011 (UTC)
Feature request: Reverse translation button
When I hover my cursor over a translation, I would like a button in the popup that sends me to an edit page with the reverse translation prefilled. ~ heyzeuss06:55, 8 April 2011 (UTC)
True; is that terrible? Note also that the prefill couldn't have a POS header (or it could, from the English, but it would be very tentative, since the FL word might not have the same POS as the English). Presumably, no one would click the link unless he was sure doing so would yield a correct entry; and such a person would usually know some more about the word that he could add in, such as an inflection line or POS category.—msh210℠ (talk) 09:06, 8 April 2011 (UTC)
Thanks, that was pretty fast. I tested it on ajatusvirhe, and it did what I wanted. I have some other ideas for it, too, but I'm pretty happy with what I've got. ~ heyzeuss11:48, 8 April 2011 (UTC)
Language categories
I don't know whether it has been already discussed or not but I think that language categories are not as useful as they could be. Here is an example: I want to find all Romanian words written here with ş, ţ (cedilla characters) in order to move them to new names with ș, ț (comma characters). So I am obliged to go through each and every separate Romanian category (nouns, adjectives, verbs etc). My job would be much easier if I could find all Romanian words in just one category. And it's not just me, I suppose. Why should users wait for the next dump and spend time and energy to built indexes of Romanian words when it's so easy to have a full list of this (every) language words? Other Wiktionaries (Greek, Romanian, French etc) categorize entries in both categories, as nouns, adjectives, verbs and as words of a certain language. Couldn't we do the same? --flyax09:04, 10 April 2011 (UTC)
Indexes of all words of a language are more useful than categories of all words of a language, unless I'm missing something. Indexes have audio examples, definitions and more space.
It would be very easy to make a query to look for what entries contain ş or ţ in the title and a Romanian section in the body, wouldn't it?
In addition, the possibility of finding all Romanian words that include a certain letter with a certain diacritical mark could be implemented with the creation of Romanian counterparts of categories like these:
I didn't mean to suggest abandoning indexes. They are good for anyone who needs them. Maybe it's easy to make a query in them but I don't know how. On the other hand it's easy to search through a certain category using API commands. Alternatively, go type the category's name on Special:Export, click add, and have the words in it (it will work perfectly for categories with less than 5000 members). So, for me, it's much easier to have comprehensive language categories - and it costs nothing. --flyax10:42, 10 April 2011 (UTC)
Since my job with Romanian entries is almost done (I'm just waiting for the vote to get the bot flag) let me add another example. The next step is to change cedillas to commas in English entries, ie find all instances of {{t|ro|something}} and modify them. Suppose that I have prepared the fix and want to run it. The command would be :
You see, it will be much easier for the bot to run in just one category that would contain all English words. --flyax11:16, 10 April 2011 (UTC)
In reply to "Indexes of all words of a language are more useful than categories of all words of a language, unless I'm missing something." If we had such indexes, yes. Currently indexes like Index:Old French don't include inflected forms like plurals, verb forms, adjective forms, etc. Using AutoWikiBrowser you could do "Category (recursive)" and "Category:Romanian parts of speech". That would get everything apart from uncategorized Romanian entries. Mglovesfun (talk) 12:54, 11 April 2011 (UTC)
Now I see that there is a similar possibility for replace.py: use subcat instead of cat. My fault; please ignore my last example. --flyax14:22, 11 April 2011 (UTC)
Do we want to keep this as it is? For example, we have Latin entries which use j. I don't know about ligatures; certainly there are attestable Latin words using ligatures, for example pæninsulae, according to WT:RFV#pæninsulae. I'm inspired by the debate over vp meaning up. It seems to me that the Latin i/j situation is the same; i and j may not have been considered separate letters for a long time, perhaps a thousands years or even 1500, but they are now. I also find the section horribly inconsistent; do not use ligatures "as these do not appear in Classical Latin", but use v and u separately despite the fact that they don't appear in Classical Latin. Mglovesfun (talk) 12:58, 11 April 2011 (UTC)
Yes, EP has left the project. We should decide for ourselves. Personally, I won't be adding any ligatures - I don't know how to type them. — This unsigned comment was added by SemperBlotto (talk • contribs) at 14:10, 12 April 2011 (UTC).
I see two issues in that, the issue of whether to recommend one spelling/form over another, like paeninsula over pæninsula, the second is whether to exclude the non-recommended spellings/forms in spite of any attestation one might find. I can't see how to do that without bypassing CFI. I goes way beyond Latin, in terms of consistency. Would anyone want to exclude an English term with a ligature that's attested, such as præsent instead of praesent. There are so many comparisons that I could make, I'd like to stop there for fear of going too far off topic. --Mglovesfun (talk) 15:32, 12 April 2011 (UTC)
English is easily attested. Considering words with completely regular variations of orthography different words can make it much more difficult to attest words, for little to no gain.--Prosfilaes17:56, 12 April 2011 (UTC)
IMO we should include forms with i' and forms with j, as attested. One should of course be a form-of entry linking to the other.—msh210℠ (talk) 16:02, 12 April 2011 (UTC)
I think you're skipping ahead a bit there CodeCat, WT:ALA still says not to include ligatures and j spellings at all. To Prosfilaes, these to me are two separate issues. WT:ALA isn't intended to supersede WT:CFI. I'm not advocating creating Latin ligatured spellings and j spellings even when not attested. WT:ALA right now says they should be deleted no matter how well attested, even if we've got 100 citations. That's the issue I want to tackle. NB (third separate point of this comment) the French Wiktionary counts Latin as a living language because it's the official language in one country (The Vatican), so j spellings are preferred to i spellings when both are attested. Make of that what you will. Mglovesfun (talk) 16:02, 13 April 2011 (UTC)
I would like to get deleted Wikisaurus pages named ".../def". There are 11 such pages. The slash-def pages and their content are listed at Template talk:ws refer; an example: Wikisaurus:tiny/def - "small in size". I would like to replace all uses of {{ws refer}} in the mainspace with something like "See also ]". Anyone who has an idea how I should best proceed about this, please let me know. I am about to proceed to replace {{ws refer}}, and maybe let the slash-def subpages be without trying to get them deleted; I don't know. If you have any questions, don't hesitate to ask: I will try to answer them. --Dan Polansky13:36, 11 April 2011 (UTC)
Related: WS:penis/translations seems like an odd idea. Good idea or not? These translations should be in the main namespace; or, I personally would favor WS:penis/French, the French Wiktionary allows all languages to have Wikisaurus entries; I'd be happier for us to do that than have this approach. Mglovesfun (talk) 13:40, 11 April 2011 (UTC)
I have created WS:penis/translations back in 7 September 2008 as a place to which I can move the translations section of WS:penis. Years later, as far as I am concered, WS:penis/translations could be deleted, but it might better stay until the issue of naming of non-English Wikisaurus entries--an open and rather challenging subject--is resolved a bit. One demo entry that I have created is WS:příbuzný, which could alternatively be called "WS:cs:příbuzný", "WS:relative (Czech)" or "WS:relative/Czech". The subject of naming of non-English entries seems rather unrelated to slash-def pages, though; the considerations that lead to its resolution are rather distinct. --Dan Polansky14:54, 11 April 2011 (UTC)
What's happening with Word of the Day these days? Who's running it since EP left? All the current words seem to be from April 2010. Ƿidsiþ06:27, 13 April 2011 (UTC)
IIRC, Lexicografía took over in early January and completed January, I did February, and no one's touched it since, so March and, so far, April's entries were recycled from last year. You can see the status at ]. Lexicografía has expressed interest in managing it, but has not been doing so. It's a big job; I'd be glad to split it somehow with someone. The hard part is finding entries good enough to be WOTD, or bettering them to that point; the easy part is the actual setting of them as WOTD, which is almost rote.—msh210℠ (talk) 07:31, 13 April 2011 (UTC)
I'm okay with either taking it on or splitting it with someone else, I've just been quite busy recently. I should definitely be able to pick it up by the beginning of May. — lexicógrafa | háblame — 12:11, 13 April 2011 (UTC)
Yeah, I'm definitely happy to help out. I don't really know how it works, but I'll happily split the work with you or someone else. I actually like getting words up to WOTD standard, I just don't really understand how our process works. Ƿidsiþ08:42, 13 April 2011 (UTC)
On Wiktionary, the main index is to find a word based upon spelling by people who either 1) heard a word and know the language's pattern of sound-to-text transcription or 2) saw a word in print and want to know the meaning. ASL has no standard phoneme-to-text transcription, and thus ASL is never seen in print. The chicken and the egg syndrome.
I have developed a rich orthography for ASL over the last five years. It is documented, but not yet tutorialized, at www.aslsj.com. Apparently no one would be willing to learn it unless they had to. It is similar to sheet music. Most people don't need to read sheet music if they aren't going to practice other people's musical compositions.
I would like to start creating ASL entries on Wiktionary using my own orthography for the titles. It is consistent and concise. The best part is that, since it is spoken-language-neutral, French or German Sign Language Wiktionary could refer to it without trying to also translating the titles. As there isn't any real activity in the ASL section, I don't think anyone would even notice.
Example: The entry "Claw5@TipFinger-Claw5@CenterChesthigh Claw5@SideChesthigh-Claw5@SideChesthigh" would be written as "5bts-jxr". The texts of entries would still be in English. I would just like to use my own entry titles. - Positivesigner08:14, 14 April 2011 (UTC)
The ASL entries were all created by User:Rodasmith, who is apparently now inactive. I'd like a different transcription system if it's documented somewhere (on the wiki, that is), because the current one is very unwieldy (you can see on some entries that their name is insanely long) and it is not any more or less intuitive than yours. -- Prince Kassad09:43, 14 April 2011 (UTC)
I am pretty strongly opposed. Frankly I would prefer the flavors of sign languages be handled exclusively in translation tables, via image strings or videos. These systems for writing down scripts for signs overlook the fact that the majority of those who sign read and write exactly like everyone else, barring those who use braille. We obviously should have sign language in Wiktionary, but I don't like the current or proposed handling of it. - DaveRoss10:23, 14 April 2011 (UTC)
I guess. I am pretty racist against things which don't make sense to me, like inventing an inelegant solution to a problem which already has an elegant one. Also I don't want to exclude them from the main namespace. - DaveRoss19:10, 14 April 2011 (UTC)
I'm surprised that you find forbidding entries for terms in non-written languages to be an "elegant solution". Doubly surprised, actually: surprised that you find it to be elegant, and surprised that you find it to be a solution. —RuakhTALK21:07, 14 April 2011 (UTC)
Let's say that I were to create another encoding scheme for English, perhaps one which had fewer letters or had a 1:1 letter-phoneme structure. This may be an interesting, even useful encoding, but I would expect it to be rejected from Wiktionary because it isn't English. Obviously ASL and the other varieties of sign language are different than what I described, but the encoding scheme for them above is not. I don't think that Wiktionary is really well equipped to handle ASL right now; I think there are plenty of elegant solutions which we could implement rather than implementing the inelegant one which was suggested. That is what I meant. If I want to find out how to sign a particular word I would love to see that sign available in video or at least picture format in the translations at the applicable entry. - DaveRoss21:28, 14 April 2011 (UTC)
Let's take a closer analogy, and say that several thousand people in North Dakota speak an indigenous language called Fake among themselves, but English with the outside world. They don't have a writing system for Fake: about half are literate in English, but none are "literate in Fake". I suppose that, if a linguist came up with a sensible writing system for Fake, and wanted to start documenting the language here, you would reject it "because it isn't Fake". If they wanted to add audio files to translations tables for English entries, fine, but no Fake entries would be allowed, and there would be no way to search for a Fake word unless you already know its English translation. Do I have that right? —RuakhTALK21:42, 14 April 2011 (UTC)
Sounds right, I would reject that as well. If the new orthography actually gained some currency and the Fake speakers adopted it that would be the written form of their language and we should include it. In the case of ASL the written form of the language is English. The proposal is for a "phonetic" transcription of the "verbal" form (quoted words used to parallel sign language to spoken languages) which is completely artificial. It would be great if there were a sensible way to search for signs, this isn't it. - DaveRoss23:00, 14 April 2011 (UTC)
Displaying ASL visually on a computer or mobile could soon become a possibility, perhaps using a series of .svg images, and a user might be able to choose ASL preferentially just as we do other languages. It seems to me that the main barrier is the lack of a concise and consistent computer-friendly notation. If we had one, I think it would soon be feasible to write a "transliteration" script to make this work. I doubt that "Claw5@TipFinger-Claw5@CenterChesthigh Claw5@SideChesthigh-Claw5@SideChesthigh" could be made useful, but "5bts-jxr" seems reasonable, and Positivesigner states that it is consistent and concise. If that is true, I think it is a good idea to go ahead. If a better system ever comes along, it should be a simple task to convert all of the "5bts-jxr" entries to the new system. —Stephen(Talk)23:47, 14 April 2011 (UTC)
There is some push to get SignWriting Unicode codepoints, which would give us canonical pagetitles for SLs.—msh210℠ (talk) 03:15, 15 April 2011 (UTC)
Fortunately, the current system is phonetically accurate and complete according to current ASL liguistics, so it should be bot-convertible to any eventual SignWriting Unicode mapping. I can't wait for that day! :-) —Rod (A. Smith) 01:59, 18 April 2011 (UTC)
Re: "In the case of ASL the written form of the language is English": That's not true. ASL signers use written English as their written language, just as Fake speakers use written English as their written language, but that's a cultural fact, not a linguistic one. Note that English has very different syntax from that of ASL, and that historically, ASL is related to French Sign Language (and not, for example, to British Sign Language). Various ASL lexemes have been influenced by English writing (e.g., by incorporating English letters), but I'm sure that Fake speakers use a lot of English loanwords, too. Re: "It would be great if there were a sensible way to search for signs, this isn't it": For the record, I'm not actually endorsing this proposal. So far, I haven't seen any really great proposals for how to deal with this problem. I'm just objecting, very strenuously, to your claim that your proposal, that of forbidding entries for attested-but-unwritten languages, is a "solution" to the problem, let alone an "elegant" one. If you had described it as "arguably the least terrible, by a small margin, of the various proposals", then I'd probably be on board. —RuakhTALK00:19, 15 April 2011 (UTC)
The lack of clarity here is my fault, I am not saying _my_ solution is the elegant one, I am saying that the various media-based sign language dictionaries out there are better than the proposed shoehorning into Wiktionary. I have seen a number of them which have videos or images and I find them much better than this alternative. - DaveRoss01:52, 15 April 2011 (UTC)
No need to go to Fake. There are real indigenous languages that have never been written by native speakers and that are written by linguists using either IPA or transliteration. I believe we even have someentries of the sort. Why are SLs less worthy?—msh210℠ (talk) 03:17, 15 April 2011 (UTC)
In response to TheDaveRoss, you mentioned that the users of signed langauges actually use a regional spoken language's transcription system to communicate in writing. This does not document their own language's words; only that some of their words happen to be similar to some other language's words and phrases. Therefore they never truly write down what they are thinking / feeling.
The general rule for inclusion in Wiktionary is any natural language word "if it's likely that someone would run across it and want to know what it means," even if it isn't attested to by Daniel Webster. The problem here is that there is no standard way to find out what a sign word means. And THAT has irritated me since age 12. I have devoted the last five years to documenting ASL phoneme patterns. Now I can write down ASL and read it months later without watching the video again. Even if I do not remember the word, I can sound it out using rules of pronunciation.
According to your comments, apparently your main objection to using my plain-text transcription system on Wiktionary is that it hasn't been adopted by any group of native-ASL speakers. Deafness is almost always one generation thick. 90% of Deaf people are born into hearing families; 90% of the children from Deaf families are born with normal hearing and are bi-cultural, bi-lingual. Due to 100 years of oralism which punished Deaf children for using sign language, historically Deaf enculturation and learning sign language happened after the age of maturity. Therefore there is no "Deaf Region" where the people could adopt a written language of daily commerce. 50% of Deaf persons today graduate without attaining a 4th grade English reading level.
I want to document ASL, not for those Deaf who cannot read it, but for the hearing people who are trying to find out what it means. They won't be able to type in the proper spelling using my system without study. But they can browse the words and see that there is structure. They can see the kinds of phonemes used and how they are put together. They can look up an English word's "See Also" section and notice how the signed word has slightly different inflection in it's definiton. They can read about the word's etymology, synonyms, antonyms, words for which it might be mistaken and common mispellings.
I have to personally remember how to spell the entry titles so I can make these links. The current encoding system is incredibly unwieldy in this respect. Since I have already done this much work, it seems better to use my transcription system than to have a personal index back to the current system. Especially since there is no one around willing to help me learn the current system.
About your comment, "I think there are plenty of elegant solutions which we could implement rather than implementing the inelegant one which was suggested." What I read in this is you would prefer to have no information rather than incomplete information. Unless you are deciding to start implementing a more elegant solution in which I could participate, I do not feel that my making ASL entries would be wasted effort. There is no one else beating me to the punch, so to speak.
I would just like to use my own entry titles to create English Wiktionary entries about ASL words. As I am not very familiar with the Wikimedia power structure, I am looking to see what barriers there are to my doing so and by what means I may address those barriers. If no real barriers are presented, then I can assume to proceed just like any other new word entry. - Positivesigner06:42, 16 April 2011 (UTC)
My view is that ASL entries are all by their very nature unsupported by MediaWiki. So, they should be in appendices. Mglovesfun (talk) 12:19, 16 April 2011 (UTC)
I think your proposal is fine. The biggest problem I see with it is that the current naming system for SL page titles was enacted by vote so needs a vote to be so heavily emended.—msh210℠ (talk) 04:47, 17 April 2011 (UTC)
Re TDR and Mglovesfun, we've already voted in a naming scheme for SLs, thereby also explicitly allowing SL entries; the horse has left the stable already. The only question here is whether the naming scheme should be changed. (Of course, if you want to change the topic of conversation to be about revisiting whether we should include SLs also, you're welcome to; but I suspect (and hope) that the proposition that we not include them won't garner much support.)—msh210℠ (talk) 04:53, 17 April 2011 (UTC)
Comparing the current transcription system with the one Positive proposes here, two differences stand out to me:
The current system favors phonetic transparency for readers, while the proposed one favors ease of writing for editors.
The current system represents the phones as analyzed and described in professional publications, and has apparently broad consensus in the field of ASL linguistics, while the proposed one is based on private analysis.
I can empathize with the expressed difficulty in writing entry titles, but perhaps a less O.R. resolution would be to adopt editing tools that simplify the writing the typographically lengthy phone names. —Rod (A. Smith) 17:12, 17 April 2011 (UTC)
Nice to see that serious Unicode SignWriting submission. I'd be curious about approval timeframe, bit it looks solid enough. After approval, I say we forge ahead with adoption/migration. I suspect I could write a migrator bot in a week, unless I'm busy with work. Hmm, would MediaWiki need an update to accept an expanded Unicode range in entry titles? —Rod (A. Smith) 04:48, 18 April 2011 (UTC)
Probably not, MediaWiki should be fully Unicode aware. And if I try something like in a tentative "plane 10" (which will probably never exist), I see that the link works correctly and I could theoretically create an entry there. So by the same means, SignWriting should work as well. -- Prince Kassad12:52, 18 April 2011 (UTC)
Reading through communications that led to the Unicode SignWriting submission, and then re-reading the submission, I see that there are a couple of known deficiencies in the submission. A minor one relates to normalization/canonicalization. In the existing SignWriting software like SignPuddle, two authors trying to compose the same sign often encode it through different typographical sequences. People are working on the rules that could yield a single canonical form of each sign, but those rules have not yet been created, let alone tested for acceptance by SignWriting users. We could ignore that problem because we could impose our own canonicalization standards. The major deficiency, though, is that the SignWriting Unicode submission omit positioning details. Unfortunately, there are multiple glyph-positioning systems in current use (absolute freeform layout, cartesian coordinates, polar coordinates, and variations with restricted layout rules), and it's not yet clear which one should be made standard. The authors of the Unicode submission acknowledge this as a key deficiency, and say it will be at least a couple of years before sufficient testing can be done to determine which system should be adopted as the standard. The three universally accepted classes of sign language phones are handshape, position, and movement, so without glyph-positioning details in the script, entry titles based on SignWriting would be a largely unintelligible sequence of handshape and movement phones. —Rod (A. Smith) 23:53, 18 April 2011 (UTC)
Although the SignWriting Unicode submission lacks the specification of glyph positioning, it does include symbols that represent the phonetic positions of signs. See http://www.signbank.org/bsw/iswa/386/386_bs.html for some examples. So, although entry titles would not show pleasingly-arranged glyphs, they would include the same details our current system transcribes (e.g. "...@CenterChesthigh..."). Looking forward to it's adoption. —Rod (A. Smith) 06:26, 19 April 2011 (UTC)
In response to Rod (A. Smith), you are correct in stating that my primary concern is the entry length. And also that my research is of my own originality, not published, reviewed, approved, etc. Now, while I type this, you are unable to hear my voice and understand the subtle nuances of tone not alphabetized. So please realize the statements following are made with curiosity, and not with demands. I am always glad to be filled-in where I have missed something.
Specific to Wiktionary entries, the information documented here is intended to be a reference for use by the other Wikimedia projects. It may not simply be a re-wording of existing, copyrighted definitions. It can delve into areas of possibly non-accredited research created by professionals and non-professionals alike. No one ever gets to make a final decision on any page unless it gets deleted; they can always be updated or reverted. "Being bold is generally a defensible position."
The intention of creating American Sign Language entries is to encourage other projects to use those entries. How they find the entry they want will be a guess-and-check process until ASL does get an approved orthography by a linguistic group or a political body. They would create approved ASL dictionaries and books on how to read and write in ASL. Native speakers would create scholarly and entertaining works. And so on.
Until that happens, I would like to use the information I've gathered to ease the re-use of Wiktionary ASL entries. The professional publications of which you speak are not created with concise communication in mind. I imagine that most contributors of ASL definitions will not have read those publications. Therefore they should not have the last say on this topic. My research has been solely directed toward organizing ASL words into writing patterns. Although I have not attained any degrees in sign language, I have been a software systems analyst for 20 years. My ASL encoding system is based upon my many and varied experiences in how software designers have solved language encoding problems.
Your mention of adopting "editing tools that simplify the writing of entry titles" applies equally to my system and the current system. All of your work with the ASL phone descriptions, entry structure, categories, templates, and more has laid a great groundwork. There are still other issues to address, but this issue is really at the heart of the entire project. What are our end-user's needs for the ASL entries? Copy-paste works fine with long text, but associating words to ideas, placing a lot of links in tables, or searching for an entry you have already seen does not.
I'm not trying to say that I want to "have it my way." At the same time, I do realize that Wikimedia projects are designed to aggregate "accepted knowledge." As no one uses my new orthographic design it is proof that no group has accepted it, a.k.a championed it. I'm not trying to get involved in politics. I am trying to solve a human-software interaction issue with an encoding solution. My suggestion is not meant to supplant SignWriting, discourage the use of Unicode, or ignore other's feelings. I simply feel that the current titling system can be improved and that I have a have means to readily do so. If there are other ways to address it, I'd be happy to look into those as well. -- Positivesigner06:17, 18 April 2011 (UTC)
In reply to Prince Kassad, I don't like the idea of transcriptions as entries. See almost all the entries in Category:Egyptian nouns for example. If something's unsupported, put it in an appendix and hope that one day it becomes supported. --Mglovesfun (talk) 06:41, 18 April 2011 (UTC)
That's probably where I'm jumping the gun. msh210 stated that "the current naming system for SL page titles was enacted by vote so needs a vote to be so heavily emended." Perhaps we could start with a vote about whether the current naming system for SL needs be changed at all. If such were decided, then proposals could be made as to alternatives, timelines, etc., and each of those voted upon. -- Positivesigner07:03, 18 April 2011 (UTC)
Re Gloves, those need to be moved to hieroglyphs anyway, since we now have 'em in Unicode. Just needs someone to invest some time. -- Prince Kassad12:52, 18 April 2011 (UTC)
Positivesigner, do you acknolwedge SignWriting-in-Unicode transcription as the ultimate goal for our entry titles? If not, why does your Sign-Jotting transcription system seem better? (Perhaps because it's easier to type on a Qwerty keyboard?) If you do acknowledge SignWriting as the ultimate solution, then your proposal to change from the system in Wiktionary:About sign languages to yours seems like a temporary solution to barrier to the creation of ASL entries, right? If so, I suggest you be bold with creating ASL entries here. Feel free to create them with temporary page names, and add an {{rfc|Rename this entry per WT:ASGN}} tag at the top of your entry. Once renamed, the page should theoretically be human-assisted-bot-migratable to its ultimate SignWriting-based name. —Rod (A. Smith) 18:44, 18 April 2011 (UTC)
So could the temporary page names be "ASL000001" and sequential? That way anyone could add what they know with the renaming done by admins at a later date. I'll go with your suggestion of a temporary page name using the Rename template. Thanks for the input. -- Positivesigner21:33, 18 April 2011 (UTC)
Yes, I think (hope) most editors here would welcome your ASL entry contributions that are temporarily named like that, especially if you include {{rfc|Please rename per WT:ASGN}} at the very top of the entry. I'll try to review and rename them, but if I go MIA for awhile, anyone can drop me a line to remind me. —Rod (A. Smith) 21:59, 18 April 2011 (UTC)
Really don't like the new design for the "show/hide" buttons. It makes it harder to break up the page into sections and the buttons are less visible too. ---> Tooironic01:22, 18 April 2011 (UTC)
The ± sign isn't even showing correctly in my browser. It shows under the "]". It's just plain ugly. --Dijan01:26, 18 April 2011 (UTC)
If it is loading, it's not loading properly. The specified font sizes for Arabic and Devanagari and I'm sure various other customized scripts aren't showing properly now. --Dijan01:41, 18 April 2011 (UTC)
Please change it back ASAP! One should check for compatibility with other browsers before changing. Mozilla Firefox look-and-feel and functionality for translations is disgusting. --Anatoli01:51, 18 April 2011 (UTC)
I have doubts in the two remaining articles. They are Hanzi characters with no meaning provided in Korean and yet they are categorized as "ko:Elements". Can someone please help? Malafaya16:53, 20 April 2011 (UTC)
Yes I just removed the categorization; if the translingual mean is correct, in both cases it means oyster though it could have additional meanings. Categorization can be added back to match the meanings, if/when we have some. Mglovesfun (talk) 19:31, 20 April 2011 (UTC)
CFI, attestation and ISBN
I would like to see this CFI sentence go: "When citing a quotation from a book, please include the ISBN." Finding citations and adding them to the entry is laborious enough without ISBN. I have never included ISBN in the quotations that I add, and I am not ashamed of it. --Dan Polansky08:11, 22 April 2011 (UTC)
The ISBN is the most reliable identifier we have of one specific edition of a book. It's only useful for certain modern books, but in those cases, I have no problem with CFI saying that it should be included. I don't get the laborious part; it's just 11 digits to be added, easily found on Google Books or on the physical book.--Prosfilaes19:27, 22 April 2011 (UTC)
I agree with Prosfilaes. Incidentally, I also think the SBN should be added for older books, the ISSN for periodicals, and the DOI for anything that has one. I'd also love it if a bot could go through our entries to see where the ISBN, SBN, or ISSN does not have the right checksum, marking such instances for human attention. English Wikipedia used to have such a bot (perhaps still does), but I can't seem to find it.—msh210℠ (talk) 06:54, 24 April 2011 (UTC)
External links
Perhaps we should remove the "External links" section from WT:ELE (and possibly delete Wiktionary:External links). There's never been quite clear policy or description of practices of linking to external sites in a dictionary, except via other systems already covering the topic like WT:Citations and WT:References. In the rare cases that it might warrant inclusion, the section might not even be needed. TeleComNasSprVen04:13, 24 April 2011 (UTC)
I use ===External links=== all the time to link to Wikipedia articles related to the Wiktionary entry. I abhor the usage of {{wikipedia}} template which is IMHO too conspicuous. Simply removing "External links" section from WT:ELE and deleting ] won't fix existing usages or ===External links=== in the entries, which measure by the thousands, or change editors' preference for its usage. Without providing a plan on how to change established practice under a new policy, and how to migrate existing usages of the section under a new proposal (we cannot simply make all the entries having it non-conformant to ELE layout), I don't see how your suggestion is feasible. --Ivan Štambuk07:12, 24 April 2011 (UTC)
I use ===See also=== and {{pedialite}} and agree that {{wikipedia}} makes pages look a mess, particularly when images and table-of-contents are present. I try to look at pages occasionally with the default "look" - the one which the average user will see. —Saltmarshtalk-συζήτηση09:58, 24 April 2011 (UTC)
Saltmarsh's suggestion seems like a viable idea, using the WT:See also system to produce links to Wikipedia articles instead. Perhaps we can have a bot run to replace/change existing uses of "External links" headers to "See also", and merge the two if both are present. TeleComNasSprVen05:12, 26 April 2011 (UTC)
We may have to have a vote to remove this section after all; the first fifty or so "External links" headers I've checked contained material that were badly formatted spam links, links to website of an entry, or link to Wikipedia, any of which can be fit into "See also" or "References", as per my proposed solution above. TeleComNasSprVen10:22, 10 May 2011 (UTC)
On the das (NSFW) page, you can see there is a picture of a vagina on the bottom right corner of the page. I think the vandal edited a css page to do it, and I can't figure it out. Perhaps someone with more expertise could try and fix it. Thanks! Xxpor03:23, 25 April 2011 (UTC)
Follow up: it seems to have been removed, but could someone tell me the change they made so I can fix the same problem in the future? Xxpor03:25, 25 April 2011 (UTC)
Yes, the user is Meepsheep (talk • contribs) using various meepsheep related user names, see the history of {{defdate}}. To administrators, block anyone with an expiry time of indefinite if they match these two criteria (the first criterion being blatant vandalism). Mglovesfun (talk) 21:37, 25 April 2011 (UTC)
Also of interest, if you go to the top of the Beer parlour page, enter "well-known work", and press "search in the archives of Beer parlour", you get these search results. I should have used this link before and look more carefully, as I would have found this:
Support for conveniency. The unspoken (or spoken) rule of "Let's type noun forms everywhere, except when the only noun form of a language is the plural, then we'll type plurals!" results in having two category trees for the same scope. Moreover, a category named "Category:English plurals" is very likely to be interpreted as a good place to have entries defined as plurals of verbs and of pronouns too, listed together, and (AFAICT) no one wants that. --Daniel.15:10, 30 April 2011 (UTC)
I oppose using only Category:<language> noun forms
Oppose. There's no reason that different languages should do this the same way. Both Category:Plurals by language and Category:Noun forms by language should be deleted as meaningless, since the terms "plural" and "noun form" both apply differently to different languages. ("Noun form", especially, means "noun form that isn't the lemma" — but we use different lemmata for different languages. Latin accusatives and Old French nominatives do not have anything interesting in common.) —RuakhTALK14:57, 30 April 2011 (UTC)
Latin accusatives and Old French nominatives do have something in common! They are nouns, and they are not lemmas (I suppose). I find that pretty interesting. If you are looking for closer linguistic comparisons, I'm open to suggestions regarding floods of well-explained and strict categories like "Category:French noun nominative forms", which is akin to "Category:Spanish verb imperative forms"; however, "Category:French nominatives" or "Category:Spanish imperatives" would be bad names to me. --Daniel.11:07, 1 May 2011 (UTC)
Oppose. AFAICT there is no good reason to reduce the amount of information conveyed to normal English users by the name Category:English plurals. Trying to achieve translingual consistency in the category structure seems foolish and linguistically naive or tendentious. DCDuringTALK16:13, 30 April 2011 (UTC)
As mentioned by me above, the name "Category:English plurals" is actually of poor linguistic value, either by possibly alowing too many unrelated words such as "we" (a first-person plural personal pronoun), "understand" (the lemma of a verb, that technically can be used as a plural too), "beautiful" (the lemma of an adjective, with the same technicality), "dogs" (a plural of a common noun) and "Bermuda shorts" (a plurale tantum) together, or by don't conveying clearly the fact that it is supposed to contain only non-lemma plurals of common nouns. I don't remember mentioning before that a category named "Category:English plurals" may contain pluralia tantum, but it's true as well. --Daniel.21:41, 30 April 2011 (UTC)
@Daniel.: I believe you are mistaken. In my opinion: "We" is plural, but is not "a" plural. "Understand" and "beautiful" are neither plural nor plurals. "Dogs" is plural, and is a plural (the plural of "dog"). "Bermuda shorts" is plural, and I could go either way on whether it's a plural. (google books:"inherent plurals" finds some instances referring to pluralia tantum, so some people clearly feel it's O.K.) —RuakhTALK23:28, 30 April 2011 (UTC)
I am not convinced, so I took a look at some relevant pages: The entry plural is generic enough to support my explanation of what a "plural" is. Moreover, Wiktionary's descriptive approach makes it easy to attest nuances of it by finding sources that agree with the idea I described. For example, the page 32 of this book contains "There are words that some doctors use when talking to patients — curious words such as 'pop' as in 'pop up on the couch', or plurals such as 'we' in 'We'll just have a look at you'." --Daniel.11:07, 1 May 2011 (UTC)
This is a pretty strong claim! Can you (or anyone else) please mention one language that won't fit the category tree of "Category:<language> noun forms" and another language that won't fit the category tree of "Category:<language> plurals"? --Daniel.11:07, 1 May 2011 (UTC)
Not sure what you mean by "category tree" here. The categories "Hebrew plural forms" and "English plural forms" are not parallel, as the former should have a plural-noun-form, a plural-adjective-form, and a plural-pronoun subcategory, whereas the latter should have a plural-noun and a plural-pronoun subcategory. But for another language, say one that has plural noun forms but no other plural forms, it is kind of silly to have a plural-form category just to hold the plural-noun-form category. (Otoh, that hypothetical language's plural-noun-form category should be in the plural-forms-by-language category so it can be found.) I don't know enough languages to name such a language.—msh210℠ on a public computer14:10, 1 May 2011 (UTC)
I am hesitatant, so I cannot say that I support. I support this: "For each language, if the language has plural forms for several parts of speech such as for nouns and adjectives, there should be no ]. In Czech, nouns, adjectives, and verbs have plurals, and it seems pointless to list all plurals in one category. There could be languages for which getting rid of the category for plurals would cause trouble, but is this merely hypothetical? I don't know. --Dan Polansky09:44, 2 May 2011 (UTC)
Agree Daniel. 10:12, 6 April 2011 (UTC)
Oppose. There's no reason that different languages should do this the same way. Both Category:Plurals by language and Category:Noun forms by language should be deleted as meaningless, since the terms "plural" and "noun form" both apply differently to different languages. ("Noun form", especially, means "noun form that isn't the lemma" — but we use different lemmata for different languages. Latin accusatives and Old French nominatives do not have anything interesting in common.) —RuakhTALK 14:57, 30 April 2011 (UTC)
