Wiktionary:Grease pit/2007/July

(diff) links not diffing anymore

http://en.wiktionary.org/w/index.php?title=Cracker_Jack&diff=next&oldid=2560519

Did anyone notice when this stopped working? --Connel MacKenzie 04:18, 1 July 2007 (UTC)

No, though about two days ago I noticed a period when diff versions weren't displaying correctly for a time. It might be related. --EncycloPetey 07:13, 1 July 2007 (UTC)

MediaWiki (itself) seems to have a 'diff.js' which is overriding my javascript. I'll rename it to have a wikt* prefix at somepoint, when I'm next in a javascript mood. --Connel MacKenzie 19:02, 1 July 2007 (UTC)

Apparently it was this: http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=23483. I've filed bugzilla:10466 for it. --Connel MacKenzie 03:24, 5 July 2007 (UTC) Unfortunately, bugzilla:7071 seems relevant. In trying to tighten-down edits, it looks like 'diff' was collateral damage. --Connel MacKenzie 03:33, 5 July 2007 (UTC)

Wikinews

What's happened to Wiktionary:Words in the News? It looks awful! SemperBlotto 07:00, 1 July 2007 (UTC)

Looks like it was affected by the great template merger of 2007. However, I've looked at the older version of the {{wikinews}} template and can't figure out how it ever managed to work the way it did in the first place. --EncycloPetey 07:12, 1 July 2007 (UTC)

It used to be a simple link. Now it has a fancy box. Is it OK to revert the change (this will remove the added "lang" parameter)? Or can we have a simpler version and change all the occurences in Wiktionary:Words in the News (the only place it is used?) SemperBlotto 07:28, 1 July 2007 (UTC)

I don't understand what the point of the previous template was at all. It was using {{wikinews|x}} to produce [[wikinews:x|]], which is, well, the same number of characters (more if you include pressing [shift]). That page being messed up is my fault, it's just because I thought I had subst'ed all uses of the old template before moving the new one there, but I guess I missed some pages. I'll fix it; from now on we only need bare links, not templates, for an inline link to Wikinews like those were using. Dmcdevit·t 07:40, 1 July 2007 (UTC)

OK, but now each of the entries in Words in the News is double the length. So now what is the function of the {{wikinews}} template? Wikinews is never going to have articles whose title is a single word or simple phrase - they are always sentences. SemperBlotto 08:42, 1 July 2007 (UTC)

What do you mean that they are double the length? It only shows up that way in the edit view, right? {{wikinews}} is a box like the rest of the sister project templates now. See freedom fries for an example. Dmcdevit·t 08:48, 1 July 2007 (UTC)

That seems to use {{wikinewspar}}. I have no problem with that. SemperBlotto 08:55, 1 July 2007 (UTC)

Dmc, Look at what Words in the News has as its format. One used to be able to type:

* [[regime]] - June 29 - {{wikinews:International Red Cross condemns Myanmar regime}}

but now one has to type:

* [[regime]] - June 29 - [[wikinews:International Red Cross condemns Myanmar regime|International Red Cross condemns Myanmar regime]]

This makes for a textline nearly twice the length it used to be. It is 'not the same number of characters to write or edit, which is Semper's point. As far as I am aware, Words in the News is the primary (if not sole) place that the {{wikinews}} template was being used. Because of the nature of news articles, it would never be linked from an entry. So what is the point of converting the template to a box and creating all the extra typing time for people who edit Words in the News? No one ever uses that link as a box anyway! --EncycloPetey 21:00, 1 July 2007 (UTC)

Oh! I see what you are saying, but I think you're looking at it wrong. While the output text is longer, what you type is the same, as I said. You don't have to type "[[wikinews:International Red Cross condemns Myanmar regime|International Red Cross condemns Myanmar regime]]", you only have to type "[[wikinews:International Red Cross condemns Myanmar regime|]]". As for the box, I think it is probably rare, but the article I linked above, freedom fries does use it, as does penis transplant. The point it that the previous template was pointless, as it was the same length as just using a raw link, so I just moved the existing box on top of it, so that the Wikinews box was named in line with all the other projects. Dmcdevit·t 23:46, 1 July 2007 (UTC)

notes on related terms collapsible tables

I added a note= parameter to {{rel-bottom}} and to {{rel-top4}} so that one can add a note inside the collapsible box at the bottom (or top) of the table. See en- -en for an example. Tell me what you think? I can propagate the changes to the others if people like it. Robert Ullmann 15:11, 1 July 2007 (UTC)

I like it. —Ruakh_TALK 16:07, 1 July 2007 (UTC)

Could you please pick a different example? Perhaps one not nominated for deletion? --Connel MacKenzie 19:03, 1 July 2007 (UTC)

I thought the form of the table was pretty much independent of the content ;-)

Uhhh... Why is the section labelled Related terms, but the note in the table says Derived terms. Those two labels mean very different things here on Wiktionary. --EncycloPetey 16:54, 2 July 2007 (UTC)

It is just a form(at) example; the entry has problems (RfD being the least of them ;-). Robert Ullmann 17:02, 2 July 2007 (UTC)

If this were to be added into trans-top, we would have the useful construction: {{trans-top|translations to be checked|note={{checktrans}}}} ... Robert Ullmann 11:41, 2 July 2007 (UTC)

I would prefer to clear Category:Translation table header lacks gloss and simply use the construction {{trans-top}} which is an incorrect formulation anyway as it lacks a gloss, and isn't the lack of glosses what TTBC is all about anyways? But I don't see anything inherently wrong with having the note option, which might be useful for a see-also, e.g. on uncle, or something similar. DAVilla 16:00, 2 July 2007 (UTC)

See {{ttbc-top}} which an IP-anon user created and used a couple of times; seems a possible idea too. I don't really want to overload trans-top with no parameters, because there are many words with only one (possible) definition, lacking the gloss doesn't mean it should get treated as TTBC. Robert Ullmann 17:02, 2 July 2007 (UTC)

Way of topic now, but I thought the vote for TTBC discussed that exact situation at length? I was pretty sure that missing glosses were indeed supposed to be treated as errors. --Connel MacKenzie 17:09, 2 July 2007 (UTC)

Changed behavior

Somthing is wrong with the trick we used to use that involved inserting <noinclude></noinclude> to keep an expression from being evaluated.

{{<noinclude></noinclude>temp|wikipedia}}

This evaluates to a link:

{{wikipedia}}

That means the string {{{temp|wikipedia}}} is being evaluated, when before it was left unevaluated. It's such a subtle change that there's no knowing when it happened. I have no idea if it's actually broken anything, but I know at least I had used it in various templates in the past as a form of error-checking. Because I do much less error-checking in templates now, in order to keep them simple, it's not likely to be found in many places. But it's a little troubling. I'm not sure if there's any way now whatsoever to determine if the parameter {{{lang}}} is equal to the expression {{{lang}}}. DAVilla 03:48, 4 July 2007 (UTC)

Actually yes there is, but you have to call another template and change the name of the paramter. How disturbing! DAVilla 03:51, 4 July 2007 (UTC)

Moved pages disappear from watchlist

That is, when I move a page to a new title, it mysteriously disappears wrom my watchlist. The page itself, however, still has "Unwatch" link at the top. Even if I try to 'Unwatch' and then 'Watch' it again, the page is still out of my watchlist. Why is that? Dart evader 05:39, 4 July 2007 (UTC)

Another buggy template

Something is wrong. See the entry for concordance, definition 2. It is coded as:

# {{context|grammar|obsolete}} [[concord]]; agreement.

But it displayes as:

2. (grammar, obsolete[[Category:|concordance]]) concord; agreement.

I'm not sure which template is the culprit. --EncycloPetey 06:11, 4 July 2007 (UTC)

The same things is happening with {{pejorative}} (e.g at frog) and {{archaic}} (e.g. at beef). It looks like it is something to do with {{context/categorize}} and/or {{context/cat}} which are called by some context templates. user:DAVilla was editing them early this morning (UTC) so I've left a note on his talk page directing him to this discussion. It isn't clear from the edit summaries what the purpose of the edits to these protected templates is/was, but I think the changes should be rolled back for now - I'd do this myself but I'm not an administrator here. Thryduulf 18:15, 4 July 2007 (UTC)

I'm looking at them. It looks like it could be a very minor error, so please don't roll them back yet. I'll do that if I can't find what's wrong quickly. DAVilla 18:19, 4 July 2007 (UTC)

