I notice that this template doesn't check for the existence/validity of the two mandatory unnamed parameters (that is for the less initiated, {{t|fr|mot}}, fr would be the first, mot would be the second). I recently added to {{IPA}}, {{X-SAMPA}} and {{enPR}} a check to see if {{{1|}}} was provided, this was really successful as it caught about 30 or so main namespace entries that did not actually include a pronunciation. The difference is... these templates are so widely used and often multiple times on the same page, if not dozens of times, or over 100! I wonder if we also want to follow the French Wiktionary and categorize translations using hidden categories. Possibly that's a step too far. In the example above, {{t|fr|mot}} would categorize into Category:Translations into French (or whatever title we chose). Mglovesfun (talk) 11:50, 1 May 2012 (UTC)

Categorizing entries that have translations into French would certainly be a step too far. I don't see the harm (and see some benefit) in categorizing when missing either or both parameters, though. Also those that are missing the transliteration parameter and are in languages that require it. However, because there can be so many translations on a page, any such tagging should take a visible form (so it can be spotted in the page), not just categorization. I suggest that {{attention}} be used for this purpose (especially because it's customizable by language if {{{1}}} is set), and that anyone who wishes to see the attention-seeking notification on the page follow the instructions at template:attention to do so. I think that'd be the best way. Code for {{t}} could then be as follows:

