Wiktionary:Grease pit/2007/August

Is it just me, or does anyone else get the Word of the Day listed with the header "Word of the Day for August 1"? Is something at my end messed up, or has something gone wonky? --EncycloPetey 01:31, 4 August 2007 (UTC)

That's the header I get, too. —Ruakh_TALK 03:03, 4 August 2007 (UTC)

On second look, it's not just the header; in general, that box is showing {{Wiktionary:Word of the day/August 1}}. {{CURRENTDAY}} still seems to be working, though; it's just like MediaWiki is no longer updating {{Word of the day}} whenever {{CURRENTDAY}} changes. The nice thing is, we know exactly what day the problem arose, so someone familiar with the code tree can look for changes made Wednesday to the way the job queue handles those variables. —Ruakh_TALK 03:14, 4 August 2007 (UTC)

http://en.wiktionary.orghttps://en.wiktionary.org/w/index.php?title=Wiktionary:Word_of_the_day/August_4&diff=2803414&oldid=2788418 --Connel MacKenzie 04:14, 4 August 2007 (UTC)

Thanks. --EncycloPetey 07:58, 4 August 2007 (UTC)

Now that we no longer include Modern English possessive forms, some technical changes will need to be made to {{en-noun}} (and, perhaps, to {{en-plural}}, too) — as discussed here and here. Who here feels competent to make the necessary changes? † Raifʻhār Doremítzwr 22:55, 5 August 2007 (UTC)

Well, there are at least three relevant kinds of competence, and all are subject to wiki-style collaboration.