I've easily commented the bug out of the loop to give me time to experiment on the side. Everything should look fine now, with the minor exception that {{idiom}} and maybe a few other full-language name categorizations aren't shown. DAVilla 18:30, 4 July 2007 (UTC)

Okay, the problem has been corrected. It was an odd case I hadn't considered of old code merging with new code that was introduced 20 hours ago. Strange that it takes so long to show up. DAVilla 19:02, 4 July 2007 (UTC)

Not quite! the {{archaic}} is displaing as:

  3. (archaic}}

-->, countable, plural: beef or beeves) A generic term for a cow or bull.

{{colloquial}} and {{pejorative}} are displaying the same, except for ")}}" instead of "}}". I'm guessing this is a problem with a comment code syntax. see frog, beef and permanent dirt for examples - note that you might have to hard-refresh the page for changes to appear. Thryduulf 20:29, 4 July 2007 (UTC)

Sheesh, even my fix was buggy. Screw it, I've just reverted it all. See my talk. DAVilla 20:32, 4 July 2007 (UTC)

Use of labels outside definition lines

All the headaches today with context labels aside...

A while ago I rewrote {{context}} from a less hackneyed and more software engineering sort of perspecive, but I still haven't implemented it. I've had a long break from it since then, and now I'm looking back at my work and thinking that, although very clear and deliniated, it's really much more complicated than it needs to be, even more complicated than the original {{cattag}} which had so upset all the technical folks around here. I like some new aspects in implementation for language-related issues of categorization, which I've tried, unsuccessfully, to transition to the current system. Right now I'm ready to abandon both.

The reason is this: Context labels are increasingly becoming used outside of the definition lines. {{context2}} fixes this by allowing for either {{context|...}} or {{label|...}}, the latter not categorizing anything, and assigning a default for each label when used {{alone}}, either categorize by default or don't. The problem is that there's no clear deliniation of what should be categorized context and what should be an uncategorized label. Regional templates? Register? Adding the complexity of the templates to the equation, it's time for something simpler.

What I propose is this. Instead of allowing a label to be used {{alone}}, we should require that one of {{context}} or {{label}} be called for each and every label. Or if you prefer labels without the parens, we could leave {{label}} out of it, and have the labels used {{alone}} when categorization is to be avoided. That means we wouldn't be able to use {{US}} at the beginning of definition lines, that we would require {{context|US}}, but at least that would force the deliniation of what is to be categorized and what is not. It also makes the templates A LOT simpler. DAVilla 21:02, 4 July 2007 (UTC)

I'm not sure I've understood all of this. Are you suggesting that on an entry like shunter, the {{UK}} used in the definition lines would categorise it in Category:UK because it is included through a {{context}} template; but that the {{US}} used in the synonyms section would not place the page in Category:US as it is used alone? If so then this seems like a very sensible suggestion. Presumably we could employ a bot to change all extant uses outside of {{context}} in definition lines to use the context tag? Thryduulf 22:03, 4 July 2007 (UTC)

I haven't thought through all the possible ramifications (if it's even possible to do), but this certainly sounds like something worth pursuing. I've wanted to use {{UK}} and {{US}} to simplify things for the pronunciation section, but doing so would categorize the page as "US" or "UK" English as an undesired side-effect. A change in the way they're implemented could allow their use in front of regional pronunciations. I'll see if I can draft up the ideas I've been having for templates in the pronunciation section. --EncycloPetey 22:09, 4 July 2007 (UTC)

Yes, that's correct. In terms of coding for me at this point, the details don't matter too much, as they can be dealt with quite flexibly. What I want to know is if anyone deems such a bot correction or the necessity of context| on the definition line undesirable. DAVilla 02:04, 5 July 2007 (UTC)

Are you saying this is now going back to the original {{cattag}} that would force the category? If so, then hurray! --Connel MacKenzie 02:53, 5 July 2007 (UTC)

Not quite. {{context}} would actually be required for the definition line, where {{cattag}} was optional. And otherwise not too much would change. The content of label templates would remain largely the same, whereby the relevant categories are prescribed therein, and the system in place of resolving them via redirects would remain. But there wouldn't be any "tricky code" involved in doing so. DAVilla 11:39, 5 July 2007 (UTC)

Yippie! Well, IIRC, the original cattag did have that same requirement, so it's cool with me! --Connel MacKenzie 19:01, 5 July 2007 (UTC)

I'd suggest going the opposite way, and not using {context} directly in entries at all; using context-class templates on the definition lines, and using either (''text'') or preferably {{italbrac}} else to get the customizable typography. (shouldn't the pronunciation tags be things like GenAm and RP rather than US and UK?)

(aside) The present context template is an order of magnitude more complex than it needs to be. I commented, rudely, on DAVilla's talk page that he didn't know enough; I apologize again. I'll try be more polite now: "tricks" like trying to differentiate between {{lang}} as a stirng and as an expression (see a couple of sections above) are very poor engineering practice; I warned you about that one and you assured me it was okay. Overloading detection of recursion on a call with processing the lang parameter with #ucfirst tricks etc... the thing is that each time you get bug(s), you patch more and more code in instead of backing out and simplifying. I'll explain what it should, IMHO, look like:

Each context class template should contain: [(name) is the template name]

{{context/cattag|(name)|lang={{{lang|}}}|sub={{{sub|}}}|{{{1|}}}|{{{2|}}}|{{{3|}}}|{{{4|}}}
    |{{{5|}}}|{{{6|}}}|{{{7|}}}|{{{8|}}}|{{{9|}}}}}

If the tag and the cat are different:

{{context/tag|(name)|lang={{{lang|}}}|sub={{{sub|}}}|{{{1|}}}|{{{2|}}}|{{{3|}}}|{{{4|}}}
    |{{{5|}}}|{{{6|}}}|{{{7|}}}|{{{8|}}}|{{{9|}}}}}
{{context/cat|(category name)|lang={{{lang|}}}}}

(A POS-class template uses context/poscat, which will call {{language}} or whatever we are doing in future)

Modifiers ("mostly", "chiefly", etc.) are context templates (so it is easy to add them), using {{context/mod}} the same way.

