I just stumbled across a fun issue where my Linux keyboard can easily output a single right quotation mark ’ at Unicode point U+2019, but cannot easily output a modifier letter apostrophe ʼ at Unicode point U+02BC. The modifier apostrophe is used in Navajo entries here on WT to represent the glottal stop and ejective consonants.

Visually, these are identical in many of the fonts I've tested them in, including in the default WT display font and the default WT editing font. However, WT recognizes these differently in both the URL bar and the search feature. I very nearly created an entry for a missing Navajo term before I realized that this was just an encoding hiccup, and the term already exists.

Does anyone know of an easy way to tweak the search feature to suggest an entry with the modifier apostrophe when a user enters a term using the single quote instead? -- TIA, Eiríkr Útlendi │ Tala við mig 22:00, 1 April 2012 (UTC)

This might be part of bug 4430, which no one is working on. —Michael Z. 2012-04-06 20:11 z

That sure looks like it. Thank you, Michael. I certainly wouldn't have found that on my own. -- Eiríkr Útlendi │ Tala við mig 22:17, 6 April 2012 (UTC)

If you think it's worthwhile, we could create redirects from the quotation-mark entries to the modifer-apostrophe entries, just like we create redirects from c’est la vie to c'est la vie. - -sche (discuss) 16:24, 7 April 2012 (UTC)

I can never remember which categorization templates use {{{skey}}} and which use {{{sort}}}. Would anyone object if I added the missing param name to the various cat templates? -- Eiríkr Útlendi │ Tala við mig 23:57, 3 April 2012 (UTC)

It seems to me that we should probably decide on a standard, and then bot everything to match that standard. I don't know about anyone else, but all the templates I use utilize 'sort'. I've never encountered 'skey'. -Atelaes λάλει ἐμοί 00:43, 4 April 2012 (UTC)

{{context}} uses skey, that's the only one I'm aware of. Mglovesfun (talk) 09:20, 4 April 2012 (UTC)

I'm reasonably sure I've seen {{{skey}}} in more places, but I can't think where. It's been more of an occasional annoyance when I run into it. I just thought I'd ask if anyone would be upset if I added {{{sort}}} the next time I ran into {{{skey}}}. (I was thinking I should leave {{{skey}}} in place as an existing feature that other pages probably already use.) -- Eiríkr Útlendi │ Tala við mig 15:20, 4 April 2012 (UTC)

Possibly in some Japanese templates. It rings I bell, but it's not like I often edit Japanese templates. Mglovesfun (talk) 20:41, 4 April 2012 (UTC)

I just added {{{sort}}} to the {{context}} template as a synonym for the {{{skey}}} param. — This unsigned comment was added by Eirikr (talk • contribs). doh, signing now... -- Eiríkr Útlendi │ Tala við mig 02:58, 5 April 2012 (UTC)

That's good for me, as I often copy a sort=foo down the page, but for context labels, have to change it to skey=foo. Mglovesfun (talk) 12:14, 5 April 2012 (UTC)

I did {{idiomatic}} earlier, as that also used just {{{skey}}}. There's still some grotty code towards the bottom of {{context}} that seems to use skey in an expr statement that calls something else. I haven't bothered parsing the code enough to figure out what it's calling; I might do that later when I'm not so busy.  :) -- Eiríkr Útlendi │ Tala við mig 18:48, 5 April 2012 (UTC)

You really shouldn't have modified {{context}} without understanding the basics of how it works. It's one of our most important and most widely-used templates; it was carefully designed by our most skilled and technically-minded editor; and it's not to be trifled with. But to answer your implicit question . . . {{context}} calls {{context 1}}, which calls {{context 2}}, and so on. I actually think that most of the expr logic is obsolete now, but again, this template isn't to be trifled with. —Ruakh_TALK 22:55, 5 April 2012 (UTC)

Note that adding sort= to {{context}} without adding it to all context templates could be counterproductive, since I think most editors would expect (e.g.) {{context|basketball|sort=foo}} and {{basketball|sort=foo}} to behave identically. It's also potentially confusing that {{context}} now supports skey=, skey2=, and sort=, but not sort2=. —Ruakh_TALK 22:55, 5 April 2012 (UTC)

Thanks Ruakh, I didn't notice skey2. I'll get to that. -- Eiríkr Útlendi │ Tala við mig 23:05, 5 April 2012 (UTC)

Gah, thassalotta context templates. Anyone have a bot set up for tweaking those? -- Eiríkr Útlendi │ Tala við mig 23:06, 5 April 2012 (UTC)

I could do it, but I'd have to do the protected templates separately. I do think it's worth it, to have all templates accept sort, and not (only) skey or cat. Mglovesfun (talk) 10:37, 6 April 2012 (UTC)

Anyone object? I think it's a very good idea. Mglovesfun (talk) 22:18, 6 April 2012 (UTC)

I wouldn't, but I'd prefer if it's just made 'sort' everywhere, without 'skey'. Could your bot also modify any uses of 'skey' in entries? —CodeCat 00:41, 7 April 2012 (UTC)

Yes and no. Not using only regular expressions, because the skey can appear anywhere in a template, and I can't code for every single possibility. It would be possible to change all examples skey to sort in the main namespace, using a one-to-one text replacement (that is, a straight swap). But it'd be a big task. Mglovesfun (talk) 10:17, 11 April 2012 (UTC)

Done I think. Mglovesfun (talk) 15:59, 11 April 2012 (UTC)

For some reason these pages all have #] added to their links. Why is that? —CodeCat 22:11, 6 April 2012 (UTC)

I don't see it. I'll clear my caché now and try again. Mglovesfun (talk) 22:19, 6 April 2012 (UTC)

I do see it. No idea what causes it. -- Liliana • 00:24, 7 April 2012 (UTC)

Its subcategory Category:Proto-Indo-European athematic nouns is fine... —CodeCat 00:39, 7 April 2012 (UTC)

• The first line of the cat page's source is {{poscatboiler|ine-pro|nouns}}, which looks like it's probably related. -- Eiríkr Útlendi │ Tala við mig 00:41, 7 April 2012 (UTC)
  • Yes it is related. When I removed the template, the problem went away too. —CodeCat 01:02, 7 April 2012 (UTC)

Every page in this category links to Template:ine-pro/script! The same problem is with Category:Proto-Slavic nouns, every page links to Template:sla-pro/script. Maro 21:55, 11 April 2012 (UTC)

• My fault. The problem came from Template:catfix and the associated script. The template was using the first parameter given to poscatboiler to find the correct language name, but Template:ine-pro doesn't exist, so the result of attempting to tranclude it is ]. I've modified Template:catfix to use langprefix, so this should be fixed now. --Yair rand (talk) 20:23, 15 April 2012 (UTC)

I use tabbed languages and for some reason the category Category:Requests for pronunciation (Mizo) is placed on the Dutch tab, even though the {{rfp}} template is in the Mizo section. Category:Mizo adjectives is placed right, though. —CodeCat 23:51, 6 April 2012 (UTC)

Is it OK now that the link is blue? DCDuring TALK 00:59, 7 April 2012 (UTC)

Strangely, yes... but isn't that just because the RFP category is a hidden category? —CodeCat 01:01, 7 April 2012 (UTC)

I just took a stab at a fix. Some templates and/or JS seem not to handle even fairly common non-standard conditions. I couldn't do better or tell you why the template doesn't handle hidden-category or any category redlinks. DCDuring TALK 03:42, 7 April 2012 (UTC)

BTW, some of the Mizo (lus) language category pages I added to help welcome a Mizo-N contributor are defective because I could not figure out how to our baroque system of category templates works. Someone with a higher pay grade than I should fix them and document accessibly (ie, with plenty of links) what's required to add a starter set of categories for a language. DCDuring TALK 03:53, 7 April 2012 (UTC)

On a somewhat tangential question. Could I get a quick answer on who uses tabbed languages, and if they think they're ready for prime time? It's my opinion that they're polished enough, intuitive enough, and just so damned superior to our current default setup that we should consider making them our default setup. -Atelaes λάλει ἐμοί 07:34, 7 April 2012 (UTC)

I don't use tabbed languages; while it's certainly a cleaner and more concise interface if you're looking at terms for a specific language, I'm enough of a language geek that I'm happier seeing all the languages in a single-window kind of interface.  :) -- Eiríkr Útlendi │ Tala við mig 15:12, 9 April 2012 (UTC)

I use and love them. —Ruakh_TALK 15:41, 9 April 2012 (UTC)

I use them and I prefer them. Sometimes I miss having a ToC, but not enough to go back. —Stephen ^(Talk) 16:44, 9 April 2012 (UTC)

Like Eirikr, I prefer to see all the language sections at once, so I don't use tabbed languages. We do regularly get WT:Feedback like "why don't you have a entry for the German word man", which we must answer by saying: we have a German section if you just scroll past the English. I'm not sure whether tabs would make it harder or simpler for new users to find the German (etc) sections. If we turn tabs on by default, can we give IPs the option of turning them off, or is that infeasible? - -sche (discuss) 18:48, 9 April 2012 (UTC)

• Frankly, I'm just plain baffled by folks who haven't figured out how to scroll a web page. Would tabs really help such people, or just introduce something else for them to be confused about? Or perhaps tabs would lead to a new and different population of confused website users? -- Eiríkr Útlendi │ Tala við mig 20:28, 9 April 2012 (UTC)
  • I prefer tabbed languages because it allows me to more readily see only what I need to see, instead of having to scroll all the time and visually separate the signal from the noise. —CodeCat 21:35, 9 April 2012 (UTC)

Like Ruakh, Stephen, and CodeCat, I use tabbed langs and like them a lot, although sometimes I wish they were better at reading my mind. ("Yes, I know last time I looked up a word I was looking for the French word, but this time I'm looking for the English word, you should know that!") —Angr 08:49, 12 April 2012 (UTC)

That is why I proposed making a language for {{term}} required at all times, and using {{l}} in favour of raw links. —CodeCat 12:24, 12 April 2012 (UTC)

See tail wagging the dog. DCDuring TALK 13:26, 12 April 2012 (UTC)

I understand DCDuring's concern here, but I also think it's just generally good form to be specific when linking. I've found it a bit frustrating when I click a link and expect to see, say, the Spanish entry, and instead I get an English or translingual entry with Spanish somewhere down towards the bottom. It's just plain confusing at best, and quite irritating in most other respects. -- Eiríkr Útlendi │ Tala við mig 18:02, 12 April 2012 (UTC)

I agree. The tabbed-languages feature exacerbates certain problems — links that don't specify a language section, images and infoboxes in lede text, etc. — but those things are problems even without the feature. —Ruakh_TALK 19:35, 12 April 2012 (UTC)

Can anyone think of any technical flaws that need to be addressed before this gets taken to the BP for a pre-vote discussion? Yair hasn't been terribly active of late, but they might be willing to tweak the code a little bit if renewed interest was shown. Barring that, I'm sure they wouldn't object to anyone else working on it. -Atelaes λάλει ἐμοί 13:25, 12 April 2012 (UTC)

The problem has just reappeared on broom. Category:nl:Chemical elements is appearing on the English tab, not on the Dutch tab where it belongs. —CodeCat 19:31, 16 April 2012 (UTC)

My tabbed languages have suddenly disappeared, even though I still have the box checked under Gadgets on my Preferences. —Angr 21:59, 18 April 2012 (UTC)

Same here. I assume it relates to the latest software upgrade. For now I've fixed it — mostly — by changing the gadget not to use ResourceLoader. (I don't know why that would fix it, but ResourceLoader has been buggy in the past, so it seemed like a reasonable thing to try first.) —Ruakh_TALK 22:52, 18 April 2012 (UTC)

All I had to do was resave my preferences on Special:Preferences, and do a cache refresh, and the tabbed languages reappeared. I don't really know if both of those actions were necessary, but the combination fixed it. -Atelaes λάλει ἐμοί 00:23, 19 April 2012 (UTC)

I'm pretty sure I had already tried those, but just to be sure, I just changed it back to use ResourceLoader and tried those again, and it still doesn't work for me. Does it still work for you? —Ruakh_TALK 01:52, 19 April 2012 (UTC)

