Wiktionary talk:Entry layout/archive 2008

Redirects in Wiktionary space

I propose that all of the "sections" used in the standard entry layout have a page in the "Wiktionary" namespace that either describes that section in more detail or redirects to this page. In particular, the redlinks below would need pages or redirects created:

==English==
===Alternative spellings===
===Etymology===
===Pronunciation===
*Hyphenation
*Rhymes
*Homophones
*Audio files in any relevant dialects
===Noun===
Declension
#Meaning 1
#*Quotations
#Meaning 2
#*Quotations
     etc.
====Usage notes====
====Synonyms====
====Antonyms====
====Derived terms====
====Related terms====
====Translations====
====References====
====External links====
===Verb===
Conjugation
#Meaning 1
#*Quotations
     etc.
====Usage notes====
====Synonyms====
====Antonyms====
====Derived terms====
====Related terms====
====Translations====
====Descendants====
====References====
====External links====
===Anagrams===
---- (Dividing line between languages)
==Finnish==
===Etymology===
===Pronunciation===
===Noun===
Inflections
#Meaning 1 in English
#*Quotation in Finnish
#**Quotation translated into English
#Meaning 2 in English
#*Quotation in Finnish
#**Quotation translated into English
====Synonyms====
====Derived terms====
====Related terms====

The purpose is mainly to help those searching for these terms to find information on the proper formatting and contents of those sections. Any objections? - dcljr 20:54, 14 December 2007 (UTC)

No, I think a better method might be to link Wiktionary:Glossary items where relevant. The POS headings already have their own subpage - making a maze of itty-bitty subpages to hunt down doesn't really help. The end result should be maintainable, particularly in response to a WT:VOTE. --Connel MacKenzie 20:58, 14 December 2007 (UTC)

They don't have to be itty-bitty subpages, so long as they link to a relevant page that explains the proper formatting of the relevant type of section. I don't think you understood my original question. I wasn't asking if I could link the terms on this project page; I was asking if anyone had objections to creating these pages as redirects to the relevant info so as to make search results for things like "derived terms" more useful. - dcljr 01:00, 11 February 2008 (UTC)

I object to have pages named Wiktionary:Finnish and especially to Wiktionary:English. The format page for English entries is WT:ELE. For other languages, it is the same unless a Wiktionary:About Finnish (or the like) exists. This problem extends to the parts of speech. The format for Noun is on WT:ELE, unless the noun is not English, in which case one must look on the relevant formatting page for that language. The same is true of many other sections redlinked above. --EncycloPetey 20:43, 27 January 2008 (UTC)

As I said, many can redirect to this page. When I can't find information about something on a Wikimedia wiki, I will often try a search for "Project:Topic", where "Project" is the name of the project I'm on (here, "Wiktionary"). Sometimes this works, sometimes not. I think it would be helpful to create these kinds of pages as (at least) redirects to the appropriate information. - dcljr 01:00, 11 February 2008 (UTC)

Changed made without a vote

On the top of the page it says that the page shouldn't be modified without a vote. I made a couple of minor uncontroversial changes here. I'm going to be blocked again for that am I? --Keene 19:32, 6 January 2008 (UTC)

Looks okay to me. That section (interwikis) could be made a bit shorter as well; 6 graphs on something the user/editor doesn't need to think about seems excessive. Robert Ullmann 11:51, 8 January 2008 (UTC)

I don't understand this bit

.. so maybe it should be re written:

Headings before the definitions

In general, this group does not depend on the meaning of the word. They give an environment that leads up to the word and its relation to other words, and allow us to distinguish it from others that may be similar in some respects.

In particular, this is the first mention of 'group' - what is a group? In the second sentence, surely 'They' should be replaced by 'Headings'? Earthlyreason 09:53, 11 January 2008 (UTC)

The "group" is all the headeings that come before the definitions section. --EncycloPetey 01:41, 12 January 2008 (UTC)

Thanks EncycloPetey. So maybe the first sentence should be rewritten:

Headings before the definitions

In general, headings that come before the definitions do not depend on the meaning of the word. They give an environment that leads up to the word and its relation to other words, and allow us to distinguish it from others that may be similar in some respects.

Or are we saying that ALL headings that do not depend on the meaning of the word should/must come before the definitions? Earthlyreason 07:35, 14 January 2008 (UTC)

No. References (for example) does not depend on the meaning of the word, but comes after the definitions. And sometimes the pronunciation or etymology is tied to a specific definition, but these come before the definitions. --EncycloPetey 20:45, 27 January 2008 (UTC)

The "group" may still be ambivalent. What makes it so is the ambivalency of the header "Headings before the definitions", if one reads that "Please place headings before the definitions" then it starts to mean that "group" would refer to "Additional headings". The header "Headings after the definitions" is so far down that it doesn't give a context. There would be no ambivalency if the header would become "Headings which come before the definitions". Best regards Rhanyeia♥♫ 17:28, 28 January 2008 (UTC)

