Wiktionary:Grease pit/2008/December

What do the numeric values in this template's parameter represent? —Michael Z. 2008-12-03 15:36 z

Answered at Template talk:Xsux. —Michael Z. 2008-12-04 07:19 z

Is there a reason we still have the Wiktionary:Grease pit#Archived topics section hanging around. They were conversations subpaged by Vildricianus in June/July 2006 and haven't been touched since that July. They're not kept around for quick reference right? They're all listed as well in the GP temporal archives, so we should just be able to eliminate the section from the top of the page. --Bequw → ¢ • τ 09:26, 4 December 2008 (UTC)

Is there a way to search the temporal archives? --EncycloPetey 19:28, 4 December 2008 (UTC)

One can search the section headings via WT:GPA or Wiktionary:Grease pit archive/section index. They have been stale since 2007-08-31 though. --Bequw → ¢ • τ 22:36, 4 December 2008 (UTC)

With no reason coming forth, I did some new years cleaning. --Bequw → ¢ • τ 09:49, 6 January 2009 (UTC)

With a little magic.

It isn't subst'ble at this time (can't be, because MW doesn't recursively subst by default or with a marker; more brain-damage) but will work as {{also}} or as the language template in other cases.

I've noticed some people are still using {see}, this is expected, and not a problem, AF will sweep them up in the main namespace. We can just leave it like that for quite a while. Robert Ullmann 12:17, 6 December 2008 (UTC)

How is one supposed to check for uses of see where also is meant if see is now valid? Whatlinkshere will no longer work. (I'm thinking specifically of ns>0 pages.)—msh210℠ 19:08, 8 December 2008 (UTC)

Nearly any call to {{see}} is, at this point, incorrect. We have very, very, very few uses for Seneca. --EncycloPetey 19:52, 8 December 2008 (UTC)

Any reference (transclusion) of {see} from non-mainspace, directly, is probably something to fix. Any NS:0 reference is either okay, or AF will fix. Indirect references to see will occur from non-mainspace things like cat boilerplate, not to be worried about. Is all in all not an issue. Robert Ullmann 23:39, 8 December 2008 (UTC)

I don't care how the tabs are arranged, be they 3 by 2 or 6 by 1, but 6 tabs, instead of 4 needs to be implemented.

What I am talking about is that, say, for this page, we have "project page", "discussion", "edit this page", and "history", at the top. These are for navigational, editing, forensic, and learning purposes. Now, this isn't very user friendly, and people have argued that having 6 instead of the 4 we have now would make it more clumsy. And that if anons made an account, they could use CSS to implement this. Well some anons don't like making accounts. And it is more clumsy right now, and confusing, where by pressing the discussion tab, and then edit, it is counter-intuitive. People also lose thoughts, depending on their connection speed, by having to wait for extra pages to load. It's even hard to understand with the 4 tabs switch over system that is used right now.

Another problem are the templates: going to Template:Navbox Province of Italy, at its top left corner, you will see v • d • e. This too needs the 3 other analogs. You can put them in 3 by 2, or 6 by 1, but for the same reasons above, specifically for server resource times/loading times and userfriendlyness/navigational ease.96.53.149.117 12:50, 6 December 2008 (UTC)

I think you are commenting on the Wikipedia? This is Wiktionary. Robert Ullmann 13:02, 6 December 2008 (UTC)

The second comment is WP-specific, but the first one applies to us as well. Of the first two tabs ("project page"/"entry"/whatever vs. "discussion"), one is always selected, and it controls the meaning of whatever other tab is selected, if any (except for "watch/unwatch", which covers both); but this violates the general user-interface principle of tabs, where exactly one tab is selected at any given time. That is, right now the "project page" and "edit" tabs are both active for me, so I'm editing (part of) the project page; if I want to edit the discussion page, I click on the "discussion" tab, and then on the "edit" tab. —Ruakh_TALK 16:31, 7 December 2008 (UTC)

Hey, I created Purge - template with code from w:Template:Purge at en.wiki. This should prove helpful when placed on category-pages, in order to see changes and additions made instead of manually refreshing/purging the page(s). Cheers, Cirt (talk) 07:26, 7 December 2008 (UTC)

You don't need to "purge" a category page. Clicking on the "category" tab to reload it is sufficient. (And "purge" only affects the text of the cat page anyway.) Robert Ullmann 12:04, 7 December 2008 (UTC)

While running spork, I have noted a number of entries that should be English forms, but have no English language section. (e.g. oxides) Quite a few are from generating Spanish forms that look like English plurals and the like. So I set out to hunt them down; missing plurals, verb forms, singulars, comparatives, infinitives, etc etc) It picks up some other errors, like missing lang= (a number of Italian entries), en-noun used for a Korean entry. Some Spanish infinitives are missing.

Just putting this together, but you might like to look at User:Robert Ullmann/Missing forms, in particular the control table that tells the software what to look for. Robert Ullmann 16:44, 7 December 2008 (UTC)

Went through a number of rounds getting the table to match (most of) what en-verb does. Lots more missing for English. Please point out any mis-match I hadn't found (list says form is missing, but en-verb isn't generating that form.) Robert Ullmann 17:34, 8 December 2008 (UTC)

A couple mistakes on the Spanish list. The list says that exhumes links to *exhumer when it only links to exhumar. As well, the list says that galope links to *galoper when it only links to galopar. Good idea, though. --Bequw → ¢ • τ 23:03, 9 December 2008 (UTC)

Mistakes in the entries, to be fixed. Look closely, and you'll find the French section using {{es-verb-form}}. (! ;-) McBot added it, but was misled (I think) by an IP anon adding French with {es-verb form of}. If you'll look at the Italian list, you'll find bolo referencing bolos, in that case the Portuguese section using {{it-noun}} ... Robert Ullmann 17:58, 10 December 2008 (UTC)

These lists are a bit more useful now, if you want another language add to the control file (or try to ;-). The English list still has a number of forms that AF hasn't gotten to adding lang= to yet. Robert Ullmann 17:58, 10 December 2008 (UTC)

I've noticed that several heavily-used templates generate nonsensical, redundant content, which is selectively hidden using CSS. This contravenes any accessibility guidelines and the basic principles behind the CSS standard (“Style sheets complement structured documents . . . , providing stylistic information for the marked-up text”). It belies the basic use of content vs. presentation in making web pages.

For example, {{term}} and {{en-term}} put redundant quotation marks around terms and mis-nest brackets.

Some inflection templates, like {{en-noun}} and {{en-adj}}, insert the inflection line into an entry twice, once in a table and once in a paragraph (in various order).

It appears that we are disregarding users of assistive technology and alternative browsers, so that each of us can have our quotation marks ever just so. Somebody tell me we don't consider this acceptable practice! —Michael Z. 2008-12-09 08:21 z

No, that is called customization. It is a feature, not a problem. Some users want their noun inflection lines compact, while others prefer a tabular format. Customization allows them to choose which one they prefer. Similar customization exists in the other templtes you mention. This is what CSS is designed for--to allow style to be coded. We consider this not only acceptable practice, but highly desirable. Mis-nesting of brackets is another issue. --EncycloPetey 23:35, 9 December 2008 (UTC)

That's wrong. CSS is meant to style the presentation, not to shuffle around poorly-structured content. The HTML should be able to stand alone. This is pretty clear in the HTML and CSS standards and in accessibility guidelines. In fact, serving up unacceptable content and then patching it up for the non-disabled majority is contrary to what CSS is for, and contrary to the spirit of an open dictionary. —Michael Z. 2008-12-10 00:08 z

As supportive of user customization as I am, I am in total agreement with mzajac. Whatever is actually generated by the template should not look sloppy when viewed without CSS activated. It's just common sense. I recommend extra/optional/replacement elements be generated with before/after styles where possible. Either that (the old-time graceful degradation) or we proceed by strict progressive enhancement of valid output. Circeus 00:30, 10 December 2008 (UTC)

(Circeus: I was going to use :before and :after in {t} (see below), but it isn't supported in IE until IE8, which is a bit painful) Robert Ullmann 17:46, 10 December 2008 (UTC)

No EP, Michael is correct. We can certainly use CSS to customize things, but the default (un-styled) content must be correct and pretty much in the style we want. Monobook on a desktop/laptop screen is one particular view, but it should (must) be correct on other things; it isn't just disabled-accessibility, it is PDAs, handhelds, cellphones and who knows what next. {{term}} is screwy (I don't get the extra paren at all—well, I do, but it's a crock ;-). (The other observation is that there is frequent and vociferous demand for "customization" by a handful of editors, and little evidence that any of it is ever used by anyone else.)

(Michael: you'll find {{t}} is also one of the offenders; I still need to improve it; there was an awful lot of heat and noise about revising it, and I don't know if anyone has ever customized anything using its provisions. I just need a bit more work to get there. ;-) Robert Ullmann 17:43, 10 December 2008 (UTC)

Agreed. BTW, it's not just users of assistive technologies and alternative browsers, but also users of copy and paste on certain mainstream browsers (including IE7 and FF3). —Ruakh_TALK 18:04, 10 December 2008 (UTC)

Yes, forgot that. Write {{term|слово||word|tr=slóvo}} and copy/paste the presented text and you get слово (slóvo), “‘word’”) which is not very good. And the broswer is doing the correct thing. Robert Ullmann 18:11, 10 December 2008 (UTC)

