Wiktionary:Beer parlour/2011/April

Definition from Wiktionary, the free dictionary
Jump to: navigation, search
This is an archive page that has been kept for historical purposes. The conversations on this page are no longer live.

April 2011

Sorting topical categories

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 Kassad 07: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 rand 08:11, 1 April 2011 (UTC)
Uh, and how does this solve the problem? -- Prince Kassad 08:12, 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 rand 08: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 Kassad 08: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 Polansky 09: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 Kassad 09:05, 1 April 2011 (UTC)
Dan Polansky's idea is good in essence, yet I too disagree with replacing a complete list with an incomplete list; Category:ase:Colors is not linked from Category:Colors, among countless other examples. --Daniel. 09:12, 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 Polansky 09: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 rand 09: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. —CodeCat 09: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.

-- Prince Kassad 09:59, 1 April 2011 (UTC)

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 rand 10:04, 1 April 2011 (UTC)
Awful suggestion. I would leave the project. SemperBlotto 10:06, 1 April 2011 (UTC)
I certainly oppose the suggestion.
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)
I had a similar idea a while ago, but my idea was to use subpages: der/sv. —CodeCat 11:21, 1 April 2011 (UTC)
How is typing [Language]:[term] more convenient than typing [term]#[Language]? 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., 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 Buchmeier 13: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. —CodeCat 14: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 Buchmeier 15: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). Lmaltier 18: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.--Prosfilaes 19: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. Lmaltier 20: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 :) --Waldir 00: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:

  1. Links could be guessed without visiting the page
  2. 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")
  3. Categorization would be much more consistent (take a look at the categories in the "do" page!)

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.

So... what do you think? --Waldir 18:31, 6 May 2011 (UTC)

It's been suggested before: See WT:BP#Restructuration of foreign languages. --Yair rand 08:38, 8 May 2011 (UTC)
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.
I'll move this thread to the one you linked to, so the discussion can be centralized. --Waldir 00:17, 10 May 2011 (UTC)

Categories in etymology chains

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. —CodeCat 15: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. —CodeCat 12: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.

--Daniel. 02:04, 2 April 2011 (UTC)

Move Romanian entries with cedillas

I've started moving Romanian entries with cedillas to new names with commas according to community decision (Wiktionary:Votes/pl-2011-02/Romanian orthographic norms). I applied for the bot flag (Wiktionary:Votes/bt-2011-04/User:Flubot for bot status) and the tools I'm going to use are here. If there are any comments by anyone I'd be happy to listen to them on WT:GP#Move Romanian entries. --flyax 07:35, 3 April 2011 (UTC)

Serbo-Croatian edits

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) SemperBlotto 10: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)
Just undo or mark with {{attention|sh}} if there was a genuine content modification (i.e. something other than removal or multiplication). --Ivan Štambuk 14:46, 3 April 2011 (UTC)
Agree with msh210 on this. Mglovesfun (talk) 15:36, 4 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. Lmaltier 17: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 Štambuk 22:34, 4 April 2011 (UTC)
More Lmaltier idealism that shouldn't be applied to the real world. Mglovesfun (talk) 23:28, 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. Lmaltier 05: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. --Anatoli 06: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. --Anatoli 08: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 Štambuk 08: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". --Anatoli 08: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. —RuakhTALK 18: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. —CodeCat 10: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. --Anatoli 12: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. Lmaltier 17:03, 5 April 2011 (UTC)
Wiktionary:About Serbo-Croatian is being changed, I can sense some smoke already... --Anatoli 12:34, 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 Štambuk 14: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 (DiscCont) 04:10, 6 April 2011 (UTC)
Again, I don't think there is a neutral stance on this issue apart from "not touching it". Mglovesfun (talk) 09:51, 7 April 2011 (UTC)

How to grow faster

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? --LA2 02: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. --Anatoli 05: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). SemperBlotto 07:08, 4 April 2011 (UTC)

language/family conflict

We have both Category:Egyptian language and Category:Egyptian languages. One category is of a language, other is of a family.