The list type of example sentences

Which of the two is the preferred list type of example sentences?

• #:
• #*

In the section "Example sentences", #: is mentioned, while in the section "Additional headings", #* is used. My experience with entries says that #: is the common one. --Daniel Polansky 11:15, 11 January 2008 (UTC)

I don't see the format “#*” used for examples sentences in the “Additional headings” section. It does show quotations, though, which properly begin with “#*”. Note that quotations are not considered "example sentences" here, despite the fact that they show an example of a word's use. Here, "example sentence" means an example penned by a Wiktionary editor. Quotation means an example taken from an existing work. Anyway, (contrived) example sentences should be formatted with “#:”. Rod (A. Smith) 16:54, 11 January 2008 (UTC)

I see, thanks. I have failed to distinguish "quotation" from "example sentence". --Daniel Polansky 17:10, 11 January 2008 (UTC)

In translation example, add space after "*"

I have just modified the translation example, by adding a space after "*", matching the current usage. Now I have realized that I should not have done it without a vote. Next time around, I will stick to that rule. --Daniel Polansky 12:21, 7 February 2008 (UTC)

Oh, please don't. And thanks for your improvement. -- Visviva 12:24, 7 February 2008 (UTC)

Translation example: orange --> { { en-noun } }

In the translation example, should not orange be replaced with { { en-noun } }? --Daniel Polansky 12:24, 7 February 2008 (UTC)

I think so, but then again that might distract from the clarity of the example (which is supposed to be about translation layout, not inflection templates). -- Visviva 14:36, 7 February 2008 (UTC)

That is right. Maybe a small note below that example, explaining that the use of templates is actually preferred, would keep the example simple while pointing out the preferred markup. Anyway, not a big issue for me. --Daniel Polansky 08:40, 8 February 2008 (UTC)

Quotation formatting -- colon vs comma after the year

In the format of quotations, this article uses colon after the year, unlike Wiktionary:Quotation, which uses comma. Which one is preferred? --Daniel Polansky 13:57, 9 February 2008 (UTC)

A colon is not really an appropriate choice for punctuation for this. Most people I've seen use either a comma or an em dash. I prefer the latter, but I usually am putting Quotations into a separate section or the Citations namespace. --EncycloPetey 17:17, 9 February 2008 (UTC)

I insert commas and perform colonectomies. I don't use dashes and sometimes remove them if making other changes to quotations. I thought my preferences were based on a guideline, perhaps in the more specific page on quotations. (Yes, See Wiktionary:Quotations). Guidelines aren't policies though. I would conform to any policy about such a formatting matter. Perhaps we need to formalize some aspect of this? DCDuring TALK 17:32, 9 February 2008 (UTC)

We have tried, and there is old discussion that has established some of the norms. Last time we had discussion about citation format, only a few people ever commented and no consensus was reached, as the conversation became dusty and forgotten. I'm interested in having more discussion and formalizing format, but don't really have a lot of time to put thought into such a discussion these days as my offline life is very busy. --EncycloPetey 17:37, 9 February 2008 (UTC)

Thanks. I will use comma, then. --Daniel Polansky 02:37, 11 February 2008 (UTC)

Coordinate terms

What are these? __meco 19:37, 9 February 2008 (UTC)

Some sets of words have related meanings. For example, consider the words (deprecated template usage) cold, (deprecated template usage) cool, (deprecated template usage) warm, and (deprecated template usage) hot. When the such a set is large enough, we usually create a category for them, but for small sets, it can be more effective to list them as "coordinate terms". Does that make sense? Rod (A. Smith) 21:22, 9 February 2008 (UTC)

Wiktionary:Semantic relations#Coordinate term explains them as words that share a hypernym, but somehow that seems a bit off. To me, they're words that denote one particular value out of a range. Usually, there would be a common hypernym for such terms. Rod (A. Smith) 21:32, 9 February 2008 (UTC)

Hyphenation?

Could we add a section in Pronunciation on Hyphenation, similar to the Rhymes section? (Recommending interpunct and the {{hyphenation}} template.)

Also, could we make a distinction between hyphenation and syllabification?

Nbarth (email) (talk) 01:02, 14 February 2008 (UTC)

I agree that we should not say hyphenation if we mean syllibification. So I can better understand the issue, can you link to an entry that does so? {{syllables}} might be helpful. An alternative to documenting hypenation policy on this page (which some feel is too long) is to link to a supporting Wiktionary:Hyphenation (or some such) page. Consider Wiktionary:Pronunciation instead of the arguably over-long ELE. To solicit more feedback on this idea, consider posting your suggestion on WT:BP. Rod (A. Smith) 03:02, 14 February 2008 (UTC)

The way we're using Hyphenation, it has nothing to do with syllabification. We mean hyphenation. It is in the "Pronunciation" section yes, but it has nothing to do with pronunciation or syllabification. My recommendation would be to do as Rod says, and put it on the Wiktionary:Pronuncation page, which is still a draft rather than policy. Once things look OK there and people are happy, it's then easier to copy it into WT:ELE. For the record, I would prefer "Hyphenation" to go last in the section always, since it isn't really about pronunciation anyway. --EncycloPetey 03:13, 15 February 2008 (UTC)