Interesting: Safari doesn't copy the hidden text. Firefox also copies redundant inflection lines, so ===Noun=== ¶{{en-noun}} in the entry word copies as

Noun

Singular
word
  

Plural
words

word (plural words)

 —Michael Z. 2008-12-10 19:23 z

I appreciate that it's difficult to justify removing existing features. I'd be glad to help develop better (simple) ways of customizing the appearance of some elements. But I see some absolutely trivial customization wired into much of the infrastructure, at a very significant expense in adding nonsensical content, poor markup quality, reduced accessibility, and a high threshold and overhead for template editors.

At a minimum the content and markup must be normalized (let's prepare to participate in Naked CSS Day in April).

Sure some customization is possible. But quite frankly, it's easier to cut 'n' paste a line of CSS than it is to parse the horn o' plenty that is WT:PREFS (I'm complaining there, too). And someone who prefers italicized brackets on alternate weekends might have to choke back the tears and take it like a man.

I can help with this stuff, but I'm just getting familiar with the baroque intricacies. I'd like to take stock and set some concrete goals for improvements, with the understanding that some features may be put up on the chopping block. —Michael Z. 2008-12-10 18:22 z

I am also fully supportive of this. We could simply adapt the CSS quotes attribute to fix the single/double quote sign issue. As for the parens: why not simply put in another opening paren, which is also hidden as appropriate, such that at least copying works more or less correctly: (slóvo), (word), where then both the middle parens should be hidden. This feels more like the intended use of CSS to me: hide content (it is content!) in favor of design. H. (talk) 14:00, 11 December 2008 (UTC)

CSS quotes doesn't work in any shipping version of MSIE, and I think they are only intended for direct quotes, not glosses. They are being considered for removal from HTML 5, so long-term support may not happen. It is best to just put quotation marks here. Readers of books don't get to choose which kind of quotation marks they are subjected to, and that is not a huge problem, so I don't see why we can't just pick a house style.

I haven't looked, but the brackets problem looks like a template bug which was hacked around using CSS. —Michael Z. 2008-12-11 16:51 z

Well, here's the latest relevant discussion: Template talk:term#Parentheses. I can't untangle the code and discussion well enough to definitively evaluate the situation, but near as I can tell, the brackets are an ill-considered solution in response to requests for multiple customization options. Here are the relevant customization options from WT:PREFS (mixed in with 13 others):

• Hide the parentheses around list item qualifiers.
• Italicize the punctuation (parentheses and colon) around italic text.
• Hide the maximal amount of parentheses.
• Show other Latin (Roman) script mentions in bold. (Default is in italics.)
• Show English glosses for mentioned terms in single quotes. (Default is in double quotes.)
• Hide parentheses around transliterations and glosses.
• Hide parentheses around glosses.
• Show parenthesized plain (non-italic) transliterations.

Do our readers need or want this? Can they possibly understand it?

I'd like someone to write a short, clear instruction for readers explaining these options. If we can't do that, then this is just wasteful self-indulgence. —Michael Z. 2008-12-11 17:25 z

Okay, if anyone can help fix the output of template:term, please respond at Template talk:term#Fixing the brackets and quotation marks output. Otherwise I'll take a crack at it myself. I suspect that some or all of the customization options may have to go. —Michael Z. 2008-12-18 21:31 z

If you plan to remove the customization from {{term}}, you should first mention the expected results on WT:BP. People not interested in technical discussions will be surprised when you take away their custom rendering. Let them know how etymologies, etc. will look to them when you're done with your edit. If you get objections, you'll have to go through WT:VOTE before making your desired changes. Rod (A. Smith) 22:08, 18 December 2008 (UTC)

I, too, fully support Mzajac in this issue: content and style should be separate, so should be separated. This has been bugging me for some time, to be honest, and I'm very glad someone is doing something about it. I'm also glad I'm not he, as (a) customizability is lovely, has a lot of fans, and will need to be lessened; and (b) the coding is complex.—msh210℠ 22:21, 18 December 2008 (UTC)

For what it's worth, I support the cause to clean up the CSS, but I haven't forgotten our experiences trying to herd cats at Wiktionary:Votes/2006-12/form-of style, Wiktionary:Votes/2007-08/style for mentioned terms, or Wiktionary:Beer parlour archive/2007/August#Consistent format for mentioned terms, so elimination of customization should at least be mentioned on BP before action is taken. Rod (A. Smith) 23:14, 18 December 2008 (UTC)

I'd tackle the brackets first, which should be doable without removing any customization.

The current customization scheme for quotation marks is not viable at all, where CSS pretends to be content management. If anyone has any ideas for alternative methods, please shout out at template talk:Term. Particularly, is there a way for a template to respond to a user's preference stored in a cookie?

Once I figure out how I'll go about this, then I'll don me armour and post at the BP. —Michael Z. 2008-12-18 23:17 z

Just thought I'd take a second to say that I, too, am fully supportive of making Wiktionary follow standards and best practices. My thanks go out to Mzajac for taking the initiative on this, and for bearing the inevitable of the forthcoming BP convo. :-) -Atelaes λάλει ἐμοί 23:24, 18 December 2008 (UTC)

I've picked this apart in detail. The mis-nested brackets are not a mistake—they are hard-wired into the CSS-based “content management”. To clean up the output means to eliminate the current customization scheme for both selective brackets and alternate quotation marks.

Demo wikitext:

{{term||слово|word|tr=slóvo}}

Unstyled output on the page (emphasizing invalid content which is hidden from visual browsers by CSS):

слово (slóvo), “‘word’”)

HTML output (emphasizing the code dedicated to customization.   is a non-break space.):

<span class="mention-Latn">слово</span>&#160;<span class="mention-tr-paren">
<span class="mention-tr-gloss-paren">(</span></span><span class="mention-tr">slóvo</span>
<span class="mention-tr-paren"><span class="mention-tr-gloss-separator-paren">)</span></span>
<span class="mention-tr-gloss-separator-comma">,</span>&#160;<span class="mention-gloss-double-quote">“</span>
<span class="mention-gloss-single-quote">‘</span>word<span class="mention-gloss-single-quote">’</span>
<span class="mention-gloss-double-quote">”</span><span class="mention-gloss-paren">)</span>

Removing the customization code for a single unlinked term with transliteration and gloss would trim the output from 561 bytes to 91 bytes , an 83% reduction.

Options:

1. Eliminate the customization of brackets and quotation marks. Everybody sees the default.
2. Create a new Javascript-based solution to customize the text. I'm not capable, and I don't know if it could be made to work smoothly.
3. Replace this with a solution based on CSS content: declarations. Not supported in MSIE—conditional comments might be used to rig an alternative solution for MSIE, but I don't think we can do that in Wiktionary.

Further advice is welcome. I'll propose option no. 1 at the Beer Parlour, and see how it flies. —Michael Z. 2008-12-19 23:40 z

I’d like to plead for introducing spaces before and after headings. That is, between the equals signs and the header text. Reason for this is that it is much easier to edit headers that way: Ctrl+Left/Right work better, Ctrl+Delete/Backspace work better.

Is there a reason why we do not put those spaces there, apart from terseness?

Example: == English == instead of ==English==. Try navigating with your keyboard, the first is easier to edit. H. (talk) 13:55, 11 December 2008 (UTC)

I second this, I find it easier to read wikitext with the spaces present - though I know there must have been discussion on this before as AF always comes and corrects me. Conrad.Irwin 14:00, 11 December 2008 (UTC)

See some past discussion at Wiktionary talk:Wikitext style#(2) No whitespace after a heading start, nor before a header end. —Ruakh_TALK 14:24, 11 December 2008 (UTC)

As incredibly minor as this issue is, the pro-spacers seem to have the better argument. I say that as someone who intentionally removes said spaces when he edits a section, and who very much præfers the spaceless status quo; however, I think that that’s down to habit and convention more than anything, so I don’t have a valid counterargument against changing to the spaced style. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 15:30, 11 December 2008 (UTC)

I'd change my no-space habit (despite my balky/worn spacebar) for the reasons presented so far, but I'd like to hear more about any technical concerns. DCDuring TALK 15:44, 11 December 2008 (UTC)

Yes, please! Simply put, English words are always be bounded by whitespace or punctuation (the equals sign is neither). Specifically:

1. Butting equals signs up to the words confuses some software, including cursor navigation and selection (described above), some spell-checkers (in earlier versions of Mac OS X).
2. It reduced readability of wikitext, especially if I don't want to use a wide monospace font, like MSIE's default.

 —Michael Z. 2008-12-11 16:26 z

Okay: technical details and some background:

First: note that the wikitext, mostly in the XML, is the primary product of the WMF projects; the purpose is to produce reusable content, not the whizziest site on the web. Users of the content are discouraged from heavy use of the live site, and prohibited from setting up live mirrors.

The wikitext is read by thousands of applications, written by a similar number of people, of varying abilities and resources. There are a number of things we do to keep it tractable, and this is one. (See the code snippet above I wrote for Equinox.) The content should (must) be accessible to simple code. One can easily (for example) read all of the English definitions from the dump without any knowledge or use of XML or re (or whatever). And this is routinely done. (No-one in their right mind reads the dumps with an XML parser; the format is simple, and that is way too slow. ;-)

(Aside: We certainly do not want to allow anything like what the MW parser will permit. For example:

=={{
fr
}}==

==　French　==

== Mandarin　==

===   {{
        abbreviation
        |
        lang
        =
        fr
        }}   ===

is all legal; but I don't think we would consider any of it? Yes, the two ordinary headers in the middle with single spaces are both wrong, and not something you want to permit. Yes, they look "right". Can you tell why not?)

Yes I do. That is evil! But also not a problem, nobody will use these spacers, will they? Hm, but I can type an unbreakable space indeed (Shift+Space), it gives problems in Java files sometimes. Anyway, it really is an aside and barely relevant to the discussion. (http://www.macchiato.com/unicode/chart/ helped me to find out it is ideographic space you’re using, U+3000) H. (talk) 14:00, 15 December 2008 (UTC)

In May 2006, we decided to not permit the spaces in our canonical format. (by 100% consensus). At the time, the MW software did not "allow" spaces around headers; it worked by accident, generating HTML with the spaces included, which was then ignored by the browser parsing. (And the one line of code that generates spaces in add-section only worked because of that.) Spaces after headers broke section editing completely (since fixed).

At this point in time we have no spaces around any headers in NS:0. If you want to change that, this is what it will take:

1. define whether you mean "exactly one space" or "whitespace"
2. edits to all 1M+ entries
3. changes to thousands of software applications and programs that use the current syntax
4. (AF can fix the suspicious cases above, as it does now; meaning the two that "look" right ;-)

Do you really want to break all that? It can be done. Many, many, people who have working code will curse you for it. Robert Ullmann 17:11, 11 December 2008 (UTC)

If these are, as Robert explains, unavoidable outcomes of such a change (and I wouldn’t know whether they are, because of my ignorance of such things), then it really does not seem worth the hassle to change. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 17:32, 11 December 2008 (UTC)

The link on discussion pages includes spaces by default. Examples in Mediawiki help documents include them. There are spaces in the headings in the main namespace all the time, as editors create and edit entries.

Any software that can't deal with the spaces is is going to produce errors, and should be fixed.

Which thousands of programs are broken by the spaces? —Michael Z. 2008-12-11 17:53 z

Thanks for providing the full explanation, Robert. It sounds like a parallel to aspects of the evolution the grammar of natural languages. We have evolved away from XML rules a bit. Keeping things as they are would mean my balky keyboard may have an extra month of useful life. DCDuring TALK 18:23, 11 December 2008 (UTC)

While I have no interest in spaces in headings, and, indeed, am against their introduction if it means the various bots will need to be rewritten, I nonetheless have to comment on one particular argument raised against their introduction, both on this page (just above, by RU), and at Wiktionary_talk:Wikitext_style (also by RU): If we allow these spaces, we'll have to change all million entries. Well, no, not if we merely allow, but do not mandate them.—msh210℠ 19:39, 11 December 2008 (UTC)

The benefit of the spaces is slightly easier keyboard-based navigation. The down side is re-writing the bots and all million+ pages. I don't think the potential benefit is anywhere close to compensating the required cost. --EncycloPetey 19:45, 11 December 2008 (UTC)

Which bot can't deal with whitespace boundaries next to heading text? As this occurs in many pages, how is it that this bot is considered to work right? Why not make them work with English-language conventions, web browsers, spell-checkers, and operating systems? This is backwards. —Michael Z. 2008-12-12 01:07 z

Which English-language conventions put equals signs around words? What web browsers, spell-checkers, and operating systems? The lack of spaces makes not the slightest difference in any browser or operating system I've been using; and AF automatically spell-checks section headers. --EncycloPetey 01:14, 12 December 2008 (UTC)

Well, none of them do, of course: that's why this convention will remain incompatible with English-language text, and with any software made to work with it. The lack of word separators caused the technical problem which started this thread, among others mentioned here. The spell-checker in earlier versions of Mac OS X is broken by this too, and AF doesn't work in the edit field.

If thousands of programs are broken by adding the spaces, can you name one or two of them, so we can understand the problem? —Michael Z. 2008-12-13 03:04 z

At what point did I say, or even imply that "thousands of programs are broken" by this? I said that I don't see any compelling reason to make the proposed change. "Fixing" this little issue will not make our pages word-processor friendly. We use curly-brackets templates, ISO codes, piping, hash-based links, and any number of other code syntax that present just as much of a "problem". AF can handle misspelled section headers without the spaces, so why do we need to change every page on Wiktionary? For the few people editing with an older version of Mac OS X? I use OS X, and have never had a problem that would have been solved by inserting spaces into the section headers.--EncycloPetey 03:16, 13 December 2008 (UTC)

Apologies, the “thousands” came from someone else in this thread.

This convention causes incompatibilities and inconveniences, and will continue to do so. Just because it doesn't bother you doesn't mean it's better—in fact it's demonstrably worse, and it inconveniences several of our editors who have chimed in here. Changing over is not a burden—we have all the time in the world, and we have bots. —Michael Z. 2008-12-13 03:57 z

"Demonstrably worse". No, you haven't demonstrated that it's worse. Changing over is a burden, and (again) you haven't actually demonstrated any significant benefit for the cost involved. Stating an opinion over and over does not constitute a persuasive argument. --EncycloPetey 05:59, 13 December 2008 (UTC)

The benefit of the spaces is slightly easier keyboard-based navigation, or so I'm told. Readability of English also suffers when words are not separated by word-separator characters. A few other editors have recognized these advantages, so I think there may be some validity to these arguments.

The flip side, I'm told, is “re-writing the bots”. Please, can you point out an example of a bot which would need to be rewritten, so we can get some idea of the problem? —Michael Z. 2008-12-13 07:33 z

"...or so I'm told"? So, you're not even sure about slightly easier keyboard-based navigation, then? This is your reason to modify one million pages?

I’m sorry I have to drop in here. I am sure about easier keyboard navigation, it was the reason I started this discussion. H. (talk) 13:46, 15 December 2008 (UTC)

"Readability of English also suffers when words are not separated by word-separator characters." No, it doesn't. Standard English punctuation routinely places non-letter characters right up against words—hyphens and dashes, commas (and parentheses), as well as periods. And exclamation points! Internet text frequently adds *asterisks* around words that do not hamper readability, and our own coding does the same with curly braces, angle brackets, and pipes. Your argument does not hold up to the evidence.

"The flip side, I'm told, is “re-writing the bots”." Please go back and look at the other counter-arguments. You've noticed one of them, but there were others. I would have to change the multiple templates my bot uses for adding Latin verb forms. SemperBlotto would have to change all his templates. MatthaisBuchmeier would have to change his bot. AF would have to be changed. And those are just the bots that immediately came to mind. Making the change would require a lot of work from a lot of people for dubious benefits. It isn't worth the effort to keep pointing this out. --EncycloPetey 21:32, 13 December 2008 (UTC)

EP, that's not “evidence,” it's poppycock.

Blocks of equals signs butted up against words are not English punctuation; this is never used in English prose. And when Oxford uses solitary equals signs to show equivalence in transliteration, even of individual letters, they separate them with spaces (Oxford Style Manual 2003, p 350, Oxford Guide to Style 2002, p 335). Research about reading says that we recognize the shapes of words, and butted blocks of equals signs change them. And if you really think we should aspire to the text standards of email, then you're welcome to articulate some evidentiary argument that *this* means that ===this=== as readable as === this ===.

And yes, “so I'm told” because I was quoting you directly. Nice for you to poke at flaws in my rhetoric. But are you now saying that the butted-up equals signs do interfere with keyboard navigation or that they don't?

Evidence is the fact that this bothers a number of editors, who have cited problems which may not be serious, but they are real, and potentially with us forever. I will try to look at the counter-examples you mentioned, to see what would be involved in mitigating a change-over. —Michael Z. 2008-12-15 20:49 z

You are still trying to apply the rules of English prose to computer coded pages. Stop. Think. You just said that "Blocks of equals signs butted up against words are not English punctuation; this is never used in English prose." But then you appealed to a style guide for standard English prose on the formatting. The coding for the page is not prose, and is not subject to those rules. Where would # {{alternative form of|]|lang=xgc}} ever appear in English prose? Or do you maintin that curly braces, angle brackets, and pipes are part of standard English prose?

I actually find the form with equals signs abutting the header easier to parse mentally than the form with the spaces.

"...the fact that this bothers a number of editors" means there are people with opinions. Opinions are personal expressions, not evidence. And what is the number? --EncycloPetey 21:32, 15 December 2008 (UTC)

Well, it seems to me that editor preference is an important consideration in setting up our editing policies. We've deviated from the code readability of 'pedia, and for good reason, I think. However, as a project whose code is more difficult to read than most, I think that editor ease is an important consideration. Truth be told, equal signs abutted and equal signs a space away are all the same to me. Also, I wonder if the two of you need to be set in opposite corners of the discussion room. This conversation is getting awfully huffy for a minor technical formatting dispute. -Atelaes λάλει ἐμοί 21:47, 15 December 2008 (UTC)

I apologize. This is long and, I admit, huffy. But we are kinda trying to agree on some facts relevant to the question. So I will carefully respond to EP's last.

Wikitext is text, resembling typescript, and annotated with markup and macros (wiki templates). It represents written English text, and is meant to be written, revised, and read by the editors of open media projects, including the general public—everyone. Even computer languages for use by computer scientists are designed with code readability in mind, and on top of this professionals choose coding standards specifically to improve readability by people, not to ease the burden on their software compilers. I also understand that the Wikimedia developers have explicitly said that editors should not normally have to worry about the technical workings of the software, although I can't find the reference right now.

Wikitext is also designed to be forgiving to editors, to let them include or omit spaces around headings. But Wiktionary has chosen to tighten this restriction on editors, to ease the burden on bot developers. We have essentially created our own version of Wikitext, (debatable—I can still type it either way, but apparently it must be changed by a bot or something will break). We could have chosen to either include or omit spaces—or we could have required bot developers to deal with the normal range of Wikitext. But we chose the option which is further away from English typing conventions, and, in some opinions, worse for many editors. This is why it bugs me, why I think it is contrary to the spirit of the project, and why I think we should work to improve the situation. —Michael Z. 2008-12-15 23:21 z

Tiny benefit for an awful lot of edits. Not only because there is hardly ever a reason to edit headers anyway, except for the half a dozen people who clear the bad headers maintenance page. Such a massive change should, if at all, be an additional aspect of some substantial massive change for an important good reason such as a major change to the general article structure (e.g., if it was decided to move everything before the definitions to below the definitions). -- Gauss 21:26, 13 December 2008 (UTC)

I quite frequently edit headers. Most of the time, changing “See also” into “Derived terms” or some such. Or because a word is the same in several languages and I copy over the section from another language to adapt it to the other, then I have to change the language header. And so on. H. (talk) 13:46, 15 December 2008 (UTC)

So far, the benefits demonstrated have been fairly minor, and would not convince me to go through the trouble of making this switch. However, is there some standard from outside Wiktionary that we should be considering? Is there a Wikimedia best practices, or an HTML best practices, or something like that? While there are a great many pages that would have to be changed, if we do decide to change them, it could be done with bots, fairly painlessly, and at our leisure. Not being a programmer myself, I could be wrong on this, but I wonder if making a few minor tweaks to code for a few bots would really be that huge of an issue either. In short, if spaces between headers is suggested by some form of best practices, and if that in turn is used to develop other things which may become important in the future, then I think we'll be kicking ourselves ten million entries down the road because we were too lazy to change a million. -Atelaes λάλει ἐμοί 22:29, 13 December 2008 (UTC)

Actually, the instigation for this discussion was that I noticed that the Trac wiki requires the spaces to be there, and I find them convenient. I didn’t really think about the repercussions, although I remember having read Wiktionary:Wikitext_style long ago. I didn’t want to suggest changing all entries, but maybe I did, lol. I guess I’ll just have to live with it, leave the point be, not worth the hassle. H. (talk) 13:46, 15 December 2008 (UTC)

As to the 'pedia (ref above to "deviating from ..." ;-), suppose we go look at what people prefer. The English 'pedia explicitly allows spaces and not-spaces (see stylesheet). So what do people do? Sampling 100 random entries, looking for entries that use the spaces, don't use the spaces, use them in some headers, or lack any headers, we find:

100 entries: spaces 0 (0.00%), no spaces 69 (69.00%), mixed 21, no headers 10
(another run):
article is System to Retrieve Information from Drug Evidence (7841580)
100 entries: spaces 0 (0.00%), no spaces 56 (56.00%), mixed 26, no headers 18
      total spaced headers 89, not-spaced headers 416
(exit)

People there prefer leaving the spaces out. Robert Ullmann 13:53, 17 December 2008 (UTC)

Or maybe most of them haven't tried using a proportional font in their MSIE, because they don't even know that's an option. Please define what you're actually measuring before you reach for conclusions.

As I've mentioned before, omitting spaces is less of a problem for users of MSIE and other browsers which use a monospace font by default. A user of Safari, or an editor who sets the textarea to a proportional font to improve readability, then has to suffer because of this choice. Being blind isn't popular either, but we prefer to improve accessibility anyway. —Michael Z. 2008-12-17 15:48 z

I for one prefer headings without spaces. They look better to me. Having no spaces between "=" and the heading text matches having no spaces within other wiki markup, such as the one for italics, boldface, and wiki links. I do not see that the look of the headings with variable-width fonts is significantly different from the look with fixed-width font to modify the preference from no spaces to spaces; who prefers spaces is going to prefer them regardless the variable-width/fixed-width tag, I estimate. --Dan Polansky 20:21, 18 December 2008 (UTC)

Suddenly today, the "Support Wiktionary" banner appears expanded on some pages, and the "Collapse" button just refreshes it. It's getting annoying. SemperBlotto 08:29, 12 December 2008 (UTC)

• Seems to be OK now. SemperBlotto 15:28, 15 December 2008 (UTC)

I. Following on WT:BP#Counting the uncountable, and specifically Ruakh's option 6, I'd like to propose that {{en-noun}} be modified to generate the appropriate output for mostly-uncountable nouns like "milk" and "gasoline". For example, for milk:

{{en-noun|-|s}}

would produce:

milk (usually uncountable, plural milks)

Currently {{en-noun|-|s}} generates the same output as {{en-noun|-}}.

II. As long as we're considering changes to a heavily-used template, I'd also like to suggest that the template be changed so that {{en-noun|?}} generates the same output as {{infl|en|noun}} (boldface pagename + category only). Ideally this would also add a hidden maintenance category, something like "English nouns with unknown or unattested plurals".

Thoughts? -- Visviva 09:13, 13 December 2008 (UTC)

I'm in favour of this. It comes up just often enough not to be regular, and the routine is to spend two minutes scanning the documentation to figure out that it can't be done, then spend 5 seconds doing it some other way. Or else let's rename the template {{en-most_nouns}}. —Michael Z. 2008-12-13 18:04 z

I'd like something like this, too. IMO, though, there are two different statuses:

1. contributor not sure about plural (ideally marked "?")
2. plural exists in principle (by parallel to similar nouns), but is not yet (!) attestable (ideally marked "-").

The problem with this notation is that many of the items now shown as "-" need some kind of review and are, in effect, with status that would be marked "?" I would be willing to devote ("addict") myself to the manual of such a review, though I would hope that there would be parts of this that would be botable. DCDuring TALK 18:23, 13 December 2008 (UTC)

I'm not sure that distinction is salient enough... I mean, if I'm not sure about the plural, that probably means that I think the plural should exist in principle; otherwise I would just mark it "uncountable". So these seem, at most, like two slightly different grades of uncertainty to me; we're still left with a noun that is probably countable but lacks a suitably attested plural. At any rate, if we did adopt this distinction, we would need another symbol than "-" since that is already well-established in use for "uncountable". -- Visviva 12:49, 15 December 2008 (UTC)

The proposed changes sound good to me. I've experienced some of the same frustration with the current template often enough. --EncycloPetey 21:20, 13 December 2008 (UTC)

• A draft template is now mostly functional at Template:en-noun/draft; see tests at Template talk:en-noun/draft. (Note: not quite finished sorting out the "inflection table" half of the template.) Please feel free to modify, test, and improve, within the scope of this discussion. (I know there are other/more profound issues with the template, but one thing at a time...)-- Visviva 06:20, 24 December 2008 (UTC)

Some excellent improvements. I'm in. -Atelaes λάλει ἐμοί 06:38, 24 December 2008 (UTC)

Nice! —Ruakh_TALK 08:21, 24 December 2008 (UTC)

This is definitely an improvement. However, the ? should point to our glossary, where its intended meaning can be made clear for anyone unsure. Also, what about hypothetical forms? –Usually +-s, but for words like agent nouns formed with -man or -woman, they’d be -men or -women in the plural. These should be programmable (perhaps with a pl*= parameter), marked with an asterisk (*), and sometimes multiple (as in cases of -person words, which can become -people and -persons words; perhaps included using pl*2= &c.).
Finally, whilst we’re at, could we add more plural parameters to {{en-noun}} per this requæst please? † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 11:41, 24 December 2008 (UTC)

Ah, the draft template doesn't generate "?", that's just a demonstration of the current output of {{en-noun|?}}. Maybe that's too confusing... Anyway, per the above proposal, "?" just generates boldface pagename + Category:English nouns + a to-be-hidden maintenance cat. It's primarily intended for cases where we want to avoid asserting anything about the plural/countability of the headword, usually because more research is needed.

Regarding your other concerns, please do feel free to post a new batch of proposed changes separately. Personally, I am not convinced that we ever need to have more than three plurals on the inflection line. (In fact, I'm not convinced that we ever need more than two.) -- Visviva 13:35, 24 December 2008 (UTC)

It may be better for {{en-noun|?}} to display:

pagename (no plural attested)

However, even in those situations, I think it’s better for {{en-noun}} to specify a probable hypothetical plural (formed by analogy with the word’s relations) wherever possible, but showing that that form is not (yet) attested.

AFAIK, policy / convention is to list at least every standard plural form of a noun in the nominal inflexion line, so if a word has more than two or three standard plurals, then the template should be able to accommodate those supernumerary plurals. † ﴾^(u):Raifʻhār ^(t):Doremítzwr﴿ 14:26, 24 December 2008 (UTC)

To me, any distinction between plurals that aren't attested yet (because no one has had the time to research them) and plurals that are fundamentally Unattestable seems a bit dubious, particularly in the context of an open wiki. However, this being the second time that this issue has come up in this discussion, I have added a "!" option to {{en-noun/draft}} which will mark the entry specifically as having an unattested plural. Hopefully this will be agreeable to everyone.

I would be interested in a Tea Room discussion of (deprecated template usage) deus ex machina. I don't see, for example, how "di ex machina" or "dii ex machinis" can possibly be regarded as standard, whatever else may be said of them.-- Visviva 12:54, 27 December 2008 (UTC)

• Notice: If there are no objections, I will plan to replace {{en-noun}} with {{en-noun/draft}} around the beginning of January. So if any of you techie folks see something that needs to be fixed, please let me know (or fix it directly). -- Visviva 12:54, 27 December 2008 (UTC)

It's wonderful. DCDuring Holiday Greetings! 13:08, 27 December 2008 (UTC)

Looks pretty good. We should probably add more cases to the regression tests. However, these should work:

• {{en-noun/draft|-|follies}}:

Template:en-noun/draft

• {{en-noun/draft|-|pl=follies}}:

Template:en-noun/draft

• {{en-noun/draft|-|pl=follies|pl2=follys}}:

Template:en-noun/draft

first one has some stray something in there; and pl and pl2 should work? Robert Ullmann 13:29, 27 December 2008 (UTC)

Ack! That's bad. Fixed now, thanks. -- Visviva 14:41, 27 December 2008 (UTC)

(trying to create a unique section title)

Update:

The WMF dump process is working on the en.wikt, http://download.wikimedia.org/enwiktionary/20081214/ and has done all but the 7z all-history file. (So the ones you want are available.) It took over a month to complete a cycle on these. The English Wikipedia dump is scheduled to be complete in June.

The daily for today is based on that dump, rather than incremented from yesterday's.

Dumps of en.wikt content are available every morning by 09:00 UTC, see http://devtionary.info/w/dump/xmlu/

Any technical issues, please ask me. (I know you will.) Robert Ullmann 11:03, 15 December 2008 (UTC)

Thanks. Events have proven this to have been an excellent decision. DCDuring TALK 11:41, 15 December 2008 (UTC)

Hi, I have a question regarding news:// links, please see Template talk:cite newsgroup. H. (talk) 13:00, 15 December 2008 (UTC)

A fairly minor discussion re modifying this template is currently at template talk:google#Should_groups_option_restrict_to_Usenet.3F.—msh210℠ 17:39, 16 December 2008 (UTC)

FYI: the MW software now uses File: where Image: was used. Image still works as an alias, but you will see File displayed in various places. This was done because using Image for, say, .ogg files was silly. This should not affect anything you are doing, but will explain what you are seeing ... Robert Ullmann 13:36, 17 December 2008 (UTC)

I've added this to Wiktionary:News for editors. —Michael Z. 2008-12-17 18:39 z

The following WT:PREFS controls don't work at all in my Safari 3.2.1/Mac and Firefox 3.0.4/Mac:

• Put the button onto the left of the translation bars
• Hide the horizontal separator between each language section

Do they work for anyone? If not, then I'll post a note at the BP and remove the prefs. —Michael Z. 2008-12-18 23:43 z

Feel free to remove the left show button, it was only there for previewing to see if it was better than the current position - bit like Right floating TOCS except not so amazing :). Dunno about the hr's, one of those prefs that's been there since before I was. Conrad.Irwin 23:51, 18 December 2008 (UTC)

They both work for me (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5). Moreover, I like the left-hand-side show/hide personally and believe that it might be better than the right-hand-side one for new users, if we care. If someone has some good reasons why I'm wrong in my beliefs or if there are substantial technical reasons to abandon this innovation, I'd like to hear them. DCDuring TALK 23:58, 18 December 2008 (UTC)

They probably work for you because they're in your monobook.css ;). I've fixed the javascript to use your non-broken version. Conrad.Irwin 00:24, 19 December 2008 (UTC)

Your user style sheet is changing the show/hide button's position. Are you sure that the WT:PREFS control actually works? —Michael Z. 2008-12-19 00:23 z

Neither work for me- Firefox 3 / windows. Nadando 00:02, 19 December 2008 (UTC)

Don't work for me, FF 3.05, Ubuntu 8.10. I have no problem with keeping these prefs if people think others might find them useful. However, if we're going to keep them, we may want to make them work for more systems. -Atelaes λάλει ἐμοί 00:10, 19 December 2008 (UTC)

The clutter and confusion of the prefs page makes it all but useless for new users. As it is, I can't see it being much more than an indulgence for active editors who have requested a particular feature, and can't edit their monobook.css or monobook.js. First, I'm doing a search-and-destroy for anything that doesn't work at all—how could that be missed? But it does need more drastic rearrangement. —Michael Z. 2008-12-19 00:30 z

Okay, so I guess these didn't work until Connell adjusted them just now. No offence, but can we define what WT:PREFS is?

Is it a permanent set of preferences? Is it worth doing some serious work to improve the interface (e.g., my example layout)? Should we avoid cluttering it with features for which there is no demand (e.g. hiding separators has been happily broken for 2-1/2 years)?

Or is it just an informal sandbox, where editors are made to understand that some features might go away if they are part of something counterproductive (e.g., quotation marks pref depends on misusing CSS to manage content)? —Michael Z. 2008-12-19 01:19 z

It seems to currently be a little bit of both. I think that there's nothing wrong with keeping both elements, but I imagine they should be separated a bit better. I like your setup example, and would support moving towards those lines. Perhaps another section, "Experimental (highly dangerous, say goodbye to loved ones before trying)" could be added to put some of the more experimental/buggy ones in. -Atelaes λάλει ἐμοί 01:26, 19 December 2008 (UTC)

(edit conflict) I am not Connel, but apart from that... I have no objection if you remove the preferences, but it annoys me to have broken things hanging around so I fixed them for the meantime. If you want to make changes to the interface, that would be great - just be bold and do it. The interface doesn't affect people so you can be more bold with it. I use WT:PREFS to give out javascript I wrote - like the acceleration, There is no way to tell whether they are useful until people are using them or not, so yes it is used as a bit of a sandbox . Things that are broken are occasionally removed, but as you've noticed, it's much easier to give than to take away. Conrad.Irwin 01:41, 19 December 2008 (UTC)

Oops, I'm sorry. —Michael Z. 2008-12-19 15:20 z

Am I right in concluding that the rigors or trying to address the needs of many models of many browsers, not to mention operating systems, are such that it will not be practical in the foreseeable future for us to have a user interface for unregistered users that is different from the one I experienced a year ago using IE (w/o WT:Prefs)? Are, say, right-hand tables of contents and left-hand show/hide too buggy for prime time and too hard to make work for all the major target configurations? Right-hand Toc seems to me the single best change in the user interface: a dramatic increase in the number of entries that have valuable content above the fold (especially for English language speakers who are concerned about etymology and pronunciation). Can that be made to work for all users? DCDuring TALK 02:19, 19 December 2008 (UTC)

Right hand TOC is (or was) working for everyone - but there was not clear consensus to turn it on, perhaps a VOTE is in order, or at least another mention in WT:BP. It would go without saying that when we turn it on, we'd need to add a new PREF to allow it put back on the left for any sadists :). Conrad.Irwin 13:12, 19 December 2008 (UTC)

I was under the impression there was rather stiff opposition to the idea. But IMO it would be an excellent improvement; I've had it on for months, and the only problems I have seen involve {{wikipedia}}, which refuses to play nicely with other elements; I presume that would be fairly straightforward to fix. -- Visviva 14:13, 19 December 2008 (UTC)

To the best of my knowledge, {{wikipedia}} poses no problems if placed according to the instructions, which is unfortunately not always the case. Might be a job for AF at some point. -- Gauss 17:23, 19 December 2008 (UTC)

I plead guilty to having put many WP templates before the English header, sometimes out of habit, sometimes because I believe that WP deserves special ease of access for a specific entry (user likely (How would I know?) to need more than what Wikt can provide). I will stop forthwith and henceforth, if doing so if it cannot be accommodated. Is such placement evil from a user perspective? Is it technically difficult to accommodate? DCDuring TALK 18:30, 19 December 2008 (UTC)

Placing the WP box template ahead of the English header causes problems with several other templates, including project banner notices, WOTD templates, and right-hand TOC among them. I concur that every WP link should be inside a language section, since any link it provides will be language-specific. --EncycloPetey 18:39, 19 December 2008 (UTC)

{{wikipedia}} smells, use {{pedia}} always! :p Conrad.Irwin 22:47, 19 December 2008 (UTC)

This is not an objective argument, Conrad. Apart from that, it is according to Special:MostLinkedTemplates a minority opinion (64,406 links over 2,860 links!) and, on a more personal note, rightly so. -- Gauss 23:56, 19 December 2008 (UTC)

The WP template used to specify that it should be placed in various ways depending on whether the TOC appeared or not, this to try to compensate for various problems. Since fixing the "floating edit links" problem, this is no longer the case. It should always be inside the language secion it belongs to; else something extracting a language section cannot tell whether the WP link belongs to that language or not. (the lang= par is not sufficient, it can be in an FL section pointing to the relevant en.wp entry) Likewise images and such should be structurally inside the appropriate language section. Robert Ullmann 17:18, 20 December 2008 (UTC)

Have a look at the section “right-floated elements” in my style sheet. The see alsos, TOCs, sister links, and image boxes are all made the same width, to align nicely and make a virtual third column. It could be improved, but I haven't seen any layout problems in Safari. —Michael Z. 2008-12-19 21:07 z

Do you want to update the current Right TOC pref so we can all see this? Conrad.Irwin 22:47, 19 December 2008 (UTC)

I have only tested it briefly in Firefox, and not at all in MSIE. I'd rather someone try it in their user style sheet for a bit before it's forced on anyone. —Michael Z. 2008-12-19 23:42 z

I did some testing on screw, In Firefox3 Chrome and Safari for Windows the TOC is a few pixels wider than the Wikipedia box, which are both 20-30px wider than the images. In Opera, IE6, IE7 (and firefox without the -moz-box-sizing) the TOC box is 10-15px narrower than the Wikipedia box, which is again 20-30px than the images. It has no noticeable effect in Konqueror - i.e. the TOC stays narrower than thumbnails, while Wikipedia stays much wider than both. Conrad.Irwin 14:33, 20 December 2008 (UTC)

I'll have to have a closer look. I built and tested it in Safari/Mac, where it is pixel-perfect. In Firefox/Mac, for some reason, the TOC was too narrow, using MSIE's box model, and adding -moz-box-sizing: content-box; made it perfect. I'll have to trace the source of this, and it should be possible to fix it for all modern browsers. Never know about MSIE until you try, though. —Michael Z. 2008-12-20 16:41 z

I'd thought before of making several elements the same size, but ran up against the problem of not being able to tell what the user had set for thumbnail size in preferences. Note that your css will only work if a user has the same setting as you are using. (I use 180px, and the images are narrower than all the other elements as you set them.) We can fix this in WT:PREFS by adding a setting there with a note to make it match user preferences; but this can't be fixed in general. If the column was set up this way for everyone, it would have to match the default thumbnail width (for not-logged in users), and logged in users who had set preferences would be forced to set WT:PREFS to make it come out right. (And some of the widths would be bad.)

Defaulting the TOC to would go a long way toward addressing a lot of this. Else whether right or left, it will push images or LHS content off the screen. Robert Ullmann 17:04, 20 December 2008 (UTC)

Well, making it work for the default thumb size is a good start. (It is 250px, right?)

I wonder if there's a {THUMBNAILWIDTH} or equivalent system variable we can use, or a thumbnail template in the MediaWiki namespace? We could set a min-width or an absolute width for the thumbnail's invisible container box, so it will align nicely even if it is smaller, but that might make it look ugly on its own. Failing that, a supplementary preference would let the reader manually match their thumbnail size.

“On screw?” —Michael Z. 2008-12-20 17:53 z

(on the entry at screw ;-) The default is 180. There wasn't any magic word or otherwise usable bit when I looked, but that doesn't mean there isn't something I didn't find or think of. The other problem is that if the user selects something quite small (120px) you aren't going to get some of the other things to fit. (although in that case aligning images right inside a wider invisible container might be okay) btw: using your 252px wide things with images at 180 doesn't give the pure column look, but does look okay. Robert Ullmann 19:08, 21 December 2008 (UTC)

It would be nice if the script templates gave each mentioned term the correct HTML language attributes, like lang="ru" or lang="az-Arab". I've described a basic solution, with some working code. Please have a look over it and leave comments, corrections, or improvements: User:Mzajac/Language attributes. —Michael Z. 2008-12-20 00:02 z

Which template should be used for possessive noun forms such as "kertem" = my garden, where the lemma is kert and the first-person singular possessive ending is -em? If there is no such template, do we need one for other foreign languages besides Hungarian: {{possessive of}} with the following parameters:

• Parameter {{{1}}}: with values 1 or 2 or 3, resolved as first-person, second-person, third-person
• Parameter {{{2}}}: with values s or p resolved as singular or plural
• Named parameter: lang=, with categorization, for example: Category:Hungarian noun forms
• Built-in anchor back to lemma

--Panda10 16:20, 20 December 2008 (UTC)

I'd format it with a non-templated parameter so that the usage would look like {{possessive form of|First-person plural|word}}, this way we avoid havint to edit to account for dozens of later variations (e.g. you can have {{possessive form of|Second-person female plural accusative|word}} if it's needed in another language). admittedly, by then you might as well just use {{form of}}... Okay., that idea is not all that helpful, but the issues of likely later addition of parameters stand. Circeus 22:40, 20 December 2008 (UTC)

I don't know Hungarian, but it seems from what you've written at kert, and at Appendix:Hungarian possessive suffixes. that you'll need at least three parameters: singular vs. plural noun ("my garden" vs. "my gardens"), 1st- vs. 2nd- vs. 3rd-person possessor ("my garden" vs. "your garden" vs. "his/her garden"), and singular vs. plural possessor ("my garden" vs. "our garden"). In the case of a plural noun, it might be desirable to link to the noun's plural non-possessed form as well, though I could go either way on that. I'm a bit confused about how this fits in with the case system; do possessive-suffix–having nouns not have case?

I'd recommend one of two approaches:

1. Use named parameters rather than positional ones. If other languages need to use this template, they'll likely need slightly different criteria (they might need to specify the possessor's gender, the noun's case, whether the possession is alienable or not, etc.), and it's easier to add named parameters. The downside of named parameters is that people always forget what they're named; but even with positional parameters, people always forget what order they go in, what the legal values are (is it s or sg or singular?), and so on.
2. Create a Hungarian-specific template, say {{hu-possessive of}}, with exactly what Hungarian needs. Other languages will have different needs; they can have different templates, with different parameters and different text.

(These approaches are not mutually exclusive.)

—Ruakh_TALK 00:04, 21 December 2008 (UTC)

Thank you both for your thoughts. Yes, Hungarian possessives can get all the regular case endings, for example

kertemben (kert + em + ben) = in my garden

kertjeinkhez (kert + jeink + hez) = to our gardens

This will require lengthy definitions:

kertemben --> First-person singular possessive form of kert, singular possession, inessive case.

I will go with the Hungarian-specific template, as you recommended. For noun form (or any other POS form) entries, I like to provide a simple example because there will be users who will not understand the grammar terminology, while an example and its English translation will make it clearer: kertemben = in my garden. Thanks again. --Panda10 01:23, 21 December 2008 (UTC)

Such examples may not be practical, long term. While there are others who disagree with me on this, I have a strong preference for simple, grammatical definitions with inflected forms. If a lemma has multipler senses, a gloss such as "in my garden" may imply that it is only limited to one of those senses. I suggest setting up an inflected forms template for Hungarian, and perhaps have a Hungarian grammatical appendix which can be linked to by the template, so users who don't know what inessive means can look it up. I'm not vehemently opposed to such examples, by any means, however, and will not work for their exclusion. -Atelaes λάλει ἐμοί 04:48, 21 December 2008 (UTC)

Thanks, Atelaes. I see your point and I like the appendix idea. --Panda10 12:57, 22 December 2008 (UTC)

How do I make this cat (and ditto in other languages) have a link to Hinduism rather than hinduism? SemperBlotto 22:58, 21 December 2008 (UTC)

One uses the description= parameter to override the default. I've inserted this into the category. --EncycloPetey 23:06, 21 December 2008 (UTC)

The various on-English subcategories receive their description from Template:topic cat description/Hinduism, which I have created. --EncycloPetey 23:11, 21 December 2008 (UTC)

Perhaps some of the techy folks could make a list of entries sorted by language name using a deprecated syntax for {{inflection of}} so that they can be manually corrected by the editors. E.g., in entries such as abacorum where the first positional parameter is 1) unwikified 2) uses entry#<language-name> format.

