This is an archive page that has been kept for historical purposes. The conversations on this page are no longer live.

June 2011

Sloooooooooow

This wiki is incredibly slow today (other sites seem normal, so I don't think it's me). I'm going to do something more productive instead. SemperBlotto 10:27, 3 June 2011 (UTC)[reply]

It's my ISP's fault - "You will currently be experiencing intermittent connection issues on your broadband internet service. Our engineers are aware of this issue and are currently working to fix it fast. We apologise for any inconvenience this may be causing." SemperBlotto 14:48, 3 June 2011 (UTC)[reply]

Dutch nouns

Would anyone object if I converted {{infl|nl|noun}} to {{infl|nl|noun|g=g}} a bit like I did for French nouns a few weeks ago? It would fill up Category:Dutch nouns with incomplete gender. Mglovesfun (talk) 16:24, 4 June 2011 (UTC)[reply]

I wouldn't mind, but replacing it with {{nl-noun}} would be preferable. —CodeCa t 18:17, 4 June 2011 (UTC)[reply]

{{nl-noun}} produces automatic plurals and diminutives, some (perhaps more than 50%) of which will be wrong. It's the same reason I don't convert {{infl|fr|noun|g=m}} to {{fr-noun|m}} - something like mois could have the automatic plural moiss. Mglovesfun (talk) 11:09, 5 June 2011 (UTC)[reply]

Nobody's objected. --Mglovesfun (talk) 10:36, 9 June 2011 (UTC)[reply]

Help with template for Japanese Pitch Accent

I've written a template for Japanese Pitch Accent. (I'm about to use it for a batch import.) It displays like this:

(Standard Japanese) Pitch Accent: びしょうじょ [2]

And the code looks like this: {{ja-accent-standard|accent=2|び|しょ|う|じょ}}. First you have the accent as a named parameter (a number saying which mora is accented). Note: a mora is similar to a syllable, and can be one or more characters (kana). After the named parameter follows each mora in the word as an unnamed parameter.

This works pretty well, and I'm quite happy with it. It works for 99% of the entries.

However, there are some entries with 2 kernels (i.e. downsteps in pitch). Also, though I've yet to see one, there's no reason why there couldn't be more than 2.

E.g. 四方八方, which is しほう-はっぽう [2]-[3] has 2 kernels. I want it to show this:

(Standard Japanese) Pitch Accent: しほう-はっぽう [2]-[3]

What I want to write is: {{ja-accent-standard|accent=2-3|し|ほ|う|-|は|っ|ぽ|う}} and have it automagically work, but I don't see how to do that.

Any ideas for how to write such a template? Vaste 06:34, 11 June 2011 (UTC)[reply]

Would the following work perhaps?

I add another parameter accent2, and if it's present, I'll look for the "-" separator (with a switch). I then now where each part of the word starts/ends and I can call the original template on each part. Same could be done with a parameter accent3.

E.g. so I would write (for 粗衣粗食):

Is this too ugly? Vaste 06:32, 12 June 2011 (UTC)[reply]

Trying to make a template subst-able

The template {{langrev}} works fine when it's transcluded, and it works fine when subst-ed as long as the subtemplate for the language name in question exists. It's only when it doesn't exist ({{langrev|foobar}} for example) that the template doesn't work. It works when transcluded and gives an empty string, but when subst-ed it gives something else instead. Does anyone know how this could be fixed, so that it is subst-ed with an empty string if the parameter is an unknown language name? —CodeCa t 11:50, 13 June 2011 (UTC)[reply]

Essentially, {{subst:langrev|French}} works because Template:langrev/French exists, {{subst:langrev|ABCDEF}} creates {{subst:langrev/ABCDEF}}, which can't subst: because it doesn't exist. You'll need some sort of {{safesubst:#ifexist:Template:langrev/1 in there (would finish, but am going out and haven't worked it out in my head yet). --Mglovesfun (talk) 11:58, 13 June 2011 (UTC)[reply]

I wanted to avoid using ifexist. The template works when not subst-ed because if the subtemplate doesn't exist, it expands literally to [[:Template:foobar]], which can then be checked for. —CodeCa t 12:06, 13 June 2011 (UTC)[reply]

After a lot of experimentation, I've found and implemented a solution. I don't have time right now, though, to explain the ins and outs of why this approach was necessary; sorry. I'll comment back later. —Ruakh_TALK 15:02, 13 June 2011 (UTC)[reply]

I have no idea what you just did but thank you! —CodeCa t 15:07, 13 June 2011 (UTC)[reply]