First is a linguistic competence: the competence to determine rules the template can use to compute the possessive forms automatically where possible (and to know when it can apply those rules and when it needs to rely on outside intervention. Since the Wikimedia projects don't support the StringFunctions extension yet, this is rather limited, but I think it's fair to say that:

• If the template is called without specifying a plural and without marking the noun as uncountable; or, if only one plural is given, and it's just "s"; or, if only one plural is given, and it's equal to the singular plus "s"; then the singular possessive is formed by adding -'s and the plural possessive is formed by adding -s'. (This doesn't cover some incredibly-old-fashioned possessives, e.g. patience', but I don't think it's a big deal for those pages to just list e.g. patience's until such time as a human editor or bot gets around to adding the old-fashioned alternative.)
• Otherwise, it might be possible to infer the plural possessive in some cases (specifically, if the plural is given as "es" or the singular plus "es", then the plural possessive is formed by adding -es'), but not the singular possessive. (That's not completely true, in that any singular noun can form its possessive by adding -'s, but I think that in this case there are enough people who'd still use -' with some of these words that we're better off writing nothing than including only one. Though maybe not: it might be that people only do this with proper nouns, which obviously aren't affected by {{en-noun}}.) Since it would look silly to include the plural possessive and not the singular, I think we should omit both by default in this case.

Second is a user-interface-design competence: The competence to determine the best way for users to be able to specify singular and plural possessives, keeping in mind that it needs to be possible to specify multiple possibilities, as well as to label some of them. In the case that more than one plural is specified, it might also be necessary to tie specific plural possessives to specific plurals. Together with this is the competence to decide how these should be displayed to the reader. I really don't have any suggestions on this front, except to make the rather obvious points that we're going to need named template parameters for this, that it should resemble the support for special plurals as much as possible (except without the numbered parameters and magic "-", except of course that a strictly uncountable noun won't have a plural possessive), and that it might actually turn out not to be worth it to include plural possessives on the singular form's page.

Third is a wiki markup competence: Editing the template to fulfill the above. This doesn't look too bad, as template stuff goes; I'm pretty sure I can do it.

As I noted above, all of these are subject to collaboration; opinions are welcome. :-)

—Ruakh_TALK 00:53, 6 August 2007 (UTC)

P.S. We also need to decide whether other parts of speech's (prepositions', verbs', etc.) inflection templates should also have support for possessives. —Ruakh_TALK 00:53, 6 August 2007 (UTC)

Which English verbs have possessives? --EncycloPetey 19:50, 6 August 2007 (UTC)

I believe they all do. As discussed previously, a possessive is formed by adding -'s (or in some cases -') to the last word of a noun-like construct; hence, "Our advertising seems to have worked well. Almost everyone came; and the one woman who didn't come's daughter was in the hospital, which is presumably why." —Ruakh_TALK 21:22, 6 August 2007 (UTC)

Isn't that the possessive of the noun phrase "the woman who didn't come", rather than of the verb "come"? SemperBlotto 21:29, 6 August 2007 (UTC)

Yes, but I don't think that affects my point. —Ruakh_TALK 19:18, 7 August 2007 (UTC)

Exactly. The verbs themselves have no possessive, only noun phrases and words which can function in the place of such phrases have possessives. The verb come does not have a possessive, and listing such on its page would be terribly misleading. --EncycloPetey 21:33, 6 August 2007 (UTC)

I agree, but people wanted this for nouns, and I think it's the same situation for other words. And this doesn't just affect the templates; people were talking about providing pronunciation information for possessives, and obviously that information is also relevant for other words (since -'s's three-way alternation between , , and always obtains). The only quirks are (1) the personal pronouns' possessive forms (that we usually say "my" instead of "me's"), and (2) -'s's alternation with its silent form -' (well, usually silent — obviously Arkansas' is pronounced differently from Arkansas); and in both cases, the discrepancy between these quirks and the general rule results in inconsistency between different speakers' application of these quirks. The only way to address this comprehensively is to describe it at 's. —Ruakh_TALK 19:18, 7 August 2007 (UTC)

If you agree, then why are you proposing somehting no one has suggested doing? We do not have to put all the information on the page at 's; we can create a whole Appendix:English possessives or Appendix:English possessive forms to treat the issue in full. --EncycloPetey 19:41, 7 August 2007 (UTC)

I'm not proposing anything; I said that something needs to be decided, because there are arguments to be made both ways, and it's relevant to what we're currently discussing. I don't understand your problem here, honestly; is it so horrifying to you that something might be mentioned without everyone taking a side first? —Ruakh_TALK 20:52, 7 August 2007 (UTC)

Presently located at {{context x}}

While the old template involved a set of 10+ different sub-templates, and could easily transclude many hundreds of lines in an entry, with many hundreds or thousands of parser function calls, this is one fifteen line template, transcluded once for each tag, with unused evaluation alternatives suppressed. So server load is very seriously reduced.

It does all the same things, as well as allowing a much simpler syntax:

{{astronomy|of a star}}
{{astronomy|physics}}
{{UK|slang}}
{{usually|jocular}}
etc.

Explicit calls to context still work of course. The constraint is that the first label must be a template; and during the transition, all of the templates in this simple syntax must be the new form. I've updated {{astronomy}} and added modifier {{usually}} so far.

The spurious stuff in Special:Wantedpages will all go away. (I also need to fix {nav}.) It does need the language code templates unlinked.

Once all of the label templates are converted, {context x} can be copied (not moved) to {context} (has to be a copy because double redirects don't work! technical nit, can be fixed afterwards ;-) Take a look. It plays fairly nicely with the old stack of templates, I only had to add one parameter to one call to make it work. (oh, and force the language code back to lower case, the old code does all sorts of atrocious things with it!) This really is a fairly simple task, I don't know why it was ever made so complicated ... Robert Ullmann 23:24, 5 August 2007 (UTC)

I've not really been following all the discussion of {{context}} and its kin (complex Wiki template markup gives me a headache — it is beyond me how someone in this day and age could have created a markup language that can't even be approximated with an ABNF), but if your description here is accurate (and I assume it is), that sounds great. Please, go ahead with it. :-D   —Ruakh_TALK 00:09, 6 August 2007 (UTC)

Nice work. A couple really minor things, but otherwise this looks really slick:

1. You could use {{TALKPAGENAME}} instead of {{TALKSPACE}}:{{PAGENAME}}
2. There are a couple places with empty alternatives that could just have the "|" removed:

   {{#if:{{{sub||}}}|... to {{#if:{{{sub|}}}|...

   {{#switch:{{{1|x}}}|...|_= |}} to {{#switch:{{{1|x}}}|...|_= }}

Neither of these actually effect the way it works, as I'm sure you know. Mike Dillon 00:35, 6 August 2007 (UTC)

Thanks! There are still some tweaks; I realized in the middle of the night that you can't conditionalize DEFAULTSORT that way, so Category:Astronomy is in some essentially random order right now ;-) and a few other things. The first extra | you mention above is a typo, the latter was a reminder while I was editing that I was leaving a null default case. (oh, and you mean affect ;-) Robert Ullmann 13:18, 6 August 2007 (UTC)

I did indeed mean "affect". Just be happy that I got the code part right after a couple beers. Mike Dillon 15:27, 6 August 2007 (UTC)

Will the new template handle mismatches between desired display and categorization? I'm thinking of cases like {{star}}, where we want an in-line context display of (astronomy) but wish the term to be categorized in Category:Stars (a subcategory of Cat:Astronomy) rather than cluttering the main catgeory. Also, will this still handle non-English categorization by use of lang=xx? --EncycloPetey 19:54, 6 August 2007 (UTC)

Yes, {star} would/will simply specify label=astronomy|topcat=Stars. (note that {star} presently calls the "old" templates, but works correctly indirectly calling {{astronomy}} ... although it cats in Astronomy as well, which it did before) The lang=code parameter works as before. (Except: lang=en shouldn't be used, and isn't checked for) Robert Ullmann 20:04, 6 August 2007 (UTC)

I'm glad if I can specify a category sortkey in the tag in a manner like "skey=". Though of course template labels need to be modified to pass the parameter, I think I can cope with it everytime when the need arises. Meanwhile, after this change, there should be no problem for AutoFormat in continuing the current procedure of handling context tags in Japanese entries, leaving the redundancy. ―Tohru 02:10, 7 August 2007 (UTC)

Okay, we will try this; it would be nice if DEFAULTSORT would be helpful, but it simply isn't. The skey= parameter is a prefix to PAGENAME, it can't be the whole key, but this will produce the same result. Robert Ullmann 22:30, 7 August 2007 (UTC)

(clarifying the somewhat murky statement) skey= is a prefix to pagename, but if the value given is a form of the whole pagename, it will work fine, will just have pagename appended to it. So if you use the same value as the hidx= parameter in the ja- templates that will work.

however, the resulting code never uses the DEFAULTSORT value, and this is probably a negative; in hangeul entries it is very useful, since there can only be one language section, and there is one sort order. Likewise for hiragana, but entries in kanji and romaji can't use DEFAULTSORT in the general case. DEFAULTSORT just doesen't work the way it ought too (and given the design of the parser, it essentially haas to work the way it does). Haven't sorted this yet. Robert Ullmann 13:30, 8 August 2007 (UTC)

may be able to fix this, will look at it a bit later (DEFAULTSORT checks if the key is blank, not whether it was provided as with a template parameter). Robert Ullmann 13:43, 8 August 2007 (UTC)

fixed so skey= and DEFAULTSORT play nicely Robert Ullmann 15:08, 8 August 2007 (UTC)

First of all, thank you for taking the request into consideration (and implementing and documenting it). But I'm afraid that the sort order of the concatenated strings could be inconsistent with the expected order, due to the variability of the sort key's length. Taking 歯 (は) and 母 (はは) as example, the former should precede the latter, but the latter "はは母" will precede the former "は歯" if they are sorted by the concatenated strings, assuming the page name is to be appended to the skey directly. Or am I overlooking something? ―Tohru 14:29, 8 August 2007 (UTC)

There's a space between the sort key and the page name, so it will sort as "は 歯" followed by "はは 母". Mike Dillon 15:00, 8 August 2007 (UTC)

Actually, I just looked again and there isn't a space, but a space would make it work. Mike Dillon 15:02, 8 August 2007 (UTC)

As you note, the space was missing, should've been there; fixed now. Robert Ullmann 15:08, 8 August 2007 (UTC)

OK, thanks. I should've noticed that it was needed and missing there... ―Tohru 15:37, 8 August 2007 (UTC)

Besides, as I've previously stated, the problem of context templates being used to label alternative forms, synonyms, etc. where there shouldn't be any categorization, there are a couple of other recent developments that you should be aware of. One is the introduction of the glossary, which makes any error checking more difficult. If you wish to use <noinclude>{{checklabel}}</noinclude>, which might be a good idea given the increased complexity of the labels themselves, a parameter for the glossary would eliminate those mismatches. Another problem is the use of a default other than English, as per {{Mexico}}. It should probably be discouraged, but on the other hand we might need to rethink regional labels like "South African English". It's something I haven't fully thought through. DAVilla 07:42, 9 August 2007 (UTC)

Oopsie, your template does a little hickup on {{context x|neologism}}. DAVilla 08:05, 9 August 2007 (UTC)

The {neologism} template isn't a context template. And yes, it doesn't like getting lang=| ;-)

Does AutoFormat know that, or would it give backal a backal treatment? I know you don't like tricky code, but if you don't use the sub parameter to double-check that it's a label template, there are going to be holes. DAVilla

yes, it knows the list of context templates, as long as someone hasn't recently (since last XML) changed a context template to something else Robert Ullmann 11:44, 9 August 2007 (UTC)

The context templates shouldn't be used anywhere else other than definition lines, that's what we have {italbrac} for.

The whole context system does something useful, which is to standardize the names. At the very least I'd like to be able to call the same templates from {{label|...}} and not have the pages categorized. DAVilla

but that name standardization is appropriate for contexts. If I write (Mexican) somewhere else, it should not be magically converted to Mexican Spanish! Trying to overload the set of semantics we are using for definition contexts with something else is a very bad idea. Robert Ullmann 11:44, 9 August 2007 (UTC)

Well I guess we can wait for it to become a problem, if it ever gets that far. The ones I primarily see are {{US}}, {{UK}}, and {{slang}}. DAVilla 12:03, 9 August 2007 (UTC)

I think the error checking is much better done by analysing the whole set, not trying to display little warnings that no-one will notice if they aren't looking at the template page.

People look at the template page when they set up the templates. Speaking of which, {{newlabel}} would be a convenient tool for doing just that. Feel free to override it. DAVilla In fact please do override it, and I can document it there and on a help page. DAVilla 03:44, 10 August 2007 (UTC)

The regional labels should all specify a language if not English. And yes, there is an ongoing problem with inconsistent use. Robert Ullmann 10:22, 9 August 2007 (UTC)

Could you clarify that? {{Mexico}} categorizes as Category:Mexican Spanish when it should probably categorize as Mexican {{subst:language}}, and likewise for any region name. I don't think there's any way to make something other than en apply across the contextual list, so {{checklabel}} or your wholistic analyzer should catch that. DAVilla 11:32, 9 August 2007 (UTC)

A bit murky because the existing templates and redirects have several patterns. And context x does apply the default language in a template to the following labels. (and you didn't think there was any way ;-) ;-) Robert Ullmann 17:05, 9 August 2007 (UTC)

Well good then! That's why I brought it up. I meant downward and upward, but downward is good enough. Just be sure that it's consistent, e.g.

• {{Mexico|slang}}
• {{uncountable|Mexico|slang}}

should produce the same categorization, and

• {{Mexico|slang|lang=en}}

should not. DAVilla 03:44, 10 August 2007 (UTC)

I just tested it and it works. I'm not sure why because it looks like {{uncountable}} is passing an empty language string to {{Mexico}} via one of your context templates, and an empty string is not the same as a missing parameter. But it does seem to work, so hey. DAVilla 03:55, 10 August 2007 (UTC)

There are topic labels/cats, POS or POS like labels and cats (e.g. idioms), and there are also regional ones, like {{Mexico}}, but be also have forms like {{Taiwanese Mandarin}}.

I think we should make these always display the country/region (without the language, it is in the language section anyway), and then categorize as (region) (language), with a default for the language. So for example:

{{Mexico|slang}}

will display as (Mexico) and categorize in Category:Mexican Spanish and Category:es:Slang. (I think the latter ought to be "Spanish slang", not a topic cat, but that is a separate issue.) See chela for this example. Note that the default language extends to the following labels, so you don't need a redundant "lang=es".

The US and UK cats really ought to be "US English" and "UK English", but whatever.

Then I can have an East Africa template, which I need. Probably default to English. Robert Ullmann 16:52, 9 August 2007 (UTC)

It would imho be contradictory to change the display of {{mexico}} from (Mexican Spanish) to (Mexico) and at the same time change the display of {{UK}} from (UK) to (UK English). Whichever format we choose, we should standardise {{UK}}/{{US}} ((UK)/(US)) with {{Australia}} ((Australian English)) etc, Thryduulf 17:44, 9 August 2007 (UTC)

I wasn't saying the display of {US} should change, I was saying the "cat", category might be changed to "US English", so that it would be consistent. (And {Mexico} always displayed "Mexico".) Then {Australia} displays "Australia" and categorizes (by default) in "Australian English", and so on. Good? Robert Ullmann 17:55, 9 August 2007 (UTC)

Yes. Thryduulf 18:34, 9 August 2007 (UTC)

I've moved {Australian English} (back) to {Australia}, defaulting to English, and {Belgian French} to {Belgium} defaulting to French, and checked those entries. (finching is Belgian English?).

Tell me on my talk page if you see any oddities, new or old. Robert Ullmann 15:05, 11 August 2007 (UTC)

There seems to be a problem with this. http://en.wiktionary.orghttps://en.wiktionary.org/w/index.php?title=wireless_forensics&diff=2836416&oldid=2836400 I had to make this edit, as the 'jocular' appeared as "(jocular)" incorrectly. (I have parenthesis turned off normally, so seeing them indicates a template problem of some sort.) Is the recommended fix, for now, to continue using {{context}} or are the specific templates waiting to be fixed all at once (or is this just something the new scheme doesn't address yet?) --Connel MacKenzie 02:43, 14 August 2007 (UTC)

(note that Connel is referring to "jargon", not "jocular") The syntax {{computing|jargon}} works if both {{computing}} and {{jargon}} use the "new" template syntax; if the latter doesn't, you get extra parenthesis. I converted most of the topic templates before the XML dump (so I would have a baseline), now need to sort the rest. For the moment, use {{context}} explicitly in this case. (The other effect is that later tags won't show at all, if you were to write {{computing|jargon|of an operating system}} you would still get (computing, (jargon)) at this moment.) Robert Ullmann 12:00, 14 August 2007 (UTC)

Note that {{jargon}} contains (''jargon'') at the moment ;-) ... fixed. Robert Ullmann 12:21, 14 August 2007 (UTC)

See report, based on the dump we just got. The regional language templates are the ones that need the most.

There is also an issue with the "transitivity" CSS tag. This doesn't (and didn't) work if the templates are combined with others. Anyone have an idea if people use this? Robert Ullmann 13:30, 15 August 2007 (UTC)

Are you talking about the fact that there are three or four templates using id="transitivity" and that this can result in a page that is not XHTML-valid? I noticed that when I was going through the unsubstituted uses of {{templates}}. Mike Dillon 15:30, 15 August 2007 (UTC)

I just did a quick search in the User: namespace for "transitivity": . It looks like there only one page that mentions this XHTML id: User:Connel MacKenzie/custom.js. There are two other mentions of #transitivity, but those are in numbered word lists. Mike Dillon 15:36, 15 August 2007 (UTC)

Connel's js code is called out by WT:PREFS, and it stores the selection in cookies in the user's browser, so there is no easy way to tell who might be using it. But it does cause display oddities at best, and warns about that. I'm thinking of dropping it: it applies to transitive, intransitive, ditransitive, and reflexive; and see if we have an issue. Robert Ullmann 23:18, 15 August 2007 (UTC)

The selection is stored in a cookie, but the CSS itself is written straight into the page with document.write. I don't see a problem with changing the templates to use class="transitivity" and changing the JavaScript to use .transitivity { ... }. It should be picked up immediately by anyone using the transitivity preference. Mike Dillon 15:06, 16 August 2007 (UTC)

I think it might be fixable in {{transitive}} under your sytem now that you know if there are no additional arguments (in which case it would span the parenthesis too) provided that in the other cases you could get the span to close after the comma. But who tries to hide this stuff anyways? Connel had recently suggested an abbreviation only for uncountable, so if that's good enough for everyone then this is a problem that doesn't have to be dealt with.

Is it possible to design your Wiktionary page (others too) to by default, place my cursor in the Search field? That is always where everyone wants to start. It is done on other pages I've used. Thanks,

Kieran Sweeney

Thank you. That was tried about a year ago, and met rather fierce resistance. The developers rolled that change back, pretty quickly. Being able to scroll down a page as soon as it appears is much more intuitive for a lot of us. To get to the search box, I use "Alt-F" myself. (I think the FF default is Alt-Shift-F, now.) --Connel MacKenzie 01:31, 8 August 2007 (UTC)

(The Economist newspaper used to have a 2 page section in each edition entitled "Schools Brief", which was a detailed technical explanation of some aspect of economic theory. They don't do that any more, which is one of the reasons I stopped subscribing.)

You've probably heard a few times that the template system is "not a programming language", probably from someone trying to discourage you from doing lots of tricky things. That isn't strictly true: it is a programming language, what it is not is a procedural programming language. It may look like it, especially with its syntactic sugar and conceits like the #if parser function, but it isn't.

Consider the language construction:

if condition then then-part else else-part

In a familiar procedural language (C, Python, almost anything you know), this means evaluate the condition, if it is "true" then evaluate/execute then-part, otherwise don't do that, evaluate/execute the else-part.

Templates do not work that way. In the template language, the parser evaluates the condition, the then-part, and the else-part, and then passes all three result strings to the #if function. If it considers the condition to be true, it returns the first result string, else returns the second. Regardless of the condition, both branches get executed.

So when you write:

{{#ifexist: Template:one | {{one}} }}

You think you are saying—procedurally—if {{one}} exists, then "call" it. But what this means is: "transclude template one, evaluate it, (in this case resulting in string 'Oneida'), then if it doesn't exist, discard the result string". (!)

So now let's turn our attention to {{context}} (I reproduce the current version here, minus some irrelevant syntax):

{{#if:{{{1|}}}|<span class="ib-brac">(</span>
{{context/checklabel|:|{{{1}}}|{{{lang}}}}}{{#if:{{{2|}}}|
{{context/checklabel|{{{1}}}|{{{2}}}|{{{lang}}}}}{{#if:{{{3|}}}|
{{context/checklabel|{{{2}}}|{{{3}}}|{{{lang}}}}}{{#if:{{{4|}}}|
{{context/checklabel|{{{3}}}|{{{4}}}|{{{lang}}}}}{{#if:{{{5|}}}|
{{context/checklabel|{{{4}}}|{{{5}}}|{{{lang}}}}}{{#if:{{{6|}}}|
{{context/checklabel|{{{5}}}|{{{6}}}|{{{lang}}}}}{{#if:{{{7|}}}|
{{context/checklabel|{{{6}}}|{{{7}}}|{{{lang}}}}}{{#if:{{{8|}}}|
{{context/checklabel|{{{7}}}|{{{8}}}|{{{lang}}}}}{{#if:{{{9|}}}|
{{context/checklabel|{{{8}}}|{{{9}}}|{{{lang}}}}}
}}}}}}}}}}}}}}}}<span class="ib-brac">)</span>|<span class="ib-content">no ] indicated</span>}}

Simple—right? If the first parameter exists, call context/checklabel, if you did that, and the second exists, call context/checklabel for that, and so on. But what this really means is always call context/checklabel nine times, and then use the #if conditions to sort out which of the results to keep. {{context/checklabel}} then calls the label template (three times!), context/modifier twice, and context/categorize twice. So before we have done anything, we've made seventy-two template calls. And those templates aren't trivial. If we put {{context|one}} on a page, it takes 72 template calls and ~700 parser function calls to render "(one)".

The {{context x}} template does a completely different kind of conditional, calling itself (once!) recursively for each tag. If we write {{context x|one}} the call tree looks like:

• context x
  • context 0
  • context 1
    • context 0

3 calls, two to a null function, ~30 lines of code/parser functions. This is two orders of magnitude better than the present context. If you write {{astronomy}} it looks like:

• astronomy
  • context x
    • context 0
    • context 1
      • context 0

(go look at {{context 0}} ;-) Again, 4 calls, two to null, ~37 lines.

In general, writing simple templates as if they were procedural seems to work fairly well. But understanding that all branches will get transcluded and evaluated will help in understanding why certain unexpected things occur, and understanding why templates should not invoke chains of conditionals with the mistaken expectation that it will reduce server load; it is likely to have the opposite effect. Robert Ullmann 15:35, 6 August 2007 (UTC)

• Talk like that will prevent us from ever seeing mandelbrots in wikitemplates. :-)

• More seriously, I think we may see actual policy someday, that specifies particular guidelines for all templates: if a less-recursive alternate is provided, it should be used even if some functionality is lost. For the first year or two of templates existing, the rule was that any template could be subst:'ed, and the plain-text was preferable. (The concept of "be nice to newcomers" is all but completely lost with the mandate to prefer template use.) The inflection templates were changed to accommodate the "box style" inflections, but I believe that was a mistake. The only purpose of the "box style" was to disrupt secondary formatting issues (e.g., break image placement, break {{wikipedia}} placement, break inflection-line qualifiers, etc.,) while at the same time making XML dumps harder to parse, making the rendered HTML harder to parse, adding needless layers of CSS, Javascript and WT:PREFS. The only benefit is that for some people, it sometimes "looks" better (which subjectively remains dubious,) albeit, inconsistently. Those concessions were made based on false evidence, that has not borne out in practice. The result is that things like {{en-noun}} remain absurdly complicated (and resistant to what should be trivial improvements...such as the possessives.)

• Back on topic, I wish to give my full Support to any activity directed at reducing the recursion that exists the the current family of templates we use, especially {{context}}. The only reason to proceed slowly is to based on respect for the emotions of very helpful contributors who greatly influenced the existing templates' evolution. But it is time to move forward, refactoring and simplifying them. I remain hopeful that we can do so without resorting to a VOTE. This is, after all, a technical, not functional, nor emotional, issue. --Connel MacKenzie 19:45, 6 August 2007 (UTC)

The hard part, and hard work over time, is figuring out what some bit of s/w should do. That often results in spaghetti. It is then comparatively easy to re-write it to do the same things much more simply. As you note, it is building on all the work that has gone before, not replacing it. Robert Ullmann 12:37, 7 August 2007 (UTC)

This is neither here nor there, but I don't think it's helpful to say that this conditional behavior is an artefact of non-procedural design, since procedural languages sometimes provide this kind of conditional (e.g., the VBs' Iif function), and non-procedural languages always provide the other kind (at least, if they support recursion — obviously recursion is a doomed effort if your recursive call is always evaluated regardless of your conditional branch — and all that I know of do). (This doesn't affect the bulk of your explanation, but it will be sad if people read your explanation and leave with a mistaken impression of what makes a language procedural or not.) —Ruakh_TALK 20:11, 6 August 2007 (UTC)

Yes, but I was trying not to be too obscure before I got to the explanation (;-) I could have said "non-recursive non-procedural language." One reason I didn't was that the template language is not recursive, but my example shows recursion... The language itself only provides a usable conditional when invoking a sub-template. Something like defining template:x as

{{{1}}} {{{#ifexpr: {{{1}}}>0 | {{x|{{#expr:{{{1}}}-1}} }}

clearly can't work, it results in an infinite recursion anyway. The parser simply won't transclude a template already in the call stack. The documentation explains how do to a recursive loop using redirects, which is bounded by the number of redirects even if you don't limit it with a proper conditional call. Robert Ullmann 12:23, 7 August 2007 (UTC)

I understand that all branches will be evaluated, and that the link table will update with these, but are you sure all templates are actually transcluded? That seems a quite a bit absurd! Is there any way to test this, to look for residual side-effects of transclusion? Try {{#ifeq:1|2|{{prove|Fermat's-last-theorem}}|Done!}} or something. DAVilla 15:21, 16 August 2007 (UTC)

Oh yes, they are all transcluded. Try syntax like you have in the sandbox, and look at what-links-here on the template. Or on something the template uses. Remember, the parser generates the fully expanded strings for each branch, and then passes the strings to #if, which returns one or the other. Robert Ullmann 16:29, 16 August 2007 (UTC)

Okay, I tried transcluding User:Davilla/transcluded conditionally from the sandbox. When the conditional is true, the sandbox appears in Special:Whatlinkshere/User:Davilla/transcluded and Special:Whatlinkshere/transcluded. When I change the conditional to false, the sandbox disappears from the second one. That means there's something funny going on with the way Whatlinkshere works. This isn't proof that both branches are fully evaluated because {{}} may be treated as a link, just as ]. Because the link to ] is not seen in one case, it would seem to suggest that template is never transcluded when that branch is false. But it's also possible that Whatlinkshere just never receives that information. Is there any real way to tell if both branch are followed, if a template is actually looked up? Even if they are, the results from one branch are thrown away, so it can only be judged by side-effects. What other side-effects could there be? DAVilla 00:19, 20 August 2007 (UTC)

Bring back COBOL, all is forgiven! SemperBlotto 15:37, 16 August 2007 (UTC)

May I put a two cents? I think I might need to point out w:Wikipedia:Don't worry about performance: "ou, as a user, do not have to worry about site performance. In the overwhelming majority of cases, there is nothing you can do to appreciably speed up or slow down the site's servers" (emphasis as original). Yes, I know projects are independent, but this really applies to all of them. There are however, other good reasons to make a switch like what is proposed here. In this case, the opacity of the original code. Code ugliness alone is not a reason to "break" what works for something that doesn't do more. Circeus 16:49, 16 August 2007 (UTC)

Thanks. But the driving consideration here is the fact that Special:Wantedpages is broken by the old template implementation. --Connel MacKenzie 16:53, 16 August 2007 (UTC) the {{nav}} discussion is similar...but both severely degrade Special:Wantedpages...to the point of not seeing any genuinely wanted pages at all. --Connel MacKenzie 16:55, 16 August 2007 (UTC)

I had no idea it was related. I've seen the issue discussed somewhere else, but this discussion is not as readily connected for a newcomer. My bad. Circeus 23:42, 19 August 2007 (UTC)

I've replaced the conditionals in the template with a form that will not add non-existent categories to the linktable. This means it will not swamp Special:Wantedpages. Robert Ullmann 14:07, 7 August 2007 (UTC)

So we should actually see something meaningful on Special:Wantedpages after the Wednesday/Thursday specialpages.php maintenance script runs? Fantastic. --Connel MacKenzie 15:03, 7 August 2007 (UTC)

I don't understand. From Connel's explanation above, I thought the linktable counted something like {{#ifexist:page-name|wikitext-if-exists|wikitext-otherwise}} as a link to page-name? If that's the case, then it seems like your change doesn't actually change anything, because {{navline}} is still testing for the existence of these categories? —Ruakh_TALK 16:02, 7 August 2007 (UTC)

#ifexist doesn't add something to the link table. It is the branch code that does. So

{{#ifexist: Category:foo | ] | foo }}

adds Category:foo to the linktable as a side-effect of evaluating the true branch, which is always done. What {{navline}} is doing now is preventing the parser from ever "seeing" that link. Yes, it would be much better if the additions to the linktable were done by scanning the result text. But they are done by the code parsing the 's. Robert Ullmann 16:14, 7 August 2007 (UTC)

Connel's explanation was only slightly off, the devs didn't change the code to start parsing both branches, that was of course always true. What they had changed was adding entries to the linktable as part of parsing the bracket syntax, rather than scanning the result text (or something similar); so now there is a side effect to evaluating the unused branch. In general, this may be a good thing; an #ifexists conditional is almost always going to use the thing tested for, so when it is created (or deleted) the page will be regenerated. Robert Ullmann 16:28, 7 August 2007 (UTC)

If I said that, then indeed, my explanation was off. What they started doing this year is populating the "wantedpages" table with both branches, so that the job queue can be filled with entries it needs to update whenever a template is later changed. --Connel MacKenzie 17:37, 7 August 2007 (UTC)

O.K., I think I understand now. Thanks for explaining. :-) —Ruakh_TALK 16:40, 7 August 2007 (UTC)

See meta:ParserFunctions#Code_execution Robert Ullmann 17:01, 7 August 2007 (UTC)

Okay. That did not work. All of the code I looked at and the documentation are consistent with the above, but apparently #ifexists goes out of its way to create a linktable entry? To me, that seems to defeat the entire purpose! Oh well. This was a stopgap anyway, we need to fix nav so it will scale with each topic. (which I described some ideas for somewhere ;-). We did clear some of the cruft from the language template out. Making some progess ... Robert Ullmann 00:58, 8 August 2007 (UTC)

Something worked. Who changed what, where? --Connel MacKenzie 16:59, 16 August 2007 (UTC)

See the section below, about nav again. I restricted it to the base (English) cats. So now there is only one reference to the "missing" categories. And it is still there, and still can be used as intended. Robert Ullmann 17:04, 16 August 2007 (UTC)

I seem to remember that the {{blend}} template used to have an additional argument that specified where in the ordering of the portmanteaus category an entry would appear. Specifically, this could be used so that words beginning with a capital letter could be listed alongside those with a lower-case initial, by giving the word with a lower-case initial as the extra parameter. For example, "Bakerloo" currently appears under "B" in Category:Portmanteaus, whereas it should really be under "b". There are around a dozen such misplaced words.

Could this be fixed? Or is it no longer something we do? — Paul G 14:17, 7 August 2007 (UTC)

Done. --Connel MacKenzie 17:17, 7 August 2007 (UTC)

It was my understanding that the {{t}} template was to be preferred these days, as the result of the previous vote. Continuing to fork different style templates for translations, seems like a really bad idea at this point.

My attention was drawn to Template talk:t#Transliteration parameter, after noticing a few oddities like {{he-translation}}. I think some parameter for "romanization" is essential; does anyone have a variable-name preference?

--Connel MacKenzie 01:16, 8 August 2007 (UTC)

“r” and “R” seem reasonable. Is there something we can do to wrap non-Roman script output in “<span lang="..." xml:lang="...">...</span>” so the right fonts are used? Rod (A. Smith) 01:30, 8 August 2007 (UTC)

If we add that, we should consider how to integrate stuff like {{HEchar}} (different fonts and font sizes) too. The absence of these three features has probably hindered {{t}}'s adoption significantly. I don't think that was apparent during earlier discussions, when {{t}} was still abstract. --Connel MacKenzie 21:23, 8 August 2007 (UTC)

Yes, it's a problem of getting certain non-Roman scripts to display correctly. Ancient Greek and Hebrew are two of the difficult languages. I don't know whether {{t}} currently supports Cyrillic, Arabic, or Persian either. Each of these has a special display template currently to get the fonts to display. --EncycloPetey 21:32, 8 August 2007 (UTC)

At the risk of flooding wantedpages even further — if we come up with a specific trans-language naming scheme for these *char templates, then {{t}} can test for the existence of the template and use it if it exists. —Ruakh_TALK 22:12, 8 August 2007 (UTC)

Like {{t-char-he}} or something? Can you demonstrate what you think is needed? --Connel MacKenzie 05:46, 9 August 2007 (UTC)

Most script template in Category:Script templates have names of the form XX+“char”, where XX is a capitalized ISO 639-2 language code, but I don't think that is a good long-term solution. Better is probably to use the script's ISO 15924 code with some affix. Rod (A. Smith) 06:14, 9 August 2007 (UTC)

The transition wasn't as painless as it had appeared. There isn't a separate code for Nasta`līq script, which from my limited Wikipedic understanding would be preferable for Persian (fa), Pashto (ps) and Urdu (ur). There are also a couple of templates in use that have more than one script applicable, namely Kurdish and Sindi, which might need to be substituted on a case-by-case basis.

Is there any good reason to add a lang parameter to the script templates, per {{lang}}? DAVilla 09:25, 9 August 2007 (UTC)

{{t}} already has an sc parameter for this purpose, indicating the script template to use. It might be good to semi-automate that in some way, but apart from a Mediawiki extension you aren't going to get around specifying it in at least some cases, since some languages can be written in more than one script. DAVilla 06:05, 9 August 2007 (UTC)

Everyone keep in mind that script is not equal to language. So any magic based on the language isn't useful. The {t} template does have an sc parameter as noted. It needs a transliteration parameter IF we want to use the gender and number parameters, they were just added to make life simpler in some cases. Robert Ullmann 09:50, 9 August 2007 (UTC)

Note that DAVilla has completely renamed the script templates without discussion or notice (other than implied above), and the result is IMHO terrible, the names are way too long. (He also "fixed" the gender templates in a new way, that has to be undone, and Connel yelled at him.) Robert Ullmann 09:50, 9 August 2007 (UTC) (You could have moved {mpl} to {m-pl} and {mf} to {m-f} and not committed the {m.pl.} nonsense. If you'd asked what should be done you might have gotten suggestions.)

Excuse me, for the minor interruption, but I was not yelling. --Connel MacKenzie 18:47, 9 August 2007 (UTC)

DAVilla, the problem is that you immediately jump in and start messing about with templates. I'd suggest you wait at list a few days when you get some bright new idea; then we don't have to go clean it up at great length. I always wait at least a week, and sometimes months. If is is a good idea, it will still be a good idea.

In this particular case, if you had waited a few more hours, you might have gotten a bit more input. (see next)

It's far from "nonsense", but this is off-topic and I'm not going to try to defend the full stops here. Anyways there was the solicitation of discussion, though very little feedback. ArielGlenn had suggested {{-mpl-}} and got no comments. When the issue resurfaced, it was better to just finally do something about it. DAVilla 11:01, 9 August 2007 (UTC)

Please link where you solicited comments on their naming. This, AFAIK, is the first I have heard of it. The template names are quite fixed, with at least three different types of automation relying on m, f, s, n and p as the template names. --Connel MacKenzie 18:47, 9 August 2007 (UTC)

This very page, above, and I can't find when it cropped up again, late June or early July. For the record I never intended to replace the single-letter no-period variants, only duplicate them, with redirects, to allow a period, per {{m.pl}} {{m.pl.}} and {{mpl.}}. DAVilla 03:22, 10 August 2007 (UTC)

On the script codes: ISO 15924 defines codes that are always 4 letters, and have the first letter capitalized. This was intentional, so they would work well with ISO 639-4, which will have 4 letter language codes. So applications like the wikt won't have code collisions if they preserve capitalization. We could do exactly what it provides for, and use the codes as the template names. This is what I would suggest. (see w:List of ISO 15924 codes) Robert Ullmann 10:03, 9 August 2007 (UTC)

Is there an echo in the room? ;-) Rod (A. Smith) 16:12, 9 August 2007 (UTC)

The idea was to completely avoid collision, which is an annoying problem with language templates. As standardized with script appended, the full name of the template doesn't have to be passed with the parameter, only the four-letter code, or even the possibility of a two-letter code if there's only one script for the language. I was thinking that the transition can be eased by adding redirects such as Template:ARchar script. But I'll wait to revise until we're certain of which path to take. Besides this issue, other stumbling blocks were encountered as noted above. DAVilla 10:34, 9 August 2007 (UTC)

By far the most common use of the script templates is directly, not inside other templates. People do not want to go around writing {Arab script|...} instead of {ARchar|...}. {Arab|...} is reasonable. As pointed out, they are designed not to cause name conflicts. Robert Ullmann 16:24, 9 August 2007 (UTC)

I do not understand why those template names are not given a meaningful prefix. Hippietrail's long-standing complaint is that our template naming conventions are too lax. I completely agree. These need to have a meaningful prefix. Note: not an infix, nor suffix. The first-character-capitalized is not a good compromise, IMHO. That invites the confusion of Wikipedia-naming conventions by example. --Connel MacKenzie 18:47, 9 August 2007 (UTC)

• Note: weird edit conflicts today. (Restored the removed comment that I noticed, now.) --Connel MacKenzie 18:52, 9 August 2007 (UTC)

Then how about using lower camel case, like scGrek, scArab and scJpan? Prefixed but still not longer than currently used ones. I suppose this convention might be applicable to broad classes of templates. ―Tohru 22:50, 9 August 2007 (UTC)

That's better than nothing. But these are only being entered once, thereafter being put into the {{t}} uses only indirectly (by language code)? Or no, only into {{t}} itself, right? My point is that, the length of the prefix doesn't need to be short, as humans generally won't be typing these in. On the other hand, if Special:Prefixindex/Template:sc is currently empty, that should be OK. --Connel MacKenzie 23:35, 9 August 2007 (UTC)

• <grumble> Months of practicing using blown away in one day of slow WMF servers + numerous edit conflicts. </grumble>

OK, so "sc" doesn't work. How about "iso15924-" as a prefix for the template names, then? --Connel MacKenzie 23:39, 9 August 2007 (UTC)

What about "script" - this Special:Prefixindex/Template:script is empty and it is easier for humans to remember than a string of numbers. Thryduulf 00:08, 10 August 2007 (UTC)

That makes more sense, too.  :-)   Since it isn't following that ISO standard for any particular reason, but is being used to customize scripts/fonts, that does make a lot more sense. I think Hippietrail would insist that it is a sub-function of {{t}}, therefore should be something like "t-script-Xxxx", or "t-custom fonts for Xxxx", or "t-customFontsFor-Xxxx", but alas, he's traveling again. I have no objections to "script " as the prefix. --Connel MacKenzie 00:25, 10 August 2007 (UTC)

Please don't regard those script templates, which are providing a fundamental function, as accessories of {{t}}. Not only they are being used in many other templates that need to handle non-Roman scripts, but also some people, including I, will type them on plain wiki-text to specify fonts to be used, indirectly via the lang= parameter of html tags. ―Tohru 08:02, 10 August 2007 (UTC)

What is the convention for subfunctions? We have namespaces delineated by colons, in certain spaces (not Templates for some reason) subpages delineated by slashes, the unused ability to disambiguate with parentheses, and all of those built into the MediaWiki syntax. Where does this hyphen come from? DAVilla 02:56, 10 August 2007 (UTC)

Shouldn't we think that the hyphen is already reserved for inflexion templates or templates that use language prefixes? It would be the worst option among possible ones. ―Tohru 08:26, 10 August 2007 (UTC)

I view the hyphen as the delimiter of choice for templates. The colon is overused as a delimiter in MediaWiki, pipe is taken, number-sign is taken, percent is taken (URI encoding), period is taken MW URI encoding,) commas don't work, apostrophes don't work, parenthesis, square brackets and squigle brackets are taken; ampersand, dollar sign, equal and asterix are taken. Plus is inconsistently converted to space. That leaves backslash, forward slash, circumflex and hyphen. Of those last four, only one won't completely confound XML dump parsing. So: spaces, hyphens and , , . Anything else in a title in the template namespace should be speedy-deleted on sight, blocking the offender. (w:WP:BEANS. /me sets timer for an hour, for some vandal reading this, to decide to enter the very first diacritic title in the template namespace.) --Connel MacKenzie 09:17, 10 August 2007 (UTC)

Well, actually, I've now noticed many cases (which my software discards.) Currently there are templates with "+/():!,'&;~." Great. Obviously, this is nothing I will fix any time soon. --Connel MacKenzie 09:25, 10 August 2007 (UTC)

Robert is arguing above that it should be short. In fact he would prefer only the four characters. Although I have to side with Connel on downplaying the significance of capitalization for Wikimedia, and despite having pushed through alternative changes, I will add to Robert's case that scripts are not invented overnight, so we're not really reserving all four-letter combinations anyhow. We're putting in place less than 120 of these, few of which have much meaning (Moon being a counter-example), and potentially a few others over then next century or two. DAVilla 02:56, 10 August 2007 (UTC)

Prefixing isn't a bad idea, although appended words have already taken a foothold in the form-of templates, and the etymology templates are distinguished by a final period. The conflict we're trying to avoid isn't prefix namespace though, it's prefix separator namespace. Any two- and three- letter codes are reserved for templates specific to a language, but if we really wanted it there's no conflict in using s- to mean "script". DAVilla 02:56, 10 August 2007 (UTC)

Good. The prefix "s-" is fine with me, and seems likely to accommodate Tohru's expectation that these will be used outside of {{t}}. Egads, will they? --Connel MacKenzie 08:57, 10 August 2007 (UTC)

Connel, script templates are used all over the place. Look at any random Arabic entry, a lot of etymologies, not to mention a lot of templates other than {t}. I'd very strongly prefer we don't prefix them. people write them all the time working with those languages. (If it was almost always inside templates that would be different.) The s- would be a continual annoyance. Robert Ullmann 12:38, 10 August 2007 (UTC)

But not having a prefix creates a larger headache of people adding categories to templates to sift through them. --Connel MacKenzie 16:46, 10 August 2007 (UTC)

You only have to do that once. Once it's categorized, then you know what it is. Label templates, for instance, are not prefixed with l-, and there are a hundred times as many of those. These and the language templates, they're all already categorized, so why is there any problem iterating through them? DAVilla 01:15, 12 August 2007 (UTC)

This got way off topic ... ;-) Transliteration parameter could be r, shouldn't be t (;-), I added tr=. Robert Ullmann 12:38, 10 August 2007 (UTC)

Turkish? --Connel MacKenzie 16:46, 10 August 2007 (UTC)

As I just suggested at Template talk:form of#Use with non-roman scripts, {{form of}} and many of its derivatives should probably have the same script and transliteration parameters. Rod (A. Smith) 19:36, 17 August 2007 (UTC)

While looking for interwikis on google, I found the klingon version of substantief. However the .tlh interwiki link doesn't get put in the box on the side with the other wikis. Is Klingon not supposed to be cross-linked? Nadando 02:55, 9 August 2007 (UTC)

The home page of that version of Wiktionary has this message:

This wiki is going to close so the data was been transferred to wikia.

That probably means it won't be cross-linked. Mike Dillon 03:07, 9 August 2007 (UTC)

Okay, observations: this creates lots of unwanted entries in Wantedpages. More importantly, it does not scale to thousands of languages. Also, the topic hierarchy is represented in every topic cat, so making a change involves all of the language/topic cats below that point.

So: please look at {{new topcat}}

The idea is to have a template for each topic, that provides the heading for that topic in all languages. See {{topcat Nature}} for an example. It can then list all of the languages that have categories (with {{nav+}}) and languages that may presently (with {{nav-}}). We can turn off the references to the ones that do not exist.

See Category:fi:Nature for an example of use of {{topcat Nature}}.

A language can then be added to all of the others in the topic at any point. The structure can be changed by altering the topcat * templates, not all of the individual cats. Additional text explaining the topic can be added to all of the cats for the topic.

The nav+/nav- switches are a natural target for 'bot action if anyone is inclined.

They won't show up in Wantedpages except when needed. Comment? Robert Ullmann 21:26, 10 August 2007 (UTC)

Sorry for saying so, but it looks really ugly, with the columns so unbalanced like that. Unfortunately, I don't know of a way to retain {{nav-}}'s flexibility and keep the columns balanced; I think we might need to stick to just {{nav+}}, and let other categories be added as they're actually created. —Ruakh_TALK 23:05, 10 August 2007 (UTC)

It isn't that pretty is it? I didn't change all of the ones to nav- that should be. I am assuming that if the the +/- is adjusted by bot, it is capable of counting +'s, not just lines, and balancing columns. The nav- lines are helpful if you are adding a new topic and don't want to endlessly rekey codes and languages as they are added. Robert Ullmann 23:13, 10 August 2007 (UTC)

I had thought that just by random whatever they would end up roughly equal, but in this cat almost the entire last two columns are populated? (;-). Anyway, we'll see. Robert Ullmann 23:24, 10 August 2007 (UTC)

Not so random, a bunch of the cats in the last two columns are empty. Like someone tried to fill them in? Robert Ullmann 23:35, 10 August 2007 (UTC)

I think it is worth asking anew, what is the purpose of {{nav}}. I know I spent quite a bit of time getting it to work, prior to the WikiMedia "linktable" software change that re-broke Special:Whatlinkshere. Ptcamn was very insistent that the redlink languages appear somehow (if not redlinked, then at least black text.) That much, at least, seemed a workable compromise (prior to the MW software change.) But once a template of the "topcat" style is created, it seems likely to stagnate, no longer accepting new languages from {{nav}}, while only responding to direct topical language additions at the whim of a yet-to-be-written bot.

I'm afraid this raises more questions than it answers. What should the bot do? What about categories that don't exist (redlink) but that have category members? What about categories that do exist (bluelink) that have no members? Would the bot be creating the former, and {{delete}}-tagging the latter?

Hey, that sounds like a great idea. Membership, not existence, is what's important. But better wait until an empty blue category is actually deleted to remove it form the list. DAVilla 12:13, 11 August 2007 (UTC)

Is there a specific reason the redlinks are removed, instead of being subst-black-texted? (Sorry: I know that isn't a word, but for this discussion, I think my meaning is clear. In general, that seems OK, here in the grease pit.) Would the bot be able to update the "topcat"s at the same time, or should it wait for another month, for the next XML dump? Will other templates have similar concerns that the bot should be ready to address (something like the way Wernabot used "Whatlinkshere" to determine which pages to work on?)

I agree with Ruakh that the unbalanced columns, looks really ugly.

More salient still, is the question "what is 'nav' for?" Is it just to show off how poor the category structure is, for topical indexes? Is it to encourage rampant translation entries from secondary sources (or machine translations) by people who don't speak those languages? (Native speakers will work on their own language's topics, with little or no interest in 7,000+ other languages.) What exactly are we trying to encourage, by having this/these? Honestly, I am trying not to sound overly-critical; but I just don't see its purpose.

--Connel MacKenzie 00:22, 11 August 2007 (UTC)

I also have been confused about the purpose of {{nav}}. In English Wiktionary, all translation happens through English. The corresponding English category always appears as a parent of each non-English category. To me, it doesn't seem terribly inconvenient to have readers click through English (both in categories and in entries themselves) to get from one non-English language to the next. Rod (A. Smith) 01:20, 11 August 2007 (UTC)

I agree. If I regularly want to translate between two non-English languages, say French and Welsh, the French Wiktionnaire and/or Welsh Wiciadur would be my first port of call. If the word didn't exist on either of them, then I'd look at English (and possibly add it to one or both non-English wiktionaries, assuming I knew enough of the language). Thryduulf 01:46, 11 August 2007 (UTC)

Would someone more diplomatic than myself mention this on User talk:Ptcamn's page please? --Connel MacKenzie 04:57, 11 August 2007 (UTC)

Done. Rod (A. Smith) 07:03, 11 August 2007 (UTC)

Thank you. Is he active on Wikipedia these days? --Connel MacKenzie 18:12, 11 August 2007 (UTC)

We don't need category navigation from every language to every other? I could have sworn I made that point a year ago.

Anyways, yeah, just put the +/- information in one place, in the bottom-level category (i.e. English, as it stands) if that's the only place it's needed. DAVilla 12:13, 11 August 2007 (UTC)

A bot would probably run once after each XML dump, make a list of all the xx:topic cats that exist, and then for each "topcat", update the +/- switches, add languages that are missing, sort and rewrite the columns balanced.

But Connel et al are correct, we should be questioning the utility of the table. Even though some automation would be fairly easy, it is pointless if the tables are not useful. Luba-Katanga? We have no words in that language, not even for the name. And code "lu" is Tshiluba aka Luba-Kasai, Luba-Kantanga isn't coded until 639-3, "lub". (these are languages of the Congo) So what is the point?

The rest of the nav template is useful, it also does the categories for the instant cat; and even without the table, something like the "topcat"s may be useful to add text to all the categories for a topic,and make it easier to change the structure.

Re leaving the black non-links: nav- could certainly do that (I've changed it, if you care to look again, but then it just looks like it did before ;-) Robert Ullmann 14:21, 11 August 2007 (UTC)

What do people think of removing the table from {{nav}} for the present, while we sort this? Then we can see what Wantedpages would look like, and we can always put it back in a moment (undo the edit ;-). The best thing would be to put back something we want and can maintain. Robert Ullmann 14:30, 11 August 2007 (UTC)

Maybe. It might be construed as too hasty. I've made a whitespace edit so that the "Wrong Version" doesn't get rolled back, after you make that change and it gets rolled back. --Connel MacKenzie 18:24, 11 August 2007 (UTC)

Connel's comments above have convinced me that the {{nav}} tables aren't worth keeping — either for the present, or period — but I think their removal should be discussed at Wiktionary:Beer parlour first, as it's much more than a technical change. —Ruakh_TALK 19:46, 11 August 2007 (UTC)

Comments above by Rod and Thryduulf lead to the solution: have the tables appear only on the English cats; users don't need so much to navigate from one FL to another. The other languages can provide a reference to the English cat. Then the table occurs once per topic, and there isn't any special load on Wantedpages or whatever. I changed nav to do this; see Category:Animals. (There are a number of topics missing the {nav} template.) Robert Ullmann 20:10, 12 August 2007 (UTC)

Is there a template with the same functionality as {{trans-top}} and {{rel-top}} for derived terms? If so can someone add it to -less where there are 5 long columns of derived terms. Thanks. Thryduulf 12:53, 11 August 2007 (UTC)

{{rel-top}} is intended for use in other sections such as Derived terms where appropriate; it just defaults to "Related terms" in the box header. In this case, you would want {{rel-top4}}. Robert Ullmann 13:17, 11 August 2007 (UTC)

Thanks for that. It does look odd with three different column widths, but I guess that can't be helped? Thryduulf 16:40, 11 August 2007 (UTC)

Oh, you did say five columns; apparently you figured it out ... Robert Ullmann 16:58, 11 August 2007 (UTC)

I don't see why this can't be {{top}} etc. for translations and {{top2}}, {{top3}}, etc. for everything else, just like the old naming convention. Or do we not want to convert all of the old boxes, and still use that style in various places? DAVilla 15:26, 16 August 2007 (UTC)

Because top is Papantla Totonac, and mid is Mandaic? You of all people are asking? ;-) ;-) Yes, there are many places where there are a few (say) related terms, using top2, but collapsing a box would be obnoxious; better when there are a lot? Robert Ullmann 16:24, 16 August 2007 (UTC)

Oh, duh! /self slaps forehead

So {{top2}} etc. and {{mid2}} etc. are here to stay. That's fine except that it doesn't give any information about which section it's in. Ideally we'd want certain attributes of the boxes to pertain to preferences on a per-section basis. If this can ultimately be done more easily with extensions, as I've seen on the test site, then these templates are the way to go. If we don't want to rely on extensions, then we should be consistent in indicating the section.

Did we ever discuss the naming of {{trans-top}}? Looking at the archives there was plenty of opportunity before, during, and after the vote to bring up objections, but I didn't see any. My vote: {{a to i}} and {{j to z}}. Or not. Still, we have a small problem now that {{rel-top}} is in the lang=rel reserved range. Maybe we should be using a space instead of a hyphen?

Alternatively, if the section doesn't need to be distinguished, maybe we should overload {{top2}} so that it acts like a collapsible box if there's a parameter and otherwise not. (I've also seen a need for {{top1}} with See: another page.) More generally, couldn't we call this {{table}} or {{columns}} or something, passing the number? Hadn't you or someone else said that overloading {{bottom}} was possible? Can you write a generic "mid", possibly at {{break}}? DAVilla 14:05, 18 August 2007 (UTC)

Don't know how to write a generic mid, as the way we do it sets the width and colour for the column. However if the columns are all set by the -top template, so there are two rows instead of one, this can be done; whether it can be done with a zero-height first row in wikitable syntax I do not know. A generic bottom is easy iff we always have the top templates open (i.e. leave open) two div tags whether needed or not. With a bit of careful re-writing, that would have to affect all of the top/mid/bottom templates, we could get there. It would take a sub-template or several for the "top"s. (Can't wrap the table syntax in a conditional easily.) As to the "trans-top" name, I just invented it for the demo on GP at the start, and no-one I recall ever objected to the name. Robert Ullmann 17:10, 19 August 2007 (UTC)

I checked and there was sufficient time to make objections, but none were made. I don't have any reservations except that rel- is reserved, although that can easily be changed by using a space instead of a hyphen. I'd just wanted to step back a little and see what direction we should take this.

I guess it wasn't you who had mentioned that a single "mid" might be possible with the css. Regardless, it hasn't been demonstrated. I do think a universal {{bottom}} would be a good idea. The main question right now is if we want to have the section indicated in the template call. If so, the reasons for doing so should support it universally, even for tables that don't collapse. If not, some simplification is in order. DAVilla 23:36, 19 August 2007 (UTC)

Has anyone ever noticed the broken behavior of subcategory tree expansion in the non-English subcategories of Category:*Topics? I was looking at Category:Latin language and tried to expand Category:la:Fruits and the list in the subtree ended up being the children of Category:Fruits, not Category:la:Fruits. I made an attempt to track down the bug in the CategoryTree extension and submitted bugzilla:10883, but I was just wondering if anyone else has noticed it previously. Mike Dillon 16:47, 11 August 2007 (UTC)

Neat bug-find. Thank you for correctly filing a bugzilla on it. --Connel MacKenzie 18:05, 11 August 2007 (UTC)

Indeed. What is amusing is the clicking on (say) fr:Fruits, then under that ru:Fruits ... I didn't see how far it would go ;-) Robert Ullmann 23:28, 11 August 2007 (UTC)

This issue has been addressed and the fix is now live. I think the fix is a little odd since it seems weird to me that Title::newFromText('la:Foods', NS_CATEGORY) would ever be interpreted as "la:Category:Foods", but the end result works for the way that CategoryTree actually calls the function. Mike Dillon 14:42, 25 August 2007 (UTC)

Note: see also WT:BP#Rumors

Allegedly at WikiMania2007, Brion said that SUL (AKA CentralAuth) would be turned on this week. (Note that for three years now, the promise of "in the next two weeks" has finally diminished to only one week...so it could be turned on for real, some time this year!) You can experiment with it at http://test.wikipedia.orghttps://dictious.com/en/Special:MergeAccount if you've set up an account on test. If not, set one up, and play. --Connel MacKenzie 18:10, 11 August 2007 (UTC)

Partly, maybe, but I'd think for the most part no. They have to resolve all the username conflicts first, before it can be fully functional.

Come to think of it, I'm not entirely sure if I want any of my records on Wikipedia to be matched here, so they're just gonna have to do a forceful renaming for that.

Can you explain what you mean here? --Brion 17:02, 15 August 2007 (UTC)

I'm only speculating that it will come in phases, which I haven't read about by the way. If there is a name conflict on two projects, would the name be reserved to either individual on a third project? Would that reservation fluctuate as either user defeats the other in number of edits? At some point you will be able to merge all of the login info, but not until the conflicts are resolved. That's all I meant. DAVilla 21:47, 15 August 2007 (UTC)

Do we finally have first letter lower-case usernames available? Can someone make a stink about that before anything goes online? After all, it may be helpful for resolving conflicts, no? DAVilla 00:59, 12 August 2007 (UTC)

"Resolve conflicts"? That would make it much worse. You'd never know if you were talking to the right person.

Um, thanks for taking up the cause. I meant in a technical sense, not in an I-don't-know-the-difference-between-capital-I-and-lowercase-L sense. DAVilla 09:38, 12 August 2007 (UTC)

Perhaps in the sense of setting your username to display with initial-lowercase, but never to allow separate "foo" and "Foo" names to exist simultaneously. There'll be no rush on it, though. --Brion 17:02, 15 August 2007 (UTC)

Why not? You already allow McDonald versus Mcdonald (versus MacDonald), JAY versus Jay, and even ∂ανίΠα for Christ's sake! The problem with impersonators is most severe only when the glyphs appear identically. Otherwise, capitalization is no worse than double-letter etc.

The relevancy of this is that, in some cases, if two users have the same name on different projects where both wish to cling to it, giving one user the lower-case version would be an easy compromise if it were available. DAVilla 21:39, 15 August 2007 (UTC)

User pages are already diambiguated à la articles on Wikipedia - see w:WP:UN. The problem of glyphs appearing (almost) identical is also recognised on Wikipedia - see w:Template:Doppleganger and w:Category:Wikipedia doppelganger accounts. Thryduulf 23:24, 15 August 2007 (UTC)

The relevant question is, would macy really be considered a doppelganger account of Macy?

An account is either an doppleganger account or it isn't. If User:Macy created User:macy to prevent anyone else registering it (to avoid confusion or to prevent impersonation) then it is a doppleganger account. If someone else registered User:macy then it is not a doppleganger account, depending on their intentions it is either a legitimate account, an imposter account (or possibly even a sockpuppet). In the former case both users would just need to make it clear on their user pages they are not the same; in the latter two cases user:macy will be blocked as would any other imposter or sock. Thryduulf 09:08, 16 August 2007 (UTC)

Oh, I got the terminology mixed up, which you've clarified for me. Blame my poor German-speak. My point in soliciting for this development, besides the timing, was that the lower-case would not necessarily be an imposter account. Connel and Brion seem to disagree, thinking that the two would be too easy to confuse. DAVilla 15:35, 16 August 2007 (UTC)

You don't think they'd be easy for someone to confuse?

There is "impersonator" code that is used during account creation at the server-layer to determine if an account is an impostor of an existing account. (Remember Vildricianus'?) Turning off the first character upper-case-only feature would confound that miserably. Who knows, what else, though. The mechanism for renaming accounts exists so that conflicts can be mitigated...doing things to encourage more ambiguous usernames seems highly inadvisable, particularly when no one has reviewed the code with that loophole in mind. --Connel MacKenzie 22:11, 16 August 2007 (UTC)

I think a lot of things are easy to confuse, but this isn't at the top of that list. It's already permissible to register Conel MacKenzie, Connel Mackenzie, Connel McKenzie, ConneI MacKenzie, etc. To me, connel MacKenzie would stand out among those. Maybe not to you, but to me, because I don't know how to spell your name by heart, but I do know it's a combination of two proper nouns.

People look most intensely at the beginning and endings of words. Someone who's idiotic enough, like me at one time, might even think you were a colonel in the military.

Another example: His real username is User:Thryduulf. Out of Thrydulf, ThryduuIf, thryduulf, and Thruudylf, which stands out most to you?

Another example: His real username is User:Brion VIBBER. Out of Brion VlBBER, brion VIBBER, Brion VIBER, and Brion VIBBER, which stands out most to you? DAVilla 02:19, 19 August 2007 (UTC)

Wait, why am I asking this of you, of all people? I know you. You've already made up your mind, and it's going to be impossible for you to take a fresh look at it. And you aren't even a developer, so what's the use? DAVilla 02:27, 19 August 2007 (UTC)

If I were to suggest further changes to username policy, it would be to remove the grandfathering of punctuated usernames, a switch to total case-insensitivity (not just first character) and a reduction to characters of a particular language Wiktionary's alphabet (i.e. A-Z on en.wiktionary.) Going the wrong direction, I agree, is pointless. --Connel MacKenzie 16:50, 19 August 2007 (UTC)

Have you tried creating any of those impersonator accounts? When you try to create them, you will be prevented at the server level. WARNING: Doing so could also get you inadvertently blocked, by someone not reading this conversation! --Connel MacKenzie 16:50, 19 August 2007 (UTC)

Well, I was able to create User:Robert Ulman (sent him the password; God I hope I'm not blocked for that) so it's not going to be possible to prevent imposters in every case. Still, the username screening is pretty harsh, so Brion's point about allowing either case but not both makes a lot more sense. On the other hand, there might be enough difference between e.g. DaVilla and davila to pass if lower-case is allowed, but not if it were not. DAVilla 08:12, 20 August 2007 (UTC)

The raw signature option can be used to add a further layer of opacity - for example user:thryduulf could set their signature to read and link to user:Thryduulf, but then the same is true of user:ThryduuIf. This doesn't affect the page history, recent changes, etc. but browsing through a discussion page like this it would not be immediately obvious. If the comment were majorly out of character (e.g. if "I" launched into a diatribe about administrator abuse, or "Connel" proclaimed his undying love for "usuress") then I hope others would think to check it was really them. However if the imposter were more subtle then it might not be so obvious. Thryduulf 09:18, 19 August 2007 (UTC)

The first phase is for a subset of test users to Opt-in. The next phase simply expands the control group. The last phase is to simply expand the opt-in feature for all public accounts. The only time accounts have to be renamed is when a more avid user has a particular username (that exists on a given wiki) where such an account already exists. The user with more contributions "wins" while the other has to be renamed. Running the test (above) will identify if you have any such conflicts. --Connel MacKenzie 02:28, 12 August 2007 (UTC)

Note: WT:VOTE#Extension DidYouMean has been started to address this. --Connel MacKenzie 16:28, 31 August 2007 (UTC)

Is it possible and desirable to task a bot to keep the topline {{see}}s synchronised. For example, z links to Z,ʒ,Ζ and ℤ, so all of these pages should link to each other and to z. If someone adds Ž to the {{see}} on one of these pages (not that I'm suggesting they should), then the other pages should also have this added to the see also. This is a surprisingly time-consuming task that seems to me (as very much a non-programmer) that it should be a fairly simple task to code a bot to do. I suspect it would just need to sit watching recent changes for any change to or addition of a {{see}} on the first line of the page. Thryduulf 23:09, 11 August 2007 (UTC)

We could vote in Hippietrail's DidYouMean extension. --Connel MacKenzie 02:18, 12 August 2007 (UTC)

That seems like something pretty similar to what I was suggesting. Would it pick up ʒ and ℤ from z automatically though? If not could this be manually set? Thryduulf 08:10, 12 August 2007 (UTC)

It picks up any manual "see"s that are present, and supplements them as others entries are added. What examples would you like exported from here, imported on http://wiktionarydev.leuksman.com/, to test with? It has been a long time since any glitches have been observed (and those were fixed quite rapidly.) Anyhow, what are those example characters, anyway? --Connel MacKenzie 01:49, 14 August 2007 (UTC)

From their articles, z is the last letter of the lowercase English alphabet; Z is the uppercase version (I suspect you know this already though ;)), ʒ is "A symbol of the IPA, representing a w:voiced postalveolar fricative.", Ζ is "The upper case letter zeta, the sixth letter of the modern Greek alphabet." and ℤ is a mathematical symbol for a set of integers. Thryduulf 16:52, 15 August 2007 (UTC)

A non-bot solution would be to have a template for each such set, named something like template:see-z after the canonical member of the set. -- Visviva 02:23, 12 August 2007 (UTC)

That, sorry, is a horrible approach. --Connel MacKenzie 01:49, 14 August 2007 (UTC)

I like this idea - very simple to implement. We'd have to decide which is the canonical member of the set though. I would suggest that this be one in lowercase latin script with no (accented characters - e.g dan would be the the canonical member of the set also including Dan, Dan., dān, dán, Dán, dǎn, dàn and dân. Where no such word exists, then we'd use the one closest to it. Thryduulf 08:10, 12 August 2007 (UTC)

Great idea, though see- is reserved so we'd need a different name. It wouldn't quite work for bass / bas / baas, since it would end up listing bass at the top of the entry for baas and vice versa. See the changes I've made to that page for a modified proposal. Edit: WikiMedia sucks. This will require some thought. Also note that {{see}} would have to skip over the pagename itself. DAVilla 09:48, 12 August 2007 (UTC)

I presume you are referring to template:see/bas, if so I'm not entirely sure what your proposal is as that page produces the same as {{see|bas-}}?

As for skipping the pagename, yes that will have to happen. Possibly an IF {{{1}}} = {{PAGENAME}} THEN skip ELSE {{{1}}}. sort of statement. I don't know if this is possible in template coding or not? Thryduulf 10:09, 12 August 2007 (UTC)

I've been trying this out and it's a real bitch. For instance, how do you determine if there's a comma after the first element of the list? If the first element of the list is the page name, then it isn't even listed, so there can't be a comma. Otherwise there's a comma only if there's another element to list, which means that the second element exists and either it's not the page name or there's at least a third element. Then consider that after the comma is an and if that next element is the last one, which means that just to determine this first case we're already checking up through the fourth elements of the list.

If I could completely redesign the Mediawiki syntax, the current {{see}} would be two or three full lines instead of something like nine, and it would handle an arbitrary number of list elements without itself having to be expanded to arbitrary lengths. For the changes that we're considering, this blows up to something like 30 full lines just to handle nine elements. And that's before even attempting to address the issue I'd mentioned earlier.

Absolutely ridiculous. How can anyone blame me for writing obtuse code? It's the only type of code that's possible here. And guess what, I'm not writing it. Great idea, Visviva, but Mediawiki has killed it. The bot option is still a possibility though. DAVilla 08:41, 13 August 2007 (UTC)

Eureka! It's greatly simplified if you do two passes, the first one determining the first and last elements. However, that would require Template:see/bas to look something like this:

{{see {{{sub|}}}|1st={{{1st}}}|nth={{{nth}}}|bas|-bas}}

Desirable? I think not! DAVilla 09:22, 13 August 2007 (UTC)

I agree that approach is not at all desirable. --Connel MacKenzie 01:49, 14 August 2007 (UTC)

In the case of single letters, and other things with large sets, I believe we are using Appendixes? See Appendix:Variations of 'a'. In other cases, one must keep in mind (as noted above) that the "see" relationship is not transitive (a see b, b see c does not necessarily mean a see c), and just barely commutative (if a see b, then b see a). (The programming problem is not as hard as DAVilla makes it out to be: instead of trying to do it all in one layer, you use one template/function that removes {PAGENAME} from its parameter list, and it then calls {see}. There is trickiness in preventing the first from causing the parser to uselessly generate all n-1 other forms. I am not recommending this!) Robert Ullmann 12:11, 14 August 2007 (UTC)

Waitasec..."a" is not "mistakable" for "b", "b" is not "mistakable" for "c". The Next/Previous stuff needs a different (separate) mechanism (such as definition line "#* Next: c" stuff that is normally used) rather than overloading {{see}} far beyond its "navigation aid" intended purpose. The Next/Previous stuff is related to an entry's language's POS/symbol content, not overall navigation. --Connel MacKenzie 20:19, 14 August 2007 (UTC)

Connel, what planet are you on? I'm just giving example of what transitivity and commutativity mean, a/b/c are variables? Comprende? Robert Ullmann 20:42, 14 August 2007 (UTC)

The Planet of not-reading-closely-enough-in-a-technical-discussion-because-there-is-just-too-much-other-stuff-going-on. Thanks for the clarification; sorry to have misunderstood what you wrote. However, in your example, what you said is wrong; the {{see}} line is a navigation aid that supplements ===Alternative spellings===, ===Related terms===, ===Derived terms=== and ===See also=== headings. So yes, if "a" has see "b", "b" has see "c", then all three "a", "b" and "c" should have see also pointers to the other two. That is exactly what the DidYouMean extension currently does do, correctly. --Connel MacKenzie 15:43, 15 August 2007 (UTC)

It should be commutative, as a rule, or otherwise you couldn't get back to the page from which you just came. Other than double-letters as in my example, are there any cases where it's not transitive? That's important to establish for any bot that can make these changes.

I gave up on it then came up with my idea above, parallel to your solution which also does two passes. I'd thought of your too but discarded it because, as far as I can tell, there isn't any way to skip an element in a parameter list. That's because the bar | is treated as special within an #if and not at a level higher in the parameter list. You can pass the bar to the parameter list by coding it as a character, but then it isn't treated as special at that higher level either. If it were possible to do your idea, then it would probably be possible to do something much simpler, which is to have Template:see/bas just contain the parameter list itself, bas|-bas in this case.

Sure: try using {{seem}}. Just a demo. Robert Ullmann 20:42, 14 August 2007 (UTC)

Ha ha ha! I think I could get that down to a triangular number, but it's still an x² explosion. I couldn't imagine the objection to increasing the number of parameters to, say, an entire 12!! You really have to be of a different mind to write templates, don't you? It's not about idealistic problem solving in an abstract infinite universe, it's about pragmatics in a tightly restricted and finite domain. DAVilla 21:13, 15 August 2007 (UTC)

Anyways, it isn't that I really want to implement this, it's that I'm frustrated that I can't find a good way to do it. DAVilla 13:28, 14 August 2007 (UTC)

I think the Appendix/DidYouMean combination is more than adequate. Am I missing something here? Are there specific examples I should load on http://wiktionarydev.leuksman.com/ that you'd like to play with? --Connel MacKenzie 20:19, 14 August 2007 (UTC)

This isn't about appendices. This is about ensuring that the topline {{see-also}}s are synchronised between pages. i.e. if someone adds {{see|fido}} to "Fido" then "fido" needs to have {{see|Fido}} at the top. When someone edits "fido" to {{see|Fido|FIDO}}, then the topline see-also on "Fido" needs amending as well. This thread is about finding a way to automate this. Thryduulf 21:39, 14 August 2007 (UTC)

But Thryduulf, that is fully automated by the DidYouMean extension! All that is needed is a VOTE to turn it on. --Connel MacKenzie 15:37, 15 August 2007 (UTC) And I don't understand why people haven't clamored in support. --Connel MacKenzie 15:43, 15 August 2007 (UTC)

Ah yes, indeed is. My apologies. If you look above I did support this (whether I clamoured I leave for you to judge). I can only suggest that you start a WT:VOTE about it - I can't see that much discussion is needed about the form of the vote as it should just be a simple yes or no to "Should the DidYouMean extension be turned on on the English Wiktionary?" Obviously with a brief explanation of what it is and why you want it installed, a link here, a link to the extension/documentation and any appropriate other links. Thryduulf 16:52, 15 August 2007 (UTC)

Documentation? Uh-oh. --Connel MacKenzie 00:29, 16 August 2007 (UTC)

Am I understanding correctly that DidYouMean only functions when the page is not found? Then it would be relevant to this topic, but not a solution to this specific issue. DAVilla 21:05, 15 August 2007 (UTC)

I have no idea why Hippietrail chose that name...it seems wrong now. This extension is what auto-fills the see also line at the top of the page. --Connel MacKenzie 23:53, 15 August 2007 (UTC)

Note: WT:VOTE#Extension DidYouMean has been started to address this. --Connel MacKenzie 16:28, 31 August 2007 (UTC)

Note: WT:VOTE#Extension DidYouMean has been started to address this. --Connel MacKenzie 16:28, 31 August 2007 (UTC)

Is there any objection to DidYouMean? If not, I don't see why a vote is needed, unless you want to set a precedent to always require votes for extensions. Personally I wouldn't oppose a system that's useful and functioning, despite my own ideas on what might work better if for initiative. DAVilla 21:05, 15 August 2007 (UTC)

I know of no objection to it. A vote is absolutely essential. The developers will not load an extension without a clear indication of community consensus (which for en.wikt, means a WT:VOTE. That precedent was set a long time ago for ParserFunctions or similar. Actually, the misinterpretation for 1st character case-sensitivity now forces them to demand a vote every time.) Once a vote here is complete, someone files a bugzilla: request. Then the developers are nagged daily on IRC until the extension is loaded. --Connel MacKenzie 23:53, 15 August 2007 (UTC)

Oh, that thing. In that case there could be some objection to it depending on whether double-letter variations are considered. Minor objection, of course, though possibly more objection if they are included, as we haven't had a full discussion on that. Plus we have certain rules of ordering that as I remember it Hippietrail ignored. Also it would be important to know how it handles logographic symbols like Chinese characters. Does the extention merely extend the see also or does it completely override it? DAVilla 00:31, 16 August 2007 (UTC)

It extends it! Excellent! The most significant problem is the sort order, which is an issue that had come up before. See this example of ON. Also, it would be nice if it showed existing variations of any manually added see alsos, per oon. DAVilla 10:00, 16 August 2007 (UTC)

Also there can be great number of variations without an automatic appendix. DAVilla 10:24, 16 August 2007 (UTC)

Regarding sort order, I suspect the easiest to implement automatically would be unicode order, but we could define something else if we preferred. If there is an appendix then this should be the only thing displayed - I guess that might be programmable in fairly straightforwardly (IANA programmer though). Thryduulf 10:29, 16 August 2007 (UTC)

The strange results linked above are a result of unicode order.

See in for a counterexample to appendix-only. DAVilla 11:42, 16 August 2007 (UTC)

Hmm, in that case we need to work out something more logical, perhaps:

1. lowercase no accents (on)
2. mixedcase no accents (On)
3. uppercase no accents (ON)
4. lowercase with accents (ön)
5. mixedcase with accents (Ön)
6. uppercase with accents (ÖN)
7. lowercase prefixes no accents (on-)
8. mixedcase prefixes no accents (On-)
9. uppercase prefixes no accents (ON-)
10. lowercase prefixes with accents (ön-)
11. mixedcase prefixes with accents (Ön-)
12. uppercase prefixes with accents (ÖN-)
13. lowercase suffixes no accents (-on)
14. mixedcase suffixes no accents (-On)
15. uppercase suffixes no accents (-ON)
16. lowercase suffixes with accents (-ön)
17. mixedcase suffixes with accents (-Ön)
18. uppercase suffixes with accents (-ÖN)

• This sequence would start with Latin characters and no extra letters, then repeat for Latin with extra letters, then repeat with Cyrillic, then another script, etc. Each section would be in unicode order, and any appendices would come last. Thryduulf 12:15, 16 August 2007 (UTC)

I'm sorry Thryduulf, I didn't follow that. The ordering is determined first by the manual {{see}} entries, then added with Hippietrail's Unicode ordering after that. Since the list is intended to be brief, the ordering (in almost all cases) seems like a minor issue (particularly when all the one-off cases can be dealt with manually.)

The "improvement" that I see as being needed at this point (which probably can't be done for a month or three, while HT is still on the road,) is the detection of a {{see|Appendix:*}} link, or the existence of such an appendix. Then again, I haven't tested that case severely yet - maybe HT did do that bit of code before he started traveling? --Connel MacKenzie 16:51, 16 August 2007 (UTC)

Right now the manual entries are sorted in with all the others. DAVilla 12:21, 17 August 2007 (UTC)

Connel, if I have understood DAVilla's comments (both immediately above this one, and the one I responded to with the list) correctly, then the DYM extension sorts all the entries into unicode order regardless of whether they are added manually or by the extension itself. If that is correct, and people other than myself and DAVilla are unhappy with the unicode order (or at least think it can be improved), then we need to agree an alternative order. My list above is designed as a suggestion for such an order; no entry should have that many options at the top, but the ones it does have should be sorted in that order - e.g. "on, ON, -on, oné, Ои, Ои́". Thryduulf 14:50, 17 August 2007 (UTC)

Frankly, I don't think HT needs the discouragement. I would be willing to vote in favor, in its current state, if such issues could be refined later. DAVilla 12:58, 18 August 2007 (UTC)

There's more punctuation than a hyphen, but that's a good start, and pretty close to what had been said a while back. I'm not too crazy about helping to hammer it out exactly, but I'll try to find that discussion (no luck so far) if you are. DAVilla 13:11, 18 August 2007 (UTC)

How long does the vote need to last? (DAVilla, do you want to start this one?) --Connel MacKenzie 23:53, 15 August 2007 (UTC)

The usual, I guess. I don't know enough about it to attempt a description. I couldn't immediately find an example on the site you linked, but I'll play around with it now. DAVilla 00:31, 16 August 2007 (UTC)

• WT:VOTE#Extension DidYouMean has been started to address this. Please vote! --Connel MacKenzie 16:28, 31 August 2007 (UTC)

• For code, see bugzilla:8648. --Connel MacKenzie 21:33, 15 September 2007 (UTC)

While editing my watchlist, I noticed that Appendix:Writing systems and alphabets was shown as a redlink at the top of the (Main) section instead of an existing link in the Appendix section. I tried editing my raw watchlist to place it with the other Appendix entries, but the listing in the "standard" watchlist editor didn't change. I tried unwatching, then watching the page again. Same result. I tried using "action=purge". No change. What is it about that page that is causing this problem? Do other people watching that page see the same thing when choosing "View and edit watchlist"? - dcljr 02:50, 12 August 2007 (UTC)

Just watched it, and it shows up OK for me. -- Visviva 02:55, 12 August 2007 (UTC)

The way I can think of this happening is if "Appendix:" was misspelled originally, and you are watching a (now deleted) old redirect. I'm not able to reproduce the problem, myself. If all else fails, you can clear your entire watchlist in a new tab (with your current watchlist kept open in a different tab) then re-watch them all. (That probably is way more effort than you'd like, of course.) --Connel MacKenzie 16:52, 14 August 2007 (UTC)

I'm trying to set myself up a construction template at user:Thryduulf/pluralof so creating a basic plural article (e.g. aquariums) involves less repetitive typing (along the lines of user:Thryduulf/trans3, etc.). The problem I am having is that I can't work out how to get {{subst:PAGENAME}} to substitute only when included, i.e. substitute the name of the page the template is included on, not "Thryduulf/pluralof". I've tried reading the m:Help:Substitution page but it is way over my head. Thryduulf 12:35, 12 August 2007 (UTC)

You have to trick WikiMedia into not substituting right when you save it by wrapping subst: with <includeonly> tags. That is:

{{<includeonly>subst:</includeonly>PAGENAME}}

DAVilla 13:57, 12 August 2007 (UTC)

But actually, there's already a pre-loaded template for that. Enter the plural term, click the Go button (instead of hitting the Enter key) and one of the options is a form for plurals. DAVilla 14:01, 12 August 2007 (UTC)

Thanks! I know about the pre-load template, but the majority of the time I'm creating these (and also verb forms) it is by opening the redlinks in a new firefox tab, which leads you direct to the edit window. Thryduulf 15:23, 12 August 2007 (UTC)

From there, near the top (top-middle?) is a "use the preload templates" link (yes, one more page-load, but easier than cutting and pasting from elsewhere, I think.) Note that plurals and other forms of English terms are usually bot-entered a day or two after an XML dump anyhow. I'm open to suggestions for re-wording MediaWiki:Newarticletext. A couple other people have mentioned it needs to be reworded, but didn't offer what they think it should say (or if they did, I missed it.) --Connel MacKenzie 06:48, 14 August 2007 (UTC)

Just as a note, I'm not cutting and pasteing - I just type {{subst:user:Thryduulf/pluralof|foo}} to get a complete English plural page for the plural of "foo". I find this quicker and easier than waiting for the page to load the page, waiting for a pre-load template to load (my internet connection speed is extremely variable) and then entering the word this is a plural of. Thryduulf 08:30, 14 August 2007 (UTC)

Pardon my obtuseness, but why is that easier than typing {{subst:new en plural|foo}}? —Ruakh_TALK 15:17, 14 August 2007 (UTC)

Because I didn't know I could do that! Thryduulf 16:14, 14 August 2007 (UTC)

I mentioned a long long time that you should solicit users for new ideas (edit:) for entry templates, and you suggested that I should do it, and of course I haven't. But I'm going to do it now. DAVilla 06:51, 14 August 2007 (UTC)

So what's the new wording to be, then? --Connel MacKenzie 09:07, 17 August 2007 (UTC)

Sorry, unclear. Edited.

I might propose changes later, based on how these are used. It looks like I'll have to set up a number of entry templates first though, for French, Itialian, and Latin initially. DAVilla 12:31, 18 August 2007 (UTC)

I'm starting this discussion to broaden what has been going do far here. Basically, 2 templates, {{fr-def-verbform}} and {{it-verb-forms}} where created to simplify the creation of entries that are conjugated forms.

{{fr-def-verbform}} uses the format {{fr-def-verbform|verb|ending|er or ir}} and will return all the appropriate form for that ending: {{fr-def-verbform|manger|e|er}} returns (an extra # must be added manually)

First- and third-person singular indicative present of manger

1. First- and third-person singular subjunctive present of manger
2. Ordinary second-person singular imperative present of manger

{{it-verb-forms}} is a variation of {{form of}} that returns a single line of the form Xth-person number tense form of according to abbreviations, with links. {{it-verb-forms|1|1|pi|cantar}} will return: Template:it-verb-forms It has specific limitations it that it must be called once for every individual form, even those that are normally (e.g. above) combined in a single line. It also does not actually use {{form of}}.

Now, there are good things to be said about both, but it is unclear whether they are either good ideas or what the ideal name for them would be. What do you people think? Circeus 16:40, 16 August 2007 (UTC)

It is best for the wikitext to include one line beginning with “#” for each definition that appears in the rendered text. That allows for quotations and example uses and, where necessary, to keep summary glosses in subsequent sections (e.g. usage notes) synchronized with the definitions to which they apply. Rod (A. Smith) 18:05, 16 August 2007 (UTC)

Agreed; but, we can make {{fr-def-verbform}} into a substitutable template that can be used when first creating the entry or language section.; I think that would be very useful. —Ruakh_TALK 20:48, 16 August 2007 (UTC)

Good point. FYI, to prepare {{fr-def-verbform}} to be subst-ed, someone will probably need to eliminate the comments and to change each “{{#ifeq:” to “{{<includeonly>subst:</includeonly>#ifeq:” and each “{{#switch:” to “{{<includeonly>subst:</includeonly>#switch:” in order to filter out comments and unused branches from the output. Rod (A. Smith) 21:17, 16 August 2007 (UTC)

Is it possible to keep the comments by encasing them in <noinclude> tags? It would help with code legibility. (I didn't even know you can now subst parserfunctions!).Circeus 23:43, 16 August 2007 (UTC)

<trivia> Parser functions were the developer's response to seeing crap like {{~if}}. When they realized what a significant factor those (and many similar templates) were having on performance, they implemented ParserFunctions. Since the original templates could be subst'd, (and were already used in some subst-only templates) they had to make the functions themselves subst-able. But they don't recursively subst - you either have to 'includeonly' the substs, or subst iteratively. </trivia> --Connel MacKenzie 09:00, 17 August 2007 (UTC)

I've seen ways to recursively substitute described in Help. Something like, you call a function that returns subst: or you subst: a template name that isn't explicit. DAVilla 12:14, 17 August 2007 (UTC)

I do not understand why this approach is being used, instead of a localized MediaWiki:Nogomatch/fr preload series for French. The parameters? (That's the part that is <!--fill-in-->, normally.) --Connel MacKenzie 09:00, 17 August 2007 (UTC)

Yes, that makes a lot more sense. Ultimately that's probably the way to go.

Per these templates, is there any way to pass them parameters such as the root? DAVilla 12:17, 17 August 2007 (UTC)

I have replaced {{context}} with context x.

Note that this requires several careful steps to avoid double redirects and lots of broken pages.

If you see any oddities, tell me on my talk page. The appearance of some extra parenthesis is expected.

If anything is very badly wrong, revert this edit but don't do anything else ;-) Robert Ullmann 17:10, 16 August 2007 (UTC)

See User:Robert Ullmann/Context labels for a report on the current template forms used. Robert Ullmann 17:22, 16 August 2007 (UTC)

I've now changed the redirects, and it is all working. Don't revert as above or it will all break! We seem to have almost everything sorted out (with much appreciated help from Mike Dillon). Just need some more templates now. Robert Ullmann 15:56, 20 August 2007 (UTC)

{{context x}} now redirected to {{context}} (along with talk page). Robert Ullmann 11:22, 28 August 2007 (UTC)

Have a look at, say, abaist. It appears that all uses of {{past participle of|]}} were broken by the last edit. It should work the same as {{past participle of|x}}, which seems fine. I think all the other verb form templates do this, and this one used to, too. The content of the last edit should remain, though, since it fixed a problem we were having earlier, where putting in an article that didn't exist produced an unlinked word, instead of a red link. (I don't understand why the template originally had an #ifexist in it to unlink nonexistent articles; red links are good.) Can anyone fix it? Dmcdevit·t 01:17, 19 August 2007 (UTC)

I'm not sure it's possible. The reason that {{past participle of|]}} used to work was that the parameter was used directly when #ifexist: returned false. This is the same reason that there were no red links. If you make {{past participle of|]}} work, then you'll necessarily break the red-link functionality for unbracketed entry names. Mike Dillon 01:44, 19 August 2007 (UTC)

The square brackets are useless. Can't we please just get rid of them? DAVilla 01:49, 19 August 2007 (UTC)

I was under the impression that some people might have gotten used to using them still. However, I agree that just removing them all would be the best solution, and I can do that pretty easily, I think. Dmcdevit·t 01:53, 19 August 2007 (UTC)

My understanding is that to be counted in the statistics as a valid page, a page must contain a wikilink in its actual wikitext, and that this is the reason these templates support pre-wikified page names. (Whether that's a good enough reason to have more convoluted wikitext — especially since an entry for a past participle is not exactly a paragon of pageliness anyway — I can't say.) —Ruakh_TALK 02:31, 19 August 2007 (UTC)

I'm not sure which statistics you're talking about, but the tracking of links to pages are based on the post-expansion wikitext, not the pre-expansion wikitext. This means that constructed links are pretty much identical to explicitly links for things like "What links here" and Special:Wantedpages. Mike Dillon 02:48, 19 August 2007 (UTC)

Not those statistics, no; some sort of actual statistics page, like Special:Statistics or Wiktionary:Statistics or something. —Ruakh_TALK 04:29, 19 August 2007 (UTC)

The statistic in question is the "Current number of entries", as displayed on Recent changes and as included on the Main page (with a delay). --EncycloPetey 20:01, 19 August 2007 (UTC)

Right, for statistical purposes only. In other words, they're useless. If the statistics are wrong, fix the statistics. That's a one-point fix rather than myriads. But if you really want a link on each page, a better way to do it is to add content. DAVilla 03:27, 19 August 2007 (UTC)

I don't think we have control over that, and think trying to have it changed would be a bad idea. --EncycloPetey 20:01, 19 August 2007 (UTC)

That's not my view, but I understand how you feel about trying to change something you don't have full control over. I just don't understand why, taking that view, we couldn't find another way to put a link on the page, such as an etymology. I mean, the etymology section is pretty straight-forward, is it not? No controversy over style, no need to use templates. Or if they count, maybe an interwiki link at the bottom of the page? At last, the Russian Wiktionary to the rescue! Or even a Quotations section referring users to ]. DAVilla 22:13, 19 August 2007 (UTC)

Hm, well, Connel, who is away now, said on IRC that if we move all the "lang=" parameters to after the verb parameter, the red links show up properly, and we can revert he change. He seems to think that entering the template in with the brackets is preferred. I've pasted in our conversation at User:Dmcdevit/Transcript. Dmcdevit·t 03:12, 19 August 2007 (UTC)

There seems to have been some miscommunication there: there's no way that flipping the {{{lang}}} and {{{1}}} parameters would affect the result of transcluding the template. (I've no opinion on whether flipping them might be a good idea for other reasons, such as the one Connel mentions in your conversation: ease of parsing by bots.) —Ruakh_TALK 04:29, 19 August 2007 (UTC)

What I said was first roll back then template, then swap them with {{{1}}} passed in wikified. That would at least match how the other templates handle it. How about replacing this:

{{#ifexist:{{{1}}}|]|{{{1}}}}}

with

{{#ifexist:{{{1|}}} | {{#ifexist:{{{1|}}} | ] | {{{1|}}} }} | {{#ifexist:{{{2|}}} | ]|{{{2|}}} }} }}

Including the separator spaces (where allowed) greatly improves readability. The complexity of wrapping the original "code" in another "#ifexist" allows the first have to function as it used to, while the second half deals with incorrectly constructed (lang= not at the end) template calls. --Connel MacKenzie 05:27, 19 August 2007 (UTC)

That transcript seems to be implying that having "lang=" first will throw off the number of the first unnamed parameter, but that is not the case (sorry if I misread the transcript and that's not what you meant). Have a look at m:Help:Template#Mix of named and unnamed parameters and m:Help:Template#Subsequent parameters. I'm also not sure what the nested #ifexist is trying to accomplish; the "else" branch of the second {{#ifexist:{{{1|}}} ... }}} will never be used since nonexistence of {{{1|}}} in the outer #ifexist will cause the code to use that invocation's else branch and ignore the other #ifexist. Mike Dillon 06:17, 19 August 2007 (UTC)

That was for consistency, so you can see that the inner halves are similar in form, differing only by 1 vs. 2, 2 vs. 3. While the meta documentation implies that the second parameter will be applied to {{{1}}} my experience has shown that doesn't seem to be true...but I'll test/double-check it in a sandbox now. The meta: documentation is referring to explicitly 1=, 2=, 3= parameters, not the case where there named parameters start the list. --Connel MacKenzie 19:57, 19 August 2007 (UTC)

I'm pretty sure that the first unnamed parameter is {{{1}}}, regardless of whether it is the absolutely first parameter or not. I guess the meta documentation is not entirely clear, but the algorithm is basically to set a counter for unnamed parameters that is only incremented when an unnamed parameter is encountered. Any named parameters, including those whose name overrides a numeric/unnamed parameter, are applied as they are processed. Have a look at User:Mike Dillon/Sandbox1. Mike Dillon 20:09, 19 August 2007 (UTC)

Nicely done; thank you. --Connel MacKenzie 03:14, 20 August 2007 (UTC)

Is someone going to fix this - there are very many Italian past participles that now look bad (e.g. scoperto) - and the bot adds more almost every day. SemperBlotto 10:40, 19 August 2007 (UTC) p.s. Also, the # at the start of the line doesn't give a number any more (strange) SemperBlotto 10:50, 19 August 2007 (UTC)

The # is a result of whitespace. I've rolled back the last change. I'm not sure what effect the other alteration has, an #ifexist: statement, but if you're having trouble with the template that might have been it. DAVilla 12:01, 19 August 2007 (UTC)

Well, that fixes the resulting problem, without addressing the newly reported problem. That is, I agree with the rollback. The others should be fixed by adding the proper wikification and reordering so the named parameters follow positional parameters. --Connel MacKenzie 19:57, 19 August 2007 (UTC)

Wait, why is that a problem? Named parameters are skipped in the counting. DAVilla 22:13, 19 August 2007 (UTC)

I don't agree that the template should take a wikified parameter as the default. If there is a need to pass a wikified parameter, then it should use an alternate parameter that is named (similar to the sg= parameter on {{en-noun}}). It's a big pain in the ass for editors to have to wikilink the arguments to {{past participle of}} and other similar templates; the needs of bots should always be secondary to reader and editor needs (in that order). If a bot really needs to re-evaluate wikilinks from the raw wikitext, it can interface with Special:Expandtemplates or re-implement template expansion from an offline database dump. Mike Dillon 20:18, 19 August 2007 (UTC)

Excuse me, but I am talking about parsing the offline database dump. When the offline parser I'm talking about was migrated, I don't think MediaWiki even had named parameters; at any rate, they were not used here. Yes, things evolve, but expecting overnight changes to unexpected input is unreasonable. The bot-generated entries in the past, have had to adhere to very strict conventions. (Generally, much, much stricter conventions than humans are expected to meet.) While this has been relaxed, this particular error is still unexpected.

Regardless, as stated above, the other problem is {{NUMBEROFARTICLES}} 8,238,450, which is the primary reason for providing a wikified link there. To use them consistently, means they all should indeed, have the wikilinks. --Connel MacKenzie 23:54, 19 August 2007 (UTC)

Hmm. I didn't mean to imply that I was expecting overnight changes. I actually agree that the revert to {{past participle of}} was warranted, given that many existing uses have a pre-wikilinked parameter. However, since most of the ones I've seen created by people in the few weeks that I've been around do not have wikilinks, I was really trying to focus on the fact that I don't think the pre-linked form should be required. I certainly don't think that breaking the display of existing articles is an acceptable user experience. Regarding {{NUMBEROFARTICLES}}, I'm not sure what the problem you're referring to is, but I'd be interested to find out. Mike Dillon 02:35, 20 August 2007 (UTC)

Well, if you really are in the mood for link chasing, you can start searching bugzilla, et al. I think this was only discussed in detail (in the last couple days) on IRC. It was a rather extended discussion that I wish had been in irc://irc.freenode.net/wiktionary-gfdl instead of irc://irc.freenode.net/wiktionary. The gist of the conversation was about the dev's WONFIX approach to function isCountable in Article.php. Smart money says: for the third year in a row, no, they won't add a "useSquiggleBrackets" there, and in LocalSettings.php. --Connel MacKenzie 05:53, 20 August 2007 (UTC)

Also, please do not confuse "inflection line" templates with "definition line form of" templates. They have very different purposes. In general, yes all "form of" templates wikify their inputs. --Connel MacKenzie 23:58, 19 August 2007 (UTC)

I'm confused. Are you saying that, at least for now, all "form of" templates should have have a square-bracketed link to the word they are a form of? i.e. should it be {{plural of|foo}} or {{plural of|]}}?. If the latter, would it be possible to include them in the blank template inserted from MediaWiki:Edittools when nothing is selected (if it is possible it would certainly be desriable)? Quite possibly not possible, but if it is, it would be good when if adding the template when something is selected, it would add the brackets if they were not present (i.e. select: foo and then add the {{plural of|}} from the edittools, would give {{plural of|]}}, but doing the same when foo is selected would give {{plural of|]}} not {{pluarl of|]]]]}}. Thryduulf 00:07, 20 August 2007 (UTC)

Yes. AFAIK, user-entered unlinked ones have the wikilinks added periodically, either by AF (?) or via User:Connel MacKenzie/todo5 or the rare bot cleanup run. --Connel MacKenzie 03:14, 20 August 2007 (UTC)

I would hope that the bots actually delinkify such uses when there's another link on the page, given that statistics are the only reason for this ridiculous syntax! DAVilla 07:42, 20 August 2007 (UTC)

I don't understand your objection to consistency. If we collectively were more consistent, people wouldn't make as many mistakes. For example, determining the 500,000th entry was confounded by a newcomer who followed your notion, instead of the proper syntax (and therefore didn't actually change the count, therefore didn't get credit for reaching the milestone...which obviously was important to them at the time.) Besides a minor example like that, the simple notion of having standards and sticking to them seems much more important to me. The consistent format is to use these terms wikified. Without the template, they'd still need to be manually wikified - I don't see how you justify that as "ridiculous syntax." It is not ridiculous, it is methodical, expected and consistent! --Connel MacKenzie 19:01, 21 August 2007 (UTC)

This isn't about consistency. If you wanted consistency, then it wouldn't be optional, it would be required for double-square brackets to wrap the term. Not doing so is not a mistake any more than fixing style rather than calling {{context}} or the inflection templates. It's ridiculous because it has no bearing on the rendering of the page. One time, ten times, a hundred times it would be a feasible work-around to some problems. Thousands upon thousands of times it's a superfluous hack in some competative game with the other Wiktionaries that I couldn't care less about winning. Maybe the guy entering a form-of term doesn't deserve recognition for the 500,000th entry. Certainly a robot wouldn't. DAVilla 05:57, 22 August 2007 (UTC)

I disagree. It is about consistency. I agree with your sentiment, that it should be required syntax. It isn't, only due to being lost in the shuffle. Your assertion that it isn't the format because a lack of formality strikes me as being misleading. While I agree the statistics are over-rated, it isn't productive to ignore them. The "guy" wasn't entering a form-of, IIRC, but rather forgot that his lemma entry needed wikification. Obviously, I assert that he did so, because we are not as consistent as we should be. All 'bot activity had stopped a couple hours prior to the milestone, despite them doing more for Wiktionary than individuals can. --Connel MacKenzie 15:07, 22 August 2007 (UTC)

OK. I was just giving the sg= example with {{en-noun}} because I thought most people would be familiar with this use of a named parameter for a wiki-linked alternate form, not because I thought it was a model for definition line templates in general. Mike Dillon 02:35, 20 August 2007 (UTC)

Whew. --Connel MacKenzie 03:14, 20 August 2007 (UTC)

Er, so, lots of discussion, but the original problem I had is still unfixed. In articles like acantilado, for example, where the parameter given to the template doesn't exist, it outputs plain text, not the desired red link. Can that be fixed? Dmcdevit·t 21:12, 22 August 2007 (UTC)

Wern't you going to run McBot, to wikify them? Or were you asking me to? --Connel MacKenzie 23:11, 22 August 2007 (UTC)

I suppose that's simple enough, but in my mind, that's a broken template. I should be able to enter in a parameter without brackets, and at least have it work, even if people want to periodically add in brackets for the article count, which I don't think is very important at all. Dmcdevit·t 02:05, 23 August 2007 (UTC)

Mind you, we have to be careful with single letter templates, we have 26 (or 52, or about 50,000 depending how you count ;-).

I think it would be a good idea to rename/move {{italbrac}} to {{i}}. We use it a lot, it is an important part of our formatting, and it has customized presentation. It is abbreviated at {{ib}} now, but that looks like a language code (though the ISO WG will never assign it according to its existing policy).

I've created the redirect for now, would appreciate comments. Robert Ullmann 00:12, 20 August 2007 (UTC)

I think it makes a good abbeviation, since it is the first letter of italics and is used as an abbreviation for such in many word processing programs. --EncycloPetey 00:54, 20 August 2007 (UTC)

I agree with EP. Looks good. Two down, 24 to go.  :-(   --Connel MacKenzie 02:52, 20 August 2007 (UTC)

Don't forget we already have {{c}}, {{f}}, {{m}}, {{n}}, {{p}}, {{s}}, {{t}}. --EncycloPetey 03:03, 20 August 2007 (UTC) (...and is {{g}} actually being used?)

Looks like {{g}} is used...perhaps it should <joke> expand to {{requests|Dutch gender information}}? </joke> Waitasec. It should be {{rfg}} or {{rfgender}} or {{stub-gender}} or {{gender-stub}}? Perhaps {{gender-attention}}? Maybe Hippietrail's "template naming conventions" initiative has more merit than I gave it credit for. (Granted, I give his initiative a lot of credit, but apparently not enough.) --Connel MacKenzie 18:02, 21 August 2007 (UTC)

I have a problem with {{italbrac}} in that it dictates the style rather than the use. In the same way that {{context}} is used for a specific purpose, we should be using something like {{label}}, {{gloss}}, {{onyms}}, etc. This proposal, while it isn't a poor idea in its own right, does not mesh with that goal. DAVilla 07:33, 20 August 2007 (UTC)

"label" is exactly the same: it isn't a particular semantic function and can't do anything more than i/italbrac; if you want something for a specific semantic, go ahead. ({gloss} is already used for something as you know, but you could fix that.) The pronunciations need tags ala {{RP}} that specify the variants, not the countries (GenAM, etc.) and so on. Robert Ullmann 14:59, 20 August 2007 (UTC)

If I understand what you might do with "onyms" (;-) what can it do other than being a placeholder-redirect to italbrac? (it could wrap the : in, I suppose) You have to figure out what the thingys are supposed to DO that is worth the trouble. Robert Ullmann 15:02, 20 August 2007 (UTC)

Earilier I had in mind that {{label}} would function like {{context}}, using the same context labels, but without categorization. That would be used e.g. to tag individual synonyms. Proposing it as a simple redirect to {{italbrac}} doesn't make the purpose stand out, so the name could probably use some review. It isn't supposed to do anything other than indicate the symantics of what it's wrapping, although we may want it to actually do something later. Your point about pronunciations hits that spot exactly. {{accent dialectaccent|GA}} should display as GenAM or GenAm or whatever we decide should be used consistently, preferably for me no abbreviations. Your point about the colon is also spot-on. {{italbrac-colon}} was actually poorly implemented, since some had insisted on displaying the colon within the parenthesis. I wonder what we could be overlooking, what is needed to tag translations for instance. For every different purpose, there are different issues to consider: standardization of naming, side-effects like categorization, differnt possibilities for stylistic preference. DAVilla 21:26, 20 August 2007 (UTC)

I see User:Autoformat is happy with {{i-c}} as well. I've never liked "italbrac" as a name, but I couldn't imagine anything more obsure than this. DAVilla 11:55, 21 August 2007 (UTC)

Yes, playing with that; I don't think "ic" would be a good abbreviation do you? (It isn't a language code.) Presumably most of the cases it is finding would be {onyms} or {accent} of something; mostly I'm just collecting some for now. Then whatlinkshere for template:i-c (or just the string in the next XML) will be interesting to look at. How one does one explain that editors should use {onyms} in one place and {accent} in another, and {italbrac-colon} in another, when they all do exactly the same thing? They should only be different if/when they are different. (oh, "italbrac" is just as obscure as "i-c", just one is familiar and the other isn't ;-)

The italbrac-colon code should've been done better as you pointed out (and still can be); with (say) ib-colon-in and ib-colon, one of which would be styled as desired and the other invisible (or both invisible). Robert Ullmann 12:23, 21 August 2007 (UTC)

Looking at a few dozen random entries AF has played with: the most common case is after * at the start of a line, in -nyms or something, there is a lot of inconsistency there; I think that is where we should use {i}, defined as italbrac-colon (not just italbrac); half the entries seem to use the colon while half don't. And this presentation should be (and is now) user defined if desired.

At the same time, as DAVilla and EP have pointed out, we need tags for the pronunciations. This is not a finite, well-defined, bounded set. We need everything from RP to East London to Zhangzhou and Bronx and Bahston in between. The tags, unlike language or script codes, or even contexts, have to be a different set/namespace.

I'm playing with {{a}} to reference these. (I didn't want to use "accent" in part because people whinge about not having an "accent"; it is always the other people who do ... ;-). So, e.g. {{a|RP}} and {{a|US}} etc reference Template:accent:RP and Template:accent:US. Ones used commonly can be filled in if they show up in wanted pages. Keep in mind that there aren't dozens of these; there are/will be at least tens of thousands. Might be its own NS someday.

This is following along with DAvilla's direction; contexts have label templates, pronunciation labels/tags use {a}, other labels/glosses at the start of lines for *nyms use {i}. Robert Ullmann 00:08, 22 August 2007 (UTC)

I was thinking the very same thing today, minus the subspace. It would be nice to be able to use {{RP}} by itself. In fact it would be possible to overload {{UK}} so that it could be used with either {{context}} or {{dialect}}, the latter converting to Received Pronunciation. On the other hand, there are only about 300 uses of {{RP}} right now, so if we could convert them all over there isn't any strict need to allow the template to be used by itself. See also the Spanish pronunciation of W for the types of problems we'd run into in identifying dialects.

I am extremely hesitant to reserve a single-character template for anything that isn't normally used a dozen times on a page. Plus there may already be established meanings that we'd need good reason to override. To me, "i" means italics and "a" means anchor, following the example of HTML, phpBB, and who knows what else. So in the future {{i}} will probably be a better short-hand for {{term}} than anything.

For a better name for {{italbrac}}, how about using {{()}} edit: or {{(i)}}instead? Still, that's only if we really want it to be used in entries, and you would have to make the case that it's needed somewhere that can't be identified as a common syntactic use. Otherwise I would push it of to {{stylized annotation}} and only call it from other templates. DAVilla 03:21, 22 August 2007 (UTC)

You do know (?) that accent is not dialect? you seem to be using dialect as a synonym? Yes, there is often a correspondence, but then there is often a correspondence between, say, countries and languages ... ;-)

Listen, children and you will he-ah/of the Midnight Ride of Paul Rah-vee-ah. Accent, not dialect. Accent is Boston common (not Brahmin), "hear" is standard English usage.

Are you going to wear your shoes? No, not "Are you going to wear shoes or your sandals or go about in your stockings?". But "wear" as an active verb meaning to put on: "Are you going to put your shoes on (now)?". Dialect, not accent. Dialect is East African English, while pronunciation is bog-standard. Robert Ullmann 23:52, 23 August 2007 (UTC)

Thanks for the clarification. I know what a dialect is and it took me half a minute or more to realize this was a misuse. I had been trying to think of an alternative to "accent" since you didn't like the word, but it seems to be the most appropriate one. DAVilla 01:56, 24 August 2007 (UTC)

On the more technical points: I'm not concerned about the HTML uses of a and i (or, say, b), a is in wiki text, i is ' ' and b is ' ' ' ... "i" as generally meaning "italic in parens" seems to be useful.

Overloading (e.g.) "UK" is not a good idea at all; UK usage and UK pronunciation are two entirely different things. Indian English is almost exactly British/UK usage (where it shares meaning; there is also a set—many sets—of local terms, as in Singapore Singlish) but pronunciation of almost every multi-syllabic word is different. (Giving values to vowels reduced to schwa in most UK and GenAM accents.) In general, the context/usage tags do not correspond to accents.

There are many, many accents required: any reasonable set dwarfs the existing Template namespace, even if it had all of the language codes, script codes etc. There are hundreds of cities and districts in China alone; thousands in Africa; and India?

What I'm intending now is to convert pronunciation tags to {{a|...}}, glosses in Related terms etc to {{i-c|...}}; we can then change the names if desired with ease. {{i|...}} seems to be already seen as a good idea by a number of people. Just collecting the accent tags will be useful.

Note that (as DAVilla may know, but others probably won't) the ISO policy now is to recognize that applications of 639 often use a mix of 2/3 letter codes, and therefore new 2 letter codes for things with 3 letter codes will not be assigned. (Unless the Klingons show up, and prove to be the Masters of the Universe, and demand that tlh be kl or something. Otherwise, we aren't going to discover some big, new, and previously unknown language ;-) So we could use {ic} instead of {i-c}, and perhaps use the exiting {ib} redirect to italbrac. Robert Ullmann 00:28, 24 August 2007 (UTC)

You joke now, but some day... !!! :-P

What would be the output of {{accent|UK}} then? Would it not be automatically corrected? I think most people think of accents in terms of regions, even though there are more precise names. DAVilla 01:56, 24 August 2007 (UTC)

My impression is that most people think of accent in terms of deviation from a standard. Thus, if we call the template {{accent}}, we'll fall into continual arguing over what constitutes an "accent" versus what is "standard" with every new user. Because of this, I'd rather devise a POV-neutral name tied to the section name instead, like {{pron}} (even though that might be confused with pronoun, it's not likely since it will appear in the Pronunciation section). --EncycloPetey 18:46, 25 August 2007 (UTC)

If the template is just called {{a}}, then I think we'll bypass that sort of problem. (Template talk:a can explain that it stands for "accent", but also make clear that we are in no way implying that pronunciations are non-standard.) —Ruakh_TALK 19:53, 25 August 2007 (UTC)

But look at the discussion above. The letter "a" has an HTML meaning that would create confusion. --EncycloPetey 20:13, 25 August 2007 (UTC)

<p> and <s> also have HTML meanings, and both are used here rather often (especially <s>), but it doesn't seem that anyone gets confused. Given how often we'd use {{a}}, I think people would overcome their confusion quite quickly. —Ruakh_TALK 21:22, 25 August 2007 (UTC)

The salient difference is that "a" is used in HTML even by people who don't particularly do HTML (e.g. slashdot, blogs, or a million similar message boards.) And {{a}} wouldn't be so common here, not nearly as common as gender, no matter how optimistic one gets about it. --Connel MacKenzie 04:44, 26 August 2007 (UTC)

The most important difference I see is that when we use {{p}} or {{s}}, we never include arguments. Each of those templates displays as a simple bit of text, and so it is fully transparent what the template outputs are. The proposal currently under consideration for {{a}} would include arguments, so the output would not be so transparent and would look more like an anchor function. --EncycloPetey 05:29, 26 August 2007 (UTC)

You'd have to look it up to know that "a" meant "accent". Otherwise "area" would spring to mind. If we're to use a full name, how about {{tongue}}? Or it could be abbreviated as {{8-P}} ;-) DAVilla 11:03, 26 August 2007 (UTC)

Crap, see Wiktionary:Entry layout explained#Pronunciation. DAVilla 06:09, 27 August 2007 (UTC)

What's the problem? ELE shows a simple form, and we need a comprehensive format documented. How is this different from anything else? Robert Ullmann 18:46, 27 August 2007 (UTC)

It'll be a pain to go through all the discussion and voting to get the Pronunciation format modified, but I think we're all agreed that the format can and should be improved. We can work on creating a new draft for Wiktionary:Pronunciation as a fully fleshed out document for even the complex cases, then create a simple version to replace the current ELE text. Since Wiktionary:Pronunciation is currently labelled a "draft" (it's really just a list of links at this point), we don't have to go through voting on editing that page. We can wait until we've got the document where most people are happy with it and then vote on the product. --EncycloPetey 00:17, 28 August 2007 (UTC)

There are a number of variations on this, as people improvise on the trans-top collapsible templates and so forth.

I've seen quite a few watching AF. The one I like best is represented by (for example) qualitative which uses {{checktrans-top}}. It also omits the mid call (which should be optional in this case anyway). Why {checktrans-mid}} and {checktrans-bottom} aren't redirects I don't know.

But just look at the format. Do you like the result? We could do away with the L5 header, and it looks good to me ;-) Robert Ullmann 00:27, 20 August 2007 (UTC)

Generally, yes, I like the flattening (no L5) by using this technique. I know my JS hasn't been updated to check for {{checktrans}} or {{checktrans-top}} yet, (sill only 'checktrans',) but that is minor. I have no idea if or TTBC-checking translators actually use the L5 heading or not. It certainly gives the whole entry a much cleaner look.

I thought that "style" of checktrans was going to use {{checktrans-mid}} (which should, yes, be a redirect.) --Connel MacKenzie 02:50, 20 August 2007 (UTC)

If there are only a few ttbcs, there isn't much reason to insist on the use of {checktrans-mid}. If there are a whole bunch, sure. It is supposed to be temporary anyway. As to whether they use the L5 heading: they use just about every combination of heading/no heading/"Translations to be categoried", ttbc-top, trans-top, checktrans, and checktrans-top that you can think of. (;-) Robert Ullmann 14:30, 20 August 2007 (UTC)

It is unbelievable to me that, since the last time I partially cleaned out Category:Translation table header lacks gloss, it has again doubled in size as a result of users converting {{top}} to {{trans-top}} without adding a gloss. If we keep {{trans-top}} distinct from {{top2}}, then not having a gloss is an error that is not currently indicated. I have been cleaning up that category again, and this time I will finish the job, and at that point I would hope that {{trans-top}} can be overloaded with the {{checktrans-top}} feature when no gloss is provided, or some other clear indication of an error state, so that the category can be removed, because quite frankly once I'm done I NEVER INTEND TO CLEAN OUT THAT CATEGORY EVER AGAIN. DAVilla 07:23, 20 August 2007 (UTC)

I think you are conflating two (related) things: yes, when you go to add gloss(es), it often involves ttbc; but just having the gloss missing is common when there is only one sense, and people don't understand that there ought to be a gloss. Robert Ullmann 14:30, 20 August 2007 (UTC)

There should be a gloss even when there is only one sense, to avoid TTBC'ing all the translations when someone adds a new sense. If it were in some way evident that something was very wrong when the gloss were missing, then this wouldn't happen. It could say "No gloss provided" and even change the top strip to red. Right now "Translations" indicates that everything is hunky-dory. Changing that to "Translations to be checked" and adding {{checktrans}} is an alternative, but the category has to be cleaned out first, and it may be too much of an overloaded function anyway. I want to do something. What do you think? DAVilla 20:24, 20 August 2007 (UTC)

You're missing my point: a missing gloss does not mean that it should be ttbc; the common case is there is only one sense. Yes, when you go cleaning them up it often means sending stuff to ttbc if there is more than one sense; but they are not the same thing! If there is only one sense, everything is fine, except that we'd like the gloss anyway. Robert Ullmann 15:24, 21 August 2007 (UTC)

Look, screw it, if I can't convince you of another use for the missing gloss, let me at least convince you that it should display prominantly as an error state. It's not just that we'd like people to put in a gloss for only one sense, it's that doing so will save a ton of work later if another definition line is ever added, even an erroneous one that's later deleted! The point of checking translations is to reach a point where they don't have to be checked anymore, or at least very rarely. Allowing translations without a gloss is just asking for the useless expansion and indefinite extension of that workload. DAVilla 05:10, 22 August 2007 (UTC)

I agree with DAVilla. A missing gloss is an error. --Connel MacKenzie 15:26, 22 August 2007 (UTC)

We have not yet standardized the format for mentioned terms within running text. Mentioned terms may or may not be English, may be written in roman or non-roman scripts, may show with alternate text, may include transliterations, and may include English translation glosses. Some editors embolden mentioned terms. Others italicize or just wikilink them. My own conventions for mentioned terms are to quote English ones, to italicize non-English roman-script ones, to parenthesize and italicice their transliterations, and to use enclose their English translations in directional quotes.

Forgetting that there is no standard, I sometimes reformat mentioned terms (e.g. ), as do other editors (e.g. ). Previous discussions about the subject achieved no consensus regarding use of bold or italics, but we made some headway with Category:Form of templates by allowing users to customize their experience to fit their expectations.

Judging from previous conversations, consensus is unlikely regarding formatting conventions for mentioned terms, so I propose we compromise by using a user-customizable template like {{term}} to mention terms within running text, especially for terms that require special scripts, transliterations, or gloss translations (e.g. when we refer to terms within etymologies, usage notes, and derived terms). For English terms, {{term}} simply displays the linked term using whatever format the user has chosen for Category:Form of templates, e.g. {{term|word}}, displays as (deprecated template usage) word. Common formatting options follow:

Customize the output of {{term}} by adding any of the following to Special:Mypage/monobook.css:

• For plain mentions (i.e., to mention word), use this:

  .mention { font-style: normal; }

• For bold mentions (i.e., to mention word), use this:

  .mention { font-weight: bold; }

• For italic mentions (i.e., to mention word), use this:

  .mention { font-style: italic; }

Currently, the default matches that which the community chose for Category:Form of templates. If we so choose, though, we can alter the default format while allowing readers to customize their own environment.

Additional benefit from adopting {{term}} for inline mentions appears with non-English and non-roman script terms, e.g. in an ===Etymology=== section, one might use “From {{term|sc=Hang|말|tr=mal||gloss=word}} + ...”, which produces this:

From 말 (mal, “word”) + ...

At this stage, I am mostly seeking feedback regarding the parameters, template name, mechanics, and additional formatting options. I welcome any additional feedback at this time, but per standard process, I expect to take this suggestion to WT:BP to gauge community support after we refine this template here. Rod (A. Smith) 05:37, 20 August 2007 (UTC)

Sounds like one for either WT:TAT, or WT:CUSTOM, then WT:PREFS, right? --Connel MacKenzie 05:58, 20 August 2007 (UTC)

Absolutely. The easier it is for users to customize the output, the more beneficial this will be, and more uniform our dictionary will be. Hmm. I'm surprised the Category:Form of templates info didn't make it into WT:CUSTOM. I thought I added that, but perhaps not. Is there any reason I should not do so now? Rod (A. Smith) 06:03, 20 August 2007 (UTC)

Please add it all; having it tested in WT:CUSTOM makes it significantly easier to add to WT:PREFs. --Connel MacKenzie 06:20, 20 August 2007 (UTC)

Done. Rod (A. Smith) 06:27, 20 August 2007 (UTC)

Wait, this is actually a partially settled issue. It just hasn't been implemented because there was no way to determine the script. Now that we plan to pass sc= to form-of templates, it can finally be done. I've added class='mention-roman' to Template:stylized mention root if someone wants to update the css. Alternatively, let me know if there's a way to make class=mention default to bold except when there's a script, which can either wrap the mention or be wrapped by it depending on what's easier. DAVilla 07:07, 20 August 2007 (UTC)

Thanks for pointing out that vote, DAVilla. It's good to see that there was some agreement about how to format mentioned terms in at least that context. {{term}} is intended to allow us to apply the common formatting to other places where we mention terms (“class=mention” for roman script terms, the appropriate script template elsewhere, and consistent formatting of any following transliteration and gloss). Rod (A. Smith) 16:18, 20 August 2007 (UTC)

Reviewing {{stylized mention}} reminded me to bring up a point related to the new “{sc}” parameter used in various places. Since our script names are now standardized to end in “ script”, it seems sensible to have users pass only the four-letter ISO script name as the argument to “{sc}”. I.e., “{{stylized mention|sc=Hang|...}}” seems better than the redundant “{{stylized mention|sc=Hang script|...}}”. Thoughts? Rod (A. Smith) 16:26, 20 August 2007 (UTC)

Excuse me, but DAVilla moved the templates to Xxxx script without discussion; it is in no way "standardized"; the subsequent discussion was to use either just Xxxx or some short prefix. I for one prefer just the Xxxx form. Can we please NOT propagate the "Xxxx script" form in any case? Keep in mind that most uses of script templates are direct, not passed as sc= or whatever. Robert Ullmann 17:32, 20 August 2007 (UTC)

How about if we remove "script" from each of the titles for now, to allow sc=Xxxx to work universally, and then just modify the templates that use {{{sc}}} later if we decide that Xxxx alone is unworkable? DAVilla 21:01, 20 August 2007 (UTC)

support Rod (A. Smith) 21:06, 20 August 2007 (UTC)

That sounds fine. Keep in mind that people will also want to use sc=polytonic and a few others; it also means that existing and new uses of (for example) sc=ARchar will work, without having an "ARchar script" redirect. We can deprecate the older forms over time. Robert Ullmann 12:39, 21 August 2007 (UTC)

Moved all and resolved the double redirects. Also protected the ones that weren't already, except Template:Goth which is fairly new. Could someone review the css classes? E.g. Template:Cyrl assumes it's Russian, even including {{Russian fonts}}. DAVilla 04:44, 22 August 2007 (UTC)

It looks like we'll need different css classes for form-of definitions, which should normally be boldfaced, and other mentions, which should normally be italicized. By "normally" I mean in Roman script, including English. An exception is that Paul G likes to put English (including Old English?) words in boldface in the etymology, which just makes things more confusing. DAVilla 12:10, 21 August 2007 (UTC)

I would personally prefer most mentions to default to italics, but I don't know of any style guide that so recommends. Is there one? Rod (A. Smith) 15:10, 21 August 2007 (UTC)

No, I know of no style guide that recommends that. Also, many of us (as shown by the last vote) have serious objections to italicizing words mentioned. I prefer mentions in bold, transcriptions in parenthetical italics, and translations of meantions in quotes. --EncycloPetey 15:28, 21 August 2007 (UTC)

That objection is good to know. I expect to see many more such preferences when I introduce this topic on WT:BP. I'm very pleased to be able to introduce {{term}} in order to standardize the orthography of mentions while still allowing each reader to choose the style he or she prefers. Is there any indication that some editors or readers prefer one style of mention for within Category:Form of templates and a different style for within running text elsewhere? Rod (A. Smith) 15:45, 21 August 2007 (UTC)

You mean the vote we had, that DAVilla linked above? --Connel MacKenzie 16:36, 21 August 2007 (UTC)

Reading that vote, I see no indication that anyone wants a different style in the “form of” definitions as compared with anywhere else. In particular, you seem to prefer consistency (“as long as we are consistent within the entire dictionary”). I would love to talk with anyone who does want the style for mentions to differ depending on location. Rod (A. Smith) 18:13, 21 August 2007 (UTC)

I guess I fall into that category: I strongly prefer that synonyms, antonyms, translations, etc. not be given any kind of special formatting, as that would look stupid, but in definitions and etymologies I prefer that mentioned terms be italicized. If we've agreed to bold lemmata in "form-of"-style definitions, I'm O.K. with that, but still think we should italicize other mentioned terms in definitions and etymologies. —Ruakh_TALK 21:49, 21 August 2007 (UTC)

Your point is well taken, Ruakh. There is a legitimate reason to use different orthography in a simple list of terms (e.g. in ====Derived terms====, ====Synonyms====, etc.) than that used in running text (e.g. in ===Etymology===, definitions, and ====Usage notes====). I will refine {{term}} with that distinction in mind. Rod (A. Smith) 00:18, 22 August 2007 (UTC)

The best syntax I've found so far to distinguish between listed terms and terms mentioned in running text is to use a different template for list items, e.g. {{entry}} (which exists but is unused). At this juncture, though, I think a proposal to adopt {{term}} would be gather more support if it is limited to use within running text. Some time later, it will of course still be possible to address the issue of consistently formatting listed terms, possibly using {{entry}} or another template. So, if there are no further suggestions or concerns, I will start the discussion on WT:BP. Rod (A. Smith) 01:41, 22 August 2007 (UTC)

I agree with Ruakh about the principles, but not the italicizing. I also think that any mentions in definitions should be done uniformly, however we do it. Mentions in etymologies might be a separate issue.

Ruakh, part of the problem with italicizing mentions is that in certain scripts, the charatcers change when you italicize. I can read printed Cyrillic, but I always get very confused by italicized Cyrillic because they're not the same characters. For example, lower-case Russian Д lloks like д in print, but in italics looks like a cursive g; the lower case of Russian Т is т in print, but looks like a cursive m in italics. I would rather not confuse someone looking up Russian. I also would rather the format not be language or script specific, as that would mean having multiple formats. Hence, I prefer bold text. --EncycloPetey 04:32, 22 August 2007 (UTC)

When we talk about italicizing, we should restrict our meaning to Roman script for exactly that reason. Personally, I don't see why any style is necessary for other scripts, since the different script stands out anyway. But if you really want Cyrillic bolded as a mention, there should be a way to do that through css, given it's wrapped with both class=mention and class=Cyrl (currently class=RU for some reason). DAVilla 04:53, 22 August 2007 (UTC)

Cyrillic is an extreme example. Do you consider IPA to be "Roman script"? What if I mention an IPA symbol? Also, I have real trouble reading Latin with macrons when italics are used—depending on the font size, browser, and computer. Modern Latin textbooks prefer bold, possibly for the same reason I have. Namely, that italics usually look spindly and pixelated. Traditionally italics is supposedly for emphasis, but in reality it just makes things smaller and harder to read (to quote a friend of mine from college). --EncycloPetey 05:01, 22 August 2007 (UTC)

Points well taken. I will be certain to allow us to mention IPA term by specifying “IPA” as the script, e.g. {{term|sc=IPA|ɕ}}. I will also ensure that the templates that result from this discussion use a default for roman script entries that matches some standard (e.g. the format voted in for the “form of” templates) and a different default for non-roman script mentions. To satisfy your need for a different default, we could have {{term|sc=Latn|verbum}} (with the script specified) format differently from {{term|word}} (without the script specified). Coolio, dadio? Rod (A. Smith) 05:29, 22 August 2007 (UTC)

The additional problem with Latin, Greek, Hebrew is that the link is not the same as the display form. The lemma does not use diacritics or vowel markings, but the display form as used in an etymology or definition mention does. The template proposal seems to make the entire process of mentioning a word highly cumbersome. --EncycloPetey 23:02, 22 August 2007 (UTC)

Yes, the alternate text issue is well known, and yes, the current syntax of using the "alt" parameter does seem a little cumbersome. I'll tweak the syntax to see if it can be a bit easier to use. Rod (A. Smith) 23:11, 22 August 2007 (UTC)

No, IPA is not Roman script. Yes, many of the symbols derive from the familiar alphabet, but not all, and regardless, if you mention an IPA symbol, you should put it in slashes or brackets as IPA symbols are always, always written. At least Latin macrons are a legitimate complaint, but these other counterexamples simply don't apply. What I and I believe others have in mind are mentions of words written in familiar characters. We can address different scripts on their own merits. Indeed, we almost have to. I remember someone complaining that one script, I'm not sure if it was Arabic or Chinese or what, didn't boldface well. No single solution is going to apply to all scripts well. DAVilla 05:33, 22 August 2007 (UTC)

Indeed. Bold obscures the strokes of complex Chinese characters. This initiative will allow each script to be formatted in its ideal style. Rod (A. Smith) 05:40, 22 August 2007 (UTC)

No, no no. An IPA symbol enclosed in brackets or slashes is a sound, not a symbol. If I want to mention the symbol, I cannot use slashes or brackets because I am talking about a written character. If I enclose the symbol in brackets or slashes, I am discussing the sound that the symbol represents. --EncycloPetey 23:02, 22 August 2007 (UTC)

Hmmm... okay. Well they have their own unicode range, so I support discussing them separately—I think that was your original concern—if there's a need to discuss them at all. No objection to your bolding or quoting them as you wish for as long as {{term}} does not suit your needs. There are more common scenarios that have not been resolved, taking in all of the WT:BP discussion. DAVilla 23:58, 22 August 2007 (UTC)

True. My primary goal in this discussion is to raise as many of the potential issues as I can come up with, so that whatever template/format is selected and developed is as well-designed as possible. I have my reservations, but the underlying principle and goal is attractive. --EncycloPetey 02:29, 23 August 2007 (UTC)

See Orthography of mentioned words in user discussion. DAVilla 03:39, 22 August 2007 (UTC)

On a related topic: Is there a similar, but linkless template to just add <span class="mention"></span> around words? Circeus 02:44, 24 August 2007 (UTC)

To address EncycloPetey's concern about cumbersome syntax and Circeus' suggestion for a link-free version, I changed the syntax for {{term}} to use positional parameters and allow the link parameter to be empty:

• Proto-Indo-European base *(deprecated template usage) werə-.

Proto-Indo-European base *{{term||werə-|to speak}}.

The syntax is now usually just slightly more succinct than the standard syntax used to mention terms in running text:

• From (deprecated template usage) word + ...

From ''']''' + ...

From {{term|word}} + ...

• From (deprecated template usage) verbō + ...

From ''']''' + ...

From {{term|verbo|verbō}} + ...

• From (deprecated template usage) verbō + ...

From ''']''' (“for the word”) + ...

From {{term|verbo|verbō|for the word}} + ...

• From (deprecated template usage) verbum + ...

From ''']''' (“word”) + ...

From {{term|verbum||word}} + ...

• From (deprecated template usage) λόγος (lógos) + ...

From {{Grek|]}} (''lógos'', “word”) + ...

From {{term|sc=Grek|λογος|λόγος|tr=lógos|word}} + ...

Interestingly, though, I cannot locate any CSS change that resulted from this vote. I think “.mention { font-weight: bold; }” should have been added to Mediawiki:common.css, but it does not appear to have happened. Am I overlooking something? Rod (A. Smith) 22:28, 24 August 2007 (UTC)

FYI, that vode decision had not yet been implemented but is now. Refresh your browser cache if you use defaults and don't yet see (deprecated template usage) word in bold. Rod (A. Smith) 05:28, 25 August 2007 (UTC)

That is quite incredibly elegant. I'll remember to use it. Circeus 04:16, 25 August 2007 (UTC)

Just to verify, I can link to a specific language section of an entry using this template? For example, If I need {{term|tenere#Latin|tenerē}}, this will work consistently, yes?--EncycloPetey 18:32, 25 August 2007 (UTC)

Yes, that syntax is valid and expected. Following the lead from {{t}}, I also added support for circumstances where the editor might want to link to the entry in a non-English Wiktionary. For example, {{term|lang=es|palabra||word}} creates this:

palabra (“word”)

Of course, maybe there is some reason we need to restrict such links to translation tables. If so, please let me know. Rod (A. Smith) 06:53, 26 August 2007 (UTC)

I'm not to keen on the interwiki link, though it would be good to have an L=Language name parameter for the #secion link, per EncycloPetey's example, especially useful for terms that are identical to {{PAGENAME}}. DAVilla 10:51, 26 August 2007 (UTC)

OK. I will add a parameter {{{L}}}, gather additional feedback about the interwiki link, and remove it assuming it is generally disliked. Rod (A. Smith) 01:11, 27 August 2007 (UTC)

Wow, what a long section. Rod, is this a sufficient example, for you to add your CSS yourself? I seem to have lost track of where you put the CSS you mentioned earlier. (And yes, you are welcome to edit that...it will move to the Wiktionary namespace when Monobook.js moves to Common.js.) --Connel MacKenzie 06:29, 7 September 2007 (UTC)

Yes, that is a good example. I'll add the code. Thanks. Rod (A. Smith) 06:39, 7 September 2007 (UTC)

I have incorporated most everyone's feedback with regard to orthography of mentions into {{term}}, {{Latn}}, MediaWiki:Common.css, WT:PREFS (via custom.js), and {{en-term}}. {{en-term}} is required by User:Paul G's suggestion (copied at Template talk:term#Requirements analysis: Types of mention) to distinguish between English mentions and non-English Latin (Roman) script mentions. For a complete list of the types of mentions that this system is meant to handle, please see Template talk:term#Mentions by type.

User:Hamaryns has suggested a couple of changes that are not yet incorporated. The one element with which I need feedback is the suggestion to incorporate the styles from {{italbrac}} into {{term}} for transliterations. Because {{term}} also may need to display non-italic text (English translation glosses) inside the parentheses, I cannot directly use {{italbrac}}, but I could incorporate its classes (ib-brac and ib-content) into {{term}} if that is desirable. That application may not be desirable, though, because I think some readers use {{italbrac}} to hide parentheses around definition context tags. Would such readers really want the parentheses to drop around transliterations? Rod (A. Smith) 23:07, 7 September 2007 (UTC)

How do I use the en-verb template for a verb ending in e? I've been specifiing the spelling for all the forms but I think there is supposed to be a shorter way. RJFJR 16:10, 21 August 2007 (UTC)

{{en-verb|lik|ing}} Rod (A. Smith) 16:15, 21 August 2007 (UTC)

Something like {{en-verb|normalizes|normalizing|normalized}} is the best way, so that the complete spelling can show up in a default search. There is an abbreviated form (described on template talk:en-verb?) that makes the template render correctly, but foils searches for inflected forms. --Connel MacKenzie 16:16, 21 August 2007 (UTC)

Although some may point out that for such problems, the MediaWiki software should change to search post-expanded text. I wouldn't want to change our editors' behavior just to allow MediaWiki's search function to find inflected forms. Rod (A. Smith) 16:22, 21 August 2007 (UTC)

Also note that Google searches do currently work for inflected forms and that MediaWiki search will eventually find the inflected forms, either after bots eventually enter all of the non-lemma forms or when MediaWiki search eventually includes post-expanded text. Rod (A. Smith) 16:27, 21 August 2007 (UTC)

Erm, what? We've gone back and forth on that concept for at least three years. Even when searches "work" on post-expanded forms (why doesn't it? It was very recent that we got ls2...but that doesn't make that not-so-logical leap either...likewise none of the three preceding search algorithms) it still makes similar challenges for offline analysis of the XML database dumps. The form of template use you indicate above was supposed to be deprecated ages ago. --Connel MacKenzie 16:31, 21 August 2007 (UTC)

I very much appreciate your desire to make offline XML dump analysis easier. Unfortunately, I am unfamiliar with the challenges you reference. Similarly, I was unaware that the usage pattern was ever proscribed. Is there some place I can read about either of those topics? Rod (A. Smith) 16:38, 21 August 2007 (UTC)

The offline analysis remains the least concern. The online search features can't have incredibly complicated language-specific stuff in them. They can't re-render pages recursively on each and every search.

Now, I may have mislead you with my wording above. I said was supposed to be deprecated so that I could use weasel words without saying anything absolute AND avoid finding all the conversations. My apologies for being snarky, but I really don't relish trying to find the dozens of relevant conversations using any of the search tools we have available now. The 2004/2005 conversations with Ncik, Polyglot, Eclecticology; 2004/2005/2006/2007 conversations with Hippietrail, DAVilla (aka davilla, etc.), more recent conversations with Robert Ullmann et al. No thank you sir. That is a lot to sift through. Oh, and the WT:BPA. Oh, and the WT:GP archives too. I suppose my talk page archives have a substantial amount too. I'm sorry, but I think my summary of the issues (below) is a bit more productive. --Connel MacKenzie 17:23, 21 August 2007 (UTC)

Yes, it is difficult to find such conversations, especially through the (speaking of “weasel words”...) MediaWiki search tool. Nothing official seems to have been been formally decided, but if we locate those conversations, we'll find that some editors strongly prefer English entries to spell out each inflected form. Rod (A. Smith) 17:59, 21 August 2007 (UTC)

Hmm.... if I participated in that discussion, it wasn't much. DAVilla 12:06, 23 August 2007 (UTC)

• Furthermore, the "spell-it-out-for-each-form" style has always been seen as less confusing, especially for newcomers. --Connel MacKenzie 16:33, 21 August 2007 (UTC)

  For me, an important consideration is the ability to review an entry to determine correctness. It easy to miss a doubled, missing, or substituted letter in a long "spell-it-out-for-each-form" list, so I prefer the shorter syntax. When we consider more highly-inflected languages, it becomes clear that wikitext for entries should not contain all of the inflected forms, but preferably a simple rule used to generate the inflected forms. Rod (A. Smith) 16:38, 21 August 2007 (UTC)

  For non-English I disagree. For English, I disagree. You can't review the spellings you are giving, if they are only rendered by arcane template magic. Browser-based spell-checks (Firefox's or my WT:PREFS spell-check) can check on input for the long form, but not for the arcane magic form. Likewise, newcomers can immediately read the long form. For doubled letters, the letter that is doubled is usually "L". Pipe-L-Pipe looks confusing...and confounds any external spell-checking.

  Now, for non-English, I think it is absurd to assume that English speakers/English readers/English contributors/English editors will immediately understand highly inflected forms. It is absolutely silly to think the core WMF software will (or should) behave the same as templates on one language Wiktionary. Having the spellings given unambiguously is, well, unambiguous. The benefits to Lucene search, Lucene2 search, MediaWiki search, MySQL search, Connel search, etc., are undeniable. The concept is for doing the search to each page only, not re-render each page in the database on every search. If you aren't searching the database contents, what exactly are you searching? If you aren't searching the text that can be edited, what exactly are you searching? --Connel MacKenzie 17:02, 21 August 2007 (UTC) (edit) 17:05, 21 August 2007 (UTC)

  Presumably that reasoning would apply to possessive singular and possessive plural forms of nouns, too. So, instead of typing “{{en-noun}}” in the wikitext for something regular like “word”, those editors would have us type “{{en-noun|sg=word|pl=words|posssg=word's|posspl=words'}}”. For verbs, such reasoning would have us type “{{en-verb|inf=talk|1sg=talk|2sg=talk|3sg=talks|pl=talk|prespart=talking|gerund=talking|simplepast=talked|pastpart=talked}}” instead of “{{en-verb}}”. Now, consider that compared with English, most languages have many, many more inflected forms of each word. (See the conjugation sections of hablar, говорить, and 말하다 (malhada, “malhada”) for examples.) Applying that logic to highly inflected languages would require an error-prone string of dozens of inflected forms in the wikitext for most of our lemma entries. To me, specifying each inflected form of a regularly inflected word in the wikitext would be absolutely silly and making such a preference our policy would be absurd. Rod (A. Smith) 17:59, 21 August 2007 (UTC)

  I said no such thing. They would be {{en-noun|words|word's|words'}} or {{en-verb|talks|talking|talked}}. Yes, I think the current approach used for most foreign language templates here is atrocious. But you are talking about the subsequent inflection table, while I am talking primarily about the so-called "inflection line." I.e. {{es-verb|hablar|hablando|hablado}}.

  <PERSONAL OPINION> The inflection table given for hablar is the product of a poisonous mentality. The inflection section (Conjugation) should have a series of templates that comprise it. </PERSONAL OPINION> Since they are formulaic, a subst'd template could be used to generate something like this:

  * {{es-verb-ind-pres|hablo |hablas |habla |hablamos |habláis |hablan}}

  * {{es-verb-ind-imper|hablaba |hablabas |hablaba |hablábamos |hablabais |hablaban}}

  * {{es-verb-ind-pret|hablé |hablaste |habló |hablamos |hablasteis |hablaron}}

  * {{es-verb-ind-fut|hablaré |hablarás |hablará |hablaremos |hablaréis |hablarán}}

  * {{es-verb-ind-cond|hablaría |hablarías |hablaría |hablaríamos |hablaríais |hablarían}}

  etc.

  Not only would doing so facilitate searches, it would also make it enormously easier to make corrections, especially for irregular conjugations.

  --Connel MacKenzie 19:23, 21 August 2007 (UTC)

  We obviously disagree about which approach is more error-prone. Rod (A. Smith) 19:31, 21 August 2007 (UTC)

  Do you not understand what I was saying about generating those from a subst:'d template? I don't see how that could introduce errors. But leaving complicated arrays of magic-inflections means mistakes creep in, when irregular forms cannot be corrected. --Connel MacKenzie 20:15, 21 August 2007 (UTC)

  The error-prone issue I mention is not with the step of generating the inflections, but rather with the step of reviewing them after they are generated. Errors can sneak into wikitext, perhaps because of a typo during the generation process or perhaps during an edit that occurs after the generation. Regardless of how the wikitext is produced, checking the latest wikitext for errors is easier when there is less text to check. Rod (A. Smith) 20:38, 21 August 2007 (UTC)

  I'm sorry, but to me, that makes no sense at all. You review what the entry looks like, either way. That is the same exact amount of text that you are looking at. When you notice an error, which style is easier to correct (particularly for newcomers)? The one where it is all occluded by template magic, or the one where each spelling rendered corresponds to text found in the corresponding place in the wikitext/entry? --Connel MacKenzie 22:05, 21 August 2007 (UTC)

  Yes, the first review is of the rendered text. That stage of the review typically reveals something to improve in the entry, so I click "edit". Then, the wikitext appears and I make the improvement. When I'm ready to save, if the wikitext says something like “{{en-verb|anthropomorphizes|anthropomorphizing|anthopomorphized|anthropomorphized}}”, it is difficult to notice the error because there is so damned much text. If it says, “{{en-verb|anthopomorphiz|ing}}”, it is much easier to notice the missing letter. Rod (A. Smith) 22:26, 21 August 2007 (UTC)

  But fixing the missing "r" (if missing in only one) is much easier when the rendered text corresponds to the wikitext! If the missing "r" is a product of an errant template, you can't do anything about it. --Connel MacKenzie 22:51, 21 August 2007 (UTC)

  Two things that mitigate the example you give above, for me: #1) my javascript auto-fills in the approximate inflected forms for me, #2) Firefox 2 puts a red squiggle under the form with the missing "r." --Connel MacKenzie 23:01, 21 August 2007 (UTC)

In rayo alfa, I tried putting in links to the individual words in the headword with "{{es-noun-m|sg=] ]|pl=]}}" (just like {{en-noun}} works, like ] ]}}"), but the result, as you can see, is the brackets showing up in the text. {{es-noun-f}} does this as well (e.g.: radiación alfa). Can someone fix that, so that you can link to multiple words with "sg="? Dmcdevit·t 21:31, 22 August 2007 (UTC)

Would it be possible to make a list of all the redlinks in the wiktionary? The problem is that the scan would have to be done after expanding templates since many of the templates add links. RJFJR 00:00, 26 August 2007 (UTC)

Special:Wantedpages lists the first 5,000 by number of links. Mike Dillon 00:11, 26 August 2007 (UTC)

The following is copied from WT:TR#Neo-Latin in Antarctica:

P.S. Category:Late Latin derivations says it belongs to Category:Latin derivations, which doesn't list it as a subcategory. What am I missing? —Ruakh_TALK 06:53, 27 August 2007 (UTC)

It shows up under "L", which isn't on the first page: . Looks like we also have Category:New Latin derivations. Mike Dillon 15:07, 27 August 2007 (UTC)

O.K., fixed, thanks! (And, that seems like a bug. The category page doesn't indicate in any way that the "previous page"-"next page" thing applies to subcategories as well as entries.) —Ruakh_TALK 16:20, 27 August 2007 (UTC)

Reading that was my first exposure to that MediaWiki bug, but now I see that Category:English nouns gets around the bug by prefixing its subcategory indices with an astrisk. Is there a Bugzilla issue about this? I'd rather not artificially prefix the category index of subcategories, but this bug is a significant navigation problem. Thoughts? Rod (A. Smith) 17:44, 27 August 2007 (UTC)

bugzilla:1211. Mike Dillon 19:17, 27 August 2007 (UTC)

Really? I've known about subcategories listing on following pages for some time. It's not a "bug" as far as I'm concerned, since subcategory lists can be very long. --EncycloPetey 00:12, 28 August 2007 (UTC)

I think that besides the perfomance concerns noted in the bugzilla ticket, there are indeed usability concerns about exactly how the interface would end up working. I don't know that I've seen an intuitive UI metaphor for dealing with paging through two distinct but related lists without overwhelming the user. Mike Dillon 01:22, 28 August 2007 (UTC)

AutoFormat usually does not make an edit for "minor spacing", spacing that does not affect rendering. This includes things like ] or iwikis out of place. If it makes an edit for some other reason, all that gets done.

I added a couple of lines of code to cause the edit to be made if the entry is new; see for example this edit. Mostly it is just adding some blank lines to follow our usual wikitext style. The edit summary is always just "minor spacing".

Opinions? easy to turn off if it is felt that it just isn't worthwhile. Robert Ullmann 19:16, 27 August 2007 (UTC)

I think it's a good idea; if the article's creator is watching the page, they'll learn a bit about our formatting, and if not, no biggie. —Ruakh_TALK 21:44, 27 August 2007 (UTC)

I agree. Does it capitalize Category also? Again, not a requirement, but given past capitalization issues, it might be worth considering. --EncycloPetey 00:09, 28 August 2007 (UTC)

It changes ] to ] but not birds to Birds of course. Fiddly little stuff. Mostly blank lines. Editors do learn from AF edits to watchlisted entries, but this may be just too minor? Better if it is only more important stuff? Robert Ullmann 00:19, 28 August 2007 (UTC)

No, those aren't too minor. The spacing can have an effect on iw links involving colons, and capitalization can affect template calls, so teaching the newbies to notice their capitalization and spacing is a Good Thing. --EncycloPetey 00:39, 28 August 2007 (UTC)

Sure, I support that. You could also tag them with {{subst:nolanguage}} and {{subst:notenglish}} and whatever else you think to add. Frankly, I get annoyed when AF says it would have done something and it doesn't do it. It was for clarification as it applies to bots like AF that I was trying to pin down the levels of headers. What was the objection to a bot flag, anyway? I think not listing AF in WT:WL addresses any of those concerns.

The only reason that it doesn't correct headers is that it has a flag in the code (named "Connel" ;-) telling it not to. Otherwise it would be following ELE. The vote for bot status passed; it hasn't been flagged because it appears that people like seeing it in RC without "show bots", it doesn't make large numbers of changes that flood RC, and never more than one every 70 seconds. It is whitelisted. It does add "nolanguage" but not very often; it only looks at entries after the edits have been patrolled. (Else it would be "fixing" vandalism all the time, and making it annoying to roll it back! ;-)Robert Ullmann 12:34, 1 September 2007 (UTC)

Aside from no-ops there are "very" minor edits, like wikifying a language name, that I would distinguish from corrections like proper spelling. While writing a new entry often involves standind back and eying it with pride, the users who add content such as translations en mass are less likely to watch it. I'm wondering if you could avoid making very minor edits until there were a sufficient number, or until some correction is needed, so as to prioritize the work that AF does. DAVilla 19:27, 31 August 2007 (UTC)

That was its behavior before, I've just flipped it back. (one line of code anyway) Any correction that affects rendering it will do. Robert Ullmann 12:34, 1 September 2007 (UTC)

There is some intermediate behavior, like fixing the capitalization of Category, or taking the extra spaces out of header lines, but not just adding a single blank line, that could be arrived at .... Robert Ullmann 12:43, 1 September 2007 (UTC)