Or perhaps fix the template itself to make it backwards-compatible to older format (if it can be fixed) as I suspect these are quite numerous. --Ivan Štambuk 07:12, 23 December 2008 (UTC)

Fixed the template. (;-) We can still make a list of the entries where someone used word#Latin (from May 07 to Jan 08), so they can be changed to use lang=la. I think they are all Latin; but I'm not sure. We can see. Robert Ullmann 08:08, 23 December 2008 (UTC)

Great! :) Also, as far as I understand it, in this particular case the usual usage of lang= to link to language sections is not preferable to the normal #<language-name> wikification because of the page-count problem, as many of these inflected forms are the only entries on their respective pages (at least that's what FitBot and SemperBlottoBot have been doing judging from their contributions). It's really bad to see some nice, clean and consistent usage to be broken in order to circumvent a problem that is somebody other's care. --Ivan Štambuk 08:25, 23 December 2008 (UTC)

see more notes at {{inflection of}}. Would be good to use lang= in all cases (except with the old #syntax, which would create two section links ;-), even if the first param is a wikilink to make the page count. (Note that only has to be done once on a page; and we should really do something else for page count. It is getting very irritating.) Robert Ullmann 08:31, 23 December 2008 (UTC)

There are 2108 entries which use this sort of thing, most Latin, but a number of others, some fairly recent. Most are {inflection of} or {term}, but there are others. I'm planning on fixing all the Latin for those two templates, and then we can see what is left later. Robert Ullmann 08:38, 24 December 2008 (UTC)

I've identified 1021 of these that are (a) Latin references, (b) use {term} or {inflection of}. Other languages, templates, and some variants left for later. Set up to run, see this edit to abactor, which shows both templates. If the alt word is the same, it is elided. (as the example shows) Robert Ullmann 10:59, 24 December 2008 (UTC)

Do note that this change doesn't affect page count; it doesn't add or remove brackets. The kludge question is mostly separate. Robert Ullmann 11:21, 24 December 2008 (UTC)

running these; no change to page count will occur, replacing deprecated syntax with the lang parameter as per initial request; I/we can then look at the others (note I have snaps of before/after dumps, as always ;-) Robert Ullmann 00:04, 25 December 2008 (UTC)

Fixed another 302 for a small set of other languages; will check what's left after another dump. Several hundred more are things that matched the general pattern ({{xxx|yyy#zzz|...}}) but are not of interest here. Robert Ullmann 09:59, 27 December 2008 (UTC)

The business of adding explicit links to various templates, usually "form of", to make pages "count" in the NUMBEROFARTICLES statistic was sort of okay, but is causing increasing trouble.

I'd like to propose a different kludge. Still a kludge, but at least independent of other templates; we add {{count page}} to entries which do not otherwise have links. Like this:

{{count page|]}}

