Wiktionary

Wiktionary:Beer parlour/2010/March

< Wiktionary:Beer parlour
(Redirected from Wiktionary:Beer parlour archive/2010/March)
This is an archive page that has been kept for historical purposes. The conversations on this page are no longer live.
Beer parlour archives edit
2024
2023
Earlier years
2022
2021
2020
2019
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
2007
2006
2005
2004
2003
2002
December


March 2010

Prepositional phrase or phrasal preposition

As the category naming scheme, please decide between prepositional phrases (and adverbial phrases, etc.) or phrasal prepositions (and phrasal verbs, etc.) This decision may be made as a quick vote. Then I may continue my work on templatizing categories. The final result will be the whole set of related categories named either as "Category:English phrasal prepositions" or "Category:English prepositional phrases". Thanks in advance. --Daniel. 07:59, 1 March 2010 (UTC)[reply]

I think that prepositional phrases is the better choice. --Daniel. 07:59, 1 March 2010 (UTC)[reply]
Prepositional phrases was decided to be the standard POS header in Wiktionary:Votes/pl-2010-01/Allow "Prepositional phrase" as a POS header, so I don't think having "phrasal prepositions" (as a header or as a category) is really an option. Related POSs are still up for debate somewhat, but I don't think anyone would support having parts of speech that don't fit the pattern. --Yair rand 08:23, 1 March 2010 (UTC)[reply]
Both. The terms are not synonymous at all. A prepositional phrase is a preposition plus its complement (such as "alongside them" or "after the end of the war"), whereas a phrasal preposition is a multi-word preposition (such as "due to" or "in front of"). A verb phrase is a verb plus any complements and modifiers (such as "go shopping for boots when I have a chance"), whereas a phrasal verb is a multi-word verb (such as "keep up" or "hand over"). Note that not all linguistic approaches use all these terms; in particular, phrasal prepositions and phrasal verbs are both somewhat controversial. —RuakhTALK 14:34, 1 March 2010 (UTC)[reply]
Right: they're different. That doesn't, of course, imply we should have both. We've been listing phrasal Xes as just Xes, and I don't see any compelling reason to change to "phrasal X". (Now that "prepositional phrase" is usable, though, we'll be listing as that some things that we've hitherto called adverbs, and I guess adjectives.)​—msh210℠ 16:22, 1 March 2010 (UTC)[reply]
I think you're conflating two separate things: categories are not the same as POS headers. We have had both Category:English phrasal verbs and Category:English prepositional phrases for a long time, even though neither ===Phrasal verb=== nor ===Prepositional phrase=== was an accepted POS header. Now, I don't think that Category:English verb phrases, specifically, is at all worth having; but the question was about the category naming scheme overall, and for that, we want both types. —RuakhTALK 16:51, 1 March 2010 (UTC)[reply]
Correct, I was conflating two things, a result of my not reading the OP well enough. Sorry. Yes, I agree with Ruakh.​—msh210℠ 16:56, 1 March 2010 (UTC)[reply]

Understood. I've started to templatize the discussed categories. Thank you for the information. --Daniel. 01:48, 6 March 2010 (UTC)[reply]

If we already systematically shove multi-word nouns and adverbs into the same category as single-word one, what sort of justification can be made for separation preposition on that ground? Circeus 03:44, 8 March 2010 (UTC)[reply]
Many English prepositional phrases behave as both adverbs and adjectives (at least after forms of "is"). They do not commonly behave fully as adjectives (gradable, modifiable by "very" or "too", correct after "become"). The adjective and adverb senses of prepositional phrases usually have a great deal of duplication of meaning. Items in Category:English phrases include a wide variety of grammatical phrase, clause, and sentence types, as well as non-constituents (not truly "phrases", consisting of elements that are grammatically part of different phrases or do not make up a complete grammatical unit). Prepositional phrases are a relatively homogeneous group that is at present larger than any of the categories of phrases. DCDuring TALK 04:30, 8 March 2010 (UTC)[reply]

Top category for all English categories?

I can't find a "top" category that contains all the English categories. What does everyone think of "Category:English" or "Category:English categories" to contain all the top level categories from "Category:English abstract nouns" through to "Category:English words..."? Facts707 09:00, 1 March 2010 (UTC)[reply]

They *should" all eventually feed into Category:English language. Mglovesfun (talk) 09:05, 1 March 2010 (UTC)[reply]

Vote on the inclusion of particular individuals

I have created vote Wiktionary:Votes/pl-2010-03/Including particular individuals.

The vote starts in seven days to provide enough time for discussion before the vote.

The vote is planned to last approximately a month, as it is a policy vote rather than an executive vote on a minor action. --Dan Polansky 14:05, 1 March 2010 (UTC)[reply]

One thing this doesn't deal with is what should be in the definition line. For example, Snoopy currently says "1. Charlie Brown's pet beagle in the comic strip Peanuts, by Charles M. Schulz.", which while correct is uninformative; it does not help the reader to understand the citations, for example: "Mary Mann, another sophomore, sits on the roof of a red dog house, giving her most enigmatic Snoopy look". It seems to me that the citable attributes of a character must be present in the definition in some form. Also including Snoopy implies that this shouldn't be restricted to "human" individuals. Conrad.Irwin 14:54, 1 March 2010 (UTC)[reply]
It seems hard enough to get the proposal discussed and passed when it focuses only on the inclusion criteria, without at the same time delving into the question of how exactly the particular sense lines should look. The proposal is meant to prevent the RFV process from deleting the sense lines, while leaving it to the common sense of Wiktionary editors to write good sense lines of dictionary entries meant to help in decoding various uses of the names of the individuals, including figurative uses.
Snoopy is included by the attributive use rule, which the proposal does not modify. --Dan Polansky 08:54, 3 March 2010 (UTC)[reply]
Why are we going to become a short-attention-span encyclopedia? Because we are afraid of failing as a dictionary? Because Wikipedia isn't providing encyclopedic coverage of enough individuals.
What about the extremely radical consequences of no longer covering "entities" and instead covering "individuals". (deprecated template usage) Individuals is normally taken to mean "individual people". The proposal seems to have the effect of providing no treatment whatsoever of other entities that bear proper names. DCDuring TALK 15:33, 3 March 2010 (UTC)[reply]
Re "Why are we going to become a short-attention-span encyclopedia?" We are not going to become a short-attention-span encyclopedia or an encyclopedia with very short encyclopedic articles. Only two narrow sets of individuals are proposed for inclusion, one set of those who are included anyway in adjectives, the other set of those who are invoked figuratively, as "the Pericles of the Italian Renaissance". The proposal makes no plan or allowance for including a sense line for every notable human individual, unlike an encyclopedia or a dictionary of biography. Whether Wiktionary is failing as a general dictionary or not, that is irrelevant to the acceptability of the proposal: the inclusion of particular individuals has nothing to do with the quality, correctness and completeness our entries.
The term "entity" ambiguously refers to both classes and individuals, and so does "specific entity", which I tend to read as "a narrow class of individuals". The distinction between an individual and a class seems thus better captured in the term "individual" than in the term "entity". The term "individual" can refer not only to a human individual but to any individual referred to with a definite or indefinite article, so "the cat over there" refers to an individual, as does "a green car" and "the number three". For the case the meaning of "individual" were not clear, the proposal clarifies in the following: "a particular individual—including people and places". --Dan Polansky 17:20, 3 March 2010 (UTC)[reply]
  1. As we cannot be assumed to be now and forever a community of philosophers the use of the term individual where entity has been used is not appropriate. In contrast "entity" draws attention to the notion that there is no specific limit on the the types of individual entities covered in a way that "individual" does not in the discourse of normal English-speaking human beings. I will not be the only person to make the interpretation I made.
  2. Unless the enumeration of specific types of individuals is complete, it can easily be taken to limit the types of individuals to those specifically mentioned. That is a common entailment of an enumeration in speech or text. DCDuring TALK 18:09, 3 March 2010 (UTC)[reply]
You have marked the sense "An object, be it a thing or an agent, as contrasted to a class" in Wiktionary's individual with the context tag for philosophy, but that seem unjustified. This sense is not constrained to philosophy. Check “individual”, in OneLook Dictionary Search., including Merriam and Webster online[1], Encarta[2], and Cambridge Advanced Learner's Dictionary[3]. --Dan Polansky 16:35, 4 March 2010 (UTC)[reply]
I'm all in favor of the figurative addition, but question the "origin of an adjective" idea for two reason. Firstly, what's special about adjectives? Should we include Rick Astley because it's the origin of the verb rickroll, or John McCain because of the common noun McCainiac, or Galen of Pergamum because of the adverb Galenically? Secondly, why include entities separately as the adjectival sense line should already contain sufficient information about the originating individual for understanding? This lexically piece-meal approach to inclusion of entities will confuse our viewers (I still don't know which proper nouns MW includes). Better to have a more obvious delineation and point users to other resources when appropriate. --Bequw → τ 17:25, 4 March 2010 (UTC)[reply]
I find it odd or incongruent to include information about the ancient Greek Socrates only under "Socratic" and not under "Socrates". I admit that the sense-line for the ancient Greek Socrates in "Socrates" is not needed for perusing the entry "Socratic"; the entry "Socratic" should better be stand-alone anyway.
You are right that the rule could be based not only on adjectives but also on verbs and other parts of speech. But I don't find the other parts of speech so compelling; and it would broaden the rule, making it less likely to be accepted. The task of exploring the likely consequences of the rule would be harder. If the rule is accepted and the community wants not only adjectives but also other parts of speech to serve as a basis for inclusion, that can be dealt with in a subsequent vote.
I also find it odd to include under "Socrates" only the generic sense of given name without pointing out that the name overwhelmingly refers to the particular Socrates. This rationale is not explicity included in the proposed rules yet is covered by them, in that people to whom space-free names almost unequivocally refer usually manage to generate an adjective.
When CFI is applied rigidly, there is hardly any way to avoid piecemal inclusion rules. The terrain to be covered by the rules is not smooth but rather ragged, which has to be reflected in the complexity of the rules, lest the inclusion criteria become too simplistic.
Also, compare the proposed rules with the existing rule for attributive use, the rule that cites "New York delicatessen" as an example. How does "New York delicatessen" justify the inclusion of the city of New York under "New York"? To understand what "New York delicatessen" are, I don't need to know what "New York" is, but rather what the typical qualities or properties of the food called "New York delicatessen" are. From what I can see, "New York delicatessen" should have a dedicated entry, as it is a term that denotes a class of food that cannot be determined from the meaning of "New York" and "delicatessen". If you ask me why "New Work" should be included, I say that it is because it is a major city, and by including major cities Wiktionary does not become overflooded with particular places. The rule with attributive use is a proxy rule or a workaround, I think. The newly proposed inclusion rules are made to be good enough and practically useful, and no worse than the existing rule for attributive use at that. --Dan Polansky 09:51, 5 March 2010 (UTC)[reply]
You're right, the attributive use of "New York" does not justify the proper noun senses and that inclusion of the proper noun sense creates piece-meal coverage of place names. It's included because there's no workable compromise about place name inclusion. That's why I started WT:Votes/pl-2010-03/Placename namespace which will hopefully allow the main namespace to be more CFI-compliant. Ideally, New York would have the attributive sense (assuming it's valid and shouldn't just be covered under other idiomatic phrases as you suggest) and point readers to Placename:New York where proper noun referents would be found. --Bequw → τ 14:08, 5 March 2010 (UTC)[reply]
Are we to simply follow WP for notability? If not, what are our criteria for differentiating individuals included from those excluded?
The happy fact of our having an associated encyclopedia removes from us the necessity or benefit of having coverage of encyclopedic matters, most especially in the area of proper names. We still have an obligation to cover name words qua words. That obligation seems to require an entry for any (?) attestable name. Whether a name word has a special meaning that is derived from one or more of the bearers of that name is exactly what the attributive-use test is designed to address. I have come to believe that it does not include all the cases where such special meaning exists. Some instances might possibly be evidenced by "a [proper noun]": "He is a Socrates at cross-examination." (where Socrates had not been discussed previously in proximity). Our treatment of brand names may provide a analogy.
Also, I will continue to oppose any proposal that substitutes the word "individual" for "entity" on that ground alone. The change conveys the implication that the word "entity" is wrong and invites efforts to find the differences in coverage between the two words. DCDuring TALK 12:16, 5 March 2010 (UTC)[reply]

Namespace votes

WT:NS informs that namespaces Index:, Appendix:, Rhymes:, etc. were created on June 2006. Can someone please provide me links to votes related to creation of Wiktionary namespaces? --Daniel. 03:30, 2 March 2010 (UTC)[reply]

There was no vote, just https://bugzilla.wikimedia.org/show_bug.cgi?id=6476 back in the good-old pre-bureaucracy days :). Conrad.Irwin 15:06, 2 March 2010 (UTC)[reply]
I see. Thank you. (: --Daniel. 19:10, 2 March 2010 (UTC)[reply]

Inconsistency between {{pedialite}} and {{wikipedia}}

Currently, the template {{pedialite}} provides the full page name of a Wikipedia article at the left-hand side of the page, when it differs from the entry name. {{wikipedia}} does not provide such information; but I think it should, for consistency, among other reasons. For example, see this page where both templates are used: Appendix:Harry Potter/P. --Daniel. 06:43, 3 March 2010 (UTC)[reply]

Language vs. dialect

I'm sure this gets brought up all the time, but do we (almost) always follow ISO 639 on what qualifies as a language? It's certainly causing some problems. See WT:ANO which says that Norwegian Bokmål and Norwegian Nynorsk should be treated as dialects of Norwegian. Also regarding some Syriac categories I corrected, they got reverted because Syriac is a dialect of Aramaic, although both have ISO 639 codes. See also Category:Gaulish language which has no single ISO 639 code, but two.

Ok I'm rambling. So here's the point. Do we have anything close to policy on this, or is it 'tacit consent'? Is everyone happy re Norwegian for example? Mglovesfun (talk) 10:04, 3 March 2010 (UTC)[reply]

  • We don't always follow ISO. ISO will give pretty much anything you want a language code. They aren't there to arbitrate between languages and dialects, they're there to give specific codes to people who want to distinguish between geographical or temporal speech norms (or that's how it seems to me anyway). At the minute we are doing it by tacit consent, but, as with the recent Serbo-Croatian vote, it does provoke strong opinions. Ƿidsiþ 10:08, 3 March 2010 (UTC)[reply]
    Modern standard Bosnian/Croatian/Serbian/Montenegrin are all one and the same dialect (Štokavian), moreover the same subdialect of it (Neoštokavian, aka Eastern Herzegovinian). I've explained this many times. It's beyond any logic to treat what is one dialect as multiple languages. --Ivan Štambuk 03:43, 5 March 2010 (UTC)[reply]
    Please document this type of information at WT:LANGTREAT. --Bequw → τ 14:56, 3 March 2010 (UTC)[reply]
In which case LANGTREAT and WT:About Norwegian contradict each other perfectly. Mglovesfun (talk) 15:11, 3 March 2010 (UTC)[reply]
When I wrote LANGTREAT, I've described the actual usage: the three versions of Norwegian currently exist as individual languages; at least until someone cleans up them based on another organization scheme. --Daniel. 10:26, 7 March 2010 (UTC)[reply]
We should not rely solely on ISO. Sometimes they define languages which the majority of linguists deem dialects of each other as independent languages, and languages which are in fact independent are not always recognized by ISO as such. -- Prince Kassad 16:57, 3 March 2010 (UTC)[reply]
Ya I agree. They give codes to anything which can be useful. 'Multiplie languages' and 'no linguistic content' can be useful labels, but are not languages. Mglovesfun (talk) 12:16, 6 March 2010 (UTC)[reply]

Translatable interface text

Would there be any cases where we'd want to provide automatic translate of stock text on pages? Wikimedia does this for the generic UI (mostly stuff around the page contents) depending on one's preferences using system messages. We can do something similar by creating new system messages ( their translations) and using the int: magic word probably wrapped up in a template (or if all else fails, using JavaScript). We obviously won't translate everything as this is the English Wiktionary. Maybe though, the word "Translations" to facilitate the addition of these (especially since many other wikt's have a similar native-only policy towards translations and therefore will occasionally want to relocate other translation information to separate wikt's). Is this desirable in any situation? --Bequw → τ 23:11, 4 March 2010 (UTC)[reply]

See Category:Translations to be checked (French).​—msh210℠ 16:57, 5 March 2010 (UTC)[reply]
Hmm.. as that's only shown in one place (per language), we can probably just do it with transclusion. That text should probably be integrated with Help:How to check translations, /es, /de, and /fi somehow. --Bequw → τ 03:42, 6 March 2010 (UTC)[reply]
There's nothing wrong with the idea, but it would require a lot of changes for the benefit of (very few, I assume) logged-in readers who have changed their language settings. That said, I would not be against changing our headings to use templates (which is what this would entail), in the very lpong term this might let us do fun things (using certain extensions), such as remove the need to pass the language into every single template (it could pick it up from the heading). Conrad.Irwin 15:08, 6 March 2010 (UTC)[reply]

Anagrams

I'll probably get jumped on for such a question, but what's the point of adding anagrams to all entries? Besides being an interesting curiosity, what are they useful for? Playing Scrabble? -- dougher 01:27, 6 March 2010 (UTC)[reply]

I think you answered the question yourself - intersesting curiosity, and for playing Scrabble! But more likely, because someone programmed their bot to do it quickly and effectively. --Rising Sun talk? contributions 11:20, 6 March 2010 (UTC)[reply]
Scrabble or other such games... But anagrams is a game in itself. Lmaltier 11:40, 6 March 2010 (UTC)[reply]
I'm an ex-Scrabble player, and I'm not mad on anagrams on the Wiktionary. Having said that, I think the main advantage is creating extra links between entries that would otherwise by near-orphaned. On a personal note I sometimes notice anagrams that are missing and add the word in French, like tuber#French today which was missing from a French entry I was editing. If someone did want to get rid of anagrams, I'd be mildly in favour of keeping them. Especially now done by a bot. Mglovesfun (talk) 00:08, 8 March 2010 (UTC)[reply]

[4]

In the left hand column, it says "in other projects" and then a bullet says "Wikipediafr". I don't think this is supposed to happen.174.3.110.108 00:02, 7 March 2010 (UTC)[reply]

No, I'm pretty sure it is. Could you explain what you think is supposed to happen? --Yair rand 01:47, 7 March 2010 (UTC)[reply]
It looks pretty terrible with the Vector skin enabled (part of the Beta version) and that is what I think s/he might be getting at. Even with the monobook though, the "In other projects" has more margin on the bottom than the other navigation bar headers, and I think we should correct that. —Internoob (Disc•Cont) 03:25, 7 March 2010 (UTC)[reply]

Bolding letters in initialisms

Things like this [5]: I find it hideous, distracting, and unnecessary. Is this our standard accepted practice, to bold the individual letters? Equinox ◑ 01:13, 7 March 2010 (UTC)[reply]

Probably not, but maybe it should be. --Yair rand 01:16, 7 March 2010 (UTC)[reply]
We don't have one. We should definitely have yet another fun vote to sort this hideosity out, mind. --Rising Sun talk? contributions 01:18, 7 March 2010 (UTC)[reply]

I'd vote to support bolded key letters in initialisms if this practice resulted in a proper and sourced explanation of whether the word bit is an abbreviation of binary digit or of binary digit. --Daniel. 01:35, 7 March 2010 (UTC)[reply]

I've started Wiktionary:Votes/pl-2010-03/Bolding letters in initialisms. Starts in a week. --Yair rand 01:39, 7 March 2010 (UTC)[reply]
Oh god, please no! So much bureaucracy! --Rising Sun talk? contributions 01:44, 7 March 2010 (UTC)[reply]
Seriously. Do you really think this needs a vote? Nadando 01:45, 7 March 2010 (UTC)[reply]
No, we don't. Maybe you should be more explicit about your humour Rising Sun, they invented smileys just for this ;) [wink for superciliousness]. I am indifferent to bolding in entries, it strikes me as a fairly pointless thing to do, but perhaps it makes the page easier to read. There are some cases, e.g. RSVP, where it may be helpful. Conrad.Irwin 01:59, 7 March 2010 (UTC)[reply]
Er, why shouldn't this be done by a vote? It gives a clear outcome and gives the decision authority. A few weeks and the issue is resolved. What's the problem? --Yair rand 02:04, 7 March 2010 (UTC)[reply]
It takes time, and it's not even evident that the decision needs authority, ideally we'd come to mutually acceptable compromises for everything. It would take a day to unbold everything, maybe two or three days to bold everything, zero days if we decide it doesn't matter. So doing the vote will take longer than the outcome, whatever it is. Conrad.Irwin 02:13, 7 March 2010 (UTC)[reply]
I don't think this is the kind of thing there's likely to be clear consensus about, but hopefully I'll be proved wrong about that. Forget the vote for now, hopefully we can come to a consensus without one... --Yair rand 02:27, 7 March 2010 (UTC)[reply]
Yes, let's forget the vote for now, particularly if we can reach a consensus without it. But I'd like to vote on this issue otherwise, next week; probably to support bolded letters, as I said. --Daniel. 06:31, 7 March 2010 (UTC)[reply]

Absolutely I think we should bold the letters used to form the initialism. In most cases, those are fairly clear, but not always - in particular, where multiple letters are drawn from a particular word in the sequence, either from multiple initial letters of one of the words or multilpe letters within the word (as in deoxyribonucleic acid) or where there are words in the sequence that are not incorporated into the initialism at all. bd2412 T 03:12, 7 March 2010 (UTC)[reply]