You're welcome! —Ruakh_TALK 15:30, 13 June 2011 (UTC)[reply]

O.K., turns out I do have time. (A co-worker in QA messaged me, asking if I was available . . . and I haven't heard from her since.)

So, the main problem is that {{subst:#ifeq:a|b|c|d}} (or {{safesubst:#ifeq:a|b|c|d}}) apparently doesn't evaluate any non-substituted template-calls or non-substituted parser-function-calls in a or b. Therefore, while {{#ifeq:{{fr}}|French|equal|unequal}} and {{subst:#ifeq:{{subst:fr}}|French|equal|unequal}} both produce equal, {{subst:#ifeq:{{fr}}|French|equal|unequal}} produces unequal. (This is not just #ifeq:, by the way. {{urlencode:{{fr}}}} and {{subst:urlencode:{{subst:fr}}}} both produce French, but {{subst:urlencode:{{fr}}}} produces %7B%7Bfr%7D%7D.)

Unfortunately, the obvious solution — just change {{langrev/{{{1|}}}}} to {{safesubst:langrev/{{{1|}}}}} — doesn't actually work. This is because non-existent templates can't actually be substituted, apparently; {{safesubst:langrev/foobar}} just gets saved verbatim to the database, and the translation to [[:Template:langrev/foobar]] happens during rendering. (Incidentally, {{subst:langrev/foobar}} also gets saved verbatim to the database, and doesn't even get translated during rendering — since subst:, as you know, doesn't trigger transclusion during rendering, which is the whole reason that Conrad created safesubst: to begin with — so it actually gets output verbatim as well: {{subst:langrev/foobar}}.)

So, my solution was to use {{safesubst:padleft:|1|...}} to grab just the first character of {{safesubst:langrev/{{{1|}}}}}, and see whether it's [ (meaning that we're not substituting, and the template doesn't exist, so {{safesubst:langrev/foobar}} is becoming [[:Template:langrev/foobar]]), or { (meaning that we are substituting, and the template doesn't exist, so {{safesubst:langrev/foobar}} is remaining itself), or anything else (meaning that the template does exist). This isn't a perfect test, since in theory {{langrev/foobar}} could be a real template whose value starts with [ or {, but I knew that wouldn't be the case here. Ideally I would have preferred to test more than just one character, but it would be messy to have [[ or {{ in the string being compared to, because that could confuse the MediaWiki parser. (But if we ever need that in the future, we can probably accomplish it by using {{safesubst:urlencode:...}} to translate [[ to %5B%5B and {{ to %7B%7B.)

Does that make sense?

—Ruakh_TALK 15:30, 13 June 2011 (UTC)[reply]

Yeah... kind of. Substitution still confuses me a lot. I'm just glad it works! —CodeCa t 16:17, 13 June 2011 (UTC)[reply]

Using plural forms in category boilerplate parameters where appropriate

Right now, most of the category boilerplate templates such as {{poscatboiler}} take a parameter that indicates the name of the category, but that parameter is singular even though the name of the category itself is plural. For example, {{poscatboiler|en|noun}} creates Category:English nouns. Daniel said it was originally inspired by {{infl}}, since part-of-speech categories were the first to use such a system. But now that we have many more categories, it's becoming cumbersome because they all have to be added to {{theplural}} each time. So I would like to ask if anyone would object to simply using the plural form as the parameter? —CodeCa t 20:57, 13 June 2011 (UTC)[reply]

topiccatboiler

I've been working on improving the {{catboiler}} template so that it can be used for a wider range of purposes. One of those purposes is to replace {{topic cat}}, but that's so widely used that it would be a bad idea to start messing with it on a significant scale. That's why I'd like to ask first if anyone would object to me testing the new template, {{topiccatboiler}}, on a small part of the topical tree and a few languages, to see if there are any bugs that need to be worked out? So far it already works well, but there may be some small bugs or improvements that need to be taken care of, and it would be better to make sure they're found before the template is used on a full scale. —CodeCa t 16:24, 15 June 2011 (UTC)[reply]

Template:syc

It used to display Classical Syriac, now it displays Syriac. {{syr}} already displays Syriac. Is this as straightforward as it appears. --Mglovesfun (talk) 17:17, 15 June 2011 (UTC)[reply]

According to ISO 639, syc is 'Classical Syriac', a single historical language, and syr is 'Syriac (Northeastern Neo-Aramaic)', a living macrolanguage. So it seems to me that the original naming was correct. —CodeCa t 10:47, 16 June 2011 (UTC)[reply]

It could (or frankly, it will) create a bit of a mess if we modify one now. In this version of ܗܘ the contributed used both syc and syr. --Mglovesfun (talk) 10:56, 16 June 2011 (UTC)[reply]

There is no Category:Classical Syriac language yet, so we can assume that all uses of {{syc}} should really be {{syr}}. Maybe a bot could fix this? —CodeCa t 10:58, 16 June 2011 (UTC)[reply]

Using regular expressions it's quite easy. I agree that this is the easiest way, then make {{syc}} displays Classical Syriac and let editors changes entries from one to the other whenever they see fit to. --Mglovesfun (talk) 11:10, 16 June 2011 (UTC)[reply]

No, I meant precisely {{syc}}, Classical Syriac of Edessa, everywhere in Category:xcl:Syriac derivations. --Vahag 11:27, 16 June 2011 (UTC)[reply]

It's enough to make you syc (wahey!) --Mglovesfun (talk) 11:30, 16 June 2011 (UTC)[reply]

The Syriac templates would need to be renamed, too. Maybe that would be a good place to start. —CodeCa t 11:48, 16 June 2011 (UTC)[reply]

Yes but not so fast, let's let the discussion go on a little. --Mglovesfun (talk) 11:49, 16 June 2011 (UTC)[reply]

I've looked around a bit and I noticed that the code 'syr' is used in some places already. So it looks like for a long time we've used both codes for the same thing. —CodeCa t 12:11, 16 June 2011 (UTC)[reply]

Yes, "syc" should probably be changed back to "Classical Syriac," which is what I've been using it for. The code "syc" is indeed used for "Neo-Syriac" (divided into the dialects "Assyrian Neo-Aramaic" and "Chaldean Neo-Aramaic", apparently). Maybe it's a good idea to have "syc" be "Classical Syriac" while "syr" is "Neo-Syriac"? It gets rid of all the ambiguity "Syriac" causes. I know that doesn't jive too well with Wiktionary's policy of not using "modern" or "neo" or "new" when naming languages, but "Syriac" almost always refers to the classical language. Modern speakers usually don't even call their language "Syriac" (in English, at least). --334a 17:36, 16 June 2011 (UTC)[reply]

A lot of people use 'Greek' to refer to 'Ancient Greek' as well. —CodeCa t 17:42, 16 June 2011 (UTC)[reply]

Is it gonna be the case that these all need to be sorted by hand? And in some cases split between Classical Syriac and Syriac? --Mglovesfun (talk) 17:43, 16 June 2011 (UTC)[reply]

Are there any Classical Syriac entries? If not, then all the 'proper' uses of syc are probably only in etymology sections. I've already converted most of the categories. —CodeCa t 17:52, 16 June 2011 (UTC)[reply]

I think from 334a is saying, it might be the opposite, and the question I was about to ask was 'shall we convert all of these to Classical Syriac?' If 334a has created these as Classical Syriac entries (that is, syc), how many Syriac entries do we have created by other users? So, if 334a has created in these as 'syc' entries, I think we should respect that. --Mglovesfun (talk) 18:02, 16 June 2011 (UTC)[reply]

But I don't know how to tell the two apart, so I can't really help with that. —CodeCa t 18:06, 16 June 2011 (UTC)[reply]

Mglovesfun understood me correctly: every single entry I've made in "syc" is Classical Syriac. Should "syr" even be used? I thought Wiktionary's policy was not to have macrolanguages, but I could be wrong. To be honest, the labelling of only Assyrian and Chaldean Neo-Aramaic as "Neo-Syriac" is pretty dumb since the Neo-Aramaic dialect "Turoyo" is a lot closer to Classical Syriac than Assyrian/Chaldean Neo-Aramaic but isn't included in the "syr" macrolanguage group. The folks over at ISO/Ethnologue/wherever might realize that one day and change it... --334a 18:27, 16 June 2011 (UTC)[reply]

If that's the case, then we would need to start by changing the template. Without it, we can't create entries using the code. —CodeCa t 18:40, 16 June 2011 (UTC)[reply]

Is there any modern language that is generally referred to as "Syriac"? --Yair rand 18:54, 16 June 2011 (UTC)[reply]

Syriac (neo-Syriac that is) is an official language in some areas in Iraq according to its constitution It is also being taught in some public schools in Iraq and Sweden.--Rafy 21:28, 16 June 2011 (UTC)[reply]

I would argue that it isn't, at least not really. Usual names include "Assyrian", "Chaldean", "Neo-Aramaic" or even just "Sureth/Suret/Surit". Having the names "Syriac" (for Neo-Syriac) and "Classical Syriac" is a little like calling Italian "Latin" and Latin "Classical Latin". In the same way that Romance languages don't descend from Classical Latin (but Vulgar Latin), most Neo-Aramaic languages, or at least Assyrian and Chaldean, don't directly descend from Classical Syriac. The name "Syriac", which describes the classical eastern Aramaic dialect of Edessa, is a misnomer when it comes to the Northwestern Neo-Aramaic languages. A lot of the confusion and multiple names has to do with relatively recent sociolinguistic and nationalist reasons. --334a 21:36, 16 June 2011 (UTC)[reply]

(NB, this is why I said to CodeCat "Yes but not so fast, let's let the discussion go on a little.") Mglovesfun (talk) 22:01, 16 June 2011 (UTC)[reply]

Does anyone object to {{syc}} displaying Classical Syriac instead of just Syriac? I've just done it now as CodeCat suggested. This has turned into a bit of a mess. Good news is we 'only' have 355 Syriac entries. {{syc}} has 718 transclusions, {{syr}} has 46, just 9 of those in the main namespace. Mglovesfun (talk) 22:21, 16 June 2011 (UTC)[reply]

I take it that the templates actually have the correct code, they just need to go into different categories? —CodeCa t 22:49, 16 June 2011 (UTC)[reply]

I might be mostly level 2 headers than need changing, and then there's translations. In reply to 334a, we don't allow 'Chinese' but we do allow Arabic and Nahuatl. Mglovesfun (talk) 23:16, 16 June 2011 (UTC)[reply]

Is there actually anything that does use {{syr}} correctly, or is everything we have that's now called Syriac actually Classical Syriac? —CodeCa t 23:23, 16 June 2011 (UTC)[reply]

Debatable; w:Northeastern Neo-Aramaic has some good coverage. If it's anything like Greek and Ancient Greek, there's probably a massive overlap. Mglovesfun (talk) 23:35, 16 June 2011 (UTC)[reply]

Ok, but what I mean is, is there anything that should definitely not be moved to Classical Syriac? Or can I just move everything indiscriminately? —CodeCa t 23:51, 16 June 2011 (UTC)[reply]

Again, I think waiting another 24 hours will do no harm. I can't answer that, we need 334a. It literally will take less than 5 minutes to change these by bot. AWB, Category (recursive) with Category:Classical Syriac language, change ==Syriac== and to ==Classical Syriac== and you're done! --Mglovesfun (talk) 11:14, 17 June 2011 (UTC)[reply]

I had a once-over of all the {{syr}} transclusions and fixed what was supposed to be Classical Syriac. The few {{syc}} entries that weren't created by me are also Classical Syriac (the ones that I know of and/or edited, anyway), so I think it's pretty safe to go ahead with a bot and make the L2 header switch. Also, is it possible to change all the entries under (the subcategories of) Category:Syriac irregular nouns to Category:Classical Syriac irregular nouns? --334a 03:30, 18 June 2011 (UTC)[reply]

Shouldn't be too hard. Mglovesfun (talk) 09:55, 18 June 2011 (UTC)[reply]

Template:emoticon

Template:emoticon failed RFDO last year. However, I recreated it to help me with populating Category:Japanese emoticons. Feel free to revise my decisions. --Daniel 05:29, 18 June 2011 (UTC)[reply]

I think the point was the emoticon is not a context. If something's an emoticon, you should write 'emoticon' in the definition, and tag using a manual category. Writing out a manual category really isn't as difficult as people think; I don't understand why people are so scared of it. Mglovesfun (talk) 09:54, 18 June 2011 (UTC)[reply]

NB I've deleted it as 'previously failed RFD', but we can still reopen the discussion. Do you (others) prefer to have (emoticon) on the definition line, or simply to write in the definition 'An emoticon that […] '. Mglovesfun (talk) 10:07, 18 June 2011 (UTC)[reply]

I like your solution. As far as I'm concerned, from this short discussion onwards, {{emoticon}} can stay deleted. --Daniel 01:57, 25 June 2011 (UTC)[reply]

Sorting in Welsh

Welsh has the peculiar property that ‹ng› is considered a single letter, which is alphabetized between ‹g› and ‹h›, when it's pronounced [ŋ], but it's considered two letters ‹n›+‹g› (and thus alphabetized between ‹nff› and ‹nh›) when it's pronounced [ŋɡ]. The word cyngyd is actually ambiguous between the two: when it means 'adjoining' or 'frontier', it's pronounced [ˈkəŋɪd] and should be alphabetized between words starting cyg- and words starting cyh-. But when it means 'intention', it's pronounced [ˈkəŋɡɪd] and should be alphabetized between words starting cynff- and words starting cynh-. This is what Welsh print dictionaries do: the word is listed twice, 'adjoining'/'frontier' under C+Y+Ng+Y+D and 'intention' under C+Y+N+G+Y+D. In the entry itself, I've tried to force the correct sorting of the adjective meaning 'adjoining' and the noun meaning 'frontier' using sort=cygzyd, while the noun meaning 'intention' I didn't give a sort= parameter since it can sort automatically. This kludge worked for the adjective: at Category:Welsh adjectives, it's correctly sorted between cyfyng and Cymraeg. But at Category:Welsh nouns, there's only one entry, and it's alphabetized between cynaniad and cynrychiolydd. Ideally, it should be listed twice in the category: once where it already is, and once again between cyfystyr and cyhoedd. Is there any technical way to make that happen? —An gr 08:51, 18 June 2011 (UTC)[reply]

Is there a unicode character for <ng> when it is used as a single character? If not there is no way to distinguish two identical strings as you describe. - [The]DaveRoss 20:43, 20 June 2011 (UTC)[reply]

No, there isn't, and if there were it would probably be deprecated, just like the single-character codes for Dutch IJ (Ĳ ĳ) and Serbo-Croatian Dž (Ǆ ǅ ǆ), Lj (Ǉ ǈ ǉ), and Nj (Ǌ ǋ ǌ). —An gr 21:51, 20 June 2011 (UTC)[reply]

What about a zero-width space ⁠? Would that work? —CodeCa t 21:56, 20 June 2011 (UTC)[reply]

I dunno. I suppose cyn‌gyd is a possible article title, but I don't know if it would be considered legitimate. I'd have to put "See also" templates at the top of each article linking to the other, but since the two would look alike to the human eye, it would definite confuse people. (But that would be true with a separate "Ng" character, if one existed, too.) —An gr 05:20, 21 June 2011 (UTC)[reply]

This is kind of . . . awkward . . . but redirects can belong to categories. You can create a [[cyn⁠gyd]] that redirects to [[cyngyd]] and belongs to Category:Welsh nouns with one sort order, while [[cyngyd]] itself belongs to Category:Welsh nouns with a different sort order. —Ruakh_TALK 11:17, 21 June 2011 (UTC)[reply]

Also, if you do plan to do this, I'd use the zero-width non-joiner (‌). This is what Persian uses as well, which has a similar problem. -- Prince Kassad 12:26, 21 June 2011 (UTC)[reply]

Yes, that worked. I used the zero-width non-joiner rather than the zero-width space in the redirect, and now Category:Welsh nouns has two entries, one in each location. (One of them is italicized because it's a redirect, but I can live with that.) Thanks for your help! —An gr 06:51, 22 June 2011 (UTC)[reply]

Distinguishing categorised and not-categorised scripts

Many templates have a sc= parameter which allows you to set the script. The category boilerplate templates use this parameter to add an extra bit to the name of the category to specify what script its contents is in. However, we have no proper method of categorising entries into those categories. {{infl|sh|noun|sc=Cyrl}} will categorise in Category:Serbo-Croatian nouns. I wonder how we could adjust templates like this so that they know their script parameter should also be used in the name of the category, so that it becomes Category:Serbo-Croatian nouns in Cyrillic script. —CodeCa t 10:31, 19 June 2011 (UTC)[reply]

Why would that be necessary? The category already divides up Latin and Cyrillic scripts by sorting. As you browse the category, first you get all the Latin-alphabet words, and then all the Cyrillic-alphabet words. To find a word, just click on the initial letter in the script you want in the little navbox thingy on the category page. —An gr 13:53, 19 June 2011 (UTC)[reply]

That will work for Serbo-Croatian, but not for Chinese, where the two scripts are mixed together. —CodeCa t 13:55, 19 June 2011 (UTC)[reply]

Simplified and Traditional Chinese characters aren't really two different scripts. —An gr 16:49, 19 June 2011 (UTC)[reply]

Making {{infl}} categorize all words by their scripts is a bad idea, at least because people don't want to separate Serbo-Croatian into categories by script. --Daniel 02:15, 24 June 2011 (UTC)[reply]

Linking here from Venetian Wikipedia

I tried to link to one of our pages from vec.Wikipedia using [[wikt:en:insegnar]]. It gave a blue link, but clicking on it went to Wikimedia instead of here. It seems to me that this is because there is no vec.Wiktionary. Is this a bug? or is there a better way of linking here in this situation? SemperBlotto 15:43, 20 June 2011 (UTC)[reply]

Maybe [[en:wikt:insegnar]]? I think [[wikt:en:insegnar]] resolves as "go from vec.Wikipedia to vec.Wiktionary, and from there to en.Wiktionary" (and fails if there is no vec.Wiktionary), whereas [[en:wikt:insegnar]] should resolve as "go from vec.Wikipedia to en.Wikipedia, then to en.Wiktionary". - -sche (discuss) 16:31, 20 June 2011 (UTC)[reply]

Cross-wiki linking can be ugly. There's a trick: use m:wikt:insegnar, it works everywhere. -- Prince Kassad 16:40, 20 June 2011 (UTC)[reply]

How does m:wikt know which Wiktionary (English vs Venetian vs German etc) to go to? Or does it always only go to en.Wikt? - -sche (discuss) 17:24, 20 June 2011 (UTC)[reply]

It goes to en.wikt, no matter what. -- Prince Kassad 18:42, 20 June 2011 (UTC)[reply]

(Re -sche.) Wouldn't that need to be [[:en:wikt:insegnar]], with a colon?—msh210℠ (talk) 17:08, 20 June 2011 (UTC)[reply]

Yes, the extra colon makes it work! SemperBlotto 18:46, 20 June 2011 (UTC)[reply]

Ah, you're right. - -sche (discuss) 17:24, 20 June 2011 (UTC)[reply]

Or create a template like {{wikipedia}}, though I suppose it won't be able to handle every single language, you could certainly allow lang=en and lang=it. --Mglovesfun (talk) 17:11, 20 June 2011 (UTC)[reply]

Static Dump / Openzim Extention

I'd like to request a static dump of Wiktionary dump (html, not xml). If possible adding .zim export capability would be even better to enable offline work. OrenBochman 13:20, 22 June 2011 (UTC)[reply]

[1]- these haven't been available for a long time. Nadando 18:01, 22 June 2011 (UTC)[reply]

Those are Wikipedia only I think. Also they are 3 years old. - [The]DaveRoss 19:37, 22 June 2011 (UTC)[reply]

Xyzy and infl

I believe {{infl}} should not support {{Xyzy}} anymore. --Daniel 02:12, 24 June 2011 (UTC)[reply]

See diff, diff, and Thread:User_talk:Yair_rand/The_first_parameter_of_infl. --Yair rand 02:16, 24 June 2011 (UTC)[reply]

Maybe we should keep {{Xyzy}}, though, rather than having duplicate code in large numbers of different templates ({{infl}}, {{term}}, {{l}}/{{onym}}, {{t}}, {{form of}}, etc.). If sc= and lang= are both arguments to {{Xyzy}}, then other templates can just do something like {{Xyzy|...|lang={{{lang|}}}|sc={{{sc|}}}|face=...}} and let {{Xyzy}} figure out whether sc= is non-blank, whether lang= is supported, etc. —Ruakh_TALK 02:34, 24 June 2011 (UTC)[reply]

`{{term}}`

How come {{term}} is no long italicising words? Ƿidsiþ 06:28, 25 June 2011 (UTC)[reply]

Adding en: to topical categories

Is there any way to do this, recategorize the entries adding en:? I'm not quite sure how to do it. Obviously something like [[Category:English nouns]] to [[Category:en:English nouns]] is unacceptable. Thoughts? And what about {{context}}, is that up-to-date yet? Mglovesfun (talk) 22:44, 29 June 2011 (UTC)[reply]

Yes, I updated {{context}}. Either {{context|grammar}} or {{context|grammar|lang=en}} should categorize an entry into Category:en:Grammar. --Daniel 11:10, 30 June 2011 (UTC)[reply]

I trust you first went through all our entries adding lang= to context tags in non-English sections.—msh210℠ (talk) 16:11, 30 June 2011 (UTC)[reply]

No, msh210, I didn't do that. If a Mandarin section has {{context|grammar}} today, it is incorrectly categorized. If the same Mandarin section had the same code before the creation of categories with "en:", it was incorrectly categorized as well. I did not solve that problem, and I did not introduce that problem, because that's not my problem. --Daniel 10:01, 1 July 2011 (UTC)[reply]

That's been a problem for years and years; if anyone knows how to solve it, be our guest! Mglovesfun (talk) 10:15, 1 July 2011 (UTC)[reply]

AF ~~KassadBot~~ A bot can do it easily: check the language header and add lang=foo to any context tag that lacks it. it doesn't even have to be sure it's a context tag: there's nothing wrong with adding that parameter to a non-context tag on the definition line. I have longed for such a bot for a long time.—msh210℠ (talk) 18:58, 1 July 2011 (UTC)[reply]

I would prefer it if the language were always required, so that we could find these errors without bots. The template could add the entry to a cleanup category if the language is missing. —CodeCa t 19:05, 1 July 2011 (UTC)[reply]

That's not inconsistent with having a bot add the parameter.—msh210℠ (talk) 19:31, 1 July 2011 (UTC)[reply]

But it would allow us to rely on bots less. Bots come and go as their owners join and become inactive, but a cleanup category will always work. —CodeCa t 19:46, 1 July 2011 (UTC)[reply]

Maybe you could check whether the first part of the category is the name of the language? Something like... 'if there is a category in the English section and its name begins with English, it shouldn't be prefixed'. —CodeCa t 23:17, 29 June 2011 (UTC)[reply]

Good idea. --Daniel 11:10, 30 June 2011 (UTC)[reply]

I'll work on it. Mglovesfun (talk) 10:15, 1 July 2011 (UTC)[reply]

I've come up with a heavy, ugly yet perfectly good way of doing it using User:MglovesfunBot/switch. The switch is perhaps so big, it's impractical to use it in the number of entries we're talking about. Like all of them! Mglovesfun (talk) 11:02, 1 July 2011 (UTC)[reply]

But your switch would only work if there were a way to separate the language name from the rest of the category name. And in any case, we have {{langrev}} now which is faster than your switch but it does the same. —CodeCa t 11:19, 1 July 2011 (UTC)[reply]

That is how it works (in reply to sentence 1) and I've changed the switch (in reply to sentence 2) but... I have found an unexpected bug. Shouldn't be too hard to fix; but will have to think about how to modify the code so it can't go wrong again. Mglovesfun (talk) 16:39, 1 July 2011 (UTC)[reply]

New-look layout?

In the midst of a session (10:50ish BST) the screen layout changed in Firefox (but not Chrome) - looking at mo I have an clickable list of languages in boxes down the LHS and only the clicked language is displayed - I'm not aware of doing anything to make this happen - and it's there before I log on. Looked at Announcements - Community portal etc

I think I like it - but can someone explain ? —Saltmarsh^{talk-συζήτηση} 10:09, 30 June 2011 (UTC)[reply]

Sounds like you enabled tabbed languages, either through WT:PREFS or the gadget or the button in the beer parlour or here or through my userpage. (I didn't accidentally enable it for everyone or something, did I?) --Yair rand 10:14, 30 June 2011 (UTC)[reply]

I now feel rather stupid - I'd copied textbox/button wayback in April as a "sample" - and promptly forgotten that it actually did something! Sorry to have bothered you! —Saltmarsh^{talk-συζήτηση} 10:21, 30 June 2011 (UTC)[reply]

Bad category name generated by template obsolete

Applying {{obsolete}} to clepest generates membership in Category:English terms with obsolete senses. It is the form not any particular sense that is obsolete, though clepe may be entirely obsolete, suggesting the need for yet another category name. These needs to be corrected promptly or the category hidden until it is. DCDuring TALK 19:08, 30 June 2011 (UTC)[reply]

I disagree. In my point of view, "Category:English terms with obsolete senses" does not suggest the existence of nonobsolete senses. Therefore, I think that that category should contain terms that are entirely obsolete, among other levels of obsoleteness. --Daniel 10:10, 1 July 2011 (UTC)[reply]

It's not a bug, it was an intentional edit by Daniel, I suspect it's in response to the RFM debate that you (DCDuring) started on Category:English rare terms. Mglovesfun (talk) 11:10, 1 July 2011 (UTC)[reply]

I am aware of why the context tag generates the name. It has to do with an attempt to overgeneralize some scheme of template operation. (See tail wagging the dog.) I didn't ask that such specific context template design choice be made. It seems to me that the current name generated fits the most common use case of the context tag. As Ruakh had pointed out in the earlier discussion, the "rare" category name does not well fit an ordinary human's understanding of the words in the cases where the term has no non-rare senses. This is an example of another class of cases where an ordinary human's understanding of the category name does not fit. I understand that those who think in mathematical/logical/database/programming terms are not bothered by this. Those manners of thinking characterize a generous portion of contributors here, not of internet and Wiktionary users at large. That is why we cannot rely on ourselves, even in the aggregate, as model users. If we are the only users to be considered, then the category name should be hidden.

Alternatively, we might need some kind of switch in the context tag to alter the name or to eliminate the context tag for inflected forms in favor of something like {{obsolete form of}}. I haven't thought through the consequences - not that such lack of thought necessarily prevents notions from being proposed, voted on, passed, and implemented. DCDuring TALK 12:13, 1 July 2011 (UTC)[reply]

Maybe the obsolete tag could be moved to the headword line if it applies to the term itself, and kept in contexts if only one sense is obsolete? —CodeCa t 12:31, 1 July 2011 (UTC)[reply]

But that couldn't change its categorization behavior, could it? DCDuring TALK 12:37, 1 July 2011 (UTC)[reply]

It could if we introduce a new kind of template to be used for headword lines, similar to {{context}} but appearing differently and also putting words in different categories. —CodeCa t 12:41, 1 July 2011 (UTC)[reply]

Here are a few possibilities to be considered:

Having two categories: "Category:English obsolete terms" and "Category:English terms with obsolete senses".
Having only one, comprehensive, category with a longer title for all levels of obsoleteness: "Category:English obsolete terms or with obsolete senses"
Having only one, comprehensive, category with a shorter title, for all levels of obsoleteness: "Category:English terms with obsolete senses"

I assure all of them are possible to be implemented relatively easily. Currently, the third possibility is in practice. --Daniel 14:46, 1 July 2011 (UTC)[reply]

Of those options I favor the first. The "terms with X senses" category would clearly be populated based on the presence of a single "X" tag in the relevant L2 section. Ruakh had suggested that a bot could populate the "X terms" category, which I assume would mean using Autoformat-like logic to insert a hard category.

I don't believe the category names are appropriate for inflected forms. Inflected forms don't have senses of their own; they inherit the senses from the lemma. Whatever sense they have, they are almost always "rare", "obsolete", "archaic", or whatever on their own. Thus it is the form of the term that is obsolete not the term itself.

Furthermore, we have many cases where there are multiple PoS sections (and even multiple Etymology sections, which probably can be ignored) with a few possible combinations of PoS-level and sense-level "rarity", "obsolescence", etc. This is an intrinsic feature of our page structure. We have overcome the difficulty with respect to L2 sections, but analogous solutions for PoS (Ety-PoS, actually) would require a lot of effort. DCDuring TALK 16:14, 1 July 2011 (UTC)[reply]

The second of those three possibilities seems more accurate than the third (and not less than the first) and easier to maintain than the first (and not harder than the third), so the best. However, it should be not "English obsolete terms or with obsolete senses" but something more grammatically correct: either "English terms obsolete or with obsolete senses" (my choice) or "English obsolete terms and terms with obsolete senses" or "English terms that are obsolete or have obsolete senses" or cetera.—msh210℠ (talk) 16:32, 1 July 2011 (UTC)[reply]

With regards to using {{obsolete}} for obsolete forms of words that do not necessarily have any obsolete senses, we now have {{obsolete spelling of}}, which populates Category:English obsolete spellings. That seems the exact analogy to the treatment I seek for obsolete forms of lemmas. I suppose that means that I would like {{obsolete}} to be a clean up target to be replaced by {{obsolete spelling of}} or {{obsolete form of}}. DCDuring TALK 21:16, 1 July 2011 (UTC)[reply]

Note: {{obsolete spelling of}} populates Category:English obsolete forms, per a decision to delete certain categories of spellings. Category:English obsolete spellings is not populated by any template, and should be deleted eventually. --Daniel 23:16, 1 July 2011 (UTC)[reply]

The option 2 surely is easier to maintain, and leaves all terms with a level of obsolescence together, so I'm with msh210: I choose the option 2. More specifically, I vote for "English terms obsolete or with obsolete senses", too.

DCDuring, I fail to see the benefit of separating categories as described in the option 1. It adds a layer of complexity and a second place to look for obsolete things to say. --Daniel 00:46, 2 July 2011 (UTC)[reply]

Autoformat: return to entropy

I again (See #Autoformat above.) haven't seen any evidence of the Autoformat function being performed for the ten days at least. Do we no longer need such automated problem identification? Do we no longer have duplicates and other problems in translation tables? Headers are always in appropriate structural arrangement? etc? As crowds diminish, do we want to rely more on crowdsourcing for this function? DCDuring TALK 21:05, 30 June 2011 (UTC)[reply]

I'm sure not, but PrinceKassad runs the bot now and they've been having some problems lately I think. —CodeCa t 21:14, 30 June 2011 (UTC)[reply]

We just need someone to run the script. And let's be patient with those who run it. Mglovesfun (talk) 11:10, 1 July 2011 (UTC)[reply]

Oh yeah, it kinda died because of unified login issues (since I no longer have a global account)... should be fixed for now. -- Prince Kassad 13:45, 2 July 2011 (UTC)[reply]