What other languages share its name with a family? --Daniel. 08:25, 5 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 Kassad 08: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. - TheDaveRoss 10:34, 5 April 2011 (UTC)
We have, however, Category:Sinitic languages, which is an exact synonym of "Category:Chinese languages" with a name that doesn't conflict with the Chinese language. Whether we should have a Category:Chinese language is subject of a separate controversy. --Daniel. 05:10, 7 April 2011 (UTC)
There's also {{etyl:hyx}} and {{etyl:euq}}, I guess. -- Prince Kassad 12:59, 5 April 2011 (UTC)
Thankfully the codes hyx (Armenian family) and euq (Basque family) aren't used, so they don't cause conflicts with languages! On the other hand... That makes our coverage of categories of families is technically incomplete; Category:Armenian languages may hypothetically be created eventually to contain Category:Armenian language and Category:Old Armenian language. --Daniel. 08:53, 6 April 2011 (UTC)
Don't forget Category:Middle Armenian language. I would have created that category long ago, if it weren't for that conflict. -- Prince Kassad 09:51, 6 April 2011 (UTC)
Addendum: maybe we could coin a protologism to solve that problem? -- Prince Kassad 20:35, 7 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 Kassad 20: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)
Examples are abundant. For example, when Greenberg reformed the classification of African languages, he coined the new terms Afro-Asiatic (replacing the older term Hamito-Semitic), Niger-Kordofanian, Nilo-Saharan and Khoisan, among many others. Most of these are still used today. -- Prince Kassad 21:01, 7 April 2011 (UTC)
addendum: I just created Category:Vasconic languages since, like I said, that name is already established. -- Prince Kassad 08:58, 8 April 2011 (UTC)

There's also {{etyl:sqj}}, which also has a potential for conflicts. What to do with this one? -- Prince Kassad 12:24, 10 April 2011 (UTC)

Simplification of brand names rules

The title is the 10% inspiration. You are to provide the 90% perspiration. Here's a starting point: Wiktionary:Votes/pl-2011-04/Commercial terms. DAVilla 08:42, 6 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 Polansky 09: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 Polansky 09: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. DAVilla 09: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 Polansky 09:53, 6 April 2011 (UTC)

Some companies should have dedicated sense lines in some entries.

  1. Symbol support vote.svg Agree Daniel. 10:12, 6 April 2011 (UTC)
  2. Symbol support vote.svg Support --Yair rand 10:22, 6 April 2011 (UTC)
  3. Symbol support vote.svg Support --Anatoli 10:40, 6 April 2011 (UTC)
  4. Symbol support vote.svg 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 Polansky 18:16, 6 April 2011 (UTC)
  5. Symbol support vote.svg Agree. In particular, those that are single words (or acronyms). SemperBlotto 18:58, 6 April 2011 (UTC)
  6. Symbol support vote.svg Agree Ivan Štambuk 06:11, 7 April 2011 (UTC)
  7. Symbol support vote.svg Agree. --Vahag 11:22, 7 April 2011 (UTC)

No company should have a dedicated sense line in any entry.

  1. 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)
  2. Symbol support vote.svg 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.) —RuakhTALK 18: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 Polansky 18: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. —RuakhTALK 19: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 "[Do you agree that ...] 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 Polansky 07: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". —RuakhTALK 12: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)
  3. -- Prince Kassad 09:04, 7 April 2011 (UTC)
  4. Symbol support vote.svg Support - -sche (discuss) 22:22, 6 April 2011 (UTC)
  5. Symbol support vote.svg Agree DCDuring TALK 00:51, 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. Lmaltier 17:08, 6 April 2011 (UTC)
See my comment under #Serbo-Croatian edits, before I get told off again. Mglovesfun (talk) 17:11, 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 Polansky 18: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. Lmaltier 20: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 Polansky 08: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)
Asking the right questions makes answers much easier. Lmaltier 20:23, 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. Lmaltier 20: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 rand 21: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. Lmaltier 05: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? —RuakhTALK 12: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. Lmaltier 17:59, 7 April 2011 (UTC)

Edit definition gadget

Can someone please undo the "Edit definition" thing that appears at each definition? --Dan Polansky 08:28, 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 rand 08: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 Polansky 08:41, 7 April 2011 (UTC)
There is a button to disable it in the WT:BP#Tabbed Languages, Definition side boxes, and Sense IDs section. --Yair rand 08:44, 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 Polansky 08: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 rand 09: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 [edit] 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)
Okay, I've made the change. --Yair rand 09:45, 7 April 2011 (UTC)
Thanks. --Daniel. 09:54, 7 April 2011 (UTC)
wiktprob.png