Right, I also think that bolding by default is good. Though there are some people who dislike this specific formatting; being it a matter of appearance, we might simply use CSS styles to give them the right to see non-bolded letters. --Daniel. 06:31, 7 March 2010 (UTC)[reply]
  • One reason to oppose formatting individual letters is that it renders the word unsearchable. In the case of YMMV it doesn't matter because your mileage may vary is included. But many initialisms and acronyms have referents that are not and should not be included (non idiomatic or encyclopedic). If someone can solve that problem it might be worth allowing the bolding of characters, though I also find the appearance hideous and conveying no useful information. DCDuring TALK 10:10, 7 March 2010 (UTC)[reply]
If we were to just upper-case the individual letters, then this would not be a problem, but that looks less nice than emboldening, because it's not always obvious what is going on. While it would be possible to work around by adding a template to the page {{blank|your milage may vary}} - the chances of people remembering to do this are small though. Otherwise, we could put the form with emboldening into the etymology section, and have the definition as plain (or linked) text. Conrad.Irwin 11:41, 7 March 2010 (UTC)[reply]
That would be okay for most organizational names, but wouldn't work for mid-cap entries - DeoxyriboNucleic Acid? bd2412 T 00:22, 9 March 2010 (UTC)[reply]
It is ugly, but it does work, RSVP is like that independantly. Conrad.Irwin 00:30, 9 March 2010 (UTC)[reply]
I'm amazed that nobody yet has pointed out the obvious that such details, when not self-evident, go into the damn etymology section. Circeus 03:40, 8 March 2010 (UTC)[reply]
There should be a vote for this. I am going to oppose because it looks poor and distracting, IMHO. We do not have all that many executive votes and policy votes: try to count the number of policy and executive votes in the last year. We have too few votes. There is nothing fundamentally wrong about voting; it is a practical method of collective decision making. --Dan Polansky 07:59, 8 March 2010 (UTC)[reply]
Not difficult to see why votes are a good idea, but votes should not be a subtitute for leadership. I've started acting unilaterally a lot more; I figure whatever I do can be undone by someone else, so if nobody undoes it, there's a reason why. Mglovesfun (talk) 14:10, 8 March 2010 (UTC)[reply]
Right, but notice how this particular thread originated: 1. one person started something without a discussion, and 2. another person disagreed; 3. the disagreeing person has brought the issue to Beer parlour, and 4. another person started a vote. The first three steps seem like an unbureaucratic procedure. It is the fourth step of starting a vote that was questioned, but I don't see why: if the initiator, instead of starting to edit entries with AWB, would bring the issue to a vote, that would indicate an overly bureaucratic environment. But what actually happened is that a vote was created only after it became clear that there is a disagreement about the desirability of an action that was already running; the initiator did not fear to get something started without much ado. From what I can see, the way things proceeded is perfect, or near-perfect.
A formal vote could be avoided by informally voting here in Beer parlour, which presupposes that people post their boldfaced supports and opposes. But votes provide more time for people to notice that a collective decision is taking place.--Dan Polansky 18:34, 8 March 2010 (UTC)[reply]
And you forgot 5. another person commented about the over-bureaucracy about the whole thing, without reading up their smiley manual :# . ... --Rising Sun talk? contributions 22:01, 8 March 2010 (UTC)[reply]
Rising Sun, do you actually support that a vote gets started? --Dan Polansky 08:26, 9 March 2010 (UTC)[reply]
To Be Honest, I don't give a rat's arse either way. --Rising Sun talk? contributions 12:26, 9 March 2010 (UTC)[reply]

Boldfacing is double emphasis, and makes the entry look like ham-fisted, amateur typesetting. But even italics aren't necessary when four initials correspond to a four-letter initialism! The message we're sending is either “see the letters, dimwit” or “lookit ma, I boldenized these hear letters!” —Michael Z. 2010-03-10 03:22 z

I basically agree. I oppose not only the use of boldface but also the use of italics and any other formatting to highlight the letters in initialisms. --Dan Polansky 10:08, 10 March 2010 (UTC)[reply]
Unfortunately, there are some initialisms for which the letters incorporated are not so apparent, nor can they necessarily be capitalized. We could employ bolding only in those, but then our entries would be inconsistent. bd2412 T 00:00, 11 March 2010 (UTC)[reply]
Agreed. In these cases, only, italicizing the letters is sufficient. That's how the big boys do it. —Michael Z. 2010-03-11 20:58 z
All character-level formatting defeats our search engine. OTOH, our search engine, whatever its weaknesses is superior to what is available from any of the OneLook dictionaries or apparently for free from any dictionary, among which must be some of the fairly large boys.
Perhaps even more unfortunately, bolding individual letters is a word makes the word unsearchable at present. Do any specific examples of required bolding come to mind? Can we characterize the cases and count or estimate their number? Is there no alternative? DCDuring TALK 01:56, 11 March 2010 (UTC)[reply]
There is a large set of initialisms where the letters are obvious. In that small set of cases where it is not, etymology section can be used to do the job. --Dan Polansky 08:44, 12 March 2010 (UTC)[reply]
Very well, then, I yield the point. I'll undo my bolding spree. bd2412 T 15:49, 13 March 2010 (UTC)[reply]

Two issues: ADAR and ADA, which has multiple senses including a shorter form of ADAR. Is my etymology resolution to ADAR appropriate, and how do we handle this where the initialism reflects one sense among many, as in ADA? bd2412 T 16:23, 13 March 2010 (UTC)[reply]

I would just {{rfc}} ADA for all the other issues, such as the five ugly {{wikipedia}}s. Also the entry illustrates, I think, the problem of mixing common nouns and proper nouns under the various abbreviation headers, as currently being discussed at WT:BP#English contractions etc..
Camel-case treatment plus the sense-line "See" reference is adequate for "ADA", IMO. Camel case plus the etymology seems more than sufficient for "ADAR". DCDuring TALK 16:46, 13 March 2010 (UTC)[reply]
Camel-case doesn't convey the actual non-capitalized usage. It incorrectly suggests to the reader that capitalization is necessary, where it may actually be improper. Compare ACTH. bd2412 T 16:59, 13 March 2010 (UTC)[reply]

{{unsupported}}

I've created this with a few test cases- the idea being that, since Appendix:Unsupported titles is kind of a mess, it would be better to move everything to subpages. This also makes it easier to link to the individual sections. So {{unsupported|#}} yields #. Thoughts? Nadando 05:27, 7 March 2010 (UTC)[reply]

