Wiktionary:Grease pit/2012/July

Am I correct in assuming that this template does absolutely nothing? It looks like Tooironic (talk • contribs) ran into some problems while modifying it, disabled it temporarily, then forgot about it.

It seems to be transcluded all over the place, but I'm not sure what should be done with it. Should I RFDO it, or is it something worth fixing? Or something too tied up in knots to mess with? Chuck Entz (talk) 02:39, 1 July 2012 (UTC)

Why can't you use {{attention|zh}}? -- Liliana • 03:53, 1 July 2012 (UTC)

If I have something that needs attention, I do. I was going to nominate this template for deletion on RFDO as unnecessary, but the number of transclusions led me to wonder if I was missing something. Chuck Entz (talk) 04:44, 1 July 2012 (UTC)

Since {{zh}} shows Mandarin, not Chinese, only {{zh-attention}} categorizes in ]. Or it used to, as pointed out, Tooironic has disabled it. Mglovesfun (talk) 10:28, 1 July 2012 (UTC)

We could always split ] by language! That's what we do with other languages! We don't have ]! Mglovesfun (talk) 10:32, 1 July 2012 (UTC)

But what if one of the translingual sections about a character needs attention? I admit that 'zh' isn't a good name for it still, but even so it would be a good thing to be able to ask for attention on something that applies across all Chinese languages (and beyond). —CodeCat 11:28, 1 July 2012 (UTC)

{{attention|zhx-zho}} -- Liliana • 19:17, 1 July 2012 (UTC)

See WT:RFDO#Template:zhx-zho... —CodeCat 19:50, 1 July 2012 (UTC)

According to the Wiki Appendix page - Portuguese pronouns, Wiktionary voce page and common understanding, the portuguese word você (translated - you) is the 2nd person.

However, on all of the portuguese verb conjugation tables, você is missing from the 2nd person column header and is instead included in the 3rd person column header for both singular and plural. This appears to be the case in the Regular verbs groups: -ar (falar), -er (comer), -ir (dormir) as well as the Irregular verb groups: -ar (murar), -er (fazer), -ir (ir). This leads me to conclude the template is incorrect.

Please correct the template. (I know not how.) Thank you. David 19:18, 1 July 2012 (UTC)

• "Você" and vocês, although being 2nd person, should always take 3rd-person verbs. (apparently) SemperBlotto (talk) 19:25, 1 July 2012 (UTC)

This is a bit of an odd issue I agree, and Portuguese isn't the only language to be faced with this. French, Spanish, Dutch and German have a similar dilemma. The situation is basically this: semantically (in meaning), the word is second-person singular. But grammatically it is (in Portuguese, Spanish and partially in Dutch) third-person singular, (in French) second-person plural, or (in German) third-person plural. So it means that a word that is second-person singular 'in our heads' actually behaves as something else when we use it to form sentences. I don't think there is really an error in the template as such, it just doesn't mention this fact for the sake of simplicity. —CodeCat 19:30, 1 July 2012 (UTC)

• That’s right. The same thing happens with a gente, which functions as a first person plural pronoun but takes third person singular conjugation. — Ungoliant ^(Falai) 19:34, 1 July 2012 (UTC)

Same thing with French on when it means "we". It takes a third-singular verb, though a predicate adjective can be inflected to agree with the logical subject. Thus two or more women saying "We've arrived" can say On est arrivées with the verb in the 3rd person singular but the adjective in the plural feminine because on is semantically referring to two or more women. —Angr 19:42, 1 July 2012 (UTC)

Note that {{pt-conj}} has other errors. It doesn’t distinguish between long and short past participles, and it includes the first person singular imperative, which doesn’t exist in Portuguese. {{pt-verb}} displays the gerund as “present participle” (which also doesn’t exist in Portuguese). — Ungoliant ^(Falai) 19:52, 1 July 2012 (UTC)

I'm not quite sure what the difference would be between a gerund and a present participle. But from my experience with Catalan, what is traditionally called the gerund corresponds to what is called the present participle in Germanic languages. So is there an argument aside from tradition why it should be called a 'gerund' (a rather ambiguous term) and not a 'present participle' (much less ambiguous)? —CodeCat 19:57, 1 July 2012 (UTC)

Portuguese gerund ends in -ando, -endo, -indo and (rare) -ondo, while the “present participle” ends in -ante, -ente, -inte and (rare) -unte. The present participle can be used as a noun and adjective; for example: “transeunte” can mean the noun passer-by or as an adjective meaning “who is passing by”, but in all cases they are considered a noun and an adjective, rather than an actual present participle verb form. The gerund can be used as an adverb and as a verb form: “João está cantando” (John is singing), “João trabalha cantando” (John works singing), and it’s considered a verb form. The nomenclature may not be the same as other languages, but they are certainly distinct in Portuguese. — Ungoliant ^(Falai) 20:59, 1 July 2012 (UTC)

Ok, I understand. It seems that those two forms have simply fallen together in Catalan so they can't be distinguished in form. But why can a present participle not be an adjective? In Germanic languages it certainly is, and I believe it was in Latin as well. —CodeCat 21:22, 1 July 2012 (UTC)

You mean the gerund? It can also be an adjective, I forgot to say that. — Ungoliant ^(Falai) 21:56, 1 July 2012 (UTC)

No I mean the present participle, you said in all cases they are considered a noun and an adjective, rather than an actual present participle verb form. It sounded to me like you implied a present participle can't be an adjective. —CodeCat 23:13, 1 July 2012 (UTC)

That sentence is about present participles. It's saying that "present participles" in Portuguese (as in Spanish and apparently Catalan) are nouns and adjectives, rather than actual verb forms — by contrast with "gerunds", which are verb forms. —Ruakh_TALK 00:59, 2 July 2012 (UTC)

Then I am confused. Aren't participles verb forms by definition? —CodeCat 01:23, 2 July 2012 (UTC)

Perhaps what's meant is that the morphological structure that historically was a participle has ceased to act as one in the modern language- it's a participle in form (and name?) only. Chuck Entz (talk) 01:36, 2 July 2012 (UTC)

These terms are always language-specific. "Present participles" in Spanish descend from Latin present active participles, and they're still verb-derived adjectives and nouns (like participial adjectives in English); so we give them a bit of a pass on the actually-being-verb-forms thing. (But even so, when Spanish speakers speak of the participio, they almost always mean the past/passive participle, which is still a verb form; participio presente is a bit of a learned term. Judging from Ungoliant's comments, the terminology for Portuguese seems to be the same in that respect.) —Ruakh_TALK 01:50, 2 July 2012 (UTC)

That’s right! Only fringe grammarians consider words ending in -nte to be present participle. Back to the point: {{pt-verb}} calls the Portuguese gerund “present participle”, perhaps because in Brazil it is used as an equivalent to the English present participle (e.g.: “Estou falando”: “I am speaking”). In Portugal they use a + infinitive (“Estou a falar”). — Ungoliant ^(Falai) 02:16, 2 July 2012 (UTC)

• I certainly agree the verb table is confusing. From my perspective there is a distinction between the words I (eu or ich), you (tu & voce or du) and he/she (ele/ela or er/sie) and the form of the verb they use. On the pronoun side of language, first comes I, 2nd person is me addressing 'you' and 3rd is I or you including 'he or she'. What form of the verb that attaches to this seems less important than 'you' being second person. I learned that in German and think the first 2 bullets under Portuguese > voce > Usage notes sum up the situation. Voce has replaced tu. My point is that the conjugation tables delineate tu as second person, but relegate voce to 3rd person. Maybe we are pointing to a 4th column in the singular and plural groups, or 2 columns (tu & voce) beneath 2nd person. Yes, voce uses the same form of the verb as the 3rd person, however, voce is still 2nd person.... What do you think? David 20:01 1 July 2012 (UTC)

Well, I suppose that there is some merit in that, the terms '2nd person' and '3rd person' are probably being used to refer to their original meanings (in older forms of Portuguese). On the other hand, I know that Portuguese doesn't require you to use a pronoun... so if you use just the voce form of a verb but without the word 'voce', would it be assumed to be 2nd person or 3rd person? —CodeCat 20:09, 1 July 2012 (UTC)

Você didn’t replace tu. Tu is still used in Portugal and parts of Brazil. — Ungoliant ^(Falai) 20:59, 1 July 2012 (UTC)

@CodeCat You are correct about the omission of voce. The pronoun is often omitted. @Ungoliant. You are also correct. My mis-speaking. Tu has only been replaced in some locations. — This unsigned comment was added by 184.91.84.172 (talk). 00:47, 2 July 2012 (UTC)

I've read through this discussion, and I don't think this has been suggested already, but apologise if it has: simply strip the "first person", "second person", "third person" labels out of the table. Have the table indicate which forms are used with which pronoun (whether that pronoun is explicit, or omitted-but-implied), and the issue of which pronoun is which "person" is bypassed. I would copy the template to the sandbox and edit it to demonstrate, but the template is too complex. - -sche (discuss) 01:01, 2 July 2012 (UTC)

The verb-conjugation tables are about verbs, not pronouns. The pronouns supplied at the tops of the columns are only there as headers. Você could and should be included, but in the 3rd-person column just as we do with the Spanish verbs (usted in the 3rd-person column of hablar). That does not mean that você is a 3rd-person pronoun, because the table is not about pronouns. Besides ele/ela/você, you could also put Paulo, Maria, o governo, and many other words, but the basic pronouns that govern the 3rd-person are sufficient to use as a representative header for the column. If this were a pronoun-inflection table (such as the one at the bottom of você), then você would be placed in the 2nd-person column along with tu...but it’s not, it’s a table about verbs, not pronouns. —Stephen ^(Talk) 01:49, 2 July 2012 (UTC)

The question though is why the form that is listed as 3rd person is in fact 3rd person, when it can also be second person? —CodeCat 11:09, 2 July 2012 (UTC)

In English, would you say that "is" is not just third-person but also first-person ("the author is" = "I am") and second-person ("the reader is" = "you are"; "your Honor is" = "you are")? It's not always obvious what the technically best analysis is, and anyway I think it's more productive to focus on the question of what our readers will understand. —Ruakh_TALK 18:42, 2 July 2012 (UTC)

The form você is not listed as third person or any person. It is a representative subject pronoun that governs the third person of the verb. It is associated with the third person of the verb. That’s what I meant when I said the table is not about pronouns, it’s about verbs. The third-person of the verb is governed by the pronouns ele, ela, você, o senhor, a senhora, as well as by singular nouns and proper nouns, and by noun phrases and some types of clauses. It does not mean that all of those subjects are themselves third persons...some of them are technically second persons, but since this table is not about the subject pronouns and subject nouns, that technicality is not addressed in this table. The pronouns and their persons are dealt with in a separate table which is about the pronouns. —Stephen ^(Talk) 00:54, 3 July 2012 (UTC)

Ok but then I wonder... if we consider the verbs by themselves, what makes us say that a certain form of the verb is third person? In Portuguese, pronouns can be left out, so could a "third-person" form such as fala actually be second person even without any pronoun? Or to make it more explicit: Does fala português? always mean 'does he/she/it speak portuguese?' or can it also mean 'do you speak portuguese?'; and if so, what criteria are there for labelling fala as third person despite this? —CodeCat 10:28, 3 July 2012 (UTC)

I don't know the answer to that question, but I do know that dropping the subject pronoun is much less common in Portuguese (at least, Brazilian Portuguese) than it is in, say, Spanish, so you're not nearly as likely to encounter Fala português? as you are to encounter ¿Habla español?. And I'm pretty sure that Spanish sentence, despite being technically a 3rd person form, will be interpreted as 2nd person in the right context, just as Sprechen Sie Deutsch? when spoken out loud (since you can't hear capitalization) will be interpreted as 2nd person rather than 3rd plural in the right context. —Angr 10:44, 3 July 2012 (UTC)