I disabled the script because of the problem seen to the right. -- Prince Kassad 12:56, 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 Štambuk 17:19, 7 April 2011 (UTC)
I've fixed the bug and re-enabled the tool. --Yair rand 17:39, 7 April 2011 (UTC)
This edit summary seems to be correct.​—msh210 (talk) 17:50, 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. DCDuring TALK 18: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. —RuakhTALK 18: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. DCDuring TALK 19: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 rand 02: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. DCDuring TALK 04: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 rand 04: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. DCDuring TALK 04: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 rand 08: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.
Re: "..., which the overwhelming majority of the community disagrees with": Any evidence please? --Dan Polansky 10:03, 8 April 2011 (UTC)
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 Štambuk 07: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 rand 08: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. DCDuring TALK 13: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 rand 18: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 Polansky 10: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 rand 10: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 Polansky 11: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 rand 11: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 Polansky 11: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 rand 11: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 Polansky 12: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 rand 13: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 Polansky 14:28, 12 April 2011 (UTC)
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 rand 10: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 Polansky 11: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)

Hm? It already is optional, this is about whether it should be on by default. --on the pseudo-home page of the project 13:20, 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? —RuakhTALK 14: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 rand 15: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 Polansky 15:30, 12 April 2011 (UTC)

Wiktionary:Votes/2011-04/Lexical categories

The vote Wiktionary:Votes/2011-04/Lexical categories is scheduled to start in 3 days, after a number of tweaks by multiple editors, and postponings. Feel free to double-check the set of categories to be affected by this vote before it starts. --Daniel. 09:27, 7 April 2011 (UTC)

The glossary and language codes

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)

Yeah support and add to internal links, or see also, or whatever, links to such appendices/WT pages. The page could do with a spring clean. Mglovesfun (talk) 14:00, 7 April 2011 (UTC)
yup, support. -- Prince Kassad 14:03, 7 April 2011 (UTC)
Yeah.​—msh210 (talk) 16:25, 7 April 2011 (UTC)

Palindromes by language

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:

Thoughts? --Daniel. 14:14, 7 April 2011 (UTC)

Actually it's already been at RFC and RFM (in that order) with no input. Support. Mglovesfun (talk) 14:17, 7 April 2011 (UTC)
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)
Sure, Appendix:Palindromes can link to Appendix:Portuguese palindromes, Appendix:English palindromes, etc. However, a Category:Appendices of palindromes would do the same job unless I'm missing something, so the appendix of the list of links probably would be unnecessary. --Daniel. 16:41, 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)

Poll: Playing cards

There are certain terms defined as playing cards, including queen of spades, ace of spades and queen of diamonds. Simultaneously, certain names of playing cards are actually redlinks, including two of spades, two of diamonds and ten of hearts.

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.

A more-or-less recent RFD discussion listed and deleted a number of them. However, it didn't list them all and didn't delete them all. Another, slightly less recent RFD discussion kept ace of hearts in the end. There are opposing arguments.

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?

Thank you. --Daniel. 18:06, 7 April 2011 (UTC) Edited for legibility.​—msh210 (talk) 19:39, 7 April 2011 (UTC)

All of them

  1. Symbol support vote.svg Agree Daniel. 18:06, 7 April 2011 (UTC)
  2. Symbol support vote.svg Agree. No really, I do. Mglovesfun (talk) 18:19, 7 April 2011 (UTC)
    Clarification, because of Talk:ace of diamonds. Sets a precedent which has not yet been overturned. Mglovesfun (talk) 13:06, 11 April 2011 (UTC)
  3. Symbol support vote.svg Agree. --Anatoli 22:09, 7 April 2011 (UTC)
  4. Symbol support vote.svg Agree WurdSnatcher 02:44, 8 April 2011 (UTC)
  5. Symbol support vote.svg Agree Ivan Štambuk 07:14, 10 April 2011 (UTC)