Good idea. My only thought is that it would be nice, rather than having completely unpredictable sub-page names, and having to edit the template to add each new subpage, if the titles were something the software can generate automatically. Something like [[Appendix:Unsupported titles/{{anchorencode:_{{1}}}|{{{1}}}]] seems to work somewhat O.K., though the page-names it produces are a wee bit ugly: [[Appendix:Unsupported titles/
  1. ]] [[Appendix:Unsupported titles/.]] [[Appendix:Unsupported titles/
]]. (Does anyone have any better thoughts on this front?) —RuakhTALK 06:08, 7 March 2010 (UTC)[reply]
Agreed: the template {{unsupported}} is generally a very good idea. I also agree with Ruakh on disliking the fact that unpredictable titles such as "Unsupported titles/2" might exist. Perhaps descriptive names are a better choice? I propose Appendix:Unsupported titles/Colon, Appendix:Unsupported titles/Fullwidth space, etc. --Daniel. 06:22, 7 March 2010 (UTC)[reply]
Good idea. Mglovesfun (talk) 14:08, 8 March 2010 (UTC)[reply]
I like this idea. Am I to assume that the duplication of content (on the subpages and their parent) is temporary: that the main page will become merely a list of subpages? (I hope so.)​—msh210℠ 16:17, 8 March 2010 (UTC)[reply]
I'm not happy with the way the template / subpage naming works, particularly with whitespace characters. Also, I've only created pages for the individual characters, so if someone wants to work something out for the rest, then the main page could be cleared. Nadando 21:28, 8 March 2010 (UTC)[reply]
I've now added the rest to the template.​—msh210℠ 17:24, 10 March 2010 (UTC)[reply]

Entry list upgraded

I've edited various details of the {{list}} template, mainly trying to solve issues raised at a previous BP discussion. Currently the English entries blue and ice blue contain examples of the new version of this project of standardization of See also sections. --Daniel. 09:13, 8 March 2010 (UTC)[reply]

Would you mind adding documentation to template talk:list and perhaps a brief summary to WT:NFE?​—msh210℠ 16:12, 8 March 2010 (UTC)[reply]
Both done. --Daniel. 18:15, 8 March 2010 (UTC)[reply]
The template's treatment of hypernyms is redundant to the WT:ELE treatment of hypernyms. OTOH, it would facilitate standard list of synonyms and coordinate terms and probably other -nyms as well. But many of the lists of synonyms have regional and register qualifiers that are somewhat useful, though arguably they would be better at Wikisaurus. Complex semantic relations take up a great deal of space in some entries, even with horizontal lists and still do not do justice to the matter. DCDuring TALK 00:43, 9 March 2010 (UTC)[reply]
Personally and proudly, I think that using {{list}} to link to hypernyms is better than merely using an Hypernyms section as explained by WT:ELE. DCDuring, if you provide me examples of entries with semantic relations, regional qualifiers, etc. to be organized, I may express ideas on how to standardize them. --Daniel. 03:09, 9 March 2010 (UTC)[reply]
WT:ELE is what we have been trying to standardize on for some time. I'm sure that each of us has many thoughts about how wiktionary and the world would be better places. In my wiktionary it would be a trivial matter to find entries that have both synonyms headers and not much harder to find {{a}} or {{i}} under that heading. Unfortunately our lack of support for that kind of search and the absence of any consistent markers for register and region makes it difficult for me to point you to the kinds of entries I am talking about. I always assume the the technical adepts have better means than I to find such things. My unaided meat memory fails me in this regard. DCDuring TALK 03:22, 9 March 2010 (UTC)[reply]

Why are encyclopedic subject lists being added to entries? (Whether it's advisable or not, we already have machine-aggregated categories and manually-created appendices that do this.) Wikipedia has articles and navigation lists about the subject of red colours, etc, that create a web of related things. Please don't clutter up our dictionary entries by duplicating the encyclopedia. I don't see any evidence that we have consensus to start adding this to entries, and I've not seen any precedent for it.

The dictionary deals with lexicographical relationships, so Wiktionary entries for terms have links to related terms: etymons, synonyms, hyponyms, derived terms, etc. The “See also” section is meant for semantic relationships (see WT:ELE#Further semantic relations and WT:NYMS#Otherwise related). —Michael Z. 2010-03-10 17:55 z

I thought this template is for hyponyms.​—msh210℠ 17:59, 10 March 2010 (UTC)[reply]
I thought the “Hyponyms” heading was for hyponyms. But maybe readers will find the hyponyms more easily if we remove the heading and throw them into a comma-separated list. If we've identified a serious problem than needs solving, maybe we should add add menus, a ribbon, and a talking paper clip? Duplicating existing elements waters down the design and makes an entry worse. —Michael Z. 2010-03-11 20:40 z
Now I'm going to ignore your sarcastic references to ribbons and paper clips in order to rationalize your comments on the basis that you're trying in good faith to convey something that should improve Wiktionary.
From your complaints related to this discussion, I could generally understand that you probably, but not always, think that these concepts shouldn't be present in our entries: any sets of hyponyms, comma-separated lists, lists with various links, any information that may be found in encyclopedias, any duplication of content or the very template {{list}}. You may want to clarify your point of view and continue to express possible solutions.
Most of these issues could be solved by moving {{list}} to a Hyponyms section, as opposed to the current See also section. --Daniel. 14:25, 13 March 2010 (UTC)[reply]
I haven't seen the use of this template improve any entries. I don't know what problem we have that this template is solving. I can't tell how it improves the editors' job, or even how to use it. Why was it created?
Have we decided to change our layout style from bullet lists to comma-separated lists? (Might be a good idea.) Why is a layout style change being implemented as a new template instead of discussing the style change? Why are hyponyms being put in “See also?” What exactly is the “other semantic relation” represented? Is it easier for an editor to use “the list system” than to type a comma-separated list? Template talk:list is utterly opaque to me – I can't even tell where the contents of a lists comes from.
I would just like to see clear, simple explanations of why, what, and how. —Michael Z. 2010-03-26 17:13 z
Please compare the "See also" section of these two versions of the entry bisexuality: before list template and after list template.
The {{list}} template makes that work easier by listing all terms at once. It also makes the work of {{l}} by creating links to that particular language section.
An editor may ignore this template and type comma-separated lists manually if he doesn't know these features or wants to ignore them. The contents of any list may be edited through the "[edit]" button.
Both bullet-separated and comma-separated lists are widely used at "See also" sections. You may propose the use of only one of them if you like. You may also propose the placement of this template at the sections "Hyponyms" or "Coordinate terms" (rather than "See also", which is synonymous of "Other semantic relations") when suitable. --Daniel. 07:03, 29 March 2010 (UTC)[reply]
The template has an optional place for hyponyms. It struck me as of greatest use under the WT:ELE-sanctioned heading "Coordinate terms". The value of having an optional hyponym slot is that there may be many ways in which a sense of a word has coordinate terms. Thus "blue" could have as coordinates red and green under one hyponym (Anyone?), red and yellow under another hyponym, primary color, and a very large number indeed under the hypernym color. Whether we want to have multiple sets of coordinate terms for each sense of a term is another matter. Coordinate terms do seem to run the risk of becoming encyclopedic, but can undeniably be helpful in grasping the meaning of a sense of a word. DCDuring TALK 19:52, 10 March 2010 (UTC)[reply]

luomahua / Luomahua / romanization / Romanization / romanize / Romanize

  • Tooironic:
Capitalization is not wrong. Please see related dictionaries for reference (luomahua). An administrator should do its business objectively.
  • Tooironic: What is wrong of the capitalization (luomahua)? Even it is wrong, you shouldn't block me for 1 month! ---91.106.31.27

1 600 000 entries

Nobody bothered to check (if possible) what our 1 600 000th entry was? Mglovesfun (talk) 14:07, 8 March 2010 (UTC)[reply]

Semper did. Conrad.Irwin 14:19, 8 March 2010 (UTC)[reply]

Think we could change the "categories" shown by the search options box to something a bit more relevant? Potentially commonly used functions of Wiktionary are hidden by the Advanced option and the box's desire to limit itself to "content pages, multimedia, help and project places, everything, and advanced". I think the options should be changed to put a better emphasis on the content of Wiktionary, maybe like:

  • Definitions
  • Thesaurus
  • Appendices (and Concordances)
  • Help and project pages
  • Everything
  • Other

The preset for multimedia would go, simply because I don't see the point of it on a dictionary site. It makes sense on the other sites, but not here. Think this could be possible? ViperSnake151 21:55, 8 March 2010 (UTC)[reply]

This would be good, it requires changes to the software, which I have requested https://bugzilla.wikimedia.org/show_bug.cgi?id=22774 . (Depending on my time constraints, I may be able to do something about it in the next month or two, but we'd still need to wait a few months before any changes became live). My only differing thoughts would be to include Rhymes and Citations into your "Appendices" section, and perhaps rename Help & Project to something like "Wiktionary pages". Conrad.Irwin 22:36, 8 March 2010 (UTC)[reply]

CFI for place names based on the quality of the entry

Has this kind of criterion ever been discussed: "Place names are words, and subject to the same criteria for inclusion as any other words. However, unless the place name meets the attributive use criterion, every place name entry should include at least two of the following: an etymology, a pronunciation, a translation that is not identical with the English form, or an additional definition as something else besides a place name." This would prevent blind copying of place names from the Wikipedia or from an atlas. And if somebody makes an entry for his home town in Uzbekistan, isn't it welcome if the etymology and pronunciation are included? --Makaokalani 16:29, 10 March 2010 (UTC)[reply]

To me, it is really the encyclopedic content that is the long-term problem. We could exclude "North Carolina", but include the toponym word "Carolina". That would address the lexicographic content aspect without us becoming a short-attention span gazetteer. One problem is that the logic would escape most would-be contributors. ("How come 'Georgia' and 'Virginia' have entries, but not 'North Carolina' and 'South Carolina'?") I think that we are likely to get a lot of badly formatted encyclopedic entries from folks contributing their home town, neighborhood, favorite park, or natural feature, etc. If we wanted to incubate a Wikigazetteer, we could try it out for a period of time (3, 6, 12 months ?) and then decide whether we could do it justice or whether it should be a separate project or the responsibility of WP. DCDuring TALK 17:12, 10 March 2010 (UTC)[reply]
Well - speaking as the inclusionist who has deleted more words than probably anyone else - I would include brief entries on all major geographic entities, and even many smaller ones if they have some sort of dictionary-type interest. Do you think I could get away with Nempnett Thrubwell? (probably not) SemperBlotto 17:20, 10 March 2010 (UTC)[reply]
I don't like the idea of requiring an entry to have a certain amount of information to be added. I wouldn't mind having places like Nempnett Thrubwell, so long as the definition lines had a standard, unbendable format. (My preference would be something like "1. A place name." followed by a bunch of m:WikiMiniAtlas buttons/links and a bunch of linked WP icons, but I doubt anyone agrees with me on that.) --Yair rand 02:12, 11 March 2010 (UTC)[reply]
We need to include "North Carolina" separately from "Carolina" because there are numerous places named "Carolina" (all of which have a "North" portion) but only one place properly denoted as "North Carolina". The same applies for most every state or country for which the name includes a term like "North", "South", "West", "Central", "Inner", "Outer", "New", and so forth. bd2412 T 02:21, 11 March 2010 (UTC)[reply]
Also, we aspire that all of our entries should be of that quality. For place names, the cutoff should be in terms of geographic, social, and cultural importance. bd2412 T 02:24, 11 March 2010 (UTC)[reply]
Can we include this in the current vote? Can we define geographic, social, and cultural importance? Note that Wikipedia or maps don't provide gender or transliteration for foreign scripts.--Anatoli 02:31, 11 March 2010 (UTC)[reply]

The proposal sounds fine, and I've already mentioned something similar the last time this was discussed in the BP in order to address the concerns of including large number of (possibly bot-generated) toponyms not containing lexicographically relevant content (i.e. simply the definition lines). There's no point adding something that Wikipedia already covers (and which shows up in Wiktionary search results). OTOH, it's preposterous that quality entries are being deleted on the basis of CFI which hardly reflects community consensus of today. All *nyms should be allowed, especially their derivatives such as demonyms, and possesive/relative adjectives, which are often irregular or counter-intuitive formations. --Ivan Štambuk 03:44, 11 March 2010 (UTC)[reply]

Shall I create a vote? Every place name proposal creates opposition, but what's the harm in trying? Discussions about the relative importance of places seem to come to nothing. Of course all entries should eventually have etymology, pronunciation, etc, but unlike other words, place names are worthless without them. I don't believe we'd be flooded by erratic anon entries, but if we are, they can be deleted on sight. Nobody has the duty to patch them up. Most anons never read the CFI anyway. They are more likely to be intimidated by Anatoli's entries.
The definition "a place name" looks like deliberate teasing to me (We won't tell you where, ha ha). The reader needs to know if this is the word he meant. On the other hand, there's no need to list every single place. The current practice allows for the grouping of places, with separate definitions for words that have different translations, etymologies or pronunciations. This could be added to the CFI: "Only minimal information about the place is question should be given, with links to other Wikimedia projects. A definition for a common place name might be, for example: "Any of several places in the U.K., U.S.A., Canada and New Zealand.""
Nempnett Thrubwell looks like two words to me and, unlike New York and North Carolina, it might not pass the attributive use test.--Makaokalani 13:20, 13 March 2010 (UTC)[reply]
This is skirting dangerous ground. We certainly shouldn't include or omit terms based on the “geographic, social, and cultural importance” of their referents (Wikipedia has notability criteria for articles' subjects), and most likely not on these qualities of the terms themselves, either. Using “quality of the entry” sounds like the latter to me. A checklist of included sections is the opposite of quality; it's a meaningless measure of quantity.
Why “define” a term as “Any of several places in the U.K., U.S.A., Canada and New Zealand?” We don't define a surname as “any of several people residing in towns X, Y, and Z.” We're not a gazetteer nor a phone book. Define it as “a place name,” explain its origin and meaning, list its derivatives, and link directly to the Wikipedia disambiguation page which already lists precisely the 7 countries, 2 provinces, and 6 counties where these places lie, and will continue to do a better job at it than we ever could.
Let's add a CFI for non-sum-of-parts toponymic terms. They're probably already includable; we just have to provide some examples. Or I'll get around to it. —Michael Z. 2010-03-15 05:22 z
How about the following criteria:
  • At least 150 years old (exception should be made for country capitals or cities with over 1 mln population)
  • A Wikipedia article should exist (perhaps in the language of origin if not in English)
  • Searchable information on the location - e.g. Google Map
Makaokalani, why would anons be intimidated by my entries? The main purpose of a dictionary is definitions and translations. (Of course all entries should eventually have etymology, pronunciation, etc, but unlike other words, place names are worthless without them) It applies to place names. --Anatoli 05:43, 15 March 2010 (UTC)[reply]
It was meant as a compliment. I've seen from given name entries that anons stop adding careless information if there is an impressive Greek or Hebrew etymology. And like Ivan Štambuk says above, place name entries are worthless without linguistic information - you get the same info from Wikipedia through the search button. --Makaokalani 16:01, 16 March 2010 (UTC)[reply]
I wonder whether the vandalism slows on pages with good etymology because people don't know what to make of the page, or, in particular, can't find where to add definition lines (for themselves or their friends) because they can't find the definitions. Feedback frequently complains about inability to find definitions. I think perhaps we should stop dividing up by etymology (combine all etymolgies into one Etymology section, with paragraphs for the different etymologies) and put the Etymology and other sections after the definition.​—msh210℠ 16:13, 16 March 2010 (UTC)[reply]
Re, the criteria: Why?? We're not looking for notability of the place, we don't care about population of the place, or about a Wikipedia article on the place, we don't care about the place at all. What matters to the entry is the place name and only the name, as that's what the entry is about. --Yair rand 06:05, 15 March 2010 (UTC)[reply]
If you want to change place name definitions and categories into parts of speech, start another vote. It has nothing to do with the CFI. (I removed the definition example from the CFI.) Whatever you put on the definition line, it doesn't say how to pronounce the name, inflect or translate it, or where it comes from. Three years ago I was against place names but by now I'd be ready to vote for them, if only they are entered by people who actually know something about them as words. --Makaokalani 16:01, 16 March 2010 (UTC)[reply]

Numbers

The number entries on Wiktionary right now are a mess, even if you forget the issue that nobody knows what headers or categories should be used. Theoretically, infinite numbers could be included, with all the mostly pointless "sum/product of parts" numbers. Or we could go with the attestation criteria, making tens of thousands of English numbers while leaving unpopular languages with barely any. Or we could just ban all entries like three hundred (recently failed RFD, even though all translations are still kept with broken links, and two hundred, four hundred, five hundred etc. are all kept) leaving just the base parts of numbers in languages, though nobody knows what in the world those would be. Or we could just leave everyone to make whatever number entries they want (basically what's done now, with loads of time being wasted by people going through numbers and manually adding translations). Or we could just include everything up to a thousand and leave it at that (as is oddly mentioned at the bottom of Appendix:Italian numerals (?)). Or we could just draft up some new criteria for numbers and start setting up bots to get it done.

Anyone have any particular preferences? --Yair rand 02:37, 11 March 2010 (UTC)[reply]

We should not go out of our way to include numbers that are exclusively "SoP" (this includes two hundred, forty three etc.), it is a waste of time. However, in my opinion, we also shouldn't delete them if someone wants to spend the time creating them. Ideally an extension to the software could be written that would generate useful entries "on-demand", I presume that the form of numbers in all languages is somewhat predictable (given a list of exceptions). [I would also like an extension that does this for "form-of" entries, so maybe we can combine the two]. Conrad.Irwin 11:06, 11 March 2010 (UTC)[reply]
I agree. However, in some languages (e.g. Italian), quite large numbers are written as a single word (thus (deprecated template usage) ventimila rather then (deprecated template usage) twenty thousand. These should be included under the "all words in all languages" rule. SemperBlotto 11:18, 11 March 2010 (UTC)[reply]
Perhaps the Translingual section of 1337 (defined as "the number one thousand three hundred and thirty-seven in the decimal number system") should be deleted. It is sum of parts. By the way, I think that similar definitions from 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 30, 33, 40, 45, 50, 60, 69, 70, 78, 79, 80, 81, etc., until 4649 should be deleted too. This action would be a good start in cleaning up Translingual numerical entries from now. --Daniel. 13:48, 11 March 2010 (UTC)[reply]
I disagree about 10, 11, etc. (well, sort of). At a minimum, these should be Translingual entries keyed to the English name, from which all the other language translations can be found. --EncycloPetey 03:40, 13 March 2010 (UTC)[reply]
Then, please see the current entry 19. I've developed a way to show links to English entries where sum-of-parts numerical entries would exist. --Daniel. 09:27, 13 March 2010 (UTC)[reply]
Great idea. DCDuring TALK 13:17, 13 March 2010 (UTC)[reply]
My preference: including 1. numbers from 0 to 100 (in letters). 2. all other numbers with a clear linguistic interest (e.g. trillion, but it depends on the language). 3. all other numbers would be includable only with (e.g.) 3 independent quotes really using (not mentioning) them, and written in letters. This condition is required because I think it would be a bad thing for the project if a bot creates millions or billions or trillions (or more) of number entries... Lmaltier 22:43, 11 March 2010 (UTC)[reply]
I don't see where you are getting at with the use/mention distinction: sum-of-parts terms for numbers such as "three hundred" are plentifully used rather than mentioned. --Dan Polansky 08:56, 12 March 2010 (UTC)[reply]
Of course. But, for fifty-six millions three thousands four hundred two, it's less obvious... Lmaltier 22:01, 12 March 2010 (UTC)[reply]
(Although interestingly, that is not an English number at all. In English we would say fifty-six million three thousand four hundred and two, and in the US there would be no (deprecated template usage) and. So it's obviously not as predictable as all that. Ƿidsiþ 13:58, 13 March 2010 (UTC))[reply]
I voted keep for three hundred, but the consensus was about 70% for the deletion, so I deleted it. I oppose all such deletions for the exact reasons that Conrad gives - I see no reason to mass create them, but no reason to delete the ones that already exist. If someone wanted to delete a load of SoP number entries, I wouldn't restore them because there seems to be an overall consensus to delete them. Mglovesfun (talk) 17:20, 13 March 2010 (UTC)[reply]
A further question is what to do with all the number-related words other than cardinal numbers themselves. We may want quadricentennial and icosahedral, but where does that stop? What about ordinals, or fractions, or multipliers? Additionally, having a number-of-quotes minimum makes it possible to have things like "four hundred twenty five billion", so that doesn't work. The only solution I can see is to simply build a set of criteria for each of these types of cases. For cardinals, my preference would be to include all up to 101, all round numbers (numbers containing only one numeral that isn't zero) up to 20,000, and all numbers with a clear linguistic interest. --Yair rand 03:31, 14 March 2010 (UTC)[reply]

audio file system

Hi, I have a suggestion for how to put audio files. Recently I have been working on the Japanese wiktionary a lot and I found out that their system allows them to have a direct play-button on the entry page for audio files. In the English version I would have to go to another page to listen to it. To me that seems like a huge advantage and I think we should use the Japanese system. Here's an example: http://ja.wiktionary.org/wiki/encounter Kampy 09:15, 11 March 2010 (UTC)[reply]

This was suggested in 2007 by User:Steinninn at Template talk:audio#Player. Connel MacKenzie gave a number of good reasons not to use the direct-play button. --Yair rand 20:11, 11 March 2010 (UTC)[reply]
Do you agree? The reasons dont convince me at all. Kampy 22:18, 11 March 2010 (UTC)[reply]
Direct play would be excellent. I never use the present awful system. SemperBlotto 22:19, 11 March 2010 (UTC)[reply]
By the way, the current system in the English version doesnt even work for me. I can only download the files - then start them, but they are usually not played correctly (skipping the first half of it). I think there should be a different solution. The size of the button can also be altered. Kampy 22:23, 11 March 2010 (UTC)[reply]
I find Connel MacKenzie's reasons far from convincing. We can easily change the size of the symbol, and FF doesn't lock up when playing it, also it seems a big waste of time to follow numerous links just to hear a tiny 1-second audio file. The download time for that is minimal. So IMO it would be a vast improvement --Rising Sun talk? contributions 22:30, 11 March 2010 (UTC)[reply]
Done. There are about 150 pages at WT:TODO which use {{audio}} in a broken way (most were broken before I made the change) but now the template is a block instead of inline, the uses that have a sentence after it look horrible. (Also those using {{a}} before {{audio}} could do with tweaking so that the language goes into {{audio}}). Conrad.Irwin 23:27, 11 March 2010 (UTC)[reply]
There is another audio template used in the index pages: {{audio-list}}. Would you be able to adjust that, too? If yes, it would be great, but it would be nice to keep the small blue arrow image. Thanks. --Panda10 23:48, 11 March 2010 (UTC)[reply]
I think it would be impossible to make it small enough, but maybe we can write some javascript that hooks into those links and puts a player somewhere else on the page (so it doesn't mess up all the index formats). Not easy though... Conrad.Irwin 23:50, 11 March 2010 (UTC)[reply]
In that case, it's ok to leave it as is. I know you have enough things to do and this is not critical. Thanks for your reply. --Panda10 23:54, 11 March 2010 (UTC)[reply]
That is one ugly, space-hogging button. I hope that it will be replaced by something of the same size as the previous, perhaps a different color, to distinguish the different systems until we settle on one. DCDuring TALK 01:59, 12 March 2010 (UTC)[reply]
Well, if you were to click on a link, it would suddenly expand into an ugly space-hogging media player; reserving the space in advance seems more sensible. I am open to ideas as to how to reduce the size of the button further (or even make it look nicer), it's height seems to be hard-coded. Alternatively, we could try and hide the player thingy completely, and get the files to magically play out of the ether; might be the most aesthetic when it works, but when it doesn't it's nice to show users perhaps why. Conrad.Irwin 02:14, 12 March 2010 (UTC)[reply]
(The button can be modified. This is an example: http://is.wiktionary.org/wiki/rós Kampy 10:05, 12 March 2010 (UTC))[reply]
P.S: oh you did it. great! a big improvement! Kampy 10:07, 12 March 2010 (UTC)[reply]
I doubt that more than 10% (probably less, but we have no facts) of all uses (and a far smaller percentage of usage time) involve audio pronunciation on entries that have audio information. Why would the other 90% have to pay the price of reduced visibility of definitions in the entry? The version I just looked at remains extravagant in its use of vertical screen space.
All elements that appear above definitions, especially in the Translingual and English-language sections, merit vertical space-conserving effort to enhance usability. Getting as much of the most valuable content onto a single screen, especially the landing screen ("above the fold"), remains an underweighted layout-design consideration, IMHO. DCDuring TALK 13:11, 12 March 2010 (UTC)[reply]
Uhmmm I've tried it with several browsers. Safari and Seamonkey ignore the changes (maybe my cache problem) and it looks really ugly on Chrome and Stainless, doesn't it? Pharamp 18:24, 12 March 2010 (UTC)[reply]
The expected level of ugliness is about:
 
There are minor variations across browser in appearance of the button (though they should all be the same size), the position of the bullet (though they should all be contained within the same height as the button). If you are seeing something significantly different, I'll try to fix it; if not, and people still don't want this, it's a fairly simple matter to undo my changes to {{audio}}. I would suggest we don't do this for a few days, perhaps it'll look better without the initial reaction. When the player itself pops out, what you see depends on your browser, that is again not really fixable, and arguably an improvement over previous behaviour. Conrad.Irwin 19:53, 12 March 2010 (UTC)[reply]
 
Something like this would be possible? With "Audio" in the second parameter by default. Pharamp 21:55, 12 March 2010 (UTC)[reply]
Yes, but it would break the pages on WT:TODO even more, so it'd be nice to fix those first, the actual edit to the template isn't too hard. Audio as the default second parameter seems sensible, I left it as blank because it really should list the region/dialect, but there are many cases of {{audio|blah.ogg|audio}}, yay for collaborative work :). Conrad.Irwin 00:22, 13 March 2010 (UTC)[reply]
If every template has already something in the second parameter, it's not needed to have Audio by default. Just, the second parameter "creates" the line with the little square, which is needed. Pharamp 14:17, 13 March 2010 (UTC)[reply]
  • Although this technical stuff is little TLDR for me, I must express my congratulations and appreciation for the new button, very shiny! Great work everyone! ---> Tooironic 12:47, 13 March 2010 (UTC)[reply]
  • I personally dislike the change. The new button is too conspicous, especially when compared with the replaced neat little hyperlink. However, I rarely have a need to listen to these pronunciation files to really appreciate the benefit. I do see the benefit of direct play in the page in principle, if only the button were not so distracting. The hard task is to determine whether the benefits of this change outweigh the costs for the average user. I suppose I can hide the box with the icon using some CSS magic, but that is not what an anonymous user can do. --Dan Polansky 13:24, 13 March 2010 (UTC)[reply]
    I don't understand what these "costs" are that you speak of? ---> Tooironic 22:53, 13 March 2010 (UTC)[reply]
    By "costs" I mean the disadvantages: the unduly conspicuousness of the button. The way the button looks now, it is by a wide margin the first thing that I notice in a plain page without images. --Dan Polansky 06:51, 15 March 2010 (UTC)[reply]
    How is that a bad thing though? Pronunciations are one of the best features we can flaunt (although at present we don't have enough of them and they are extremely tedious to upload and fill in all the paper work). For older people and people with vision problems this button could be very helpful; for people that don't fit this description it is hardly a hindrance. We aren't shoving pop-ups in their face or anything. ---> Tooironic 21:02, 15 March 2010 (UTC)[reply]
I agree that this is a great idea. The pronunciation is one of the main things from a dictionary. If a button is visible, then it's obvious that you can listen. I referred a couple of people to Wiktionary to look up words in another language. They couldn't find the translation until I told them they have to expand the translation section. --Anatoli 23:37, 13 March 2010 (UTC)[reply]

English contractions, etc.

Should the category English contractions be placed together with English abbreviations, English acronyms and English initialisms? --Daniel. 13:32, 12 March 2010 (UTC)[reply]

Not in my opinion. For one, it would mean renaming the overarching category for abbreviations, initialisms, and acronyms. For another, contractions tend to be verb phrases or adjective phrases, whereas the others tend to be nouns, although some can be used as verbs or other parts of speech. There just isn't much conceptual overlap between the categories. --EncycloPetey 03:37, 13 March 2010 (UTC)[reply]
I think it might make sense. This was brought up a bit at Wiktionary talk:About English#Debated PoS. We should clarify the distinction between contractions and abbreviations. (Should ma'am and Mr be categorized differently as they currently are?) Aside: I'd also support removing the Initialism header and leaving the distinction in just the categories and pronunciation sections. I think we're one of the few references that really pushes this little-known word. --Bequw → τ 05:26, 13 March 2010 (UTC)[reply]
I prefer keeping "Initialism", since it eliminates the need for a pronunciation section for the entry altogether. --EncycloPetey 05:29, 13 March 2010 (UTC)[reply]
It seems to me that the PoS-based distinction between abbreviation and contraction that EP suggests might be helpful for our classification purposes. One virtue is that it is very close to our current practice, which in term reflects some evolution of scholarship and contributor beliefs and expectations. It will be interesting to determine how many headwords don't fit a simple application of the rule. We will need some acceptable way of presenting the exceptional cases. This raises the question of whether we have taken the trouble to make sure that the headwords we classify as initialisms and acronyms are usually used as proper nouns and to distinguish those that are normally not. The answer, of course, is "no".
I have long been bothered by the absence of PoS classification and inflection information for abbreviations, acronyms, and initialisms. As many are proper nouns, for which we don't show the plural of the corresponding common noun, the difficulty applies only to a minority of these, but not a small one. I don't think that users can be expected to know any but the simplest general rules ("Add (deprecated template usage) -s or (deprecated template usage) 's in writing to form a plural of an abbreviation when needed."; "Add regular conjugation endings (deprecated template usage) -s, (deprecated template usage) -ing, (deprecated template usage) -ed or (deprecated template usage) 'd to conjugate a verb when needed." (eg. RfV => RfVs, RfVing, RfVed or RfV'd)). There are many cases where we implicitly expect a user to automatically classify one of these into the correct PoS category (common noun or proper noun) and then know what rules to apply. The classification and rules are no more obvious for this group of headwords than for many of our other headwords, for which we lovingly record every PoS. Clearly this class of headwords has suffered from a lack of such love.
Can any find it in their hearts to address this in a way that would be satisfactory across many languages? Should it be addressed one language at a time? DCDuring TALK 12:38, 13 March 2010 (UTC)[reply]
I prefer to use {{abbreviation of}}-like templates instead of abbreviation, acronym and initialism POS headers; it is satisfactory for me. Like here: 9º. --Daniel. 13:22, 13 March 2010 (UTC)[reply]
That seems quite good where applicable. That is not satisfactory IMHO for such cases as ADA, which combines common nouns and proper nouns under the same heading. There are also other cases where other combinations of PoSs may be involved. Of course, in almost all acronym and initialism cases, each definition line is actually more in the nature of an etymology, so we wouldn't want to have a separate etymology. DCDuring TALK 16:41, 13 March 2010 (UTC)[reply]
This first link points to the entry ADA as it were before I edited it. This second link points to the same entry after I edited it mainly to use {{abbreviation of}}-like templates. Do you still think that the second option is not satisfactory? --Daniel. 17:19, 13 March 2010 (UTC)[reply]
I'm glad that we're having this working chat. The final change to make this wholly satisfactory (IMHO) would be to put the links to the WP articles in the sense lines in forms like
  1. Americans for Democratic Action (at Wikipedia)
and
  1. Assistant district attorney (See w:District Attorney at Wikipedia).
They might benefit from templates when as and if the formats were agreed, especially the first format.
I wouldn't object to the second WP link being under the "See also" header, because it is not as specific as the first.
Lastly, the word-by-word linking of the components of the proper name or title seems wasteful of the time of the user who clicks the links. I expect that users of initialism and acronym entries are almost always interested in the entity not the component words. That is certainly true for native speakers and those with advanced skills in the language involved and I think it is usually true of language learners. DCDuring TALK 18:21, 13 March 2010 (UTC)[reply]
I'm glad too, DCDuring; I've noticed from some time the fact that the discussed set of entries generally need to be cleaned up. I agree with your proposal of placing Wikipedia links at definitions when appropriate. Then, I've created a third version of ADA to convey the effect.
The difference in wording between the Wikipedia article and its initialism virtually makes no difference because links may be edited. So, ADA may be defined as "Initialism of Air Defense Artillery.", while linking to Air Defense Artillery Branch (United States Army) at Wikipedia. However, I chose in to not show a link to the Wikipedia article District Attorney at the entry ADA; the Wiktionary entry district attorney is currently linked instead.--Daniel. 20:08, 13 March 2010 (UTC)[reply]
The "assistant district attorney" sense was the one for which the WP link had the least merit IMHO.
The 3rd revision looks good. The most likely objection would be to the repetition of initialism at each line. That aspect doesn't look good to me either, but I like the presentation of the grammatical facts. An alternative would be to have "Initialism" be an L3 header and "Proper noun" and "Noun" be L4 headers underneath it. Unfortunately, that would require a vote to change WT:ELE. Let's see what other folks think. DCDuring TALK 21:57, 13 March 2010 (UTC)[reply]
I like how lexical information is currently conveyed at each definition of the entry ADA. Similarly, I also quite like how the entries went and amasse are formatted. --Daniel. 22:45, 13 March 2010 (UTC)[reply]

Finally I'm gonna propose a CFI change

User:Mglovesfun/CFI/1. Please edit the lower half (the top half is just the current CFI verbatim) and the relevant talk page as much as you see fit. I think the introduction might be one of the easier sections to clean up. Note that the current CFI contradicts itself - 'all words in all languages' but 'terms' have to be 'idiomatic' and terms seems to include single words, so (deprecated template usage) bucket simultaneously meets and does not meet CFI. Mglovesfun (talk) 17:12, 13 March 2010 (UTC)[reply]

Wiktionary:Votes/pl-2010-03/Change to first lines of CFI Mglovesfun (talk) 14:19, 25 March 2010 (UTC)[reply]

Specific entries

I'm glad that Yair Rand is taking on a quest to get these verified at WT:RFV. At the very least it shows why our current policy doesn't work - much, much too vague. Some people interpret it as means 'used attributively with a widely know specific meaning other than the primary one'. So Brigitte Bardot, ok because its listed as a common noun, so are Hitler, Arnold Schwarzenegger and some others. That would mean any individual entry would need to have a non proper noun meaning. I suppose that England and United States wouldn't pass under this rule; so while I'd support having this policy clarified per above, wouldn't it be nice to have some exceptions? I'd propose

  1. Names of countries, continents, seas, oceans and planets
  2. Names of languages

I'm not sure that (deprecated template usage) French the language is ever used attributively as a common noun, so it would fail RFV. We could end up deleting all our countries and languages for that reason. Mglovesfun (talk) 17:25, 13 March 2010 (UTC)[reply]

I support having language names, but I don't like limiting place names to countries, continents, seas, oceans and planets. --Yair rand 03:36, 14 March 2010 (UTC)[reply]
This kind of proposal has already been discussed extensively. (I think there was even a vote on it, WT:VOTE/ has a lot of placenames votes that are worth revisiting). This seems to codify a subset of current practice explicitly, so it is probably worth doing. I would vote in support, but I would prefer a solution that provides a simple underlying reason which lets us decide which placenames to include, the simple "three cites" seems to be excessively broad to some people, and the attribute use seems too narrow for some people. Perhaps "three cites in a fictional context", is closer to the mark, but there are many other considerable criteria. The idea behind "three cites in a fictional context" is that cites in reference works have no choice over the place names that they choose, wheras a place name that is used in fiction implies that the author considers that people will know of it. (For example, this criteria excludes the hamlet Draycot Foliat, and village Chiseldon, but includes the town Swindon based on a quick scan of google books - it almost certainly includes all countries, continents, ocenas and planets; possibly some seas are not there, but I'd think many are). For "names of languages": I think the same criteria would work, but also we should have an appendix on every language, I don't think that the current dictionary entries are very helpful, we should link to the appendices in the header. Conrad.Irwin 12:20, 14 March 2010 (UTC)[reply]
Finally, a proposal with reasonable, explicit operational inclusion criteria. I still think that such content belongs in a separate WMF project. If we are going to incubate the transliteration/translation, etymology, and pronunciation portions of the content, at least this would focus our efforts on terms of some attestable usage. Attributive use seems to be too hard for the amateur lexicographers among us and not easy to explain to users, either. DCDuring TALK 17:08, 14 March 2010 (UTC)[reply]
Interesting idea. But wouldn't this require inclusion of a bajillion non-idiomatic names: Office of the Vice President, Johnny Horton, HMS Hood, William Lyon Mackenzie etc? Even with some qualifiers to reduce that, wouldn't this be equivalent to a notability threshold rather than a lexical one? —Michael Z. 2010-03-15 18:04 z
Johnny Horton might be citable, William Lyon MacKenzie doesn't seem to be, office of the vice president is blatent sum of parts, not sure about HMS hood - it would be interesting if suitable cites can be found. It is certainly a measure of notability (and a totally arbitrary one at that), but it is a measure that is a) simple to state, b) seems approximately appropriate, c) follows the bias of authors (not Wiktionarians), d) includes only knowledge readers are assumed to have. Conrad.Irwin 18:33, 15 March 2010 (UTC)[reply]
Re: Attributive use of "French (language)" of course it would be difficult to assess, but still, what about "French speaker"? (in the parallel "Belgian French speaker", "French" is clearly a noun to me). Circeus 00:42, 15 March 2010 (UTC)[reply]
I would support in principle, but the list you gave of classes of individual things to be included is rather incomplete. I am trying a different approach along similar lines, in the following thread in Beer parlour. --Dan Polansky 06:45, 15 March 2010 (UTC)[reply]
I think Equinox's term generic use rather than attributive use is a much better choice of words. Mglovesfun (talk) 11:04, 16 March 2010 (UTC)[reply]

Inclusion of individual places

I cannot give you a decision procedure for "chair". And I cannot give you a decision procedure for "inclusion-worthy place". But I can point to individual chairs, as well as to individual inclusion-worthy places.

I propose a vote that confirms that, of the following places, (a) their place names should be included, and (b) the places themselves should be included on the sense lines as individual things rather than as "A place name" or "A geographic name":

  • the continent of Asia under "Asia"
  • the continent of South America under "South America"
  • the particular island under "Isle of Sheppey"
  • the particular archipelago under "Orkney Islands"
  • the country of Spain under "Spain"
  • the country of the United Kingdom under "United Kingdom"
  • the U.S. state of Iowa under "Iowa"
  • the U.S. state of New York under "New York"
  • the Chinese province of Shaanxi under "Shaanxi"
  • the particular dependend territory under "Puerto Rico"
  • the city of London, U.K., under "London"
  • the city of New York under "New York"
  • the particular ocean under "Atlantic Ocean"
  • the particular sea under "Sargasso Sea"
  • the river of Nile under "Nile"
  • the river of Potomac under "Potomac"
  • the particular lake under "Michigan"
  • the particular mountain range under "Himalayas"
  • the particular mountain range under "Rocky Mountains"
  • the particular mountain under "Everest"
  • the particular mountain under "Mount Everest"
  • the particular mountain under "Snowdon"
  • the particular desert under "Sahara"

The list confirms the current practice. It is meant to be an inclusion core, acceptable to those voters who are not opposed to inclusion of individual places (as opposed to place names) in principle.

I have not created a vote, waiting for a response in Beer parlour instead. The vote would be formulated closely along the lines of what I have just posted.

Please provide your feedback or input. --Dan Polansky 06:42, 15 March 2010 (UTC)[reply]

OK. I don't see the difference between including a placename and including a place. Of course, what is included is placenames, not places, but proper nouns should be addressed just like any other word, a short definition should be allowed, and this definition has to explain the sense, i.e. which place it is. The only difficult point is about placenames including Mount, Isle, River, etc. When this is a part of the name, it might be considered the same way as New York, but his has to be discussed and clarified: in which cases do we include only the basic name (e.g. Everest), and in which cases do we include both (e.g. Everest and Mount Everest)? Lmaltier 07:16, 15 March 2010 (UTC)[reply]
Lmaltier, do you want "Mount Everest" excluded? Which of the items listed above do you want to get excluded? --Dan Polansky 07:58, 15 March 2010 (UTC)[reply]
More questions: do you see the distinction between the term "cat" and the class of domestic cats denoted by the term "cat"? Have you noticed that some people are okay with "New York—a place name" but not with "New York—The largest city in New York State, a metropolis extending into neighboring New Jersey state"? --Dan Polansky 08:02, 15 March 2010 (UTC)[reply]
For Mount Everest, I don't know. But this is less obvious than Everest. This should be discussed.
cat may have several senses. But I don't understand why some people would require a place name as a definition and not require an animal or even a common noun as a definition for cat. It's exactly the same case, the only difference is that New York is a proper noun. But A popular given name for a dog. as the definition of Fido is OK, because it's a correct and sufficient definition. Lmaltier 21:33, 15 March 2010 (UTC)[reply]
As in the previous section, I would much prefer a simple reason describing which entities we include (my suggestion "three cites in fiction" or others can be discussed there). Inclusion of the entity implies inclusion of the name, idiomatic or attributive use implies inclusion of the name (but not necessarily the entity). I would suggest that mentioning the entity(s) either in the Etymology or definition line is necessary for fuller understanding (a link to Wikipedia's article is enough, further relevant information should be a matter of editorial discretion). Whether we include the actual entity on the definition line is a matter of layout, it would be consistent with our treatment of initialisms (see ADA) to include the entity in the definition, but in the case where only the attributive/idiomatic use is citable, it is perhaps unnecessary (just as is including the "literal" definition for multi-word idiomatic terms is contentious); again I think this can be left to editorial discretion. Conrad.Irwin 13:40, 15 March 2010 (UTC)[reply]

Let's take a look at the various options for what to do with place names, shall we? For inclusion:

  • Three cites, same as any ordinary word.
  • Three cites in fiction.
  • Inclusion determined by a predefined list, or a set of categories of place names (all countries, oceans, planets, etc.)
  • Inclusion based on amount of useful information within the entry, such as translations or etymology.
  • Inclusion based on attributes of the place or places that the name refers to (i.e. population, age).
  • Inclusion based on "attributive use" of the place name, or by the existence of derived terms.
  • Inclusion limited to a namespace or appendix.
  • Complete exclusion of place names.

And for layout:

  • Either "A place name" or "place name" context tag, followed by a short description if a: the name only refers to one place or b: if the place name refers to multiple places with differing linguistic content, followed by a WikiMiniAtlas button or buttons, and possibly a WP link in the definition line. Sense lines split only upon differing linguistic content.
  • "A place name" in all place name entries, only one place name sense in the entry in all cases.
  • Short descriptions in each place name, senses split by represented places in every case (one sense per place).
  • Descriptions, including some encyclopedic content, one sense per place.
  • Some combination or compromise of the preceding four options.

Place names are a complicated issue, being neither like given names and surnames as they refer to a limited number of sometimes even only one entity, nor like specific entities, as the names are often used in multiple places. I don't think that most of the community would find pulling the place names out of the mainspace or setting inclusion based on attributes of places themselves to be acceptable outcomes. --Yair rand 20:51, 15 March 2010 (UTC)[reply]

I agree about given names and surnames. But place names are specific entities, even when the same name happens to be shared by a few places. The name is the name of each place, not the name of a "family of places", unlike surnames, nor a member of a family of "names available as a possible choice", unlike first names. Lmaltier 21:33, 15 March 2010 (UTC)[reply]
Place names are names of specific entities. "George Bush" is a name of several specific entities. --Dan Polansky 08:42, 16 March 2010 (UTC)[reply]

I have striken "Mount Everest" from the list as disputable, which does not mean that it should be excluded, merely that it does not belong to the inclusion core. My question is, should the above geographic names be included? Should the above geographic entities be included on the sense lines under these names? --Dan Polansky 11:19, 16 March 2010 (UTC)[reply]

They should all be included (and the sample I checked seem to scrape through the "three cites in fiction" criteria). Conrad.Irwin 11:31, 16 March 2010 (UTC)[reply]

Feedback from other people is welcome. My question is, should the above geographic names be included? Should the above geographic entities be included on the sense lines under these names? Should any of the items in the above list be striken from the list? Is the formulation clear or should it be adjusted? --Dan Polansky 08:36, 19 March 2010 (UTC)[reply]

Whatever form this may take, can we all agree to include place names, and not places? After all, the motto is “all words,” not “all things.”
Layout: place name is not a context, but a word function; i.e., part of the definition. A restricted-context label would be the same as the silly template:bird and template:fish “context” labels we seem to have done away with.
Fictional citations only represents a highly skewed corpus. I understand the motivation, but this would have other implications that we haven't even considered.
Aren't these clearly sum-of-parts: Atlantic Ocean, Mount Everest, Isle of Sheppay, Orkney Islands, Sargasso Sea? Aren't the proper nouns in these names Atlantic, Everest, Sheppay, Orkney/Orkneys, Sargasso? I notice the list above includes London, but not London Town, London Towne or City of London, New York, but not New York City, City of New York, New York State, and State of New York, United Kingdom, but not United Kingdom of Great Britain and Northern Ireland, Nile, but not Nile River and River Nile, etc. Are we trying to add geographical proper nouns, or all geographical names?
Names: I keep seeing editors stating categorically that place names are qualitatively different than personal names, but I've seen no real argument. Would someone like to try again? —Michael Z. 2010-03-19 15:17 z

Requests for attestation

The page Wiktionary:Requests for verification was created in 2005 and was defined as supposed to dispute existence of terms, as opposed to considering them "obvious nonsense" on sight which would be the purpose of Wiktionary:Requests for deletion. As far as I know, this distinction was a result of related discussions from that year (including [6][7][8][9][10]) [Note: The page Wiktionary:Beer parlour archive/July-September 05 is a mess.] and some adaptation of Wiktionary:Verifiability from Wikipedia to Wiktionary. The user dmh appear to be always present in these instances, among other active people such as Connel and Paul G.

In a recent discussion, the technical differences between RFD and RFV were commented, including the fact that "a failed RFV => delete, and a failed RFD => keep", which causes an unnecessary cognitive burden. One proposed alternative was merging both WT:RFD and WT:RFV into a page named Wiktionary:Requests for attestation. I'd like to know the opinions of users about the merging proposal, including the new name. Particularly, Conrad.Irwin and msh210 (and Daniel.) seem to support it and Mglovesfun seems to oppose it. I've created a vote containing basically that proposal, which may be edited as users see fit. --Daniel. 16:05, 15 March 2010 (UTC)[reply]

Just to clarify, I do not support such a merger, and I don't see how the discussion linked to, q.v., implies that I do (or, for that matter, how it implies that Conrad does).​—msh210℠ 16:21, 15 March 2010 (UTC)[reply]
I also do not support such a merger. Requests_for_attestation was a proposal by me to rename Requests_for_verification. I maintain there is a useful distinction between RFV (which is an impartial search for citations to determine whether a word is attestable), and RFD (which is an opinionated discussion on whether a phrase is considered as a word that we should even bother citing). For example, while mug of tea is clearly citable, it should not be included; a decision that would be made by RFD; gallovantering is clearly an includable form of word, but is not clearly citable, a decision that would be made by RFV. Similarly, one would file an RFD for a redundant sense, but an RFV for a dubious one. Conrad.Irwin 16:33, 15 March 2010 (UTC)[reply]
  • It's not that complicated for goodness sake. Send it to RFV if you don't believe it exists, send it to RFD if you think it exists but doesn't belong in a dictionary. Ƿidsiþ 16:36, 15 March 2010 (UTC)[reply]
Oppose merger. As to cognitive load, in my mental model it is the entry rather than the request that fails or passes. I imagine that others have a similar model. It seems easier to change one's mental model than to make a page that will be even slower to load and have more edit conflicts. DCDuring TALK 20:40, 15 March 2010 (UTC)[reply]
I don't think the merge is a good idea, either. Equinox ◑ 21:45, 15 March 2010 (UTC)[reply]
I have put up with the status quo. I understand at least in part why having the RFV and RFD processes separated can be a good thing. My understanding was that Conrad Irwin and msh210 opposed the merger in Wiktionary:Beer_parlour_archive/2010/February#RFD_vs_RFV. --Dan Polansky 09:10, 16 March 2010 (UTC)[reply]

Conrad and msh210, I'm sorry for misinterpreting your opinions. Thank you for clarifying them. After reading Conrad's recent explanation, I also oppose merging these two discussion rooms; instead, I prefer to support his original proposal of renaming Wiktionary:Requests for verification to Wiktionary:Requests for attestation. Anyone else would support this new name? --Daniel. 22:12, 15 March 2010 (UTC)[reply]

I don't see the purpose; it seems like a waste of effort. That said, fwiw I have no particular objection.​—msh210℠ 15:11, 16 March 2010 (UTC) 18:29, 19 March 2010 (UTC)[reply]
I agree with Msh210. Mglovesfun (talk) 08:12, 17 March 2010 (UTC)[reply]
If it ain't broke, why fix it? Keep RFV as it is. -- ALGRIF talk 16:00, 19 March 2010 (UTC)[reply]
Changing acronyms for something is generally not a good thing. Starting to call RFV (a very well-known discussion room) RFA would confuse a huge amount of people, especially since that usually means Requests For Adminship. --Yair rand 18:05, 19 March 2010 (UTC)[reply]
See also WT:FWC :). I think "requests for verification" is an adequate name. Conrad.Irwin 18:07, 19 March 2010 (UTC)[reply]
Well, [[WT:RFV]] can still redirect to it, and (as we're descriptivist  :-) ) if people still refer to the page as RFV then taht's what it'll be called. What the title atop the page is has little to do with that. But you're right that (at least according to WT:GL) RFA means "request for adminship" (though I don't recall seeing it used that way here). So I take back my support, above, of the move.​—msh210℠ 18:29, 19 March 2010 (UTC)[reply]

"save page"

A lot of useless entries are created where the entire page text is "save page". I don't know whether bots are doing this — it seems possible, given how frequent they are — but could we block the creation of such pages or something? Equinox ◑ 20:41, 15 March 2010 (UTC)[reply]

probably just people testing --Rising Sun talk? contributions 21:40, 15 March 2010 (UTC)[reply]
I agree, the button at the bottom of the page is called save page, and I think people are misunderstand "click" on save page with writing it. Mglovesfun (talk) 12:25, 16 March 2010 (UTC)[reply]

RFBS (Request for bot status)

User name: Heyzeuss
Bot name: Deepthought
Bot software: Python 2.6
Bot tasks:

  • Categorize entries in accounting and finance
  • Link outdated Finnish inflection appendices to newer ones, making it easy for editors to find them and manually replace inflection templates within entries.
  • categorize entries in accounting and finance
  • link outdated inflection appendices to newer ones, making it easy for contributors to find them and manually replace inflection templates within entries.
    python add_text.py -page:"Wiktionary:Finnish inflection types/nouns/paperi" -text:"<small>KOTUS type [[Appendix:Finnish declension types/paperi|paperi]]</small>" -summary:"kotus type" -except:"Appendix:Finnish declension types" -putthrottle:06
  • Bot boundaries: Those recommended in WT:BOT~ heyzeuss 05:07, 16 March 2010 (UTC)[reply]
What exactly are you wanting to do, can you show a few edits of each kind (1. categorizing, 2. changing appendix links, 3. "manually" replace inflection tables")? You can do them manually or by using the bot. Could you also please upload a copy of the code (this helps check for errors, and means that if you fade away your bot can still be run), I assume you are using one of the bot frameworks on top of Python 2.6?. (Also, there's no need to copy random conditions out of WT:BOT, they are assumed). Conrad.Irwin 10:59, 16 March 2010 (UTC)[reply]
You state that you will ask for consensus before giving the bot a task. That's what this section (a bot request in the BP) is usually for. So state what tasks specifically you want it to do, and if there's consensus then you'll get the go-ahead (for those tasks) and the bot flag.​—msh210℠ 16:17, 16 March 2010 (UTC)[reply]
Conrad and Msh210, thank you for getting back to me.
Example:
Wiktionary:Finnish inflection types/nouns/paperi - diff
The problem:
I would look up a word in Finnish and find that it does not have an inflection table. Instead, it has a link to a generalised inflection table, and the link is produced by an old inflection template. The link to the appendix is helpful, but the appendix is from an outdated model of Finnish grammar. The 78 inflection patterns were organized differently in the past and I don't know the new one. There are too many steps involved in updating the inflection table:
  1. Open the link Wiktionary:Finnish inflection types/nouns to get the matching inflection pattern. It belongs to one of 78 inflection templates. This is the step that I aim to bypass with my proposed bot.
  2. Open the link to the appropriate template.
  3. Click the edit tab.
  4. Copy the template.
  5. Copy the template from the example given in the appendix and insert the word.
  6. The consonant gradation doesn't match. Plug in the gradating consonants. This is the part that an ordinary bot cannot do. Somebody would have to put a lot of time into building it.
  7. Return to the entry in question.
  8. Click edit
  9. Replace the old template with the new one.
  10. Preview and save.
The solution:
A bot for updating the templates is probably not feasible. Instead, I want to use a bot to link the old inflection appendices to the new ones in order to remove guesswork, keystrokes, and mouse clicks by contributors.
Difficulty with replacing templates:
The old Finnish inflection templates might be rather difficult to replace automatically. The bot would have to be able to recognise all of the 78 different conjugation and declension patterns as well as the 14 different kinds of consonant gradation that take place. That is quite a few lines of code and I don't know anyone who can or is willing to tackle that project. For that reason I want to facilitate manual replacement of Finnish inflection templates. ~ heyzeuss 21:51, 17 March 2010 (UTC)[reply]
This sounds alright. If you want to start making these edits without a bot flag, that would be fine (unless there are a vast number of them); if you think it does really need a bot flag, just create a WT:VOTE. Conrad.Irwin 14:56, 18 March 2010 (UTC)[reply]
If you see anything off the mark, please tell me immediately. Thank you for your time and attention. ~ heyzeuss 07:37, 19 March 2010 (UTC)[reply]
You need to register User:Deepthought - if you're going to use that account anyway. Conrad.Irwin 11:26, 19 March 2010 (UTC)[reply]

Number versus numeral (again)

Now that the vote has ended, there are a LOT of categories that need renaming, possibly hundreds or one or two thousand entries to recategorize. AWB is one, somewhat slow way to do it, but a bot would be much better.

A second concern is that at least one person prefers numeral over number. I'd strongly favor number, just because it's more natural for an English speaker to say it! Never in my life, outside of Wiktionary, have I heard "cardinal numeral" or "ordinal numeral". On Google Books, "cardinal number" is about 4 times as frequent as "cardinal numeral", and for ordinal it's about three times as frequent.

Basically, if we can avoid a vote it will save us a lot of time, otherwise we might end up moving a few hundred entries to just move them somewhere else again. I don't think any vote should be called unless there is 1) a realistic chance of it passing 2) a realistic chance of it failing. You gotta hate those votes that finish 8-0, because obviously had you just made the changes in the first place, nobody would have objected.

So, how many people would openly support numeral over number? If it's very few people, I say no vote at all. Mglovesfun (talk) 12:23, 16 March 2010 (UTC)[reply]

I'm assuming the recently finished vote is Wiktionary:Votes/pl-2010-01/Number_categories? It should not be hard to write a bot to fix these, though if entries are categorised using templates, fixing the templates first is a good idea.
Number is preferable to numeral, (and our definitions imply that number#2 == numeral). While numeral may be more precise (numeral only refers to the denotation of number#1), I think clarity is preferable to precision for those who have to read this stuff we write. (That said, using "numeral" does make me feel much more grown up). There are currently ~50 pages using "(Cardinal|Ordinal) numeral" in the heading (vs. 3000 using "(Cardinal|ordinal) number"), they can be fixed with a simple bot. Conrad.Irwin 12:52, 16 March 2010 (UTC)[reply]
This is a false count, as you did not include in your statistic those that have Numeral as a header versus Number. We have never agreed whether Cardinal Number/Numeral should be a POS header versus simply Number/Numeral. The same issue applies to ordinals and other numerical parts of speech. --EncycloPetey 01:56, 17 March 2010 (UTC)[reply]
I strongly prefer Numeral for Portuguese, because in this language cardinal numerals and ordinal numerals are individual branches of the part of speech "numeral", both with their respective grammatical characteristics. I've already cleaned up the categories Portuguese cardinal numerals and Portuguese ordinal numerals. --Daniel. 13:13, 16 March 2010 (UTC)[reply]
Some searches:
The searches of course need to be taken with caution, but the last search shows some printed books that use "cardinal numbers" in reference to Portuguese words.
Does anyone really use "cardinal numerals" in reference to Portuguese parts of speech?
On another note, Citations:numeral" is empty, so there is not much evidence in Wiktionary to go by. --Dan Polansky 14:56, 16 March 2010 (UTC)[reply]
Other pages to fill: Citations:cardinal number, Citations:cardinal numeral, Citations:ordinal number, Citations:ordinal numeral. --Dan Polansky 14:58, 16 March 2010 (UTC)[reply]
I could favor "numeral" if we restricted inclusion to the digits 0-9. As this is not the intent AFAICT, the evidence seems to me to strongly favor the more inclusive English word number. DCDuring TALK 15:53, 16 March 2010 (UTC)[reply]
Re: Dan. Actually, I see the opposite in the searches above. While a search for "Portuguese cardinal numbers" returned 6 hits, none of those six books actually contain that phrase. Each one of them has a period after the word Portuguese, with Cardinal numbers being the start of a new line, sentence, or section. Also note that two of the six returns are 19th century books about banking and two are travel guides published as part of the same series (and so are not independent). The remaining two books were also published in the 19th century, and so cannot be considered a guide to current nomenclature The single return for "Portuguese cardinal numerals", however, actually uses that phrase as part of a sentence and is a reference grammar published in the last 10 years. This pair of searches thus (weakly and marginally) supports the use of "numeral" over "number". --EncycloPetey 01:50, 17 March 2010 (UTC)[reply]
I cannot agree that the pair of searches supports "numeral" over "number", marginally or not. It is true that, in the found Google books, "Portuguese" and "Cardinal numbers" are found as separate phrases, but I see no problem with that, and think it an irrelevant point. The higher age of four of the six hits is more problematic, but two of the six hits are recent, just that they are not shown. The older items are naturally shown in full view, as their copyright has expired.
A quotation from one of the books: "Cardinal numbers are invariable; except which vary according to gender or number; ..."[11]
Other searches:
Yes, the searches also find some hits on mathematics, and they find not only moderns uses but also more dated uses. But the particular items found in these searches show unequivocally that "cardinal number" is used plentifully in discussion of Portuguese grammar. The claim that the searches show higher frequency of use is admittedly more disputable.
What is your evidence that "cardinal numeral" is used more often than "cardinal number" in reference to Portuguese parts of speech?
Or would you agree that "cardinal number" is more common than "cardinal numeral" in grammar books? --Dan Polansky 07:21, 17 March 2010 (UTC)[reply]
If you had suggested it, I would have agreed that "cardinal number" used to be more common, but that "cardinal numeral" is increasingly more common in grammars written in English. The CGEL itself adopts the distinction in that they use "numeral" for the words / part of speech, but use "number" for the meaning of such words. Which of the books in your search make this distinction of use between the words this way? I do not know. How many of the book hits this time are from antiquated sources again? I do not know. I am not as willing to be swayed by mere results of a tandem search for phrases in the absence of context. Your previous search and my critical anaylsis of the results should demonstrate why. --EncycloPetey 13:34, 17 March 2010 (UTC)[reply]
I strongly prefer numeral for the name of the words that represent numerical values, but number for entries that involve the use of digits. I do not know whether this distinction exists in all languages, but European languages, especially Romance languages and European linguists, are increasingly using numeral to refer to the part of speech. The CGEL also prefers numeral, as can be seen in the sample quote on the entry for (deprecated template usage) numeral. --EncycloPetey 01:50, 17 March 2010 (UTC)[reply]
Agreed. The proposal of "numeral" for words and "number" for digits seems very reasonable to me. --Daniel. 01:58, 17 March 2010 (UTC)[reply]
To clarify, I would not restrict "number" to digits alone, but then I feel that some entries such as 10, 19, 100, etc. are worthy of inclusion. Whether or not we choose to include entries for them on Wiktionary is a separate issue, of course, but I do want to be clear about what I think should be included under that description if those entries are allowed. --EncycloPetey 02:02, 17 March 2010 (UTC)[reply]
I think we should consider not only the commonality of the terms "cardinal number" and "cardinal numeral" but also the resulting category structure.
Mixed structure of categories:
  • Numerals
    • Cardinal numbers
    • Ordinal numbers
Neat structure of categories with "numerals":
  • Numerals
    • Cardinal numerals
    • Ordinal numerals
Neat structure of categories with "numbers":
  • Numbers
    • Cardinal numbers
    • Ordinal numbers
Oddly, the mixed structure is sometimes used, for instance here, here and here: S:Gesenius' Hebrew Grammar/97. Numerals. (a) Cardinal Numbers. The search: google books:"numerals" "cardinal numbers".
The neat structure of categories with "numbers" is seen here, but is hard to find, as the search for "cardinal numbers" finds mostly mathematical hits. --Dan Polansky 08:58, 17 March 2010 (UTC)[reply]

19

Please see the current entry 19. It contains a "sum-of-parts" message. I'm thinking on including that type of message in other numerical entries as well. Firstly, I'd like to know the opinions of more people about this proposal. --Daniel. 02:12, 17 March 2010 (UTC)[reply]

I prefer to include quite a number of these. First, because many numerical systems are not base ten. Second, this is not sum of the parts 1 and 9, but sum of the parts 10 and 9, which is not apparent unless you have learned the rules for adding Arabic numerals. Third, this is an arithmetic sum, and not a grammatical sum of parts. --EncycloPetey 02:18, 17 March 2010 (UTC)[reply]
Not exactly. Instead of defining different entries for 10, 100, 1000 and so on, I'd prefer to make clear in only the entry 1 that its value is different according to the place it occupies in a number with multiple digits. Therefore, 1 may be worth one, ten, one hundred, etc. in base ten. (And in base two, it may be worth two, four, eight, etc. Different bases may be described eventually.) --Daniel. 02:34, 17 March 2010 (UTC)[reply]
I see that more as defining how "a" is a component of a word. If we say "it's value depends on how it's used", then that's not a definition at all. We also, in eliminating those entries make it impossible to coordinate the symbolic forms across numerical systems. This is separate from the cross-listing of word forms in various languages. --EncycloPetey 02:51, 17 March 2010 (UTC)[reply]
I see that more like defining the word not as a component of a phrase. A person may say "not red", "not amicable", "not ugly", each resulting in different overall ideas, which are considered sums of parts that include a word implying negation. The fact that the value of 1 is one, multiplied by ten according to its place in a number is important enough to be stated at the single-digit entry (even if the community decides to keep entries for "sums of parts" like 11, 93 and 100). Finally, that box currently in the entry 19 contains a link to the English entry; so, including symbolic forms in other numerical systems would not be a difficult task if they're desirable. --Daniel. 03:38, 17 March 2010 (UTC)[reply]
And how would your suggestion affect the ability of foreign-language users to find out that 19 is called nineteen in English? Currently, a user need only type in "19" and find the entry. --EncycloPetey 13:25, 17 March 2010 (UTC)[reply]
Right. Typing "19" and finding an English link is fine for me. (In my opinion, this idea of an entry linked to the English version is particularly better than the current entry 43, a redirect to forty-three.) --Daniel. 15:30, 17 March 2010 (UTC)[reply]
I think I like the idea of 19. But one thing I do not like is the wording "sum of parts of Translingual 1 9". Wiktionarians know what that means, and anyone might if he thinks about it enough, especially if he follows the link to see what we mean by sum of parts. But I think your average reader will look at it, see "1 9", and say "huh? These guys don't know basic arithmetic", or "that's a bad typo".​—msh210℠ 16:58, 17 March 2010 (UTC)[reply]
Unless your average reader is a programmer, and knows what overloaded means. ;) Pingku 17:51, 17 March 2010 (UTC)[reply]
Then, "It is sum of parts of Translingual terms 1 and 9." would be a better explanation? --Daniel. 14:35, 18 March 2010 (UTC)[reply]
"And" beats " " any day of the week in my book. Why the italics?​—msh210℠ 15:53, 18 March 2010 (UTC)[reply]
The term "sum of parts" merits attention (evidently as the reason for the existence of the whole message) so I italicized it. Would you prefer "It is sum of parts of Translingual terms 1 and 9.", without italics? --Daniel. 16:53, 18 March 2010 (UTC)[reply]
Me, yes, without italics — and with "the", per Mg, below.​—msh210℠ 17:38, 18 March 2010 (UTC)[reply]
For me, of the Translingual terms (translingual should also be lowercase, I know). Mglovesfun (talk) 17:09, 18 March 2010 (UTC)[reply]

I've edited {{SOP}} to include the words "the", "and" and "terms", per me, Martin and Michael above; I've also removed the italics. Therefore, a slightly different version of 19 is available. Then, please correct me if I am wrong: Isn't Translingual a particular set of words as known by Wiktionarians, as opposed to translingual terms that are randomly found in two or more languages? --Daniel. 18:13, 18 March 2010 (UTC)[reply]

Even if so, all Translingual words are translingual also. It looks odd to me capitalized, though I may be alone in this. (We capitalize it in headers and category names, but they'd be capitalized anyway.) A fix, if one is desired, could be replacing the {{langname/cat|{{{lang}}}}} terms with the {{#switch:{{langname/cat|{{{lang}}}}}|Translingual=translingual|{{langname/cat|{{{lang}}}}}}} terms.​—msh210℠ 18:38, 18 March 2010 (UTC)[reply]
Yes, this code suggested should "fix" the upper case letter into lower case. However, I prefer "Translingual", as it is spelled for example, at the description of Category:Translingual suffixes and the policy Wiktionary:About Translingual. --Daniel. 02:50, 19 March 2010 (UTC)[reply]

Shavian donation

I'm the administrator of a wiki whose purpose is to map English words in their conventional spelling to their spelling in the Shavian alphabet (a phonemic alphabet for English). For example, the word "dictionary" maps to "𐑛𐑦𐑒𐑖𐑩𐑯𐑼𐑦". There are about 15,000 entries. It was started because we needed a database for transliteration work, and we couldn't find a freely-available pronouncing dictionary which didn't exhibit the cot-caught merger. The licence on the wiki data is cc-by.

I asked on the Information Desk whether it might be appropriate to donate a copy of this content to Wiktionary. Someone replied and said it might work as an appendix. How would I go about structuring such an appendix? Clearly I shouldn't put all 15,000 entries on the same page, so should it be broken up by initial letter, or something like that? Marnanel 13:44, 18 March 2010 (UTC)[reply]

That would seem great, if necessary you can always take the approach of Index:English and further subdivide the largest letters (whether you are dividing by letters in English or Shavian, or both is up to you). How were you planning on importing the words? Conrad.Irwin 13:56, 18 March 2010 (UTC)[reply]
I was tentatively thinking of writing a Perl script which took the content of the Shavian wiki and turned it into MediaWiki markup in whatever form we decided, and then using a bot to do the upload. Marnanel 14:04, 18 March 2010 (UTC)[reply]
I'm unclear about what's being proposed. Do you propose to add Shavian spellings to English-language entries (under "Alternative forms" or "Pronunciation")? Or to add them as separate entries? The latter would not be in accord our current practice regarding fingerspelling and Morse code. (We do not allow fingerspelling or Morse-code entries for whole words, though we do the individual letters.) And I'm not sure how welcome the Shavian spelling would be in English entries under "Alternative forms" or "Pronunciation": consider shorthand, which we have in some entries but which is tolerated because "it is relatively harmless at the bottom of the page", which is not where "Alternative forms" or "Pronunciation" is currently.​—msh210℠ 16:07, 18 March 2010 (UTC)[reply]
I'm asking whether Wiktionary would like a copy of this content in some form, and offering to upload it in any form which gains consensus. I'm not particularly proposing anything about the form. Marnanel 16:43, 18 March 2010 (UTC)[reply]
An appendix would seem best, we can copy it into articles if people decide they want it later. Conrad.Irwin 16:45, 18 March 2010 (UTC)[reply]
Yeah, sounds good IMO. I guess appendix:Shavian spelling (or transwiki:Shavian spelling?). In any event, since it's cc-by, you've gotta include all the "by" (though I'm sure you know that).​—msh210℠ 16:56, 18 March 2010 (UTC)[reply]

Register for AWB

Could I have my account enabled for AWB use, please? There is some maintenance stuff to do with Dutch verbs (replacing templates mostly) and I want to see if AWB would make it easier. Thanks. --CodeCat 19:56, 18 March 2010 (UTC)[reply]

Done (I think). --Yair rand 20:12, 18 March 2010 (UTC)[reply]
Seems to be working. Thanks. :) --CodeCat 20:20, 18 March 2010 (UTC)[reply]

New language section

Is it possible to add the new section link (the " " symbol, as found at the top of talk pages) to all entries to create new language sections more easily? --Daniel. 03:16, 19 March 2010 (UTC)[reply]

Yeah, that would be helpful, as long as it were automatically alphabetising. ---> Tooironic 07:59, 19 March 2010 (UTC)[reply]
Yes, automatic alphabetization (for instance, by placing the new Portuguese language section exactly between Norwegian and Russian) would be great. Although I wouldn't mind if new language sections were placed in the end, then subsequently relocated by AutoFormat. --Daniel. 14:38, 19 March 2010 (UTC)[reply]
Such a link wouldn't currently alphabetize, but, as you note, AF will. To add such a link to any one page, just put __NEWSECTIONLINK__ anywhere in the page. To edit a new section on any page, use the URL http://en.wiktionary.org/wiki/PAGENAME?action=edit&section=new. To add it to ns:0 pages by default... I don't know.​—msh210℠ 17:37, 19 March 2010 (UTC)[reply]
This proposal sounds extremely useful. Especially if it would provide a template for the part of speech, romanization, etc. like the auto-translation template.--达伟 19:28, 19 March 2010 (UTC)[reply]
I've added a __NEWSECTIONLINK__ and tested. Both the usability and the result (current version of iceberg) look great indeed. Except for the unsorted languages and the lack of "----". --Daniel. 05:08, 20 March 2010 (UTC)[reply]
And Autoformat seems not to be rushing to fix it, which is a shame. It would be easy to add the with javascript, and also possible to hijack the save button with WT:EDIT or something simpler. Conrad.Irwin 19:37, 20 March 2010 (UTC)[reply]

Entry creation aider

I also really like 达伟's suggestion, and think it should be further explored, the idea below is that it would start off with only 1 and 2 showing, then, once the editor has selected something, it can help guess the inflection line (based on language and part of speech), showing the remaining fields as and when feels best. The bolded links are the ones I "clicked" on to get it to look like this. I should currently not be spending so much time on Wiktionary, but would be happy to help with getting this to work, if other people felt comfortable with working on it. Please feel free to embellish and improve the design below, some factors that shold be taken into account: a) it should never slow down existing expert editors, b) it should be easy for new editors to see how the buttons change the wikitext, c) it should be easy to add the guess-work for new language/part of speech combinations. (I don't think it is very practical to update the interface if the user edits the wikitext, and maybe even guessing a gloss will be too hard). Conrad.Irwin 19:37, 20 March 2010 (UTC)[reply]

Adding a new section to bunny
  • 1. Language (name or code): [ en ]
  • 2. Part of speech: Noun, Verb, Adjective, Adverb, Other: [ (select) v]
  • 3. Plural: bunnies, bunnys, Other: [      ], Advanced: [{{en-noun|bunn|ies}}]
  • 4a. Definition: [rabbit with a fluffy tail]
  • 4b. More details: Quotations, Synonyms, Translations, Other: [(select) v]
    (delete) Synonyms: [       ], More... (gloss: "rabbit" (change) )
  • 5. Further information: Another definition, Etymology, Pronunciation.
==English==
===Noun===
{{en-noun|bunn|ies}}

# rabbit with a fluffy tail

====Synonyms====
* {{sense|rabbit}}
This should be very useful, especially to bots that automatically create entries. SemperBlottoBot for example just tags the article with {{rfc-auto}} and lets another bot clean it up. With this change, it won't need to. --CodeCat 13:28, 25 March 2010 (UTC)[reply]

Unified Gaulish

Per the proposal of [[Category:Gaulish parts of speech]] for deletion, do we want to unify the two Gaulishes (sic) into one code, such as {{gaul}}, the French Wiktionary's code for it. I know just about nothing on the matter, I certainly don't know what the difference between the two language is. Mglovesfun (talk) 11:34, 19 March 2010 (UTC)[reply]

The difference is mostly geographical only. Cisalpine Gaulish was spoken in today's Italia, while Transalpine Gaulish was spoken in today's Provence (on the different sides of the Alps, hence the names). -- Prince Kassad 19:39, 19 March 2010 (UTC)[reply]
Uniting them is fine, there is already a template at {{cel-gau}} which fits into the code scheme. Conrad.Irwin 19:46, 19 March 2010 (UTC)[reply]
Shall we make this so, providing nobody objects? Mglovesfun (talk) 18:52, 20 March 2010 (UTC)[reply]
Passes unopposed (deprecated template usage) alors. Mglovesfun (talk) 12:29, 26 March 2010 (UTC)[reply]

Minnan/Taiwanese

I don't know if this is the right place to ask this, but I wanted to note that the Chinese character/hanzi entries lack two of the more prominent Chinese topolects, Wu (Shanghainese) and Minnan/Taiwanese (Hokkien). Is it realistic that editors (including myself) could add headings for these languages on the appropriate hanzi pages?--达伟 19:30, 19 March 2010 (UTC)[reply]

I am not very familiar with Hanzi entries, would you be able to give me a run-down of how it's usually organized? It seems a little messy at the first glance. Might be able to help you then (being a native Wu speaker myself). Jamesjiao → T ◊ C 22:54, 24 March 2010 (UTC)[reply]
An example Min Nan entry: 囡仔. An example Wu entry: 啘. They are dialects/topolects/languages sharing largely the written form with Mandarin. Words completely different from Mandarin with established writing deserve an entry. Otherwise they are all written in Mandarin - standard Chinese but pronounced in whatever dialect. Be careful with definitions, as single hanzi may have too many meanings but if you want the pronunciation only, why not? Stick to a standard transliteration, please. --Anatoli 02:50, 25 March 2010 (UTC)[reply]
What I was thinking of was the following. (1) Anatoli is correct in saying that these topolects/dialects can be written, in which case they will use some characters which are common with "standard" Chinese (i.e. Mandarin), AS WELL AS some characters which are unique to those dialects/topolects. Cantonese also has some dialect-specific characters. (2) Any "regular" character also has its own unique pronunciation in each topolect/dialect. (3) The dialect-specific characters (囡仔 or 啘) are valuable but they are not necessarily what I was thinking of at them moment. (4) Instead, what I was thinking of is the "regular" Hanzi/character entries--these currently contain pronunciations and in some cases definitions in Mandarin, Japanese, Korean, and Cantonese. My question is: why don't we also include the pronunciations for these "regular" characters (e.g. 萬, 國, 达, 伟 to pick at random) in Wu, Min Nan, etc.?--达伟 10:13, 29 March 2010 (UTC)[reply]
Why? Lack of knowledge or time, perhaps, not enough editors wanting to do it. Even dialect speaking Chinese editors would perhaps focus on Mandarin entries/translations first. More importantly, dialects are researched but they are normally not taught - they are usually non-standard. If we talk about Wu, do we take some district of Shanghai as standard? Min Nan is also spread. In Taiwan, they will claim to have the proper Min Nan but perhaps it's in southern Fujian? Of course, there are special dictionaries of Chinese dialects but I haven't seen them. You may not find contributors for each language/dialect here. --Anatoli 10:29, 29 March 2010 (UTC)[reply]
In terms of lack of time or lack of qualified editors, I understand. But I do hope that some people will eventually share my aspiration of placing the Wu and/or Min Nan pronunciations on the ordinary Hanzi entries just like we have Cantonese/Japanese/Korean/Mandarin at present. Regarding problems of location, my feeling is that it shouldn't be a problem. I think we have no other choice than to pick Shanghai topolect/dialect as our representative Wu (as opposed to Hangzhou/Suzhou or whatever)--the population and cultural importance of Shanghai seem overwhelming. Regarding standardization, I'm pretty sure that there are commonly available 上海话 dictionaries in mainland China. As to Min Nan/Taiwanese, I would just use whatever standard we're currently using for the other Min Nan entries that people like A-cai are creating...--达伟 00:13, 30 March 2010 (UTC)[reply]
Despite some people's opinion that Chinese dialects are languages, they do have the features of dialects - they have "no army or navy", they are not promoted by the Chinese government. Written forms of these dialects may be crude, since different writers may choose different characters for the non-standard words (these words are not taught at school). The diglossia with Chinese dialects is not unsimilar with the Arabic where many dialects don't have a written form or only starting to develop it. Hence, the same words may have various spellings, often affected by the standard language, not the pronunciation of the topolect itself. A-cai may disagree, as speaking Min Nan in Taiwan means you are close to people and politicians use it every now and again to get more support. Some movies use Min Nan in Taiwan. Cantonese is the de-facto standard in Hong Kong, although they write documents in Mandarin. Wu also enjoy a high status. --Anatoli 00:28, 30 March 2010 (UTC)[reply]
I agree with Anatoli that editors like me would rather spend more time promoting Mandarin than other topolects of Chinese. It's more an issue with time and effort than the validity of including separate entries under Hanzi enries. Jamesjiao → T ◊ C 07:01, 31 March 2010 (UTC)[reply]

Quidditch

I've developed a new template to standardize etymologies of terms coined in fiction such as lightsaber, hobbit, etc. For instance, see Quidditch, particularly its English etymology section. --Daniel. 13:23, 20 March 2010 (UTC)[reply]

Interesting how it makes it completely impossible for anyone without the secret knowledge to edit the actual text. In what sense of member is it a "member of the franchise"?--Prosfilaes 15:17, 20 March 2010 (UTC)[reply]
Agreed, I dislike the drive to push content into abstruse templates. Additionally, I think it is futile to attempt to reduce the information in these etymologies to a small set of fixed parameters (in this case title=, franchise=, author=, date=). --Bequw → τ 15:27, 20 March 2010 (UTC)[reply]
I've got inspiration from citations and references, whose contents are also generated by templates with parameters author=, etc. so they must be well-known by Wiktionary editors. I don't see how the use of {{from}} requires secret knowledge or strict information. Or does it simply look bad? Suggestions would be appreciated; the word "member" could be changed to something else for a start. --Daniel. 16:45, 20 March 2010 (UTC)[reply]
A few things:
  1. Why not just use {{from:HP1}}? (Extra templates are not good, indirection is irritating)
  2. I see no problem with having a series of from: templates, like the series of R: templates.
  3. The wording of {{from helper}} is too generic and thus unpleasant. HP1 is not just "a member of the HP franchise", it is the first HP book, but is that even relevant? I also think it should be made clearer that JK Rowling is the author of the book, not just the coordinator of the franchise: Perhaps "First used by JK Rowling in Harry Potter and the Philosophers Stone (1997)." is sufficient, or if we want to be less assertive, "first use attributed to", if it's absolutely necessary to link to Harry Potter (though I note that the word "franchise" appears not once in that Wikipedia article), "the first novel in the Harry Potter series" can be appended. Conrad.Irwin 18:22, 20 March 2010 (UTC) (Oh, I notice the link goes to our appendix, not Wikipedia, that can be done more nicely in "see also" where people will notice that it is actually a useful link). Conrad.Irwin 18:24, 20 March 2010 (UTC)[reply]
I've removed indirection per Conrad; now {{from:HP1}} may be used. I prefer "coined" than "first used" in the wording. I agree on making clearer that Rowling is the author as opposed to just the coordinator of the franchise. And, I disagree on stating which book is the first in the series at the etymologies. --Daniel. 19:48, 20 March 2010 (UTC)[reply]
I've said openly that Daniel. has a bit of an obsession with creating complicated templates. I don't mean that figuratively, I mean an obsession. Mglovesfun (talk) 18:35, 20 March 2010 (UTC)[reply]
I guess we've all got our obsessions here. All the better for us if the obsessions are useful --Rising Sun talk? contributions 18:40, 20 March 2010 (UTC)[reply]
I'm not denying that. Mglovesfun (talk) 18:50, 20 March 2010 (UTC)[reply]
Apparently and interestingly, according to people's opinions my templates tend to be hard to edit but easy to use; such as adding a simple {{poscatboiler|fr|noun}} or {{pt-verb|arran|car}} to the proper places but having no idea on how to change their codes. Then I upgrade such templates as people suggest or ask, usually either to make them easier or to expand their scope. This relationship seems to be working well up to today. --Daniel. 19:48, 20 March 2010 (UTC)[reply]
Please don't stop making templates :). They are great (and from time to time provide some much needed mental exercise :D). Conrad.Irwin 19:51, 20 March 2010 (UTC)[reply]
Hey, thanks for these nice words. :) OK, I don't intend to stop making templates indeed. --Daniel. 17:57, 21 March 2010 (UTC)[reply]
Instead of "member of", how about "from the franchise"? —scs 14:25, 21 March 2010 (UTC)[reply]

I've edited the template wording to conform to various suggestions from this discussion, including the "from the franchise" per scs but not the "first book in the series" per Conrad, although this idea may be discussed further.

On second thought, I've maintained the initial "From" rather than "First used" or "Coined", because terms are derived from fiction and tend to be defined differently in the real world, such as kryptonite meaning "weakness", not "extraterrestrial mineral that makes Superman weaker, among thousands of other arbitrary effects based on context and author".

Conrad, you suggested the text "Harry Potter and the Philosophers Stone (1997)" So do you prefer to convey only the year in the date, rather than the current "1997-06-30"? --Daniel. 17:57, 21 March 2010 (UTC)[reply]

I don't think the month/day add anything, {{quote-book}} only highlights the year, so yes, I prefer just year. It's a minor niggle though, thanks for cleaning up the rest, much better now. Conrad.Irwin 18:09, 21 March 2010 (UTC)[reply]
Fair enough. I've removed month and day now. --Daniel. 18:19, 21 March 2010 (UTC)[reply]

Straw Poll: Inclusion of unattested identifiers

As the language codes appear to have failed RFV (qv discussions 1 and 2), I'd like to gauge community sentiment before acting (and the previous BP discussion was too thin to be representative). The class of terms affected is that of unattested w:Identifiers or w:Codes. Basically, any key for predefined key/value pairings that is not used in natural language. I believe the desire to include these emanates from the desire that Wiktionary be not just a dictionary in the first sense but also in the second sense, which reads "a data structure where each value is referenced by a particular key". Examples of unattested identifiers are (though maybe some of them are attested).

If this straw poll shows that most people support the current CFI (that attestation is required for all terms) then the RFV'ed langauge codes will be deleted. If most people support their inclusion, then we can vote on amending the CFI. Otherwise, this can be added to WT:UNRESOLVED. — This unsigned comment was added by Bequw (talk • contribs).

Support current CFI

  1.   Support Wiktionary should stick to defining attested terms as that is where we can provide actual linguistic information. Other sources, such as Wikipedia, adequately "define" identifiers. We are not a code book for everyone's codes. --Bequw → τ 16:29, 20 March 2010 (UTC)[reply]
  2.   Support We should eat our own dog food. If a rule like CFI is good enough to apply to all the other groups of potential users and their codes, then it should be good enough for us. DCDuring TALK 19:44, 20 March 2010 (UTC)[reply]
    Such extra-linguistic special-purpose codes may be usefully compiled in Appendices with whatever explanation is needed affording great economy of presentation and maintenance. This follows the lexicographic practice, common among dictionaries that include similar items, of having distinct treatment of such items. The rationale for following this practice is user cognitive economy and maintenance economy, not space economy. If such terms were found to be searched for, we could include Appendix space in the default search. We could also reference such appendix using (deprecated template usage) also if the the headword otherwise meets CFI. DCDuring TALK 13:14, 21 March 2010 (UTC)[reply]
  3.   I agree with much of what CI and EP have written, below, which means that I support inclusion of some of these things (e.g., ISO codes for languages) and not others (e.g., ISBNs). That is, I support the current CFI, modified to include certain sets of things, but not others. (Incidentally, I think chemical formulae should be included if they are alphabetic-only, or at least if they are full-caps alphabetic, such as NO and KCN, since people may well come across such things, not have any idea what they are, and look them up. Things like C₈H₁₀N₄O₂ should be excluded. (But this opinion is liable to change without notice.  :-) )) So I don't feel comfortable putting my name on the list below, supporting inclusion, since that sorta looks like I'm supporting inclusion generally of all the things listed above (although I know others, such as CI and EP, have listed themselves there and clarified that that's not what they mean).​—msh210℠ 16:40, 22 March 2010 (UTC)[reply]
  4.   Adding a catalogue of books to the dictionary? Seriously? But apart from that, this would be a departure from the principle of “all words in all languages.” We document real languages as they are used. We do not prescribe, or venerate prescriptive “authorities.” To open that door would be to bring in a million sum-of-parts medical and chemical terms which are fabricated for translation dictionaries and have never been used. And a list of every star (HD 128620?). And Klingon (qoSlIj DatIvjaj). And standard ball bearing gauges, and functions in programming libraries, and ham radio call signs, and who knows what else? Let's just make a great dictionary before we add tits to this bull. —Michael Z. 2010-03-24 05:59 z

Support inclusion

  1.   Support Mglovesfun (talk) 18:33, 20 March 2010 (UTC). I never thought that anyone was gonna try and cite these, I think some (probably not all, I grant you) are attestable, just nobody succeed. Can you imagine how many cites there are for "en" that refer to other things? Possibly millions. We use these codes quite a lot, in virtually every template from {{context}}, {{etyl}} to {{t}}. I wouldn't mind an exception for this, in the same way that I doubt that England, Wales and Scotland would actually pass CFI directly, we rely on an "unspoken" consensus that we keep names of countries evern without attributive cites. Mglovesfun (talk) 18:33, 20 March 2010 (UTC). Addendum I was only referring to ISO 639 codes, not all ISO codes. Mglovesfun (talk) 10:28, 21 March 2010 (UTC)[reply]
  2.   Support Conrad.Irwin 19:00, 20 March 2010 (UTC) Though a poll like this is not accurate enough. I am in support of including well defined, reasonably sized sets of well used identifiers, ISO 639, 15924, airport codes, unicode code points, top-level-domain names, standard units etc. I am not hugely in favour of including ill-defined, or excessively large sets, i.e. not ISBNs, CODENs, chemicals (names or codes), all numbers, DUNS, domain names, etc. Mainly because this is a pointless attempt, partly (for numbers/chemicals) the names are just sum-of-parts, partly because they merely represent commercial entities. I think this opinion is roughly equivalent to the informal consensus that has evolved on Wiktionary thus far. It is an open question as to whether formatting these as "translingual symbols" is really the best way of doing it, but it seems adequate enough for now. Conrad.Irwin 19:00, 20 March 2010 (UTC)[reply]
    But is there reasoning behind this point of view aside from inertia? What does it matter if the identifier or identifier system is rare? We include many {{rare}} terms and languages. What does it matter that the size of the class is large? If you think some unattested identifiers should be in Witkionary, ISBNs would actually be quite easy to add (they could be bot added and protected to prevent vandalism). If you think people come here looking for these identifiers, we might want to include the ones that are technically sum-of-parts, since few average readers could delineate the parts. In fact, however, it appears from Wiktionary:Most missed articles that people don't search for these identifiers here. As they don't appear in natural language, people are aware that they aren't words/terms and don't search for them here (they're all defined on easy to find websites). --Bequw → τ 02:13, 21 March 2010 (UTC)[reply]
    In my opinion, yes, though I suspect you will disregard my reasoning. Firstly it is clear that all identifier sets are used in websites and applications like ours; I imagine they are not so used in English prose (though I suspect they appear in many technical manuals), our CFI has no way to deal with that situation. Secondly, and more importantly, it is clear that people are interested in defining such sets; this implies to me that there will be some interest in looking them up (incidentally note the "most" and "missed" parts of that page's title, many of the things I want to include would not be missed, and many of them are not interesting enough to get multiple hits every day). Now, why to exclude large sets, and not ignoring the partial reasons I gave above. For the sum-of-parts sets, we could provide definitions, however it's far more useful to the reader to find a document explaining how the parts are made up, this is more efficient for everyone; conceivably in the future we could work out how to automatically generate the meaning of these terms "on demand", including them literally is wasteful and repititous; more formally I suppose the entropy of such sets is low, so the value of each entry is tiny. Large sets are also used in websites, but typically they are not used literally, for example, MediaWiki has a set of files MessagesXxx.php, with Xxx being the language code, some software uses the list of top level domains to validate email addresses; it is not posible to imagine a situation where using ISBNs or CODENs like that would be useful, there are too many of them to handle; thus any application using them is going to use them from a dataset that already knows what the ISBN means. Secondly, and again importantly, there seems to be no interest in definining these terms, so one can only assume there is little interest in looking them up.
    There does not need to be a technical specific reason for everything (though there often is if you look), what people are interested in is a much better criteria than CFI (which should aim to describe what people are interested in, or they will just ignore it). Given that we can't find out what our readers are interested in, we should use what data we have from our editors. This is a wiki, we shouldn't be afraid to let it grow in the manner it wants, sure some tending and pruning is needed, but lopping off an entire branch is taking liberties. Conrad.Irwin 10:04, 21 March 2010 (UTC)[reply]
    If I may play devil's advocate: there's obviously a lot of user interest in adding made-up terms; but aside from Richardb, I'm not aware of any regular contributor who supports allowing them. —RuakhTALK 15:46, 21 March 2010 (UTC)[reply]
    In such a case we would be spreading disinformation, which is clearly harmful. Including too much information doesn't seem damaging to me. Conrad.Irwin 15:50, 21 March 2010 (UTC)[reply]
  3.   Support EncycloPetey 19:05, 20 March 2010 (UTC) I'm for including ISO codes for langauges and the codes for scripts. I think the standard journal abbreviations might need some investigation, as I'm not sure there's just one standard, but would support these too if there were a single standard and a reference to refer to. I would not support including ISBN codes, in part because of some of the same reasons Conrad has already stated. --EncycloPetey 19:05, 20 March 2010 (UTC)[reply]
    What would it matter if there were multiple identifier standards for a class of objects? Indeed, ISO 639-1 & 639-3 have different identifiers for identical languages. We don't, for instance, limit ourselves to a single term for man and welcome synonyms. --Bequw → τ 01:46, 21 March 2010 (UTC)[reply]
    You misunderstand. What I mean is that if each publisher / editor uses their own set of abbreviations specific to their publications, then the abbreviations would not be general enough for me to see it included. However, if there are agreed upon standards used across many publishers and publications, then there's a greater likelihood that such entries could be useful. --EncycloPetey 01:52, 21 March 2010 (UTC)[reply]
  4.   Support —Internoob (Disc•Cont) 20:14, 20 March 2010 (UTC) As per Conrad.Irwin.[reply]
  5.   Support Yair rand 01:38, 21 March 2010 (UTC) At least the ISO 639 and 15924 stuff. --Yair rand 01:38, 21 March 2010 (UTC)[reply]
    Why? It would seem that only editors would want to look these up. And if we're defining terms based on the needs of editors, why not add all template names as well to the main namespace? --Bequw → τ 02:21, 21 March 2010 (UTC)[reply]
    Because ISO codes are symbols, commonly used to refer to specific things, even if not in standard spoken or written communication. They clearly mean something. Emoticons don't exactly fit into language either, but they definitely mean something, so we toss them in and mark them as translingual symbols. The ISBN stuff doesn't really have a clear meaning though. --Yair rand 02:37, 21 March 2010 (UTC)[reply]
    I also dispute above that they are not in use. Nobody really bothers citing RFVs which is why have stuff from 2007 that should be deleted immediately, but only isn't because nobody has even attempted to cite them. This seems to be a case of putting CFI ahead of the user. The day a written document becomes more important than Wiktionary users is the day we should all quit. Mglovesfun (talk) 13:21, 21 March 2010 (UTC)[reply]
  6.   Support While other sites may contain this kind of information, I think that Wikt. is about the only single entry search and find site which gives the user a quick reference. Take cat = official language code of Catalan and Valencian for example. -- ALGRIF talk 14:07, 21 March 2010 (UTC)[reply]
  7.   Support. Come now, we know these exist. They are not the kind of made-up thing that we really want to keep out. bd2412 T 15:26, 21 March 2010 (UTC)[reply]

Other

  1. I support either Bequw's way or Conrad.Irwin's way, as long as the question gets resolved one way or the other. Please count this as a straw-vote in favor of whichever option gets more straw-votes. :-)   —RuakhTALK 19:42, 20 March 2010 (UTC)[reply]

Comment

Wiktionary:Votes/bc-2010-03/User:Stephen G. Brown for bureaucrat

Does what it says on the tin. Mglovesfun (talk) 13:36, 21 March 2010 (UTC)[reply]

anthropo

Currently, the word anthropo is a red link. But anthropo- exists as a blue link; it is defined as a prefix. Can the lack of hyphen in anthropo be recognized and result in automatic redirection to anthropo-? By extension, other prefixes and suffixes without hyphen could be auto-redirected as well, like danielle redirects to Danielle. --Daniel. 17:58, 21 March 2010 (UTC)[reply]

Done. Conrad.Irwin 18:08, 21 March 2010 (UTC)[reply]
Good. Thanks. --Daniel. 23:34, 22 March 2010 (UTC)[reply]
Nice. —Michael Z. 2010-03-23 22:26 z

WT:RFDO#October 2009

C'mon guys. Mglovesfun (talk) 20:47, 21 March 2010 (UTC)[reply]

Being above the fold matters

This article from Nielsen-Norman Group provides basic facts about typical human behavior on web pages. One tidbit:

Information foraging theory says that people decide whether to continue along a path (including scrolling path down a page) based on the current content's information scent. In other words, users will scroll below the fold only if the information above it makes them believe the rest of the page will be valuable.

-- DCDuring TALK 16:25, 22 March 2010 (UTC)[reply]

I would like to propose moving the Etymology and Pronunciation to below the definitions. This would have the advantages of:
  1. Moving definitions up (see hello, even on my screen I can't see any meanings).
  2. Unifying disparate part of speech sections (see flag, for a page this would seriously help).
  3. Making the format of these sections consistent with other sections (i.e. we could use {{sense}} to differentiate - added bonus, this makes it much easier to write editing tools).
  4. Making it easier to keep Etymological information specific (i.e. there's no need to create an entire new set of headings to add one definition)
Clearly there is a phenomenal amount of inertia with the current system, and clearly there are many people who prefer it, for those of an Etymological bent (and presumably we, as a group olf philologists, have plenty), that is the interesting part of the page. I contend, and believe there are others who would agree that Joe Average is more likely to be looking for definitions.
In detail, my proposal is that, where Etymology/Pronunciation information is specific to one part of speech, the section is nested under that part of speech (like translations and synonyms), I'll leave it to the Jury to decide exactly where in the list of headings it should come; in the case that the Etymology/Pronunciation covers multiple parts of speech the Etymology/Pronunciation section can be un-nested, below the part-of-speech sections, but above the other unnested sections.
There are problems with this proposal.
  1. Makes Etymology/Pronunciation harder to find.
  2. Sense-specific Etymology/Pronunciation may not be necessary.
  3. Requires fixing all existing pages.
  4. Breaks anyone who is trying to extract our Etymology/Pronunciation.
I don't regard the first as a problem, compared to the benefit of making definitions easier to find, the second can be dealt with nicely using # broad defintions and ## specific senses; relying on the notion that Etymology/Pronunciation that is marked as covering the broad definition also covers its subsenses (unless otherwise indicated, naturally).
The third again, is a non-issue. Having some pages in the old format around for a while does not matter a bit, additionally most pages will be fixable using a bot (i.e. any that have just one Etymology section, or one Etymology section per part of speech, and, I imagine, many of those that have multiples). I don't know of anyone who is currently trying to extract this information from us as suggested by point four, most interest has been in the Translations section (which is, by the way, the thing we are by far the best at).
Sorry for the lengthy post, is anyone else for doing this? (I would ask you to vote, but this needs some intelligent debate first) Conrad.Irwin 22:54, 22 March 2010 (UTC)[reply]
I don't understand what you would propose for an entry like (deprecated template usage) flag with its four etymologies for four distinct groups of meanings. Also, at least one of the etymologies has two parts of speech. A mock-up would be a help.
How would it help a human user to run together the senses of (deprecated template usage) flag}, (deprecated template usage) flag, (deprecated template usage) flag, (deprecated template usage) flag?
As to our supposed excellence in translations, I still don't understand how the translations can be better than the definitions, unless the definitions are ignored. DCDuring TALK 01:12, 23 March 2010 (UTC)[reply]
Wiktionary:Usability/flag is what I proposed above. I have just rearranged what is currently at flag, and both pages could do with a lot more work. I find working with the etymology attached to senses makes it more obvious where senses are related, clearly the "abbreviation of capture the flag" didn't come from the Middle English as is implied by our current entry. I pondered for a while about whether to join the Etymology sections of the Noun and Verb together into one uber-section, but I did not as it seems likely to me that the verb senses are derived "from the noun", not from the earlier etymons (though I have no talent or experience in etymologizing).
To your other points: I think it is useful to have all the same information in the same place, it makes it easier for a human that has decided "I want to find out what X means" or "I want to find out the Etymology of X", instead of looking in six or four places, they may now just look in two (or one, if they know that they want a Noun or Verb definition). If they decide, having found the definition or etymology they want, in either case they have only one place to look. It is perhaps merely that everyone else is less good at translations, our sense handling good do with a lot of improvement. Conrad.Irwin 02:56, 23 March 2010 (UTC)[reply]
(slightly off topic) That usability page is beautiful. I've never liked the etymologies being separated because with entries with multiple etymologies for one PoS it's a matter of guesswork finding which definition you want. -- 124.171.169.189 01:54, 24 March 2010 (UTC)[reply]
I fully support moving pronunciation and etymology below the definitions. (I've made that change to WT:ELEE at some point, though perhaps it's been reverted by now: I don't know.) I was thinking that these should nest under language, not POS, even if POS-specific, as paragraphs in the Etymology section can discuss the different POSes' etymologies — but I'd be happy with CI's solution, too. Everything else (except {{also}}) should also be below the definitions, viz alternative spellings/forms and {{wikipedia}}/{{pedia}}.​—msh210℠ 16:02, 23 March 2010 (UTC)[reply]

Google there is no fold for some contrary information, including detailed studies. Nielsen-Norman tested a wide variety of sites: please remember that ours is a deep reference site, so we are probably skewed away from the average.

Nevertheless, on the one hand, it is still good usability to let hurried readers find what they want easily. On the other hand, Our primary function is as a central repository for structured dictionary data, and others can create alternate interfaces (e.g., Google define:above the fold, get a dictionary app for your phone, etc). —Michael Z. 2010-03-23 22:25 z

I am of the opinion that making the Etymology/Pronunciation sections consistent with the rest of the entry improves our ability to function as a structured data store. The current "nested" situation is very open to misuse, with definitions being snuck under etymologies to which they do not belong; it also requires separate handling to other sections (I was thinking about the #Entry creation aider idea above, with nesting of etymology and pronunciation sections it becomes significantly uglier). That said, this problem could be solved without moving the etymology section, just uniting them all at the top with some {{sense}}'s. Conrad.Irwin 23:40, 23 March 2010 (UTC)[reply]
Mostly re MZ.
Just like in Lake Wobegon, eh?
For new users, the first experiences are likely to influence their willingness to click through subsequently. For monolingual English dictionary users, the group most often affected by our all-too-frequent lack of visible definitions on the landing-page, there are several sites available. We are not the leaders. If we lose too many English monolinguals we will not provide high-quality and contemporary translation targets and would have a tougher path to success as a multilingual dictionary.
A non-contributing repeat user of an English dictionary is likely to opt for the site that generates quick, accurate information at the user's level of sophistication. AFAICT, we have middling-to-worse download times, very good coverage, good (not great) reliability, poor consistency, not-so-good within-site search, not-so-good search-engine placement, and middling presentation of information for highly polysemic words (problematic for any dictionary).
Are repackagers of our information real or just a rhetorically useful fantasy? Who are they? How many users do they reach? What are we doing to make our work more useful to them? Who is in regular contact with them? Among the OneLook monolingual dictionaries, I see little evidence of use of our definitions. Are we currently even doing much to make ourselves useful to WP users by inserting links to good en.wikt entries? DCDuring TALK 23:56, 23 March 2010 (UTC)[reply]
For definitions, http://ninjawords.com - ninjapancake is occasionally in irc://irc.freenode.net#wiktionary. I have also, in the past, helped various folk parse translations sections and download all our audio files, there are also a number research papers published about Wiktionary, mainly trying to use us to establish a semantic network automatically. I had a quick scan through a few just now: in one they make use our glosses [12], in one they find our translations sorely inadequate (from two years ago, maybe we've improved) [13], in one they find us the most useful of three [14] but feel we have too many "dangling references (i.e. links to a page not to a sense)". Conrad.Irwin 00:56, 24 March 2010 (UTC)[reply]
Bleurgh. I hate it. Nor do I think we should be tailoring our pages to the kind of casual users who need to be enticed to scroll down. Crazy idea, but how about we actually write this stuff aimed at people who give a shit in the first place? Ƿidsiþ 06:13, 24 March 2010 (UTC)[reply]
Do you hate the merging of the etymology sections, the moving them from the top, or both? Can you qualify why, maybe someone can dream up a compromise? Conrad.Irwin 20:27, 25 March 2010 (UTC)[reply]
Accepting the "anyone" portion of the edit-summary invite#Noun, I think that etymology top level structure segregates senses of homonyms. The (deprecated template usage) flag case seems a perfect example. The four etymologies form clearly distinct clusters of definitions. I would be perfectly happy if all etymology and all phonetic alphabet material were hidden by default and only visible to registered users who opted to have said show/hide bars open by default. DCDuring TALK 22:07, 25 March 2010 (UTC)[reply]

Glosses

If we were really trying to be a resource for repackaging we would stop playing these silly games with glosses (Wiktionary:Usability/flag has 6 sections using them) and find a better way to link information to senses. Category:Translation table header lacks gloss has almost 1000 members and hasn't shrunk significantly in months. Are we going to create Category:Synonyms section lacks glosses, etc.? Nadando 01:08, 24 March 2010 (UTC)[reply]
Glosses work, I have written software that uses them, and the research paper above also uses them; they are also easy for people to understand. What we don't do is to include the gloss on the definition line, but, by definition(:p) the gloss is already a summary of the definition line, so it seems kind of wasteful. The alternative is to turn our current format on its head, and use definitions as headings, and have all information nested underneath. As it is possible to do that transform automatically, providing that glosses are present, (see "paper view" in WT:PREFS that was doing that in 2007, maybe broken by now, I haven't checked), I think such a drastic change is not needed here.
There are problems with glosses. Mainly, not everyone uses them, this can be fixed by educating people. The second issue is that they don't seem to be reconsilable, take -phyte for example, there are four definitions, and one translations section - is this because there should be four translations sections, or because there should only be one definition? There's only one derived terms sections too, surely that should match the number of definitions... This is only a problem because glosses are too flexible, if we had a strict relational model, then we would have to get the definitions correct first time - as it is, it doesn't matter if the definitions are a bit squiffy, someone can come back and fix them later. The main culprit of this situation is that it's a lot of effort to work out what words mean, it's far easier to slap another {{trans-top}} and leave it for the next guy to sort out than to fix the definitions at the same time. Maybe if we made it harder for people who leave off glosses (by pestering them with a suitably worded {{glossy}} warning if they forget, or perhaps by installing mw:Extension:AbuseFilter and making it pester them) things would improve.
Finally, don't be disheartened, we have 100,000 english pages, so 1000 without a gloss means 99% of them are good :). Another drive to get that category clean would not go amiss though. Conrad.Irwin 01:50, 24 March 2010 (UTC)[reply]

The page and entry structure could use improvement. Adding a subheading level for terms with multiple etymologies per term is wonky. This dictionary doesn't use <dfn> for defined terms, <abbr> for abbreviations, <cite> for cited sources, nor <q> nor <blockquote> for quotations. Maybe we need to go to a microformat or HTML5 structural model, someday.

We are also building a huge citation file, but unfortunately each citation is only associated with one word in the citation. There's no way to get past this and some other issues without moving to a relational model. Just daydreaming. —Michael Z. 2010-03-24 06:29 z

Berber language code(s)

Can somebody help to create a code for Berber (Tamazight), please, eg. {{ber-tam}}? See the Grease pit discussion. I think that it's possible to have one generic code for simplicity. I am not planning to do much work in Berber but it seems that we need it for completeness, anyway. --Anatoli 23:59, 22 March 2010 (UTC)[reply]

I'll do it if nobody objects, sure. If you want to object, please do so soon! Mglovesfun (talk) 18:49, 23 March 2010 (UTC)[reply]
I'd prefer to keep Tamazight and Kabyle separate. They have separate literary tradition and some linguistic differences. -- Prince Kassad 19:50, 23 March 2010 (UTC)[reply]
  • I used to live in Morocco and was quite into Berber for a while. In Morocco they have a "standard" form taught in schools, which they call Tamazight, and I did some Wiktionary stuff using that name; but because Tamazight has no ISO code, other Wiktionary editors changed it to "Central Atlas Tamazight", which is really much too specific (Moroccan "Tamazight" in practice is an amalgam of the commonest shared elements of Central Atlas Tamazight, Tachelhit and Tarifit, among others)...and it all just got very confusing, and left me convinced that "Berber" or "Tamazight" would be the best heading, with def-line context markers to specify words which are only used in specific dialects. However on the other hand, you do have dialects like Kabyle which have always been quite independent. Ƿidsiþ 20:28, 23 March 2010 (UTC)[reply]
Widsith, what do you suggest? Can we have some common code where we could add all varieties? We have 6 two 8 groups. Like Chinese they could subclassified by other groups. Mglovesfun, please create, if you can. Widsith, do you object? Any other objections? If they have to be subdivided, please start with Central Morocco Tamazight (tzm). --Anatoli 04:57, 30 March 2010 (UTC)[reply]
See my latest edit, I used tzm to add a Central Atlas Tamazight translation of Casablanca. --Anatoli 05:00, 30 March 2010 (UTC)[reply]

StringFunctions

I would like to request that the String functions be available for use on this wiki (specifically for this). —Internoob (Disc•Cont) 02:34, 23 March 2010 (UTC)[reply]

See [15]. --Yair rand 02:40, 23 March 2010 (UTC)[reply]
Please vote for bugzilla:20246, mw:Extension:Transliterator could handle that for you easily (hey, it could generate SAMPA from IPA directly :D). I have been trying to get that installed for 8 months now, if anyone has bright ideas as to how we encourage Wikimedia to listen to us, please share! Conrad.Irwin 02:59, 23 March 2010 (UTC)[reply]
SAMPA from IPA directly??? I want it NOW. (I've voted for it!) Pharamp 19:58, 23 March 2010 (UTC)[reply]
support what Pharamp's supporting. --Rising Sun talk? contributions 13:45, 24 March 2010 (UTC)[reply]
Wiktionnaire has a Js gadget that transliterates IPA -> SAMPA. Why don't we install (w/ appropriate modifications) that in the meantime? --Bequw → τ 17:20, 7 April 2010 (UTC)[reply]
Seems like a good idea, I looked at it once, but never took it anywhere. User:Conrad.Irwin/ipa2sampa.js. Conrad.Irwin 17:36, 7 April 2010 (UTC)[reply]

Phrasebook

If en.wikt is to have a phrasebook at all, then the phrases have to be accessible to someone who is trying to say something or is preparing for a type of social encounter, broadly defined. If we have normal entries for such phrases, the last thing we need is an Appendix that offers a very incomplete list of such phrase, alphabetically organized. Unfortunately, that is all that is in Appendix:English phrasebook, except for two redlinked items and an apology for phrases being SoP. The apology is already in Wiktionary:Phrasebook. A much more inclusive list, still pathetically incomplete, of such items appears in Category:English phrasebook.

Taking as an example McGraw-Hill's NTC's Dictionary of Everyday American English Expressions, by Spears et al, we would expect to need something more than the 18 major categories, 774 "topics", and 7,000 English phrases they have to make a useful phrasebook. At present we have 3 "topics" and 134 phrases. We probably have some number more among our idioms and possibly among Category:English phrases and Category:English interjections. Thus, it seems that what we have is, at best, a placeholder for the idea of a phrasebook.

The most important missing element, IMHO, is some kind of user-centered typology of phrases. The typology would map to a category structure. IF we can keep a user focus, then some steps such as the following might lead to a useful phrasebook entry category structure:

  1. Examine all idioms and phrases for items that might be good candidates for a phrasebook by reason of utility and commonness and place candidates in the appropriate top-level category, eg Category:English phrasebook, or in an ad hoc temporary category, eg English candidates for phrasebook.
  2. Find candidate categories by reviewing the members of the category or categories.
  3. Find user-centered typologies of phrases from print phrasebooks, sociolinguistics, pragmatics, discourse analysis, and other sources.
  4. Integrate into a usable category structure.

Having an initial category structure would then enable contributors to fill in phrases that would populate the category structure. As many casual contributors and anons will probably feel that they have something to contribute, we would need some comprehensible criteria for inclusion/exclusion or we would need to simply accept a possibly large number of contributions. Attestability seems insufficient. Perhaps we could initially use some simple maxima in number of characters (say, 40) and number of words (say, 8).

What say all? DCDuring TALK 17:45, 23 March 2010 (UTC)[reply]

Sounds good, but I think a WT page for candidates might be better than a category, though (Wiktionary:Phrasebook candidates?). We'd need to set up a standard procedure for getting these into the phrasebook without too much bureaucracy. Another issue is what to do with the definitions of non-idiomatic phrasebook entries. (And should there even be idiomatic phrasebook entries?) Some of these have "this entry exists for translation purposes only", some have "Sum of parts", some explain the individual parts, and some don't have a definition line at all. --Yair rand 18:06, 23 March 2010 (UTC)[reply]
If we take a human-user-centered approach to phrasebook entries, then there is no reason to distinguish between idioms and non-idioms and between single-word and multi-word entries for normal-user purposes, assuming we intend to serve such (by no means evident from our behavior). The user's sole interest is in whether the entry is useful as a stand-alone expression in discourse. Thus (deprecated template usage) yes and term|you betcha}} are both positive responses to questions or orders. I don't see how we can dispense with most of the accoutrements of a full entry for phrasebook term: alt forms (contractions, etc), etymology (often ellipsis), context tags, gloss or non-gloss definition, usage notes, synonyms, antonyms, coordinate terms, etc. The prosodic elements of a phrase would seem to make pronunciation valuable. I suppose we could dispense with anagrams (available piecewise). DCDuring TALK 18:29, 23 March 2010 (UTC)[reply]
The current category includes phrasebook entries such as where are the toilets, which would be better grouped in an appendix (much easier to find, and more consistent with wiktionary principles), and entries really needing an entry (either idiomatic phrases or set phrases), such as to whom it may concern. These cases should be discussed separately. Lmaltier 06:46, 24 March 2010 (UTC)[reply]
How would an Appendix work for inducing translators to translate phrases or organize them? There is no provision for inserting translations there.
Conventional entries would seem to help for that purpose. A comprehensive set of situational categories could help folks find various expressions for types of situations. Even something like a Wikisaurus page would seem to address differences in register and variations in situation. An appendix would seem most useful to provide guides to all of the terms relevant to a situation including the generic ones, such as greetings, farewells, responses, etc.
Usually, in phrasebooks, phrases are organized by topic (shopping, travelling, etc.). There could be an appendix by language, with the correspondence English -> language. This is the best solution, because the starting point (English sentence) may exist with lots of variations. What I propose is only for phrases clearly not deserving their own entry in a language dictionary. Lmaltier 18:40, 24 March 2010 (UTC)[reply]

Wikimania Scholarships

The call for applications for Wikimania Scholarships to attend Wikimania 2010 in Gdansk, Poland (July 9-11) is now open. The Wikimedia Foundation offers Scholarships to pay for selected individuals' round trip travel, accommodations, and registration at the conference. To apply, visit the Wikimania 2010 scholarships information page, click the secure link available there, and fill out the form to apply. For additional information, please visit the Scholarships information and FAQ pages:

Yours very truly, Cary Bass
Volunteer Coordinator
Wikimedia Foundation

User:MewBot, a Dutch form bot - request for bot status

I've written up a bot script to take care of Dutch verb forms, which are still lacking in many cases. The bot works by giving it an entry to look up. Then it extracts the templates {{nl-conj-wk}} and {{nl-conj-st}} from the page, and uses them to generate the necessary verb form entries with {{nl-verb-form}}. It then submits those new entries if the page does not already exist. If it exists, it checks for a ==Dutch== section, and if none is found it adds the entry to the bottom of the page. It adds {{rfc-auto}} to the page so that User:AutoFormat can put the entry in the proper place. (Note that this may be fixed if this proposal goes through.)

The bot itself uses the Pywikipedia framework and is based on some of the code from User:SemperBlottoBot. The code can be viewed at User:MewBot/nl-conj.py, though this is my first real experience with Python, so some of the code might not be very 'Pythonesque'. It has been tested and things seem to work nicely. I'm still slightly concerned about flooding, since I got an error about it while testing (it tried to do too much in one go and the wiki blocked it for a few seconds). I'm not sure how to circumvent this except just letting it wait for one second or so after each entry. Then again I'm not sure if it's really a problem, either.

There are a few things I plan to improve. Firstly, I plan to include support for irregular verbs. The template for those ({{nl-conj-irr}}) is a bit more complicated so I forwent adding support for it. Another improvement is to have it automatically read a list of things to do from a 'feed me' page, so that I can just run it and let it do its business. And finally, I might create two more scripts to handle adjective and noun forms, if I get around to it. --CodeCat 13:57, 25 March 2010 (UTC)[reply]

Start a vote, go for it. Sounds good to me. As long as it works, who could possibly object? Mglovesfun (talk) 14:35, 25 March 2010 (UTC)[reply]
Well, vote ahead I suppose. I don't post in BP too often so I'm a bit rusty. :P --CodeCat 14:41, 25 March 2010 (UTC)[reply]
start your vote here. Conrad.Irwin 15:51, 25 March 2010 (UTC)[reply]
Done. Vote away! --CodeCat 18:20, 25 March 2010 (UTC)[reply]

Why British spellings are not British words

Of note, we don't have British spelling or American spelling, although I think these are definitely idiomatic as they don't refer simply to spellings used in the US or the UK. A British spelling is not a synonym of a British word - (deprecated template usage) colour is a British spelling of (deprecated template usage) color, but the word colour isn't only used in the UK. Gutted (meaning disappointed) is a British words. It might be used in the other English speaking places, but AFAIK not in the US. Similarly (deprecated template usage) sidewalk in not used in the UK. Paper dictionaries tend to favor simplicity over accuracy and lump everything under British or American no matter how simplistic that is. As pointed out by Ruakh, you can write in British English using American spellings or in American English using British spellings. Another point - paper dictionaries don't use categories, we do.

Hence to the meaty bit of my proposal - split Category:British English (English used in the United Kingdom) from Category:British spellings (spellings of a British style). Ditto for 'American English'. The dictionaries that Mzajac use that give (deprecated template usage) realise as chiefly British contradict the Oxford English Dictionary, that gives realise as an alternative spelling of (deprecated template usage) realize. Unlike the -or endings and the -er endings for (deprecated template usage) centre and (deprecated template usage) calibre, -ize spellings are considered standard in the UK, and have been for decades. Therefore glossing (deprecated template usage) realize as chiefly US is extremely misleading, or just plain wrong. Mglovesfun (talk) 19:15, 25 March 2010 (UTC)[reply]

I think you want to split Category:British spellings from Category:British English, given that that's where everything is now. I am neutral about that, it seems a very fine point of distinction, if you want to do it, go for it (see also the "from=" parameter on {{alternative spelling of}}. (Incidentally, I don't agree unreservedly that [British spelling] or [American spelling] deserve an entry - so find some cites before creating them!). Sweeping generalisations as to how words are spelt will get no-one anywhere. Find cites (though references will probably do, and be significantly easier to verify), then you have documentation that you can refer our readers to; it is not our place to pass judgement, we just document what we find. Conrad.Irwin 20:25, 25 March 2010 (UTC)[reply]
I'm no expert on the subject, but isn't the issue of different spellings very similar to the difference between traditional and simplified Chinese characters? In both cases they represent the same word, and it's only the representation that is different. I've had a bit of a look and it seems that the entries for Chinese words barely distinguish traditional/simplified at all, they only list the 'other' spelling. The categories however show for example 'Mandarin nouns in traditional script' and 'Mandarin nouns in simplified script'. So maybe we could take a similar approach here. 'English nouns in commonwealth spelling' and 'English nouns in U.S. spelling'? --CodeCat 20:35, 25 March 2010 (UTC)[reply]

Realise

"Sweeping generalisations as to how words are spelt will get no-one anywhere". Well I think that's what Mzajac is advocating. Dictionaries that use 'British' use it to avoid using the full list of countries where it's used. As I said, simplicity instead of accuracy. Dictionaries that say that (deprecated template usage) realise is British give the impression that in the UK it is always spelt (deprecated template usage) realise, while the OED gives realize as the primarily spelling. Hence why even British user like SemperBlotto and Equinox have the -ise forms as alternative forms of the -ize forms, not the other way around. Mglovesfun (talk) 21:09, 25 March 2010 (UTC)[reply]
Can you find evidence of "realise" being used as much in the US as it is in the UK? If not the definition as it currently stands "(chiefly British) Alternative spelling of realize." is accurate, and agrees with the referenced dictionaries. It sounds like you are misunderstanding something, but I don't see what. Conrad.Irwin 21:47, 25 March 2010 (UTC)[reply]
Well I think you can either categorize British words and British spellings separately or not at all. Just don't categorize them together. I think any -ize spelling (apart from (deprecated template usage) franchise and a couple of others) can be turned into -ise using British spellings, even if not used in the UK. While I can't think of one, any such spelling used in Australia, New Zealand (et al.) but not in the UK would still be a British spelling, even if not used in the UK. Any better? Mglovesfun (talk) 11:33, 26 March 2010 (UTC)[reply]
Actually, Mg, I tend to spell with -ise (but I've agoni*ed about it sometimes). I mostly — not always — enter the -ize form as the primary entry because it's more common worldwide (and thus more "standard" globally and more likely to be attestable), not because of any trend of usage I might know about in the UK. There are definitely some I've seen where -ise wouldn't meet CFI. Equinox ◑ 16:50, 29 March 2010 (UTC)[reply]

Translation table labellers

I have just enabled these for everyone, including anonymous users, in an effort to help plough through Category:Translation table header lacks gloss. Personal options can be set as follows:

You don't have the current version of the gloss editor.
You don't have the current version of all editing features.
NB. logged in users can also set this option permanently by going Special:Preferences, then to the gadgets tab, and checking "Disable translation editing".

If this is found to cause problems, please let me know. Conrad.Irwin 02:52, 26 March 2010 (UTC)[reply]

It broke completely for me. It says "You don't have the current version" and now the editor.js is completely disabled. -- Prince Kassad 10:21, 26 March 2010 (UTC)[reply]
I was using a keyword for a variable name, which may have caused errors on some browsers. Is it working now? If not, what browser do you use? Conrad.Irwin 11:29, 26 March 2010 (UTC)[reply]
Ok, now it works like it used to before. -- Prince Kassad 11:43, 26 March 2010 (UTC)[reply]

First tgloss vandalism. Maybe mortal IPs shouldn't have this tool auto-enabled. Cleaning up Category:Translation table header lacks gloss is a tricky issue. --Vahagn Petrosyan 14:35, 27 March 2010 (UTC)[reply]

"Misc" character set in editing interface

Sorry that I don't know the technical term for this, but there is a drop-down menu containing character sets for an array of languages accessible in the editing interface. I just wanted to raise a proposal that the character set title "Misc." be retitled to something such as "Formatting" or "Symbols" or "Puncuation"--I think these would more adequately describe the characters in that set, and indicate that they are language-neutral.--达伟 16:07, 26 March 2010 (UTC)[reply]

Template:Xyzy

So we started using this thing sometime last year, but I really don't think it's particularly helpful. It saves us some typing, but I don't think that balances out all the work it does on entries with lots of translations (case in point, as usual when it comes to server load, is water). Even Ullmann admits that the overhead is so much that we can't even use this for all languages that would need it. Only the "biggest" ones. So given that, could we possibly phase this thing out? — [ R·I·C ] opiaterein — 17:37, 26 March 2010 (UTC)[reply]

It is very helpful to me; saves me a lot of typing. Besides, I have already left out the sc= parameter in thousands of instances because of Xyzy. --Vahagn Petrosyan 18:03, 26 March 2010 (UTC)[reply]
Add sc in every {{l}}, {{term}}, {{infl}}, and every other general template? That would waste a ridiculous amount of time. --Yair rand 18:13, 26 March 2010 (UTC)[reply]
I agree with both of you. Mglovesfun (talk) 18:16, 26 March 2010 (UTC)[reply]
That could be done completely automatically by a bot. --Ivan Štambuk 18:21, 26 March 2010 (UTC)[reply]
Alright, so we don't care about minority languages and we'll just assume that no one is ever going to add to them. But if they do, we're going to burden them with the extra typing because it's not useful enough to include them in comparison to the extra work the template has to do. I hate you all :D — [ R·I·C ] opiaterein — 19:45, 26 March 2010 (UTC)[reply]
I'm wondering - if it's the #switch thing that's causing all the overload, perhaps moving that list of languages to subpages could help reducing the overload a bit. -- Prince Kassad 19:48, 26 March 2010 (UTC)[reply]
Yeah, that makes sense. </angry sarcasm> — [ R·I·C ] opiaterein — 19:54, 26 March 2010 (UTC)[reply]
Well, if the #switch thing could cause overload, and it is necessary for the scripts to be done automatically, would it make sense to run scripts the same way as we do the ISO-639 codes? Those don't seem to give any trouble. --Yair rand 20:02, 26 March 2010 (UTC)[reply]
I have no idea what you mean here. — [ R·I·C ] opiaterein — 20:15, 26 March 2010 (UTC)[reply]
For language codes, we have individual templates for each language code. For scripts, we have one template which accesses which language corresponds to each script through a #switch. What we could have is a template for each language's script, i.e. {{Xyzyen}} and {{Xyzyhe}} each of which would direct to the correct script. --Yair rand 20:19, 26 March 2010 (UTC)[reply]
We already have templates for the scripts. Some languages have more than one script. I still don't really understand. — [ R·I·C ] opiaterein — 20:25, 26 March 2010 (UTC)[reply]
It's simple - instead of that switch which compares the entered language code to all languages in the list, it would instead load a template like {{Xyzy:en}} (which is much easier on performance, since it just needs some use of {{{1}}}). This subtemplate would then contain the correct script to use. -- Prince Kassad 20:48, 26 March 2010 (UTC)[reply]
But what does that do for languages that have more than one script? Such as Serbian? —CodeCat 20:56, 26 March 2010 (UTC)[reply]
It doesn't, and {Xyzy} ignores/should ignore all such cases (which are quite numerous in fact). The whole point of {Xyzy} was to reduce typing effort, but the proper way that should have been handled is by setting up a bot which would detect script range used in a particular template parameter, and automatically add/correct the most appropriate sc=. --Ivan Štambuk 21:12, 26 March 2010 (UTC)[reply]
Are there any performance metrics to substantiate that, that the transclusion (which also involves template name lookup and comparison) works faster than static conditional resolving? How can one measure resources (memory, CPU time) involved in template expansion? --Ivan Štambuk 21:05, 26 March 2010 (UTC)[reply]
Performance statistics are added to every page. Open the page source and do a search for "NewPP". -- Prince Kassad 21:08, 26 March 2010 (UTC)[reply]
Seems to be correct: node count of switch statements grows linearly which step. In other words, MediaWiki works much faster when resolving template names than it's template language conditionals (or perhaps it doesn't, it's just that that particular operation isn't subject to constraints). These are all static code paths which sould be precomputed, cached and served in O(1)...It doens't make much sense to me at all. --Ivan Štambuk 21:49, 26 March 2010 (UTC)[reply]
Why are people contrasting a switch statement to a template load, at the moment {{Xyzy}} does "both". Providing all our script templates are of the form of {{Cyrl}}, then it can skip the template load completely:
<{{#switch:{{{face|}}}|ital=i|head|bold=b|span}} class="Cyrl">{{{1}}}</{{#switch:{{{face|}}}|ital=i|head|bold=b|span}}>
This would save time without losing functionality. Are there currently script templates that don't look like this? In which case please fix them :). The problem with trying to eliminate the switch is that every single one of the script templates would need to be created, unless you want {{ {{#ifexist:Template:Xyzy:{{{lang|}}}|Template:Xyzy:{{{lang|}}}|Latn}} }} everywhere (hint: you don't).
It is very naive to try and calculate whether a switch statement is "faster" than a template load, I imagine a reasonably sized switch is considerably faster than getting a template from the database (which involves "check memcached", "get from database", "give to memcached") though mostly templates will come from memcached much more quickly. As Ivan notices, Switch is O(n), template lookup is O(1), but there are large constant factors involved (which the parser output doesn't show at all), someone could plot pretty graphs if they had the patience.
There are other micro-optimisations we could try and make, maybe doing less checking of gender parameters, fixing #language to understand real codes (I might ask #mediawiki about doing that, though it'll take a loong time to propagate here) - (edit: someone already did!) and fixing Wikimedia to understand read codes too (heh, fat chance).
We could also try and write an extension that allows us to have O(1) pre-compiled #switch's this would also have the advantage of requiring considerably fewer templates on large pages (at a constant once-per-page cost of loading a much larger map), mw:Extension:Transliterator will let us do that to some extent, so we can play around a bit. Conrad.Irwin 23:05, 26 March 2010 (UTC)[reply]
Most of our script templates aren't, and shouldn't be, of the same form as {{Cyrl}}. Script templates serve two purposes: (1) they specify the class for our CSS to hook onto; (2) they control how the various faces (term, head, and none — also ital and bold, except that SFAIK no other template ever calls them with either of those) are implemented. For example, {{Latn}} italicizes terms (foo), but {{Cyrl}} and {{Grek}} do not (фю, φυ); all three of those bold headwords (foo, фю, φυ), but {{Hebr}} embiggens them (פֿוּ).
If we want, we can move all that logic out of individual script templates and into Common.css, and have script templates generate code like <span class="Cyrl face-term Cyrl-term" lang="ru" xml:lang="ru">фю<span> (where Cyrl specifies fonts, and possibly font-size; face-term specifies italics; and Cyrl-term de-specifies italics, because IIRC, selectors like .Cyrl.face-term didn't work in IE6). We can also restore, or partially restore, the older system, with names like RUchar and HEchar. (They would be synonyms for Cyrl and Hebr and such.) That would allow us to move all such logic out of Xyzy and into Common.css.
—RuakhTALK 13:08, 27 March 2010 (UTC)[reply]
It would seem possible to define (in Common.css) rules for b.Hebr {font-weight: normal; font-size: big; }; i.Hebr {font-style: normal;}; .Hebr { font-face: "blah"; } and so on. This would result in more consistent HTML, but I appreciate it's prone to people asking "hey, why doesn't bold work anymore?!?!?!" - we could use other tags in place of <b> and <i>, <em> and <strong> are less associated with their default appearance. Conrad.Irwin 13:31, 27 March 2010 (UTC)[reply]
Well, currently {{Cyrl|фю|face=term}} uses <span> (фю) and {{Cyrl|фю|face=ital}} uses <i> (фю); so if we changed both to use <i> and made <i> non-italic, we'd lose that distinction. But personally, I can't say that I'd be at all bothered by that loss. (And if the b.Hebr rule were also applied to b .Hebr and .Hebr b and .use-with-mention .mention .Hebr, that would really rock.) —RuakhTALK 13:45, 27 March 2010 (UTC)[reply]

Portuguese bot now ready

Hi all. Just letting you know that I've retrained User:Dawnraybot, who now does Portuguese verb forms. He can handle anything. --Rising Sun talk? contributions 14:26, 27 March 2010 (UTC)[reply]

Table of contents, again

Wiktionary:Votes/2010-02/ToC format failed, there was no consensus for any of the options. So, we're back at square one, ToC's taking up massive amounts of space, one out of four views are of pages that have the whole first screen occupied by the table of contents. Can anyone think of any alternatives to the current format of ToCs? Clearly all of the options available in the vote are unacceptable. I doubt that anyone thinks that the current format is the best possible. Should the current table of contents format continue, nearly all pages would eventually be obscured by an enormous table of contents, making the dictionary virtually unusable. Does anyone have any possible solutions? --Yair rand 20:41, 28 March 2010 (UTC)[reply]

You could enable hippietrail's nearbypages.js for anonymous users. Besides showing nearby pages, it also adds a table of contents in the left navigation column. -- Prince Kassad 21:26, 28 March 2010 (UTC)[reply]
I do not see any problem that urgently needs a solution. On a page that has a lot of content such as "cat", the table of contents is the first thing I want to see. I am not sure whether the current format is the best one, but it is more than good enough.
Is the calculation of the results of the vote available anywhere? I do not see it at Wiktionary:Votes/2010-02/ToC_format#Decision. --Dan Polansky 09:38, 29 March 2010 (UTC)[reply]
If we redo ELE so that the order of headings is ==Language, ===POS, ====Nyms/Rel/Der/Transl, ===Etym/Pron/Anag/Seealso/Links, then having the TOC show only L2 and L3 would help. In fact, any change to ELE that standardizes levels (so that e.g. Noun is always L3 or always Lwhatever) may help.—msh210℠ on a public computer 23:16, 3 April 2010 (UTC)[reply]

Wiktionary:Votes/2010-02/Accepting the results of the Wiktionary logo vote

The vote on whether to accept the new book logo is now live. I see no reason to delay the vote. --Rising Sun talk? contributions 21:34, 28 March 2010 (UTC)[reply]

Sorry, the work isn't done yet. There's still some work to be done with the text, and it would also be better if we waited until the localized versions for other Wiktionaries were available before we start deciding here. (We're still missing more than half of the necessary localization texts.) --Yair rand 21:42, 28 March 2010 (UTC)[reply]
But the English logo is ready though, and that's the only logo that will bother us locally at en.wikt. --Rising Sun talk? contributions 07:11, 29 March 2010 (UTC)[reply]

Category:Votes that have not been closed

Just came across this. It had 39 entries, which is clearly wrong as we don't have 39 active votes. I started deleting some that have never been open(!) but there are some interesting ones that I couldn't delete, as although the vote had never opened, there was some discussion about them, and it seemed better to open them rather than just delete them on sight. Mglovesfun (talk) 09:16, 29 March 2010 (UTC)[reply]

Why not just leave them unopened? Conrad.Irwin 12:30, 29 March 2010 (UTC)[reply]
I think you misunderstand the name of the category. When a vote is first created, it has not been closed — whether or not it has been opened yet. This is not a hypothetical Category:Votes that need to be closed; for that matter, it's not Wiktionary:Votes, which lists all active votes. Please only remove a vote from this category when the vote is "closed" in some way: either a decision is reached, or you determine that the vote is abandoned/withdrawn/superseded. (Don't get me wrong: cleanup is good. I'm just saying that it's not "clearly wrong" for unopened votes to be in there, as long as they seem likely to be opened eventually.) —RuakhTALK 13:41, 29 March 2010 (UTC)[reply]
Technically if they've never been opened, they've never been closed. At the risk of stating (what I think is) the obviously should we have three categories: Category:Votes that have not been opened, Category:Votes that have not been closed and Category:Closed votes all to be in Category:Wiktionary votes, which doesn't exist either (but will do in about two minutes). Mglovesfun (talk) 14:46, 29 March 2010 (UTC)[reply]

bonito

I've recently upgraded the inflection system of Portuguese adjectives. The main improvements were the addition of comparative and superlative forms and a parameter scheme that makes {{pt-adj}} technically similar to {{pt-verb}} and {{en-verb}}. I've also decided to create an inflection table to handle the various forms of comparable adjectives. My next step is to update the approximately seven hundred adjectives to conform to the new system. They would need to be updated anyway, to merge the functions of {{pt-adj}}, {{pt-adj-old}}, {{pt-adj-mf}} and {{pt-adj-form}}. For example, see the adjective bonito. --Daniel. 15:18, 29 March 2010 (UTC)[reply]

Dialects

I would like it if the context tag was (dialect) rather than (dialectal). Why? Because I would like to be able to do things like {{context|north-east|_|dialect}} which would auto-categorise in Category:Dialectal, AND produce a coherent tag, AND also allow me to specify a dialect area which doesn't necessarily correspond to a specific named dialect like Geordie. At the minute it's very hard for us to be specific about dialects, and our treatment of them is not great. Ƿidsiþ 16:54, 29 March 2010 (UTC)[reply]

I agree. If it makes things more clear and practical, then I don't see why not. —CodeCat 17:10, 29 March 2010 (UTC)[reply]
After a single 10-second edit, {{dialect}} (100 to 200 uses) is now a different-text duplicate of {{dialectal}}. Any complains? Circeus 01:56, 3 April 2010 (UTC)[reply]
Great! Thanks. Ƿidsiþ 10:10, 5 April 2010 (UTC)[reply]

Wiktionary:Votes/pl-2010-03/Placenames with linguistic information are accepted

Scheduled to start after Easter. --Makaokalani 13:07, 30 March 2010 (UTC)[reply]

Re "Placenames are words, and subject to the same criteria for inclusion as any other words": I disagree. "New York" is not a word. We can stipulate "word" to include all kinds of things, but, where I am coming from, "New York" are two words just like "black hole". I will oppose the vote already on this ground. --Dan Polansky 17:19, 30 March 2010 (UTC)[reply]
Just because it's not a single word doesn't imply much. We have plenty of phrase entries, which are made of several words. Furthermore, it's common for phrases to act as a unit within the sentence. For example 'with my friend' is a phrase that acts as an adverb of manner. The current criteria for including such phrases as separate entries is whether their intended meaning can be derived from the combination of the words alone - the meaning is a sum of the meanings of the individual parts. 'New York' definitely isn't a sum of parts, unless you take it to literally mean a new version of the city of York. Perhaps the word 'word' isn't applicable here, but that's not the meaning the original text indended. I think the proper term is 'lemma'. —CodeCat 19:20, 30 March 2010 (UTC)[reply]
Just call it a "term" or "name" and sidestep the issue of whether it's a "word". --EncycloPetey 21:28, 30 March 2010 (UTC)[reply]
I changed it into "term".--Makaokalani 16:23, 31 March 2010 (UTC)[reply]
Nonetheless, linguistically and lexicographically speaking (as opposed to typographically), if we can define "couch potato" as a word, then there is no argument to be made for the rejection of "New York". Circeus 01:52, 3 April 2010 (UTC)[reply]
Polansky, the definition of a "word" is completely arbitrary and language-dependent. By your orthographic criterion Serbo-Croat Njujork or Russian Нью-Йорк would be words meriting inclusion, but the English-language translations would not. Or e.g. Sanskrit mīmāṃsakasvāntasarojabhāskaram, which is orthographically and phonetically one word, but morphologically and semantically several words combined by sandhi. Objecting on purely abstract grounds should be reserved only for abstract discussions (e.g. the logo vote :) The primary driving motive for the extension of CFI to include new class of terms should be: "How is this doing a service to language learners/translators, the main target base of Wiktionary users". Placenames obviously could provide some very useful content and it would be a disservice not to have them. --Ivan Štambuk 00:41, 31 March 2010 (UTC)[reply]
Interesting. Han Chinese often think in number of characters, not number of words, e.g. describing 我不知道 (I don't know) as having 4 characters, rather than 3 words. Just a thought. Yes, importance of entries to users, not whether they are words or combinations should count. --Anatoli 00:48, 31 March 2010 (UTC)[reply]
I do not think I understand what you mean when you say that the definition of a "word" is "completely arbitrary". Certainly not any arbitrarily picked morpheme sequence can be seriously pronounced a word. I surely admit that there is some indeterminacy in the scope of the concept of a word, but that is far from being "completely arbitrary". I am actually not so much concerned with abstract definitions of "word" as with the actual practical scope of the concept of word as we use it in Wiktionary. I see no reason to give up the concept of orthographic word, which is rather clear and is in my estimation the default understanding of the term "word", in favor of some kind of broader semantic concept of a word that includes prefixes, proverbs and letters of alphabet. Terminological confusion is exactly the sort of thing CFI should avoid like a plague. I surely admit that "Njujork" is one word while "New York" is two words. We have an analogue of this pair in common nouns and other parts of speech too, hence the past discussions about the proposed translations-target criterion: we have "třista" in Czech and "three hundred" in English. Whether a term contains a space has been a key factor to consider in inclusion of terms in Wiktionary; once a term does not contain a space, it is automatically considered CFI:idiomatic. The definition of idiomaticity must at least implicitly refer to the concept of orthographic word. It cannot just refer to any constituent of a term, as morphemes are also constituents. Otherwise, you end up with "headache" being sum-of-parts, because it is non-sum-of-parts only with respect to words, not with respect to morphemes. --Dan Polansky 08:58, 31 March 2010 (UTC)[reply]
I am going to vote in support. As to whether "New York" is a 'word' or not, I think it's a technicality, matter of opinion/mood and not relevant. Semantics is not math. The community wants (and de facto does) include place names and this vote legalizes that practice. --Vahagn Petrosyan 18:47, 30 March 2010 (UTC)[reply]
It's not the worst idea I've ever seen. But not the best either. I'm not sure whether it will create more problems than it solves. Mglovesfun (talk) 19:29, 30 March 2010 (UTC)[reply]
I'm not sure about this, especially the wording "a translation that is not identical with the English form." Define "identical". What if the word just happens to be spelt the same as the English place name but is pronunced completely differently in the foreign language? And even if it is both written and spoken in the same way, translations for ALL languages should be included, like we do for any other word (e.g. Czech's hippie, German/Dutch/Spanish's China, Danish/Dutch/Finnish/French's genre, Croatian/Polish/Romanian/Slovene/Swedish's ocean, etc). ---> Tooironic 21:23, 30 March 2010 (UTC)[reply]
I changed it into "spelled identically", of course it was nonsense to say that it would be completely identical. And of course all translations are welcome - they just don't count as the initial justification.--Makaokalani 16:23, 31 March 2010 (UTC)[reply]
Perhaps if we only had German/Dutch/Spanish translations of China and without the gender information, the translations and the entry itself would have much less value but yes, they are the translation nonetheless. A country may not be the best example of a poor entry because many Roman based languages will have a similar but different spelling. Washington (surname, state city) is spelled the same way in most Roman based languages. German learners will know that cities are normally neuters and French learners that Washington is masculine in French, so providing German, French, Spanish, Finnish is good for consistency but an entry, in my opinion, should contain at least one translation where the spelling is different (e.g. Lithuanian: Vašingtonas) or is written in a different script (e.g. Japanese: ワシントン. In summary, if we have a place name entry in English and a translation into a language with the same script, i.e Roman, it would be a poor entry. It's my opinion only. I do agree that translations of place names into Roman script languages is still needed but it may look strange to have a hundred of Washington's in Roman letters and none in other scripts or with other spellings. --Anatoli 22:07, 30 March 2010 (UTC)[reply]

a translation that is not identical with the English form - this automatically makes every Polish and Czech village eligible for inclusion on the basis of their German names. I'm sure we don't want that. -- Prince Kassad 22:16, 30 March 2010 (UTC)[reply]

Who said we don't want to include every Polish and Czech village? I want to include them with their pronunciations, etymologies and German translations. --Vahagn Petrosyan 22:34, 30 March 2010 (UTC)[reply]
I don't think all Polish or Czech villages will be added (add Kaliningrad oblast's former German names here), anyway but places like Szczecin vs Stettin, Kraków vs Krakau, Ústí nad Labem vs Aussig, Plzeň vs Pilsen are interesting, at least if you want to know the origin of beer names. :) What other limitation would you like to add, Prince Kassad? Population, age, significance (this needs a further clarification)? Many people know Auschwitz but not many Oświęcim, definitely useful! --Anatoli 22:38, 30 March 2010 (UTC)[reply]
All criteria you listed there are subjective. A non-subjective criteria would be administrative power, i. e. only include cities if they're an administrative center of an oblast or a raion or similar. -- Prince Kassad 22:53, 30 March 2010 (UTC)[reply]
I support this criterion (administrative power) as one of CFI, if it is an administrative centre, it should override others. Perhaps, only the first level (e.g. state capital not county)? Some people objected having all possible administrative centres. The age (e.g. at least 100 years old) and the population (e.g. not less than 100,000 people) are not subjective. Significance can also be defined clearly - requiring several quotes from fiction or historical books, etc. --Anatoli 23:03, 30 March 2010 (UTC)[reply]
Population is definitely subjective, because it excludes cities in sparsely-populated countries such as Papua New Guinea. Age excludes all cities in Africa. Notice the issue? -- Prince Kassad 23:30, 30 March 2010 (UTC)[reply]
I personally support all place names inclusion, as long as they verifiable BUT if we put some limitations (to increase the current CFI) I don't see a problem with what you described. PNG place names are hardly known and less likely to be of much interest to the rest of the world. Small African cities may be still in the stage of establishing themselves and are likely to be renamed if the power changes. Same thing, are they interesting? Places with business, education, migration, marriage, travel, history, shopping, etc. are likely to be searched by users. If no newspaper mentions a small African city, who will know about it? If any of them fit "administrative centre" criteria, they will be included. I proposed population and age as a sample of some kind of limitation, a historical (e.g. a major battle) or cultural significance (mentioned in local history of fiction books) could be other criteria requiring citations. --Anatoli 00:14, 31 March 2010 (UTC)[reply]
Many object to this. As a minimum - a reference in Google map reference, linguistic info would be sufficient and more than language, since we are a dictionary. --Anatoli 00:14, 31 March 2010 (UTC)[reply]
Another reason why I am going to oppose is that the proposal refers to the unvoted-on "attributive-use rule", under the name "attributive use criterion". Thus, the proposal is a step to making the attributive-use rule legitimate, which IMHO should better never happen. This certainly was not the intention of the proposal. But I think that the discussion has proceeded so far now that we can avoid half-baked solutions, dropping the unvoted-on attributive-use rule altogether instead. --Dan Polansky 08:26, 31 March 2010 (UTC)[reply]
Well, that part could be taken out. Only I'm not sure if I can apply retrospective rules to entries that have been made under the old rules. Would all placenames that meet the current CFI also meet the new one? Or would you word it differently, "unless some other part of CFI justifies the placename definition"? And yes, to Prince Kassad's comment, any placename could be included if the entry is good enough. How would a valid entry about the name of a Polish village hurt this project? What frightens me is that it's so easy to make bad entries on placenames, and on any kind of names. Just open a gazetteer and start copying.--Makaokalani 16:23, 31 March 2010 (UTC)[reply]
(<) I think that the part "unless the placename meets the attributive use criterion," can be removed. The proposed requirements for inclusion of names of geographical entities are very relaxed anyway. The proposal basically says that all names of geographical entities should be included: at some point, contributors will be able to provide several of the five required classes of information. Given that CFI would contain a new section "Placenames" as proposed, it would be understood that placenames (names of geographical entities) are regulated by that section rather than the section for the inclusion of names of specific entities. --Dan Polansky 21:12, 31 March 2010 (UTC)[reply]
Retrieved from "https://en.wiktionary.org/w/index.php?title=Wiktionary:Beer_parlour/2010/March&oldid=70643079"