What about a footnote? — Ungoliant ^(Falai) 17:38, 2 July 2012 (UTC)

] contains the pointer {{also|敪}}, but until just a moment ago, ] did not point back to {{also|敠}}. Is it desirable for every page which is given as an {{also}} in another page to use {{also}} to link back to the first page? Is it feasible to have a bot add such links? I presume that it is both: that it is feasible, and that it is either desirable for every page to link symmetrically, or that it is at least desirable in most cases and not undesirable in any. 01:32, 2 July 2012 (UTC)

I think there are many cases in which there is no need for it and the links should therefore not be added. The purpose of {{also}} is to allow users who came to the wrong page accidentally, due to mistyping, to find the correct page easily. Thus, the page ] should link to ]: people will type the former intending the latter. However, people will not type the latter intending the former, so there's no need for {{also}} at ]. (Even if you disagree with my assertion of what people will type as an error for what, and therefore think {{also}} is necessary at ], my principle is, I think, sound, that {{also}} is for things people will mistype, which is not symmetric.)​—msh210℠ (talk) 17:24, 2 July 2012 (UTC)

I always felt {{also}} was to link entries which would be adjacent if diacritics were disregarded (as in many languages' paper dictionaries) and to link gylphs that were visually identical or similar (so that someone searching their Character Map for a ]-like character and finding an inputting ] would still reach ], or ]-]). If we set aside the first kind of {{also}} (word-to-word), is it desirable for all gylphs (one-character entries like ], ], ], ], ], ], including single characters which are words, like ], ]) to link symmetrically? - -sche (discuss) 18:29, 2 July 2012 (UTC)

I agree (though not with "to link entries which would be adjacent if diacritics were disregarded" is meant to include things like ]↔]. Note that there is a preference for having such links script-added, and there was talk of turning it on by default).​—msh210℠ (talk) 17:12, 3 July 2012 (UTC)

¶ Hullo. May I propose that a Template, mayhap Template:irregular_plural_of, auto‐categorises for other Languages besides English ? Thanks. --Æ&Œ (talk) 11:58, 2 July 2012 (UTC)

I don't disagree, but before it's added it may be a good idea to check if any other languages are affected by this, and to make sure we want the new category for those other languages too. —CodeCat 12:01, 2 July 2012 (UTC)

¶ French definitely possesses irregular plurals, so if nothing else we need auto‐categorisation for that. I do not know what you mean by ‘check if any other languages are affected by this’. --Æ&Œ (talk) 19:54, 11 July 2012 (UTC)

Could someone less intimidated by esoteric template syntax than I am please edit Template:singulative of so that it the |lang=xx parameter not only correctly categorizes the term but also correct links to the language's subsection? For example, at ], using |lang=cy correctly puts the term into Category:Welsh singulatives, but it still links to the top of ] rather than to ]. Thanks! —Angr 15:54, 3 July 2012 (UTC)

I've fixed the template by completely rewriting it. It now passes on the call to {{form of}} which is a generic template for all form definitions. —CodeCat 16:51, 3 July 2012 (UTC)

I've reverted that, sorry. {{form of}}'s handling of periods got broken a while back (intentionally, but wrongly); that's very difficult to fix, but there's no reason to infect other templates with the problem. —Ruakh_TALK 17:02, 3 July 2012 (UTC)

Wasn't there an agreement some time ago that final periods were being dropped from form-of templates? From what I can see, the template doesn't actually 'handle' periods at all, it just doesn't display one. —CodeCat 17:18, 3 July 2012 (UTC)

It used to optionally display one, and it's still documented as doing so, but now it doesn't handle that anymore. There was discussion about it, yes, and there may even have been a decision to provide the period in entries rather than in the templates (TBH, I'm not sure that such a decision was actually reached, but obviously Mglovesfun thought it was, so O.K.). However, no such decision was ever implemented: the "rather than in the templates" part was implemented via a change to {{form of}}, and the "provide the period in entries" part was ignored. This was an error on Mglovesfun's part, and there's no reason to propagate that error to other templates. —Ruakh_TALK 17:32, 3 July 2012 (UTC)

So then all that would have changed with my edits is that the entries in Category:Breton singulatives, Category:Cornish singulatives and Category:Welsh singulatives now have no dot at the end of the definition. And you reverted it just for that? I can think of more important issues, honestly... —CodeCat 19:15, 3 July 2012 (UTC)

I, too, can think of more important issues. Are you saying that I shouldn't have reverted your edit? If not, why not? —Ruakh_TALK 19:20, 3 July 2012 (UTC)

Well, I was trying to fix the issue Angr was having, and as far as I could see, it fixed it in a very neat way by reducing the duplication of code among templates. So yes I think it's a little overboard to revert all of it just for that one small detail, which I think isn't even an issue personally because we have countless definitions without periods at the end and no consensus on whether there should be one or not (meaning either is fine). —CodeCat 19:23, 3 July 2012 (UTC)

Re: first sentence: I don't mean to criticize — I think that, if not for this problem, using {{form of}} would have been fine — but all else being equal, I think {{deftempboiler}} makes more sense. (It's what e.g. {{alternative form of}} uses.)   Re: lack of consensus: I think we actually do have a consensus that form-ofs should start with capital letters and end with periods. At least, until Mglovesfun broke {{form of}}, we were very consistent about that, and even now that's still the case for the vast majority of form-ofs. But if you're right that form-ofs, like other definitions, lack such a consensus, then presumably they have the some consensus as defs, which is that it's not appropriate to go around changing from one format to the other.   I'll also add that it's not necessarily true that you removed periods from the ends of defs. There may be some singulatives that have additional information after the template, in which case you removed punctuation from the middle of defs. —Ruakh_TALK 19:48, 3 July 2012 (UTC)

Ok, I didn't realise there was {{deftempboiler}}. But I'm also a bit confused by it. Is it another Daniel-style complicated trying-to-do-everything template? And as for the dots... well... the way I see it is, it takes more template-code-writing effort to make the dot work in every way we want, while at the same time we could just... press the . button on our keyboard? —CodeCat 20:02, 3 July 2012 (UTC)

Re: {{deftempboiler}}, Daniel, complicated, trying-to-do-everything: Yes, but I think the idea behind this one is actually pretty sensible. (Even a stopped clock . . .) You wouldn't have changed {{singulative of}} to use {{form of}} if you hadn't felt that it made sense to have a generic form-of template that others can farm the work out to.   Re: dots: I don't strongly disagree (though personally I'm punctilious enough to prefer approaches whereby the dot is inside the appropriate <span>; see e.g. {{he-form of noun}}), but the point is that you didn't press the . button on your keyboard. It's all well and good to say that you could add . to all of those entries, but am I right that you didn't intend to actually do so? —Ruakh_TALK 21:55, 3 July 2012 (UTC)

No I didn't because I didn't think it mattered that much to have it or not. But I prefer to be principled about this kind of thing: first find out what is the best way, then work out what needs to be done to change it into that without letting the difficulty of a possible conversion get in the way of the decision. So more along the lines of 'how should it be' rather than 'what's easiest to do given the existing sitation?' So, does it make more sense to add nodot=1 when you don't want a dot, or does it make more sense to type the dot when you do want it? Personally I think having no dot built into the template is a better approach, and as there didn't seem to be a clear preference for form-of templates (there are quite a few without a dot) I went with what made the most sense to me. And yes, I do think a common template that other templates can use is a good idea, but what is the biggest difference between {{form of}} and {{deftempboiler}}? Could the latter be too complex for what it tries to do (especially as the much simpler {{form of}} does fine, too)? —CodeCat 01:08, 4 July 2012 (UTC)

At any rate, the changes didn't work because the definition line at ] still links to the top of ] rather than to ]. —Angr 21:05, 3 July 2012 (UTC)

The changes did work, but were reverted. (By me.) See above. —Ruakh_TALK 21:55, 3 July 2012 (UTC)

O.K., now it's working again. See e.g. ]. Unfortunately, it's more opaque now than it was before, so hopefully this is the most complicated feature you expect you'll ever need. :-/   —Ruakh_TALK 22:19, 3 July 2012 (UTC)

Thanks for your help. For what it's worth, I've never understood why people feel the need to start definition lines with capital letters and end them with periods when they aren't sentences. —Angr 07:44, 4 July 2012 (UTC)

I imagine it's simple for a bot to add a dot after any form-of template that's missing one. (Am I wrong? Is it somehow difficult to distinguish bare "{{form of|...}}" from "{{form of|...}}" followed by anything, and add dots only to the latter?) Thus, I agree with CodeCat that clearer templates are preferable to more opaque, Danieline ones. I also agree that given how nonstandard our non- form-of entries are, the presence or absence of the dot in a few form-of entries incredibly minor. - -sche (discuss) 01:21, 4 July 2012 (UTC)

