Can someone find out why the assisted translation adding is not working at phosphorus? It says "Cannot find translation table. Glosses must be unique" or something like that. Malafaya 22:51, 2 January 2011 (UTC)

• The translation table ended with {{rel-bottom}} instead of {{trans-bottom}}. Fixed. SemperBlotto 08:46, 3 January 2011 (UTC)

Thanks! :) Malafaya 18:38, 8 January 2011 (UTC)

...is showing words that were featured last January. Is this a technical error or do new words need to be chosen for this month? — lexicógrafa | háblame — 18:26, 3 January 2011 (UTC)

Strange, EncycloPetey hasn't been updating them recently. There hasn't been a new word since November. --Yair rand (talk) 18:40, 3 January 2011 (UTC)

Yes, he's not been active recently. I'll do the next few (starting with tomorrow's). The reason why they're the same as last year is that we reuse the same 365 templates year after year, and they've not been updated. —Internoob (Disc•Cont) 01:12, 4 January 2011 (UTC)

If someone would show me how Word of the Day is run around here I'd be glad to set it up in the absence of the main contributor. — lexicógrafa | háblame — 01:35, 4 January 2011 (UTC)

Okay. This month's words are at Wiktionary:Word of the day/Recycled pages/January and as I explained before, most of them are last year's but I've done a few already. Choose a word from Wiktionary:Word of the day/Nominations and make sure it hasn't been listed here before and preferably not in other major word of the days either by clicking the links in the nomination ("G" is Google, "W" is Wiktionary, etc.). Also make sure that the word fits the criteria at the top of the nominations page. The WOTD templates are pretty intuitive I think. —Internoob (Disc•Cont) 23:34, 4 January 2011 (UTC)

Also, you can check whether we've added similar words before by consulting Wiktionary:Word of the day/Archive/Alphabetic. —Internoob (Disc•Cont) 00:00, 5 January 2011 (UTC)

{{ {{templateX}}{{{varY|}}} | ... }}
If the template templateX contains text "el-xyz-", and variable varX contains "abc" the expession above enables a template name "el-xyz-abc" to be generated on the fly. I have tried doing something similar to generate a category name, without success. Can anyone help please? —Saltmarsh^{απάντηση} 16:05, 5 January 2011 (UTC)

] should work... —CodeCat 16:56, 5 January 2011 (UTC)

Thanks CodeCat - now working (see άσχημος). I think I was trying to include too much in "templateX". —Saltmarsh^{απάντηση} 06:37, 6 January 2011 (UTC)

Is it possible to suppress an unwanted category generated for the "calling" template (Template:el-decl-adj) - if not I can probably make use of it. —Saltmarsh^{απάντηση} 07:21, 6 January 2011 (UTC)

If you include a template that also adds a category, then you automatically get the category with it, there isn't really a way around that. But you can try giving the template a parameter that allows you to disable the categorisation, like so: {{#if:{{{nocat|}}}|<!-- do nothing -->|]}} —CodeCat 11:28, 6 January 2011 (UTC)

Thank you again —Saltmarsh^{απάντηση} 14:04, 6 January 2011 (UTC)

I'm in the process of learning Navajo, and am exploring the possibility of using verb conjugation templates much like what's used for other languages like Spanish. To that end, I'm looking at the template for -er verbs for some hints -- but I'm baffled as to where the logic is for handling sound shifts. Somehow the template knows to turn tener into tengo instead of teno, and querer into quiero instead of quero.

The relevant sections of the template are simply:

Conjugation of '''''{{{1}}}er{{#if: {{{ref_stem|}}}|se|}}'''''