Yep. Still works fine for me. -Atelaes λάλει ἐμοί 01:59, 19 April 2012 (UTC)

And now it's broken for me, although it wasn't broken for me at all before this change. I'm getting the error mw.loader::execute> Exception thrown by ext.gadget.TabbedLanguages: Cannot call method 'cookie' of undefined, which seems to mean that $ is undefined here, which is very weird, especially since jQuery functions fine. I'm going to try making $ equal jQuery inside the script and see if that fixes it... --Yair rand (talk) 02:57, 19 April 2012 (UTC)

That worked. Rather odd. --Yair rand (talk) 03:17, 19 April 2012 (UTC)

I did absolutely nothing at all except go to bed and get a good night's sleep, and now they're back for me. Maybe tabbed languages are set up to stop working when the user is sleepy. —Angr 07:31, 19 April 2012 (UTC)

This box seems to now take two lines. I didn't like it, never used it, when it was just one. How can I disable it. I didn't find anything at either my Wiktionary:Per-browser_preferences or my Special:Preferences pages that seemed to apply. Might it be in my Javascript? Or can JS be used to disable it? DCDuring TALK 14:52, 7 April 2012 (UTC)

The box doesn't have an id or class, so it can't be easily hidden with CSS. My suspicion is that you'd have to do some JS-fu to get rid of it, but I don't know what script is creating it, and don't have the ambition to go looking. -Atelaes λάλει ἐμοί 00:08, 8 April 2012 (UTC)

It's one of those things I don't remember voting on, possibly produced by someone who's gotten bored with maintenance. Yet another reason to vote no for "improvements" and not participate in experiments, a useful checkbox on the "my preferences" tab. Do other folks have the box? Has it ever misbehaved for them? DCDuring TALK 00:24, 8 April 2012 (UTC)

I think that's an overreaction. Our formats (all of them, that of viewing, editing, maintaining, etc.) are absolutely terrible, and will never get better without people tinkering. I remember when every edit had to be pulled up in order to mark as patrolled, whereas now popups displays the edit, and I can mark it patrolled directly from recent changes or my watchlist. I remember before we had Conrad's auto translation adder, and every anon translation was incorrectly formatted and had to be manually looked at and usually fixed. We've made a lot of progress. That being said, this little deletion box should be made more easily manipulated, either directly on the box, or at least in PREFS. It shows up in any list of changes (recent changes, watchlist) that has new entries in it, and it is taking up two lines, and I am similarly irked by it. Just don't throw the baby out with the bath-water. -Atelaes λάλει ἐμοί 00:55, 8 April 2012 (UTC)

It's a matter of trust. For the most part: in the past I had it; now I don't. I might be willing to experiment on specific things authored by specific folks. DCDuring TALK 01:39, 8 April 2012 (UTC)

Ok, it looks like the culprit is MediaWiki:Gadget-PatrollingEnhancements.js, specifically an recent edit made to this script by Ruakh. I suggest you nudge them. -Atelaes λάλει ἐμοί 01:55, 8 April 2012 (UTC)

Thanks. I'll know to look there in the future. DCDuring TALK 03:02, 8 April 2012 (UTC)

Indeed, this was my doing. (Sorry, I didn't notice this discussion until now.) Should I undo it? Should it be off-by-default (opt-in)? Is there anyone with UI design skills who can make it less ugly and/or less screen-real-estate-intensive? —Ruakh_TALK 19:37, 9 April 2012 (UTC)

It didn't always take up two lines, as best I remember, so perhaps it is just something in the April 4 edits. Though it was/is not elegant, it was less intrusive at only one line. DCDuring TALK 22:08, 9 April 2012 (UTC)

Yes, it used to just be a single line: you could type a deletion-reason, but there was no drop-down box with the prefab deletion-reasons. —Ruakh_TALK 13:20, 10 April 2012 (UTC)

Good idea; it takes up a little extra space in the bottom right corner, which is generally empty anyway. Mglovesfun (talk) 10:14, 11 April 2012 (UTC)

{{an-noun}} needs to be adjusted. All the nouns wind up listed in Category:Aragonese nouns lacking gender even though their genders are properly marked. When the gender is marked, it should be removed from the category. —Stephen ^(Talk) 15:09, 7 April 2012 (UTC)

I changed some things and I hope it's fixed now? —CodeCat 17:10, 7 April 2012 (UTC)

Mea culpa. Mglovesfun (talk) 20:47, 7 April 2012 (UTC)

Looks good. Thanks. —Stephen ^(Talk) 21:48, 7 April 2012 (UTC)

Is there anyone here who knows how to fix the RSS feed? Its stopped working entirely. Here is the feed and here is the toolserver page. Conrad isn't responding by email. —Internoob 23:36, 7 April 2012 (UTC)

  is a character in Ogham that is used as a space, called OGHAM SPACE MARK in Unicode and assigned number 1680. I was going to make the entry for it, but then I noticed that links like this: ] aren't wikifying. Is this unsupported or is there something else going on? --Μετάknowledge^{discuss/deeds} 00:56, 9 April 2012 (UTC)

The word space, nonbreaking space, etc., in the Roman alphabet don’t wikify either: ], ]. —Stephen ^(Talk) 06:29, 9 April 2012 (UTC)

I don't think space marks really meet our guideline of including "all words in all languages" as space marks aren't words. —Angr 07:03, 9 April 2012 (UTC)

I think we include letters, punctuation, and symbols (if they are wikifiable). CFI does not mention letters, punctuation, or symbols, but I believe we have always included them. —Stephen ^(Talk) 07:39, 9 April 2012 (UTC)

It can be added to Appendix:Unsupported titles (note that that directory is in the Appendix: namespace, but the subpages are in the main namespace). - -sche (discuss) 07:56, 9 April 2012 (UTC)

If it is a space, why would Unicode call it a "mark", and why assign it a separate code point? I think it might be supposed to render as a line: see . Equinox ◑ 22:11, 9 April 2012 (UTC)

Ogham writing uses a single line to connect all letters together, onto which other marks are added to represent individual letters (similar to the top line in Devanagari). The Ogham 'space' is just the continuation of that line but without any added letter marks. So it is a mark in the sense that it's written, but a space in the sense that it separates words. —CodeCat 22:22, 9 April 2012 (UTC)

Yup. It is a space, having Unicode isSpaceChar and isWhitespace properties. Unicode says “An Ogham font typically displays all Ogham characters with a visible stemline, representing the edge of monumental Ogham inscriptions,” and regarding the space, “glyph is blank in ‘stemless’ style fonts.” —Michael Z. 2012-04-09 22:38 z

Ogham was sometimes written on paper too, and the stemline was written then as well. See File:Book of Ballymote 170r.jpg for example, which is a medieval description of Ogham in Irish. —CodeCat 22:43, 9 April 2012 (UTC)

 Done - see Unsupported titles/Ogham space. Would an admin please edit this page (or temporarily unprotect it for me; if so notify me on my talkpage) to add this to the {{also}} template? Thanks --Μετάknowledge^{discuss/deeds} 01:50, 11 April 2012 (UTC)

I've updated {{unsupported}} so that Appendix:Unsupported titles displays the space. I'll leave adding it to the hyphen's {{also}} to an admin who knows how to link to unsupported titles (because I presume linking to the space char won't work, but adding a link whose displayed text is the actual, long pagename is probably undesirable). - -sche (discuss) 02:35, 11 April 2012 (UTC)

Just add it to {{also}} the way it's done on this page. --Μετάknowledge^{discuss/deeds} 02:38, 11 April 2012 (UTC)

Look, at the very least you could add it in the ===See also=== section... --Μετάknowledge^{discuss/deeds} 00:19, 13 April 2012 (UTC)