Following Rod's suggestion and EncycloPetey's concurrence, I've added a section to Wiktionary:Pronunciation at Wiktionary:Pronunciation#Hyphenation, with talk section at Wiktionary talk:Pronunciation#Hyphenation. Presumably we should take the discussion there, and hope it looks ok.

Nbarth (email) (talk) 17:57, 17 February 2008 (UTC)

Template for quotations

What about creating a template for quotations? Like:

# The definition of the term.
{{quotation|y=1989|a=Author|w=Work name|ch=Chapter V|t=The text of the '''quotation'''|t2=Followed by another line.}}

rendered as

1. The definition of the term.
   • 1989, Author, Work name, Chapter V

     The text of the quotation

     Followed by another line.

The parameter t2 (and t3, and t4) is there mainly for multiple quotations, instead of quotations spanning several lines.

A gotcha: The quotations need different rendering when not following the definition, having their dedicated section, that is:

• 1989, Author, Work name, Chapter V

  The text of the quotation.

  Followed by another line.

This can be handled by having two templates, or by adding to the template a parameter distinguishing the two cases.

Names that come to mind:

• {{in quotation}} -- for quotations after definitions
• {{quotation}} -- for quotations in a dedicated section

Maybe the native speakers here can come up with better names.

Alternative using the parameter:

{{quotation|in|y=1879|...}}

I am not sure whether this is the right place to propose this.

--Daniel Polansky 09:42, 22 February 2008 (UTC)

A simple solution would be to not include the spacing/indentation in the template, and leave that to the one editing the page. H. (talk) 09:58, 22 February 2008 (UTC)

I am unsure whether I understand what you mean. To create the template is easy, just that I do not want to do it without first having a consensus. And one of the points of the template was that the formatting is defined in the template, based on a common consensus; that the formatting can be changed in one sweep at any later point as soon as the consensus changes. --Daniel Polansky 12:53, 22 February 2008 (UTC)

See WT:GP#Template:quote Conrad.Irwin 12:55, 22 February 2008 (UTC)

Thanks and sorry for this redundant commotion of mine. --Daniel Polansky 13:17, 22 February 2008 (UTC)

Confusing presentation of order

When merely browsing the table of content, the "References" section comes much earlier than its correct sequential order when you look at the order list. I think this is unfortunate since many people are going to assume that the table of content reflects the order. Shouldn't the list and the table of content be corresponding? __meco 07:31, 7 April 2008 (UTC)

Where would you put it? I'ts supposed to be a L3 header, so it doesn't come as a subheader of the POS. --EncycloPetey 22:34, 7 April 2008 (UTC)

Ordering definitions

Are there any criteria for the preferred order of definitions?

Most common usage first? Etymological parents first? —Michael Z. 2008-05-02 00:21 Z

There's been prior discussion, without much conclusion. A related matter is the notion of subsenses (See discussions about {{jump}} and the entry for head). Etymological/attestation order makes for a more satisfyingly readable entry, but can be hard to implement without more factual basis than we usually have. It also isn't believed to be as helpful to users as an order based on frequency of usage. Of course, we don't have the facts for that either. The result is often a jumble, but the older senses still in use tend to migrate toward the top. Sometimes archaic and obsolete sense migrate to the top if they make a major contribution to understanding the connection between the etymology and current usage. Rare, dead-end, specialized, and distasteful senses tend to migrate toward the bottom unless they have a clear home elsewhere on the list. That's how it looks to me. DCDuring TALK 00:39, 2 May 2008 (UTC)

That's the best description I've seen of the status quo. —Ruakh_TALK 02:12, 2 May 2008 (UTC)

Glad you think so. I have been trying to pay attention. DCDuring TALK 03:02, 2 May 2008 (UTC)

Looks good to me too. I'd say that this should probably be addressed in ELE somehow. I've been tending to sort in this order: common - less common but standard and nontechnical - technical - rare/obsolete - nonstandard/slang - vulgar/offensive slang, with reasonable exceptions for technical (etc.) senses which are particularly prominent. I prefer to avoid any kind of etymological/derivational ordering, although I can see its attraction. IMO the definitions should be focused on helping users to understand the senses, with as few distractions as possible; the story of how the word came to have those senses is best told in Etymology (where a cohesive tale can be told).-- Visviva 05:40, 2 May 2008 (UTC)

What the etymology section does not tell is the tale of the evolution of the senses within English. The idea of subsenses is another idea that enhances the integrity of the entire article at the expense of the frequency ordering. The evolutionary, relative frequency, logical relatedness, and context-specific approaches lead in very different directions for highly polysemic PoSs, like head. To me it is an illustration of what makes it hard for us to satisfy the needs of our varied types of users (as we imagine them and as they reveal themselves in Feedback). The notion that we could allow customization of the order of presentation of senses is very attractive to me. I still wish I had some good basis for understanding what worked or might work for our anon, casual users, coming either from Google or WP€. DCDuring TALK 10:36, 2 May 2008 (UTC)