{{#if: {{{ref_stem|}}}|]|}} ]

The template itself doesn't seem to include *any* code for handling the addition of the g in tengo or the i in quiero. Digging around, I found that how you call the template changes things dramatically. Calling the template in the generic fashion of {{es-conj-er | 1 = tener}} will give me a conjugation for the nonexistent verb tenerer, with the first-person form tenero.

However, calling it as it's actually used on pages, using {{es-conj-er (tener)}}, seems to also call some major mojo in the background, validating that the input string is a valid Spanish verb and then feeding the template the proper forms, such as by adding the g in tengo. Inputting nonexistent words that would match similar Spanish sound-shift patterns (like terer instead of querer, or toner instead of poner) does not produce the expected conjugation table, instead just producing something like:

Template:es-conj-er (toner)

As an additional oddity, {{es-conj-er (tener)|}} produces the expected conjugation table, while {{es-conj-er (tener)}} -- minus the extra | at the end -- produces a conjugation table with {{{1}}} all over the place as plain text. Meanwhile, {{es-conj-er (querer)}} works just fine, and adding the extra bar at the end breaks the template.

I've just spent the last couple hours reading up on templates, and I still have zero idea what's going on here. Any advice would be most welcome, either here or on my talk page! I'm completely baffled as it is...

Cheers, Eiríkr Útlendi | Tala við mig 07:11, 6 January 2011 (UTC)

{{es-conj-er (tener)}} is a completely different template than {{es-conj-er}}. Each conjugation pattern has its own template. Nadando 07:35, 6 January 2011 (UTC)

So then, rather than coding in the rules of how sound shifts work, folks instead created individual templates for each Spanish verb paradigm? Or is it even for each individual verb? And here I thought the parentheses implied some internal function call. I'm frankly flabbergasted... Cheers, Eiríkr Útlendi | Tala við mig 07:58, 6 January 2011 (UTC)

That is correct. As you can see in Category:Spanish conjugation-table templates, there really aren't that many. With other languages it might make more sense to make templates that are more complex rather than creating separate templates for each pattern. Nadando 08:12, 6 January 2011 (UTC)

Thank you Nadando, that certainly clears this up for me. Cheers, Eiríkr Útlendi | Tala við mig 08:18, 6 January 2011 (UTC)

You might also want to look at Category:Catalan conjugation-table templates which has a lot fewer templates than Spanish. Those templates use parameters more so you don't need a template for each kind of irregularity. —CodeCat 11:24, 6 January 2011 (UTC)

Oh and if you want an insane example, check {{de-conj-strong}}. -- Prince Kassad 16:31, 6 January 2011 (UTC)

Now that Nadando has kindly corrected my misapprehensions about how the Spanish verb templates work, would anyone have any advice on how to build if-then and other simple logic structures into a template? Navajo verb conjugations require some interesting, but ultimately not too insanely complicated, convolutions that would seem to go beyond the scope of simple transclusion. Cheers, Eiríkr Útlendi | Tala við mig 08:18, 6 January 2011 (UTC)

Wikipedia:Help:Template#Creating and editing templates may help some (though not all of it is applicable to Wiktionary). If you specify what convolutions are needed, someone can probably help you write the template(s).​—msh210℠ (talk) 08:36, 6 January 2011 (UTC)

Bingo, that's exactly the sort of thing I was looking for! Thank you, Msh210. I will explore how best to create the template(s) in question as I finish working through my current reading list on Navajo verbs. Ahéheeʼ, Eiríkr Útlendi | Tala við mig 08:46, 6 January 2011 (UTC)

Something to remember with templates is that they can add pieces together but they can't split words apart. You should design the parameters of your templates with that in mind. —CodeCat 11:26, 6 January 2011 (UTC)

Thanks also to CodeCat and Prince Kassad -- I appreciate the examples, those will be useful references once I wade into this process.  :) Cheers! Eiríkr Útlendi | Tala við mig 16:50, 6 January 2011 (UTC)

Hi, i have done some test edits with my bot check it's contributions, i have already requested for flag here, i always run it in main namespace and and category namespace, please cast your vote, thanks Mjbmr ^Talk 14:07, 6 January 2011 (UTC)

Contributions look good, but do we need another one? Do we just want to have as many bots as possible? Mglovesfun (talk) 14:41, 6 January 2011 (UTC)

if another bots can do same, why my bot has edits? i run it for checking in Persian Wiktionary but no other bot is active there to check pages, that's because of it --Mjbmr ^Talk 15:21, 6 January 2011 (UTC)

I don't really understand how language parameters work in templates, but is there some way that {{Morocco|lang=fr}} on a definition line could automatically generate Category:Moroccan French? Ƿidsiþ 06:47, 8 January 2011 (UTC)

Done. Regional context templates have default languages associated with them- should it default to French or to Arabic if no lang= parameter is specified? Nadando 18:48, 8 January 2011 (UTC)

Moroccan Arabic has its own language code {{ary}}, so setting it to French by default makes the most sense. -- Prince Kassad 21:02, 8 January 2011 (UTC)

I thought all regional context tags have English as default. (Certainly if KassadBot starts adding lang= to context tags, as I hope it will, defaulting to English makes sense.)​—msh210℠ (talk) 16:51, 10 January 2011 (UTC)

• Thanks! Ƿidsiþ 21:05, 8 January 2011 (UTC)

I've created this to allow me to turn language names into language codes. Is there already a list on this wiki of language names to codes, such as this? Otherwise I'll need to input as many languages as I need by hand. Mglovesfun (talk) 12:00, 11 January 2011 (UTC)

Hi, i have created a list here but needs review. Mjbmr ^Talk 18:16, 11 January 2011 (UTC)

Is User:autoFormat/Languages any useful to you? -- Prince Kassad 19:08, 11 January 2011 (UTC)

Looks like it could quite easily be converted, yes. Mglovesfun (talk) 23:53, 16 January 2011 (UTC)

Ah, but it gives codes then languages, so now I've converted it into a switch, it's the wrong way round. Basically I want to turn

fr=French

into

French=fr

Which I believe can be done by Regex. That would be the only remaining modification. Mglovesfun (talk) 14:08, 18 January 2011 (UTC)

For those unfamiliar with Navajo, the language has four basic vowels: a, e, i, o; and four basic flavors of each: oral vs. nasal and low tone vs. high tone. Nasality is marked using the ogonek, and tone is marked using the acute accent. For a, the four varieties would be a (oral low tone), ą (nasal low tone), á (oral high tone), and ą́ (nasal high tone). (Navajo also has a short vs. long distinction, but long vowels are simply indicated by doubling the relevant letter.)

The various Wiki sites have adopted the convention of using composed glyphs where possible, rather than using (glyph) + (combining diacritic). The relevant combining diacritics for Navajo are combining acute accent (Unicode hex point number 0301), and combining ogonek (Unicode hex point number 0328). Since there are no composed glyphs for the Navajo combination of nasal high tone, the Wiki sites use (glyph with ogonek) + (combining acute accent).

This particular combination causes problems with the lowercase letter i, as the combining acute accent and the tittle get in each other's way: į́.

The composed glyph (i with acute accent) renders as í, with the accent properly replacing the tittle of the i instead of over(lapping) it. It is then possible to add (combining ogonek) to produce the letter į́ without this tittle collision issue. However, while it is possible to deliberately enter (i with acute accent) + (combining ogonek) in the Wiktionary editing field, clicking either Save page or Show preview involves some behind-the-scenes glyph translation, resulting in (i with ogonek) + (combining acute accent) both on-screen and in the editing field.

I would dearly love to propose that the underlying MediaWiki software use (glyph with ogonek) + (combining acute accent), instead of (glyph with acute accent) + (combining ogonek). However, I have no idea what would be involved, and I'd appreciate it if someone more knowledgeable than I am could clue me in. -- Cheers, Eiríkr Útlendi | Tala við mig 00:06, 12 January 2011 (UTC)

Unicode specifies that below diacritics have priority over above diacritics. If this poses problems to you, use HTML entities: į́. Good fonts are supposed to get rid of the dot over the I even in the above case (DejaVu, for example, applies the correct behavior), but many fonts, including the default Windows ones, don't do this. -- Prince Kassad 00:27, 12 January 2011 (UTC)

Thank you for the explanation, Prince Kassad. How wonderfully annoying of Microsoft. FWIW, I just spent a while in MS Word going through all the fonts installed on my XP system here (more than a few), and the DejaVu proportional fonts were the only ones that exhibit the proper behavior. I've since reconfigured my browser prefs, which will certainly save me some eye strain. Now I'm curious to see if the fonts on Ubuntu at home do any better. -- Ahéheeʼ, Eiríkr Útlendi | Tala við mig 01:12, 12 January 2011 (UTC)

As Prince Kassad says, this is a font issue. See w:nv:Anáʼálwoʼ:System check, which shows two possibilities of how it should look, and two unacceptable ones. If your letters look wrong, it offers a couple of fonts that produce better results. —Stephen ^(Talk) 01:46, 12 January 2011 (UTC)

Thank you Stephen, that's a useful benchmark. As expected, Ubuntu's default fonts work properly. I'll have to use the font links from the w:nv:Anáʼálwoʼ:System check page to install a few other working fonts on my Windows machine at work tomorrow. -- Cheers, Eiríkr Útlendi | Tala við mig 07:18, 12 January 2011 (UTC)

The very common combination "{{etyl|de}} {{term|lang=de|weh}}" could be simplifed if {{term}} had another parameter, e.g. {{term|lang=de|etyl=1|weh}}. The introduction is minimalistic: if parameter etyl is present, initially call the existing etyl template:

{{#if: {{{etyl|}}}|{{etyl|{{{lang}}}{{#ifeq:{{{etyl}}}|1||{{!}}{{{etyl}}}}}}} }}

Here, support for the second parameter to {{etyl}} (the target language, where the derivation is found) has been implemented by giving etyl= another value than 1, e.g. {{term|lang=de|etyl=sv|weh}} or {{term|lang=de|etyl=-|weh}} --LA2 13:11, 13 January 2011 (UTC)

I would extend it so that the parameter can also be used to display the language without treating it as an etymology. This would make it useful for listing cognates. So for example disp=etyl would show it as an etymology, disp=lang would display only the language name without extras, and leaving it blank would display only the word. —CodeCat 13:41, 13 January 2011 (UTC)

Only displaying the language name is what "-" as the 2nd parameter to {{etyl}} does. In my case, the last example ...|etyl=-|... --LA2 14:18, 13 January 2011 (UTC)

Using that code, if a Guugu Yimidhirr word comes from German, you'd have to use {{term|lang=de|etyl=kky|weh}}, which would make the etyl parameter work exactly the opposite way the etyl template does: {etyl|de}} means (and presumably would continue to mean) that the etymon is German, while {{term|etyl=de would mean that the derived term is German. Isn't that too confusing? A different name for the parameter is in order IMO (assuming we do this at all).​—msh210℠ (talk) 17:05, 13 January 2011 (UTC)

Note that the way parser-functions work, this means that {{etyl}} would be called everywhere that (deprecated template usage) term is called. Sometimes the code it generates would end up in the wiki-text, and sometimes not, but it would always be transcluded and asked to generate code. —Ruakh_TALK 23:09, 13 January 2011 (UTC)

...which is a problem because {{etyl}} uses an ifexist function, and those are limited. -- Prince Kassad 23:11, 13 January 2011 (UTC)

Maybe this ifexist problem is the deciding argument against my proposal, but I also agree that the problem of having to explain the naming of etyl=kky is hard enough. So, what about a less ambitious plan: Could {{term}} optionally print the name of the language, and what would be a good parameter structure for this?

• Giving lang= a different name? {{term|lang_printed=de|weh}}
• Or adding a separate parameter? {{term|lang=de|printed_language_name=yes|weh}}
• Or giving term a different name? {{term_with_language_name|lang=de|weh}}
• Or is the existing structure the best? {{de}} {{term|lang=de|weh}} --LA2 21:16, 14 January 2011 (UTC)

Note, on the French Wiktionary we've done the opposite; {{etyl}} (fr:Modèle:étyl) allows word=, translation= and transliteration=. Mglovesfun (talk) 00:35, 15 January 2011 (UTC)

Category:es:Classical Nahuatl derivations and Category:is:Classical Nahuatl derivations have the categories Category:es:Classical Nahuatl language and Category:es:Classical Nahuatl language in them, respectively. Would someone please get rid of these? I know Category:Classical Nahuatl language belongs only in the main derivation category, but I don't know how to fix this. Ultimateria 21:16, 13 January 2011 (UTC)

Fixed. --Yair rand (talk) 21:33, 13 January 2011 (UTC)

Thanks! Ultimateria 00:58, 14 January 2011 (UTC)

I'm having trouble with the WT:RFDO redirect. Somehow it is not as updated as the actual project page target Wiktionary:Requests for deletion/Others as the RFDO redirect only shows entries on that page up to #Template:khi-kun (i.e. nominations like Category:English_greetings below this section are cut off) and has a discrepancy behind the actual target page. TeleComNasSprVen 21:27, 14 January 2011 (UTC)

I recently created a page for 忍阪 as an alternate spelling for 忍坂, and since the content for each is almost entirely identical, I used labeled section transclusion, as I began talking about over at WT:ES#Etymologies_of_忍坂. I just noticed that KassadBot has added {{rfc-subst}} to the 忍阪 page, but I'm not really sure why. I wouldn't consider labeled section transclusion to constitute "template subst detritus", but perhaps I'm misunderstanding something here. Could someone tell me what this means? -- TIA, Eiríkr Útlendi | Tala við mig 00:30, 15 January 2011 (UTC)

Your transclusion includes several headers. We usually try to keep the header structure in the wikitext rather than hidden in templates and the like. Firstly, this helps programs parse the pages (which may be why the page was tagged by KassadBot). Secondly, it helps an editor making changes. What if someone wants to change one of the sections of one page but not another (eg adding a usage note to just one of the entries)? This may be the main reason why labelled section transclusion is used so infrequently here. I'm not sure how to find a good balance. --Bequw → τ 04:50, 15 January 2011 (UTC)

Alternate spellings may present a special case. The issue I see with alternate spellings is that all content, including the headers, should probably be identical. By way of example, the only differences I'm aware of between the English words centre and center, AFAICT, are the spellings and the usage of those spellings, and a note about spelling usage should appear on both pages. The only differences between the Japanese for 忍坂 and 忍阪, similarly, are the spellings and the usage of those spellings, and a note about spelling usage should appear on both pages.

If two alternate spellings really do require specific content on one page but explicitly not on the other (which use case honestly escapes me at present), it would be possible to use separate sections for each heading item, inserting the heading-specific content in between, and while that does increase the amount of work required, it is still less work than manually entering everything multiple times, and it would still guarantee consistency across entries for those items that should be identical.

Without transcluding, entry content must be entered manually -- and this duplication also raises the likelihood of unwanted divergence between entries, such as we do indeed see with centre and center: for instance, the latter has various items that are lacking in the former, such as a more extensive etymology or 'related terms' and prepositional usage for the verb, despite the fact that these items are equally applicable to the English entries for both spellings. A quick comparison of the English entries for colour and color immediately shows similar issues of unnecessary divergence, where useful information about the term is only found under one or the other heading, despite being equally applicable to both spellings.

This unintentional hiding of information strikes me as antithetical to what a good dictionary should strive for. LST provides an easy technical solution to this problem -- for colour and color, for example, consolidate the English entry content onto one page, and then transclude onto the other. Content that should be identical is thus managed as one unit, in one place, and no one needs to worry about keeping track of multiple discrete items that should be kept in alignment.

And that's my 2p. I'm interested in seeing what other folks might think. -- Cheers, Eiríkr Útlendi | Tala við mig 20:27, 15 January 2011 (UTC)

If the two spellings are really so equivalent that LST can be used, then in my opinion, they shouldn't both have full entries: one should be an {{alternative spelling of}} the other. —Ruakh_TALK 20:47, 15 January 2011 (UTC)

That sounds good for 忍阪 and 忍坂; I'll look into how that's used and apply it to these two later today. However, I wonder if this might not work as well for pairs where the spelling diverges along national or regional lines, like centre and center, or color and colour, given the politics that would come to bear upon choosing one entry as the primary. But perhaps this concern is moot? -- Eiríkr Útlendi | Tala við mig 20:22, 16 January 2011 (UTC)

But content will not be identical, especially on fuller entries (which we strive to have). The etymologies, inter-definition content (quotations and example sentences), and alt-form listings will all be different as they must reference the exact spelling. Possibly we could have one "merged" entry treating all alternative spellings and then transclude that section on the other pages. --Bequw → τ 17:08, 17 January 2011 (UTC)

Note re rfc-subst, you used to be able to do {{subst:w|link goes here}}, but it's not subst'able anymore. Mglovesfun (talk) 19:13, 17 January 2011 (UTC)

Fixed, thanks (using the magic of Conrad.Irwin (talk • contribs)'s safesubst:). —Ruakh_TALK 21:14, 17 January 2011 (UTC)

Is anyone willing to make me a list of phrasal verb entries in Wiktionary which are not in Category:English phrasal verbs. I assume it can be generated somehow by searching entries which match the pattern VERB PREPOSITION.--Downunder 02:20, 15 January 2011 (UTC)

That is a crazy assumption, however I think I could get you a list of all multi-word entries which have an English section which contains a Verb POS header and are not in the English phrasal verb category, if that would suffice. - DaveRoss 03:35, 15 January 2011 (UTC)

Thanks, that would bring me so much pleasure, Dave. Can I request it at User:Downunder/phrasals please. --Downunder 11:01, 15 January 2011 (UTC)

The crazy assumption makes me ask: wouldn't it be nice/useful/fun to parse multiword expressions that are entries? Certainly many would not even be the least controversial (eg Noun-Noun(head) compounds). Proverbs would be the most complex. I'm sure that we could come to terms (if necessary on a language-by-language basis) on the terminology and format to be used. On the technical side, is there a way to convert a standard notation to a labeled graphic or character-based pseudographic that yielded a tree diagram? DCDuring TALK 11:12, 15 January 2011 (UTC)

Going even further, it would nice if non-techheads could find ways to fiddle with Wiktionary data, like the data dumps. Maybe a page like Help:How to play around with Wiktionary data dumps --Downunder 19:54, 15 January 2011 (UTC)

I really think the only way to play around with Wiktionary data dumps is to become a techhead. ;-)   We can take steps to make it easier for programmers to use the dumps (e.g., create dump-manipulation libraries in common languages, or cookbooks for common types of tasks), but I don't think non-programmers are going to be able to accomplish any interesting things. (Though I could imagine an audience for a Wikibook that teaches you how to program, using WMF-related programming tasks as a starting point -slash- motivator. b:Perl for Wikimedians, say.)
—Ruakh_TALK 20:52, 15 January 2011 (UTC)

A few techheads have helped on such matters in the past, but seem to be less active lately.

My query about a tree-generator template is aimed at something that might be of value to users, but would require human activity to make it work right. If someone knows how to do it, there might be pretty good leverage of user value to tech effort. It would potentially be valuable on every Wiktionary that had multi-word entries. DCDuring TALK 00:30, 16 January 2011 (UTC)

Learn regular expressions and the world is your oyster. - DaveRoss 03:28, 5 February 2011 (UTC)

Can someone please make a list for me of Catalan nouns, verbs, and adjectives that use {{infl}} (that aren't in Category:Catalan noun forms, Category:Catalan plurals, Category:Catalan verb forms, or Category:Catalan adjective forms) so I can replace it with the correct template and expand the entries/fix plurals/etc? Ultimateria 02:48, 16 January 2011 (UTC)

User:Ultimateria/ca-infl is, hopefully, a list of all entries where a line contains \{\{\s*infl\s*\|\s*ca\b and the implicated template call won't result in the entry being added to any of the categories you mention, together with a copy of the line in question. I didn't do any additional filtering based on other ways that the entries might be in a category that you mention (e.g. due to a manual categorization), but looking at the list, I don't think such filtering would have removed too many, anyway. —Ruakh_TALK 06:17, 16 January 2011 (UTC)

Thanks! Wow, that's a long list. Ultimateria 16:36, 16 January 2011 (UTC)

I've done all the adverbs, all 144 used {{ca-adv}} with the sort parameter used when needed. Mglovesfun (talk) 19:18, 17 January 2011 (UTC)

Do these serve different functions in any way? As I understand it, it's possible to modify one's Javascript to have these two displays different things. But even for people who've done this, I think the templates are used interchangeably, so the only effect of changing the display would only tell you which template is being used, not offer any additional information. I'd considered listing this directly at WT:RFM, but that page gets ignored quite a bit. Mglovesfun (talk) 12:32, 16 January 2011 (UTC)

Oh the links; {{qualifier}}, {{italbrac}}. Mglovesfun (talk) 12:34, 16 January 2011 (UTC)

I think of {{italbrac}} mostly as a cleanup template; it's just half a step above writing (''US''). But it's not always misused to mean {{qualifier}}; for example, just now I fixed some formatting on ], which included replacing {{italbrac}} with {{sense}}. —Ruakh_TALK 15:52, 16 January 2011 (UTC)

Erm, so it's misused in other ways? Mglovesfun (talk) 23:33, 16 January 2011 (UTC)

Exactly. —Ruakh_TALK 18:03, 17 January 2011 (UTC)

When I'm working with big templates I often notice that a lot of the code is just repeated over and over. I'm not sure how efficient Mediawiki is with that but it's still kind of ugly. So I was thinking, couldn't there be an extension to add definable constants to templates? Or maybe there already is one, I don't know. But I imagine it would work something like this:

{{{stem2={{#ifeq:{{{2|}}}|-|{{{1}}}|{{{2}}}}}}}}

It looks just like a parameter name and it would be handled the same way by the underlying code. But it has an = sign after it which allows you to assign a value to it. It's also a constant so it can't be modified, and it would have to be defined before it's used (the scope is from the definition to the end of the template). I'm not quite sure what should happen if a constant and a parameter name clash, but I imagine the constant would just hide the parameter. This would allow you to override parameters and provide them with a default, so you can do things like:

{{{head={{{head|{{PAGENAME}}}}}}}}

And then you could just use {{{head}}} everywhere, without having to worry whether it's set or not. So, what do you think, would this be a useful thing to add? —CodeCat 14:50, 16 January 2011 (UTC)

You might be interested in the existing solution by User:VasilievVV to turn templates into a real programming language: Extension:InlineScripts. I have no idea if the Wikimedia Foundation will activate this on any sites, but any new extension would have the same problem. One way that some templates circumvent this today is by calling a second template with new parameters, which a known way to emulate variables. --LA2 20:43, 16 January 2011 (UTC)

I'm not entirely clear on what the prerequisite extensions are, but this link seems to describe what you're talking about. -- Eiríkr Útlendi | Tala við mig 08:30, 17 January 2011 (UTC)

We have ParserFunctions installed on this wiki (it is what gives us #ifeq etc.) but not StringFunctions. StringFunctions deals mainly with functions aimed at manipulating strings, substrings, concatenation, regex matchers etc. Neither one, I think, allows you to create constants within a template. - DaveRoss 11:06, 17 January 2011 (UTC)

It would be nice, but it ain't gonna happen, sorry. See ] for an existing extension that does that (though your syntax is arguably nicer), and ] for the opinions of Tim Starling and other developers about installing said extension on the English Wikipedia. If a single template has a lot of such constants to compute, then the best thing is (as LA2 (talk • contribs) suggests) to compute all of them and pass them in as parameters to a "private" helper template. —Ruakh_TALK 21:04, 17 January 2011 (UTC)

Thanks for the Bugzilla link. Unfortunately, the thread there was rather sparse on details; all I got from it was that the higher-ups really don't like mw:Extension:VariablesExtension, but I'm left scratching my head as to why. I don't suppose anyone has more information? -- Curious, Eiríkr Útlendi | Tala við mig 22:34, 18 January 2011 (UTC)

The underlying rationale is that the template language isn't a programming language, and that patches to make it more programming-language–like are misguided. There's kind of a running fight about this sort of thing; note, for example, that {{#if: and its ilk are implemented as "functions" rather than as built-in operators, such that {{#ifeq:foo|bar|{{foo}}|{{bar}}}} works by evaluating foo, bar, {{foo}}, and {{bar}}, and only then comparing foo to bar and returning the result of {{bar}}. —Ruakh_TALK 15:24, 19 January 2011 (UTC)

So if I understand all this correctly, would it be fair to cast this as a philosophical argument? Only the issues raised in the ] thread didn't seem to deal much with practicalities (that I could see). -- Eiríkr Útlendi | Tala við mig 18:29, 19 January 2011 (UTC)

Re: philosophical argument: Yes, that's an apt description. So far as I know, there aren't any specific negative consequences anticipated to result from adding this programming-language–like feature, only a general philosophical objection to making the template language too programming-language–like (for some value of "too"), and perhaps a slippery-slope–type concern that one such modification begets another. —Ruakh_TALK 18:40, 19 January 2011 (UTC)

Based on {{rfd}}, I was gonna add namespace switches to {{rfd-sense}}, {{rfv-sense}} and {{rfc-sense}}. This is since Prince Kassad nominated Category:German States for RFV, stating "Apparently, you can RfV categories. Wow, I'm certainly surprised." So {{rfv}} already has a namespace switch. IMO we should allow main namespace (obviously) transwiki (also fairly obvious) and appendix, because some appendices have definitions, like those in Category:Lingua Franca Nova appendices. Any objections? Mglovesfun (talk) 11:16, 17 January 2011 (UTC)

I would definitely agree on the appendix part, for the reasons you stated and also because of appendix-only languages. —CodeCat 12:59, 17 January 2011 (UTC)

Related to an earlier post, I've prototyped a customization to the "enhanced editing toolbar" (new fangled, top one) that may be able to simplify our editing a bit. User:Bequw/CustomToolbar.js (also in WT:PREFS) adds pages to the "Special characters" section for the scripts that were in Mediawiki:Edittools, but weren't above. It's not done yet, but I wanted to see if there were any show stoppers in this implementation. Specifically the character insert pages are just grids of characters so there's no formatting we can add (that I know of) like separators, subheadings (eg "vowels"), or script encapsulating templates. Will this cause any usability hardship? If not, I think it would be simpler (and probably lighten the download) if all the character inserting sections were to be moved up and unified in the top toolbar (for those that use the enhanced editing toolbar). Missing characters in the existing pages can be inserted. Down the road we even could add other sections, such as image-buttons to aid in inserting the sign language transcriptions. --Bequw → τ 22:44, 18 January 2011 (UTC)

I had some bad performance problems with the editing toolbar and dumped it on every MW project that allows me to. Is there any way to improve performance? Was I just not patient enough? Was it a FF problem, rendered obsolete by Chrome or FF4? DCDuring TALK

Its always taken about a second on my computer (FF 3.6, Chrome beta) for the subsections ("Advanced", "Special characters", "Help") to load and drop down. Maybe a bit more the first time, but nothing too noticeable. --Bequw → τ 16:47, 19 January 2011 (UTC)

I'm starting up an interwiki bot (see Wiktionary:Votes/bt-2011-01/User:Rukhabot for bot status), and I have a few questions:

• Wiktionary:Bots says that a bot should "limit its edits to a rate of one or just a few per minute". Is that accurate? Somehow I thought the recommended rate-limit was something like one edit every ten seconds? Currently there are almost 300,000 entries that need new interwiki links, so I'd like to go about as fast as y'all'll let me get away with. ;-)
• Wiktionary:Links says that interwiki links "are listed in alphabetical order by language code".
  • I've noticed that on many pages they're not quite in that order. Should I re-order existing interwiki links to conform to this rule?
  • Where Wikimedia language codes differ from ISO language codes (see Wiktionary:Wikimedia language codes), this means the former, right? For example, zh should precede zh-min-nan (ISO nan) and zh-yue (ISO yue), right?
• Added later: Also, should our redirect pages have outbound interwikis? For example, should ], which is a redirect to ], have interwiki-links to ] and so on? (Obviously that's a low priority, even if "yes".)

—Ruakh_TALK 15:51, 19 January 2011 (UTC)

AFAICT/IMO "a few per minute" can be taken to mean one every ten seconds. And AFAI'm concerned, go ahead with twelve or fifteen a minute after it's been in business for a coupla days (so you know it's not erring). WT:BOTS gives the rate limit only as "a well-run bot is careful to..." in the "Technical advice" section....​—msh210℠ (talk) 16:13, 19 January 2011 (UTC)

Re redirects: Yes!​—msh210℠ (talk) 18:44, 19 January 2011 (UTC)

If pages have different titles on for example fr.Wikt (fr:AB) and en.Wikt (en:BC), but en.Wikt has a page with the French title that redirects to the English title (en:AB redirects to en:BC) and fr.Wikt has a corresponding redirect, how are the pages supposed to be interwiki-linked? Would "BC" on the English Wiktionary contain a link to "AB" on the French Wiktionary, or to "BC"? - -sche 02:05, 31 January 2011 (UTC)

Each one's entry would have an interwiki-link to the other's redirect: en:BC would have a link to fr:BC, and fr:AB to en:AB. And, per msh210 above, each one's redirect would have an interwiki-link to the other's entry; but I'm not doing that part yet, because there are just so many missing interwikis that it doesn't seem worth it to waste the bot's limited edits-per-minute on them. (More generally, I'm prioritizing edits according to various rules, until we catch up on the backlog.) —Ruakh_TALK 02:52, 31 January 2011 (UTC)

The edits per minute limit is primarily to prevent a bot from bogging down the site for everyone else. MediaWiki and the servers have come a long, long way since those suggestions were written and until our bots catch up with the thousands of edits per minute that Wikipedia gets I would say let your processor be the limiting factor, get the work done. If it is editing fast enough to slow everyone else down then restrict it, but I would be shocked if an interwiki bot was able to do that. - DaveRoss 19:24, 7 February 2011 (UTC)

I'm pretty certain that something like {{ #if: | {{foo}} }} used to add a page to Special:WhatLinksHere/Template:foo; but that's not the case now. It also doesn't list Template:foo in the "Template(s) used in this preview" section at the bottom of a preview page. This makes me wonder . . . have parser-functions been changed? Does {{ #if: | {{foo}} }} no longer actually load Template:foo? Or is it just a "surface" change, where the UI recognizes that the loaded template doesn't end up displaying, so it doesn't list the page at Special:WhatLinksHere/Template:foo and whatnot? Because, if the former, then that's a huge deal. It will greatly simplify template "programming". A lot of proposals that come through the GP are things that have seemed like bad ideas because they'd result in some minor template being called on every single page (via {{term}} or whatnot), but if that's no longer the case . . .

Does anyone know?

—Ruakh_TALK 19:25, 19 January 2011 (UTC)

Simple way to test: just save a page with 501 potentially loaded templates with expensive parserfunctions and see if it's overloaded. --Yair rand (talk) 19:32, 19 January 2011 (UTC)

Apparently it does not load the template. --Yair rand (talk) 19:40, 19 January 2011 (UTC)

Awesome! —Ruakh_TALK 20:41, 19 January 2011 (UTC)

Some context tags linkify their respective labels, like template:British which has label=]. Currently, these are in one parameter, label. If we split it into two, label=UK | link=British English, we can then have other templates call only one of them (the label or the link). Unfortunately, I no longer remember why I wanted to do that: It's very useful for something, but I forget what. But I thought I'd post it here lest the idea completely escape my mind.​—msh210℠ (talk) 21:03, 19 January 2011 (UTC)

Ah, I remember now why this would be a good thing. Up the page, in ], I suggested that {{rfp}} categorize by requested dialect. Q.v. The suggestion was that it do so based on {{isValidPageName|{{accent:{{{1}}}|l=}}}}, but it could search, in absence of such an accent tag, for a context tag, and, if we split out labels from categories in context tags, it can categorize using the context tag's label.​—msh210℠ (talk) 07:25, 30 January 2011 (UTC)

I've considered something similar, but this overloading is probably too much for one template. Keep it simple. DAVilla 03:41, 27 February 2011 (UTC)

There are certain cases, in which disablement of italics in transcriptions is necessary, e. g. ŠU.ŠI in إبهام#Etymology: the name of the cuneiform signs, ŠU.ŠI, ought to be capitalised and non-italicised. How can the italics be disabled? Encircling the word with '' '' seems to misfire. The uſer hight Bogorm converſation 08:33, 20 January 2011 (UTC)

Are you sure about calling that a transcription? The names of the characters don't transcribe the word. I'm not sure where in {{term}} to put that information, but tr= seems incorrect. Nadando 17:47, 20 January 2011 (UTC)

ŠU.ŠI is not the transcription. The transcription is ubānu, but ŠU.ŠI (the names of the characters) is inexpendable for users who are unable to see the cuneiform signs in Unicode. The uſer hight Bogorm converſation 21:08, 20 January 2011 (UTC)

This is just an announcement for those interested that I've been working on extending MewBot to do forms of Finnish verbs. The test edits have been working nicely so far. It currently only supports {{fi-conj-sanoa}}, but it should be easy to extend it for the other templates. —CodeCat 16:07, 26 January 2011 (UTC)

Now that Conrad.Irwin (talk • contribs) is not editing until further notice, does anyone know how to and have to willpower to build an archive bot of RFD, RFV RFC and RFDO (all of them, if possible). I've been mindlessly copying and pasting deletion debates for nearly and hour now. Mglovesfun (talk) 11:56, 27 January 2011 (UTC)

If you add this code to the page rei'ittyä and then preview it, it will show it as 'not equal':

{{#ifeq:rei'ittyä|{{PAGENAME}}|equal|not equal}}

This is quite strange because the page name is exactly what it should be. Does anyone know why this is happening? —CodeCat 01:04, 28 January 2011 (UTC)

PAGENAME translates all "'"s into "&#39;"s. --Yair rand (talk) 01:07, 28 January 2011 (UTC)

I see... is there any way around this then? The template needs to check whether the outcome of a certain combination of parameters matches the name of the page it is on (so that it can catch mistakes). —CodeCat 01:11, 28 January 2011 (UTC)

Yes, there is: I've just tried a bunch of things, and apparently the {{ localurl: … }} magic word translates &#39; back into '; so

{{ #ifeq: {{ localurl: {{PAGENAME}} }} | {{ localurl: rei'ittyä }} | equal | not equal }}

at ] will evaluate to equal.
—Ruakh_TALK 03:52, 28 January 2011 (UTC)

Or, even simpler:

{{ #ifeq: {{PAGENAMEE}} | {{ urlencode: rei'ittyä }} | equal | not equal }}

—Ruakh_TALK 03:55, 28 January 2011 (UTC)

Actually, strike that second one, sorry. It works at ], but if there's a space in the pagename, {{PAGENAMEE}} will convert it to an underscore whereas {{ urlencode: … }} will convert it to a plus-sign. MediaWiki 1.17 will provide a variant of the latter that would convert it to an underscore, but there's no reason to wait for that. —Ruakh_TALK 04:03, 28 January 2011 (UTC)

Yes, that fixed it! Thank you! —CodeCat 10:35, 28 January 2011 (UTC)

I am puzzled (rather easily done with me when it comes to templates). {{el-nF-η-εις-3b}} rejects/ignores a variable >=12 characters long, but only in the genitive plural position. This variable works fine for other table positions - and I cannot find the same bug in any other of this series of templates.

Older or formal genitive singular: 123456789a-εως (123456789a-eos)

-

Older or formal genitive singular: 123456789ab-εως (123456789ab-eos) Can anyone help? —Saltmarsh^{απάντηση} 07:38, 29 January 2011 (UTC)

Table now widened to improve view - so please ignore this - I need new glasses —Saltmarsh^{απάντηση} 07:41, 29 January 2011 (UTC)

When one clicks on ± to edit translation glosses, the symbol "±" remains active. I have to press Tab to focus the text box to start editing it. I would like the focus to be automatically transferred to the text box once ± is pressed. --Daniel. 19:36, 29 January 2011 (UTC)

I tried but I suck at JS. —Internoob (Disc•Cont) 22:11, 29 January 2011 (UTC)

Done. Hopefully it won't blow up on some browsers... --Yair rand (talk) 21:44, 30 January 2011 (UTC)

Thanks! It worked on my Firefox. Now, can you (or anyone else) make an additional change?

Rather than simply placing the cursor at the end of the gloss, please make the gloss completely selected, because the idea is most likely always changing it. --Daniel. 00:20, 31 January 2011 (UTC)