None of them

  1. 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)
  2. Symbol support vote.svg Agree -- Prince Kassad 20:11, 7 April 2011 (UTC)
  3. Symbol support vote.svg Agree Ƿidsiþ 21:18, 7 April 2011 (UTC) per Msh210
  4. Symbol support vote.svg Agree with msh210 (and presumably Ƿidsiþ). —RuakhTALK 21:34, 7 April 2011 (UTC)

Some of them

  1. Symbol support vote.svg Agree per Msh210. ~ heyzeuss 07:07, 8 April 2011 (UTC)

The current sixteen

  1. Symbol support vote.svg Agree DCDuring TALK 18:14, 7 April 2011 (UTC)
    What are the "current twelve"? Currently, we have sixteen bluelinked.​—msh210 (talk) 19:56, 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)
  2. Symbol support vote.svg Agree? DAVilla 08:55, 17 April 2011 (UTC)

I am indifferent or indecisive

  1. Symbol support vote.svg Agree: I don't know. --Dan Polansky 11:14, 8 April 2011 (UTC)

(Discussion)

  • 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 Polansky 11: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? --Anatoli 06: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?

RuakhTALK 20:31, 7 April 2011 (UTC)

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 . . .) —RuakhTALK 21: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. DCDuring TALK 04: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. —RuakhTALK 14: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 Polansky 10: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 Polansky 17: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". DCDuring TALK 18: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. Lmaltier 20: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. ~ heyzeuss 06:55, 8 April 2011 (UTC)

Where would the headword-line wikitext come from? --Yair rand 07:05, 8 April 2011 (UTC)
'''{{subst:PAGENAME}}'''?​—msh210 (talk) 08:29, 8 April 2011 (UTC)
But then the entry would be uncategorized. --Yair rand 08:30, 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)
Good point. I've made User:Yair rand/transnewentry.js, which pulls the POS header from the English and uses {{infl}} as the default headword-line. --Yair rand 09:45, 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. ~ heyzeuss 11: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? --flyax 09: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:
--Daniel. 10:17, 10 April 2011 (UTC)
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. --flyax 10:42, 10 April 2011 (UTC)
I like flyax's idea better than Daniel.'s; Category:English is simple, does not proliferate categories, and allows things Category:English terms spelled with A, Category:English terms spelled with B etc would not. On de.Wikt, users have used it to add translations systematically to every page. - -sche (discuss) 04:22, 15 April 2011 (UTC)
In theory, both Category:English and Category:English terms spelled with B can exist simultaneously as they serve different purposes. However, the usefulness of the latter is obscure, because B is a extremely common letter in English. --Daniel. 04:27, 15 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 :

python replace.py -fix:ro-something -cat:'English something'

You see, it will be much easier for the bot to run in just one category that would contain all English words. --flyax 11: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)
That's interesting. I've never tried using AWB so far. Thanks for the tip--flyax 13:11, 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. --flyax 14:22, 11 April 2011 (UTC)

Wiktionary:About Latin#Orthography for Latin entries

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)

You should possibly ask EncycloPetey (talkcontribs) (perhaps on Wikipedia [1], since he seems to be more active there now), considering the fact that he has written most of WT:ALA. Caladon 10:51, 12 April 2011 (UTC)
I was hoping for a consensus, so no. Mglovesfun (talk) 13:57, 12 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 (talkcontribs) at 14:10, 12 April 2011 (UTC).
These are the modern rules for spelling Latin, which is a good orthography to normalize to.--Prosfilaes 15:20, 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.--Prosfilaes 17: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 the question then is which one we treat as the 'main' lemma... —CodeCat 16:07, 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)
This is a wiki, I'm gonna make some changes and y'all are free to change those changes. Mglovesfun (talk) 12:17, 16 April 2011 (UTC)

Wikisaurus def subpages

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 [[Wikisaurus:entry]]". 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 Polansky 13: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 Polansky 14:54, 11 April 2011 (UTC)
I agree with all of this. Mglovesfun (talk) 14:55, 11 April 2011 (UTC)

Update: I have removed all remaining uses of {{ws refer}} from the mainspace (there were around 50 AFAIR) and have sent the template for deletion, together with the slash-def subpages: Wiktionary:Requests_for_deletion/Others#Template:ws_refer. --Dan Polansky 17:42, 19 April 2011 (UTC)