1. Change {{#if:{{{tr|}}}| ({{{tr}}})}} to {{#if:{{{tr|}}}| ({{{tr}}})|{{#switch:{{{sc|{{{{{1}}}/script}}}}}|Latn|None|=|{{attention|{{{1}}}|id=t-no-tr|needs transliteration in the tr parameter}}}}}}
2. Add {{#switch:{{{1|}}}{{{2|}}}|{{{1|}}}={{attention|{{{1}}}|id=t-no-2|missing translation}}|{{{2|}}}={{attention|en|no language specified|id=t-no-1}}]}}

or similar.​—msh210℠ (talk) 16:57, 1 May 2012 (UTC)

For such a widely used template you need to keep in mind the performance effects this will have on pages like water. -- Liliana • 17:09, 1 May 2012 (UTC)

I agree completely and was just about to amend my suggestion by adding a recommendation that someone who knows about template performance would have to greenlight (or modify and then greenlight) such a change in light of {{t}}'s heavy use.​—msh210℠ (talk) 17:11, 1 May 2012 (UTC)

I noticed that {{m|f}} and {{f|n}} and such display ok: m or f; f or n. But when {{n}} is the first, it doesn't work quite the same: n or m; n or f. The word 'and' is missing. Does anyone know why that happens and how it can be fixed? —CodeCat 20:40, 3 May 2012 (UTC)

No I don't know, and yes, presumably it can be fixed, though I don't know how. Mglovesfun (talk) 22:06, 3 May 2012 (UTC)

Suggestion to be taken with low expectations: how about we replace the code in {{n}} with the following: <span class="gender n" title="neuter gender">''n<span class="gender-period">.</span>''</span>{{#switch:{{{2|}}}|n|c='',''|#default={{#switch:{{{1|}}}|f|n|c={{{sc|}}}<span class="serial-and"> ''and''</span>}}}}{{#if:{{{1|}}}| }}{{{{#if:{{{1|}}}|{{{1}}}|ns:0}}|{{{2|}}}|{{{3|}}}|{{{4|}}}|sc=<span class="serial-comma">'',''</span>}}<noinclude>{{documentation}}</noinclude> --Μετάknowledge^{discuss/deeds} 03:59, 4 May 2012 (UTC)

Judging from the way the templates are written, the design assumption seems to have been that the order is supposed to be {{m}}/{{f}} > {{n}} > {{c}} > {{s}}/{{p}} (with {{m}} and {{f}} being allowed to appear in either order; and with neither {{s}} or {{p}} being allowed to appear first if anything appears second). —Ruakh_TALK 04:28, 7 May 2012 (UTC)

I just got kicked off the server for about five minutes, and now every page I edit gets added to my watchlist, and I have to remove them all manually, or not at all. Mglovesfun (talk) 22:10, 3 May 2012 (UTC)

That happened to me as well but there is a setting in the preferences to change that. —CodeCat 22:12, 3 May 2012 (UTC)

Go to My preferences -> Watchlist and uncheck "Add pages I edit to my watchlist", which got enabled for everyone for some reason sometime in the last 12 hours. Nadando (talk) 22:13, 3 May 2012 (UTC)

Weirdly, a couple of weeks ago I got three e-mails telling me that three of the pages on my watchlist had changed. I have never enabled that e-mail option and it wasn't ticked when I logged in and checked. Temporary glitch apparently. Equinox ◑ 13:47, 14 May 2012 (UTC)

Same here. DCDuring TALK 15:10, 14 May 2012 (UTC)

Could someone who is knowledgeable please add 'singular' as a possible checkbox to the automated translation table script? Currently it only shows plural as an option, but sometimes it's also useful to explicitly show that a form is singular in contrast to a plural. —CodeCat 13:38, 5 May 2012 (UTC)

Also, when one types in 'Nepalese', nsp comes out. Nepalese should in fact produce ne. (See {{nsp}}, {{ne}}). --Μετάknowledge^{discuss/deeds} 16:07, 6 May 2012 (UTC)

That's controlled through the sub-templates of {{langrev}}. The only template beginning with "Template:langrev/Nepalese" is "Template:langrev/Nepalese Sign Language". If you create Template:langrev/Nepalese with the content "ne" this should be fixed. --Yair rand (talk) 21:21, 6 May 2012 (UTC)

Thanks! --Μετάknowledge^{discuss/deeds} 21:45, 6 May 2012 (UTC)

That might be a bad idea, as many occasional contributors will enable this checkbox for all singular forms they add, just like many people already add gender for adjectives. Matthias Buchmeier (talk) 11:56, 7 May 2012 (UTC)

NB {{head}} already allows g=p, g=s, g=inv, none of which are genders, it's just not helpful in terms of usability to distinguish between them in this template. It doesn't mean that Wiktionary is saying there is no distinction between gender and number. Mglovesfun (talk) 11:59, 7 May 2012 (UTC)

@Matthias: I'm sure occasional contributors almost never click the "more" dropdown, which is where I presume singular "gender" would go. --Μετάknowledge^{discuss/deeds} 23:21, 7 May 2012 (UTC)

I added a new sense with a context template to purple, but now it added the page to two new categories, Category:Netherlands English and Category:Belgian English. That's obviously wrong but it seems there is no way to include the context labels (which are perfectly legitimate in this case) without the categories. —CodeCat 17:12, 8 May 2012 (UTC)

If your goal is not to categorize at all, then you could write {{context|Netherlands and Belgium}} or {{context|<nowiki/>Netherlands|and|<nowiki/>Belgium}} rather than {{context|Netherlands|and|Belgium}}. (That said, you might consider something like {{context|in reference to the Netherlands or Belgium}} instead, since otherwise it looks like we're saying that this sense is used in Belgium and the Netherlands.) If your goal is to categorize in Category:en:Netherlands and Category:en:Belgium, then . . . well, same thing I guess, and then add the categories by hand. —Ruakh_TALK 17:25, 8 May 2012 (UTC)

Ok that would work I think. But now that we're looking at ways to improve context labels, this is something to look into... —CodeCat 17:31, 8 May 2012 (UTC)

Well, what do you have in mind? I don't think the context templates are misbehaving here, are they? You told them that this word is an English word found only in Belgium and the Netherlands, and they categorized accordingly. —Ruakh_TALK 19:07, 8 May 2012 (UTC)

Not strictly no, but how do we make a difference between something that is used in a place and something that's about a place? —CodeCat 19:08, 8 May 2012 (UTC)

{{context|in reference to The Netherlands and Belgium}}. Mglovesfun (talk) 15:57, 9 May 2012 (UTC)

Can we please categorize uncategorized rhyme pages? In trying to eliminate r in favor of ɹ in Rhymes:English... pages, I used Category:English rhymes. I have no way of finding ones which aren't categorized. Mglovesfun (talk) 15:59, 9 May 2012 (UTC)

A way: special:prefixindex:rhymes:English:.​—msh210℠ (talk) 17:53, 9 May 2012 (UTC)

You mean Special:PrefixIndex/Rhymes:English: (with a slash instead of a colon). —Ruakh_TALK 18:23, 9 May 2012 (UTC)

I do indeed.​—msh210℠ (talk) 18:36, 9 May 2012 (UTC)

But how to I check which are categorized and which aren't? Mglovesfun (talk) 20:43, 9 May 2012 (UTC)

If you could make a list of all entries in the category, and a list of all pages with the prefix, then you could 'subtract' the latter from the former. AWB can do that for you I think, if you save the lists to a text file. —CodeCat 20:45, 9 May 2012 (UTC)

I've been talking some with Takasugi Shinji about how to denote pitch accent in Japanese entries. 内 (uchi), for instance, has two distinct pitch patterns corresponding to separate senses of the word, but all senses share the same etymology. I thus kept one Etyl header and created two Pronunciation headers, with numbers to differentiate, much as multiple etyls for a single lemma take numbers.

Kassad-bot recently flagged the entry with {{rfc-pron-n}}, and in the process of figuring out what that meant, I had a look at record, which similarly has different pronunciations that are specific to certain senses. The record entry gives two separate etyls with the unnumbered pronunciations under these. This is one way around the dictum described at Category:Entries_with_Pronunciation_n_headers (i.e., "entries that use headers with "Pronunciation" and a number ... are not "legal"; not allowed by WT:ELE"), but it seems hacky and cludgy, since the two separate etyls both give exactly the same information.

Do we really want to duplicate etyl headers just to avoid having headers like ===Pronunciation 1===? What makes ===Etymology 1===, ===Etymology 2=== superior to numbered pronunciations, even when both etyls give identical information? I'm quite in the dark here, and puzzled by what I'm finding. -- Eiríkr Útlendi │ Tala við mig 20:32, 14 May 2012 (UTC)

I think it's silly to forbid these headers when they can make an entry more logically structured. It also forces us to assume the etymologies of two differently-pronounced words are different, and therefore that something is known about them, which isn't always true. —CodeCat 20:59, 14 May 2012 (UTC)

The wording at Category:Entries_with_Pronunciation_n_headers is rather misleading. In my opinion, something on Wiktionary is only "illegal" if it is specifically proscribed, which I don't believe the numbered pronunciation headers are, though neither have we come up with a consensus to use them. It is thus up to the discretion of each individual editor to do as they see fit. However, Kassad-bot must flag all entries which use headers which are not specifically allowed, which is totally reasonable for it to do. When we finally do come up with a specific policy on this topic, the cleanup category might well come in very handy. In any case, I suggest doing the entries as you see fit, even if that includes numbered pronunciation headers, and don't let the bot's categorizing bother you. I know I use numbered pronunciation sections from time to time, and I'll be damned if I'll let anyone else stop me until we have a better solution (inventing multiple etymologies when only one exists is not a better solution). -Atelaes λάλει ἐμοί 21:00, 14 May 2012 (UTC)

Part of the reason for {{rfc-pron-n}} is that this is not yet a solved problem: Robert Ullmann felt strongly that this should be forbidden, but he failed to garner a clear consensus. But in this specific case — it's my understanding, and please correct me if I'm wrong, that pitch accent is not a uniform attribute of Japanese, but rather, one that depends on the region, with different dialects often having it in different positions in a word, and some dialects not having it at all. (And even among speakers who do have the distinction exactly as represented in the entry, I wonder if all of them will be consciously aware of it?) So it doesn't seem to me that it's a good basis for splitting up an entry. Instead, I think it might be better to do something like:

===Pronunciation===
* ''noun'':
*: {{IPA|/ɯ˩.tɕi˥/|lang=ja}}
* ''(Kansai) pronoun'':
*: {{IPA|/ɯ˥.tɕi˩/|lang=ja}}

(By the way, this is neither here nor there, but FYI: I believe the "l" in "etyl" means "language". "Etymology" alone is just "ety" or "etym".)
—Ruakh_TALK 21:05, 14 May 2012 (UTC)

I do think "Pronunciation n" headers are the way to go here. venit#Latin is another example: two inflected forms of the same verb, spelled the same, pronounced differently. read#English shows the other option: one Pronunciation header that lists both pronunciations with labels explaining which pronun goes where. (And I thought "etyl" stood for "etymology link"). —Angr 21:37, 14 May 2012 (UTC)

Actually, upon further reflection, I realize the Latin case is different because the pronunciations also correspond to different head lines: venit and vēnit. In cases like that, "Pronunciation n" headers really are all we can do, I think; cases like 内 and read can be handled with a single Pronunciation header that lists multiple pronunciations. But do we want to be that inconsistent? —Angr 21:42, 14 May 2012 (UTC)

As the original author of {{etyl}}, I was thinking etymon language. I don't know how authoritative that should be considered. -Atelaes λάλει ἐμοί 21:48, 14 May 2012 (UTC)

@Angr: Re: "I do think 'Pronunciation n' headers are the way to go here": Obviously you're not under any obligation to justify your opinion, but I think it would be helpful if you did. I gave 1½ reasons that I thought they weren't a good idea for Japanese terms differing only in pitch accent; do you disagree with those reasons? Or is there some other consideration that you think overrides the reasons I gave? Without that explanation, I think your comment isn't nearly as useful as it might be. —Ruakh_TALK 23:22, 14 May 2012 (UTC)

Sorry, I thought my reasoning was clear. You were talking about this specific Japanese case only; I was talking more generally. There are cases like Latin ] where the two pronunciations correspond to two different headlines, and in those cases I think separate "Pronunciation n" headers are the most efficient way of presenting information. Then, for consistency, we should probably use "Pronunciation n" headers in other cases, like English ] and Japanese ], where otherwise two listings under a single "Pronunciation" header would have been possible. But perhaps consistency isn't a good enough reason to separate the pronuns of ] and ]. I don't really see what the low profile of pitch accent in Japanese has to do with it, unless you're saying we shouldn't be transcribing it at all. —Angr 06:09, 16 May 2012 (UTC)

Ah, I understand what you're saying now, thank you.   Re: "I don't really see what the low profile of pitch accent in Japanese has to do with it, unless you're saying we shouldn't be transcribing it at all": Nah, I was just saying that it's not a good basis for such a high-level split. Analogously: sometimes a difference between dialects is big enough to warrant separate L1 headers, like ==English== vs. ==Scots==, but sometimes it's not. Even when it's not, we still tag senses with dialect information, we just no longer use it to carve up entries. Likewise, sometimes a difference between pronunciations is a good way to split up an entry, and sometimes it's not; but even when it's not, we should still indicate the pronunciations. —Ruakh_TALK 15:05, 16 May 2012 (UTC)

Well, I'm all in favor of flexibility in the application of our standards and deciding on a case-by-case basis how best to present things. —Angr 18:13, 16 May 2012 (UTC)

(After edit conflict)

@Ruakh: Generally good points. For 内, the entry was already split by POS, with the pronunciation difference matching that split, but yes, insofar as I understand the phenomenon, pitch accent varies by region. I've been told that it's used to distinguish between homophones, such as 花 (hana) "flower" and 鼻 (hana) "nose", and that some pitch accents are specific to certain regions (such as the Kansai pronunciation listed at the moment at 内). In the interest of getting a better picture of the back story, I'm glad to learn about Ullmann's stance on numbered pronunciations, but I've found that he also felt rather strongly about some things where I feel the opposite at least as strongly, so the simple fact of his opposition, without more detail, doesn't necessarily signify all that much to me.

The biggest factors weighing against adding pitch accent seem somewhat more practical -- regional variation, and lack of information. I can find very little information in Japanese dictionaries about pitch in general. All the ones I've seen at least mention in the introductions that pitch accent exists, and some entries will even clearly mark it, but most entries don't include it at all. (This is similar to the situation in JA dictionaries with regard to etymologies.) There are specific dictionaries that focus on pitch accent, but these special editions exist precisely because most dictionaries don't include this information.

Where pitch accent results in different meanings, it makes more sense to me to group the defs under the relevant pronunciations. Keeping all pronunciations in one place separates them from the corresponding defs, and I find this layout generally harder to understand compared to layouts where defs are grouped right under the relevant pronunciation. While an exaggeration, imagine the usability issues for get or hip if the etymologies were given all together at the top of the entries.

(And thank you for the FYI: I had run across examples of forum posts using etyl as if just a shorthand for etymology, but apparently I misunderstood.) -- Eiríkr Útlendi │ Tala við mig 22:44, 14 May 2012 (UTC)

Re: "the simple fact of opposition, without more detail, doesn't necessarily signify all that much to me": Er, sorry, I guess my comment wasn't very clear. I didn't mean for Robert's opposition to "signify" anything — I actually disagreed with him about this issue, and have used ===Pronunciation n=== headers in a number of Hebrew entries — I was just trying to explain where {{rfc-pron-n}} came from: Robert created it and Category:Entries with Pronunciation n headers, and created the bot that, among many other features, adds it to entries. (Liliana now runs that bot, under a different username, but I don't think she's made any specific decision to retain the {{rfc-pron-n}} feature; rather, it's just that she took all of the bot code, and hasn't made any specific decision to remove that part.) —Ruakh_TALK 23:22, 14 May 2012 (UTC)

(Not sure how to indent, so simply starting anew) I tend to think that using Pronunciation n headers is superior to denoting multiple pronunciations within a single Pronunciation header for organization and ease of use. If a word is pronounced differently (even if not consistently, i.e. only in certain dialects), I would interpret that to mean that the language makes some kind of fundamental division within that word. We convey that division infinitely more clearly to our readers with multiple headers. Having to go back and forth between a header (and its various descriptions) and the part of speech header, trying to line up what matches up with what is simply a travesty of layout that I would prefer to avoid inflicting on our readers. I would also take such a phonetic distinction as a red flag that we should expect other items, such as parts of speech, semantic relations, etc. to be similarly divided, which is of course more easily done with multiple headers. -Atelaes λάλει ἐμοί 23:38, 14 May 2012 (UTC)

@Atelaes: How would you handle a case like contract, where some speakers pronounce one verb sense like the noun, and other speakers pronounce it like the other verb senses? Would we divide the entry into three pronunciation sections, even though (SFAIK) no speaker actually uses three different pronunciations? —Ruakh_TALK 00:47, 15 May 2012 (UTC)

I think I have to concede defeat on this one, 'cuz I'm not really sure. This is of course why we haven't come to a consensus on the issue, as some entries are really, really sticky. However, as I think about it....I wonder if it might be a good idea to separate the "legal agreement" verb sense from the other verb senses, as I suspect it's different from them in ways beyond pronunciation. We'd have to do a rather thorough historical investigation to be sure, and this word's etyma seem equally convoluted. However, I retain my suspicion that the different pronunciation signals different other things. -Atelaes λάλει ἐμοί 01:02, 15 May 2012 (UTC)

I do agree with you that the different pronunciation signals different other things, I'm just not sure that ===Pronunciation n=== is always the best way to present those things to our readers. The existence of different past-tense forms can also signal other differences, but I don't think we'd want to split ] up with ====Verb==== headers nested under ===Conjugation 1=== and ===Conjugation 2===. —Ruakh_TALK 02:04, 15 May 2012 (UTC)

Quite true. Perhaps what it ultimately comes down to is that we don't have a good format for adding sense-specific information of any kind. Putting translations and semantic relations below the whole chunk of definitions and then using {{sense}} and glosses is terrible, but we do it because we don't have any other option. Ultimately, I think that what we really need is something like hidden quotes, but with more, space for semantic relations, translations, grammatical notes, etymological clarifications, etc. I seem to recall that Conrad thought along the same lines, but never really produced any concrete proposals (with the exception of changing our format to have definitions as headers, which looked so insidiously ugly that it almost caused me to find religion so I would have a proper deity to call curses down upon it with). -Atelaes λάλει ἐμοί 02:37, 15 May 2012 (UTC)

I think the verbal forms of contract that are pronounced differently have slightly different etymologies: there's the directly inherited verb form that's accented on the final syllable, and there's the form derived from the noun, which takes its stress pattern from its parent. It all goes back to the same Latin participle, but the route from there to the present is different. Chuck Entz (talk) 05:41, 15 May 2012 (UTC)

• What I get from this thread is that there are some entries that may or may not have sense-specific pronunciations, where grouping senses under ===Pronunciation n=== is messy at best (such as contract); meanwhile, there are some entries where senses seem to pretty clearly and consistently match specific pronunciations, where grouping senses under ===Pronunciation n=== could be sensible (such as record).

The loose consensus suggests that the wording at Category:Entries_with_Pronunciation_n_headers that "entries that use headers with "Pronunciation" and a number ... are not "legal"; not allowed by WT:ELE" is overly strong and might need changing. Is this correct?

WT:ELE doesn't address the issue of multiple pronunciations with enough specificity to provide a clear guideline. There appear to be multiple approaches, such as at record, reject, read, contract. Is there enough agreement on dos and don'ts to tighten up the description at Wiktionary:ELE#Pronunciation? Or, is the current ad hoc approach acceptable? -- Eiríkr Útlendi │ Tala við mig 15:56, 15 May 2012 (UTC)

I have changed the wording to be more neutral. Please take a look and change it/comment here as you see fit. I suspect that wording could be added to ELE, which, while not completely describing the details of proper use of Pronunciation n headers, could give some pointers, links to entries where they are clearly well used, as well as links to entries where their inclusion is problematic. I wonder if it might be a good idea to raise a BP thread on the topic to get wider input beforehand. -Atelaes λάλει ἐμοί 00:24, 16 May 2012 (UTC)

The new wording in the cat header looks good to me. A BP thread might not be a bad idea. -- Eiríkr Útlendi │ Tala við mig 02:30, 16 May 2012 (UTC)

I believe there is a way to distinguish in terms of link colors between entries which have a desired language section, and ones that don't. For example {{l|fr|vacant}} will show in one color if vacant#French exists, and another if it doesn't. Mglovesfun (talk) 11:35, 15 May 2012 (UTC)

Not only can that be done, but in fact, it already has been done! It's an optional feature, and it works by finding all blue section-links on the page, asking the API if the linked page belongs to any matching category (in this case Category:French adjectives), and if not, marking the link with class="partlynew". To turn it on, you can click the "Color translation links orange instead of blue if the target language is missing on an existing page" checkbox at WT:PREFS, or you can add User:Yair rand/orangelinks2.js directly to your JavaScript. —Ruakh_TALK 13:58, 15 May 2012 (UTC)

In case I was unclear, I meant 'currently possible' not 'theoretically possible'. Whatever, I've got my answer. TY. Mglovesfun (talk) 18:49, 16 May 2012 (UTC)

That box in WT:PREFS is unclickable for me (greyed out). SemperBlotto (talk) 18:53, 16 May 2012 (UTC)

So, there are actually two separate-but-similar options, and my previous comment mixed them up:

• "Color translation links orange instead of blue if the target language is missing on an existing page", a.k.a. User:Hippietrail/ajaxtranslinks.js
  • Only applies to links in translations section.
  • Shows up at WT:PREFS as an unclickable/grayed-out checkbox unless you've got Gecko 1.8.1+, such as Firefox 2+.
• "Color links to language sections that don't exist orange where they would otherwise be blue", a.k.a. User:Yair rand/orangelinks2.js
  • Applies to all links.
  • Is marked as experimental, and may not work in all browsers.
  • Is always clickable at WT:PREFS, even if it won't work in your browser.

—Ruakh_TALK 19:07, 16 May 2012 (UTC)

It seems to me that those two settings really do the same thing and should probably be merged... —CodeCat 19:14, 16 May 2012 (UTC)

I'm trying to clear out Wiktionary:Requested entries (French)/a (and so on), that's what prompted my question. Mglovesfun (talk) 20:37, 16 May 2012 (UTC)

And it's not working, does it only work in the main namespace? Mglovesfun (talk) 09:25, 17 May 2012 (UTC)

It's disabled on all but the main namespace, as I didn't think it would really be useful in other namespaces. Should I also enable it in the project namespace? Or maybe on all namespaces? (There are 249 orange links on that page, by the way.) --Yair rand (talk) 21:31, 17 May 2012 (UTC)

Maybe main, project, index, and ws?​—msh210℠ (talk) 16:15, 18 May 2012 (UTC)

Don't the index pages get orange links built in, added by Conrad.Bot? I've changed the script to activate on main, project, and Wikisaurus pages. --Yair rand (talk) 17:44, 20 May 2012 (UTC)

I'm just brainstorming here, but is there some way we could set up to put a unique, non-displaying tag in the sense line, so that we could refer to that sense elsewhere in the entry without having to know what number it is? Let me illustrate, using the verb "foo":

===Verb===

{{en-verb))

# ]

# ]

===Synonyms===

* ] ()

* ] (whatever it is 2])

If we could make this work in an easily-understood way, it could take a lot of the randomness and chaos out of translation sections, etc. Chuck Entz (talk) 14:07, 17 May 2012 (UTC)

Do you mean like the {{senseid}} template? It doesn't display anything, but it attaches an anchor to specific senses, allowing them to be linked to. --Yair rand (talk) 21:33, 17 May 2012 (UTC)

Just so you know, there's a new limit on "expansion depth". I don't know what it is, so if someone does, that'd help.

The limit is set to "40". water uses "24".

If performance is to be improved, this should probably be reduced, no? -- Liliana • 17:51, 18 May 2012 (UTC)

It's actually not a new limit; according to mw:Manual:$wgMaxPPExpandDepth, we've had it since 1.13.0, so, almost four years. What's new is that it's easier to see how close a page comes to hitting that limit.

I don't know much about the guts of PHP, but I don't think that this is likely to have much impact on performance. There are good reasons for putting a firm bound on the depth of the call stack, but as long as you're within that bound, I don't think that shortening the call stack will really make a difference.

By the way, I wouldn't expect ]'s value to be atypical, since this figure shouldn't correlate very strongly with page size: it's a measure of recursion, not iteration. I checked out a number of pages, and got these results:

• 17: ], ], ], ]
• 19: ]
• 23: ], ], ]
• 24: ], ], ], ]
• 25: ]
• 26: ], ]