Re: "Thus, I agree with CodeCat that clearer templates are preferable to more opaque, Danieline ones": FWIW, I imagine that everyone agrees on that point — including Daniel, who presumably doesn't intend for his templates to be opaque. (Alternatively, it's possible that he thinks his templates are so perfect that it doesn't matter how opaque they are, because they will always do exactly what everyone needs and will never need to be edited. But I doubt he's quite reached that extreme: I'm sure that, ceteris paribus, he'd agree that clarity is preferable to opacity.) But keep in mind that there's no non-opaque option on the table: CodeCat is advocating the opaque use of {{form of}}, and I'm advocating the opaque use of {{deftempboiler}}. ({{form of}} itself is less opaque than {{deftempboiler}}, but that doesn't make much difference to someone editing {{singulative of}}.) —Ruakh_TALK 02:13, 4 July 2012 (UTC)

Both templates have standard parameters like lang=, sc= as well as the convention that in links, the parameter after the entry name is the word to be displayed. (Wouldn't it be desirable to have a page that describes those conventions so that people wanting to write/understand templates have a base to start from?) But one reason why {{form of}} may be easier is that it can be and is used in mainspace, so editors are more likely to be already familiar with how it works (which makes me wonder why {{deftempboiler}} says it can't be used in mainspace?). In any case I am going to propose merging these two templates: WT:RFM#Template:deftempboiler into Template:form of. —CodeCat 11:30, 4 July 2012 (UTC)

Just to butt in with an anecdote (because it's one person, me): I pretty much stopped using {{form of}} when changes were made to it (last May), or thereabouts, because the changes were not noted in the documentation and I figured they'd be reverted (since they were so drastic), so I didn't know whether to include a period at the end or not (or how to do so). (I use either {{n-g}} or some other template.) If the template is in fact stable (as it seems to be), then Martin, who made those changes, should document them in the documentation and should check every entry that uses {{form of}} to make sure it has appropriate punctuation. The current state of that template is terrible: changes that affect entries were made, the entries weren't fixed, and documentation wasn't updated.​—msh210℠ (talk) 16:51, 4 July 2012 (UTC)

Would it be possible for someone to generate a random or pseudo-random sample of English entries? I haven't seen mention of this having been done before. A sample of 1000 should be sufficient. I would suggest that the sample be placed in Wiktionary space.

My own intended use is to make a comparison of coverage among MW2, MW3, MEOnline and en.wikt. For this purpose it is probably not worthwhile to be too careful about the highly polysemous entries, which are underrepresented by most simple sampling methods, as they are a very small fraction of the total and are likely covered well by all dictionaries. It might be nice to do this periodically, say, once a year, but that would depend on the value of the uses contributors made of it. DCDuring TALK 13:49, 4 July 2012 (UTC)

For purposes of this sample, does "English entry" mean "==English== L2 section"? That is — even if it's split by etymology, it only counts as one entry, and even if it only has form-of definitions, it still counts as an entry? —Ruakh_TALK 14:27, 4 July 2012 (UTC)

True, you already have the logic for identifying more-or-less lemma entries, don't you. (Your upper and lower limits were quite close, as I recall.) But a simple any-English-L2-section sample has some use for estimating the composition of English at en.wikt (and making comparisons over time if we do it the same way every time). It would also address some questions about how our form-of entries compare to the equivalent in other dictionaries. And it is about equivalent to the lemma approach for the vast majority of entries. I could operate with either kind of sample if one required significant new work. If the hard part is just getting your mind around it, then, by all means, please do both so I don't have to ask again.

Are there other ways of getting some statistics about entries in English (or any other language)? Do we still have runs that do counts of Headers? Are they done by language? Can we rely on template-use counts for anything at the language level? That is, do we have counts of uses of various templates by the lang parameter specified? Do we have mechanisms to make sure that the lang parameter for any template needing one matches the L2 header?

It would be nice to hear whether others could make use of such samples and statistics and for what purposes so we had some idea of what was most useful. DCDuring TALK 16:42, 4 July 2012 (UTC)

Re: "True, you already have the logic for identifying more-or-less lemma entries, don't you": I actually didn't hold on to that code, because there were too many things about it I didn't like. But since you don't seem to feel strongly one way or the other, I've gone ahead and created a random sample of 1000 entries that contain a line matching ^== *English *== *$ . . . the problem is, it's huge. If I include the entirety of what the XML dump has to say about a page, it comes out to about a megabyte. If I only include the text of the English entry itself, it comes out to about the current size of the Grease pit, which is to say, somewhat under half a megabyte. Should I zip it up (160 KB or so) and e-mail it to you? Or should I just post a list of 1000 links to the randomly-selected English entries? Or . . . ? —Ruakh_TALK 17:52, 4 July 2012 (UTC)

All I really need is the list of headwords and the knowledge of how the sample was generated. The links are fine. The first analysis is just a comparison of inclusion in other dictionaries. I can use our actual entries for any further (manual) exploratory analysis that is warranted. Once I get to having more hypotheses that matter, there might be reason for other specific information, but never whole L2 sections. DCDuring TALK 18:06, 4 July 2012 (UTC)

See User:DCDuring/1000EnglishEntries. Feel free to move it into the project namespace. —Ruakh_TALK 19:08, 4 July 2012 (UTC)

When I move a page, although the "Reason" box is enabled, I cannot type anything in it; keystrokes are ignored. This is in Opera 12.00. I had no problems in previous versions and I'm not sure that an Opera upgrade caused it; maybe it was a Wikimedia change at some point. Does anyone else have this problem? Is there a known fix? Equinox ◑ 21:41, 4 July 2012 (UTC)

I have this problem as well with Opera. Disabling Javascript seems to make the reason box typable again. -- Liliana • 21:45, 4 July 2012 (UTC)

I too have this problem in Opera, so... yeah, seems to be Opera. - -sche (discuss) 22:00, 4 July 2012 (UTC)

I am perpetually reporting bugs in Opera (mostly little stupid things like misuse of ellipsis in the user interface), but this one is difficult because you have to be on Wiktionary with admin rights. Can anyone check if it happens on Wikipedia too? Is there some common JavaScript that's doing odd things with the DOM or what not? (P.S. The really annoying one in Opera is that if you fill the edit summary textbox completely, by pasting, you then can't tab out of it!) Equinox ◑ 22:04, 4 July 2012 (UTC)

You don't have to have admin rights to move, do you? Just an account (and maybe auto-confirmed status). I just moved a page on Wikipedia, but couldn't type a move summary, so it happens there, too. - -sche (discuss) 23:47, 4 July 2012 (UTC)

Quite right. According to Special:ListGroupRights, everyone has the move right as long as they're in the "Autoconfirmed users", "Confirmed users", or "Administrators" group. I'm sure there are people at Opera who have autoconfirmed accounts on en.wiki. —Ruakh_TALK 00:22, 5 July 2012 (UTC)

It doesn't happen for me in Firefox 13.0.1. —CodeCat 22:05, 4 July 2012 (UTC)

Hi everyone, I don't know if you have already noticed that a SQL error appears when trying to access the Main Page's talk page. This appears on every wiki. --82.120.45.5 13:25, 5 July 2012 (UTC)

I see no such error. Wiktionary talk:Main Page works just fine for me. (That's where you get when you visit http://en.wiktionary.org/ and click on "Discussion".) Maybe you're using the wrong URL? —Ruakh_TALK 13:35, 5 July 2012 (UTC)

(after edit conflict) I went and tried it, getting the SQL error, then went back with no problem a few minutes later. It may have been fixed. A few minutes before, I got an SQL error (I don't remember exactly the circumstances, but I think it something to do with an unpatrolled edit being patrolled by someone else while I was looking at it. This also didn't reappear the second time. I'm sure it was a temporary glitch, but I had never gotten an SQL error on a Wikimedia site before. Chuck Entz (talk) 13:47, 5 July 2012 (UTC)

I've had a few SQL errors, but not lately. Are they worth reporting? Is it the duty of every committed Wiktionarian to report them? DCDuring TALK 14:20, 5 July 2012 (UTC)

This is very strange. I'm not getting SQL errors because I can't even get to the talk page. None of the tabs on the main page are clickable for me (not even "delete"). Any ideas? SemperBlotto (talk) 14:26, 5 July 2012 (UTC)

I'm still not seeing what I would describe as "SQL errors". I've seen errors where the application server can't connect to the database server, but presumably that's just a load issue; I'm confident that the devs have monitors in place to detect those problems, and I'm guessing that about the only way we can help is to make donations (so that more infrastructure can be purchased). If you're seeing actual SQL errors, please post more information. Are they also attributable to load issues? Or do they represent bugs in SQL queries in newly-deployed code? —Ruakh_TALK 14:29, 5 July 2012 (UTC)

My guess as to what happened is that something went wrong on the back end (perhaps someone trying something new?) that caused SQL errors under certain circumstances, so they brought servers down to fix it, and now everything is fine. Chuck Entz (talk) 14:35, 5 July 2012 (UTC)

I got the error (see User_talk:Equinox) and it stopped me viewing large pages (like Grease Pit) but not small ones; it also stopped me viewing page histories. I think it's gone now. Equinox ◑ 19:52, 5 July 2012 (UTC)

When I place a template in an entry as ‘{{en-noun|pl2=anæmiæ|-}}’, it insists that it is uncountable, but it should really just say that it is countable & uncountable and list the alternative plural along with the traditional plural. See also : this edit. --Æ&Œ (talk) 17:30, 5 July 2012 (UTC)

I think the current behavior is fine. —Ruakh_TALK 17:51, 5 July 2012 (UTC)

This looks like a matter for Template talk:en-noun. In the meantime, adding "pl=anaemias" or whatever should give the right result. DCDuring TALK 17:54, 5 July 2012 (UTC)

I tend to agree with Ruakh; use {{en-noun|s|-|pl2=anæmiæ}} and it should work. Mglovesfun (talk) 20:04, 5 July 2012 (UTC)

I'm seeing a problem with citations; everything is formatted ok apart from the numbering which reads 1. 2. 1. 1. instead of 1. 2. with citations not numbered. Mglovesfun (talk) 18:10, 5 July 2012 (UTC)

Could be a {{defdate}} problem: when I remove them, the output looks fine, at least in the preview. --MaEr (talk) 18:48, 5 July 2012 (UTC)

I'll bet there's an extra linebreak, I have an idea who's added it too, but I'll say nothing. Mglovesfun (talk) 18:55, 5 July 2012 (UTC)

Thanks for correcting my mistake. DCDuring TALK 20:00, 5 July 2012 (UTC)

This discussion of {{artfl}} gives me an idea. I think it's clever to have a template to help editors on preview (a template designed to be removed again before the page is saved). Could we set up a template that listed all our or other {{context}} templates? We could sort them into collapsible lists like "grammar and linguistics" and "animals and animal sciences", so a user editing ] could transclude the template, preview, and click "animals and animal sciences" to look through those templates (({{ornithology}}, {{biology}}, etc) and refresh themselves about whether the template for "(ornithology)" was {{birds}} or {{ornithology}}? The guide-template could even add entries to a cleanup category, so we could detect accidental uses of the template. That would help users see if there was a context template they could include, and what it was named. - -sche (discuss) 22:23, 5 July 2012 (UTC)

The idea of using it for wiki-specific context seems promising. Its featured content was a set of links to reference sites like "artfl", whence the name. This approach seems simpler and certainly more dynamically flexible than personalizing what shows up under the edit window. Less experienced users would benefit from the selection of items that more experienced editors had placed in the template scheme for display. But would it be better to fold it into the edit window capability? DCDuring TALK 22:57, 5 July 2012 (UTC)

The argument for a template is it can be used selectively (only by editors who need it, only on words they need it on), whereas edittools are automatically loaded for everyone who edits any page, and increasing the size of the edittools increases the page size users have to download. A comprehensive list of context templates would probably double the size of edittools. We could, however, link to the guide-template from edittools. - -sche (discuss) 00:01, 6 July 2012 (UTC)

I still haven't a clue what it is. So... what is it? Mglovesfun (talk) 18:42, 6 July 2012 (UTC)

Here's a very incomplete mock-up: User:-sche/template. - -sche (discuss) 19:50, 6 July 2012 (UTC)

Would it be worth adding something along these lines to MediaWiki:editnotice-0 (which shows up above the edit-window when editing a mainspace page)? See asefasefasef?action=edit for one possibility. —Ruakh_TALK 20:57, 6 July 2012 (UTC)

I just hope the real thing is a bit more selective. I didn't actually see the kitchen sink, but I get the uncomfortable feeling that it's in there... somewhere. Chuck Entz (talk) 07:58, 7 July 2012 (UTC)

As of https://gerrit.wikimedia.org/r/14419 project-specific css, js are available on the Mobile view of en.WT. As you may be aware, collapsing templates do not work and look particularly awful on a small mobile device screen.

People familiar with the en.WT custom js will likely wish to modify the js to work via MediaWiki:Mobile.js. MaxSem wanted to make clear to me (and I'm passing on to you) that this js must work without jQuery and mediawiki.util: they are simply not available in the MobileFrontend.

- Amgine/ ^t·e 22:43, 5 July 2012 (UTC)

To elaborate: jQuery will be available to devices that support it, however a lot of phones don't support it and they will be served with the same script. So it is highly preferrable not to use jQuery, and if you have to - first check that it is loaded. MaxSem (talk) 22:48, 5 July 2012 (UTC)

Is the JS run after the DOM is loaded? If not, is addOnloadHook available, or does the code need to be attached to the onload/DOMContentLoaded manually? Also, is the CSS page located at MediaWiki:Mobile.css? --Yair rand (talk) 23:08, 5 July 2012 (UTC)

Yes/yes. It's not deployed yet. MaxSem (talk) 23:22, 5 July 2012 (UTC)

Does this mean that we should also be avoiding jQuery in MediaWiki:Common.js? —Ruakh_TALK 22:35, 8 July 2012 (UTC)

Answering my own question: No, it doesn't mean that. The mobile view includes MediaWiki:Common.css, MediaWiki:Mobile.css, and MediaWiki:Mobile.js, but not MediaWiki:Common.js. As a comment in the new version of MobileFrontend.php explains, "Common.js usually depends on desktop-specific features". —Ruakh_TALK 22:49, 11 July 2012 (UTC)

I'm running Firefox 13 on Windows 7. I have Firefox set to use Segoe UI as my default font, and here on Wiktionary that's mostly the case, but some languages using the Latin alphabet display using Arial instead of Segoe. See the screenshot to the right: for example, Upper Sorbian (hsb) and (Modern) Irish (ga) display in Segoe UI, while Lower Sorbian (dsb) and Old Irish (sga) display in Arial. Why does this happen, and how can it be fixed? It displays the same way regardless of whether I'm logged in or not. I know I can set my CSS settings to force these languages to display in Segoe, but why is the display different in the first place? {{hsb/script}}, {{dsb/script}}, {{ga/script}}, and {{sga/script}} all return "Latn", and I can't find anything at MediaWiki:Common.css that could be causing it. Obviously this isn't a matter of earth-shattering importance, but it is mildly annoying to have to look at ugly Arial when I could be looking at pretty Segoe instead. —Angr 16:05, 6 July 2012 (UTC)

If I use Special:ExpandTemplates I get this, for Old Irish and Irish respectively:

<span class="Latn mention-Latn" lang="sga">]</span>
<span class="Latn mention-Latn" lang="ga">]</span>

So whatever the difference is, it must be in the lang= part. Presumably your browser is doing some things there... —CodeCat 16:19, 6 July 2012 (UTC)

I think it's a Firefox thing. I discovered recently (while investigating the WebFonts stuff) that Firefox doesn't display <span lang="hi" style="font-family:monospace">foo</span> in a monospace font — at Wiktionary or otherwise. I'm guessing your issue is similar. Try creating an HTML file containing this:

<p lang="sga">Old Irish: féil</p>
<p lang="ga">Modern Irish: féil</p>

and opening it in Firefox. What fonts do you see? —Ruakh_TALK 16:45, 6 July 2012 (UTC)

Old Irish is in Arial, Modern Irish is in Segoe, so yeah, it's Firefox rather than something at Wiktionary per se. I just noticed the difference also applies when you use {{term}} without specifying a language: {{term|word}} displays in Arial, while {{term|word|lang=en}} displays in Segoe. Anyway, does this mean it's unfixable (provided I want to keep using Firefox)? —Angr 16:51, 6 July 2012 (UTC)

I have no idea, sorry. —Ruakh_TALK 17:07, 6 July 2012 (UTC)

I went to my Options and set the default font to Segoe for all Latin-alphabet options, not just Western, and that seems to have worked. (Why Irish and Upper Sorbian are Western while Old Irish and Lower Sorbian aren't is anybody's guess.) —Angr 17:37, 6 July 2012 (UTC)

Good to know, thanks. (Presumably Firefox recognizes ga and hsb, but not sga and dsb, so treats the former two as "Western" and the latter two as "Other Languages".) —Ruakh_TALK 17:49, 6 July 2012 (UTC)

The "visibility" control box on the left under search and navigation is displaying "Declension" headers as what looks like raw HTML. I noticed it at ]. DCDuring TALK 17:33, 8 July 2012 (UTC)

It works for me in Firefox 12.0 and IE 9 (both on Windows 7). What exactly is the raw HTML that you're seeing? —Ruakh_TALK 18:43, 8 July 2012 (UTC)

Three instances like (differing only in the section numbering):

Show <span class-"mw-headline-number">11.2.1</span>declension

I use Firefox 13.0.1. DCDuring TALK 18:52, 8 July 2012 (UTC)

The other section #s are 8.2.1 and 9.2.1, which are the only sections that have "Declension" headers. DCDuring TALK 18:57, 8 July 2012 (UTC)

Ah, I see. I take it you've enabled the "Auto-number headings" preference at Special:Preferences#mw-prefsection-rendering? Yes, I can reproduce this issue by enabling that preference. —Ruakh_TALK 19:43, 8 July 2012 (UTC)

Yes, I have. DCDuring TALK 20:07, 8 July 2012 (UTC)

O.K., fixed. Note that, in order to get the updated JavaScript, you may have to visit http://bits.wikimedia.org/en.wiktionary.org/load.php?debug=false&lang=en&modules=site&only=scripts&skin=vector&* (or &skin=monobook&* or whatnot) and hard-refresh (usually shift+F5). Sorry for the delay in fixing this; due to the above discussion about the mobile front-end, I wasn't sure at first if I should use jQuery in the fix. —Ruakh_TALK 00:06, 12 July 2012 (UTC)

If it isn't seen by anons it isn't really highest priority. Thanks for getting to it. DCDuring TALK 00:48, 12 July 2012 (UTC)

Okay I'm posting this here 'cause it's been bugging me. Recently (today too even...), and also sometime in the past, I went and created some missing {{topic cat parents}} subtemplates to enable templatisation of topical categories that were still using raw links to parent categories (at least in the "top level" non language specific ones...most lang prefixed ones tend to be made already using {{topic cat}}, but I digress.)

Now, onto the actual problem. I'll explain with some examples...though I can't say if this is only client side or server side (if those are appropriate terms): I created Template:topic cat parents/Petrochemistry a while ago. Now, look at Category:Petrochemistry. The parent cats are all showing up...everything seems to be fine right? Wrong. Look at one of the parents, say Category:Oil industry for example. Guess what? Petrochemistry isn't showing up as a subcategory there...What I'd like to know is why? O_o

Note also this is not only limited to topic cats it seems...rather anything using many helper templates perhaps. For example, {{xib}} is categorised in Category:Iberian language (another category recently made by me), but it doesn't show up in there. 50 Xylophone Players talk 15:02, 11 July 2012 (UTC)

I'm not sure of all the ins and outs, but in broad strokes, this happens when a page ] uses a nonexistent template {{Y}} inside a {{#ifexist:Template:Y|...}} construction, and then {{Y}} is created. Then ] can end up looking like it's using {{Y}} just fine, but it won't be listed in categories that are added via {{Y}}. This problem, once triggered, seems to last quasi-permanently: it never gets auto-corrected, and resolves itself only when ] is edited.

Any specific instance of the problem, once identified, can be addressed by editing ] — it doesn't even have to be a real edit, it can just be a null edit (visit the edit-page, click "Save page"; it won't shows up in the revision-history, but it will solve this sort of issue) — but the overall problem is thornier, and instances of it seem to be nontrivial to detect. I'm not sure if it's possible to detect them via database-dumps.