It usually doesn't, but there's no reason why it couldn't, where suitable sources are available. I think I have added this information in a case or two, and nobody has yelled at me for doing so yet. This approach allows us to have this information (which is Good) without obstructing other functions of the entry (which would be Bad). -- Visviva 11:02, 2 May 2008 (UTC)

That could be Good, but for using more of the first-screen space already squandered on the white space to the right of the ToC and on Pronunciation. DCDuring TALK 11:23, 2 May 2008 (UTC)

True, but the question of what the Etymology section should contain is (or should be) separate from the question of where it should be in the entry. If the prominent position of Etymology is dissuading us from creating truly comprehensive etymology sections, that is a strong argument for the urgency of TOC and/or layout reform. -- Visviva 11:48, 2 May 2008 (UTC)

In terms of TOC whitespace specifically, drumming up community support for doing something like this in larger entries would be a noble project. Of course, we all know what kind of animal husbandry is involved in any such effort. -- Visviva 11:58, 2 May 2008 (UTC)

Entry layout reform is the topic for a new discussion - however much it is needed. In terms of ordering the definitions, I would say from "simplest" to most "complex" - an utterly subjective layout that tries to ensure that the people looking for easy information find what they want easily, while those looking for more advanced information (and who will probably understand better what is going on) have to look harder. I think ordering by Etymology is just plain silly, as it requires a lot of guessing and does nothing to aid readability to anyone but the etymologists,(sounds like it's nearly as silly as putting the Etymology section first ;). Conrad.Irwin 12:15, 2 May 2008 (UTC)

Right floating ToCs

That's an interesting idea - and can be achieved simply (and reasonably aesthetically) by just adding some CSS to MediaWiki:Common.css. There are some issues in that Wikipedia boxes will show above the ToC - but I think that it is a nicer default than having it pushing things down on the left. Maybe we should ask in the BP before forcing it site-wide, for those who want to test, try adding the following to Special:Mypage/monobook.css. Conrad.Irwin 12:15, 2 May 2008 (UTC)

#toc {
  float: right;
  clear: both;
  margin-left: 5px;
  margin-bottom: 5px;
}

Nice! The pediabox issue can always be addressed with __TOC__, if need be. Yes, this had better be discussed on the BP/GP first, but it sure looks good from here. -- Visviva 12:25, 2 May 2008 (UTC)

Right-floating ToC, coupled with nested "rel" templates to hide/show Etys, PoSs, Senses would enable dramatically greater information density on the initial screen. It might give us a lot of what we would need on long entries if we had the right text on the "rel" bars. What is the relationship of right-floating ToCs to images? Is it technically an all-or-nothing thing for right-floating TOCs? Is it possible that clicking on something in a TOC could automatically expand the items under "rel" templates? DCDuring TALK 14:35, 2 May 2008 (UTC)

Started BP discussion; perhaps it was premature (I'm concerned now about how this affects TOCs for big community pages like the Beer Parlour), but it's too late now.  ;-) Hopefully something will come of it. -- Visviva 16:00, 2 May 2008 (UTC)

References at level 3 or 4??

Hey. The layout explanation is inconsistent as for the heading level of references. The very simple example here says it's three, and this says it's four. Which one of the two it is? Or could it be both? If it can be both of them, what's the criterion for that? Gosh, how annoying... :P -- Frous 17:03, 7 May 2008 (UTC)

Most of the time it should be at L3. The only time I ever put it at L4 is when it is being used only for one particular POS and nothing outside that section, while another POS section has different references. This is rare. The Vote on including References at L4 merely indicates what sequence it shou,d be listed in the event that it appears at L4, and does not advocate for or against placing the section at L4. --EncycloPetey 19:37, 7 May 2008 (UTC)

If it is specific to an L3 POS, then it may, perhaps should, be at L4, under the POS (and as shown in the nesting examples); more typically just at L3 for the language section. Robert Ullmann 23:08, 7 May 2008 (UTC)

Compounds should be differentiated from Derived terms

Whereas derived terms would be limited to a few words that are cognate with the entry term, the list of derived compound terms can often be exhaustingly long. The real derived terms will easily become lost amongst these if they aren't placed under a separate header. Many pages use the Compounds header even though it is not listed on the present page, and I think we should sanction this by including the term here. __meco 12:24, 25 June 2008 (UTC)

Compounds is only (at present) supposed to be used on Han character pages, and only under the Hanzi/Kanji/Hanja/Han character L3 headings, not under POS headings. Also: people already can't tell the difference between related and derived terms ... Robert Ullmann 12:38, 25 June 2008 (UTC)