(The 25 and 26s are a nice summary of how murderously complex Daniel Carrero's templates are, but again, I don't think the numbers are a problem in and of themselves.)

—Ruakh_TALK 18:34, 18 May 2012 (UTC)

While we're talking about Daniel's overly complex templates... 33: ]]. This is why I advocated getting rid of {{list}} (but that's for another topic). -- Liliana • 18:40, 18 May 2012 (UTC)

Oh, and built like a brick shithouse exceeds it. That is a problem, a big one actually. -- Liliana • 18:42, 18 May 2012 (UTC)

I believe that that one resulted from a combination of {{context}}'s recursiveness and the {{langprefix}} ugliness — and possibly other things as well. (I don't think there's any way to get an explicit stacktrace, so it's hard to be sure.) I've fixed it hackishly for now . . . but it's yet another reason I should resume work on the {{context}} rewrite that I started proposing last month before I went offline. —Ruakh_TALK 19:05, 18 May 2012 (UTC)

What is expansion depth? Mglovesfun (talk) 12:34, 20 May 2012 (UTC)

For the general (non-MediaWiki-specific) concepts, see w:Call stack, w:Recursion (computer science), and w:Nesting (computing). At MediaWiki — the expansion of parser-functions operates recursively; for example, to expand something like {{#if:1| {{#if:2| {{#if:3| {{#if:4| {{#if:5| {{#if:6| {{#if:7| yay! }} }} }} }} }} }} }} (expansion depth 8), the software invokes a bit of code that understands #if: (for the #if:1), and then that bit of code calls back to the software to expand the 'true' branch. So then the software invokes the same bit of code again (because of #if:2). Eventually a deeply-nested call returns yay!, and that gets passed all the way back out; but in the meantime, there are seven different "active" calls to the code that understands #if:. Something similar happens when a template is used in generating a template-name to be called by another template; for example, {{ {{ {{foo}} }} }} has an expansion depth of at least 4 (more if {{foo}} does things that increase it). And <ref> and <nowiki> and the like also work recursively, but I don't think any of those are amenable to nesting, so they would only ever increase the expansion depth by +1, and aren't the problem here. —Ruakh_TALK 18:18, 20 May 2012 (UTC)

I have a bot/AWB job that I would really appreciate done. Every time the string English appears under the L2 header ==Tok Pisin== in the main namespace, it should be converted to {{etyl|en|tpi}}. The reason for this is that I added probably 100 entries with English etymologies and didn't bother to mark it correctly at the time. I hope somebody can help me clean up these old mistakes I made as a newbie. Thanks --Μετάknowledge^{discuss/deeds} 23:33, 19 May 2012 (UTC)

I'd say these are suboptimal rather than mistakes, the {{etyl}} template is recommended, but not mandatory. Mglovesfun (talk) 12:33, 20 May 2012 (UTC)

Not every time; if nothing else, there are cases like banana#Tok Pisin, which contains the definition-line # ]. I've created User:Metaknowledge/Tok Pisin English with a list of Tok Pisin entries where, I believe, at least one instance of English really does need to be changed to {{etyl|en|tpi}}; but even these entries will sometimes also have instances of English that don't need to be changed (pen#Tok Pisin, for example, has the definition-line # ]). —Ruakh_TALK 13:00, 20 May 2012 (UTC)

@Mglovesfun: Not only suboptimal, but it makes Category:Tok Pisin terms derived from English very misleading in a language that was originally an English pidgin.

@Ruakh: That doesn't sound like much of a problem - the list of words that are identical in English and Tok Pisin that Wiktionary has isn't very long, and those ones could be excluded (I would fix them manually).

I don't know exactly what you need to solve the problem, but I still think it is worth doing, and I will try to help however I can. Thanks --Μετάknowledge^{discuss/deeds} 04:18, 21 May 2012 (UTC)

So, I take it you don't want to fix them manually? —Ruakh_TALK 17:04, 21 May 2012 (UTC)

I don't, but if nobody wants to do it in an automated fashion, I'll have to. I am willing, but of course I'd rather not. --Μετάknowledge^{discuss/deeds} 21:01, 21 May 2012 (UTC)

O.K.; I'll see if I can give it a shot sometime in the next few days. —Ruakh_TALK 21:26, 21 May 2012 (UTC)

Thank you so much. I'd like to know once it's done. --Μετάknowledge^{discuss/deeds} 21:29, 21 May 2012 (UTC)

 Done. It required a lot more manual intervention than you thought, but at least I was able to make good use of JavaScript to make it go faster. By the way, how come pela is described as "cognate with" English fella, rather than "from" it? —Ruakh_TALK 18:28, 24 May 2012 (UTC)

Thank you so much!

As for (deprecated template usage) pela, that is one of the rather few Tok Pisin terms we have that I did not create. It needs some cleanup, and you are quite correct that it is not a cognate so much as a descendant. --Μετάknowledge^{discuss/deeds} 21:47, 24 May 2012 (UTC)

Greeting, editors. I have not been contributing here long, but I have been a language geek and computer professional for many years (just to get background out of the way).

One of the things I thought needed doing was templates for Old Irish nouns and mutations, but I ran up against what looks like an insurmountable technical problem.

Doing sga nasalisation or ga eclipsis is easy, as you can see at User:Catsidhe/sga-nasal. Take the first letter with {{str left}} or padleft:, and use a switch to determine what prefix to stick on the supplied word. This is even easier when eclipsis generally doesn't get capitalised even in an all-caps or titlecase context.

Lenition, in Old Irish or Modern, is another question, as it requires the first letter to be replaced, either with a single letter (eg., sga f -> ḟ), or two (ga t -> th). And that doesn't seem to be possible at all with the current setup.

When I found {{str left}}, I attempted to use the obvious {{str right}}, but it had been deleted, with no explanation why that I could find, beyond that nothing used it. When I put it back, it didn't work because {{str sub}} was missing, and that has been deleted and locked.

I investigated, and what I found scared me more than a little. {{str left}} is based on the core function padleft:, and does what it says on the tin without any fuss. {{str right}}, on the other hand, relies on {{str sub}}, which uses {{str index}} in a horrible way. Clever, but horrible. (For those who don't know, {{str index}} takes the first n characters of the text, call it A, and the first n-1; B, and then does a switch: against A for "Ba" = a, "Bb" = b, "Bc" = c, ..., "Bá" = á, ... Which needless to say is scary because it's a necessarily huge switch statement, and if a character is not in that list, then it's not going to be returned. {{str sub}} exhaustively runs a huge if-then-elsif-then-elsif-then over each letter in the string in turn, returning each nth character if n >= start_index, and n <= end_index and n <= sting_length and n < arbitrary limit on the length of the function.

I can fully understand why it was removed. It is possibly the pessimal way of executing this function.

And yet, as far as I can see, it is the only way of doing it. (As for both padleft: and padright, the behaviour which returns the first n characters of the 'fill' string is a side effect, and only ever does it from the left-hand side.)

And without even that function available, that makes it impossible to return the rightmost portion of a string, and thus impossible to do a template for initial mutation short of User:Angr's workaround of splitting off the first character when invoking the template, as in the {{ga-decl-m1}} template.

I have seen commentary in the archives that the site admins will not install the StringFunctions Extension. Is there a reason given? Is it worth appealing this?

Else, is there any worth in the idea of suggesting a patch to padleft: and padright: (both of which could be done with a patch to pad in Core Parser Functions) whereby a negative fill length fills in the same way, but when the fill string is to be truncated, it is truncated from the other end and added to the left-end of the fill string, i.e., turn

$finalPadding .= mb_substr( $padding, 0, $length );

into

$finalPadding = mb_substr( $padding, $length, $lengthOfPadding ) . $finalPadding;)

or provide a new pair of parser functions with the same effect.

Note that this would not only make templates for Initial Mutation (which would affect all Celtic languages), it would make {{str index}} simply {{padleft:|-1|{{padleft|{{{1}}}|{{{2}}}}}}}, without either huge server load or the current brittleness.

Failing that, I would petition for the return of functionality to {{str right}}}, as hideous under the hood as it is.

Failing that, I suppose I had better get to creating templates for sga which split off the initial character. But that would mean that automatic entry of declined forms based on the pagetitle would not be possible, which would make entering the data more prone to error.

I agree that having string functions would be a big advantage and I argued for them before. But for now I guess we won't have them, because someone out there thinks it's too cumbersome to provide string functions to a site that deals with thousands of word strings on a regular basis... I realise that splitting it off would be prone to error but you could always check for that: {{#ifeq:{{{firstletter}}}{{{rest}}}|{{PAGENAME}}||]}} —CodeCat 12:27, 20 May 2012 (UTC)

I'm not continuing this to belabour the point, but to actually provide links for the next poor bastard who wanders in and thinks that it is trivial to implement a {{str right}} to match {{str left}}. When people say "we'd like to have this feature, but the admins say no," the actual discussion is here and here. On the second link, Alexandr Ignatiev's comment is absolutely correct, and is what I (through some effort and mental anguish) figured out from first principles myself. The upshot is that {{str left}} is a side-effect of padleft:, and can't be turned off without disabling padleft:. {{str right}}, on the other hand, has been vetoed by the grand high admins, and neither it, nor anything which provides the same functionality at all looks likely to be provided. They don't have to give reasons. In any case, the reasons given so far are irrelevant, insofar as the rebuttals are ignored, and I'm going to try to stop getting angry now.

In the meantime, there is a promise that this sort of functionality will be provided when Lua becomes part of the infrastructure, Any Day Now, at which point it will probably be dictated that string functions aren't allowed in that medium either.

It is impossible, in practice, theory, or spirit, to access the rightmost part of a string. There doesn't have to be a reason, it just is. It won't be allowed, and the admins have, from the conversations in the links above, years since become angry with people even asking for it. It doesn't matter how much simpler it makes anything, how much extra complexity it abstracts away in an instant, how much more efficient it makes simple functions, how mind-boggling it is to be missing this basic functionality. You Can't Have It. Why? Because.

So now a putative couple of weeks work making templates for Old Irish declension tables, which make things simpler for contributor and reader alike, will now turn into an I-don't-know-how-long to figure out a way of making it work anyway. As I see it, the interface for any putative template would have to either forego entire categories of information (such as vocative and dual particles and their induced mutations, the latter of which vary depending on root and gender, and thus would be hugely useful to include), or make the templates twice as complicated, in both structure and invocation.

I don't mean to sound bitter, but I can't help it. This isn't meant to be a cry for help, because I know that everyone here is as helpless about this as I am.

My reason for posting this is so that the next new contributor who wanders in and thinks it's easy has a clear warning: it's not just not easy, it's not possible, and it's not going to be. You can stop beating your head against that wall now.

Ah well, I've got some work to do, it looks like. --Catsidhe (talk) 01:58, 23 May 2012 (UTC)

Full string manipulation will be possible after Lua is deployed. There's a prototype at http://scribunto.wmflabs.org . See mw:Wikimedia_Engineering/2012-13_Goals#Milestones_by_quarter_7 for a schedule. At the moment it is not possible to do complex string manipulation, including accessing the end of a string. --Yair rand (talk) 03:11, 23 May 2012 (UTC)

Lua can't do Unicode. This is a big problem for Irish, as it means it will choke when it encounters special characters like ḟ. -- Liliana • 04:39, 23 May 2012 (UTC)

I assume the developers will find a way to have it do Unicode before it's deployed on Wikimedia sites. Wikimedia is multilingual, and the software is made to work with all languages. --Yair rand (talk) 04:54, 23 May 2012 (UTC)

• @Liliana -- Where do you see that Lua doesn't support Unicode? Re-reading my post at the related thread Wiktionary:Beer_parlour#.24wgPFEnableStringFunctions, I realize I might have sounded combative, but I only intended to convey absolute flabbergasted surprise that the MediaWiki folks would even consider any non-Unicode-compliant coding module. As I posted there, it appears that Lua does indeed support Unicode, albeit in a rudimentary way. So I'm curious -- where are you getting this information that Lua doesn't support Unicode? Is this something specific to the Lua implementation that will be used in MediaWiki deployments? -- Eiríkr Útlendi │ Tala við mig 04:57, 23 May 2012 (UTC)

I wish I still had the link at hand, but it was right at the very beginning when the whole Lua idea was introduced. Among the huge enthusiasm was one keen anonymous user who immediately noticed that Lua cannot handle Unicode as-is. The developers replied with "we'll do something about it", but to me that response felt lackluster, as if they were not taking the whole issue seriously. -- Liliana • 05:13, 23 May 2012 (UTC)

"as if they were not taking the whole issue seriously" -- as much as it grieves me to say it, that seems sadly par for the course, as it were. Ah, well. I can hope.  :-\ -- Eiríkr Útlendi │ Tala við mig 05:34, 23 May 2012 (UTC)

Sorry, but accessing the rightmost part of a string is not "complex string manipulation". Especially when the left-bound equivalent has been possible for time out of mind. That this has been an open and contentious issue for five years or more without resolution is a sign that any hopes that Lua will finally be the fix -- especially when perfectly reasonable previous fixes have been rejected out of hand -- are likely to be optimistic.

TL;DR: I'll believe it when I see it. But I'm not holding my breath. --Catsidhe (talk) 05:49, 23 May 2012 (UTC)

Well, the developers have said for years that the problem with the string-functions is that they're an attempt to turn wikitext into an ugly and inefficient programming language. (The point has also been made that the existence of {{Str *}} on Wikipedia is evidence of this: given a quirky hack to extract a leading substring from a string, Wikipedians invented a huge, ugly, inefficient, unreliable mechanism for extracting non-leading substrings and performing other string manipulations. And started using it widely in situations where it wasn't needed. Given actual string manipulation functions, what would Wikipedians invent? A regular-expressions engine? A recursive descent parser? I had hoped that Wiktionarians would be less reckless and stupid, but my hopes were dashed when {{str index}} was undeleted.) When Tim Starling merged the string-functions into ParserFunctions and turned them off by default, he explicitly pointed people at Lua as a better language. (See http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/ParserFunctions/ParserFunctions.php?r1=51483&r2=51497.) So while it's good that you're not holding your breath — I don't think Lua will arrive quite as quickly as is being advertised, and I don't think you should design templates based on it yet — I believe that it really will happen. —Ruakh_TALK 11:39, 23 May 2012 (UTC)

I see that the titles of diff pages recently changed to Difference between revisions of "word". Might I suggest that we rearrange this to "word" - Difference between revisions, so that (when viewing several tabs, or Taskbar buttons, or whatever) the important thing comes first? It's the same principle as with applications prepending a filename to their titles, e.g. Document1.doc - Microsoft Word. Equinox ◑ 21:32, 20 May 2012 (UTC)

I support making that change (by editing MediaWiki:Difference-title). —Ruakh_TALK 21:45, 20 May 2012 (UTC)

Support, it is mildly irritating. Ungoliant MMDCCLXIV 22:57, 20 May 2012 (UTC)

Support making this change. --Yair rand (talk) 23:13, 20 May 2012 (UTC)

 Done. Obviously this is easy to undo if it turns out that anyone dislikes it. —Ruakh_TALK 00:12, 21 May 2012 (UTC)

I was expecting a hyphen-minus (-) instead of a dash (—) but whatever. Mglovesfun (talk) 10:39, 23 May 2012 (UTC)

Feel free to change it. This isn't a template; so far as I know, there's no harm in changing it fifty times in a day. —Ruakh_TALK 12:17, 23 May 2012 (UTC)

I noticed Wikipedia changed it too, but they used a colon. —CodeCat 11:45, 25 May 2012 (UTC)

A colon takes up less room, which better fits Eq's purpose outlined above.​—msh210℠ (talk) 16:58, 25 May 2012 (UTC)

O.K.,  Done that. —Ruakh_TALK 17:24, 25 May 2012 (UTC)

I'm sure I'm simply overlooking something, but could someone point me to any pages that explain the process for customizing one's Editing window options? For instance, in the dropdown for the quick-access items, I never use most of the possible categories (like Templates or Headers or Hebrew), but I do use some items that are located across multiple categories (such as the funny apostrophe for ejectives under the IPA category and used as a letter in Navajo, along with acute-accent and ogonek vowels; or macron vowels for Japanese romaji). Any pointers on how to define my own categories for that dropdown would be appreciated. -- TIA, Eiríkr Útlendi │ Tala við mig 05:18, 23 May 2012 (UTC)

I think that was one of the options that were never added to either the Preferences or Gadgets. Anyway, you'll want to have this in your JS file:

mw.loader.load("http://en.wiktionary.orghttps://en.wiktionary.org/w/index.php?title=User:Conrad.Irwin/edittools.js&action=raw&ctype=text/javascript");

From here, create your edittools page and fill in any characters you want to have in its own section. To get an idea on how it could look, see this. -- Liliana • 05:30, 23 May 2012 (UTC)

Brilliant, thank you, Liliana. I'll give that all a good look. -- Cheers, Eiríkr Útlendi │ Tala við mig 05:36, 23 May 2012 (UTC)

I've been checking my watchlist on my phone a fair amount lately, and it's reminded me of a long-standing problem we have here. We deal with a large variety of esoteric scripts, and most of our readers can't view them. On my phone I can see unaccented Greek characters, and a lot of those with simple accentuation, but anything with, say, a breathing mark and a tonal accent doesn't show up, and I'm left with ugly little chunks of words. I suspect my experience in this respect is far from unique. My impression is that web embedded fonts is a pretty standard feature at this point, supported by the recent versions of all major browsers. I was thinking that we could find open source fonts, host them on Wiktionary, and then use our font templates to serve them. That way an average user could see this (which I can't see on any of my computers) or this (which I can sort of see on my main computer, but nowhere else). This would also have the advantage that we could more precisely determine what script a user sees, to make sure they're seeing the appropriate form of cuneiform or some such. Before I put much work in this, I'd like to hear any comments anyone else might have on this. It seems like such an obvious solution to such a glaring and longstanding problem, that I wonder if there is some hurdle. -Atelaes λάλει ἐμοί 12:08, 23 May 2012 (UTC)

The problem with this is a "security" feature of most browsers that prevents web fonts to be embedded cross-domain. If this were resolved somehow, it would be easily doable. -- Liliana • 12:18, 23 May 2012 (UTC)

Would it have to be cross-domain? Generally we like to keep whatever we can on Commons, but there's no technical restriction on what we can keep locally, is there? -Atelaes λάλει ἐμοί 12:23, 23 May 2012 (UTC)

You can't upload fonts, though. -- Liliana • 15:18, 23 May 2012 (UTC)

Even if we can, all uploads are at upload.wikimedia.org, aren't they? So it'd be cross-domain.​—msh210℠ (talk) 16:50, 23 May 2012 (UTC)

What exactly is cross-domain? I can't imagine blocking even other subdomains of the same main domain would be very productive, as it's quite common for sites to have separate domains for assets like fonts and images. —CodeCat 17:25, 23 May 2012 (UTC)

No, not subdomains, just things like wiktionary.org → wikimedia.org. -- Liliana • 17:33, 23 May 2012 (UTC)

...I can't believe I missed that. —CodeCat 17:46, 23 May 2012 (UTC)

• @Liliana, what's preventing us from uploading fonts? -- Eiríkr Útlendi │ Tala við mig 18:35, 23 May 2012 (UTC)

They aren't a legal file format on the upload form, so they'll be rejected. -- Liliana • 18:49, 23 May 2012 (UTC)

Thank you. Experimenting confirms that the server is doing more than just looking at the filename extension, which is smart, so renaming a .ttf file to .pdf, for instance, won't work.

Presumably the list of allowed file types is something that can be configured. Does anyone know where, and by whom? -- Eiríkr Útlendi │ Tala við mig 20:39, 23 May 2012 (UTC)

• Partial answer to myself: http://www.mediawiki.orghttps://dictious.com/en/Manual:Configuring_file_uploads

Not sure who would be able to configure this for EN WT, or how complicated it would be to do enable this just temporarily for installing whatever web-based fonts that pass consensus. -- Eiríkr Útlendi │ Tala við mig 20:43, 23 May 2012 (UTC)

• @msh210, uploads can be just to Wiktionary. Have a look at http://en.wiktionary.orgview_image.php?q=Wiktionary:Grease_pit/2012/May&sq=Wiktionary:Grease_pit/2012/May&lang=en&file=File:Test_silliness , which doesn't currently exist -- it gives a link to a special page for uploading binaries to a page URL that is under the Wiktionary domain. -- Eiríkr Útlendi │ Tala við mig 18:35, 23 May 2012 (UTC)

• Could you demonstrate that? Like — could you upload a test file to a URL whose hostname is a subdomain of wiktionary.org? 'Coz I'm not seeing it. —Ruakh_TALK 18:49, 23 May 2012 (UTC)

We might be talking past each other, but as an experiment, I just uploaded ], which appears at http://en.wiktionary.orgview_image.php?q=Wiktionary:Grease_pit/2012/May&sq=Wiktionary:Grease_pit/2012/May&lang=en&file=File:Test_silliness.png -- nothing cross-domain in this URL for our purposes. Is that what you meant? -- Eiríkr Útlendi │ Tala við mig 20:39, 23 May 2012 (UTC)