If context/tag is implemented properly, a modifier can just use {{context/tag|(modifier)|_|lang= ... instead of having a separate context/mod template. Robert Ullmann 16:24, 6 July 2007 (UTC)

Context/tag etc then calls the additional templates with sub=sub. If sub is blank it generates (, when {{{2|}}} is blank generates tag and ) and stops. Else generates the tag, comma, and calls {{{{{2}}}}} with sub=sub, lang={{{lang|}}}, and params 2, 3, 4 ... (also tests if {2} exists as a template. If not, just calls context/tag with it and sub=sub! And looks for "and" and "or" and "_", which get handled specially)

Context itself tests to see if the first param is a template, and calls it with sub blank, or else calls context/tag with sub blank.

Now we can write:

# {{biology}} def...
# {{biology|of a mammal}} def ...
# {{slang|US}} def...
# {{US|and|UK}}
# {{context|of a musical instrument}} def... (still works ;-)
# {{vulgar|slang|lang=es}}
etc.

Looks so much better, and the implementation is simpler. And it is easy to get from here to there if you change the specific templates first, the existing context will ignore the extra stuff. Robert Ullmann 14:22, 6 July 2007 (UTC)

response

Yes, that is a cleaner solution than what exists presently, pushing off the work of recursion/iteration, of processing additional labels, to each of the label templates. I avoided it initially because I didn't want to have the preset limit of {{context}} defined in each and every context label, rather than within {{context}} itself. Your solution also uses a separate parameter from language to indicate what is a substitution and what is a direct call. That in and of itself would have been a cleaner implementation of the process currently in place.

Aside: If my version of {{cattag}} was complex, it was this change, the overloading of a {{{lang}}} tag at the time of transition to a second version at a new {{context}}, that was over the top. Charging ahead with this solution is what I most regret. I did so at the time due to an announcement being misworded and misplaced in the Beer Parlour rather than here, which resulted in another user pushing some of the changes forward. It was a mistake not to revert his changes to allow for the feedback of yourself and others first, as intended.

However, I do not regret having made the initial changes to {{cattag}}. Despite the complex code, it was a more consistent system of labelling and categorization than existed at the time.

Your solution therefore has the two solid improvements above, and the one minor drawback. It also adds the ability to exclude context| from multiply tagged definitions. However, it doesn't address the new issue of labels used outside of the definition lines, of differentiating which tags should be categorized. Besides a consideration of uncategorized labels, it is precisely the tricky code in your aside, such as the detection of recursion, that I am trying to eliminate. In fact, the code I am proposing would be even simpler than what you have outlined. The context templates would, in essence, contain:

''label name''{{context/cat|category name|lang={{{lang|}}}}}

which I would like to implement as:

<noinclude>{{checklabel}}</noinclude>{{content|label name}}{{context/cat|category name|lang={{{lang}}}}}

The implementation of this, at the time {{context}} is replaced with new code, could depricate {{context/tag}} by simply redirecting it to {{content}}. {{content|label name}} would simply wrap the label name as the contents of a bracketed expression, nothing more. It eliminates the recursive {{context/tag}} of both the current solution and your proposal, and therefore the extra parameters of that call. To categorize the page, {{context/cat}} would still be required. There is a new version of this at {{categorize}} that was written for the unimplemented {{context2}} but is so general that it could be easily adapted to either your solution or mine.

Besides having the advantage of complexity reductions in your solution, or even further simplification as above, there are three other advantages of this solution over yours. One advantage is minor in that it does not pre-specify a limit on the number of context paramters in each and every context label. Another advantage is that the context labels would not need to be rewritten, but I don't think that should be taken into consideration. The major advantage is that it allows {{context}} to default the {{{lang}}} parameter to en rather than doing so in {{context/cat}}. Doing so would allow for the context labels to be used directly on a page without categorization, or from a wrapper tamplate such as {{label}} that does not pass a language parameter.

The major disadvantage of this system is that it would require context| to be used in the definition line regardless of the label or labels. That is why I posed that very question here. DAVilla 11:55, 8 July 2007 (UTC)

Changing username?

How do I change my user name in Wiktionary.org? In Wikipedia, I could type "change username" in the search-box, but that doesn't work here. [[User:Mortsggah|Mikael Häggström]] 05:06, 6 July 2007 (UTC)

Please make your request at Wiktionary:Changing username and a bureaucrat will respond to it. :-) Dmcdevit·t 09:11, 6 July 2007 (UTC)

Requesting help at Marathi Wiktionary

Dear Wiktionarians,

At Marathi Language Wiktionary even after addition of new pages stats are not getting updated , What may be the reason and what corrective action does it need. Please do guide.

Regards

Mahitgar 16:13, 6 July 2007 (UTC)

The MediaWiki software counts "real entries" as those that contain "[[" and are in the main entry namespace that have more than 30 characters. If you don't include wikilinks in your entries, they probably aren't counted. --Connel MacKenzie 18:10, 6 July 2007 (UTC)

Thanks Mr.Connel MacKenzie , we have updated monobook at Marathi Language Wiktionary , hence forward you won't have deficulty in writing in english language there.

We do need one more help request at Marathi wiktionary, when we could not recreate trans-top range of templates with its show and hide facility.Can you guide us in this respect also.We are trying that template on Marathi Wiktionary atसाचा:भाषांतर-माथा if needed please see mr Wiktionary:CSS

Thanks and regards

Mahitgar 16:07, 8 July 2007 (UTC)

Of course you have to copy over mid and bottom as well. Those templates rely on certain CSS classes called NavFrame, NavHead, and NavContent (among others, apparently) in MediaWiki:monobook.css. Pretty tricky stuff though, be careful! DAVilla 01:23, 9 July 2007 (UTC)

Wrapping collapsible boxes

Does anyone know how to fix User:DAVilla/trunk so that the boxes open and close naturally? I modified the trans-top code to exclude clearing the margins, but that only seems to affect the title box in blue. For me, the yellow boxes are jumping down below the images. DAVilla 01:09, 9 July 2007 (UTC)

Oh, I think it's in the MediaWiki:monobook.css file I found in repling in the section above. It has a class called "div.NavEnd" containing "clear: both;". Is there any way I can make my example look right without editing the global file? In other words, can I reproduce the .css information in User:DAVilla/bottom et al.? DAVilla 01:28, 9 July 2007 (UTC)

I know next-to-nothing about css, but in the absence of anyone more knowledgeable repling, it might be worth trying to modify your special:mypage/monobook.css. Thryduulf 09:59, 9 July 2007 (UTC)

Right, good idea to test it first. And guess what? The change doesn't seem to fix anything. I have no idea how to make the page look right. Use fewer boxes maybe, but.... DAVilla 05:52, 10 July 2007 (UTC)

Waitasec - what's the question? How to use {{-}}? --Connel MacKenzie 05:22, 13 July 2007 (UTC)

No, I don't want the boxes to be the full width. That would produce too much white space. I want them to wrap around the images. Right now they're okay closed, but they goof when they're opened. DAVilla 01:08, 15 July 2007 (UTC)

You could use tables - see Maltese cross and ellipsis for how this can work. Thryduulf 01:15, 15 July 2007 (UTC)

Please don't do that. Evar.

1. Images don't get size specifications on en.wiktionary.
2. Images don't get placement specification on en.wiktionary.
3. Tables aren't supposed to span headings. (Section editing also malfunctions with that.)
4. Random tables with magic-number width percentages are a Very Bad Thing.
5. The concept of "web-designer cum-wikisyntax guru" is overrated. The idea is to work our way away from page layout atrocities.
6. Style designs for specific pages needs to be eliminated whenever encountered, for other skins to work right.

etc. --Connel MacKenzie 01:57, 15 July 2007 (UTC)

Painting

Hello,

We purchased a painting in Positano, Italy. It is a vegetable water color on material made to look like a tapestry. The subject matter is a harvest scene. The artist is signed Giannina. It was suppose to be 17th-18th Century.

Does any one who this artist is?

Thank you,

Liz

<email address removed>

Hello, this page is for discussion of technical matters (templates, etc) on Wiktionary, a Free content dictionary. If you ask your question again at the Wikipedia Reference Desk someone will more likely be able to help you. Thryduulf 19:15, 14 July 2007 (UTC)

aleph-null

I've copied the א symbol and I have the ₀ code but I can't get ₀א to look like $\aleph _{0}$ in the link. Somehow I got it to look right here: ₀א but then when I literally just COPY and PASTE the code it always comes out reversed: ₀א  !! What the...?!? DAVilla 01:23, 15 July 2007 (UTC)

Wow, that's pretty cool - the aleph is a RTL character, forcing the next character to appear to the left, and the zero is a LTR character forcing it to stay in place so you can't cut-n-paste either one into the opposite spot. 0א even as http://en.wiktionary.org/w/index.php?title=%D7%900 doesn't work as expected. Is there a RTL zero you can use? --Connel MacKenzie 01:47, 15 July 2007 (UTC)

If it’s only the aleph that you need, you could use ℵ₀, which is a left-to-right symbol. Otherwise, you can insert the "left-to-right" code, thus א‎₀ or א₀. —Stephen 16:46, 16 July 2007 (UTC)

Great, thanks! DAVilla 03:22, 22 July 2007 (UTC)

Show/Hide default

I would like the default (for me) to be Show rather than Hide - because I like to see the information. Is that at all possible? Failing that, could a particular table stay at Show when I click on a link and subsequently return? SemperBlotto 07:30, 16 July 2007 (UTC)

I’m with you. Everything hidden causes a lot of problems. Before I can search for a term on a page, first I have to "display" all of the tables. It’s frustrating. —Stephen 16:19, 16 July 2007 (UTC)

Yes, WT:PREFS has that option. "Alternatively, leave the translation sections (Nav boxes) expanded - Default is to leave them collapsed". Is it not working for you? --Connel MacKenzie 19:17, 18 July 2007 (UTC)

No it isn't. (I use vanilla Windows/Internet Explorer and the sysop preferences work OK) SemperBlotto 07:34, 20 July 2007 (UTC)

Hmmm. Doesn't seem to be working in FF anymore, either. It looks like it isn't honoring the cookie restructuring. I'll try to get this straightened out later today. --Connel MacKenzie 17:20, 20 July 2007 (UTC)

It still does not work for me. It appears nobody has been able to fix this. —Stephen 15:11, 24 July 2007 (UTC)

The cookie for "all" settings had been renamed in only one place. This should work now. Try Ctrl-F5 to refresh (on IE.) You may also need to toggle that one setting (once more) on WT:PREFS. --Connel MacKenzie 16:02, 24 July 2007 (UTC)

Well done - it works fine now. SemperBlotto 16:27, 24 July 2007 (UTC)

For Firefox, toggle the WT:PREF off then on, then refresh with Ctrl-Shift-R. --Connel MacKenzie 15:18, 25 July 2007 (UTC)

Context label problem

Editing a French idiom, the evil parenthesis displayed for me. So I tried to fix the {{fridiom}} to do it correctly: [1]. But it seems to have lost the category, as a result? Why isn't this working? --Connel MacKenzie 19:17, 18 July 2007 (UTC)

Oddly, a similar change to {{frslang}} did work. --Connel MacKenzie 20:02, 18 July 2007 (UTC)

It looks like the problem is with {{idiomatic}}: it includes {{context/cat}}, but doesn't give it any numbered parameters, instead giving it two named parameters (named noprefix and lang). {{context/cat}} does nothing unless it has at least one numbered parameter, and does nothing at all with a noprefix parameter. (My guess is that the value passed in as noprefix is meant to be the sole unnamed parameter, but I'm loath to mess with it without being more sure.) —Ruakh_TALK 20:50, 18 July 2007 (UTC)