I tried to add it like at ( yesterday, but that didn't work. I'll add it to the See also section as you suggest, until someone figures out how to add it to {{also}}/{{xsee}}. (Or... maybe I'll just fake {{also}}.) - -sche (discuss) 00:27, 13 April 2012 (UTC)

Any chance of regenerating this? May I suggest including all the entries that contain ====Translations==== but not {{trans-bottom}}. Mglovesfun (talk) 08:16, 10 April 2012 (UTC)

But perhaps excluding those that, while lacking {{trans-bottom}}, contain {{trans-see}}? - -sche (discuss) 08:23, 10 April 2012 (UTC)

Fair point. {{trans-mid}} isn't always used (but should be) and {{trans-top}} is sometimes not used, as {{checktrans-top}} is used in its place. Basically, I'm out of cleanup lists, so I have nothing to do at the moment but create words. Mglovesfun (talk) 21:51, 10 April 2012 (UTC)

In {{context}} and its many offspring, would anyone object to removing the opaque, inflexible tcat=XXX|regcat=XXX system and just using categories?

The way these are set up:

1. It is very difficult for an editor to learn how to categorize these templates.
2. It is difficult for me to relearn how to categorize them after being away for some months.
3. It is impossible to put them in multiple categories.
4. It is difficult to determine how it is that they end up in Category:Context labels, and how to remove them from there.

 —Michael Z. 2012-04-10 23:57 z

Needless to say, any such change should be made very cautiously. —Ruakh_TALK 18:27, 11 April 2012 (UTC)

Agreed, but I support the idea. - -sche (discuss) 18:37, 11 April 2012 (UTC)

Depending on how this is to be done, it may break {{context labelcat}} and the templates that depend on it. I therefore oppose unless the change to be made accounts for the labelcat template. However:

One way that wouldn't break the labelcat template — and anyway the most natural way to effect the suggestion on the table here — is to include, outside of the {{context}} template called by {{US}}, ] and similar lines to account for {{{script}}}, {{{script2}}}, {{{skey}}}, and {{{sort}}}. And likewise not ust for {{US}} but for every other context template currently existing or to be created in the future. Part of the beauty of {{context}} is that it does all this for you so that not only is it easy to use but it's easy to create new context templates. (I agree, though, with Michael above, that one bad thing about them isthat one cant put a context label in multiple such categories. Of course, that can still be done manually, but at the expense I note above.) I therefore oppose this suggestion if it's to implemented in the way I describe or similarly. Can someone think of a better way?​—msh210℠ (talk) 22:23, 18 April 2012 (UTC)

I am working on a template for the inflection of Portuguese nouns. Template:pt-infl-noun/doc has several examples of this template in use.

As this is my first template, the code is quite a mess. I’d like to get some feedback before using it in entries. Any complaints or suggestions on how to improve? Ungoliant MMDCCLXIV 16:43, 12 April 2012 (UTC)

I agree, the code looks quite convoluted for such a small table... I don't even know where to start! o.o —CodeCat 17:09, 12 April 2012 (UTC)

They are small but there are 28 possible table layouts. I did try to give the code some proper indentation and documentation. (note: the indentation was created with a tab length of 8 in mind). Ungoliant MMDCCLXIV 17:24, 12 April 2012 (UTC)

Maybe you could just use a few layouts, and just leave certain table cells blank if nothing can be added to them? —CodeCat 19:41, 12 April 2012 (UTC)

But many of those layouts involve alternative feminine and alternative plural forms. If a word has only one plural (as most do), the table shouldn’t have an empty column for alternative plural forms. Ungoliant MMDCCLXIV 20:10, 13 April 2012 (UTC)

I'm unsure about some conceptual details. For example:

• Are diminutives and augmentatives really "inflected forms"? For example, would you describe mesazinhas as "diminutive plural of mesa" (and not as "plural of mesazinha")? And — if a given noun had an unusually-constructed augmentative, would you call it "irregular"?
• Why do masculine nouns have a portion of the table labeled "masculine" (and likewise for feminine nouns)? Surely that's a property of the noun, not of the form?
• What's the difference between "(plural)" and "(plural) alternative"? How do you know which one is which?

—Ruakh_TALK 19:05, 13 April 2012 (UTC)

• Well they aren’t lemma. I’d describe it as “plural of mesazinha”, because there are other diminutive plurals of mesa. I’d call it irregular if paper dictionaries find it necessary to list them. Look at the table for faca in the documentation, it has 3 irregular augmentatives (the masculine ones), and a regular but non-standard one (facona).
• The problem is that augmentatives and diminutives, in some cases, have a different gender than the lemma. See the table for faca.
• Some words have more than one plural forms. I suppose the least common should be in plural (alternative), but this can be easily changed.

Ungoliant MMDCCLXIV 20:10, 13 April 2012 (UTC)

You could list both plural forms in a single cell, if necessary. —CodeCat 01:50, 15 April 2012 (UTC)

But how would one distinguish the augmentatives and diminutives of each form? Ungoliant MMDCCLXIV 14:56, 15 April 2012 (UTC)

What's the difference in these two revisions, and why does the newer revision show a bluelink (and link to a page that exists) while the older one shows a redlink (and links to a nonexistent page)? - -sche (discuss) 01:22, 15 April 2012 (UTC)

And are entries such as this (which contain exclamation points) Unsupported titles? Same problem here, so I'm guessing they are... - -sche (discuss) 01:23, 15 April 2012 (UTC)

It was changed from exclamation marks to alveolar click IPA symbols. Ungoliant MMDCCLXIV 01:30, 15 April 2012 (UTC)

Would it be useful for anyone if we had a list of functions for parsing the database dumps in multiple languages? Nadando (talk) 05:33, 15 April 2012 (UTC)

Mglovesfun (talk) 10:33, 15 April 2012 (UTC)

What are ifs (that is {{#if:{{{foo|}}}|...) expensive? What does expensive mean in this context? Are all ifs the same? Such as ifexist, iftrue and so on.

As an example {{cy-verb}} displays {{{2}}}- when no 2nd parameter is given. It would be possible to use an if to stop this happening, but I keep hearing about how 'expensive' ifs are. Mglovesfun (talk) 10:43, 15 April 2012 (UTC)

Basically means "it takes a relatively long time to run or process", so if it was used in a common template then it would slow things down or take too much of Wikimedia's computing resources. I don't know the specific deal with ifs here. Equinox ◑ 11:27, 15 April 2012 (UTC)

Firstly — #if: is not expensive. The only "expensive parser functions" are #ifexist:, PAGESINCATEGORY, and PAGESIZE. They're "expensive", in the sense that Equinox explains, because they require database lookups.

Secondly — how many times is {{cy-verb}} used on a page? Once? Twice? Maybe a handful of pages will somehow find reason to call it three or four times? Who cares if it uses an expensive parser function?

—Ruakh_TALK 13:14, 15 April 2012 (UTC)

To sum up, ifs should be used in headword line templates whenever they are genuinely useless, as headword line templates rarely appear more than once on the same page. Mglovesfun (talk) 09:51, 16 April 2012 (UTC)

Not exactly. To sum up: ifs should be used whenever they are genuinely useful (I assume you meant "useful" rather than "useless"?), because they're not expensive; and even moderately expensive functions should be used in headword-line templates whenever they're genuinely useful, since there are generally fairly few headword-line templates per page. —Ruakh_TALK 11:42, 16 April 2012 (UTC)

Yeah thinko. Mglovesfun (talk) 14:47, 16 April 2012 (UTC)

I would like to suggest a new format for Tea Room, Beer Parlour, Grease Pit (for example). Currently, all discussions are in the same huge page, whereas I suggest sub-pages (linked or included). Here some examples:

• Some micro-examples at User talk:MaEr#Sub-pages for high volume discussion pages
• Wiktionary:Votes (included sub-pages)
• fr:Wiktionnaire:Prise de décision (linked sub-pages)

Sure, one could use Liquid Threads but this doesn't seem to have many friends here.

The background of this suggestion can be found here: Wiktionary:Information desk#LiquidThreads and Wiktionary:Beer parlour#LT Straw Poll.

The most important advantages of sub-pages are in my opinion:

• Sub-pages can be watched individually, whereas individual sections of a huge page can't.
• Sub-pages can be moved around (when being archived or renamed) without breaking all links, whereas sections can't. Sections tend to be lost and forgotten even when they contain important discussions or decisions.

I need (at least) two things:

• A consensus about introducing this new format, at least for testing purposes. I suggest the Etymology Scriptorium because it has an odd and complicated format.
• Volunteers who write a mechanism that creates the sub-pages and links them into the parent page. This could be something like the New Entry Creator written by Yair rand (example).

The workflow could be:

1. The user opens the discussion page.
2. The user clicks a link at the top or on the bottom of the page.
3. The wizard (in computing sense) starts and prompts for title and content.
4. The user enters title and content, and clicks OK.
5. The wizard prepends the current date to the title, disarms all unsupported characters and creates a sub-page (using the title as page name).
6. The wizard links the newly created sub-page into the parent page.

What do you think about it? --MaEr (talk) 12:08, 15 April 2012 (UTC)

The main negative for me would be having to go and manually "watch" every newly created page, or else miss out on new stuff. Equinox ◑ 12:14, 15 April 2012 (UTC)

You really want to watch every discussion in a page like Tea Room, Grease Pit or Beer Parlour? Well, in this case you would have to put them manually on your watchlist. --MaEr (talk) 12:28, 15 April 2012 (UTC)

If the subpages were guaranteed to be linked from the parent page, it would probably be fine. Equinox ◑ 12:35, 15 April 2012 (UTC)

This is why I want some kind of script to do the sub-page creation. --MaEr (talk) 12:43, 15 April 2012 (UTC)

• Okay, so here's User:Yair rand/DiscussionSandbox.js, which creates title and content editing boxes, much like the "new section" edit screen, on the page. A preview button is available, and upon clicking save, the content is created on a separate subpage, and the main discussion page is modified to transclude the new page at the bottom of the page. User:Yair rand/DiscussionSandbox is the current testing area for this. There's probably still a bunch of bugs in the script, and I still need to add watch and edit buttons to the header template... --Yair rand (talk) 02:23, 18 April 2012 (UTC)

Thank you very much! I just added it to my User:MaEr/vector.js. I tried it and it looks good. After saving the sub-page I had to "purge" the page; simply refreshing the local cache did not help.

It looks fine and we should try it in WT:ES. --MaEr (talk) 17:18, 18 April 2012 (UTC)

I Support a month-long test in WT:ES, but I'm useless in terms of making it work. --Μετάknowledge^{discuss/deeds} 00:37, 18 April 2012 (UTC)

It is now enabled on WT:ES. --Yair rand (talk) 21:36, 17 May 2012 (UTC)

Hold on, hold on. I just noticed WT:ES uses, to a certain extent, labeled section transclusion. This could be applied to other pages, too! (RFD and RFV immediately come to my mind) It would have immense advantages: the old huge page would still be there, but the discussions would be neatly separated on the respective talk pages (which has a second advantage: the archiving process becomes entirely unnecessary). This is the way we should go. -- Liliana • 22:16, 17 May 2012 (UTC)

Hi! could any Bot create the Kurdish verb forms because I can't do it because there are lots of forms and I don't have time.ThanksGeorge Animal (talk) 13:12, 15 April 2012 (UTC)

There are bots that do this job, but general bot owners like to know the language they are working in, so they can manually spot any mistakes and correct them. Mglovesfun (talk) 23:28, 16 April 2012 (UTC)

I was talking with Haplology about organizing JA entries, when I discovered an apparent failure of WT's search feature.

Specifically, JA has numerous terms that are potentially both nouns and verbs, such as 勉強 (benkyō, “one's studies; to study”), with the verb senses appearing standalone in certain restricted contexts, and as + する ("to do") in running speech and other contexts. JA dictionaries across the boards list both noun and verb senses under the bare as the lemma.

After discussion, it seemed best to follow suit here on WT as well, and as a result, the issue arose of what to do with existing entries where the lemma is in the する format, such as 勉強する. Deleting these is one option. Experimenting, I found that searching for する does not list the page in the search results. The headword template format currently in use for verb senses of + する forms is just that -- + する. Thinking this might be screwing up the search function, I pasted in exactly that, and found still nothing -- not even in a full-text search.

Example:

• Entry 放出する deleted, with content moved to 放出.
• Searching for "放出する" finds nothing: http://en.wiktionary.orghttps://en.wiktionary.org/w/index.php?search=%E6%94%BE%E5%87%BA%E3%81%99%E3%82%8B&button=&title=Special%3ASearch
• Searching for "放出 + する" (the exact text of the headword line for the verb sense at 放出#Verb) also finds nothing: http://en.wiktionary.orghttps://en.wiktionary.org/w/index.php?title=Special%3ASearch&profile=default&search=%E6%94%BE%E5%87%BA+%2B+%E3%81%99%E3%82%8B&fulltext=Search

Is there some oddity of the search feature that I'm missing? I assumed that "full text search" meant "full text search", i.e. a search of all the text on the page, but it doesn't seem to be working that way.

Should we be turning する lemma entries into redirects instead of deleting them?

Any insight appreciated. -- Eiríkr Útlendi │ Tala við mig 17:01, 16 April 2012 (UTC)

Re: oddity of the search feature: The full-text search is based on the page's wikitext, with a little bit of parsing, but with no transclusion of templates; so, for example, a search for "simple past and past participle" will turn up Template:en-verb, and a few dozen entries that actually use the phrase "simple past and past participle" (most of which should be using {{past of}}, but I digress), but will not turn up all the entries that include {{en-verb}}.

Re: redirects: Quite possibly, but that goes beyond the scope of the Grease pit. :-)

—Ruakh_TALK 17:43, 16 April 2012 (UTC)

Sorry, I should have been clearer about redirects, actually I was seeking technical guidance for what would be the best way to make sure that someone looking for a する entry would find the proper entry. I thought the search feature would do the trick, but clearly it won't unless the headword template gets edited somehow. Do HTML comment strings get search hits? That might be one hackish way to tweak the template... -- Eiríkr Útlendi │ Tala við mig 18:28, 16 April 2012 (UTC)

I don't know about comments — I rather doubt it — but template arguments do show up, so one option is to add some parameter to {{ja-verb-suru}} for the noun plus suru. This parameter doesn't even have to do anything, though it would probably be best if the template confirms that the parameter has the value that it expects (and otherwise adds the entry to some sort of cleanup category). —Ruakh_TALK 19:21, 16 April 2012 (UTC)

The German Wiktionary handles misspellings by including them as parameters of a template, in the correctly-spelt entry, which (the entire template) displays nothing. Of course, I prefer Ruakh's suggestion of a do-nothing parameter in the existing template. - -sche (discuss) 19:49, 16 April 2012 (UTC)

@-sche -- Yah, that sounds grotty, beyond what I'm comfortable with. Functional, apparently, but hacky enough to worry me.  :-/

@ Ruakh -- A do-nothing param might be the best route, but before I do that, I'm trying to think of a way to get the search feature to work while also keeping the param format and requirements for {{ja-verb-suru}} as close as possible to that for {{ja-verb}}, {{ja-noun}}, and the other JA POS templates. When you say "the full-text search is based on the page's wikitext, with a little bit of parsing, but with no transclusion of templates", does that parsing include expanding things like {{PAGENAME}}? -- Eiríkr Útlendi │ Tala við mig 20:24, 16 April 2012 (UTC)

I really don't know every detail — I'm just going by the behavior that I've observed — but my overall impression is that the purpose of the parsing is just to strip things out that are considered "markup" rather than "text"; for example, a search for "ja-verb-suru" will not find entries that use {{ja-verb-suru}}, and a search for "td" will not find entries that use <td>. So I'm reasonably confident that {{PAGENAME}} is not expanded, not because of any specific thing I've seen, but just because that would be a fundamentally different sort of behavior from the things that I have seen. (Maybe I shouldn't even have used the word "parsing". It seems to be a very basic sort of stripping-out. Parameter-names, for example, are not removed, presumably because that would require enough intelligence to decipher when a template-call ends, so it just strips out {{...| and calls it "good enough".) —Ruakh_TALK 21:29, 16 April 2012 (UTC)

I'm trying a couple different approaches in my own user space to test some template ideas, and the results I'm getting are disheartening -- the WT search feature is really not very good.

Example:

• I added a deliberately odd string to my test page to make sure I can at least search for that. But searching for countermanding trousers for fez liberty gets nothing, even with all namespaces explicitly included in the search terms:

http://en.wiktionary.orghttps://en.wiktionary.org/w/index.php?title=Special%3ASearch&profile=advanced&search=countermanding+trousers+for+fez+liberty&fulltext=Search&ns0=1&ns1=1&ns2=1&ns3=1&ns4=1&ns5=1&ns6=1&ns7=1&ns8=1&ns9=1&ns10=1&ns11=1&ns12=1&ns13=1&ns14=1&ns15=1&ns90=1&ns91=1&ns92=1&ns93=1&ns100=1&ns101=1&ns102=1&ns103=1&ns104=1&ns105=1&ns106=1&ns107=1&ns108=1&ns109=1&ns110=1&ns111=1&ns114=1&ns115=1&ns116=1&ns117=1&redirs=1&profile=advanced

This string is not transcluded, but just hanging out in the page source as a straight string. The entire source of my test page User:Eirikr/Sandbox2:

{{User:Eirikr/Sandbox3|k|hira=てすと|rom=test}}

 countermanding trousers for fez liberty

If the search feature won't even catch a straight string like this, how can I expect it to work properly for term lookup? How am I to test templates and resulting page discoverability?

This certainly looks like a bug. Or does the search feature not work for subpages for some reason? If so, that also seems like a bug. Does the server take a long time to index things? That also seems like a bug. I added the above text late last night in this edit, and Google already has this indexed (and incidentally as the only occurrence of the string "countermanding trousers for fez liberty" anywhere online). -- Eiríkr Útlendi │ Tala við mig 18:14, 19 April 2012 (UTC)

Re: "Does the server take a long time to index things?": I believe some sort of scheduled job performs incremental updates on the Lucene search indices. I don't know how often it runs, but I wouldn't be surprised if it's only once a day, or even less than that. —Ruakh_TALK 18:33, 19 April 2012 (UTC)

Hmm, very good to know, if somewhat disappointing. I'll just have to wait a while then and take my time testing. Thanks, Ruakh. -- Eiríkr Útlendi │ Tala við mig 20:01, 19 April 2012 (UTC)

For what it's worth in calculating how long the search takes to be updated, I created stave-rhyme at 08:56, 19 April 2012, and as of this writing the search still hasn't found it. - -sche (discuss) 20:36, 19 April 2012 (UTC)

And for what it's worth, stave-rhyme still hasn't been picked up. - -sche (discuss) 02:08, 20 April 2012 (UTC)

Both of the above now show up in searches. —Ruakh_TALK 19:01, 20 April 2012 (UTC)

Yes, I just saw that a few minutes ago. Thank you, Ruakh. -- Eiríkr Útlendi │ Tala við mig 22:03, 20 April 2012 (UTC)

Since there seems to be some movement in the direction of modifying {{context}}, I think it might be a good idea to really rewrite a large chunk of it. The overall design is obsolete, in a few respects:

• Back when it was created, {{ #if: condition | a {{b}} c | d {{e}} f }} always transcluded both {{b}} and {{e}}; the function didn't even check whether condition was non-blank until after it had already evaluated a {{b}} c and d {{e}} f. (This is how templates work: they always evaluate all parameters, whether or not all parameters are "used". Parser-functions used to do the same thing.) So the only way to approximate "conditional execution" (like an if in an actual programming language) was to have the parser-function itself generate a template name: something like {{ {{ #if: condition | helper-template-to-call-if-true | helper-template-to-call-if-false }} | parameters-to-pass-to-whichever-helper-template-gets-called }}. This was a serious constraint on the design of {{context}}, and resulted in a great deal of complexity that simply isn't needed anymore.
• A template cannot call itself — not directly, and not by calling another template that calls it. For example, if the template foo is defined as ! {{bar}} ! and the template bar is defined as $ {{foo}} $, then a page that contains {{foo}} will display as “! $ Template loop detected: Template:foo $ !”. This has always been the case, but there used to be a workaround for finite-depth recursion: if {{redirect-to-foo}} was a redirect to {{foo}}, then {{redirect-to-foo}} and {{foo}} were counted separately, so {{foo}} could call {{redirect-to-foo}}. Due to the previous bullet-point, it was very tricky to make this work, but it could be done; and {{context}} depended on it, by using a family of redirects named {{context 1}} and {{context 2}} and so on (together with a parameter named sub= that determined which redirect was called, and use of {{#expr:...}} to increment the suffix). However, this workaround was silently wiped away in a MediaWiki software upgrade, and in haste to get {{context}} working again, Conrad.Irwin (talk • contribs) replaced all of these redirects with verbatim copies of {{context}}. Even to begin with, these copies were imperfect (since they retained all the complex logic that had only been needed to support the redirect-workaround), but the situation has grown worse over time, since these copies have not been consistently kept up-to-date with changes to {{context}} itself. It's terrible. (Of course, we could fix that last part right now by re-synching all the copies to match {{context}}, but the problem would just come back. People simply cannot stop themselves from editing templates that they don't understand, and no one understands {{context}}.)

Any thoughts, anyone?

—Ruakh_TALK
17:32, 16 April 2012 (UTC)

How about making a list (on one page) of all of these sub-templates and their basic form, so that the call-relationships can be disentangled? Equinox ◑ 17:40, 16 April 2012 (UTC)

Sorry, I don't understand your suggestion. :-/   By "sub-templates", do you mean {{context 1}} and so on? There are just nine of them, 1 through 9, all listed at Special:PrefixIndex/Template:context, and the call-relationships are actually fairly straightforward: {{context}} calls {{context 1}}, which calls {{context 2}}, and so on. (Well, it can be a bit trickier — {{context 1}} calling e.g. {{rare}} calling {{context 2}} and so on — but that's the idea.) That's the thing: the call-relationships are simple now, but the templates still have all the old super-complex code from when they were all redirects to a single {{context}} that needed to manage everything using #expr:. —Ruakh_TALK 18:08, 16 April 2012 (UTC)

Hmm, from what you say, the four #expr: statements now in the template are completely unnecessary? I'll have a look at the code later (copied to a text editor; I'm leaving the template alone :D) and see what I can tease out meaning-wise. -- Eiríkr Útlendi │ Tala við mig 18:36, 16 April 2012 (UTC)

Re: first sentence: I believe so, yes. Basically, {{context 1}} (for example) is always supposed to be called as {{context 1|sub=1}}, so, now that it's its own template instead of a redirect to {{context}}, it could just use {{context 2}} instead of {{context |sub=}}. I can't make an absolute guarantee that this stuff is always used right; and the existence of the related template {{context labelcat}} complicates matters slightly (though clearly it can't be depending on these #expr:-s); but it should at least be possible to modify these templates to confirm that they're used right (e.g. by adding {{#ifeq:{{{sub|}}}|1||{{blank-template-1}}}} to {{context 1}}, waiting a while, and seeing what pages show up in Special:WhatLinksHere/Template:blank-template-1) before making any changes that rely on that. —Ruakh_TALK 18:57, 16 April 2012 (UTC)

I think it may be better to rewrite a large part of it from scratch. But to do that, there would need to be a proper description of what the template is actually supposed to do. —CodeCat 18:46, 16 April 2012 (UTC)

Yay! Requirement specifications!

(Not being ironic: this is a good idea.) -- Eiríkr Útlendi │ Tala við mig 18:51, 16 April 2012 (UTC)

(I'm sure we all know what {{context}} is supposed to do, but here's my attempt at formally writing it down.) It should display all parameter-values in italics between parentheses, each one separated from the next by a comma where the | is in the template, except that |_| should result in a space, rather than in , _,. (It seems to also at present know not to include a comma after especially| and similar words...?) Also, if one of the values is the name of a template or a redirect to a template, it should use that template's contents, but without any extra parentheses (or extra italics that would cancel out the existing italics). So, {{context|medical|not used anymore|_|except in|_|dialects}} should display the equivalent of (medicine, not used anymore except in dialects) (not, say, (medical, not used anymore, _, except in, _, (dialects))) and should put the entry into the categories Category:en:Medicine and Category:en:Dialectal (because that's what {{medicine}} and {{dialects}} do). Also, apparently, the template should handle sort= and/or skey=... though I've never encountered them in it before. Does it need to do anything else complex? Is it supposed to be tagged with a lang=? - -sche (discuss) 19:09, 16 April 2012 (UTC)

I think the real difficulty is that it's supposed to transclude templates that are themselves supposed to work like {{context}} does, which implies some kind of recursion no matter what. If we could forego that behaviour, (require {{context|medicine}} instead of {{medicine}}) the template could be considerably simplified. —CodeCat 19:14, 16 April 2012 (UTC)

(this is probably you're suggesting, but I'm not sure) We could forbid the use of {{medicine}} outside of {{context}}, and then strip the bits from {{medicine}} that add parentheses and that allow {{medicine}} to handle {{medicine|obsolete}}, and require that labels always be inside {{context}} (or, as we may rename it soon, {{label}}). - -sche (discuss) 19:20, 16 April 2012 (UTC)

I don't think there's any technical reason that {{context|medicine}} has to call {{medicine}}. If we have {{context|medicine}} call {{medicine/guts}} instead, then {{medicine}} can be a simple wrapper around {{context|medicine}}. —Ruakh_TALK 19:33, 16 April 2012 (UTC)

And you want to do this for every subtemplate of {{context}}? It seems rather convoluted to me... —CodeCat 19:36, 16 April 2012 (UTC)

Eh? You commented that recursion was necessary as long as we want {{medicine}} to be syntactic sugar for {{context|medicine}}; I was merely pointing out that that's not true, since the syntactic sugar can be separated from the implementation of the functionality. I didn't say that I "want" to do it; but it's an idea that I think is worth examining. (BTW, I think that two straightforward templates, each with a single clear purpose, is less convoluted than a single convoluted template that serves two disparate purposes. How "straightforward" the two templates end up, of course, and how "convoluted" the one, remains to be seen. Hence my suggesting it only as a possibility, not as a desideratum.) —Ruakh_TALK 19:58, 16 April 2012 (UTC)

Ok, I have to admit that I really don't understand {{context}}. I could be wrong, but I suspect I'm not the only one. Everyone basically understands how to use it and what it produces, but everything in the middle's a wash. Additionally, I can't come to learn it at the moment, because it's in flux. So.....I suspect that everyone would be cool with you, Codecat, and whoever else monkeying with it to make it simpler, more efficient, and whatever else, as long as it works properly in the end. I could be overly cynical here, but I kind of feel like your explanation of recursion and parameter parsing is a waste. Almost no one has the technical expertise requisite to assessing the merits of your plans. -Atelaes λάλει ἐμοί 22:45, 16 April 2012 (UTC)

With Ruakh's help I've added line breaks and made the code tidier without changing what it does. I hope that those changes will make it a bit easier to understand it, for you too Atelaes. I'm starting to understand the picture a bit better now as well, and it's not very pretty. Rewriting everything will break too many things because it's incredibly intricate. So it may help to identify 'loose ends'... pieces of the code that don't depend to a significant degree on other things. So far, I think the best candidate is to remove the automatic categorisation of label templates that is done at the bottom, since that only affects label templates themselves, not the entries they are placed in. Michael Zajac already commented on that above. This is not too difficult... first, <noinclude>]</noinclude> needs to be added to every template in Category:Context labels and its subcategories. I've already done the first three subcategories, but the latter three have so many templates that a bot might be better suited to it. Once the categories have been added manually, the code in {{context}} that adds them to those categories can be removed without losing them. —CodeCat 22:52, 16 April 2012 (UTC)

• I've added to {{context}}'s documentation a bunch of examples of various cases that it supports. Due to the nature of documentation-pages, it doesn't exemplify the categorization stuff (which, admittedly, is fairly complex), but it demonstrates most of the other functionality. —Ruakh_TALK 23:57, 16 April 2012 (UTC)

Why does context call copies of itself ({{context 1}} etc), anyway? Is it so it can handle the fact that {{medicine}} currently displays (medicine) rather than medicine, but {{context|medicine|foo}} needs to display (medicine, foo) rather than ((medicine), foo)? - -sche (discuss) 20:54, 17 April 2012 (UTC)

It calls copies of itself because originally it called itself, and copying it was the fastest/easiest way to get it working again after a MediaWiki upgrade broke the behavior that allowed it to call itself. (This is my second bullet-point above.) As for why it originally called itself — I suppose there were a few reasons. One is that MediaWiki's wiki syntax doesn't support loops, so the only ways to do the same thing over and over on different inputs used to be (1) what might be called total, manual loop unrolling (that is: copy and paste the same thing over and over, so the template's wikitext consists of the same wikitext repeated many times) and (2) this sort of recursion. (Now that the recursion is broken, #1 is the only option.) Another reason is that manual loop unrolling, using {{#if:-s to control the number of iterations, was even less appealing back when {{context}} was created, since back then all branches were always evaluated even if unused. (This is my first bullet-point above.) The third reason is that if it's already recursive, then yeah, like you say, that recursion can also be exploited (and doubled-down on) to have {{medicine}} serve both as a template that can be called directly from entries and as a template that can be called indirectly via {{context}} (and other context-templates). —Ruakh_TALK 22:27, 17 April 2012 (UTC)

Yes, I should have been more specific; I saw your explanation that {{context}} called {{context 1}} as a workaround to calling itself, I just wondered why it (how can I put this) needed to be recursive at all.

1. Does its recursion have anything to do with recognising |_| as a space rather than as , _,? How simple or complex is that recognition?
2. What part of interpreting, say, {{context|medicine|obsolete|foo-which-is-not-a-template}} requires recursion as opposed to straightforward, ah, incorporation of the text and category of {{medicine}}, the text and category of {{obsolete}}, and the provided text 'foo-which-is-not-a-template'? Is recursion required / only present because {{medicine}} calls {{context}}? If {{medicine}} simply contained the text 'medicine', and some code to put entries into the appropriate language's medical categories, (presumably using manual categorisation, rather than topcat= etc?), would {{context}} still need to be recursive? If so, why?

- -sche (discuss) 02:50, 18 April 2012 (UTC)

If I understand it correctly (and I think I do), we could have {{context}} do as you suggest: display its parameters and correspondingly categorize. The parameters (their names, aliases (current redirects), display forms, and categories) would need to be listed in the {{context}} itself (well, a helper template, actually, so it can be called nine times) rather than be their own templates. We'd thus get rid of {{medicine}} et al. in favor of a huge {{context}} (with a huge #switch). Can anyone address performance under that method versus under our current method?​—msh210℠ (talk) 15:38, 19 April 2012 (UTC)

I've noticed that in most cases when a large switch appears, an alternative and faster solution is to use subtemplates. This is how we updated {{catboiler}} long ago, and more recently {{langfamily}}, and especially in the first case the performance gain was quite large. So, it would be a separate template {{context/medicine}}. Of course, there is no reason why it could not be called {{medicine}} like the current template, but since we're not intending to ever call that template itself, there is no need for a simpler name. —CodeCat 17:10, 19 April 2012 (UTC)

Yikes. I hadn't realized just how tangled a web I was proposing pulling a few strands out of.

I'd have no problem with always entering {{context|medicine|transitive}}, or {{label|medicine|transitive}}, instead of {{medicine|transitive}}. This might make the wikitext clearer for new editors. And it would be great to have a template simple enough not to require a research project before updating it.  —Michael Z. 2012-04-18 21:06 z

A resounding amen to Michael's comment here. I see little compelling utility in having dozens upon dozens of specialist context label templates compared to just having {{context}} handle each label itself, and the current structure entails the negatives of being unintuitive and, as amply described above, a code maintenance nightmare. -- Eiríkr Útlendi │ Tala við mig 20:15, 18 April 2012 (UTC)

As a starting-point, I've put together {{User:Ruakh/label}}. This:

{{User:Ruakh/label|biology|medicine|;|now|rare|or|dialectal}}

will generate this:

• (biology, medicine; now rare or dialectal)

and add an entry to Category:en:Medicine and Category:English terms with rare senses.

The above uses all the templates currently listed at Special:PrefixIndex/User:Ruakh/label, namely:

• {{User:Ruakh/label}} ({{label}}) — the outermost wrapper; provides the parentheses and whatnot; expected to be called directly, though e.g. {{medicine}} could if desired be defined as a wrapper for {{User:Ruakh/label|medicine}}.
• {{User:Ruakh/label/label}} ({{label/label}} — this probably isn't the best name — called once for each parameter, such as "rare" or "or", and handles that parameter plus any following comma and/or space. Has special handling for _, ,, ;, and, or, and blank parameters; anything else gets delegated to another template.
• {{User:Ruakh/label/~medicine}}, {{User:Ruakh/label/~now}}, and {{User:Ruakh/label/~rare}} ({{label/~medicine}} etc.) — handle the "medicine", "now", and "rare" labels. (N.B.: we would need hundreds of these, though a lot of them could potentially be redirects to exemplars. For example, the "now" template just generates the string now, which is equivalent to {{{1}}}, so could be a redirect to a generic {{User:Ruakh/label/qualifier}} or something.)
• {{User:Ruakh/label/default}} ({{label/default}} — handles the "biology" and "dialectal" labels, since they don't have their own templates yet (and aren't magical like ; and or).
• {{User:Ruakh/label/cat-langcode}} ({{label/cat-langcode}} — a helper template, called by {{User:Ruakh/label/~medicine}} for help in categorizing entries in e.g. Category:en:Medicine with appropriate sorting.
• {{User:Ruakh/label/cat-langname}} ({{label/cat-langname}} — a helper template, called by {{User:Ruakh/label/~rare}} for help in categorizing entries in e.g. Category:English terms with rare senses with appropriate sorting.

Some advantages of this over {{context}}:

• It eliminates the pseudo-recursion business, and I think it's more flexible and maintainable, but of course I would think that, having just written it. I'd welcome the opinions of editors with less personal interest. :-)
• It eliminates the risk of a label conflicting with an existing unrelated template, such as a language code (and it eliminates the ugly check that tries to detect such conflicts).
• It supports ;, because hey, why not?
• It's smarter in some edge cases. Actually this isn't much of an advantage, because those edge cases shouldn't really be used, but they're an indication of how much easier this template is to work with than {{context}}.
• It hopefully concentrates the complexity in a very small number of templates, while allowing the large numbers of templates that ordinary users might want to create ({{label/~rare}} and so on) to be somewhat simpler. At the very least — creating {{label/~foobar}} containing just foobar won't break anything, even if it also doesn't accomplish anything. (By contrast, even just missing a } in {{foobar}} would break not only the foobar part of {{context|foobar|baz}}, but also the baz part.)
• It makes it conceivable that we could support more than nine parameters if needed. Currently, supporting (say) fifteen parameters would require changing not only {{context}}, but also every context template. Even if we don't mind if {{medicine|1|2|3|4|5|6|7|8|9|10|11|12|13|14}} doesn't work, the current approach means that even {{context|medicine|1|2|3|4|5|6|7|8|9|10|11|12|13|14}} couldn't work without modifying {{medicine}}.

Open issues include, but are not limited to:

• Do we like this approach at all?
• How do we want these to be categorized? For example, should {{User:Ruakh/label/~medicine}} ({{label/~medicine}}) belong to a category? Or should there be a project page to list them? or something else?
• Do we want to keep {{medicine}} and so on as wrappers? If so, do we still want e.g. {{medicine|US}} to work, or would we just want them to be syntactic sugar for the case of a single label?
• What's with {{context}}'s current script=, script2= and skey2=? Does the new template need to support them?
• What's the migration path?

—Ruakh_TALK 20:38, 19 April 2012 (UTC)

re script= : maybe for something like ? I can't tell if it does anything in that entry. - -sche (discuss) 20:54, 19 April 2012 (UTC)

script is supposed, if I'm reading {{context}} right, to categorize {{anthropology|lang=lad|script=Latin}} in Category:lad:Anthropology in Latin script (do we have such categories for any language? We shouldn't IMO) — but it does not. So presumably I'm reading {{context}} wrong.​—msh210℠ (talk) 23:02, 19 April 2012 (UTC)

No, you're reading it right; it's just that {{anthropology}} doesn't relay the script= parameter, so it doesn't work for that template. One template that does relay it is {{literary}}, and therefore, for example, the {{literary|lang=cmn|script=traditional|script2=simplified|skey=一00|skey2=yi1ri4}} at ] categorizes that page in Category:Mandarin literary terms, Category:Mandarin literary terms in traditional script, and Category:Mandarin literary terms in simplified script with various sort-keys. By "what's with it?" I don't really mean "what does it do?" but rather something more like "is this really how we want this to be?" Because it seems like a hackish and ugly system to me — adding opaque parameters to our entire sense-label system to support oddities in our handling of one language — but maybe this is the best way, or the least-bad way? I don't know what the alternatives are. I assume it was discussed, but I don't remember the discussion, and I don't know how much of it would still apply to {{label}}. —Ruakh_TALK 23:22, 19 April 2012 (UTC)

I feel like any code change which doesn't change the input or output will likely be fairly uncontroversial, and a consensus here is sufficient to implement. Any change which alters the functionality probably requires a larger consensus at the BP. That being said, I agree with you that using script in this way is a terrible idea, and would support changing it. It would probably be pretty easy to change the parameter to something like zh-script, leaving script to do what most people expect it would do, though I don't know if we have any need for context/label to do that. The actual implementation would probably require an analysis of how every entry on Wiktionary is using script within {{context}}, and, if it's only used like your example, we could add zh-script, with identical functionality to script, bot change the entries, and then change the behaviour of script. As to actually changing {{context}} itself, as a whole....that's messy. I'm not really sure, but I suspect it would have to be a multi-stage operation to minimize the impact on the site. Perhaps we could have the change to the new code, as well as the change to the name {{label}} coincide? That might ease things a bit, allowing us to change things from {{context}} (with old code) to {{label}} (with new code) as support is added. -Atelaes λάλει ἐμοί 00:57, 20 April 2012 (UTC)

Re: your last two sentences: Yes, absolutely. I think the migration could be done without a rename, but the rename will probably make the migration much more convenient. —Ruakh_TALK 02:10, 20 April 2012 (UTC)

It does look like a good start but I would like to recommend adding comments at the end of lines and the beginning of the next one. Line endings can sometimes make templates behave differently in very subtle ways, and it's better to just prevent it. Secondly, the 'information' templates in {{catboiler}}, instead of including lots of code directly, just transclude a helper template, {{catboiler helper}}, which simplifies the ordering of all the information in a more neat way that makes it easier to change the formatting later on. It may be useful to do it with this template as well. I'm also wondering why the templates begin with ~. Is there a technical reason for that? —CodeCat 00:28, 20 April 2012 (UTC)

Re: HTML comments <!-- --> around newlines: I've used them when necessary, but eschewed them in contexts where the software swallows newlines anyway (and done my best to create those contexts where possible). I don't object to them when they're necessary — actually, I think I may have introduced the practice here of using commented-out newlines in template wikitext to space things out for readability — but when they don't do anything at all, I think they're clutter, and they tend to distract from the code that actually does things. Do you disagree? Also, comments I've received from less tech-savvy editors have suggested that they might be a barrier to understanding, though that may be a minor point, since the templates here that contain newlines for readability are probably not templates that non-tech-savvy editors will understand the guts of. :-/

Re: {{catboiler helper}}: I'm not sure I understand. I'm actually not even sure which template(s) you're suggesting to change. Can you make that a bit less abstract? Maybe even create your own {{User:CodeCat/label}} to demonstrate? (In general terms, I'll say that I'm not a fan of template "frameworks" like {{catboiler helper}} — they're generally very flexible along the specific dimension that their creator planned for, but very inflexible along any other dimension, and they generally make it hard to find the template that's actually doing something — but this may indeed be a case where their advantages are greater, and disadvantages lesser, than usual.)

Re: ~: Not exactly a technical reason, but this clearly distinguishes the "open class" of individual sense-label templates from the "closed class" of architectural/infrastructural subtemplates like {{label/label}} and (deprecated template usage) label/default, thereby preventing any risk of name conflicts if someone types something like {{label|of a|fashion|_|label}}. The reason I chose ~ as the prefix is that it's the last seven-bit ASCII non-control character, so this ensures that the architectural/infrastructural subtemplates are listed first, all in a group, at Special:PrefixIndex/Template:label, and are therefore easily findable (see Special:PrefixIndex/User:Ruakh/label, and imagine that there were hundreds of individual sense-label templates, to see what I mean).

—Ruakh_TALK 02:10, 20 April 2012 (UTC)

I don't think there would be a need to keep the original templates really. Migrating could be fairly painless if we do it like this:

1. Bot-replace all instances of directly-called context templates with calls to {{context}}. So, a bot would replace {{medicine}} with {{context|medicine}}. This change is guaranteed to break nothing (as far as we know) because of how context is supposed to work.
2. Replace {{context}} with a redirect to {{label}}. At this point all the old context templates should become orphaned, as {{context}} no longer transcludes them and neither does the new template.
3. Bot-replace all the occurrences of {{context}} with {{label}}.

—CodeCat 01:18, 20 April 2012 (UTC)

Re "a bot would replace {{medicine}} with {{context|medicine}}. This change is guaranteed to break nothing (as far as we know)": would it cause "Limit of template reached" one step sooner? (I don't know.)​—msh210℠ (talk) 02:50, 20 April 2012 (UTC)

It would, but that situation is exceedingly rare (if it happens at all) so it's not really a big problem, especially because the situation is only temporary. —CodeCat 12:32, 20 April 2012 (UTC)

so, are we going to implement this? If only as a test to see how well it works, and what still needs to be done. -- Liliana • 04:32, 14 May 2012 (UTC)

I thought I'd commented here, but I guess not. My comment: Brilliant. It looks very good, except that it does not take {{context labelcat}} into account. Any idea on what to do for that? (Note that it's used by other templates and alone, in both cases as {{foo|sub=labelcat}} for foo a context template. (It may have other uses, too, I'm unaware of.))​—msh210℠ (talk) 20:43, 18 May 2012 (UTC)

I just came across a situation that may be a bit confusing. Some context label templates assume that the language is not English. But what happens if you combine them? Here are some results, using {{rare}} (no default, but generally English), {{Cajun}} (French by default) and {{Flemish}} (Dutch by default) and showing the categories they add an article to:

• {{rare|Cajun|Flemish}}: English terms with rare senses, Cajun French, Flemish French
• {{Cajun|rare|Flemish}}: Cajun French, French terms with rare senses, Flemish French
• {{Cajun|Flemish|rare}}: Cajun French, Flemish French, French terms with rare senses
• {{rare|Flemish|Cajun}}: English terms with rare senses, Flemish Dutch, Cajun Dutch
• {{Flemish|rare|Cajun}}: Flemish Dutch, Dutch terms with rare senses, Cajun Dutch
• {{Flemish|Cajun|rare}}: Flemish Dutch, Cajun Dutch, Dutch terms with rare senses

As you can see, a label that overrides the default language 'poisons' all labels that follow it; all templates after it take on its language while those before it do not. —CodeCat 02:20, 30 April 2012 (UTC)

I've modified {{Louisiana French}} (formerly {{Cajun}}), such that it can only be French, but that doesn't change the problem you describe — even when lang=en is set following e.g. {{rare}}. - -sche (discuss) 02:50, 30 April 2012 (UTC)

Well since we're rewriting all of these templates anyway, it may be a good time to think about what actually should happen in these cases. What would be the desirable and most logical behaviour? —CodeCat 02:55, 30 April 2012 (UTC)

Hm, {{context|obsolete|Quebec|rare|lang=de}} appears to correctly categorise into German categories, despite {{Quebec}}'s default being French (and its alt being English)... perhaps it's a model for how to code templates that don't poison other templates? but is there a way to suppress Category:Quebec German? - -sche (discuss) 02:58, 30 April 2012 (UTC)

To your knowledge, at Template_talk:Han_char#Expansions some suggestions are posted for discussion. -- sarang♥사랑 14:11, 17 April 2012 (UTC)

en.WT's MobileFrontend main page currently displays {{WOTD}} and that's pretty much it. There are some tricks to use to get the main page to display well. The community may want to work on how they wish to display for mobile users, such as the Wiktionary Mobile android app (latest build link) - Amgine/ ^t·e 00:57, 18 April 2012 (UTC)

Hm, maybe we should include the list of indexes on the mobile main page? And/or the introductory text, perhaps? The current styling problems are a bit unfortunate, but I don't think we can fix that so long as we don't have access to the CSS file... --Yair rand (talk) 01:05, 18 April 2012 (UTC)

According to WT:About Kurdish the two major variants: Kurmanji (iso-code: kmr, written in Latin script) and Sorani (iso-code: ckb, written in Arabic script) should be nested under Kurdish. The current behavior of Assisted translation adding is that (without the explicit nesting option, which seems to be to complicated for many occasional contributors), that kmr and ckb will generate a non-nested Northern Kurdish and Central Kurdish entries resp., while the meta-language iso-code ku will generate entries under Kurdish. As a consequence the current situation is that many Kurdish translations have Kurmanji and Sorani mixed and without nesting. Would it make sense to switch on automatic nesting based on kmr and ckb iso-codes (similar as current behavior of Norwegian nn and nb resp.) and map the kmr and ckb wikilinks to kuwiktionary (as currently done for e.g. cmn)?Matthias Buchmeier (talk) 12:00, 18 April 2012 (UTC)

Given how w:ckb: is separate from w:ku:, I think Sorani translations should not interlink to Kurdish Wiktionary. -- Liliana • 16:59, 18 April 2012 (UTC)

Your right, there also doesn't seem to be many Sorani enries in kuwiktionary. Matthias Buchmeier (talk) 17:18, 18 April 2012 (UTC)

Hey all, I've recently expanded {{grc-cite}} so that it has the capacity to do some automated work with the information given it. For example, if you look at the first quote on ἔλαιον (élaion) you'll see what it can do. For starters, this keeps our grc quotes in a consistent format. Additionally, by accessing a few subtemplates ({{grc-cite-Homer}}, {{grc-cite-Homer-Iliad}}, {{grc-cite-numtouppGrek}}, and {{grc-cite-blank}}), it takes the raw information and converts it into a number of useful links, such as links to the 'pedia on Homer and the Iliad. Additionally, it adds the year (well, centuries, actually) based on the author. However, the real power, in my opinion, is the reference link (10:577), where it links to the wikisource page of the actual work itself, in Ancient Greek. Also, it adds some convergent magic, such that the following different code inputs produce the same results:

• {{grc-cite|Il.|10|577}} -->
  800 BCE – 600 BCE, Homer, Iliad 10.577
• {{grc-cite|Hom.|Iliad|10|577}} -->
  800 BCE – 600 BCE, Homer, Iliad 10.577
• {{grc-cite|Homerus|Iliad|10|577}} -->
  Homerus, Iliad 10.577
• {{grc-cite|Ὅμηρος|Iliad|10|577}} -->
  Ὅμηρος, Iliad 10.577

As you can all probably imagine, the power of this template lies in the creation of quite the host of subtemplates. I absolutely think such a project is worth the effort, but I'd really like to avoid finding a mistake in the code 500 templates in. If anyone has the time to troll through some of the code and let me know if they find any mistakes, omissions, or things that aren't quite either but give a vague feeling of disquiet, I would most sincerely appreciate it. -Atelaes λάλει ἐμοί 01:25, 19 April 2012 (UTC)

Most of the other citation templates have transliteration parameters- was that a deliberate omission? Nadando (talk) 01:29, 19 April 2012 (UTC)

It was not. I'll add that. Thanks! -Atelaes λάλει ἐμοί 01:36, 19 April 2012 (UTC)

I have replaced the contents of Wiktionary:Languages with the contents of User:-sche/langcodes. I think and hope it now more carefully explains why/how we choose the language codes we do, where we put them and where we store the family and script information (which was opaque to Metaknowledge WT:ID). My updates to WT:Families also attempt to better explain why/how we choose the family codes we do — something which was long opaque to me. One thing is still missing, though: I haven't figured out our system for naming reconstructed languages. Do we use ISO codes; does the ISO have codes? Do we invent codes of our own? - -sche (discuss) 02:05, 19 April 2012 (UTC)

Discussion moved from Wiktionary:Information_desk#Wiktionary:Etymology.2Flanguage_templates.

Wiktionary:Etymology/language templates is updated by bot, but it still lists Template:etyl:awd-mai, although that template was deleted in 2011. Any idea why? - -sche (discuss) 05:45, 18 April 2012 (UTC)

Template:yue-toi was also deleted in 2011, but is still picked up by the bot and listed here. - -sche (discuss) 01:41, 20 April 2012 (UTC)

I made a template recently (editing view here) which makes a basic entry in Zarma. I wanted the user to be able to only type in the part of speech once (for {{head}} ), and then without needing a bot to cleanup after them, the capitalized form would appear for the section title (like ===Noun===). I used a bunch of #ifeq parser-functions designed to cover every possible POS in Zarma. Is there a neater/better way to do this? --Μετάknowledge^{discuss/deeds} 23:37, 19 April 2012 (UTC)

For most cases like this you would use the #switch function to do something like this: {{subst:#switch:{{{1}}}|noun=Noun|verb=Verb|adjective=Adjective}}, but in this case all the thing seems to be doing is changing the first letter to uppercase, so you'd be best off just using ucfirst: {{subst:ucfirst:{{{1}}}}}. --Yair rand (talk) 00:15, 20 April 2012 (UTC)

Thank you!--Μετάknowledge^{discuss/deeds} 00:34, 20 April 2012 (UTC)

Responses to this query would also be greatly appreciated from those who are technically minded: Wiktionary:ID#Bot_creation_for_dummies. Again, thanks! --Μετάknowledge^{discuss/deeds} 03:24, 20 April 2012 (UTC)

page think
format think: 'sorted/rebalanced translations'
Updating page think via API
Received a bad login token error from the server.  Attempting to refresh.

This doesn't look too good. Looks like something broke with 1.20 which causes problems saving pages with the bot. -- Liliana • 05:06, 20 April 2012 (UTC)

Where exactly are the flags associated with L2 language headers encoded, and how does one go about adding one for a language which doesn't have one yet? Ƿidsiþ 10:02, 20 April 2012 (UTC)

See MediaWiki:Gadget-WiktCountryFlags.css -- Liliana • 10:05, 20 April 2012 (UTC)

Thanks. How do I treat diacritical marks in language names? It doesn't seem to like ‘Guernésiais’ or ‘Guernésiais’. Ƿidsiþ 11:04, 20 April 2012 (UTC)

You "anchor-encode" them — {{anchorencode:Guernésiais}} = Guern.C3.A9siais (which is like URL-encoding, except it uses . instead of % and _ instead of +; it's a MediaWiki-specific thing, that it does to id="...") — and then you escape each . by preceding it with \. So, Guern\.C3\.A9siais. I've fixed it now. —Ruakh_TALK 12:09, 20 April 2012 (UTC)

Thank you. I have literally no idea what I'm doing with this stuff. Ƿidsiþ 14:12, 20 April 2012 (UTC)

Trying to mark an edit on RC as patrolled, I get a dialog box "badtoken: Invalid token". Presumably this is a result of the MW upgrade. Any thoughts? Is it just me, or does it seem like this update broke more stuff than previous ones have? -Atelaes λάλει ἐμοί 06:10, 21 April 2012 (UTC)

I'm not getting that dialogue (yet?); I just patrolled diff, and AFAICT it worked. Hmm... - -sche (discuss) 06:27, 21 April 2012 (UTC)

This may or may not be relevant, but I had no such difficulties on my Windows machine. This problem only showed up when I tried doing stuff on my Chrome OS machine. -Atelaes λάλει ἐμοί 06:51, 21 April 2012 (UTC)

API tokens are tied to your log-in session. Is it possible that you had the page open while you logged out and then back in, such that the patrol token that you got when you loaded the page is not the patrol token that you needed by the time you clicked the button? (More generally — is it possible that you had the page open for a long time before you clicked the button and got this message?) Also, have you tried the usual "new JavaScript" stuff (refreshing the page, clearing the cache, etc.)? If that stuff doesn't help, then I guess we'll have to try to debug in earnest. :-/   —Ruakh_TALK 14:49, 21 April 2012 (UTC)

By the way, I've edited the dialog box to check if the error is badtoken and, if so, to indicate what the token is. Hopefully that will give us a start on any debugging we have to do. The token should look something like e39b676cc3363095f26575283fd26dc1+\ — that is, it should be a sequence of thirty-two lowercase hexadecimal digits (digits 0 through 9 and letters a through f), followed by a plus sign + and a backslash \. —Ruakh_TALK 15:04, 21 April 2012 (UTC)

It is possible that the page was open for a long time when I did the edit, though I'm not really sure. If I run into the problem again, I'll try a cache refresh. -Atelaes λάλει ἐμοί 15:08, 21 April 2012 (UTC)

This seems to be the same problem that prevents the AutoFormat bot from working properly. 1.20 apparently did a breaking change to tokens that broke most bots and scripts. -- Liliana • 15:00, 21 April 2012 (UTC)

I keep getting "notoken: The token parameter must be set" when trying to mark an edit as patrolled. (I'm using Chrome) SemperBlotto (talk) 10:38, 23 April 2012 (UTC)

Thanks for letting me know. I have Chrome installed on my work machine, so I can try to reproduce that today. —Ruakh_TALK 11:29, 23 April 2012 (UTC)

Unfortunately (?), it works for me on Chrome, so I can't test to figure out the problem you're seeing. However, I've now modified the Gadget to do nothing if it doesn't get a valid patrol-token, rather than create a bunch of buttons that don't work. This should be a bit less frustrating, at least. :-/   —Ruakh_TALK 13:09, 23 April 2012 (UTC)

Ah, the blue Ms have finally disappeared for me. Oddly, the red Ds are still there and still work: I successfully deleted ルナ using them (as a test; and then I restored that seemingly-OK entry). And I can still hide unpatrolled edits and see the red exclamation marks that signify the remaining edits are unpatrolled. - -sche (discuss) 19:03, 24 April 2012 (UTC)

And now, before I even finished writing this, the blue Ms are back and functional: I just patrolled city hall. Yeah, I know...appropriate place to patrol ;) - -sche (discuss) 19:03, 24 April 2012 (UTC)

The blue M's and red D's are more or less independent; they're both created by the same script, obviously, but the blue M's are created in a callback with data from http://en.wiktionary.org/w/api.php?format=json&action=query&list=recentchanges&rctoken=patrol (human-readable version here), whereas the red D's are created in a callback with data from http://en.wiktionary.org/w/api.php?format=json&action=query&prop=info&titles=:&intoken=delete (human-readable version here). Presumably the blue M's disappeared because the didn't supply a patrol-token, or supplied an empty or invalid one; as I mentioned above, I had modified the Gadget not to create the buttons in that case (since they wouldn't work anyway).

In the hopes of getting information that will at least make debugging conceivable, I've modified the Gadget to add some information at the top of the page — right below the header — if an error occurs. Dunno how well that will work, but if/when you encounter this issue again, please let me know what it tells you.

—Ruakh_TALK 20:49, 24 April 2012 (UTC)

right|thumb

Hm, the Ms and Ds have both disappeared for me, now, and I don't see any information below the header, but I've uploaded a screenshot in case I'm missing it. I can still patrol by viewing a specific diff and clicking "Mark as patrolled", as I did here. (That's Firefox. I will test Opera now.) - -sche (discuss) 21:14, 24 April 2012 (UTC)

I see the same thing in Opera, but I'll refresh my cache now and see what happens. - -sche (discuss) 21:20, 24 April 2012 (UTC)

I refreshed the cache, and still see the same thing as before. I did dig these numbers (look at the pre-deletion content of that page) out of the pagesource, if they help any. - -sche (discuss) 21:27, 24 April 2012 (UTC)

Nope, sorry; thanks for the bug-report, but actually that's just because my attempt to add debugging info ended up breaking things. :-S   On the bright side, I've now figured out what URL I need to hard-refresh when I change the Gadget — it's http://en.wiktionary.orghttps://en.wiktionary.org/w/index.php?title=MediaWiki:Gadget-PatrollingEnhancements.js&action=raw&ctype=text/javascript&16727791 — so now I can actually test changes when I make them. Always useful. :-P   —Ruakh_TALK 22:03, 24 April 2012 (UTC)

Ok, glad you figured it out. :) The Ms and Ds are indeed back now. - -sche (discuss) 22:13, 24 April 2012 (UTC)

I've also been intermittently losing the patrolling enhancements, and sometimes on submitting a page I get "Sorry! We could not process your edit due to a loss of session data. Please try again. If it still does not work, try logging out and logging back in"; also I sometimes get the default not-logged-in buttons instead of my "Equinox, my talk, etc." but refreshing the page brings my logged-in state back. And finally, my Webster tool (based on DotNetWikiBot) now takes several attempts to log in, which means several minutes with the "waiting 60 seconds" after each failure. Once logged in, it works fine for as long as I want. Whatever is going on? Equinox ◑ 13:11, 27 April 2012 (UTC)

Same, sometimes they work, then I refresh the recent changes looking for more recent edits, and I lose the ability to patrol. Mglovesfun (talk) 13:16, 27 April 2012 (UTC)

And now the Ms have gone away. The Ds are still there on new pages. SemperBlotto (talk) 21:19, 27 April 2012 (UTC)

And now they're back! SemperBlotto (talk) 21:21, 27 April 2012 (UTC)

I, too, am experiencing the issue of the software periodically saying I'm logged out, only to admit that I'm logged in if I refresh or resubmit the page. I'm not sure that's connected to the patrolling enhancements, though; if anything, I think it may be the more basic issue, and the patrolling enhancements not working may be a side effect of it (of the software periodically forgetting that we're logged in). - -sche (discuss) 21:55, 27 April 2012 (UTC)

Related to the discussion of "c" above, could someone with a bot replace "Late C14", which occurs in about forty entries, with something less opaque, such as "late 14th century"? There were a few other centuries formatted that way ("late C15", "early C15"), but I fixed them by hand. I also manually replaced an instance of "C20, ½"(!) on zemja with {{rfdate}}. - -sche (discuss) 05:59, 24 April 2012 (UTC)

Sounds easy enough. Mglovesfun (talk) 10:09, 24 April 2012 (UTC)

Could someone modify {{Phnx}}'s face so that Phoenician-script terms, like {{Hebr}}-script terms, are not italicised by {{term}}? Italics hamper legibility of a script that already displays as boxes for many people. - -sche (discuss) 20:07, 24 April 2012 (UTC)

It's strange but from what I can find in the script template, it should never be italicised at all unless it is coming from elsewhere. The code in the template is written to always show the text 'raw', without any formatting, even in headword lines. —CodeCat 20:14, 24 April 2012 (UTC)

I'm confused. In the page-version that you link to, the Phoenician-script text is explicitly italicized using ''...'', before being passed to {{term}}; and I don't see any other source of italics. {{term|foo|bar|lang=phn}} — bar — does not show up in italics for me. What am I missing? —Ruakh_TALK 20:35, 24 April 2012 (UTC)

thumb|right

Oh, I linked to the wrong diff (although that diff, showing both italics and non-italics above it, does serve the purpose of showing the reduced legibility of italics). The current revision, with <tt>{{term|𐤒𐤀𐤓𐤕𐤇𐤀𐤃𐤀𐤔𐤕||tr=Qart-ḥadašt|New City|lang=phn}}</tt>, still shows italics for me, though. Also, your example isn't using Phoenician script (as the input), it's using "bar"... - -sche (discuss) 21:02, 24 April 2012 (UTC)

Actually, when I compare 𐤒𐤀𐤓𐤕𐤇𐤀𐤃𐤀𐤔𐤕 (Qart-ḥadašt, “New City”) (term) vs 𐤒𐤀𐤓𐤕𐤇𐤀𐤃𐤀𐤔𐤕 (plain text) vs 𐤒𐤀𐤓𐤕𐤇𐤀𐤃𐤀𐤔𐤕 (explicit italics) (vs 𐤒𐤀𐤓𐤕𐤇𐤀𐤃𐤀𐤔𐤕 (big plain text) vs 𐤒𐤀𐤓𐤕𐤇𐤀𐤃𐤀𐤔𐤕 (big explicit italics)), I see that each displays differently — perhaps term just uses an odd font (one that raises 𐤔, slants 𐤒 and cuts off one of the crossbars of 𐤕), and I mistook that for italics? - -sche (discuss) 21:43, 24 April 2012 (UTC)

How does <span style="font-family: Aegean; font-size: 125%; direction: rtl; unicode-bidi: embed;">𐤒𐤀𐤓𐤕𐤇𐤀𐤃𐤀𐤔𐤕</span> (𐤒𐤀𐤓𐤕𐤇𐤀𐤃𐤀𐤔𐤕) display for you? How about <span style="font-family: sans-serif; font-size: 125%; direction: rtl; unicode-bidi: embed;">𐤒𐤀𐤓𐤕𐤇𐤀𐤃𐤀𐤔𐤕</span> (𐤒𐤀𐤓𐤕𐤇𐤀𐤃𐤀𐤔𐤕)? —Ruakh_TALK 22:09, 24 April 2012 (UTC)

The first one (Aegean) displays in the same pseudo-cursive as discussed above; the second (sans-serif) has the more familiar letter-forms. (Ironic, that the serif font has fewer nubs — e.g. on 𐤕 — than the sans-serif font!) - -sche (discuss) 22:43, 24 April 2012 (UTC)

So, do you think we should remove Aegean from the specification of .Phnx in MediaWiki:Common.css? —Ruakh_TALK 23:11, 24 April 2012 (UTC)

Yeah. I've done so. I split and left it for Ugaritic, because I don't know how good or bad it is for Ugaritic, yet. I'll test and see. - -sche (discuss) 00:46, 25 April 2012 (UTC)

Note that Liliana-60 (talk • contribs) has now added Code2001 in its place; see images here. —Ruakh_TALK 12:21, 25 April 2012 (UTC)

This template had already been created, and I've now expanded it so that it shows some documentation for language templates, as well as their subtemplates. Look at {{en}} for an example. I think it would be a good idea to add this to all language templates? —CodeCat 00:27, 27 April 2012 (UTC)

I tentatively support this, expecting to fully support it but first wanting to know why it was initially only included in some. - -sche (discuss) 00:40, 27 April 2012 (UTC)

I do think it needs a better name though, and it would be best to choose the name before it becomes more widely used. —CodeCat 12:52, 27 April 2012 (UTC)

I know nothing about templates. Could someone add an optional parameter for a Wikipedia link to be used in cases where the Wikipedia page name doesn't match the Wiktionary page name? For example, in the Cancer page the template creates a link to w:Cancer (the page is about the disease) instead of to w:Cancer (astrology). It may not be worth the trouble for a template that's only used 14 times, but it seems wrong to have an uneditable link to an incorrect address. Perhaps it could be made more broadly usable by adding a parameter for Wikipedias in other languages, like {{wikipedia}} has. Chuck Entz (talk) 16:16, 27 April 2012 (UTC)

Well, presumably there would only be 12 distinct values, yes? Maybe with a couple more as alternative forms. If so, it might make more sense to just use a switch statement and add the "(astrology)" bit on the end for those specific zodiac signs that require this for proper WP linking. This could also automatically handle the "previous" and "next" bits as well, reducing the number of arguments required.

Looking briefly at the template and what uses it, some questions come to mind --

• w:Capricornus is about the constellation, with a disambig line at the top pointing to w:Capricorn (astrology). Is that an acceptable destination for the w:Capricornus link on the Capricornus page?
• What preference is there for using the Latinate forms like Capricornus and Scorpius, vs. the more prosaic Anglicized forms like Capricorn and Scorpio?

Further reading leads me to suggest 1) that the astrology sign entries link to zodiac instead of Zodiac, and 2) that we use the Anglicized forms as listed at w:Zodiac#The_twelve_signs. Comments? -- Eiríkr Útlendi │ Tala við mig 17:02, 27 April 2012 (UTC)

I don't know what you mean by "we use the Anglicized forms": we have English entries for Capricorn and for Capricornus. Did you mean "we use {{Zodiac}} in the Anglicized forms' entries"? That may be true, but wouldn't it be better to allow the template to work in entries for both forms? That'd be AFAICT best accomplished by having an optional parameter for the WP pagename, as requested by Check Entz. I've added it (and documentation).​—msh210℠ (talk) 17:40, 27 April 2012 (UTC)

I was wondering for purposes of the {{{previous}}} and {{{next}}} params -- if you're at Libra, is the next sign listed in the template Scorpio, or Scorpius, or both? For Scorpio and Capricorn, EN WP seems to list the zodiac symbols under the Anglicized forms, and the constellations under the Latinate forms. I don't know if that should have any bearing here, which is why I brought it up as a suggestion.  :) -- Eiríkr Útlendi │ Tala við mig 17:59, 27 April 2012 (UTC)

• @msh210, Chuck, anyone else interested, what would you say to the following?

Calling: {{Zodiac|Image:Libra_symbol.png}}

Output would look like the table over on the right here:

Signs of the Zodiac

Virgo		Scorpio, Scorpius
Wikipedia has an article about Libra.

I've got draft of reworked template code in my user space at User:Eirikr/Sandbox3, which apparently I was doing at the same time as msh210's edits to the template itself. The reworked code is more complex, but the calling is simpler; it automatically handles the {{{previous}}} and {{{next}}} params and proper linking to the relevant EN WP articles. Don't know how much that matters to folks. If there's much demand for linking to WP articles in other languages, it wouldn't be too hard to add params for doing so, but it might be better to use {{wikipedia}} to do that.

The new parameter has been added to (and tested in) all 14 entries, so I'm done with this, though it does seem odd to have a redlink to what looks to be an SOP entry (Signs of the Zodiac), when a link to ] might be better, and wiki-linking the previous and next might be nice, too. Thanks for your help! Chuck Entz (talk) 19:20, 27 April 2012 (UTC)

(1) I'm confused. If the template does everything else for you, why not have it choose the image also? (2) You can't use your version in (e.g.) the page ]. That's the benefit of (e.g. my version,) allowing hand-carved parameters.​—msh210℠ (talk) 20:01, 27 April 2012 (UTC)

It'd be easy enough to automate the image, sure. I'd started getting that sorted when I got busy with other stuff IRL.

Chuck's initial comment described use only on the zodiac sign entries, so that's the use case I built to.

About the redlink, that's because there is no Zodiac as I mentioned previously. I'll tweak the code at {{Zodiac}} to fix that momentarily, to point to zodiac instead.

-- Cheers, Eiríkr Útlendi │ Tala við mig 20:14, 27 April 2012 (UTC)

Part of the confusion may be because there's no signature showing where Eirikr's reply ends and mine starts. I began with "The new parameter has been added..." I don't know if I edited over the signature or it just wasn't there. Chuck Entz (talk) 20:37, 27 April 2012 (UTC)

Mediawiki seems to be undergoing a number of changes lately. Today, I look at my watchlist, and some of the items are bold, while others are not, and I'm trying to make sense of it. My first instinct was that bold items have been edited multiple times recently, where non-bolded items only once, which would be a useful feature. However, Wiktionary:Requested entries (Sanskrit) is bold, but has only been edited once in the last three weeks, whereas Wiktionary:Requested entries (Ancient Greek) is not bold, but has been edited a number of times recently. I tried checking the release notes, but didn't find anything. Does anyone know how to interpret this? -Atelaes λάλει ἐμοί 01:13, 28 April 2012 (UTC)

It shows you which pages you haven't viewed yet since the last change, so you can keep track of which watched items you still need to have a look at. —CodeCat 01:18, 28 April 2012 (UTC)

Ah....that's pretty slick. Thanks so much. -Atelaes λάλει ἐμοί 01:53, 28 April 2012 (UTC)

This doesn't seem like an improvement for Wiktionary. Aren't we usually happy that some whitelisted person has looked at something? And it has no value for the discussion pages. DCDuring TALK 02:36, 28 April 2012 (UTC)

I suppose it depends on how you use your watchlist. I use mine primarily for keeping up to date with things I consider important. It is very rare that I have to patrol any of the changes on it (though I do try and keep as much of the Ancient Greek section as possible on my watchlist, and the occasional edit needing patrolling does pop up). If you typically do a lot of patrolling based off your watchlist, then I can see how it might simply be less than helpful noise. -Atelaes λάλει ἐμοί 03:17, 28 April 2012 (UTC)

Yep, it will be very useful for me, it'll save me reading the same edits more than once. Mglovesfun (talk) 03:47, 28 April 2012 (UTC)

Less useful for me since I often check what a change was merely by means of popups rather than by actually going to the page, so even though I've already seen the change, the page name stays bold for me. But I can live with it; Wikisource and Commons have been doing it this way for a long time now. —Angr 09:21, 28 April 2012 (UTC)

I'm sure I could learn to live with it eventually. But if there are enough people who are unhappy with it and there is something short of a rectal tonsillectomy that can give another presentation with, say, no bold on that page or more selective bold, perhaps some JS or CSS maven can provide relief to those who want it. DCDuring TALK 18:09, 28 April 2012 (UTC)

Adding .mw-watched{font-weight:normal;} to your CSS will remove the bolding. --Yair rand (talk) 15:11, 29 April 2012 (UTC)

Thank you. I will definitely try it out. Every single item on my most recent 12-hour watchlist appears bold. A little excessive, don't you think? Especially since most of the principal namespace items only appear there because of translations, on which I have nothing to contribute. I would love to exclude all translations. DCDuring TALK 20:16, 29 April 2012 (UTC)

Ahhhh. Much better. My headache will go away soon, I'm sure. DCDuring TALK 20:19, 29 April 2012 (UTC)

It contains ]. Obviously this shouldn't happen; what's the solution? Adding the families seems okay, but maybe {{#ifexist:}} or {{does-template-exist}}. Mglovesfun (talk) 11:11, 28 April 2012 (UTC)

Maybe these categories should just be merged into Latin. After all, it doesn't really matter much for our category structure whether a term was derived from Medieval Latin or Classical Latin. The etymology itself can of course still be specific. —CodeCat 12:15, 28 April 2012 (UTC)

Well I suppose, but we don't need to do that. And I'd oppose it. For what it's worth some might say Category:English terms derived from Latin "doesn't really matter much for our category structure" though I find it sort of interesting, it's not of much practical use that I can think of. But on reflection, the ifexist solution seems ok. {{derivcatboiler}} is only used on categories and only once per page, so the server side issues are minimal. Deleting stuff like {{ML.}} is a very different matter. Mglovesfun (talk) 12:18, 28 April 2012 (UTC)

If {{derivcatboiler/ALL}} were less horrendous, I could do it myself. Mglovesfun (talk) 12:19, 28 April 2012 (UTC)

I don't think you would need to. If you create {{etyl:ML./family}} it would work I imagine. —CodeCat 12:22, 28 April 2012 (UTC)

I know, but that would put this into Category:English terms derived from Italic languages which I don't think is desirable. Seriously though, any way that Daniel Carrero could write templates that mere mortals can understand? Mglovesfun (talk) 12:24, 28 April 2012 (UTC)

Why is that not desirable? And why isn't Category:English terms derived from Latin already there?? —Angr 12:54, 28 April 2012 (UTC)

I've fixed it now. I've created the template as I suggested and it seems to work fine. —CodeCat 13:04, 28 April 2012 (UTC)

I've now tried to simplified the template somewhat and I've added comments to help as well. —CodeCat 16:58, 28 April 2012 (UTC)

Looks good; well thought through. Mglovesfun (talk) 11:02, 29 April 2012 (UTC)

On the Italian Wiktionary, if you hover the cursor over a blue-linked word then up pops its definition. See it:abbaside as an example. How does this happen? Can we have the same feature, please? SemperBlotto (talk) 17:12, 28 April 2012 (UTC)

When I hover over the blue links I just see the word in the blue link. —CodeCat 17:26, 28 April 2012 (UTC)

Yeah, I just see the word in the blue link, too. However, I think Lupin popups do something similar (they can be enabled in PREFS). - -sche (discuss) 17:28, 28 April 2012 (UTC)

OK - here, if I go to "My Preferences" => "Gadgets" and tick "Navigation popups, page previews and editing functions popup when hovering over links" then it does the same here (I had the equivalent ticked on it.wiktionary). SemperBlotto (talk) 17:35, 28 April 2012 (UTC)

Does anyone here know how we managed to modify the navpops gadget from the standard ('pedia) version? Our version is well-suited to Wiktionary, but I wish it showed part of speech as well. Maybe also we could show the arguments to {{head}} for Latin entries (so I can see the genitive and thus figure out the declension, as well as seeing the gender and macrons). --Μετάknowledge^{discuss/deeds} 00:04, 29 April 2012 (UTC)

The gadget is at MediaWiki:Gadget-popups.js; that page, in turn, imports Lupin's WP page and User:Connel MacKenzie/mess-with-popups.js, which is what seems to strip headers. I think if you (Metaknowledge) turn off Lupin popups in PREFs, add to your own common.js the content of the first page minus the line that imports User:Connel MacKenzie/mess-with-popups.js, and then manually add the contents of Connel's page, you can tinker with it and see if you can get it to show you headers and head-arguments. Or we can ask Yair or wait until Ruakh comes back and ask him. :D - -sche (discuss) 00:31, 29 April 2012 (UTC)

The link to Connel's page is great, thanks! My skills are still too low to make anything successful, but I'll try (as a language, I'm at js-1...). --Μετάknowledge^{discuss/deeds} 00:48, 29 April 2012 (UTC)

Never mind, I'm worse than I thought. I commented out User:Metaknowledge/vector.js and re-enabled navpops because it was so frustrating: I thought I hadn't changed anything, but then the popups were only showing the L2 headers and no content below them! --Μετάknowledge^{discuss/deeds} 01:27, 29 April 2012 (UTC)

Please assist Category:Chapacuran languages, Category:Hmong-Mien languages, Category:Jê languages, Category:Mataco-Guaicuru languages, Category:Trans-New Guinea languages, Category:Tyrsenian languages, and Category:Wintuan languages are in redlink categories and have template errors, but I'm not smart enough to fix it. Thanks. koavf (talk) 00:26, 30 April 2012 (UTC)

Thanks for spotting these! I've fixed Category:Trans-New Guinea languages, which may have broken when we stopped using the non-genetic category Papuan, and it looks like Nadando has fixed the others, except Category:Jê languages. :) I don't know of a code for Macro-Jê, so we'll probably have to devise an "exceptional code" (in Wiktionary parlance) for it. - -sche (discuss) 00:40, 30 April 2012 (UTC)

I have tentatively devised ] for Macro-Jê. (Liliana may correct it to sai-jee or something else...) - -sche (discuss) 00:44, 30 April 2012 (UTC)

Ah, CodeCat's fixed it to sai-mje. Thanks, CodeCat. I'll expand WT:Families to note that we don't use qfa when there's nai or sai available, or is that only partially true? - -sche (discuss) 00:49, 30 April 2012 (UTC)

Honestly I think for the sake of consistency we shouldn't use the 'non-family' codes ({{etyl:nai}}, {{etyl:sai}}, {{etyl:aus}}, {{etyl:paa}} and maybe others) at all. Right now we don't use them directly as families but we do use them as prefixes to create new codes. I would like that practice to be abandoned and all of them changed to use the qfa- prefix. —CodeCat 00:53, 30 April 2012 (UTC)

On a related note: I recently created Category:Indo-Portuguese language and assigned it the family code cpp, as specified here. However, I now notice this doesn't appear at WT:Families (which I didn't realise existed until just now), and I also wonder if it should be crp-cpp or something, and since I have never understood the Byzantine complexity of our language templates and subtemplates, I am hoping someone else will tell me how this should look. Ƿidsiþ 09:36, 1 May 2012 (UTC)

Do we use them? I thought that's what {{ancestor of language}} was there for. -- Liliana • 11:36, 1 May 2012 (UTC)

Is this the sort of soft redirect we want here? Mglovesfun (talk) 14:44, 30 April 2012 (UTC)

It's like an empty sleeve: I don't see the 'arm in it.​—msh210℠ (talk) 17:05, 30 April 2012 (UTC)