If you check, the image on that page actually has a URL on upload.wikimedia.org.​—msh210℠ (talk) 21:24, 23 May 2012 (UTC)

Huh, whaddaya know. The way it's managed on the server, though, allows us to link to it directly from EN WT (which I guess is hinted at by the wiktionary/en portion of the image's direct URL, http://upload.wikimedia.org/wiktionary/en/7/77/Test_silliness.png) -- does this suffice for our purposes? (Though this whole sub-thread might be mooted by the webfonts extension Yair mentions below...) -- Eiríkr Útlendi │ Tala við mig 21:37, 23 May 2012 (UTC)

I think you're misunderstanding what Liliana's referring to. You seem to be thinking of servers' being configured to prevent inline linking by examining the Referer header in an HTTP request for an image; but I believe that Liliana is referring to browsers' being designed to prevent cross-site scripting by enforcing a same origin policy for certain types of requests. That said, it looks like recent browsers actually support Cross-origin resource sharing for font embedding, so I think this problem should be workaround-able on the server? I'm not sure. —Ruakh_TALK 22:18, 23 May 2012 (UTC)

@Ruakh, you're correct, I was off track. Here's hoping the webfonts extension has a way around the cross-site issue. -- Eiríkr Útlendi │ Tala við mig 06:08, 24 May 2012 (UTC)