The noprefix parameter is unimplemented. I must have forgotten to roll back changes to {{idiomatic}} a couple of weeks ago. I'll do that now. DAVilla 03:10, 22 July 2007 (UTC)

Alternative plurals

For a plural that is clearly an alternative form (e.g. octopodes, abaci) or a plural of an alternative spelling (e.g. butterknives instead of butter knives), ought there be a template for {{alternative plural of|}} or {{plural alternative spelling of|}}? Or should we continue using the individual templates in such entries? bd2412 T 21:49, 19 July 2007 (UTC)

Well, we could just use {{alternative spelling of}} and list the standard plural as the argument, then add {{p}} on the inflection line to signify that it is a plural. --EncycloPetey 22:31, 19 July 2007 (UTC)

For the second scenario, I can’t see how that’s necessary — the word in question is the plural / inflected verb / adverbial / or some other (as this proposal would also logically apply to them and not just to nounal plurals) form of the word which is itself an alternative spelling of some other word. What good does it do to duplicate that information in the entries for the inflexions?

For the first scenario, a lot more conflict is avoided and a lot more consistency is achieved by discussing the respective merits of a word’s various plurals in the singular entry’s usage notes section. Just like all {{alternative spelling of}} entries, an {{alternative plural of}} entry will carry that implicit disapproval of the “variant form”. If such disapproval is warranted, it can be explained in the singular form entry’s usage notes section, rather than being expressed vaguely by unnecessarily dividing plural noun entries into two, unequal classes. † Raifʻhār Doremítzwr 22:43, 19 July 2007 (UTC)

For the first scenario, I agree with † Raifʻhār Doremítzwr; I've argued multiple times that labeling a spelling an "alternative" spelling is in no way a derogation or diminution, but simply a practical way of organizing Wiktionary and avoiding duplicate entries that we can't possibly keep synched. Marking a plural as an alternative spelling flies in the face of this; we gain nothing, pragmatically speaking, by labeling abaci an alternative spelling of abacuses instead of labeling it a plural of abacus. (Of course, if it's a rare or non-standard or region-specific plural of a word whose singular doesn't have these properties, then we should use the proper sense labels.)

For the second scenario, I think something like this:

{{plural of|[[butterknife]]|nodot=1}} ({{alternative spelling of|[[butter knife]]|nocap=1|nodot=1}}).

which produces this:

Plural of butterknife (alternative spelling of butter knife).

might work; what do you think?

—Ruakh_TALK 03:28, 20 July 2007 (UTC)

Some alternative plurals are clearly unusual - like octopodes. I see no harm in labelling them in their entry as 'alternative', although octopodes is really not an 'alternative spelling' of octopi or octopuses. For true alternative spellings - butterknife, for example, a single template could be fashioned to create the above outcome - in fact, a single template could be created to call both of the other two in the format presented. I know that templates calling other templates is not preferred, but would it be problematic here? bd2412 T 04:05, 20 July 2007 (UTC)

Maybe I'm off-base here, but to me when people complain that we mark demeanour an "alternative spelling of" demeanor, they're being silly: we're not saying that the British spelling is inferior to or less important than the American spelling, we're just putting the information at one spelling and linking to it from the other (this being a more workable solution than trying to keep the two entries in perfect synch). But we don't derive this benefit from labeling octopodes an "alternative" plural of octopus; the only reason to do so is if we've decided that "alternative" really does mean something like "secondary". And that's not a decision I'm O.K. with, because it would mean those complainers are right, and we'd have to stop using "alternative" to describe spellings used by half the English-speaking world. Do you see what I mean? (And yes, sorry, I meant that {{alternative plural of|[[butterknife]]}} could use {{plural of}} and {{alternative spelling of}} to produce something like {{plural of|[[butterknife]]|nodot=1}} ({{alternative spelling of|[[butter knife]]|nocap=1|nodot=1}}).; sorry for not being more clear.) —Ruakh_TALK 04:29, 20 July 2007 (UTC)

Works beautifully, thanks. bd2412 T 05:10, 20 July 2007 (UTC)

Comparative difficulties

We 've run into a problem in Latin (which may also affect Ancient Greek and other highly inflected languages). In Latin, comparatives decline as you can see below:

Template:la-decl-3rd-comp

That's the declension table just for the comparative adjective. The positive and superlative also undergo inflections, and Latin adjectives frequently have a different inflectional pattern in each form. This can't all be shunted to the positive lemma, because the meaning of a Latin comparative adjective is not the same as expected in most other languages. The comparative certior does not simply mean "more certain", but can also mean "rather certain", and may carry other specific meanings besides. Discussion on About Latin has tenatively agreed that the masculine nominative singular of the comparative and superlative adjectives should be treated as a sub-lemma, with declension tables, definition, etc. However, we still want to link back to the positive and say "this is a comparative of X".

So, I would like to see the {{comparative of}} template revised, or an alternative form of it developed. Using this template as currently set up will automatically categorize the word, but the category is wrong for Latin. For certior, for example, using the template as {{comparative of|[[certus]]|lang=Latin}} puts the entry in Category:Latin adjective comparative forms, which is the wrong category. The form certior is not a form of the comparative adjective; it is the comparative adjective and should be in Category:Latin comparative adjectives or possibly Category:Latin adjective comparatives. It is the inflected forms of the comparative sub-lemma that should be categorized as "forms"; no lemma pages should ever be placed into a "forms" category.

We run into a second problem in that the template is not equipped to handle comparative forms of adverbs. It assumes automatically that the word is an adjective. While this is a fine assumption for English, it doesn't hold in other languages such as Latin. Could the template be revised to accept an optional "pos=adverb" which adjusts the default POS? --EncycloPetey 22:46, 19 July 2007 (UTC)

When you figure out how the sub-lemma thing should work, I'll be quite grateful; Hebrew needs the same thing (for participles, which are verb forms but have their own declensions, and for the minor conjugations, which are just passives of two of the major conjugations). —Ruakh_TALK 03:39, 20 July 2007 (UTC)

Why aren't you just adding the category:Latin adjective comparative forms to those entries, and leaving the extra category alone? Not listing those adjectives in both categories means that English speakers/Latin learners will have a more difficult time navigating through categories. Our target audience is not the linguist who is already fluent in Latin. --Connel MacKenzie 10:36, 20 July 2007 (UTC)

Because we don't want that category. The problem is that the template puts it in whether we want it or not. --EncycloPetey 10:48, 20 July 2007 (UTC)

And why shouldn't lemmas appear in other categories, anyhow? I fail to see the harm, and I know of no such policy, nor any such guideline. --Connel MacKenzie 10:36, 20 July 2007 (UTC)

The root lemma forms are always placed in a category that does not contain "forms" in the name -- so the lemma of a verb will appear in Category:Spanish verbs or Category:Latin verbs -- but the various inflected forms appear in the "forms" category. That's the way I've seen every category done in inflected languages that I've looked at. It may not be a policy or guideline, but it is current practice. What you are telling me to do is to change the practice. It would be like suggesting having all the singular and plural English nouns in the same category. We don't do that. Or like putting all the various inflected forms of English verbs into a single category. We don't do that either. So why then should we do it in non-English languages? Hmm? --EncycloPetey 10:47, 20 July 2007 (UTC)

No, I have misunderstood your complaint and would like clarification. Looking at the English example nastier, I guess I see the problem. But that is more typically overcome by simply saying # {{italbrac|[[comparative]] of}} ... then adding the correct category below. --Connel MacKenzie 17:40, 20 July 2007 (UTC)

But it's silly to have to use that workaround for every comparative adjective in Latin. --EncycloPetey 19:50, 20 July 2007 (UTC) Using {{italbrac}} as a workaround doesn't work. See minor to see why -- we get those blasted parentheses, which arent' wanted in this case. --EncycloPetey 20:10, 20 July 2007 (UTC)