at the end of page. AF can do all the work (:-), it would be simpler than the code it has now. (I always like that.) We can find the pages, and remove it later cleanly if MW ever uses a rational statistics counter. See Wiktionary:Page count. What do you think? Robert Ullmann 10:23, 23 December 2008 (UTC)

I've set up AF to do this (can always be changed to something else). Minor technical issue preventing blank line(s) at end in some cases, sorted. Please comment. Robert Ullmann 11:26, 23 December 2008 (UTC)

What'll I do with the four keystrokes that you propose to make redundant? This couldn't come in a worse economy for them. And right before Xmas. DCDuring TALK 12:14, 23 December 2008 (UTC)

I've applied to SecTreas Paulson for some of that TARP money to carry them over. Robert Ullmann 12:17, 23 December 2008 (UTC)

Sorry. He says it's all been spent on new executive jets for the bankers and ponies for their children. OTOH, the 4 brackets themselves are still employed ... Robert Ullmann 16:58, 23 December 2008 (UTC)

An elegantly stupid solution to a stupid problem.  :-) Well done. -Atelaes λάλει ἐμοί 16:12, 23 December 2008 (UTC)

Thank you. I think. The convolutions people were going to with the templates was using up time better spent on other things. (see prev section and the section on English gerunds and plurals in BP) So we give the minor task to AF, and most people can forget about it. The bot operators generating pages may want to take another look at what they are doing, or may not. btw: AF is not adding this to entries that consist of {misspelling of} or {only in}. Robert Ullmann 16:58, 23 December 2008 (UTC)