WOTD

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)

  • Are you volunteering? SemperBlotto 07:24, 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 [[WT:WOTDN#statusboxofwotdupdates]]. 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)

ASL Orthography

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. - Positivesigner 08: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 Kassad 09: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. - TheDaveRoss 10:23, 14 April 2011 (UTC)
Why would you exclude sign languages from the mainspace? Isn't that a bit racist? -- Prince Kassad 13:17, 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. - TheDaveRoss 19: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. —RuakhTALK 21: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. - TheDaveRoss 21: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? —RuakhTALK 21: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. - TheDaveRoss 23: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)
See this. If this turns out to be mature, we may soon see SignWriting in Unicode. -- Prince Kassad 02:19, 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. —RuakhTALK 00: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. - TheDaveRoss 01:52, 15 April 2011 (UTC)
[Indented under Ruakh, as it sort of is in response to what he said; but the question at the end is more for TDR.] 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 some entries of the sort. Why are SLs less worthy?​—msh210 (talk) 03:17, 15 April 2011 (UTC)
On the subject of inelegant things, the language name "Proto-Central New South Wales". On the subject at hand, perhaps Positivesigner can enter words as user subpages or an appendix? To msh210: do the speakers of PCNSW or Darling communicate in writing in another language, the way ASL-signers write in English? - -sche (discuss) 06:37, 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. - Positivesigner 06: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)
So is Jurchen or Minoan. Did that stop us from having entries in these languages? -- Prince Kassad 12:54, 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)

I agree with Rod's analysis and conclusion. - -sche (discuss) 03:11, 18 April 2011 (UTC)
Out of curiosity — on what sort of timescale are we expecting SignWriting Unicode codepoint assignments to be approved? How confident are we that it will happen, and how much do we know about what it will be like? When that happens, will it be possible for a bot to effect the conversion from the "Claw5@TipFinger-Claw5@CenterChesthigh Claw5@SideChesthigh-Claw5@SideChesthigh" style to SignWriting? —RuakhTALK 02:14, 18 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 Kassad 12: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. -- Positivesigner 06: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. -- Positivesigner 07: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 Kassad 12: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. -- Positivesigner 21: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)

Romanian entrees

Are entrees like școală also being fixed internally? If you open the conjugation table you'll still see the cedilla forms. --Ooswesthoesbes 18:32, 17 April 2011 (UTC)

Fixed. The plural form used the old cedilla form. --Dijan 01:42, 18 April 2011 (UTC)

new "show/hide" design

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. ---> Tooironic 01:22, 18 April 2011 (UTC)

The ± sign isn't even showing correctly in my browser. It shows under the "]". It's just plain ugly. --Dijan 01:26, 18 April 2011 (UTC)
Is common.css even being loaded? Maybe it's some issue with Mediawiki? --Yair rand 01:35, 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. --Dijan 01:41, 18 April 2011 (UTC)
Thanks. --Dijan 01:47, 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. --Anatoli 01:51, 18 April 2011 (UTC)
I agree. --Dijan 01:53, 18 April 2011 (UTC)
A recent edit to common.css had a typo in it, which broke the CSS. I fixed the typo a few minutes ago. --Yair rand 01:54, 18 April 2011 (UTC)
Thanks for the fix! --Anatoli 06:30, 18 April 2011 (UTC)

Category:ko:Elements

Why is there the different category Category:ko:Elements? I believe all pages in this category should be moved to Category:ko:Chemical elements. Right? Malafaya 16:43, 20 April 2011 (UTC)

You're correct, that category should not exist. -- Prince Kassad 16:45, 20 April 2011 (UTC)
Based on the interwikis, no, empty and delete (speedy, that is). Mglovesfun (talk) 16:47, 20 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? Malafaya 16: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 Polansky 08: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.--Prosfilaes 19: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. TeleComNasSprVen 04: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 [[Wiktionary:External links]] 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 Štambuk 07: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. TeleComNasSprVen 05: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. TeleComNasSprVen 10:22, 10 May 2011 (UTC)

multi-word entries