By the way, {{comparative of}} currently takes a POS parameter (pos presumably having been avoided as it would have looked like "positive"); as for the category issue, how about if it took an is_lemma boolean parameter that caused it to add things to [[Category:{{{lang|English}}} comparative {{{POSes|{{{POS|adjective}}}s}}}]] instead of to [[Category:{{{lang|English}}} {{{POS|adjective}}} comparative forms]]? —Ruakh_TALK 14:22, 20 July 2007 (UTC) Edited 20:06, 20 July 2007 (UTC) to escape markup.

Thanks, I didn't know that about the POS argument. Your categorization suggestion might work for English, but it doesn't help with Latin. --EncycloPetey 19:50, 20 July 2007 (UTC)

Me stupid, I failed to escape all my markup. (That was the only problem, yes? There's no deeper reason it won't work for Latin, is there?) —Ruakh_TALK 20:06, 20 July 2007 (UTC)

Yes, there are several reasons it won't work for Latin. Go back to the original example I gave of certior. Of all the forms in the declension table above, only certior (the sub-lemma) will have the template {{comparative of}}. But using the template on the page for certior will place this entry in the Comparative adjective forms category. This is wrong. Only the entries for all the other declined forms of the comparative in the inflection table should be listed as forms of the comparative. The comparative sub-lemma entry certior should be in either Category:Latin comparative adjectives or possibly Category:Latin adjective comparatives, which the template can't handle. --EncycloPetey 20:29, 20 July 2007 (UTC)