—Ruakh_TALK 21:09, 11 July 2012 (UTC)

I see...:/ Well, thanks for replying, at least there's some sort of way to fix it, as you explained. 50 Xylophone Players ^{talk to meh} 01:42, 12 July 2012 (UTC)

I added Yair's boldness-suppression code to my CSS, but it seems to have stopped working: most of my watchlist items are bold again. - -sche (discuss) 22:52, 11 July 2012 (UTC)

Looks like they changed the HTML output. .mw-changeslist-line-watched span.mw-title{font-weight:normal;} should work. --Yair rand (talk) 22:58, 11 July 2012 (UTC)

It does; thank you! :) - -sche (discuss) 23:01, 11 July 2012 (UTC)

Thanks, dude. DCDuring TALK 00:52, 12 July 2012 (UTC)

I have the pre-browser preference "Color links to language sections that don't exist orange where they would otherwise be blue." checked, but {{term}} does not seem to be functioning. I noticed it in the etymology section at ]. See sette and setten, for example. It seems to have happened in the last several hours. I assume this has to do with whatever suite of changes are being implemented at MW. DCDuring TALK 01:35, 12 July 2012 (UTC)

I doubt it ever worked at ], because it's designed to just give up if it finds that it has too many pages to examine. Are you seeing it not-work at a page where it previously did work? —Ruakh_TALK 02:03, 12 July 2012 (UTC)

Actually, the maximum number of links' target pages it can handle is 500 for admins, and set has less than that. I think it might be breaking because of the links to Ste.. Periods in the target page name isn't something it's prepared to deal with. I've made a change which should fix the problem, hopefully without causing additional new problems. --Yair rand (talk) 02:30, 12 July 2012 (UTC)

Thanks yet again. It works the way it's supposed to at ]. Good luck with other entries. DCDuring TALK 04:52, 12 July 2012 (UTC)

What is a "pre-browser preference" and how do I set this function for myself? I can't find it at Special:Preferences. —Angr 06:34, 12 July 2012 (UTC)

The per-browser preferences are at Wiktionary:Per-browser preferences (WT:PREFS). —Ruakh_TALK 12:13, 12 July 2012 (UTC)

The link, labeled "Preferences", also appears on the left-hand-side of every page in the box labeled "navigation" - not that the preferences are limited to navigation, navigation options being only about one quarter of the total options available. I think it would be a bit more intuitive were it in the "toolbox" box. DCDuring TALK 14:11, 12 July 2012 (UTC)