I was just putting a Greek translation in "give rise to" - so we have "führen zu", "οδηγώ σε" etc - are we wanting all these multi-word foreign entries? Would "führen zu", "οδηγώ σε" be better? —Saltmarshtalk-συζήτηση 06:45, 24 April 2011 (UTC)

Need help with removing vandalism, pic of vagina

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! Xxpor 03: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? Xxpor 03:25, 25 April 2011 (UTC)
I have absolutely no idea what's going on. See the WT:ID, where two people have complained of this. —Internoob (DiscCont) 03:51, 25 April 2011 (UTC)
What browser are you using? Is there anything in your browser's downloads? —Internoob (DiscCont) 03:54, 25 April 2011 (UTC)
It was Template:langnamex. Problem solved. —Internoob (DiscCont) 04:54, 25 April 2011 (UTC)
The same vandal also hit Wikiversity. - -sche (discuss) 19:17, 25 April 2011 (UTC)
Yes, the user is Meepsheep (talkcontribs) 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)

Vote on removing usage in a well-known work

I have created a vote: Wiktionary:Votes/pl-2011-04/CFI: Removing usage in a well-known work. I don't know how it turns out; let us see. --Dan Polansky 14:57, 25 April 2011 (UTC)

Where's the prior discussion? DCDuring TALK 20:33, 25 April 2011 (UTC)
I share DCDuring's question. However, I know this has been discussed some before; it's just a question of finding the discussions. - -sche (discuss) 20:49, 25 April 2011 (UTC)
Yes and I said I'd opposite it in that aforementioned discussion. Mglovesfun (talk) 21:30, 25 April 2011 (UTC)
I have linked to a previous discussion from the vote when I have created the vote, as is customary. A link to the discussion, anyway: Beer parlour: CFI: Removing usage in a well-known work, January 2011.
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:
--Dan Polansky 09:23, 26 April 2011 (UTC)

Quick poll: plurals to noun forms

We currently have a mix of [[Category:<language> plurals]] and [[Category:<language> noun forms]]. A couple of languages use both - most notably Catalan which double categorizes plurals as plurals and noun forms. This is a quick poll to ask whether we should eliminated the contents of Category:Plurals by language all together and replace with Category:Noun forms by language, that is to say, [[Category:<language> noun forms]]. Mglovesfun (talk) 14:07, 30 April 2011 (UTC)

I support using only Category:<language> noun forms

  1. Symbol support vote.svg Support for consistency. It's a real mess currently as every language uses a different system. -- Prince Kassad 14:24, 30 April 2011 (UTC)
  2. Symbol support vote.svg Support for the same reason. —CodeCat 14:28, 30 April 2011 (UTC)
  3. Symbol support vote.svg 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)
    @Daniel., yes, we already have some proper noun plurals in Category:English plurals. Mglovesfun (talk) 16:20, 30 April 2011 (UTC)

I oppose using only Category:<language> noun forms

  1. Symbol oppose vote.svg 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)
    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)
  2. Symbol oppose vote.svg 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. DCDuring TALK 16:13, 30 April 2011 (UTC)
    Well (perhaps this merits a separate section below), do you think all plurals should be in Category:Plurals? For example, we do have plurals of proper nouns. For example, Jameses. Mglovesfun (talk) 21:32, 30 April 2011 (UTC)
    But what about plurals of adjectives? —CodeCat 21:37, 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)
    My question was to DCDuring, and I was thinking specifically about English plurals as that's what he's mentioned. Mglovesfun (talk) 21:49, 30 April 2011 (UTC)
    I knew that your question was to DCDuring, thanks to indentation. I, personally, would oppose the suggestion of leaving all plurals in Category:Plurals for fear of having either Category:es:Plurals, Category:pt:Plurals, etc. or unnecessary inconsistency between languages. --Daniel. 22:06, 30 April 2011 (UTC)
    Damn, did I write that? I meant Category:English plurals. Mea culpa. Mglovesfun (talk) 22:33, 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.) —RuakhTALK 23: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)
  3. Neither alone will work for all languages.​—msh210 (talk) 04:19, 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 computer 14:10, 1 May 2011 (UTC)
  4. 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 [[:Category:<language> plurals]]. 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 Polansky 09:44, 2 May 2011 (UTC)

Related discussions