We seem to be miscommunicating somehow? My suggestion was to add an is_lemma boolean parameter to {{comparative of}}, such that (for example) {{comparative of|certus|lang=Latin|is lemma=1}} would categorize its entry into Category:Latin comparative adjectives. A similar — indeed, slightly simpler — modification could categorize it into Category:Latin adjective comparatives. Just let me know which you want, and I can take care of it. (By the way, I assume you'll want a similar change to {{superlative of}}?) Or am I still missing your meaning? —Ruakh_TALK 00:00, 21 July 2007 (UTC)

OK, I think I understand now. I'll have to give the category name some thought and confer with Medellia (and other Latin editors) before deciding. --EncycloPetey 00:29, 21 July 2007 (UTC)

Now implemented at Template:comparative of, documented at Template talk:comparative of, and used at certior; please take a look and let me know if everything's kosher. —Ruakh_TALK 02:07, 19 August 2007 (UTC)

I have addressed this in a different way with {{comp of}} and {{the comp of}}. There is a lot that needs to be worked out with these form-of templates, so it is only a suggestion at this time. (There is a huge list of ideas that needs to be sorted through, and some of them will be dropped.) I just need to know if the distinction I've made is adequate to address the problem raised here, for those who are inclined to test undocumented code. is_lemma as a boolean parameter seems a bit geeky to me. DAVilla 02:59, 19 August 2007 (UTC)

Regional Spanish

Could someone set up a regional language template Template:Mexico along the lines of {{UK}}, but set to automatically categorize the entry in Category:Mexican Spanish? Right now, Autoformat is converting (Mexico) to {{context|Mexico}}, putting such words into Category:Mexico, which is the wrong category. Creating a {{Mexico}} template will fix this problem. --EncycloPetey 10:01, 20 July 2007 (UTC)

Done — but shouldn't AutoFormat be converting it to {{context|Mexico|lang=es}} instead? That should have been categorizing into Category:es:Mexico. —Ruakh_TALK 13:40, 20 July 2007 (UTC)

It may have been doing that; I'll double-check. (It would still be the wrong category though). --EncycloPetey 19:40, 20 July 2007 (UTC)

So, {{Mexico}} should be moved to {{Mexican Spanish}}, right? --Connel MacKenzie 19:42, 20 July 2007 (UTC)

This is a new template. What should happen is that someone can enter "Mexico" as a context label, and the definition line will get (Mexico) at the head of the definition line, but the category for the word should appear as Category:Mexican Spanish. Right now, all of this works except the category, which comes up as Category:es:Mexico (and this is incorrect). The category Category:es:Mexico should be for Spanish names of places in Mexico, not for words peculiar to that country. See chela for an example or where the template isn't working correctly. This should work similarly to {{NZ}}, where a person can enter "NZ" as a context label and have the word appear in the category Category:New Zealand English --EncycloPetey 19:46, 20 July 2007 (UTC)

Overlapping text

The page Category:Requests for pronunciation now has the entries in the category list overlapping with the "Oldest requests" box. I've also noticed that images in categories (such as in Category:Languages of Italy) have also changed the way they display, so that the text and entry lists now wrap around such images rather than appear below them. Has someone been mucking around with Category display? --EncycloPetey 21:30, 20 July 2007 (UTC)

Dunno. But I think {{-}} is the way we should handle these, as they come up. --Connel MacKenzie 19:47, 21 July 2007 (UTC)

Since they won't fix Special:Wantedpages

• User:Connel MacKenzie/Wantedpages

Improvements and suggestions are welcome. Yes, I know: handle Unicode correctly. (Sorry, not yet. It's too much of a pain.)

--Connel MacKenzie 19:43, 21 July 2007 (UTC)

Could you add some explanation of what a "bad redirect" is? I assumed it meant something like "broken redirect", but that doesn't seem to be the case. :-/ —Ruakh_TALK 20:06, 21 July 2007 (UTC)

Well, I just fixed that. "Bad redirects" are things that (on en.wiktionary) shouldn't be redirects. --Connel MacKenzie 20:10, 21 July 2007 (UTC)

I think I'll exclude Transwiki: pages on this next pass. --Connel MacKenzie 20:13, 21 July 2007 (UTC)

Why not just limit to NS:0? Or at least exclude User (Special:Whatlinkshere/Bulbasaur). Or does it need something more complicated than just per-namespace.. hmm. Anyway, excellent work. I was wondering whether I should propose throwing out the baby with the bathwater and just delete {{nav}}... Cynewulf 21:05, 21 July 2007 (UTC)

Well, I'd support that deletion nomination.  :-)   Perhaps I should generate a second one for just NS:0. Maybe English sections only, excluding translation sections? Erm, wait, that would get difficult (and have significant processing time, as opposed to the 30 seconds or so, that it takes now.) --Connel MacKenzie 00:02, 22 July 2007 (UTC)

Just my 2 cents: How about using the sum of those two numbers, the link count and the page count, as the sort key weighting the red links? In this way, in other words, one link of the word in a page will get 2 points and each of the rest in the page will get 1 point. It seems to me that a word appearing in more pages, or more diverse contexts, is more important. --Tohru 00:43, 22 July 2007 (UTC)

I'm surprised to see this sentiment (twice now.) It always bugged me that Special:Wantedpages ranked by pages not links. But it seems to be a common request? I'll generate a separate table by page hits. Doing a straight traversal means I have to add them up differently for that, instead of counting only when done. Once I have that, I'll add your clever idea of the combined ranking. --Connel MacKenzie 01:18, 22 July 2007 (UTC)

Hmmm. That was much easier than I'd thought it would be. --Connel MacKenzie 02:02, 22 July 2007 (UTC)

Wow! Great idea, Connel MacKenzie! — Beobach972 01:04, 22 July 2007 (UTC)

Thank you. Now, how to get people to start entering them...  :-)   --Connel MacKenzie 01:19, 22 July 2007 (UTC)

On a somewhat related note, is there some reason for not having redirects such as Category:xx:Computing —> Category:Computing? I was about to add several, to help clear out the Special:Wantedpages, but noticed that they were recently deleted. — Beobach972 01:04, 22 July 2007 (UTC)

Entering those redirects makes DAVilla's {{context}} template lose its friggin' mind, dropping categories or adding incorrect categories. Please don't make it worse by entering them. --Connel MacKenzie 01:12, 22 July 2007 (UTC)

Wait, I may be wrong. Were redirects an acceptable work-around or not? --Connel MacKenzie 02:36, 22 July 2007 (UTC)

Redirects don't really work for categories anyways. Cat:X redirects to Cat:Y, someone enters [[Cat:X]] on a page, it doesn't appear in Cat:Y. Redirects for categories should be routinely substituted and deleted.

I'll pay special attention to Special:Wanted pages as I rewrite {{context}}. The xx's are already being moved out of the system entirely. Otherwise, most of those links show because of labels that differ from the category name, but it's possible to push the #ifexist test off to a different sub-template, which will keep it from appearing in those cases. DAVilla 02:58, 22 July 2007 (UTC)

Thanks for the clarification. The redirects weren't supposed to "work", they were just supposed to unclog Special:Wantedpages (which is a bad idea, indeed.) --Connel MacKenzie 03:22, 22 July 2007 (UTC)

Do not create redirects for categories, per the above. DAVilla 02:58, 22 July 2007 (UTC)

Alright. (Just to be absolutely clear, I meant {{catred}}-redirecting them, not hard-redirecting them. Does that make a difference?) — Beobach972 05:37, 22 July 2007 (UTC)

The red-links are there, because {{context}} checks for them first, finds they do not exist and moves on to the correct category. I don't think it has the ability to follow a catred redir. So, if you did that, any items that are correctly categorized now, would (when the job queue clears them) magically jump to the wrong category. --Connel MacKenzie 08:15, 22 July 2007 (UTC)

Could someone explain what the problem with Special:Wantedpages is? Specifically, does it count {{#ifexist:nonexistent_page_A|[[nonexistent_page_B]]}} as a redlink for nonexistent_page_A, for nonexistent_page_B, or for both (or am I completely misunderstanding the problem)? —Ruakh_TALK 19:50, 24 July 2007 (UTC)

The major problem I'm aware of is that it doesn't allow filtering by namespace, which means that the list is perpetually flooded with the gunky categories that are thrown up by various templates (I'm not entirely sure why this can't be fixed by fixing said templates, however). I may be wrong on that -- and also on the answer to your question, which I think is that it would count this as a redlink to nonexistent_page_B, since, like Special:Whatlinkshere, it is based on the expanded wikitext of each entry (or rather, on the links table which is generated from the expanded wikitext of each entry). -- Visviva 03:19 25 July 2007 (UTC)

But in my example, neither nonexistent_page_A nor nonexistent_page_B appears in the expanded wikitext? —Ruakh_TALK 14:24, 25 July 2007 (UTC)

Oops, you're right, I misread it. I would have thought, therefore, that this wouldn't be counted at all; but per DAVilla's comment below, I guess I was mistaken. -- Visviva 14:52, 25 July 2007 (UTC)

In addition to any [[links]], no matter how complicated, for {{#ifexist:page name|true stuff|false stuff}} the page name is caught by Special:Wantedpages. What's difficult is that this is true, I suspect, even if the #ifexist statement is never evaluated, e.g. {{#if:FALSE|{{#ifexist:page name|...}}|...}} will still catch the page name. That would explain why some of these labels are showing up as wanted categories even though it is very obvious within the code that the correct category name is already provided. DAVilla 05:00, 25 July 2007 (UTC)

Can we do something hackish, like {{#if:condition|{{#ifexist:{{#if:condition|possibly existent page|certainly existent page}}|stuff if condition is met and possibly-existent page does exist|stuff if condition is met and possibly-existent page does not exist}}|stuff if condition is not met}}? (I realize that would only help in the case that our only tests for the page's existence are in an unused conditional branch, but it's something.) —Ruakh_TALK 14:24, 25 July 2007 (UTC)

When a template is edited, all pages that use it are added to the job queue. When the job queue gets to an entry, it is re-parsed (to ensure the template changes are now reflected.) The table used to populate whatlinkshere is used for the job queue (now) to cleanly identify which pages need re-parsing. When conditional template references are encountered, the condition is treated as if it is always variable, so both positive and negative conditions trigger cascading "job queueing" by original revid (to prevent duplicates and recursion that could cause "re-job queueing.") Every page referenced, whether it exists or not, that is referenced in those conditionals, is therefore fed into the Whatlinkshere table.

Because the devs won't change the whatlinkshere functionality back to how it used to work, opting instead to have unambiguous complete coverage for job-queue re-queueing, the only remaining option is to emulate what Special:Whatlinkshere used to do, using User:Connel MacKenzie/Wantedpages. Trying to implement further template work-arounds will only work in the short term, until they are discovered and such loopholes are also handled by the "re-job-queue re-queueing" logic. (They are discovered when they cause recursion warnings.) --Connel MacKenzie 15:06, 25 July 2007 (UTC)

Oh! That makes a lot of sense. (Well, I'm not sure the whole template-job-queue concept actually makes sense; but if it does, then this does.) Thanks for explaining. :-) —Ruakh_TALK 15:59, 25 July 2007 (UTC)

AFAIK, the job queue exists because you can't update a template and update all pages that use it before the http request (for the original edit) times out. I agree that overloading the special page's link table to make the job queue work was a poor choice. I said something to that effect to the developers. IIRC, when I requested they do a schema change to add a second table with the original functionality, the response was something akin to "when pigs have wings." Apparently the space and performance considerations are significant. --Connel MacKenzie 16:51, 28 July 2007 (UTC)

Well, there is another option, actually, if there is an #ifexist that doesn't always need to be evaluated. Just push that link in these conditional off to another sub-template, and Special:WhatlinkshereWantedpages will only be incremented when the sub-template is called. It's not a big performance issue either since this is the less frequent case. DAVilla 20:24, 31 July 2007 (UTC)

Javascript mayhem

But 2001, I was convinced that Javascript was a dead programming language, with no remaining redeeming qualities. A couple years ago, I noticed wikis, and saw Javascript (for once) being used effectively, not just as annoying advertising atrocity.

But it remains brittle. The devs have pushed something through (ajaxwatch.js?) that is now thwacking Navigation Popups mercilessly. Anyone see where it is breaking, and/or have work-arounds for it?

--Connel MacKenzie 02:43, 22 July 2007 (UTC)

Some issues resolved now (thanks #wikimedia-tech, thanks Splarka) other things still need to be updated. --Connel MacKenzie 07:00, 22 July 2007 (UTC)

Redirects formed by moving pages

At present, when a page is moved here on Wiktionary, a redirect entry is made linking the old entry to the new one. Whilst this is useful for Wikipedia, it is not for Wiktionary. Is there any way to stop these redirect entries from being automatically created? † Raifʻhār Doremítzwr 01:16, 23 July 2007 (UTC)

Nope. Replace the moved page with {{delete}}. --Connel MacKenzie 18:16, 23 July 2007 (UTC)

That’s what I’ve been doing. If this problem can’t be solved, I suggest that a very obvious notice be added to the “move” page, instructing page movers to add the delete tag to the entry for the former page location. † Raifʻhār Doremítzwr 19:19, 23 July 2007 (UTC)

To clarify, I asked Brion on irc://irc.freenode.net/wiktionary if this is possible; he responded that is is positively a "WONTFIX" as far as the developers are concerned. Sometimes the residual redirect is appropriate. Perhaps a discussion could be started on WT:BP about the implications of adding a {{uncommon misspelling of}} template, (for the situations that right now are dealt with by tagging with {{delete}},) combined with an extended discussion about modifying WT:CFI to permit such a thing. (WARNING: that concept has met significant resistance in the past.) --Connel MacKenzie 15:33, 25 July 2007 (UTC)

I don’t think that would be necessary. What I believe would be best would be to edit Special:Movepage so that right at the top, immediately after “Using the form below will rename a page, moving all of its history to the new name. The old title will become a redirect page to the new title.”, it would read “In most cases, Wiktionary discourages such redirects, so remember to go back to the page, either to tag it with {{delete}} or to replace it with a suitable entry.”; what do you say? † Raifʻhār Doremítzwr 12:53, 31 July 2007 (UTC)

Language templates

We need to decide how we are using the plain language templates because it is causing major confusion. These templates were originally set-up to be substed in translation tables to provide a link to the language article on Wikipedia. However a move was made to have these as internal links instead which is no major issue really. The major problem is that temlates like {{infl}}, {{language}} and {{idiomatic}} have been using the templates for sometime now to autocategorise articles in POS categories based upon the language template. This does not work if the text with the language template is linked/wikified.

We therefore need to decide if we unlink all the templates and change the substing to [[{{subst:sux}}]] for example, or if we can work out someway to use the templates as is in {{infl}}. My preference is to go with de-linking all the language templates and setting up Autoformat to subst the templates as described above. This discussion will result in a vote hopefully to decide the use of these templates.--Williamsayers79 11:58, 24 July 2007 (UTC)

Two- and three-letter template names are reserved specifically for language name substitution, which are linked except for the most obvious top 40 or something. This is for the convenience of translators who are used to using the templates on other language Wiktionaries and are instructed to subst: them here. The linking also helps in patrolling edits.

{{language}} and the templates that call it no longer rely on the Template:xx templates with two- and three-letter names. They rely on the subspace Template:lang:xx templates and the reverse as Template:LANGUAGE NAME in the upper-case (when applicable to the script), all of which are categorized as language templates. These are very thinly populated at the moment and could use some beefing up. 07:50, 25 July 2007 (UTC) DAVilla 08:02, 25 July 2007 (UTC)

So the obvious solution is to modify {{infl}} to use {{language}} and then create templates in the Template:lang:xx subspace? Thanks for your reply. --Williamsayers79 07:56, 25 July 2007 (UTC)

Just a thought: Is it possible to write a script to create the missing language templates from the existing ISO templates? I've got tables listing the existing templates (well, most of them at this point) on a personal project page, if that helps. --EncycloPetey 08:14, 25 July 2007 (UTC)

Yes, that sounds great, I've just ran a test of the {{infl}} template with the {{language}} template transcluded - and it worked for lang codes with templates in the lang: subspace. Once the script is finished copying the templates and de-linking the new ones I'll make the changes to the live {{infl}} template. --Williamsayers79 08:37, 25 July 2007 (UTC)

1. This belongs in WT:GP.
2. This has been discussed (but not resolved adequately) in WT:GP.

--Connel MacKenzie 21:12, 25 July 2007 (UTC)

First: the reason for linking in some of the templates was so that the languages would be linked in translation tables when people subst'd the templates. This use is essentially obsolete. Observation of the tables shows that this is rarely done. (EP says it is, but the results turn out not to be statistically significant.) In any case, linking/unlinking in the template will not cause existing translation table entries to be linked, since we do not use the templates there. If we want to conform existing entries, then we need a bot (which we have, although it only does unlinking, not linking at the moment; should move that up the todo list ;-).

These templates should be simple transclusions of the standard language name for the code. It is not possibly to unlink the result of a transclusion. Having them all unlinked is a huge win:

• lots of cruft can be removed from {{context}}

  Huh? {{context}} doesn't even call {{language}} or any of the language code templates. DAVilla

• the {{language}} hack can be dispensed with, as well as the "lang" pseudo-NS, and the resulting performance hit from the template nesting and conditionals

  You're welcome to simplify {{language}} if you think conditionals cause that much overhead. Circumventing it makes more sense since the template call is more expensive. On the other hand, it's probably cached anyway.

  Template:lang: is a subspace, like Template:en- etc., which if you think appropriate you can rename to Template:lang/ or Template:t- as Dodde had tried or whatever you like.

  If these templates aren't necessary for substitution, it makes A LOT more sense to me to push them into a subspace than to worry about two- and three-letter template name collisions. DAVilla

• as noted, {{infl}} will work
• {{t}}, t+ and t- can be made to work without #if conditionals, and without serious performance hit (assuming we run tbot once in a while, which is the intent anyway)

  If we run a bot once in a while, then there's no reason not to streamline only {{t+}} {{t-}} & {{t!}}, and make {{t}} as user-friendly as possible (yes, with all those conditionals). DAVilla 20:08, 31 July 2007 (UTC)

• others like the wikipedia template can be improved
• Special:WantedPages will recover (although we have to fix {{nav}} as well
• all these result in serious performance improvements

It is win-win-win. Would think it would be a no-brainer. Robert Ullmann 09:19, 26 July 2007 (UTC)

You make it sound like a packaged deal. The no-brainer is to have a series of templates that are not linked—which doesn't have to be the two- and three-letter templates specifically. I don't much like having those names reserved, but it seems to be necessary. If that's true and if they don't have to be linked then sure, unlink them. Better to maintain one series than two. I'm not going to lie though, and say that we get all this performance increase by unlinking them, when we could easily do the same with another series of templates. Circumventing {{language}}, streamlining {{t}}, etc. are completely tangential issues. Let's present this choice, of unlinking the language templates, but let's not misrepresent it. DAVilla 20:08, 31 July 2007 (UTC)

Oooh. With AutoFormat doing the "top 40" I think my last complaint about revamping the lang templates is gone. Nice. But it doesn't seem to be working? Special:Whatlinkshere/Template:sv (currently shows lots of main namespace pages that include that one template.) (That is the first language template example listed in WT:DW - so it would seem to me, that those all need subst:ing first!) The Special: pages get updated on Wednesday and Saturday, so if others have happened, you won't know for sure, for at least four more days. Since the "top 40" list contains only about 40 unwikified languages (perhaps a couple more than that) that means there are about two hundred language templates that still need to be checked for Special:Whatlinkshere, right? So, how long has AF been doing this? One week after it started, we should recheck the Whatlinksheres, then (and only then) give you the green light to go ahead restructuring the lang templates. --Connel MacKenzie 16:39, 28 July 2007 (UTC)

Unfortunately, checking for "What links here" doesn't work that way. If you check some of the pages that supposedly link to the {{sv}} template, you'll find they're actually making a "lang=" call as an argument within another template. So, many of these do not need to be subst'ed. There may not be an easy way to find out how many un-subst'ed ISO templates there are on Wiktionary. --EncycloPetey 17:43, 28 July 2007 (UTC)

What a mess. So the XML dumps remain the only reliable way to find them, then? I guess we'd better let Robert Ullmann go ahead then. The subst'ing can be done after the next XML dump, allowing AutoFormat to wikify or dewikify as needed based on Special:Recentchanges. I guess this problem really is more simple than it appears. --Connel MacKenzie 18:39, 28 July 2007 (UTC)

If all the templates that call these language templates were changed to call the lang: language templates instead, presuming that the numbers were beefed up, presuming that we agree that they are even needed, then all the Whatlinkshere's would update in a week to only those pages that include them directly, and they can be substituted as had always been intended. But an XML dump does seem like a surer thing. DAVilla 20:20, 31 July 2007 (UTC)

Anything that simplifies {{context}} and {{t}} is a Good Thing indeed. I now see a lot of benefits to making this cut over to uniform plain language templates. With the recent AF top 40 fix, I see no remaining reason to delay. --Connel MacKenzie 18:42, 28 July 2007 (UTC)

It doesn't simplify {{context}} and there's absolutely no reason to simplify {{t}} which is intended to be substituted with {{t+}} etc. anyway. See above. If you have other reasons for agreeing to dewikify then weigh those, not these, against the benefits of linking. DAVilla 20:20, 31 July 2007 (UTC)

Of course it simplifies context: it gets rid of {{language}}. And for t, we can use {{{lang|{{{{{1}}}}}}}}} for the section reference which has too much overhead, but only for the entries it is added to until tbot (or equivalent) gets to them. And the other things that use the {language} thing likewise. In all these cases the language code templates will exist; as long as they are always unlinked all the code gets much simpler. Robert Ullmann 17:43, 3 August 2007 (UTC)

(If anyone is wondering about DAVilla's claim that {context} doesn't call {language}, that is hypertechnically true, but it depends on calling {language}; see {{idomatic}}. And (e.g.) {{context|mostly|idiomatic}} will call {{language}}.) Robert Ullmann 17:56, 3 August 2007 (UTC)

DAVilla, there are two main points here: 1) AutoFormat has obliterated the need to make wikified vs. non-wikified language names from within templates, 2) Simplification of esoteric templates such as {{context}} is (and always has been) desperately needed. The solution Robert is offering looks like it will "solve" that issue implicitly, simply, comprehensibly and elegantly. Right now, I can't see any reason to keep the language templates as they were (some wikified, others not, based on nearly random, poorly defined "recognizable" criteria.) Did I miss something? Also, what "above" mentions that {{t}} is supposed to be subst:'ed now? Wasn't that wishful thinking, or is there a bot already doing that, or what? --Connel MacKenzie 21:36, 3 August 2007 (UTC)

The successful implementation of linking through AutoFormat clears up most of my reservations. I would still like three things before I throw my full support behind de-linking the ISO templates: (1) A way to help reduce the possibility that someone will mistakenly edit an ISO template in such a way as to break the functionality of {{context}} and similar templates, (2) An automatically generated/updated list from AutoFormat of which languages it is instructed to link/unlink (this may already exist, but I don't know how to find it), (3) A policy on how all language names should appear when listed in the Translations section. The third one is the "biggie", but it is important if we're going to be linking/unlinking by bot. There is a discussion relevant to this issue currently under way at Wiktionary_talk:About_Greek#format of greek translations in english entries, and the absence of a clearly stated policy somewhere means that this will continue to be an issue until such a policy is written. --EncycloPetey 00:26, 4 August 2007 (UTC)

1. this isn't that different from any other templates, but I think if they are all unlinked no-one is going to go around adding links and such? Why would they?
2. AF doesn't produce a table, it uses the table at WT:TOP40, languages (or errors) that don't appear above or below the line are left alone. There are about 200 such not listed.
3. (it doesn't affect Greek directly, we aren't going to link Greek), but in general, if we use our standard name on one line for each language, then it works as is; if we have multi-line entries where the sub lines are not full language names, then AF has to get more sophisticated. (It probably will anyway, it ought to be able to sort and balance the columns.) Note that for (say) Chinese, both the line and the subsidiary lines have full language names. Robert Ullmann 11:48, 7 August 2007 (UTC)

They might try linking them, they might not. If they don't know the purpose, they might try adding code or something, thinking it won't affect anything. I've done that myself. I would recommend protecting them at sysop level, the two-letter codes at the very least.

You could write AF to check for the existance of a language it doesn't recognize, e.g. Anglo-Saxon or español, and make the correction automatically. DAVilla 07:04, 9 August 2007 (UTC)

Intermediate step, in reply to DAVilla's comments above: we need to keep the simple templates (not in lang: or whatever), because users expect them; all of the other wikts use code templates like that, in various ways. For now, I've simplified {{language}} to convert codes to names. It uses the xx templates, only using the lang:xx if the simple one is wikilinked.

If the xx code template is not linked, the lang:xx template is not referenced (otherwise those would fill up Special:Wantedpages and Connel will be upset again ;-). So the lang:xx templates should only exist if/when the code template is linked, and should only be used by {{language}}. Robert Ullmann 15:46, 7 August 2007 (UTC)

(oh, part of the reason to simplify this is that it was part of the Wantedpages problem. It was why "Template:EN" with 3,141 links was the first entry. Without fixing this, the entries no longer showing up from nav would just be replaced with lots of these ;-) Robert Ullmann 16:01, 7 August 2007 (UTC)

You'd already convinced me to avoid using {{language}} except when necessary, and now you've convinced me, below, to completely discard it. Since no one seems to think these need to be linked any more, let's use 'em. DAVilla 07:04, 9 August 2007 (UTC)

Request for advice re editing a template

I want to take a run at editing a simple template (I think I've got it figured out) and would like to know if this is a good procedure:

1. Make a copy of the template under a new name (like Template:Xtemp for Template:X).
2. Edit Template:Xtemp with my changes and resave.
3. Test the temporary template by calling it from a mainspace page (I wouldn't save the mainspace page with Template:Xtemp in it -- I'd just test from "Show Preview").
4. Repeat previous step with more mainspace pages.
5. Once satisfied Template:Xtemp works, make the same changes to the real Template:X.
6. Put in a request for speedy deletion of Template:Xtemp.

Is this OK? -- WikiPedant 20:03, 26 July 2007 (UTC)

Note that it's possible to transclude pages that aren't in the Template: namespace; it just means that you need to include the namespace (or an initial colon, if in the main namespace). So, you can create a {{:User:WikiPedant/Template}} (or differently named) to test with, assuming you're only ever doing one template-test at a time. (That said, I personally don't particularly mind if you create temporary templates in the Template: namespace, provided they're properly marked and you request speedy deletion as soon as you're done with them; and I doubt anyone else would particularly mind, either.) —Ruakh_TALK 21:33, 26 July 2007 (UTC)

minor edit above: colon before namespace DAVilla 19:02, 31 July 2007 (UTC)

Okay, Ruakh, thanks a lot. I'll give it a whirl in the near future. -- WikiPedant 05:42, 28 July 2007 (UTC)

Updating uncategorized TheDaveBot creations

So, I've just done about 50 edits like this ([2]). It appears that TheDaveBot's automated creations preceded the creation of some of our current templates, so, for example, all these past participles aren't in the past participle category currently populated by the template. My edits with my main account, and checking each one, were just an initial chunk to serve as an example; if I replace the precise string made by TheDaveBot, there have been no problems. Does anyone mind if I proceed and fix them all? And should I use my bot account to do it? Dmcdevit·t 12:10, 28 July 2007 (UTC)

Please do! :-) —Ruakh_TALK 13:30, 28 July 2007 (UTC)

{{subst:support}} --~~~~  :-) Yes, please use your bot account. --Connel MacKenzie 16:27, 28 July 2007 (UTC)

I'll get it started. Dmcdevit·t 16:55, 28 July 2007 (UTC)

Tor router unblock request

Hi all,

Apologies in advance; if people feel this belongs on WT:BP, then please either move this there (leaving behind a soft-redirect) or link this from BP.

I got an e-mail request for an unblocking that I am scratching my head over. The request if for a server located in Texas, owned/leased by someone in a different state. The router is identified in the Tor network as a router with the exit policy reject *:* (which means it only forwards other people's tor packets, adding a layer of encryption to foil tracing efforts.)

The request is to unblock that IP address. I cannot bring myself to any rationalization that such an action would be a sane thing to do. If the server's owner is in a different state, surely they are accessing WMF projects from their home address, nor their remote server?

Checking http://openrbl.org/ I see only one remaining RED boxen for this IP; apparently the IP owner as been quite diplomatic and assiduous in requesting other unblockings. (All public lists there have the ability to de-list a previously hostile address.)

At one point, we considered a "clean" address worth reducing the block from "infinite" to "3 months." But I can't bring myself to do even that, in this case. The server is being used to aid and abet a hostile protocol; the mere listing as a Tor node still justifies the "infinite" block.

Well, I guess I answered my own question (by rehashing the details here.) If anyone thinks we should discuss our Tor blocking practices, I guess this would be an opportune time to do so.

--Connel MacKenzie 06:24, 31 July 2007 (UTC)

Tor is simply a popular open proxy. There are legitimate uses for anonymizing IPs, but, sadly, in WMF's experience, the potential for anonymous abuse that cannot be stopped or traced outweighs the potential for anonymous contributions, and so open proxies are banned. Tor is no less banned. Dmcdevit·t 07:09, 31 July 2007 (UTC)

Is there a place where I can get a list of all redlinks in Wiktionary?

Just seems like a useful thing to be able to hit. Cheers! bd2412 T 20:44, 31 July 2007 (UTC)

By my count, that's 574,182 unique pages from 723,624 individual links. (Index pages skew it a bit!) Even you might want to consider starting smaller. What would you prefer, instead of 500? --Connel MacKenzie 09:35, 2 August 2007 (UTC)

Granted, for namespace zero only, it's only about 197,462.  :-) For a long time, Special:Wantedpages did work, and was steadily worked down. --Connel MacKenzie 09:47, 2 August 2007 (UTC)

Is there a way to discount those red links that are just plurals, past participles, etc. as many (most?) of those are suitable for a bot to create? Thryduulf 10:27, 2 August 2007 (UTC)

That is a fantastic suggestion. User:TheCheatBot does create all those, whenever I get around to running it. (Well, if the inflection template points to them correctly, anyhow.) I'll try to exclude those for the next (guesstimate: 8/8/2007?) XML dump. --Connel MacKenzie 17:24, 3 August 2007 (UTC)

Revised estimate: 8/14/2007. I may need a reminder for this. --Connel MacKenzie 19:51, 7 August 2007 (UTC)

Well, in order to identify those which are suitable for bot creation, don't we need a comprehensive list to pick those from (and once we've culled the bot-worthy ones out, shouldn't we put a bot on that task)? How about a list of all mainspace redlinks which do not contain any spaces, and do not end in an "-s", an "-ed", or an "-ing"? And, come to think of it, how about individual lists of all mainspace redlinks which do not contain any spaces, but which do end in an "-s", an "-ed", or an "-ing"? bd2412 T 14:52, 2 August 2007 (UTC)

Hmmm. That would show which parent-pages don't have their inflection templates set up correctly. Lemme think about this...not as easy as the other. --Connel MacKenzie 17:24, 3 August 2007 (UTC)

You know of User:Robert Ullmann/Missing and User:Robert Ullmann/Oldest redlinks. The problem I think is that most of what you are looking for is generated by templates; and those don't show as explicit links in the wikitext. We could fix Special:Wantedpages, it takes fixing nav and context (as I have previously explained). Robert Ullmann 15:12, 2 August 2007 (UTC)

Doesn't User:Robert Ullmann/Missing create redlinks for many words that no one had linked before (including typos)? bd2412 T 16:06, 3 August 2007 (UTC)

"create redlinks"? ;-) it does look at all the words in the definitions. Neither report is exactly what you are looking for. If we could only fix WantedPages ... but i have to be allowed to fix {context}, and get rid of {language} ....Robert Ullmann 16:14, 3 August 2007 (UTC)