Maybe 'commons.wiktionary.org' should become a redirect to 'commons.wikimedia.org' somehow? —CodeCat 18:40, 23 May 2012 (UTC)

I didn't even think about the possibility of restrictions on uploading file types, even though in hindsight it seems rather obvious. I suppose that squashes that idea. -Atelaes λάλει ἐμοί 20:05, 23 May 2012 (UTC)

mw:Extension:WebFonts. It's already enabled on some Wikimedia wikis, and it would probably work well here. --Yair rand (talk) 20:12, 23 May 2012 (UTC)

I'm aware of that extension, but I don't think it's suited to us because 1. it can only apply one font at a time, and 2. it applies the font across the whole wiki, rather than just the page title or similar. -- Liliana • 20:57, 23 May 2012 (UTC)

(edit conflict) See this thread. "The extension can load any number of fonts for one page", according to one of the developers who worked on the extension. "The only requirement is the words or sentences should be marked with the language. Example usage: translatewiki:User:Amire80/All WebFonts languages". --Yair rand (talk) 21:08, 23 May 2012 (UTC)

This description at mw:Extension:WebFonts#Alternate_ways_to_load_fonts suggests more fine-tuned capabilities:

So it should be possible to specify multiple different fonts within a single paragraph, for instance. -- Eiríkr Útlendi │ Tala við mig 21:05, 23 May 2012 (UTC)