The toolbox seems to be items that are specific or relevant to the particular page (except for the special pages link), but preferences are a very general subject and should go higher up, in a more prominent place. Also, the toolbox section is collapsible (it's not a box on my screen), and people who keep it collapsed may forget where the preferences are. Chuck Entz (talk) 14:27, 12 July 2012 (UTC)

Well, I set it at WT:PREFS and that works, but I don't seem to have a box labeled "navigation" on the left-hand side of my pages. I'm using the Vector skin in Firefox on Windows 7, if that makes a difference. —Angr 18:22, 12 July 2012 (UTC)

When I switch from Monobook to Vector, the box goes away, but "Navigation" remains, though I can scroll away from it (in either skin) on multi-screen pages. DCDuring TALK 18:47, 12 July 2012 (UTC)

Found it! The word "Navigation" doesn't appear on it in Vector for me, but the Preferences link is there. —Angr 19:41, 12 July 2012 (UTC)

(Deletion log); 19:38 . . Mglovesfun (Talk | contribs | block) deleted page Template:ku-decl-noun-m/f (author request, see Template:ku-decl-noun-mf) (no-documentation)

Ha, even when deleting the page the abuse filter tags it with no-documentation. Mglovesfun (talk) 18:43, 13 July 2012 (UTC)

Fixed.​—msh210℠ (talk) 19:13, 13 July 2012 (UTC)

The 'filter' or whatever it is, is marking new code templates as having no documentation. But those templates use {{langt}}, {{famt}} and {{scriptt}}, which are also documentation templates (they transclude the /doc subpage if one exists). Could the script be changed so that it does not mark templates that transclude one of those as errors? Thank you! —CodeCat 21:43, 13 July 2012 (UTC)

It's Special:AbuseFilter/19. Feel free to improve it. —Ruakh_TALK 23:14, 13 July 2012 (UTC)

I made some changes now, I hope they're ok. —CodeCat 23:23, 13 July 2012 (UTC)

There needs to be a space between a & Clipping. --Æ&Œ (talk) 22:49, 16 July 2012 (UTC)

 Done. — Ungoliant ^(Falai) 22:56, 16 July 2012 (UTC)

My default Watchlist has changed its look. Not sure if something happened on my PC or something has happened on Wiktionary. I had to change for a different skin - the default skin - Vector is ugly and is not user friendly any more, I have to scroll all the way to the bottom of the page to find the search window, for example. Is anyone experiencing the same thing or is it just me? When checking Wikipedia (I have an account there as well) - there is no problem with a display. --Anatoli ^{(обсудить)} 02:08, 17 July 2012 (UTC)

FWIW, nothing has changed for me. --BB12 (talk) 02:10, 17 July 2012 (UTC)

If I understood you correctly, I had the same problem some time ago. In my case clearing the browser’s cache fixed it. — Ungoliant ^(Falai) 02:16, 17 July 2012 (UTC)

Thank you. I have tried to clear the cache and changed back to vector, it didn't help. I wonder if Spybot (Search & destroy) has removed something it shouldn't, that's the only thing that changed since yesterday - I ran the immunisation and removed some tracking cookies. --Anatoli ^{(обсудить)} 02:29, 17 July 2012 (UTC)

Fixed it, thanks again! I didn't clear the cache properly before. --Anatoli ^{(обсудить)} 02:41, 17 July 2012 (UTC)

I think it'd be valuable to users to be able to find the English subcategory of a topical category (e.g. category:Religion) without having to find it among the other codes: the description atop the page should link to the English subcategory. AFAICT this can be accomplished by adding

{{#if:{{{langlink|}}}|<br><br>For the English-language subcategory, see ].}}

to template:topic cat description, but I figured I should check here first to make sure that that won't break anything (as well as to make sure it's not controversial, though I don't know why it would be).​—msh210℠ (talk) 18:08, 17 July 2012 (UTC)

The goal seems extremely sensible, though I wonder whether the display will be prominent enough to avoid wasting users' time. DCDuring TALK 19:03, 17 July 2012 (UTC)

I really don't see how this would be useful at all... --Yair rand (talk) 19:04, 17 July 2012 (UTC)

Anyone stumbling across category:Religion may well (I'd say: would most probably) be seeking English entries related to religion. (Unless he's used to Wiktionary and its category structure.)​—msh210℠ (talk) 20:12, 17 July 2012 (UTC)

I agree with the goal of helping users find the English entries more easily, but the proposed wording ("English-language subcategory") seems to presuppose an understanding of our category structure. Readers who already share the presupposition will not need the help; some readers will easily make the leap, and thereby come to a better understanding of our category structure; and some readers simply won't be helped by it. (I think part of the problem right now, BTW, is that the current text, "The following is a list of terms related to religion", is completely wrong: that category-page doesn't list any terms at all. The ideal solution would fix the current text and add text guiding readers to the English category.) —Ruakh_TALK 20:36, 17 July 2012 (UTC)

Yeah, "For the English-language subcategory, see" is bad. "For the subcategory comprising English words, specifically, see" is better, though it can probably be improved on also. And yes, the initial wording can certainly be changed also (and in the same #if).​—msh210℠ (talk) 22:31, 17 July 2012 (UTC)

Support. Mglovesfun (talk) 22:33, 17 July 2012 (UTC)

I've taken a stab. Please have a look.​—msh210℠ (talk) 05:37, 18 July 2012 (UTC)

The wording is fine, bat can't overcome the weakness of the display of subcategories. The subcategory display will probably defeat some people looking for subtopics of, say, Religion and not interested in language codes or languages. Can't the display of language-prefixed categories be separated from the topical categories? Don't most normal users have a basic interest in just one language at a time? If interested at all in categories, aren't they looking for topics. Our display approach seems to be intended for our need for organization rather than for usability. When did we vote on this display of topical information? DCDuring TALK 01:04, 19 July 2012 (UTC)

A possible alternative would be to display the languageless 'umbrella' categories only as subcategories of Category:List of topics, but not make them into a tree. Only the categories for each language would form a tree then. A category like Category:Religion would then consequently only contain the religion categories of each language, like Category:en:Religion, but not subcategories like Category:Buddhism. On the other hand, Category:en:Buddhism would stay categorised in Category:en:Religion like it is now. This way of structuring categories is what all our other per-language categories already use, too. —CodeCat 01:13, 19 July 2012 (UTC)

Index:Japanese is pretty horribly useless. Should this page just be scrapped, or is there some useful way of turning this into its stated goal, of being a list of all Japanese terms in kana-betical order? Its current format seems to be a horribly misguided attempt at manually recreating categories. I'd much rather leave that to the actual categories, but it would also be nice to have a proper index of all Japanese terms in one place, without having to navigate through our byzantine category tree structure. -- Eiríkr Útlendi │ Tala við mig 17:54, 18 July 2012 (UTC)

Isn't there a bot that creates the Indexes? —Angr 19:52, 18 July 2012 (UTC)

I rather hope there is, but the last bot to touch this particular index page was User:UllmannBot in Feb 2007 here, and that was just to change some links from "Wiktionary:...Index" to "Index:..." format. The main content of the page consists wholly of what appears to be manually maintained wikicode pointing to individual entries, such as:

If anyone has an indexing bot, please sic your bot on this page, as it sorely needs the attention. -- Eiríkr Útlendi │ Tala við mig 20:35, 18 July 2012 (UTC)

That would be User:Conrad.Bot. --Yair rand (talk) 22:38, 18 July 2012 (UTC)

The format of Index:Russian is much more useful than the current Japanese index but it gets out of date quickly. It was generated by User:Conrad.Bot. I asked Conrad a while ago but he must be too busy.

Have a look at User:Matthias_Buchmeier#English-Japanese as well. This was generated by translations from English into Japanese. Very useful (a few other languages there as well). Perhaps we could ask Matthias_Buchmeier to move this to the main space and add categories and make them automatically updateable. --Anatoli ^{(обсудить)} 23:12, 18 July 2012 (UTC)

• A slow-moving thought finally percolated up to the top of my consciousness:

Why are we relying on bots to do something sporadically, when the server probably already does it automatically?

Categories are handled automatically and almost immediately by the server. So long as editors add a category to an individual page, that page is added to that category.

Isn't there some sort of über-category for each language as a whole? Is there any way of leveraging the content of, say, ] to create an automatically updated index of all Japanese terms? That cat page even suggests that such an index might be at ]. -- Eiríkr Útlendi │ Tala við mig 00:40, 19 July 2012 (UTC)

The way the German and French Wiktionaries do things, all words appear in POS categories and overall language categories (see fr:Catégorie:français, de:Kategorie:Deutsch). - -sche (discuss) 03:00, 19 July 2012 (UTC)

I think we've decided not to index all entries, only lemma forms. But I see no reason we couldn't have a "cat:Langname lemma forms" (er, "Langname index" sounds much better, but the cat page must make it very clear not every entry goes in there), for indexing purposes.​—msh210℠ (talk) 06:49, 19 July 2012 (UTC)

• It makes sense to me to have a list of just lemmata, from the point of view of general user expectations -- when one goes to a dictionary, be it print or online, one generally expects to find lemma word forms. On the technical side, though, I'm not sure what easy way there would be of telling automatically if a given entry is a lemma or not, which could make it difficult to create such a list.

That said, it also makes sense to me to have a list of *all* entries in a given language, from the point of view of general usability and for editors -- if I, as an editor (or even as a general user), want to see a list of *all* terms for a specific language, the only way I can think of to do that currently involves data dumps, which is hardly convenient.

Is there any particular argument against listing all entries for a language under that language's main category, such as at fr:Catégorie:français or de:Kategorie:Deutsch? Both these pages are much more user-friendly and accessible than the corresponding pages here on the EN WT (Category:French_language and Category:German_language), where instead we've opted to send users to separate Index pages, which may or may not actually list all terms for that language. Moreover, both the French and German indices appear to be managed by bot based on database dumps and thus fall out of currency, rather than just using the built-in category functionality already offered by the server. This strikes me as less than optimal, and much less user-friendly than we are capable of being, if the FR and DE WT sites are anything to go by. -- Eiríkr Útlendi │ Tala við mig 16:55, 19 July 2012 (UTC)

Ha I see it very differently. The bot built indexes will of course always be out of date, but they are nicely organized into subsections with parts of speech markers and additional information. A category with over a millions entries like fr:Catégorie:français strikes me as absurd. What useful information could be gleaned from a category, apart from database dump style analysis. Mglovesfun (talk) 17:11, 19 July 2012 (UTC)

Hmm, comparing de:Kategorie:Deutsch and Index:German side-by-side, I note:

• ] wins the basic usability competition, as it lists (presumably) *all* German words starting with the selected letter on one page, and breaks the page up with sub-headings by . Meanwhile, ] just lists terms, only 200 at a time, and with no sub-headings.
• ] also lists additional information to the right of each entry, including what looks like short POS abbreviations, a right-pointing triangle to indicate audio for that entry, and an asterisk linking to the corresponding English translation where applicable. The audio & translation markers are clickable links as well, which is handy.
• Oddly, some terms in ] are showing as orange in my browser, indicating no German term. This appears to indicate terms such as ], where we have an English entry that lists ] as a German translation, but where that German entry has not yet been created -- this is really cool, and I'm happy to see this kind of functionality in an index. However, ] also shows ] as an orange link, which might be because this link is not language-specific -- it points to ] as opposed to ]. Does this indicate a change since the last time the index was updated? Or was there an error when creating the index?

Thank you, Mglovesfun, for pointing out some of the differences and prompting me to take a closer look. My desires for having a single list with all terms in a specific language are more than met by Index:German. I would greatly appreciate it if someone could do the same for Japanese, as that index is anything but an index.

That said, the current lack of a Japanese index and the need to get any specific user to do something extra to create one is a bit of a concern. If the maintainer of an indexing bot were to get hit by a bus, what then? Shouldn't we be seriously exploring how to build this kind of functionality into the server, or at least making it publicly available to admins? That way, we avoid having any single point of failure when it comes to creating and updating language indices. -- Eiríkr Útlendi │ Tala við mig 18:17, 19 July 2012 (UTC)

One difference between indexes and categories is, or at least used to be, that indexes can include red links. Index:Irish used to include not only all the Irish lemmas we already have, but all the red-linked Irish words used in translation tables. That I found extremely helpful, but the bot was reprogrammed and overwrote them all, so now Index:Irish only includes blue links. There's no bot for Index:Burmese so I maintain that one manually, including red links from translation tables and elsewhere (e.g. Wikipedia articles on various aspects of Burmese culture). —Angr 18:22, 19 July 2012 (UTC)

Angr, you probably only add Burmese words that you yourself add or happen to notice, not someone else. We need something automated, a program that won't miss anything. Yes, we need red links as well and I also like very much the idea of regularly generating English-FL dictionaries from translations in English translation section. --Anatoli ^{(обсудить)} 23:50, 19 July 2012 (UTC)

Yes, that's right. I'm certainly not suggesting the way I manage Index:Burmese is ideal! I wish it was automated, but I know nothing about bots myself. So yeah, I just add terms as I discover them. —Angr 12:09, 20 July 2012 (UTC)

So then, is any single indexing bot controlled entirely by one user? Is there no community say into how an indexing bot is programmed? Is there any version control, or do bots happen entirely off-server? (I'm quite bot-ignorant, in case that's not already obvious.) -- Eiríkr Útlendi │ Tala við mig 18:50, 19 July 2012 (UTC)

A few of the "new en" subst-only templates (eg, {{new en noun}}) are categorized in the parts of speech they are meant to start an entry in. It can't be intentional as the template appears in alphabetical order at "new en noun". See Wiktionary:English entry templates. Can't that be overcome by proper documentation and use of the various "include" tags? I suppose a prior question is whether these templates are in use or have been superseded in some way. DCDuring TALK 00:50, 19 July 2012 (UTC)

Presumably it's because the headword-line templates used in them haven't been fixed to add the category only when transcluded into entry namespaces. —CodeCat 01:01, 19 July 2012 (UTC)

Is that the only way to do it? Doesn't wrapping the template content in "includeonly" and putting in proper documentation do it? {{en-noun}} et al are fairly widely transcluded so each edit adds a lot to the job queue I would imagine, doesn't improve any current use of the template, and adds complexity not just to the template but to the whole cascading transclusion process.

In any event, the prior question is whether they are used. DCDuring TALK 01:20, 19 July 2012 (UTC)