I often don't know whether a particular word was derived from another or is just strongly related to it. In such situations, I use Related terms because it's accurate, albeit less precise than it could be if I stopped my train of work to research the etymologies further. If I'm one of the editors who you say “already can't tell the difference”, rest assured that it's not because I don't know the difference between those headers, but rather because I don't know enough about particular words to make more specific claims. Rod (A. Smith) 16:28, 25 June 2008 (UTC)

I doubt that anyone had any particular contributor in mind, because the use of the Derived terms, Related terms, and Sea also headers has a lot of inconsistency and outright error from many sources. The practice you describe of putting a lot of things in Related terms because of not having time or knowledge enough to do the "perfect" job is fairly common. If I limited myself to perfect entries, I would only be doing certain types of English inflected-form entries. DCDuring TALK 17:11, 25 June 2008 (UTC)

Prior discussions about this are probably findable by searching talk space for time and "derived terms". I think a leading suggestion was to have separate {{rel}} templates and glosses for classes of derived terms where there were long lists, but without very specific restrictions on the nature of the classes. If the gloss were specific, perhaps contributors wouldn't be too confused. DCDuring TALK 14:24, 25 June 2008 (UTC)

Dual-language grammar terminology?

For many if not most world languages, the monolingual wiktionary has far more entries than are provided bilingually in en.wiktionary. What limits the number of bilingual entries in en.wiktionary? Probably the communities of English-speaking learners of most second languages are orders of magnitude smaller than the communities of native speakers. If so there should also be fewer active contributors to bilingual segments of en.wiktionary than to monolingual wiktionaries. (OK, we can quibble that these are also bilingual, but y'all know what I mean here.)

This starts having a very practical impact when there aren't enough bilingual entries in en.wiktionary to enable a language learner to look up the unfamiliar words they encounter while reading. If they don't already know and can't look up at least 95% of the words encountered, text comprehension will suffer.

The number of root entries needed to cover 95% of the words in unsimplified text of a general nature varies by language and how efficiently the entries are biased toward higher-frequency words, but is usually over 10,000 lemmas even if these are efficiently selected by frequency. If we assume Wiktionary entries are not efficiently biased toward higher-frequency words, 20,000 root entries may be a realistic cutoff between languages with adequate and inadequate coverage in en.wiktionary. Looking at en.wiktionary language statistics, only English, Mandarin, Italian, Japanese and Finnish meet this criterion.

Learners outside this language realm will be forced into the monolingual dictionaries before they are linguistically ready. This creates a chicken-and-egg problem if the definitions use unfamiliar words. If definitions are confined to simpler words that can be found in a bilingual dictionary, the user may still be able to muddle through; otherwise it's an infinite regress.

SOme of this problem is tractable. Dictionary text has an unusual concentration of grammatical terms: preposition, noun, verb, adjective, present, past, perfective, dative, transitive and so forth. These words tend to be long, but they are finite in number. The more of them a reader knows, the more her workload in a monolingual dictionary is eased.

If Wiktionarians face the inevitable that in the short run there won't be enough bilingual entries in en.wiktionary for the majority of languages; that the audience is prematurely forced into monolingual dictionaries, perhaps we should look for ways to make this less painful.

So my modest proposal is to make grammatical terminology bilingual. Expose us to the target language's terminology alongside the English every time we look up a word, and we'll learn it fast and painlessly. LADave 22:43, 29 June 2008 (UTC)

If I understand you correctly, you are suggesting that, for example, a Russian header should be changed from the current ===Noun=== to ===Noun/существительное===? —Stephen 23:01, 29 June 2008 (UTC)

That's right. Along with most or all other grammatical terms in an entry. Often the majority of these will be captions in inflection charts. Due to space considerations in captions, grammatical terms may need to be abbreviated.

Ru.wiktionary handles this well in the few instances I looked at, but of course it doesn't try to be bilingual. En.wiktionary actually does this for some Russian words I looked at, but doesn't become bilingual until you click on a caption. In other instances there is no Russian whatsoever.

Mind you, I'm not suggesting this is an atrocity. In fact it's the prevailing mindset in most hardcopy Russian textbooks and dictionaries. Yet this begs the question whether a different approach might be beneficial, especially in this new medium. LADave 02:38, 30 June 2008 (UTC)

I don’t understand a lot of what you are saying, about captions, prevailing mindsets (what mindset would that be?), does well (does what well?), etc.

Because of the need to run bots that rely heavily on headers, we allow only a fairly small, finite set of headers, and adding foreign terms to each header would make it difficult to write an effective bot. Other than that, we can do some things such as I did with the conjugation template at читать...if you click on any of the grammatical terms in the table, such as 1st-person or present participle, it links to the appropriate Russian term. —Stephen 10:05, 30 June 2008 (UTC)

I was calling column and row titles in the inflection tables captions.

Mindset is speculation why instruction in Russian as a second language avoids native grammatical terminology. Why not embrace it instead?

Re bots and headers, читать is pretty darned good. I'm not sure what counts as a header, but I'd like to see impf. not abbreviated and translated. Transitive and intransitive should also be translated and perhaps given links. It seldom pays to overestimate grammatical literacy!

In the conjugation table, Russian terms pop up when you hover over a title. I'd prefer to see the Russian by default without having to hover, so readers are routinely exposed.

From these titles, you often have to click twice to reach useful definitions. For example clicking on imperfective aspect brings up несовершенный вид, but you don't get much help with that until you click on imperfective aspect a second time. It would be good if the first click to несовершенный вид was more informative. This isn't necessarily duplication because you could mention peculiarities of Russian aspect that would be out of place in imperfective aspect. Also not everyone has broadband. If I were hooked up by modem, I might get annoyed over the second click thing.

I'd also love to see some etymology for несовершенный and even вид.

Likewise I think the first click on any participle (deverbal) title should be more informative. This seems to be a topic that first year (college) texts avoid, so it's probably better to be generous. LADave 19:35, 30 June 2008 (UTC)

Headers are terms that occupy a separate line and are surrounded by a number of = signs, as in ===Noun===.

In Wiktionary, we give definitions of English words, but translations of foreign words. The only time we want definitions in foreign words is where there is no good English counterpart. So the only way to get the definition of imperfective aspect is by going to the English page. The Russian несовершенный вид can only contain a translation, since a perfectly good one exists.

Etymologies are welcomed for every word, and you may request an etymology by inserting {{rfe|lang=ru}} after the ===Etymology=== header.

I suppose by "title", you mean header. We only allow the header ===Participle===, for the bot reasons already explained. —Stephen 17:23, 1 July 2008 (UTC)

Can headers be followed by translation lines without bothering bots?

Although "perfective" is a perfectly good translation of совершенный, совершенный вид doesn't fit perfective aspect so neatly. For a sense of this, skim http://calper.la.psu.edu/russian/chapter3_3.php and then perfective aspect. The Wiktionary definition specifies, "viewing the event the verb describes as a completed whole, rather than from within the event as it unfolds". However some совершенный verbs translate "to begin to {do something}" or "to {do something} awhile". These seem to fall into a gray area between the obviously imperfective "My literature class is reading 'War and Peace.'" and the clearly perfective "Last year I read 'War and Peace' for a class." Yuri Gagarin exclaimed "Поехали!" just as he blasted off to become the first human in space. Вид was grammatically совершенный but Yuri was describing an unfolding event as a participant -- one of multiple participants. An hour later Yuri could have said, "Поехали в космосе." Same verb form, but now it's unambiguously perfective.

If a Russian conjugation table has a header perfective aspect, this must be a stand-in for совершенный вид in the strict Russian sense. If the header has a link, it should take you to something that tells you about Russian usage. Taking readers to a global definition of perfective aspect puts the cart before the horse.

Re titles/headers, when I go to читать and then click on edit, I don't see participle anywhere in the content I assume gets mediated by a template to produce what Wiktionary users see. So "participle" must be in the template. Aren't bots mainly concerned with the data part? If so, how would adding Russian words to titles/headers interfere with bots? LADave 00:58, 2 July 2008 (UTC)

No, headers have to be followed by certain things. The noun header has to be followed by the gloss and then at least one definition. I don’t know what you’re talking about with "совершенный verbs translate "to begin to {do something}" or "to {do something} awhile"". совершенный means perfect, absolute, complete. Words such as поехали, пошёл and пошли are, aside from their basic meanings, idiomatic interjections whose translations often do not agree in tense, aspect or number with the Russian word. In their guise as interjection, they are not perfectives, nor are they past tense, nor even indicative mood. They are a sort of 1st-person imperative. The Russian совершенный вид fits perfective aspect very neatly.

I have a very hard time trying to understand what you are saying. Links link to appropriate terms. If you go to perfective aspect, you get the definition of perfective aspect. If you go to совершенный вид, you get the translation of совершенный вид.

I’m trying to explain to you how it works here, and why. I can see that I will never be able to do it. The way we do it is the way we do it. It has been developed over a long period of time and there are good reasons for everything, even if the reasons are not immediately obvious. —Stephen 01:29, 2 July 2008 (UTC)

Definitions should explain when to use restriction templates

There's no explanation here for when to use templates such as {{politics}} or {{mathematics}} in a definition. I believe it's when that term is limited to jargon for the area, but it would be nice to have something in the guide. Scott Ritchie 08:27, 23 August 2008 (UTC)

In my experience, we only create such templates for areas that have such jargon, but we actually use these templates even for terms that are more widely used and understood. Hence [[odd]] has an {{arithmetic}} tag for the sense “Not divisible by two”, even though most people do know that sense (more or less; a lot of people seem to believe, mistakenly, that zero is both even and odd; but I don't think that's because this sense is jargon). It's not all bad, though; it adds the category, it helps people find the relevant sense, and it makes clear that the term has a technical definition (as opposed to purely non-technical words, which I think tend to be fuzzier). —Ruakh_TALK 14:32, 24 August 2008 (UTC)

Order of POS section

Where does the adjective section come in relation to nouns and verbs. Does the page explain this? __meco 13:55, 28 September 2008 (UTC)

It is on Wiktionary:Entry layout explained/POS headers: "The headers in an entry (or nested within an etymology section) should always be in (English) alphabetical order, except that non-POS headers describing characters or syllables should come first." --Panda10 14:03, 28 September 2008 (UTC)

But note that the POS page is a "Think Tank". There are some cases, especially in highly-inflected languages, where alphabetical order is less desirable, such as when an entry is the lemma for a verb, but a "form of" entry for a noun, adjective, or other part of speech that would normally come before Verb alphabetically. --EncycloPetey 23:42, 25 November 2008 (UTC)

I've generally worked on the assumption that the headers should be in alphabetical order, unless another order is more logical for that entry. For example if the noun is derived from the verb, then it makes sense for the verb to come first. Equally, if an adjective is defined in terms of a noun then the noun should come first. Thryduulf 01:25, 26 November 2008 (UTC)

The exception to alphabetical order (since I don't usually know derivation) is much more common POS uses go first. RJFJR 22:25, 27 November 2008 (UTC)

3.3.6 Translations and 3.3.7 Descendants

In Section 3.3 "Headings after the definitions", the position of the "Translations" and "Descendants" subsections does not follow the "Order of Headings" sequence. "Descendants" should follow after "Related Terms"; "Translations" should follow after "Descendants". Can the "Translations" and "Descendants" subsections be moved to the correct order?

The correct order would look like this:

3.3.5 Further semantic relations
3.3.6 Derived terms
3.3.7 Related terms
3.3.8 Descendants
3.3.9 Translations
     3.3.9.1 Translation dos and don'ts
3.3.10 Anagrams and other trivia

--AZard 15:58, 13 November 2008 (UTC)

The order is given in the vote for Wiktionary:Votes/pl-2007-06/ELE_level_4_header_sequence and in the section "Order of headings". The section headers on the ELE may not follow this sequence, nor do they necessarily need to. The Translations section is explained earlier because it is a more frequently used section, and is used by a wider group of our editors. There are several other good reasons not to follow the page order in discussing some of these headers you propose to move. For example, Derived terms and Descendants are frequently confused, so it makes more since to discuss these next to each other, rather than having "Related terms" between them in the discussion. The whole purpose of the "Order of headings" section on the ELE is so that we have more flexibility in the sequence they are explained. --EncycloPetey 18:28, 13 November 2008 (UTC)

Thank you for the explanation. I have noticed a few entries where the translation subsection is out of order. I wonder if the order of the explanations is the source of the problem. I still prefer to make both orders consistent, but do see your logic. --AZard 03:52, 14 November 2008 (UTC)

I don't thinnk that the ELE order is the cause of the problem. We have many, many pages where the Pronunciation comes before Etymology, even though Etymology should come first whenever there is just one of each section for a language. I've also seen users put Etymology and Pronunciation as subsections under the part of speech. Each Wiktionary has slightly different formatting standards, so I suspect the difference between Wiktionaries leads to more section order errors than our ELE does, and that most of the remainging errors are the result of editors being too new, too inexpoerienced, or momemtarily forgetting. --EncycloPetey 16:48, 14 November 2008 (UTC)

Derived terms and related terms - alphabetical order?

Are lists of derived terms and related terms suppose to be listed in alphabetical order? If yes, where does it say that? If not, how are they suppose to be ordered? --AZard 16:11, 21 November 2008 (UTC)

We seem to assume it generally. There has been inconclusive discussion of grouping multi-word derived terms separately from one-word derived terms. The presumption is alphabetisation within such groups.

We often don't change pages that are policies or guidelines because doing so requires a vote, which generates a discussion which, though perhaps entertaining to some and educational to others, seems to be considered boring and/or a waste of time by many of the more experienced contributors. DCDuring TALK 16:33, 21 November 2008 (UTC)

I find your response to be rather funny. On one hand, the general principle of wiki's is to allow anyone to make any edit at any time. On the other hand, these voting requirements foster inertia in changing the formal policies. I'm getting the sense that many people are okay with informal policies and are accepting of some inconsistencies among entries. --AZard 17:08, 21 November 2008 (UTC)

We are slow to set "policy" in writing for many reasons, both good and bad. The page Wiktionary:About Latin is not yet formal policy, but does include a fuller and more up-to-date explanation of Related terms, etc. and how we format them. This is one way that EL:E changes -- we try out policy changes on these unofficial language-specific pages, then (if all seems well) we can vote the same language into the main ELE document. --EncycloPetey 17:20, 21 November 2008 (UTC)

Oh, it is in the About Latin page. Alphabetical. --AZard 23:01, 21 November 2008 (UTC)

So that's where the thinking is. Just like in the typical legislature: all the action is in the committees. At least it's not actually in camera. Also a recapitulation of the history of grammar and linguistics: it all starts with Latin, that most perfect of languages. DCDuring TALK 23:16, 21 November 2008 (UTC)

Well, I try to maintain a sense of humor. More than WP, I think a dictionary needs structure that is not-so-intuitive for contributors. Also: we don't get that much good material from casual contributors; we have bots that detect format problems; serious contributors are expected to learn the ropes and usually do. I am not sure that serious contributors would do much better if we had more rules and documentation, though I believe that we could use a bit more. DCDuring TALK 17:32, 21 November 2008 (UTC)

Grouping multiword separately? That would seem to make it more difficult to find, and contrary to alphabetization. In many cases such words are exact synonyms and freely interchangeable, so it seems quite wrong to actively separate them. I would think that it's easier to find and recognize three variants when schoolbus, school-bus, and school bus are right next to each other. As far as I can tell, professional dictionaries alphabetize thus; it's only lazy computer programmers who sort the space because it has a code point. —Michael Z. 2010-06-09 01:27 z

Inconsistencies between ELE and Templates

I have been editing based on the ELE, since I thought this was the governing document on layouts and formats. Thryduulf has been nice enough to point out to me a few templates - Alphagram, Homophones, and Sense. Unfortunately, there are inconsistencies between these templates and the ELE. Now, I found the Rhymes template page. The ELE format is colon asterisk ":*", while the template is just asterisk "*". I have found almost no rhyme entry with the ELE format. Maybe I need to "undo" some of my rhyme "corrections". Something tells me that there are more templates that have not been reflected in the ELE. I think this community needs to make a list of these "rogue" templates, undergo a quick and simple vote, and update the ELE. --AZard 03:57, 25 November 2008 (UTC)

I just want to add that I've seen a number of entries where the rhyme format was asterisk colon "*:". Seems like this one might not be as easy as the other two templates. Can I assume that the Homophones and Sense templates are not controversial? --AZard 16:46, 25 November 2008 (UTC)

I would be in favor of a vote to no longer require votes to update the ELE. That well-intentioned rule is a big part of why our policy pages are in such a chronic state of disrepair. -- Visviva 16:59, 25 November 2008 (UTC)

But please remember why the rule was first instituted. We had editors coming here and changing ELE to suit their desires, then enacting them as "policy" without any consensus, and at times without any support from anyone else. --EncycloPetey 20:07, 25 November 2008 (UTC)

While I feel a vote should be unnecessary, we need some way to just tell people to piss off when they change this wrongly in a way that they cannot come back a whinge "but you never said...", or "but this is clearly right...". I have no problems with correct edits being made to the page by experienced users, however, experienced users is not a term that is easily qualifiable - there are maybe three people I'd trust to edit this page sensibly. If we don't want to have a full VOTE on each, then maybe having a poll on WT:BP would be sufficient. In any case changes must be discussed there first. Conrad.Irwin 20:16, 25 November 2008 (UTC)

I think that a clear, but informal, consensus on the BP should be sufficient to change the ELE. In the case of something small like the {{alphagram}} template, I doubt that many people would be sufficiently interested to vote either way. Thryduulf 23:19, 25 November 2008 (UTC)

How about a vote, say, twice a year to nod through all template upgrades (or other more or less minor changes), as need be? Inconsistencies that AutoFormat can fix are probably not a big issue (as long as Robert is as active, committed and motivated as he is). -- Gauss 23:27, 25 November 2008 (UTC)

Empowering three people to make changes without a vote makes a lot of sense to me. If any individual disagrees with one of their changes, that person can call for a formal vote on that issue. If these three are not making proper judgments on a regular basis, I would guess the community would vote them out of the role. --AZard 15:15, 26 November 2008 (UTC)

So what is the next step? There are now three "minor" changes that are needed to be made to the ELE: Homophones template, Sense template for synonyms, and the order of audio vs rhymes. I'm told the correct order within Pronunciation is: Hyphenation, Audio, Rhymes, and Homophones. --AZard 03:30, 5 December 2008 (UTC)

I just saw EncycloPetey's vote on the Pronunciation reordering. I guess that's the current way to fix the other two too. --AZard 03:40, 5 December 2008 (UTC)

Note: because the vote I started does not actually change any explicit policies, I went ahead without preliminary discussion (other than informal one-on-one conversations over the past months). Depending on the degree of the change, and whether it actually changes what ELE advocates, it may be worth having a brief discussion and straw poll before a more influential change is voted on. Sometimes, the community reaction can surprise you over what you thought was a minor and simple change (I've had this happen to me personally). Another thing you'll notice is that I've given the exact wording that is proposed for the change, and not simply described the kind of change. It's easier for people to agree / disagree over specific language than over concepts. --EncycloPetey 09:14, 5 December 2008 (UTC)

Mistakes in example (Translation section)

Excuse me, if I remember correctly, the language code for Latvian is 'lv' and 'lt' for Lithuanian. And orange means "oranžs" when it is an adjective, as noun it means "apelsīns" (m).