Thanks, Robert. Rod (A. Smith) 04:38, 24 December 2008 (UTC)

Also, will AF be switching pages which use the less desirable "foo#Language" format, in favour of "foo|lang=lan}}, kludge"? -Atelaes λάλει ἐμοί 06:42, 24 December 2008 (UTC)

I was just about to get back to that (;-) as soon as I make myself a pot of tea. I think I will probably run something separate; I don't see evidence that people are continuing to add that format, so it will be sufficient to fix the existing ones? Robert Ullmann 06:50, 24 December 2008 (UTC)

Hmmm.....perhaps we ought to ask the folks currently running inflection bots, and come to an agreement first. I'll contact them. -Atelaes λάλει ἐμοί 07:13, 24 December 2008 (UTC)

Those can either keep doing what they are doing, or something simpler now. As to the #Latin entries, FitBot is doing things like {{inflection of|]||acc|m|s|lang=la}} which is a lot harder than {{inflection of|implicans|implicāns|acc|m|s|lang=la}} just to generate a link. I'm not planning (now) to "fix" those. See previous section. Robert Ullmann 10:56, 24 December 2008 (UTC)

The FitBot additions are generated off-line from a master file. I do a series of find-and-replace to generate a text file, then FitBot uploads the individual entries. If the new kludge meets with general approval (and won't result in some nasty "You're cheating!" backlash from outside the project), then I can adjust my master templates. --EncycloPetey 20:16, 24 December 2008 (UTC)

It can reasonably continue working just as is if desired. If you want to use the first two parameters of {{inflection of}} as designed, with lang=la (which you already do), then you might just add the "cheat" if you didn't generate any links brackets. In the case where you are appending, you needn't worry about it either way; you are tagging for AF, it will add or remove the kludge as needed. Alternatively, just let AF pick them up later. Robert Ullmann 06:55, 26 December 2008 (UTC)

I've forced AF to work through Christmas. In spite of some whinging. (:-) The count shown is now reasonably accurate, is 1,097,289 now, and the XML dump process (to which I added code to count the entries we want counted) said it should be 1,097,648 as of a few hours ago. So that is fairly good. Specifically, AF removes the kludge when not needed, and adds it if

• the entry has no [[
• and is not a "misspelling of" entry (although it doesn't look at the whole entry, so may miss a case once in a while where it is also a valid word)
• and does not use {{only in}}
• and is not tagged {{nolanguage}}, {{wikify}} or {{delete}}

For reference, this problem was originally reported as bugzilla:11868, never resolved.

If we decide to use some other variation to "cheat", this can easily be adjusted. To be serious, sans snark: note that this is not cheating, as we are carefully causing the counter to reflect the actual count, in spite of bug 11868. Robert Ullmann 06:55, 26 December 2008 (UTC)

As of this morning, the XML dump process said there were 1,098,500 countable entries at 08:00 UTC. Now, 09:28 or so, there are 1,098,579, so we are quite close. Note that we will count a few too many: when a misspelling or only-in entry picks up iwikis, it will count even when not wanted. Also things like pages tagged for delete that have links on them suchlike. Not going to be perfect.

However there is also an overrun caused by the counter being broken two months ago, and not being restored correctly (they counted differently ...); I don't know how big that is, but it applies to all wikis. All in all, seems to be fine. Robert Ullmann 09:33, 27 December 2008 (UTC)

The exactly corresponding numbers are 1098524 (XML) 1098579 (counter), at 09:17 UTC (;-) Robert Ullmann 09:38, 27 December 2008 (UTC)

Wiktionary:Entry templates mentions entry templates for foreign languages, but says, "The corresponding language must be set in Preferences in order to see the them." Is there any provision for entry templates that are not in the language list at Special:Preferences? Rod (A. Smith) 21:19, 23 December 2008 (UTC)

FYI, I resolved this issue by having Mediawiki:Monobook.js add a language drop-down to MediaWiki:Noexactmatch. Please let me know if you notice any issues. Rod (A. Smith) 11:45, 30 December 2008 (UTC)

Clever! Three issues:

1. This approach will quickly result in a very ginormous MediaWiki:Noexactmatch. Since the whole thing requires JavaScript anyway, mightn't it as well include the bare minimum amount of information possible in the HTML — something like

   <div style="display:none" id="preloadGuide">

   <p>ase : adj, noun, verb</p>

   <p>es : adj, noun, verb</p>

   <p>sv : adj, adv , noun, verb</p>

   </div>

   — and generate everything in JavaScript? (This would require a rigid naming scheme for new-entry templates.) Actually, maybe even the list of languages and information about the languages should be JavaScript-loaded, so it's cacheable.
2. It seems to reference a bunch of non-existent preload templates. Is this just a proof of concept? (And is it intentional that Swedish has {{sv-new-adv}} for both adjective and adverb?)
3. On my system, the "preloadGuide" div starts out wide enough to contain the initial message, but when I select a language, it shrinks horizontally, and isn't as wide as the any of the tables of buttons. (It has a different width for each language I select, and every time I leave a given language and come back to it, it returns to the same width for that language.) But this isn't a functionality problem — it's not like overflow-clipping is turned on — it just looks a bit funny, and results in a heavily linewrapped "American Sign Language (ASL):". :-)

—Ruakh_TALK 14:14, 30 December 2008 (UTC)

Thanks for the review and feedback.

1. I agree, some standardization would help, and if that can yield a more maintainable MediaWiki:Noexactmatch, all the better. Wanna give-er a go?
2. I've fixed the sv-adv typo. I've also now added a template for Spanish verbs, but I'm not convinced that my format is the best. It seems helpful to intersperse instructions using something that should obviously look like replaceable text, but I'm not sure how best to format them. I used single square brackets, but I imagine that may be confusing given use of double squared brackets. Feedback is very welcome.
3. Not sure about the horizontal shrinking you are experiencing. I've made a small change to fix the width of the language names, but I don't have a suite of testing browsers to use. Is it better now? If not, does anyone know how to fix the horizontal resizing or the heavy linewrapping Ruakh notes?

Rod (A. Smith) 19:06, 30 December 2008 (UTC)

Thank you for actually doing it! Talk is cheap. ;-)

1. Sure, I'll take a look.
2. Thanks. I don't know how preload templates should look for users to understand them. We use them for Wiktionary:Feedback, and experience there suggests that even the most basic ones befuddle a great many users.
3. O.K., I've just tested locally, and it looks like the shrinking and the line-wrapping might actually be separate issues. The line-wrapping is fixable using style="white-space:nowrap". The shrinking makes me think that FF3 is on crack — it looks like the "preloadGuide" div is always the right width for just the table, so is two narrow for menu+table. For whatever reason, adding style="border:1px solid transparent" to the table seems to fix it in FF3; dunno how other browsers feel about that.

—Ruakh_TALK 23:05, 30 December 2008 (UTC)

Why has the font used in the edit field changed to monospace? Where did we ask for this?

This is far less readable than the default up til now (in Safari/Mac), especially at this font size. We're editing English text and markup here, not computer language. —Michael Z. 2008-12-24 01:10 z

It's always been Monospace (in all the browsers I have used a memorable number of occasions), and should stay that way in my opinion - but then I spend a lot of my time programming, so I suppose I'm used to it. Conrad.Irwin 01:24, 24 December 2008 (UTC)

No, it wasn't set, so the text would appear in the "sans-serif" defined in monobook.css, unless your browser overrode that with monospace for text areas (which many do, perhaps because some programmers design web browsers as if everyone were programmers). As of today, it is overridden by "font-family: monospace" in http://upload.wikimedia.org/skins/common/shared.css?192x. For Safari users the edit field is now set in 11-pixel Courier, which about as bad as it can get.

A good monospace font may be fine for programming, where code fragments and their structure is read, and indentation is important, but it sucks for reading English text, and monospace 11 sucks supremely, and I haven't even had a look at non-Latin text yet.

The same thing just happened in Wikipedia. This is not an accident; somebody just made a change to make my text display far worse. —Michael Z. 2008-12-24 01:48 z

In which case you need to moan at https://bugzilla.wikimedia.org/ where such far-reaching changes are made. It presumably only affects Safari (and maybe Chrome), as they're the only major browsers I don't use often enough to notice it wasn't Monospace. Conrad.Irwin 01:58, 24 December 2008 (UTC)

Thanks for the pointer.

Just FYI: I now can't distinguish macrons from breves or háčeks, nor hyphens from tildes. Old Cyrillic characters show up in a rather different mono font, and many other scripts show up in proportional font anyway. —Michael Z. 2008-12-24 02:04 z

If anyone cares, please post your opinion at bug 1941, perhaps more gracefully than I have. —Michael Z. 2008-12-24 02:26 z

I have to agree with the assessment that overall it is Safari's behavior that was anomalous/unusual. The modification primarily allowed Safari to automatically benefit from the use of monospace made all over the place with the assumption that the font is used everywhere. If you are that dead-set against it, isn't it exactly what monobook.css is for? Circeus 04:27, 24 December 2008 (UTC)

Circeus, I don't understand the argument. (And are you a Safari user, or do you just think you know what's good for us better than we do?)

Yes, Safari's behaviour is “anomalous/unusual” in that it uses a better font for text editing. Perhaps those who choose their browser do so on the basis of such design features. How does is bringing that down to the lowest common denominator, on the basis of a single editor's complaint about table editing, “automatically benefiting” anyone? —Michael Z. 2008-12-24 08:56 z

Michael, I think at some point you will have to recognize that what you refer to as "better" is your own opinion, and may place you in a distinct minority. I haven't edited the wikt with Safari, but would have been very upset to find it using a proportional font. Editing in a proportional font is dreadful. Just horrid. (And no, it doesn't matter what I am editing; I'm writing text now, not code.) It is very good in my opinion that they have fixed this. Robert Ullmann 11:08, 24 December 2008 (UTC)

Yeah, it's my opinion, and that of some others—and I can list some concrete reasons why I believe this is for the worse. But the main point is that this change was imposed on Safari users after a single, barely-discussed complaint. I see no evidence that Safari users want this, but a number of non-Safari users are telling us that we should.

See also conversation at Wikipedia, and bug 1941: CSS tweak for Safari. —Michael Z. 2008-12-24 16:16 z

According to the bug report, it's been reverted, at least for now. -Atelaes λάλει ἐμοί 19:53, 24 December 2008 (UTC)

It's now resolved WONTFIX, and the update appears to have been rolled back on both en.Wikt and en.Wikipedia. —Michael Z. 2008-12-25 00:21 z

I created {{hu-daybox}} to step through the days of the week. I copied and modifed the {{cardinalbox}} template, but the result is not perfect. There is an extra blank line in the middle section above Adjective. I can't figure out what's causing it. See szerda (Wednesday). Can someone please help? Would it make sense to create a general daybox for all languages to use? How about for the months? Thanks. --Panda10 14:28, 26 December 2008 (UTC)

Visviva removed the blank line, thank you. --Panda10 19:00, 26 December 2008 (UTC)

Could someone make the e's preceding the suffixes in the past tense and past participle optional? Thanks in advance, --SK luuut 22:06, 30 December 2008 (UTC)

Should the default be to include the e's or not? Also, just to clarify, should the e in the auxiliary be optional, or no? -Atelaes λάλει ἐμοί 22:10, 30 December 2008 (UTC)

Sorry, I didn't see Atelaes' questions before editing. I made it default to no 'e', though that should definitely be changed if it's inappropriate. And I did not modify the auxiliary. I rigged it so that setting the parameter e adds an e; e.g., use |e=1|.—msh210℠ 22:14, 30 December 2008 (UTC)

I don't really care what the default is, but I believe that no 'e' would be most convenient. Take a look at lusterje which should be without an 'e' at the start of the suffix in the past tense and past participle. I don't see any 'e's in the auxiliary, only hääbe. Best regards,--SK luuut 22:58, 30 December 2008 (UTC)

Forgot to mention that the 'e' in the imperative singular should be optional as well--SK luuut 23:00, 30 December 2008 (UTC)

I've added the optional e to the imperative singular. It should be all set now. Some of the previously created entries will be wrong until the job queue is cleared, but they will be fixed in time (if you want to double-check them before then, simply open the editing window and do a "Show preview", which will show you what they will look like when the servers catch up). I suggest you check for entries which should have the "e", and add the e parameter accordingly. -Atelaes λάλει ἐμοί 23:05, 30 December 2008 (UTC)

Thank you:) I assumed that changes would take effect immediately. --SK luuut 23:15, 30 December 2008 (UTC)

Take a look at fräigje. When you press "Show preview" there are no 'e's.--SK luuut 23:18, 30 December 2008 (UTC)

This has to do with how the Wikimedia software interprets template calls. By simply putting "e", the software interpreted it as "2=e". Since there is no second parameter, it is simply tossed. In order for the software to recognize e as "parameter e", you have so input it as "e=(something)". I suggest you stick with msh210's suggestion of simply putting "e=1". I have fixed the entry. -Atelaes λάλει ἐμοί 23:30, 30 December 2008 (UTC)

I want to kiss you lol:P--SK luuut 23:36, 30 December 2008 (UTC)

Is easier to use "e=e". Then you can code {{{e|}}} instead of a parser function conditional. In just about any case where one might use a flag (xx=1), there is a better way. Robert Ullmann 14:51, 31 December 2008 (UTC)