Hmm. That just leaves the problem that we'd need to developers to add a bunch of new fonts needed for our scripts. And that could take a while. -- Liliana • 21:37, 23 May 2012 (UTC)

Yes, it could. We'll have 28 scripts' fonts to start with, and we should start making requests for the others as soon as possible, if this is something we would consider to be helpful. --Yair rand (talk) 21:41, 23 May 2012 (UTC)

Sweet. We should try and get this installed on English Wiktionary. Additionally, we might be among the better wikis to assist in development of this extension. Thanks Yair. -Atelaes λάλει ἐμοί 22:14, 23 May 2012 (UTC)

• WT:Votes/2012-06/Enabling WebFonts Extension starts in a week. --Yair rand (talk) 21:23, 18 June 2012 (UTC)

People, I am retarded. You can simply use the Data URI scheme to embed fonts on Wiktionary. That wouldn't require any kind of extension. -- Liliana • 18:31, 28 June 2012 (UTC)

how can i add the |sg=word word| part to a plural only noun?Lucifer (talk) 02:04, 25 May 2012 (UTC)

Use |head=. --Yair rand (talk) 02:06, 25 May 2012 (UTC)

I'd prefer it if you used that for the singular as well, as it's the most consistent across templates and languages. —CodeCat 11:44, 25 May 2012 (UTC)