Includeonly won't work here, because of course, the templates are included - into the entry template! For a while now we've established the practice of adding code like <includeonly>{{#if:{{NAMESPACE}}||(categories here)}}</includeonly> to any templates that add entries to categories, it seems that {{en-noun}} is one of the few that still lacks it. —CodeCat 01:25, 19 July 2012 (UTC)

Never mind. I can see that there are several templates of the "new en" type that do just that. DCDuring TALK 01:27, 19 July 2012 (UTC)

So that's why there are so many uses of {{head|en|noun}} that I have to change to {{en-noun}} to take advantage of the convenient handling of un/countability. I keep on running into complaints from users on Talk pages about countability issues. {{head}} really shouldn't be used in place of the English language-specific templates. Frankly, I'm appalled that it is. It just makes work, as if there isn't enough. DCDuring TALK 01:37, 19 July 2012 (UTC)

That's why there is User:Liliana-60/en-infl - to crack down on these uses. -- Liliana • 02:32, 19 July 2012 (UTC)

But shouldn't they be cut off at the source? Why do we have to correct automated or semi-automated processes? Why is there ANY use of an inflection template for misspellings? All that seems to do is make our PoS category membership even less reliable and pointlessly increase the number of transclusions of templates? This makes me think we've been taking steps backward. DCDuring TALK 03:33, 19 July 2012 (UTC)

In addition to what CodeCat says . . . it used to be that the "preload" feature didn't support <noinclude> and <includeonly>. (And in fact, it still doesn't really support them very fully; as I recall, it now uses very simplistic string-matching to find what to strip out.) But, now that it does support them, I've modified ] to not be in Category:English nouns. —Ruakh_TALK 02:59, 19 July 2012 (UTC)

{{pedialite}} was nominated for deletion some time ago, the consensus was if anything, to delete {{wikipedia}} rather than pedialite. I was thinking maybe we could merge wikipedia into {{slim-wikipedia}}. This is more or less the best of both worlds, it takes up less space down the right hand-side where wikipedia frequently clashes with images, but also wouldn't have to be moved under the ===External links=== header, it remains in the same place as wikipedia. I'm not adding this to WT:RFM as I'm not sure if anyone would support it. Heck, I'm not even sure if I'd support it. Mglovesfun (talk) 16:41, 19 July 2012 (UTC)

I like {{wikipedia}} and the way I see it, the closer we get to {{pedialite}} (smaller, more out-of-the-way, less user-friendly), the worse. So early oppose. --Μετάknowledge^{discuss/deeds} 16:44, 19 July 2012 (UTC)

Sure, but you understand what the problem is, right? Just checking. Mglovesfun (talk) 16:45, 19 July 2012 (UTC)

No, what is the problem? I prefer {{wikipedia}} as well, because it is easier on the layout. Personally I think we should allow more elements to be floated on the right when possible. —CodeCat 16:50, 19 July 2012 (UTC)

Depends what you mean by "where possible". They tend to pile up and squash the text to the left, and then also drop into further language sections. I've seen entries using {{wikipedia}} and {{wikisource}} and {{wikispecies}} (usually not all three, but two of the three) where the boxes go down into the next language section, so you get a French entry saying "the Dutch Wikipedia has an entry on..." Mglovesfun (talk) 16:54, 19 July 2012 (UTC)

Such pileups are, well, rare. They only appear in entries that are important enough to have a lot of interproject links, but not enough text. However, if you really want to clean those problems up, there is a neater (IMO at least) solution, which is to create a template that takes other right-float templates as its arguments and shoves them together so they take up less space. That might also help if we really did float more stuff to the right, as CodeCat suggests (and I do agree that to do so would be a good idea). --Μετάknowledge^{discuss/deeds} 18:49, 19 July 2012 (UTC)

We could also amend WT:ELE so that the horizontal line ---- is to be preceded by {{-}}... or maybe make a new template {{----}} that includes both the line and the margin clearing. That would prevent floating elements from flowing into the next language sections by accident. —CodeCat 02:04, 20 July 2012 (UTC)

If we want to go that route, I think it would make more sense to just add hr { clear : both } to MediaWiki:Common.css. —Ruakh_TALK 02:11, 20 July 2012 (UTC)

Good idea! —CodeCat 15:23, 20 July 2012 (UTC)

I think that would mess up right-side ToCs. (See my edits, just now, to the sandbox.)​—msh210℠ (talk) 15:35, 20 July 2012 (UTC)

There is something that may work for this though I don't know for sure. If the page is split into two separate pieces (divs) with the ToC in one, and the remainder of the page in the other, then 'floating' would presumably be confined only to the box containing the page, and may not effect the ToC box. —CodeCat 16:34, 20 July 2012 (UTC)

Stupid question: can someone please tell me what I did wrong with the asterisks and colons for the indented bullet points here? (For an example of how it looks when it's messing up, see the Tok Pisin section in this revision). Thanks! --Μετάknowledge^{discuss/deeds} 18:45, 19 July 2012 (UTC)

Yair rand: Thanks, but skai still doesn't look right. Problem not solved yet. --Μετάknowledge^{discuss/deeds} 18:52, 19 July 2012 (UTC)

Now fixed. --Yair rand (talk) 19:00, 19 July 2012 (UTC)

Ah, now I see my mistake. Again, thank you! --Μετάknowledge^{discuss/deeds} 19:04, 19 July 2012 (UTC)

Can somebody please generate a list of Tok Pisin entries that lack etymology sections? If possible, I'd like a list that doesn't include any alt-forms (i.e., usage of {{alternative form of}} in the Tok Pisin section of the page). Thanks in advance! (I'm assuming this is dump analysis work, but there might be a better way...) --Μετάknowledge^{discuss/deeds} July 18, 2012 20:33

• User:Metaknowledge/Tok Pisin without etymology

(Feel free to move this list to a user-subpage or something.) Done to avoid cluttering the GP --Μετάknowledge^{discuss/deeds} 01:25, 20 July 2012 (UTC)

—Ruakh_TALK 01:17, 20 July 2012 (UTC)

Again, thank you so much! --Μετάknowledge^{discuss/deeds} 01:25, 20 July 2012 (UTC)

By the way, is it possible for you to tell me exactly what date the dump was accurate on? I'm going through the list, but I've found some words that already have etym sections. Just curious, I don't think it's very important for me to know. --Μετάknowledge^{discuss/deeds} 04:23, 20 July 2012 (UTC)

Most recent dump was 2012-07-16 09:39:40. --Yair rand (talk) 04:25, 20 July 2012 (UTC)

That (mostly) makes sense, given what I've seen. I'll assume any dump errors aren't actually problems present in the entries. Thanks! --Μετάknowledge^{discuss/deeds} 04:41, 20 July 2012 (UTC)

@Yair rand: That's when the huge "All pages with complete edit history (.7z)" dump (pages-meta-history.xml.7z) finished. I used the "Articles, templates, media/file descriptions, and primary meta-pages" dump (pages-articles.xml.bz2), which ran on 2012-07-15 from 03:31:28 to 04:45:28. —Ruakh_TALK 16:57, 20 July 2012 (UTC)

I just finished going through the list. While I'm at it, would it be possible to get the same exact service for Bislama and Pijin?

• User:Metaknowledge/Bislama without etymology
• User:Metaknowledge/Pijin without etymology

If not, that's OK, but I just want to get these over with and done. Thank you so much in advance! --Μετάknowledge^{discuss/deeds} 22:20, 20 July 2012 (UTC)

Thank you so much! One more request (this will hopefully be the last for now): can I get a list of terms in Tok Pisin, Bislama, and Pijin that have quotations or ===References=== sections, but do not have the {{LDL}} template (i.e. the string LDL)? I'd prefer the list to be grouped by language. Thank you so much, again! --Μετάknowledge^{discuss/deeds} 00:34, 21 July 2012 (UTC)

• User:Metaknowledge/Citations without LDL

Thanks so much! --Μετάknowledge^{discuss/deeds} 19:15, 21 July 2012 (UTC)

Sorry, I thought of another one that would be great. A while ago, a certain user added some Tok Pisin and Indonesian terms together, and it seems like the Tok Pisin ones tended to be inaccurate. I caught two of them (WT:RFV#aiadin and WT:RFV#otonomi), but there might be more ought there. Can I get a list of all articles that have both an L2 section for Tok Pisin and an L2 section for Indonesian? Again, thank you so much for all this trouble.

• User:Metaknowledge/Tok Pisin Indonesian

 Done, but it's actually you who added the Indonesian section at ], and that was later than the last database dump, so it's not in the list. —Ruakh_TALK 22:46, 21 July 2012 (UTC)

Thanks! That's true. The page was created by the user I mentioned and while trying to check it, I noticed a bunch of Indonesian citations, so I added that, too. The basic problem is still there, but this probably means that I'm exaggerating the Indonesian threat. I'll check 'em all to be sure anyways. --Μετάknowledge^{discuss/deeds} 23:27, 21 July 2012 (UTC)

Yup, a bunch of relatively suspicious-looking false positives. Thanks anyways --Μετάknowledge^{discuss/deeds} 23:36, 21 July 2012 (UTC)

I just wanted to draw attention to MediaWiki talk:Recentchangestext where requests have been backlogged. Some have been there for four years with no response. Could any sysop take the time for this? --Whym (talk) 00:29, 21 July 2012 (UTC)

I think I went through 'em all, and I added it to my watchlist so I'll notice next time it happens. If I missed any, just tell me. --Μετάknowledge^{discuss/deeds} 01:14, 21 July 2012 (UTC)

Thanks a lot! One little issue was remaining. I followed up in the talk page. --Whym (talk) 01:36, 21 July 2012 (UTC)

 Done --Μετάknowledge^{discuss/deeds} 02:26, 21 July 2012 (UTC)

I kinda feel like implementing this, but I don't think it's been discussed enough to do so. Mglovesfun (talk) 12:33, 21 July 2012 (UTC)

I support using straight ASCII quotes. —CodeCat 12:35, 21 July 2012 (UTC)

"Be bold" --Μετάknowledge^{discuss/deeds} 15:47, 21 July 2012 (UTC)

Don't be bold. I, too, support straight ASCII quotes, but this also raises the question of other templates that use curly quotes ({{l}} and {{onym}}, obviously; also reference-templates), as well as the many entries that use curly quotes in their own wiki-text. Are we establishing a policy of using straight quotes? A policy of using straight quotes except in citations? Should we have a bot modify all existing curly quotes? I don't think it makes sense to modify {{term}} without thinking these through. —Ruakh_TALK 16:47, 21 July 2012 (UTC)

It doesn't have to be a full-blown policy - but if we're going to do it that way, then yeah, I support all those actions. --Μετάknowledge^{discuss/deeds} 17:08, 21 July 2012 (UTC)

"Be bold" and "massively transcluded template" are never a good combination. Chuck Entz (talk) 17:21, 21 July 2012 (UTC)

C'mon, we're just talking quotation marks here. Not like it's noincludes or something. --Μετάknowledge^{discuss/deeds} 17:23, 21 July 2012 (UTC)

@Ruakh, Chuck Entz, yes WT:BOLD specifically mentions "Some caution is also advised if your changes affect many other pages, such as editing a template". Mglovesfun (talk) 17:29, 21 July 2012 (UTC)

(after edit conflict) Any change- no matter how small- that makes a difference in the pages where a template is transcluded will trigger an edit of (at least) every entry that changes. Remember that the time spent per entry is multiplied by the total number of entries: a millisecond spent on 60,000 entries adds up to a minute. An edit that affected all of Wiktionary would take something like 45 minutes for each millisecond. {{term}} isn't quite that widespread, but it's much too close to trifle with, especially if it's going to be challenged and force a second edit to correct it. Chuck Entz (talk) 17:55, 21 July 2012 (UTC)

How about a BOLD experiment with one or more not-so-widely transcluded templates (ie, << 370K transcluded pages, maybe hundreds), preferably on pages frequently visited, followed by a BP discussion? I expect that relatively few folks would notice the changes. DCDuring TALK 17:47, 21 July 2012 (UTC)

Coincidentally I changed {{recons}} to smart quotes some days ago. Has anyone noticed? — Ungoliant ^(Falai) 18:28, 21 July 2012 (UTC)

Well not coincidentally (what coincidence?) but I saw it in the recent changes, I haven't noticed it in entries. Mglovesfun (talk) 22:28, 21 July 2012 (UTC)

The coincidence is that DCDuring proposed trying this as an experiment, but I had already done it. So all we need to do is ask the folks if they noticed the change. — Ungoliant ^(Falai) 22:37, 21 July 2012 (UTC)

Oh sorry. In truth I can only tell the difference between smart quotes and straight ones if I look really closely, or when editing pages. Mglovesfun (talk) 22:59, 21 July 2012 (UTC)

Hello,

How do I correctly display the Avestan and the Gothic script? If you can see the Avestan and Gothic script in entries correctly, could you tell me what Unicode settings you use in your browser and in general?

Greetings HeliosX

I think you just need to download and install the fonts: Avestan and/or Ahuramzda for Avestan; and Skeirs or Code2001 for Gothic. —Stephen ^(Talk) 10:07, 22 July 2012 (UTC)

Thanks a very big bunch! HeliosX (talk) 10:37, 22 July 2012 (UTC)

Look at the listing of dwarf planets in the "See also" section of Ceres, Pluto, etc., and you'll see multiple requests for documentation requested. There must be a template called somewhere for which the documentation link was not properly set off so as not to show up in the artivle. However, I'm not sure which called template is causing the problem. --EncycloPetey (talk) 22:54, 22 July 2012 (UTC)

I made a mistake last night on a template edit. I think all should be back to its blissfully undocumented state. DCDuring TALK 00:32, 23 July 2012 (UTC)

Can we add a category for Latin reduplicative verbs such as cadere - cado - cecidi - casum, since for me they're not only third conjugation but reduplicative with third-conjugatin-elements in passive.

Greetings HeliosX (talk) 10:50, 23 July 2012 (UTC)

I don't think a category for reduplicative verbs alone is useful. Latin perfects are formed several different ways; reduplication is only one possibility, others are adding -v-, or adding -s- and so on. Do we also want categories for those? Also, what do you mean by 'add'? Add to what? —CodeCat 12:51, 23 July 2012 (UTC)

I propose that this is useful, because the actual categorization is only for the passive and the present active; Latin misi is actually very different to cecidi but they're both in the same category. Thus it'd support the valuability of categories in Wiktionary. Also, the actual Third-Conjugation-category, as example, is not the smallest one. I meant with "add" to create it.

Greetings HeliosX (talk) 20:03, 23 July 2012 (UTC)

Is there any way to transclude across projects? TIA --Μετάknowledge^{discuss/deeds} 03:26, 24 July 2012 (UTC)

Nope. --Yair rand (talk) 04:34, 24 July 2012 (UTC)

Ah well. Thanks anyway. Links to Wikisource it is. --Μετάknowledge^{discuss/deeds} 04:44, 24 July 2012 (UTC)

What happened to Interwiki bots? I never worried about adding links to other projects and discouraged others from doing it manually, as Interwikis worked great before. Although, I think some languages were "discriminated" by bots and because of the confusion with zh/cmn templates links to Chinese wiki weren't working well and Mandarin translations received a - (minus) as if a Chinese entry didn't exist. Anyway, whoever ran that bot, please check it. --Anatoli ^{(обсудить)} 05:44, 25 July 2012 (UTC)

Re: interwikis: You're right, interwikis seem to have fallen behind. I've started Rukhabot (talk • contribs) adding (and removing) interwikis based on the latest database dumps; it's a bit different from the other interwiki-bots, in that it doesn't keep up with newly created pages, but it's good for times like the present, when there are hundreds of thousands of interwikis needing to be added.

Re: {{t}} vs. {{t+}} vs. {{t-}}: That was Tbot (talk • contribs), which was run by Robert Ullmann (talk • contribs), who passed away almost a year and a half ago. No one has since written a replacement. I'll take a look at it after interwikis are caught up (in a few months, most likely), if no one beats me to it.

—Ruakh_TALK 18:14, 28 July 2012 (UTC)

I missed the answer. Sorry to hear about Robert, I didn't know! Please let me know if you'd like to talk about {{t}} vs. {{t+}} vs. {{t-}} and also {{zh}} vs. {{cmn}}. I'm not proposing any change in how we structure Mandarin translations but the language code should be consistent. Using {{cmn}} is undesirable because it adds a "ø" to {{t}}, thus unlinking from zh:wiki (cmn:wiki doesn't exist), {{zh}} is changed to {{cmn}} by bots, without adding a "ø" but always incorrectly adding a {{t-}}. On an unrelated note, I wonder who could take over generating language indexes (I know you also requested a Hebrew index from Robert a while ago). --Anatoli ^{(обсудить)} 00:26, 30 July 2012 (UTC)

Re: zh vs. cmn: {{t}} does recognize that a language-code of cmn corresponds to an interwiki language-prefix of zh — that is, {{t|cmn|foo}} will generate a superscript (cmn) that's actually a link to zh:foo — so there's no reason this should be a problem, as long as whoever writes the bot is aware of the issue.

Re: language indices: Those are actually done by Conrad.Irwin (talk • contribs), who SFAIK is alive and well. :-)

—Ruakh_TALK 01:48, 31 July 2012 (UTC)

Oops, thanks :) --Anatoli ^{(обсудить)} 02:26, 31 July 2012 (UTC)

Do you know if it's possible to make Irwin's tool NOT to add a "ø" if people use (cmn) language code in translations instead of (zh)? Or should I ask Conrad? I don't know if he is too busy to be contacted. --Anatoli ^{(обсудить)} 02:32, 31 July 2012 (UTC)

Sorry, I'm confused. Maybe we're talking at cross-purposes, or maybe you know something I don't? When I said that "language indices" are done by Conrad, I was referring to pages in the Index: namespace, such as Index:Hebrew/א. I was not referring to the conversion of {{t}} to {{t+}}/{{t-}}/{{tø}}, which used to be done by Tbot (talk • contribs), and which — so far as I know — no one has worked on since Robert passed away. —Ruakh_TALK 03:24, 31 July 2012 (UTC)

Sorry for confusing you, my fault. I'm embarrassed. I don't think straight today. You're right, these are two different issues. --Anatoli ^{(обсудить)} 04:00, 31 July 2012 (UTC)

Has anyone done something to alter the appearance of this wiki? In particular, text is smaller than it used to be (I use the default monobook skin). SemperBlotto (talk) 10:05, 25 July 2012 (UTC)

You've probably zoomed out accidentally; I do this from time to time. Zooming is usually under 'view', it depends on your browser. Mglovesfun (talk) 10:06, 25 July 2012 (UTC)

No. Wikipedia, other language Wiktionaries and other websites look the same as they always did. SemperBlotto (talk) 14:15, 25 July 2012 (UTC)

Many (most?) browsers do zoom-out on a site-by-site basis. —Ruakh_TALK 14:45, 25 July 2012 (UTC)

My father won't use Wiktionary because he zoomed in by way too much once, and now his crappy computer can't zoom at all, with Wiktionary being stuck gigantic. --Μετάknowledge^{discuss/deeds} 16:49, 25 July 2012 (UTC)

Crappy is right!! Mglovesfun (talk) 17:47, 25 July 2012 (UTC)

OK. It looks like I must have press Ctrl-minus (on Google Chrome). Ctrl-plus reverses this. Chrome help page says this zooms a single page, but it actually works for an entire website. SemperBlotto (talk) 18:30, 25 July 2012 (UTC)

I think Ctrl-zero reverts the zoom to standard.​—msh210℠ (talk) 18:42, 25 July 2012 (UTC)

Indeed it does. Same as in Firefox. —Ruakh_TALK 18:51, 25 July 2012 (UTC)

I thought Monobook was no longer default, but Vector. Certainly font size is smaller in Vector than in Monobook, so maybe SemperBlotto's settings switched skin from the old standard to the new one. —Angr 07:01, 26 July 2012 (UTC)

No. vector is nasty! I meant that I have monobook specified in preferences, but do not have my own monobook.css file. SemperBlotto (talk) 07:07, 26 July 2012 (UTC)

I went to look through Recent Changes (hide bots, hide patrolled edits) and found... none. Either someone went though a week's worth of edits and patrolled them all (in which case, thank you!), or something's wrong. Having never seem this happen in the few months I've been an admin, I thought I would bring it to the attention of those who could make sure it wasn't the second possibility. Chuck Entz (talk) 21:10, 25 July 2012 (UTC)

• Yes. Everthing is patrolled from the 17th July. SemperBlotto (talk) 21:19, 25 July 2012 (UTC)

The screen one gets sent to after deleting a page has several bugs. A major one is that, near the upper middle, it says:

Other pages to be {{delete}}d

and then gives a list of entries tagged with {{delete}}, if any exist. However, if you just deleted one of them (leading you to that screen), it still appears in the list. Does anyone know where the code that's causing this problem is located, and/or how to fix it? Thanks --Μετάknowledge^{discuss/deeds} 05:16, 26 July 2012 (UTC)

That's always how it is. Similarly, after you click a "Mark as patrolled" link, you get brought to a "Marked as patrolled" page with a list of unpatrolled recent changes. That list includes the recent-change that you'd just marked. I doubt there's anything we can do about it.

But, you said that there are "several" bugs. What are the others?

—Ruakh_TALK 13:19, 26 July 2012 (UTC)

Well, for one, the mini Recent Changes says "2 {{PLURAL:2|change|changes}}" instead of saying "2 changes" like the real Recent Changes. I'm not sure why {{PLURAL}} is just outright failing. Also, not necessarily a "bug" per se, but I can see if something is patrolled or not, but I can't patrol it. --Μετάknowledge^{discuss/deeds} 17:22, 26 July 2012 (UTC)

Re: "2 {{PLURAL:2|change|changes}}": I don't see that. Where exactly are you looking?

Re: "I can see if something is patrolled or not, but I can't patrol it": I have no idea what you mean. :-/

—Ruakh_TALK 18:05, 26 July 2012 (UTC)

OK. Make a user subpage, then delete it. Once you've deleted it, look at the screen you're sent to instead of rushing away. There's a Recent Changes-esque section at the bottom. Normally (i.e., in the "real" Recent Changes), multiple edits on a single page will collapse if you have sysop view enabled. That error occurs when the mini-RC tries to handle that. As for patrolling, I can see the red exclamation points, but the JS add-ons for marking the edit as patrolled are not present. Does that explain it? --Μετάknowledge^{discuss/deeds} 18:21, 26 July 2012 (UTC)

Re: "if you have sysop view enabled": Which I don't. (And you should have mentioned it earlier.) But assuming that by "sysop view" you mean the "Group changes by page in recent changes and watchlist (requires JavaScript)" preference at Special:Preferences#mw-prefsection-rc, I just tried it, and still couldn't reproduce either of the issues you describe. —Ruakh_TALK 18:26, 26 July 2012 (UTC)

Sorry, I mistakenly assumed that bit. Can you tell me what you do see? Or were there just no unpatrolled edits or multiple edits on one page happening at all when you tried it? --Μετάknowledge^{discuss/deeds} 18:31, 26 July 2012 (UTC)

Re: unpatrolled edits: They looked exactly as they should — a blue button, clicking it patrolled the edit. Do you consistently see this issue, or only occasionally? Does your browser's error console give any information?   Re: multiple-edits-on-one-page: *tests* — ah, yes, I see what you mean now. In fact, even without enabling the preference that you mention, this bug can be observed by hovering over (e.g.) (+40): the hover-text should be (e.g.) 2,977 bytes after change, but is instead 2,977 {{PLURAL:2,977|byte|bytes}} after change. —Ruakh_TALK 18:51, 26 July 2012 (UTC)

It is consistent, but if it's only affecting me, I guess that's just my problem. There's also some wording problems: grammatical mistakes and use of 'Error' to tell me there is nothing tagged with {{delete}} (that should not be an error message).
Just because this bug (and the previous one) are "always how it is" doesn't mean we shouldn't try to fix them, if we can. --Μετάknowledge^{discuss/deeds} 18:58, 26 July 2012 (UTC)

Re: unpatrolled edits: I don't know if it's only affecting you; all I know is that it's not affecting me. And I would like to fix it, if you can help me do so. I've put a lot of effort into lowering the barriers to patrolling, and I'd like to know if any of my efforts aren't succeeding.

Re: grammatical mistakes: Such as?

Re: 'Error': I don't see that, though I vaguely remember having seen it in the past.

Re: whether we should try to fix these issues: I guess I just don't care too much about minor infelicities of presentation in the "success" screen that admins and patrollers see after deleting a page or patrolling an edit, as long as these don't affect functionality. If they're reasonably simple to fix, then fine, but if I can't even figure out what they are, then I don't plan to spend too much time on them.

By the way, this screen is controlled by MediaWiki:Deletedtext. I'm not sure if any of the issues you mention can be addressed by simple edits there, but do take a look.

—Ruakh_TALK 19:10, 26 July 2012 (UTC)

Metaknowledge, I broadly agree but my brain has got so used to that post-deletion text that it can cope with no problems at all. Weirdly, I don't think correcting it would have any long-term advantages whatsoever, but in the short term I'd have to start reading the text to see how it'd've changed, so for me it's better not to address the bug. Mglovesfun (talk) 19:13, 26 July 2012 (UTC)

Thanks for pointing me there, Ruakh; I made some minor changes. I think the rest of my problems are with DynamicPageList, and I have no idea how to fix that. MG: If you really think so, well... it looks awful, but I guess we can leave it (I know you delete more often than I do).--Μετάknowledge^{discuss/deeds} 19:18, 26 July 2012 (UTC)

Someone just mentioned on my talk page that it might be possible to find a bot owner willing to help me create form-of pages for Latvian words. Thus far I've been doing almost only nouns, because they have relatively few forms (6 cases x 2 numbers with moderate syncretism); but adjectives have many more forms (6 cases x 2 numbers x 2 genders x 3 degrees), and verbs even more. So here I am: would anyone be interested in making bot code for creating form-of/inflection of pages for Latvian words? If so, how exactly should this be done? --Pereru (talk) 22:02, 26 July 2012 (UTC)

I've been letting it slide due to doing other things IRL..but I kind of would like to try to cover this. I'll try to get working on some more Icelandic stuff soon so that if and when I make a vote to get a bot flag for an account I would make, I would actually have a lot to add with it. So after I sort that out I can try to throw something together for Latvian. User: PalkiaX50 ^{talk to meh} 23:34, 26 July 2012 (UTC)

That would be great, Palkia. Do let me know when you're ready. (And also, since you have more experience than I do, you probably could give me some ideas about how to do this.) --Pereru (talk) 00:20, 30 July 2012 (UTC)

Why is it that the French, Dutch, and German Wiktionaries each have well less than 500 uncategorized template pages and we have more than 5,000 (or is that 10,000)? Most of the uncategorized template subpages that we have are subpages. Do other Wiktionaries not permit subpages in template space? Do their MW settings treat template subpages differently? Do their template designs not rely on subpages? Are our templates cooler than theirs? DCDuring TALK 22:14, 26 July 2012 (UTC)

The last one, in my opinion. Also we just have more contributors, hence more templates overall, not just more uncategorized ones. Mglovesfun (talk) 22:28, 26 July 2012 (UTC)

Also our entries in Special:UncategorizedPages usually get fixed within 24 hours. Other Wiktionaries have entries that are uncategorized for years and years. Mglovesfun (talk) 22:29, 26 July 2012 (UTC)

Every language template (of which there are 7,657) has a /script template and many have /names and /family templates, and script templates have /name subpages. All of these are uncategorized. As far as I know, only English Wiktionary has systems for any of these things (displaying scripts in specific fonts, categorizing by language family, etc.). Why should any of these subtemplates be categorized? How would the categories be useful? --Yair rand (talk) 22:30, 26 July 2012 (UTC)

I think DCDuring's aim is to empty Special:UncategorizedCategories, though I hope not at any cost. Mglovesfun (talk) 22:33, 26 July 2012 (UTC)

I don't see why it shouldn't be cleared, though I guess indeed not at any cost. But I wouldn't be opposed to categories existing mostly just for the sake of clearing Special:UncategorizedCategories and, more to the point I imagine, Special:UncategorizedTemplates. I can't really think of a template categorisation example but compare noun form categorisation; I mean what use are noun form categories really? Not much TBH (no, I'm not saying to delete them). But nonetheless we pretty much keep them for two reasons:

1. So Special:UncategorizedPages is actually usable for maintenance purposes.
2. In order to keep more or less only the actual "content entries" in the main noun category. User: PalkiaX50 ^{talk to meh} 23:53, 26 July 2012 (UTC)

As I see it the purpose of Special:UncategorizedXXXXX is to "force" XXXXXs into categories where they may eventually be noticed by someone interested in the category or just curious about why the category exists and what is in it. If an XXXXX is uncategorized, it may be an indication of likely error, as is my experience with uncategorized pages, or outright nonsense, as is my experience with the uncategorized pages deleted by SB before I look at them.

The use of subpages other than for documentation, for which {{documentation subpage}} categorizes them, seems to have led to the persistent existence of well more than the maximum of 5,000 and probably closer to 10K of the 45K template pages we have (11-22%). fr.wikt has 120 uncategorized template pages out of 15K template pages, less than 1%. About two thirds of the uncategorized ones seem to be subpages. Perhaps they don't use subpages as much as we do or perhaps they have a solution to the uncategorized subpage problem. The other wiktionaries I looked at (zh, nl, de) had fewer than 5K template pages, and 5-10% uncategorized template pages. DCDuring TALK 02:18, 27 July 2012 (UTC)

Maybe we should create a category specifically to pit things in that we wouldn't want categorised otherwise. Something like Category:Uncategorised? —CodeCat 10:21, 27 July 2012 (UTC)

Re: "the purpose of Special:UncategorizedXXXXX is to 'force' XXXXXs into categories": No, the purpose of Special:UncategorizedXXXXX is to assist wikis in forcing XXXXXs into categories, should they choose to do so. (Presumably the English Wikipedia wanted this feature, so it was added. That's usually how it works.) The software does not require us to categorize things. —Ruakh_TALK 12:32, 27 July 2012 (UTC)

But the software operates in an environment of humans and is part of and serves a larger system. The "uncategorized" and similar special pages are supposed direct attention to classes of entries likely to "need" attention. If more than 5,000 entries squat on a resource that is supposed to provide a focus for attention, they prevent that attention from being given.

Would it be possible to have a variant of {{documentation}} designed to work (only?) on template subpages that assigned to the subpage the documentation and categorization of its associated page. A simpler version would require that the category be added as a parameter, allowing flexibility while requiring more keystrokes. DCDuring TALK 13:23, 27 July 2012 (UTC)

I would be more partial to a sort of individual category approach, even if the categories wouldn't be extremely useful for finding templates or whatever was categorised into them. For example, for the name subtemplates of scripts, Category:Script name subtemplates. Additionally, this category could perhaps be handled by {{tempcatboiler}} (by adding support for it) so that it would have an informative description of exactly what the hell the templates in it are. User: PalkiaX50 ^{talk to meh} 13:45, 27 July 2012 (UTC)

Re: "The 'uncategorized' and similar special pages are supposed direct attention ": No, they're supposed to allow wikis to direct attention . The existence of Special:UncategorizedTemplates is not evidence of a policy that all templates should be categorized. Furthermore, even if we have a policy that most templates should be categorized, the existence of Special:UncategorizedTemplates does not mean that it is the only way, or even the best way, to find templates that violate that policy. But anyway, the simplest solution here is probably to disable the Special:UncategorizedXXXXX pages, so that you can stop badgering everyone about them. ;-)   —Ruakh_TALK 14:01, 27 July 2012 (UTC)

Yes, arguing that the existence of special:uncategorizedtemplates is a reason for us to categorize templates is letting the tail wag the dog, something I think you of all people, DCDuring, would not argue for.​—msh210℠ (talk) 16:17, 27 July 2012 (UTC)

I think the state of template space, between lack of categorization and lack of documentation, is a risk to the project. It puts the project in the position of being overly dependent on special runs on dumps, on accidental learning, and on template developers' continued participation in the project. We already have specific evidence of developers not staying with the project either voluntarily or not.

As everyone seems to find this annoying, I'll let others deal with the situation as best they can. DCDuring TALK 16:39, 27 July 2012 (UTC)

Disabling those Special pages? Please, that's a ridiculous idea. I have other things to get sorted at the moment, like trying to sort out my bot, but I wouldn't mind working to get all the templates categorised. Heck, maybe when I get the other stuff for my bot sorted (and approval via a vote) I could use it to categorise all those templates, at least the script and language code subtemplates. User:PalkiaX50 ^{talk to meh} 18:20, 27 July 2012 (UTC)

Re: "I wouldn't mind working to get all the templates categorised": Has anyone asked you to? The problem here is not that there's no one willing to do it, but that it's not clear how and whether it should be done. —Ruakh_TALK 18:30, 27 July 2012 (UTC)

Well I think it should be done; like I kind of said above, I don't see a problem with categorisation for categorisation's sake. The maintenance pages would be just fine for maintenance purposes if we got all these subtemplates and other things off the maintenance list. User: PalkiaX50 ^{talk to meh} 18:37, 27 July 2012 (UTC)

I'd mind having extra wikitext added to those pages just to categorize them. Having the enormous amount of subtemplates with useful data cleanly accessible through the API without any extra wikitext is very useful. To give an example: The translations adder script makes use of the langrev subtemplates in order to make the autocomplete system work and retrieve the language's language code at the same time. When a user types a letter into the language box, a request is sent containing the input so far, and the response is a clean JSON object containing the results of Special:PrefixIndex/(letters typed so far) and the content of the page(s), so that if "Engl" is typed, the script receives the data indicating that there is a page at Template:langrev/English, and it contains the content "en", and that's it. It wouldn't be too complicated to just load the additional content and skim off the noinclude tags every time, but there isn't really any reason to add all that, and overcomplicate the useful mass of data on language scripts, names, and families. Adding categorization there doesn't actually help anything. --Yair rand (talk) 03:06, 30 July 2012 (UTC)

Almost one month has passed and no reply to this yet. I leave it here both for the record (instead being only in an obscure IP discussion page), to inform the community the indirect way conscious vandalizers are encouraged (they only have to consistently vandalize from new ranges to get them blocked for the rest of users) in this site and to see if there will be some informative reply here. I do not know if this IP will also be blocked after adding this text. If so, I'll leave my comments, if any, in my IP's talk page. Regards. --95.20.46.174 18:49, 29 July 2012 (UTC)

A week or two ago, I noticed that Lupin popups, a PREF also called navigation or preview popups, were not working as they used to. Before, when I hovered over a link, I would see a popup containing the language header and definitions of the word. Curiously, options like "history" and "un|delete" and "un|watch" would sometimes be all enumerated at the top of the popup, other times compacted into a dropdown menu at the top of the popup: but a stripped-down version of the page content/text would be in the popup in any case. Now, however, I see only the language header (and the dropdown-menu version of the "actions"); the popup no longer shows me any of the content of the page (i.e. any of the term's definitions). This didn't bother me at first, but it inconveniences me when I patrol: I can no longer hover over the link in trans-adder summaries (t+es:atado (Assisted)) to quickly check that the addition is accurate. Popups seem to be continuing to work as before on en.WP. What has reduced their functionality here? How can the functionality be recovered? - -sche (discuss) 05:29, 30 July 2012 (UTC)

Still fine for me. Is it something in your custom .js (have you made any related changes there recently)? --Μετάknowledge^{discuss/deeds} 05:36, 30 July 2012 (UTC)

My common.js is empty, and I don't have any other .js pages. My skin is Vector, and the only gadgets I have enabled are nav popups, accelerated form-of creation links, and patrolling enhancements. (PS if anyone wants to suggest other cool ones I should turn on, feel free.) If I hover over, say, ], I see Metaknowledge or Μετά knowledge? Or maybe knowledge is my meta... — but if I hover over ], all I see is English (no definitions). This is the case in Firefox. - -sche (discuss) 05:59, 30 July 2012 (UTC)

Aha! In Opera, the problem does not appear: if I hover over ], I see what I expect, a striped version of the page: An expression of delight or enthusiasm / 1954, Oren Arnold, The Golden Chair, Elsevier, page 249, / He patted his lap for her to sit on. Hot dog, I said to myself; settin' on his lap! / 2006, Robert B. Parker, Hundred-Dollar Baby, Putnam, →ISBN, page 140, / "Anybody with an alibi they can tell me?" I said. / No one said anything. / "Hot dog!" I said. / A food consisting of a frankfurter, or wiener, in a bread roll, usually served with ketchup, mustard, relish, etc. - -sche (discuss) 06:03, 30 July 2012 (UTC)

I get this problem occasionally in Firefox, not regularly or predictable AFAICT. —Angr 22:03, 30 July 2012 (UTC)

Hello,

How do I add a request with a code for missing links in entries?

Greetings HeliosX (talk) 08:39, 30 July 2012 (UTC)

I think the first thing is to clarify your request. Mglovesfun (talk) 10:03, 30 July 2012 (UTC)

I meant to sign in an entry that as example a descendant is missing.

Greetings HeliosX (talk) 12:32, 30 July 2012 (UTC)

I for one still don't understand; does anyone else? Mglovesfun (talk) 17:04, 30 July 2012 (UTC)

@Mglovesfun: I think I understand. Imagine that you're at the entry for an Old Norse word, and you know that the word has a reflex in Modern Swedish, but you don't know what that reflex is. HeliosX is asking if there's a template (à la {{rfinfl}}, {{rfe}}, etc.) that would take sv as a parameter and alert a Swedish editor that some link needs to be added to this entry. —Ruakh_TALK 18:27, 30 July 2012 (UTC)

@HeliosX: The general way to request language-specific attention is the {{attention}} template: {{attention|sv|Can someone add the Swedish descendant?}} —Ruakh_TALK 18:27, 30 July 2012 (UTC)