Just a thought. Maybe entries in category:English non-idiomatic translation targets should have their translation boxes expanded on page load no matter what cookies someone has set for translation boxes sitewide.​—msh210℠ (talk) 17:55, 25 May 2012 (UTC)

Sounds like a great idea? How can it be implemented? --Μετάknowledge^{discuss/deeds} 03:32, 6 June 2012 (UTC)

Broadly speaking, there are two ways:

• We can use different wikitext on those pages; for example, we could create and use a non-collapsing variant of {{trans-top}} on those pages, or we could add and use a parameter to {{trans-top}} that tells it not to collapse. ({{trans-top}} only collapses because the outermost div's only class is NavFrame. If you add another class alongside that, you keep all the styling of translations-tables, but prevent collapsing.)
• We can modify the translations-table–seeking JavaScript to detect that it's being used on a non-idiomatic-translation-target entry, and either bypass those tables, or else simply start them off as uncollapsed (while still allowing them to be collapsed).

The JavaScript approach has some advantages, but I think I prefer the wikitext approach as easier and less error-prone. (Or at least, prone only to human error on an easily-fixed page-by-page basis, rather than to script error on a site-wide basis.)

—Ruakh_TALK 12:16, 6 June 2012 (UTC)

I guess it depends. Are translation-only pages categorized as such? That would make the process far easier, for humans or bots. --Μετάknowledge^{discuss/deeds} 15:27, 6 June 2012 (UTC)

Well, there are various entries that passed RFD due in part to idiomaticity of translations, and those aren't categorized; but this discussion is specifically about entries in Category:English non-idiomatic translation targets, so — yes. —Ruakh_TALK 15:32, 6 June 2012 (UTC)

So I guess it's just a find-and-replace job within a cat. The first option's extra parameter idea sounds ideal. --Μετάknowledge^{discuss/deeds} 15:55, 6 June 2012 (UTC)

An advantage of the JS approach is that once it's written so as to be error-free, it requires no extra maintenance (adding the parameter to {{trans-top}}). An advantage of the extra-parameter approach is that it can be used in entries other than those in the specified category, whenever deemed appropriate. Personally, I think the former consideration weightier than the latter.​—msh210℠ (talk) 22:56, 18 June 2012 (UTC)

I'm thinking about a project which would help language learners using Wiktionary data. The user would insert text in a language of his choice, then Wiktionary data would appear when the cursor hovers over each word. This is a simple Demo:

http://tiny url.com/cy93qt6" 

(hover over some of the first words).

Before pursuing this further, I just wanted to know - does anything similar exist?

Thanks! Jobnikon (talk) 20:19, 26 May 2012 (UTC)

I've not seen anything similar before. It should be noted that I have not memorized the entire internet (yet), and so such a thing could well exist outside of my knowledge. -Atelaes λάλει ἐμοί 22:46, 26 May 2012 (UTC)

There's WikiLook. -- Curious (talk) 22:21, 31 May 2012 (UTC)

I started working on the Demosthenes subtemplates for {{grc-cite}}, and realized that it might be more efficient to pack the logic gates into {{grc-cite-Demosthenes}} instead of creating all the subtemplates, ({{grc-cite-Demosthenes-Olynthiac 1}}, etc.). Demosthenes is somewhat unique in that he has a lot of works (51 to be exact), in comparison to the 5-12 that most other authors have. Also, his works all follow a very simply and consistent format. You can see my attempt at {{grc-cite-DemosthenesTest}}. It doesn't work. The problem is that the switch has to supply three separate parameters to the final formatting template ({{grc-cite-blank-full}}), and the pipes used to separate these parameters are, of course, indistinguishable from the pipes separating the different flow paths of the switch. This would work if the template used three identical humongous switches.....and perhaps that might be preferable to 51 nearly identical subtemplates, but I was hoping that one switch might be made to work somehow. Does anyone have any thoughts on how this could be made to work? -Atelaes λάλει ἐμοί 23:03, 26 May 2012 (UTC)

We now have Wiktionary:Index_to_templates/languages/protection, Wiktionary:Index_to_templates/languages/protection/family Wiktionary:Index_to_templates/languages/protection/etyl and Wiktionary:Index_to_templates/languages/protection/script, which are cascade protected and transclude all language templates. So, the actual protection of the code templates themselves is not needed anymore. Would it be possible to unprotect them, maybe with a bot? —CodeCat 18:05, 27 May 2012 (UTC)

What is the purpose of the switch? —Ruakh_TALK 11:48, 28 May 2012 (UTC)

It's easier to protect templates this way if there are many of them. And it's also easier to unprotect them temporarily for things like bot edits. —CodeCat 11:50, 28 May 2012 (UTC)

Really? I would have thought that the regular protection interface was easier. That is its purpose, after all. —Ruakh_TALK 11:59, 28 May 2012 (UTC)

It is if you want to protect pages one at a time. But there are hundreds of code templates, and to protect them all manually would be a huge task. The way it is done now, all of them are protected in one go. It wasn't my idea but I do think it is a good idea. —CodeCat 12:01, 28 May 2012 (UTC)

Re: " is if you want to protect pages one at a time": I find it hard to square this with your statement that "it's also easier to unprotect them temporarily for things like bot edits". Or — did you mean that it's easier to unprotect all language-templates simultaneously for bot edits? Because almost every single page on the protect uses a language template; someone who wants to run a bot over all the language-template should probably be permablocked just for having the idea . . . —Ruakh_TALK 12:07, 28 May 2012 (UTC)

You want to permablock Liliana? —CodeCat 12:09, 28 May 2012 (UTC)

Maybe . . . what did she do? :-P   (O.K., not really. But — where did she propose such a bot? I don't remember seeing such a discussion.) —Ruakh_TALK 12:11, 28 May 2012 (UTC)

I recently went through 100+ articles on the dead-end pages list and linked the to other entries. At the top of the page, it says that updates have been disabled for the page, so even when someone fixes up a page so that it's not a dead-end page anymore, it stays on the list. Could someone enable updates on that page so that I can get a better sense of what needs to be done?

Thanks,

Rob Hurt (talk) 00:33, 28 May 2012 (UTC)

It's not something we control; it was disabled on all WMF wikis because the report that generated the list was too expensive. (See bugzilla:15434 for ongoing discussion about how/whether to address it.)

How exactly is that page defined? Can we generate a substitute by analyzing a database dump?

—Ruakh_TALK 12:09, 28 May 2012 (UTC)

For some time I have found that clicking on my username at the top of every page to go my user page sometimes takes me to Wiktionary's main page. I thought it was sloppy clickwork. But I have now observed that the leftmost portion of my name overlaps the logo area. Clicking on the rightmost portion of my username takes me to userpage as desired. As the username clicking area is small and the logo clicking area is huge, it requires more click precision than is usual for me. Although this is certainly not serious, it is annoying and creates what seems to me to be an appearance of amateurishness in our generally very professional-seeming UI. Can this be corrected? DCDuring TALK 03:21, 29 May 2012 (UTC)

To replicate the experience, just narrow the window on any Wiktionary page. As the window narrows the top line runs into the logo clicking area. When the window is narrow enough the username can be completely unclickable. DCDuring TALK 16:59, 29 May 2012 (UTC)

Either your window is shrunk to about 250 pixels (at which point everything is pretty much unusable anyway) or this is an odd browser quirk that I'm unaware of... #p-personal{z-index: 1;} would probably fix the problem. --Yair rand (talk) 19:16, 29 May 2012 (UTC)

Or he's zoomed his browser to a higher magnification: everything takes up more room, so the system has less room to work with. Chuck Entz (talk) 04:26, 30 May 2012 (UTC)

The top line for me takes up most of the screen width on my laptop. Clearly this accessibility issue is not a concern to those still with either the full powers of youth and health or with more expensive, larger, higher-resolution screens. DCDuring TALK 11:25, 30 May 2012 (UTC)

@Yair rand: Does the line of code go in monobook.js or .css? DCDuring TALK 11:28, 30 May 2012 (UTC)

It's CSS. —Ruakh_TALK 11:47, 30 May 2012 (UTC)

@Yair. The code line didn't seem to work, but hiding the logo did. It is no longer a problem for me though it might be for, say, other older users who have selected larger type for legibility. DCDuring TALK 22:47, 30 May 2012 (UTC)