Wiktionary:Grease pit/2013/December

A surprisingly large number of vandals edit a page just to change one language header (e.g. ==English== to ==French==), where (i) the new language is obviously wrong and (ii) nothing is changed other than the language name — no changes to anything like {{en-noun}} etc. Perhaps we could filter this kind of vandal edit? Equinox ◑ 13:54, 1 December 2013 (UTC)

I have seen this kind of edit done legitimately, but only by admins. So support if it's only preventing IPs. —Μετάknowledge^{discuss/deeds} 19:54, 1 December 2013 (UTC)

The more usual one is where it's not a language at all, such as ==poop==. Mglovesfun (talk) 11:34, 3 December 2013 (UTC)

I would think it's safe to assume that all languages whose principal name is a string ending in sign language (or however we capitalise it) should have the family sgn and the script Sgnw. In that case, would somebody be willing to automatically add this for all the sign languages that lack it in the modules? —Μετάknowledge^{discuss/deeds} 19:52, 1 December 2013 (UTC)

I added the family sgn to all the sign languages a while back (assuming I didn't miss any). They are not, however, all written in Sgnw; indeed, I wouldn't be surprised if most of them weren't written with SignWriting. German Sign Language is mostly written using the Hamburg notation system (though SignWriting can also also found), and a number of sign languages use the Stokoe notation system, and at least a few of the more obscure ones have probably never been written at all (which does make it difficult to have entries in them...). - -sche (discuss) 21:28, 1 December 2013 (UTC)

Ah, I thought Sgnw was just the concept of signing as a writing system. I had not noticed you adding sgn, thanks for that. —Μετάknowledge^{discuss/deeds} 21:47, 1 December 2013 (UTC)

Any reason we don't just use their actual language families, ie w:French Sign Language family, w:German Sign Language family, w:Japanese Sign Language family, etc? --Yair rand (talk) 23:08, 1 December 2013 (UTC)

No reason other than the general incompleteness of Module:families and the templates that preceded it. I suggest sgn-gsl (abbreviating "German sign languages", obviously) for the German ones, and sgn-fsl, sgn-jsl etc for the others. The families should probably continue to be sorted into the macro-family sgn. Should there be a code sgn-iso for isolated, sui generis sign languages? - -sche (discuss) 00:14, 2 December 2013 (UTC)

We don't need to incorporate "sign language" into the second part of the name. Could we just prefix the standard language code with "sgn-"? That would probably be more intuitive. —CodeCat 00:41, 2 December 2013 (UTC)

In the case of French Sign Language and Japanese Sign Language, the codes are "fsl" and "jsl". German Sign Language's code is "gsg" because "gsl" is taken by something else, but we can use "sgn-gsl" as the family code because there's no naming conflict there. - -sche (discuss) 02:02, 2 December 2013 (UTC)

I would prefer "sgn-gsg" then, for consistency. It's easier to memorise if you just need to add "sgn" before the "parent" language's code. —CodeCat 01:47, 6 December 2013 (UTC)

Ok, fair point. - -sche (discuss) 23:09, 6 December 2013 (UTC)

I think it would be somewhat analogous to the relationship between a pidgin and the language(s) it's based on: there's a lot that's brought over from the spoken language, but there are some fundamental differences due to the practical needs of communication in a very different environment.

Also, the syntax may be quite similar in some ways, but the lexicon has undergone complete w:relexification: aside from some signs that incorporate letters, there's no trace of the phonemes of the spoken language (I wonder, too, how much of the morphology would survive in highly-inflected and agglutinative/polysynthetic languages). If that happened in the evolution of a spoken language, the original language might be ignored when classifying the new language as a mere substratum influence.

It would no doubt be useful, as a practical matter, to categorize the sign language according to the spoken language it came from, but there are counterexamples like w:Finnish sign language, which is said to be very close to w:Swedish sign language even though spoken Finnish is completely unrelated to spoken Swedish. Chuck Entz (talk) 01:29, 2 December 2013 (UTC)

I think that either you've indented your comment in a confusing way, or else you've misunderstood the comment that you're replying to. Yair was not suggesting that sign languages be assigned to the language-families of nearby spoken languages; rather, he was suggesting that we recognize the actual sign language families. For example, American Sign Language belongs to the 'French Sign Language family' that he refers to. —Ruakh_TALK 02:02, 2 December 2013 (UTC)

I added three sign language families to Module:families. I noticed that the default display, if a language's family is sgn, seems to be " is a sign language, thus written in SignWriting script." This is misleading and should be changed: as noted above, sign languages are not automatically written in SignWriting (whoever wrote the template probably thought they were).

Now the question is: how do we want the family of, say, German Sign Language to be identified on Category:German Sign Language? And what do we want the family category to be called? I think "German Sign Languages" would be good, but we would need to suppress two things. First, the word "family" in the category text (so that while Category:German language says it is "a member of the West Germanic family", Category:German Sign Language would say it was "a member of the German Sign Languages"). (Or perhaps "German Sign Languages family" is OK as-is.) Second, the word "languages" in the auto-generated family category name, so that it was Category:German Sign Languages rather than Category:German Sign Languages languages. How can we suppress those two things? With Template:languageshift or something similar? - -sche (discuss) 18:40, 3 December 2013 (UTC)

- -sche (discuss) 18:40, 3 December 2013 (UTC)

There are so few sign languages that scattering them all across subcategories just makes it more messy. I would very much prefer if they were lumped into one big sign languages category, like what we are doing right now. -- Liliana • 19:07, 3 December 2013 (UTC)

There appear to be 138 listed... --Yair rand (talk) 22:01, 3 December 2013 (UTC)

To -sche: For languages, this problem is solved through {{languageshift}}, which will have a Lua implementation in the newly-rewritten Module:languages as well. The same could be done for the families. —CodeCat 22:18, 6 December 2013 (UTC)

Thanks! Unless someone has a better idea, I suppose the sign language families could have names like "French Sign Languages" (plural, so as to be distinct and a separate category from "French Sign Language"), and the module could then prevent the addition of a redundant second instance of "languages" by {{langcatboiler}} etc. - -sche (discuss) 23:09, 6 December 2013 (UTC)

I fixed the problem with "thus" in diff; the ugly state of Category:French Sign Language and Category:French Sign Languages remains to be improved. - -sche (discuss) 10:52, 27 December 2013 (UTC)

Does anyone else have a set of characters under the search box that is much small than that under the edit box? Is there some trick to get them all to display? I have had to resort to a little trickery to get even the dozen of them I can see to display. Who is an active gadgeteer? DCDuring TALK 20:06, 3 December 2013 (UTC)

Now that we've separated out Module:languages from its data, can we do the same for scripts and families? Presumably yes, but just making sure people are ok with it. We don't really need to split them into multiple modules, although for administrative purposes we might want to separate families into ISO codes and exceptional codes. I don't know if we can separate script codes the same way. All of our 4 letter script codes are ISO script codes, I think? —CodeCat 01:45, 6 December 2013 (UTC)

I would keep all of the family codes in one place. I've added a number of families recently (our "family tree", for lack of a better term, is somewhat out of date), and I've added family info to a large number of languages, and in both activities I've found it helpful to have a single alphabetical list of all the family codes. It makes it easy to check if we already have a code for a family. (If anyone were to propose splitting family codes by letter, the way language codes are split, that would be even less desirable, IMO. The classification of some families is uncertain — e.g. I added Ubangian with the prefix qfa-, because recent scholarship has noted that it hasn't been shown to be related to other families, but Liliana reprefixed it as nic-, because other recent scholarship has countered that it hasn't been shown to not be Niger-Congo — and we might end up encoding the same family twice under different prefixes, and thus on different pages, without anyone noticing.) - -sche (discuss) 02:37, 6 December 2013 (UTC)

We can reorganize and put the data in a submodule, but based on the amount of data here, there's no reason to separate it out into multiple submodules. --WikiTiki89 02:40, 6 December 2013 (UTC)

I think you misunderstood, -sche. I'm only suggesting two subpages, Module:families/data3 and Module:families/datax (following the naming of language modules; we can decide to use something else). So there would be no per-letter modules. There's not enough family codes, nor are they used widely enough on Wiktionary, to warrant keeping the amount of page refreshing down. But I think splitting by ISO / exceptional is useful to keep the two types of code clearly separate. —CodeCat 02:43, 6 December 2013 (UTC)

What's wrong with just Module:families/data and nothing else? --WikiTiki89 02:45, 6 December 2013 (UTC)

Nothing is wrong with it, I just think separating ISO and exceptional codes is good on principle. —CodeCat 02:47, 6 December 2013 (UTC)

Have the ISO codes come first in the module and the exception ones after. There's no need for separate modules. --WikiTiki89 02:51, 6 December 2013 (UTC)

Why do they need to be separated out of the alphabetical order at all? They're already visually distinguished by the fact that ISO codes are three letters long and exceptional codes are six letters punctuated by a hyphen. And it's not like one kind of code is more (likely to be) valid than the other — several "families" which are known to be geographic rather than genetic have ISO codes, e.g. aus and sai, and conversely several well-accepted families have exceptional codes. - -sche (discuss) 03:08, 6 December 2013 (UTC)

I understood and replied to you in the first half of my comment. In the parenthetical second half, I also anticipated another possible proposal and replied to it. I think it would be better to keep all the data in one place, not two (nor more). - -sche (discuss) 02:49, 6 December 2013 (UTC)

As there was no objection to the proposal of moving the data modules to a subpage, I've now done this: Module:families/data and Module:scripts/data. I also created Module:scripts/tempdata and Module:families/tempdata as redirects, and changed all of the original uses of the main module to them. That way, we can keep track of which modules/pages are still using the data directly, and which have already been converted to the new "encapsulated" versions (to-be-written once the old modules are orphaned). —CodeCat 22:25, 6 December 2013 (UTC)

Module:families is now orphaned. —CodeCat 00:21, 13 December 2013 (UTC)

This may sound stupid but... why is this template system still in use? I notice that editors like -sche are updating the modules but not the langrevs, even though it appears that the langrev subtemplates are still relied upon. Am I right in saying that we can and should try to orphan this? —Μετάknowledge^{discuss/deeds} 07:04, 6 December 2013 (UTC)

I think we should orphan it, yes; Special:WhatLinksHere/Template:langrev should be treated as a cleanup category. (And we can change it to use Module:languages — which is relatively expensive, but should be fine as long as we do a good job keeping the template orphaned.) —Ruakh_TALK 08:11, 6 December 2013 (UTC)

It hasn't been changed yet because it's not clear how it should work when two languages have the same secondary names. Even its current version isn't really clear on this. If we write a new implementation, then the search could yield multiple codes that have the same name among their list of names. What would our existing templates do in that case? In fact, how would they even be able to handle it, given that templates don't support lists? We could limit any new implementation to just searching among canonical names, but that would also limit its usefulness a lot. It would no longer be able to support cases where people enter a name other than our canonical name, like for example "Croatian". So we really need to think about how we're going to do this, it's not straightforward. —CodeCat 14:39, 6 December 2013 (UTC)

The basic functionality should be to only search for primary names. If we figure out what to do with secondary names, then we could add that functionality later. --WikiTiki89 15:02, 6 December 2013 (UTC)

But our current... "things" already rely on having at least some of the secondary names available. The translation adder is one if I'm not mistaken? —CodeCat 15:08, 6 December 2013 (UTC)

I've written two functions to replace langrev in the new Module:languages (which isn't in use yet). There is a discussion at Module talk:languages#Langrev. —CodeCat 22:21, 6 December 2013 (UTC)

In case it's not obvious, I support orphaning this or switching it to use Module:languages. Trying to maintain and sync two separate lists of all the languages in the world (one in the 28 subpages of Module:languages and one scattered across the thousand subpages of langrev) is foolhardy. - -sche (discuss) 19:14, 7 December 2013 (UTC)

• Note that the translations adder depends on this, and the module wouldn't work as a replacement. --Yair rand (talk) 21:30, 8 December 2013 (UTC)

  Why wouldn't a module version work as a replacement? --WikiTiki89 21:35, 8 December 2013 (UTC)

My ] uses {{subst:langrev}} several times. If it's to be replaced, I'd appreciate someone's letting me know what subst: to use instead. (I understand from the above that that's not happening immediately, so a GP post should do whenever it comes up.)​—msh210℠ (talk) 09:07, 10 December 2013 (UTC)

Discussion moved to Wiktionary:Beer parlour/2013/December#Rhymes categories again.

Using categories for rhymes and organizing by syllables are not incompatible. I don't see why we can't have a Category:Rhymes:en/-eɪʃən as well as Category:Rhymes:en/-eɪʃən/2, Category:Rhymes:en/-eɪʃən/3, Category:Rhymes:en/-eɪʃən/4, etc. for each number of syllables. Doesn't that solve all our problems (other than the inconvenience of the 200 entry limit per page, which we are discussing below)? --WikiTiki89 18:39, 8 December 2013 (UTC)

I'm going to ignore Dan's aggressive and uncalled for outbursts and accusations. I agree with Wikitiki89. We can have both. Not every editor is willing to create complicated tables but adding to categories would be easy. I don't think anyone suggested to delete Dan's tables, anyway. --Anatoli ^{(обсудить}/^вклад) 23:28, 8 December 2013 (UTC)

• Why isn't the discussion of benefits of alternative presentation of rhymes conducted on the Beer Parlor? How is this principally a technical issue? If this is the right venue, what are the technical issues?

The choice of venues does have some effect on who participates, so this venue is well-suited for reducing the likelihood of participation by those with little confidence in their technical abilities or with little interest in technical matters. Why would one choose this venue to discuss something that might be of benefit to such users? DCDuring TALK 16:34, 9 December 2013 (UTC)

• For one thing, there are technical issues to be resolved. I have brought them up in this subsection and in the section below. I'm sure no one would object if you moved the rest of the discussion to the Beer Parlour. --WikiTiki89 16:36, 9 December 2013 (UTC)

You still can't have red links in categories, though. -- Liliana • 18:12, 9 December 2013 (UTC)

Why not? --WikiTiki89 18:14, 9 December 2013 (UTC)

Try it on or with this nonexistent page. DCDuring TALK 18:42, 9 December 2013 (UTC)

How would you have the wiki software behave? From where would redlinks be added? How would that be made intuitive for new users? DCDuring TALK 18:46, 9 December 2013 (UTC)

My mistake, I misunderstood what Liliana said. --WikiTiki89 18:58, 9 December 2013 (UTC)

Many categories have had (and perhaps still have?) lists of redlinks in their wikitext, manually added by editors who intended the pages, when created, to be added to the categories. We can do the same for categories.​—msh210℠ (talk) 09:04, 10 December 2013 (UTC)

True. And a long list would push the intended content off the screen, doubtless inducing users to add entries for the missing rhymes. DCDuring TALK 14:58, 10 December 2013 (UTC)

Seems reasonable, but (1) autocategorization by {{rhymes}} will have to await addition of a number-of-syllables parameter and (2) it requires a decision, for each language, on how to count syllables.​—msh210℠ (talk) 09:04, 10 December 2013 (UTC)

Adding such a parameter to {{rhymes}} is simple. As for deciding how to count syllables, that should have already been done as we currently do organize our rhyme pages by syllables. Languages should be able to opt out of syllable counting if it is unnecessary in that language. --WikiTiki89 14:02, 10 December 2013 (UTC)

Which is why I think it's more useful to use categories for Dutch. But we can't be sure if it's practical unless we try it out and see what happens. That's why I proposed doing it with Dutch alone as a trial, but even that was opposed by some people. Honestly, I don't see the harm if we can always remove the categories again. It seems more like an attitude of "I already know it won't work, so I won't let you try". —CodeCat 14:56, 10 December 2013 (UTC)

In the above section (#Rhymes categories again), Dan Polansky uses, as an argument against rhyme categories, the fact that category pages can only list 200 entries per page. I have myself found this to be a nuisance as well when looking through categories. I think we can benefit from having category pages give the option to display more entries at once, and possibly even have a search or find feature to search or find pages in the category. Is there a technical reason for the limit being at 200? Would category pages have any severe slowdown if they displayed more entries? Otherwise, we should file a bug report and have them introduce this feature (which I can't imagine being very difficult). --WikiTiki89 18:26, 7 December 2013 (UTC)

I definitely agree. 200 is ok as a default, but it should be possible to change it, either for one time or as a preference. —CodeCat 18:31, 7 December 2013 (UTC)

I imagine there is a technical reason it's at 200, but if there isn't, then yes, I think it should be possible to set how many words you want to see per page, just as you can on whatlinkshere pages — where, NB, you not only have ready-made links to "200", "500", etc, but can also edit the url by hand to see e.g. 356 entries per page (or whatever number of entries your heart desires). - -sche (discuss) 22:53, 7 December 2013 (UTC)

I think I have found a minor bug with the Notifications dropdown (the thing that appears at the top when you are logged in, showing a red number if you have new alerts). If you are "thanked" for an edit, the item in the expanded dropdown has a "View edit" link. Left-clicking this navigates to the edit, as expected. However, middle-clicking it (which, at least in my browser, Opera, ought to open the same page in a new tab) opens the thanking user's user page in the new tab instead. Curious. Equinox ◑ 21:42, 7 December 2013 (UTC)

Quite annoying. Can this be fixed, without signing up for accounts in other places and dealing with cold, unhelpful nerds? Equinox ◑ 03:14, 10 February 2014 (UTC)

• FWIW, middle-clicking the view edit link in Firefox on Win XP opens up that edit in a new tab. I haven't tested in Chrome (can do that tomorrow). ‑‑ Eiríkr Útlendi │ Tala við mig 03:42, 10 February 2014 (UTC)

Bug 61121. --Yair rand (talk) 04:51, 10 February 2014 (UTC)

I <3 Equinox's summaries. - Amgine/ ^t·e 08:32, 10 February 2014 (UTC)

Apparently you can't link to the asterisk itself with the term template: {{term|*|lang=mul}} returns * instead of *. Can this be fixed? -- Liliana • 14:45, 8 December 2013 (UTC)

It's fixed. —CodeCat 14:59, 8 December 2013 (UTC)

I can't click and open the declension tables in Latvian pages like vīrišķība -- or, in fact, any declension or translation tables anywhere. What's going on? (Right now, I'm in Brazil, not in the Netherlands, but this shouldn't have any impact, should it?) --Pereru (talk) 21:45, 8 December 2013 (UTC)

You need to make sure that you have JavaScript enabled in your browser and that the page loads entirely. --WikiTiki89 21:48, 8 December 2013 (UTC)

Re: "that you have JavaScript enabled in your browser": that's not necessary. The CSS that hides the table is .client-js .NavFrame .NavContent { display: none; }, which has no effect unless at least a little bit of JavaScript has run (to change the page's <html> element's class from client-nojs to client-js). A more likely problem is that the initial bit of JavaScript runs fine, so the tables are appropriately hidden, but then some subsequent error causes the JavaScript to stop running, so the tables cannot be unhidden. —Ruakh_TALK 21:55, 8 December 2013 (UTC)

And how can I check that? Is there somewhere I can check whether JS in this new laptop is running fine? Should I try to reinstall it? --Pereru (talk) 22:05, 8 December 2013 (UTC)

No, you should not try to reinstall it. The problem, whatever it is, is in our site's JavaScript. (If it works on some computers but not others, that's still a problem with the site, not with the computers.) As for how to track down the error — what OS version and browser version are you running? —Ruakh_TALK 22:38, 8 December 2013 (UTC)

I'm running Windows 8, my browser is Google Chrome Version 31.0.1650.63 m. --Pereru (talk) 01:46, 9 December 2013 (UTC)

A further detail, in case it helps: I was running the same browser, in the same laptop with the same version of Windows, about 2-3 weeks ago (when I was still in the Netherlands), and Wiktionary worked fine then: all declension tables loaded well and opened when clicked on. If, as you say, this is the site's fault, did something happen at Wiktionary in the meantime? --Pereru (talk) 01:47, 9 December 2013 (UTC)

Try bypassing your browser's cache (if you don't know how, Ctrl+Shift+R works in most browsers). --WikiTiki89 01:52, 9 December 2013 (UTC)

O.K., I've created Help:Error console, with instructions for Google Chrome. If you follow those instructions, you should at least be able to see what error is occurring, so we can try to fix it. —Ruakh_TALK 03:21, 9 December 2013 (UTC)

Would it be possible to check what context templates are still lacking the corresponding data in Module:labels/data? It seems to me that if we're done with the migration, we should kill the template check portion of the Lua, and if we're not done.....to get done and then kill said portion. Admittedly I'm not an expert on this subject, and I will accept correction from my betters if it is warranted. -Atelaes λάλει ἐμοί 04:34, 9 December 2013 (UTC)

You're right, but sadly, it looks like CodeCat abandoned that project partway through. Unless I'm missing something, Module:labels/data still doesn't support the comma-omitting behavior provided by context-templates like {{of a}} and {{chiefly}}. At first glance, it seems like that should be pretty straightforward — we could easily add omit_comma as a supported property of normal labels, or alternatively we could add a new data-table modifiers alongside labels and aliases — but I assume there's a reason that CodeCat silently gave up and moved on to the Next Big Thing, so maybe it's trickier than it looks. Does anyone have the time and inclination to pick it up? (If not, I can do it, but probably not this week.) —Ruakh_TALK 07:46, 9 December 2013 (UTC)

Well, we could perhaps start with a list of all context templates which have not been added to the Lua database, and perhaps publish it somewhere. That way any interested parties could contribute. I'm not making any promises, but I would probably be willing to work on some migration. As it happens, I'm wrestling with a comma omission problem on my module, as well. I'll give it some thought. -Atelaes λάλει ἐμοί 07:51, 9 December 2013 (UTC)

Re: "a list of all context templates": See Wiktionary:Todo/Context templates. (I can't guarantee that that list contains exactly and only the unmigrated context templates — actually, I think that a lot of those are in Module:labels/data, and simply need deletion — but at least it should give you plenty to work on.)

Re: "a comma omission problem": The thing is, the module already supports comma omission; it has to, in order to support e.g. {{chiefly}}. (Something like {{context|chiefly|foo}} is still wholly mediated by Module:labels; it detects that {{chiefly}} wants the comma to be omitted, so it omits it.) The problem is just that Module:labels doesn't offer any way for an entry in Module:labels/data to activate that feature. So it doesn't seem like it should require any thought. I find it bizarre that CodeCat didn't do it; hopefully she'll weigh in with an explanation.

—Ruakh_TALK 08:10, 9 December 2013 (UTC)

This is not strictly relevant to the original topic of this thread, but regarding comma omission: remember that commas are not only removed after certain things, like "of a", they're also removed from both sides of things like "and". Having comma-omission be a label property sounds useful; then we could easily add new labels like "outside" or "except in" (specifying "no comma on either side") to simplify things that are currently coded as {{context|archaic|_|outside|_|dialects}}, etc. - -sche (discuss) 08:21, 9 December 2013 (UTC)

I had originally intended to make the feature more general, by allowing one label to indicate that it's really equivalent to more than one other label. That way, "chiefly" would be implemented as just equivalent to "chiefly|_" and then we only have to support _ (which is already done). I think the templates did it this way too. But there may be better ways to do it, I don't know. —CodeCat 12:27, 9 December 2013 (UTC)

I don't see why we can't add two simple optional properties like drop_comma_before=true and drop_comma_after=true. This would be the simplest solution and thus the most likely for someone to be unlazy enough to implement. --WikiTiki89 14:47, 9 December 2013 (UTC)

Sorry, my above comments were totally wrong. I must have been looking at the wrong piece of code. Module:labels does currently support omit_comma as a property of an entry in Module:labels/data. The idea above, of also supporting a way to suppress the comma before the label, is a good one, but needn't block the rest of the migration of context-templates to Module:labels/data. Mea culpa. —Ruakh_TALK 17:11, 9 December 2013 (UTC)

I've checked all the templates, and incorporated the missing ones into labels/data. I've added the missing comma control, and killed the template lookup. I've tried to test this, but of course there are so many different variables and use-cases that I could well have missed something. If I did screw something up, I am deeply sorry for the trouble. Please let me know and I will do my best to fix it. -Atelaes λάλει ἐμοί 04:00, 16 December 2013 (UTC)

I've undone your change. Not all of the templates are orphaned yet, which means that some of them are still being transcluded by the module, and removing support for the templates would break the pages that use those labels. Template support should only be removed once Category:All context labels is empty, and it can only be emptied if the templates have no more transclusions. —CodeCat 04:05, 16 December 2013 (UTC)

Have any changes been made recently - in the past hour or so? When using Chrome (but not Firefox) the Wiktionary logo has shrunk to 1cm.sq. Bullets are practically invisible. The delete/move/protect/purge dropdown has also shrunk? I'm using the Vector skin and have deleted custom.CSS (the radio buttons have disappeared so I can't try a different skin. I'm not aware of having changed anything else. Saltmarsh (talk) 16:03, 9 December 2013 (UTC)

• I should add - all looks normal in Wikipedia and Βικιλεξικό. Saltmarsh (talk) 16:04, 9 December 2013 (UTC)

  It might just be your zoom. Try pressing Ctrl-0 to reset to default zoom. --WikiTiki89 16:09, 9 December 2013 (UTC)

• Thanks - I feel an idiot since I'm not sure how I zoomed out to far! cheers Saltmarsh (talk) 16:17, 9 December 2013 (UTC)

Someone must have changed something. --WikiTiki89 19:13, 9 December 2013 (UTC)

Tracked it to this edit by CodeCat. --WikiTiki89 19:17, 9 December 2013 (UTC)

Why do people never say what the error actually is? :/ —CodeCat 19:29, 9 December 2013 (UTC)

Hi Wikitiki89, next time could you provide a page where the error occurs and what the script error actually says? I understand it seemed like a urgent message, but it is useless if the message has no details. Is there a guide on how to report bugs somewhere?

Also, it should be mandatory to anyone editing widely used module pages such as Module:etymology language/data to always check a test page before saving the changes no matter how trivial the change may seem ("Preview page with this template"). Dakdada (talk) 10:11, 10 December 2013 (UTC)

Well what happened was that as I checked the script error, it told me exactly which module the error was in, where I immediately spotted the change that caused it, reverted it, and notified the person who made the change. We then had a little discussion at my talk page. Essentially, there was no longer any point in posting the error information here. --WikiTiki89 14:00, 10 December 2013 (UTC)

And Wikitiki showed me the test page feature which I didn't know I could use for cases like this, so hopefully it won't happen as much anymore. —CodeCat 14:57, 10 December 2013 (UTC)

Can we get rid of the extra bumf at "Recent changes options". I think that we (people who look there) already know what these symbols mean. SemperBlotto (talk) 19:56, 10 December 2013 (UTC)

They've just made it smaller and moved it into what was an unused white area at the top. Keep as is, we'll soon get used to it. I can only speak for myself but I filter out LOADS of stuff that is always there. Mglovesfun (talk) 20:10, 10 December 2013 (UTC)

By which I mean I mentally filter out loads of stuff. I realize now that comment is ambiguous. Mglovesfun (talk) 10:48, 11 December 2013 (UTC)

Don't worry, I think your comment was clear. :-)   —Ruakh_TALK 19:11, 11 December 2013 (UTC)

Yes, but if you have dodgy eyesight you rely on buttons being in the same place all the time - now I have to read the screen. SemperBlotto (talk) 08:30, 13 December 2013 (UTC)

I agree with Mglovesfun. If you want to hide it just for yourself, you can add dl.mw-changeslist-legend { display: none; } to Special:MyPage/common.css. (Disclaimer: not tested.) —Ruakh_TALK 23:26, 10 December 2013 (UTC)

I haven't got one of those - I like the screen to look (as far as possible) like our users see it. SemperBlotto (talk) 08:30, 13 December 2013 (UTC)

U... sers? Users? I'm not familiar with those. Is that some sort of screen-reader technology? —Ruakh_TALK 08:40, 13 December 2013 (UTC)

Although I use a CSS file I agree with Semper - personalisation of your screen mean you lose conbtact with what the casual visitor will see. Saltmarsh (talk) 10:04, 13 December 2013 (UTC)

For most of today, Wiktionary has appeared to me without the style sheet, with default fonts and placement of things. This does happen occasionally but never this long. Is this happening to anyone else? —CodeCat 23:49, 10 December 2013 (UTC)

Not to me, today or lately. DCDuring TALK 23:59, 10 December 2013 (UTC)

When that happens to me I just hard refresh until it comes back. --WikiTiki89 00:43, 11 December 2013 (UTC)

I’m also experiencing this problem. Everything works fine when logged out, but changing browsers and skins, erasing my cache and removing my custom CSS didn’t work. — Ungoliant ^(Falai) 03:07, 11 December 2013 (UTC)

I had been having the problems described, but haven't had them since simplifying my browser-specific and the general preferences and eliminating custom CSS. I still have a little JS. If anyone is interested and can't find out the settings and preferences I have, I'd happily provide them. DCDuring TALK 03:50, 11 December 2013 (UTC)

I have the exact same problem. When I log out, everything’s fine, but when I log in then the website turns into a goddamn mess. --Æ&Œ (talk) 09:57, 11 December 2013 (UTC)

I can confirm -- Liliana • 10:43, 11 December 2013 (UTC)

Is it working for you now? The Papiamentu flag was breaking Wiktionary, at least for me. — Ungoliant ^(falai) 18:49, 11 December 2013 (UTC)

It's fixed now. —CodeCat 18:51, 11 December 2013 (UTC)

That is bizarre. How/when did it become a problem, and how did you figure it out? —Ruakh_TALK 19:14, 11 December 2013 (UTC)

Yesterday. I figured it was MediaWiki:Gadget-WiktCountryFlags.css by resetting my preferences and turning them back on one by one. I figured it was the Papiamentu flag by copying the code to my custom CSS and singling the line that was causing the problem.

I couldn’t figure out why it wasn’t working though. The link of the previous Papiamentu flag is working fine (), and the syntax was correct.

Incidentally, a bunch of random flags aren’t working anymore (Portuguese, Latin and Italian are working, but not French, German and Finnish, for example). — Ungoliant ^(falai) 19:49, 11 December 2013 (UTC)

We (Wikitiki89, CodeCat, myself) want to push the new Module:languages live (meaning, we want to start changing other modules to use it). Please review. If you have any objections, please clearly announce them before 2013-12-14 24:00:00 UTC (this Saturday afternoon/evening if you're in North America, this Saturday night if you're in the U.K., sometime this Saturday or Sunday if you're elsewhere on Earth). —Ruakh_TALK 20:57, 11 December 2013 (UTC)     It's clear that we're not ready yet. Lots of arguing still going on. —Ruakh_TALK 10:46, 13 December 2013 (UTC)

Gratuitous object orientation. Switching to this module will require lots of code rewrites. As a better alternative, I wrote Module:languages/lookup, which is completely drop-in. Just change one line of code.

For reverse lookup (name ↦ code), I would write a module (or two) which computes a reverse lookup table, and later load it using mw.loadData(). And then just index that table. Keφr 20:07, 12 December 2013 (UTC)

I prefer the original proposal. The code you wrote doesn't do anything to encapsulate the data format used in the data modules, it just returns the data directly. It defeats the purpose of separating data from the access method. —CodeCat 00:24, 13 December 2013 (UTC)

I agree. However, Keφr's module does have two nice properties that Module:languages lacks: (1) it offers a mechanism for clients to iterate over all languages; and (2) it offers a slightly simplified migration path for obtaining one of the benefits of the new Module:languages, namely the not having to load all languages when you only want information about one. #1 can, and IMHO should, be integrated into Module:languages; the value of #2 is debatable, but there's little harm in either (A) integrating it into Module:languages as export.legacy or (B) renaming Module:languages/lookup to Module:languages/legacy and modifying it to use Module:languages internally. —Ruakh_TALK 01:35, 13 December 2013 (UTC)

I don't think we need such an elaborate migration path. If we aim to orphan Module:languages/alldata, that should be all we need to do, it probably won't take very long. Maybe a week or two. To convert, most existing modules would just need to be changed so that the "lang" parameter of many functions is not the language code anymore, but the Language object itself. I'm also not sure if there is a need for clients to iterate over all languages. I think the only module that currently does this is the special-purpose Module:list of languages. What use cases are there for such a thing? —CodeCat 01:47, 13 December 2013 (UTC)

But do we aim to orphan Module:languages/alldata? I think Module:JSON data sort of needs it. --WikiTiki89 01:53, 13 December 2013 (UTC)

Module:JSON data depends on being able to iterate over all languages, but not on having an elaborate migration path. (Likewise a similar function in Module:User:Ruakh that's needed for Rukhabot's updating of translation-links.) —Ruakh_TALK 02:02, 13 December 2013 (UTC)

But Module:JSON data itself doesn't cause any transclusions, and is not transcluded by anything, so if we leave it as it is, then the /alldata module will still show up as orphaned once all other modules have been converted. So we can still aim to orphan it, and it shouldn't conflict with the JSON module as long as we don't "forget" not to convert that one module. —CodeCat 02:07, 13 December 2013 (UTC)

And also not forget not to delete /alldata. --WikiTiki89 02:14, 13 December 2013 (UTC)

But we should delete /alldata. We shouldn't have multiple modules that depend on knowing exactly where all language-codes are stored; there's just no reason for that. —Ruakh_TALK 02:23, 13 December 2013 (UTC)

There is one reason, and that's to give data-module access to all the languages at once, which I guess is not that necessary if Module:JSON data's only transclusion is User:Kephir/gadgets/xte/langdata.js, which only transcludes it once. --WikiTiki89 02:28, 13 December 2013 (UTC)

I think we're talking in circles. As I said above, I think that Module:languages should provide the ability to iterate over all languages; and Module:languages/alldata should be orphaned and deleted. —Ruakh_TALK 06:15, 13 December 2013 (UTC)

As I just said, you're absolutely right as long as this iteration doesn't happen more than once per page. But if we ever need to do that in the future, it would be more efficient to have the data as a data module. --WikiTiki89 13:43, 13 December 2013 (UTC)

Oh, sorry, I didn't understand what you meant by "giv data-module access". And — I'm not sure how big a difference that makes. A data module (as opposed to a regular module) saves repeated parsing of a huge module, and it saves continual re-construction of a large data structure; but this doesn't really involve either one, it just involves the manipulation of several large data structures already provided by data modules. —Ruakh_TALK 20:23, 13 December 2013 (UTC)

It may be the only transclusion, but User:Buttermilch invokes Module:JSON data through mw:API:Expandtemplates to download the list of all language names (in order to perform reverse lookup on its own). This is the kind of use I specifically had in mind when writing the module. Keφr 07:33, 13 December 2013 (UTC)

And why do we need to do that? Time and memory are quite scarce for Lua scripts. Which means we cannot afford unneeded abstractions, and the data should flow between modules as directly as possible. Why introduce this one? Keφr 07:33, 13 December 2013 (UTC)

{{citation needed}} —Ruakh_TALK 07:55, 13 December 2013 (UTC)

Steps Lua performs to acquire, say, canonical language name:

Now:

1. Look up the language code in the languages table. Returns a table with language data, if present.
2. Look up "names" in the returned table with language data. Returns a table with names.
3. Look up the first item in the returned names table. Returns the desired name. Done.

Proposed changes:

1. Look up "getLanguageByCode" in the module. Returns a function.
2. Call function with the language code. Returns a language object.
   1. If there is a cached language object, return it.
   2. Call getRawLanguageData with the language code. Returns raw language data.
      1. Load the stable codes list. Return the data in it if present.
      2. Measure string length and choose the module to load data from.
      3. Return the data if present in the chosen module.
   3. Create a table with a "_code" field set to the language code and "_rawData" set to the data, and set this table's metatable. This is our language object.
   4. Put the newly created object in the cache.
   5. Return the newly created language object.
3. Look up "getCanonicalName" in the language object's table. This fails to return anything.
4. Look up "__index" in the language object's metatable. Returns the Language table.
5. Look up "getCanonicalName" in the returned table. Returns a function.
6. Call this function, passing the language object as its sole argument.
   1. Look up "_rawData" in the language object. Returns the raw data table.
   2. Look up "names" in this table. Returns a table with language names.
   3. Look up the first item in this table. Returns a string.
   4. Take this string to be the function's return value. Done.

Module:languages/lookup:

1. Look up the language code in the languages pseudo-list. This may fail if the language has not been queried for before.
   1. If this fails, look up "__index" in the pseudo-list's metatable. Returns a function.
   2. Call this function passing the pseudo-list and the language code.
      1. Load the stable codes list. Grab the language data if present, then put it into the pseudo-list and return it. Otherwise continue.
      2. If the above failed, measure string length and choose the module to load data from, and look up the data in the module.
      3. If data was found, put it into the pseudo-list (for future queries) and return it.
      4. Otherwise put false value in the pseudo-table to indicate a lack of data and return that.
2. Look up "names" in the returned table with language data. Returns a table with names.
3. Look up the first item in the returned names table. Returns the desired name. Done.

Now put these in order of which is the most likely to have water render in a reasonable time. Keφr 16:11, 13 December 2013 (UTC)

O.K., now try that again, this time with common sense! —Ruakh_TALK 20:18, 13 December 2013 (UTC)

There is no such thing as "common" sense. Keφr 09:34, 14 December 2013 (UTC)

It is actually possible to have a real test. It would require some work, but we can use Special:TemplateSandbox to test in real pages how custom templates/modules would perform. I'm not sure we can use it to test Modules directly like templates though, which means we would need to use custom templates as well as custom modules. (Testing modules with this would be really useful, we could suggest it to the developers). Dakdada (talk) 16:31, 13 December 2013 (UTC)

I'm not sure if analysing something by the amount of steps to be performed is a good way to gauge the performance. Something that takes more steps isn't necessarily faster or slower. Beside that, you're saying that performance is our only goal, which it definitely isn't, so you've presented a false dilemma. The real tradeoff is between speed, keeping the job queue down, ease of use, and future management. I don't see how your module takes all of those into account, it certainly seems to ignore the latter two. The original proposal is more balanced, and is (maybe!) a bit slower but is much easier to use and much easier to manage/modify later on. We should avoid "clever" solutions, they make things too hard for other editors to grasp and reduce maintainability. And we've seen where that has gotten us in the past with many of our templates. —CodeCat 16:40, 13 December 2013 (UTC)

I never said performance is the only concern. I asked for the rationale for introducing all these layers of indirection. And of course the number-of-steps analysis is just a first estimate — one also has to take into account what are the actual steps involved and whether the language employs any optimisations (although dynamic languages do not optimise very well, so one should not expect many of them) — but I doubt a more detailed one would sway the scales in favour of the other option.

I cannot see a reason why this would be harder to use than the previous system. The installed metatable ensures that the proxy table can be indexed and traversed like an ordinary table. This is a completely drop-in replacement, all it takes to migrate is to change one line of code. Future management? There will be very little to no management. As there probably should be, because the smallest change to the module would again put 3M jobs into the queue. This module just abstracts away the splitting of language data between modules. It will not do anything else. (Unless you wish to merge it with Module:language utilities. But the proxy table can be left as it is, there is nothing more it can do.)

Metatables are quite well-documented; I see nothing "clever" about using them. Keφr 20:04, 13 December 2013 (UTC)

I think the whole point was that it wasn't supposed to be a drop-in replacement. It was supposed to work differently, so that there is a break between the data format and the functions used to retrieve the data. Separating interface and implementation is a common and valuable programming tactic and helps with maintainability. Your version doesn't do that at all, nor will any other drop-in replacement. —CodeCat 20:15, 13 December 2013 (UTC)

Well, why abstract away the data format then? Any concrete benefits of doing that? Keφr 09:34, 14 December 2013 (UTC)

Encapsulation and ease of use. --WikiTiki89 16:23, 14 December 2013 (UTC)

Buzzwords. Keφr 10:53, 16 December 2013 (UTC)

Do you want to explain the concepts of "encapsulation" and "ease of use" so that you can understand why they are important? Or can't you read about them yourself? --WikiTiki89 13:10, 16 December 2013 (UTC)

The script for Jurchen is defined as Jurc but no such script exists in the script data module, causing script errors. Either change to Latn or add a definition. DTLHS (talk) 20:51, 12 December 2013 (UTC)

It's a valid ISO script code, so I've added it to Module:scripts and created Template:Jurc. - -sche (discuss) 21:10, 12 December 2013 (UTC)

It should also be added to MediaWiki:Common.css. —CodeCat 21:11, 12 December 2013 (UTC)

It shouldn't as long as it's not present in Unicode. -- Liliana • 23:57, 12 December 2013 (UTC)

Numerous entries link to Wikipedia like this: . User:Ruakh made a list of such entries some time ago. It would be good if someone could generate an up-to-date list and convert them to use {{w|Foobar}} or ]. This is clearly not a high-priority task, but it should also be a simple and uncontroversial one. Note that some links may be of the form ; they should be converted to {{w|One thing|Another thing}} or ]. Also note that links to other Wikipedias, e.g. , may exist. - -sche (discuss) 02:30, 16 December 2013 (UTC)

I've also seen a number of full urls linking to other Wiktionary entries ( instead of ]). Those mostly get fixed by patrollers, but I'm sure a few slip through. Chuck Entz (talk) 02:50, 16 December 2013 (UTC)

What in the world is  that's found in enPR transcriptions, and why is it in the 'Unicode Private Use Area', whatever the Hell that is. Mglovesfun (talk) 20:08, 16 December 2013 (UTC)

Could you maybe give an example of an entry that uses this? --WikiTiki89 20:09, 16 December 2013 (UTC)

Here's one: diff. Notice that it was added with the template {{AHD}}. Compare . DTLHS (talk) 20:15, 16 December 2013 (UTC)

The rest: brain drain, Xavier, one-way, penitence, e-dictionary, lynching, rheumatism, repentance, remorse, remuda, pilose, notorious, critter, ardent spirits, architrave, stepping stone DTLHS (talk) 20:34, 16 December 2013 (UTC)

It looks like it was meant as a stress mark. I don't know where the editor could have gotten that idea. It should be fixed to ’ (an apostrophe). --WikiTiki89 20:43, 16 December 2013 (UTC)

User:Robert Ullmann/IPAchars#enPR lists it as the last item with no description of what the character is. Does anyone know? Mglovesfun (talk) 20:50, 16 December 2013 (UTC)

That seems to be an analysis of characters used in {{enPR}}s, rather than a description of how they're used. So all it shows is that the problem has been here for a while. --WikiTiki89 20:55, 16 December 2013 (UTC)

I mean it gives @ the name 'commercial at' which is correct (the unicode name in all lower case) while this symbol either has no name or Robert Ullmann couldn't find one. Mglovesfun (talk) 21:21, 16 December 2013 (UTC)

When I edit using AWB, pages are sometimes skipped because they contain PUA characters. Are there any PUA characters which should be found in entries (outside of quotations from Usenet that actually use them)? Should someone generate a list (possibly divided into sublists for each character, if the overall list turns out to be very large) of pages that use PUA characters? - -sche (discuss) 21:13, 16 December 2013 (UTC)

I'm getting MglovesfunBot to remove Category:English nouns any time that {{en-noun}}, {{head|en|noun}} or {{en-plural noun}} is on the page. The ones with PUA characters are always skipped and must be checked by hand or not at all. And it's generally the same ones every time, to the point I can name a few without looking (do, face and falcon come to mind). Many of them I think the 'problem' is the Egyptian translation. Mglovesfun (talk) 21:16, 16 December 2013 (UTC)

May I suggest that unless the PUA characters are essential to the quotation, that they either be removed from the quotation with {{...}}, or that the quotation be replaced with one that does not contain a PUA character. --WikiTiki89 21:22, 16 December 2013 (UTC)

Egyptian translations shouldn't AFAIK contain any PUA characters. --WikiTiki89 21:22, 16 December 2013 (UTC)

Egyptian is from a time when the specific Egyptian transliteration characters were not present in Unicode. We now have them so there's no reason to use the PUA characters anymore. -- Liliana • 21:48, 16 December 2013 (UTC)

So can't we run a bot to fix them? --WikiTiki89 21:50, 16 December 2013 (UTC)

So, can we get a list of pages that use PUA characters, and maybe start replacing them? - -sche (discuss) 23:33, 21 December 2013 (UTC)

I generated User:DTLHS/private use back in July- updating it now. DTLHS (talk) 23:42, 21 December 2013 (UTC)

Thank you! :) - -sche (discuss) 00:07, 22 December 2013 (UTC)

I'd appreciate it if someone could change the link to "case-sensitive" on this page to "case sensitive". Our entry for case-sensitive just says that it's an alternative form of case sensitive, so the reader would have one less link to click through if this change is made. —Mr. Granger (talk • contribs) 03:29, 17 December 2013 (UTC)

 Done --WikiTiki89 03:32, 17 December 2013 (UTC)

As of this writing, both {{label|fr|very|rare|Switzerland|Ain}} and {{context|very|rare|Switzerland|Ain|lang=fr}} result in (very rare Switzerland Ain); vide: (very rare, Switzerland, Ain), (very rare, Switzerland, Ain). What they should actually result in is (very rare, Switzerland, Ain). {{context|rare|Switzerland|Ain|lang=fr}} correctly displays as (rare, Switzerland, Ain); vide: (rare, Switzerland, Ain). It seems, in other words, that "very" is suppressing all following commas, when it should only suppress the next comma. "Chiefly" suffers the same problem, so it does seem to be a general problem, not an issue with "very" in particular: (chiefly British, rare). - -sche (discuss) 22:36, 17 December 2013 (UTC)

I saw Atelaes (talk • contribs) recently making some changes to Module:labels that had something to do with commas. It's possible he could have broken something in the process. --WikiTiki89 22:40, 17 December 2013 (UTC)

Fixed. --WikiTiki89 23:04, 17 December 2013 (UTC)

Sorry about that. Thanks Wikitiki. -Atelaes λάλει ἐμοί 07:25, 18 December 2013 (UTC)

I have the flags extension enabled, and on Wiktionary:List of scripts, a Thai flag appears, which messes up the table. Does anyone know how this can be fixed? —CodeCat 14:53, 18 December 2013 (UTC)

Edit MediaWiki:Gadget-WiktCountryFlags.css to add a .mw-headline constraint in the selectors. Keφr 14:59, 18 December 2013 (UTC)

The first run of User:Buttermilch was quite successful; the number of atypically marked up translations decreased by nearly six thousand entries since the last dump. Now I started to target simple translations with transcriptions: single link, transcription in parentheses, and optional gender marks.

To minimise the number of falsely identified transcriptions, the bot will touch only languages with the following codes: ain, am, ar, bg, chr, cu, el, gu, he, hi, hy, ja, ka, kn, ko, ks, kv, ml, mr, myv, ru, sah, si, ta, te, th, tyv, tzm, uk, yi. These seem to fit this pattern quite consistently. There are about 2500 pages in the queue to be processed.

I will do a test run now, on about 100 pages. The proper run shall start an unspecified amount of time after 00:00, 19 December 2013 (UTC). Please take a look at Special:Contributions/Buttermilch once in a while.

Keφr 19:01, 18 December 2013 (UTC)

"...see whether Google can find it for you where this in-site search engine has failed." I think this is a poor choice of message. The "search engine has failed" bit often makes me think an error has occurred. Equinox ◑ 19:59, 18 December 2013 (UTC)

I agree. The sentence should be more like "...search Wiktionary with Google." --WikiTiki89 20:06, 18 December 2013 (UTC)

Does anyone know what is the edit count or registration time threshold for new accounts before they can save edits that contain external links without being presented with CAPTCHA? I'm making this bot and CAPTCHA is interfering (external links are generated through a reference template). --Ivan Štambuk (talk) 02:58, 19 December 2013 (UTC)

@Ivan Štambuk: all autoconfirmed users and flagged bots have the "skipcaptcha" right (Perform CAPTCHA-triggering actions without having to go through the CAPTCHA). Maybe you should get the bot flagged by a bureaucrat (or temporary confirmed by an administrator). --Ricordisamoa 06:21, 9 January 2014 (UTC)

Hi, can someone update this page?

• Change at line 7 http://toolserver.org to {{fullurl:tools:...}} in <span style="white-space:nowrap;"> '''·'''</span>

• Add CentralAuth meta:Special:CentralAuth or Special:CentralAuth at line 8
  

• from '''</span> <span style="white-space:nowrap;"> '''
  

• to '''</span> <span style="white-space:nowrap;">] / '''

Thanks, TeleComNasSprVen (talk) 09:29, 20 December 2013 (UTC)

 Done, thanks. (Approximately. I went with Special:CentralAuth rather than m:Special:CentralAuth, because in the event that either the enwikt account or the meta account is unattached, I assume that Special:CentralAuth is the relevant one. Also, I handled the HTML a bit differently.) —Ruakh_TALK 16:17, 20 December 2013 (UTC)

Is this it? TeleComNasSprVen (talk) 09:39, 20 December 2013 (UTC)

This one is a couple of years older. —Stephen ^(Talk) 10:07, 20 December 2013 (UTC)

This page was probably imported from Wikipedia, not sure it should count. Dakdada (talk) 10:18, 20 December 2013 (UTC)

It was moved from WP in 2007. The move retained the WP edit history. DCDuring TALK 16:32, 20 December 2013 (UTC)

The oldest edit we have is this one. -- Liliana • 20:44, 20 December 2013 (UTC)

"Please insert Wiktionary here." LOL. Mglovesfun (talk) 20:52, 20 December 2013 (UTC)

So in a way, the first page was a template. —CodeCat 03:06, 21 December 2013 (UTC)

Exactly. Devoid of content. DCDuring TALK 03:12, 21 December 2013 (UTC)

 Done Equinox ◑ 03:31, 21 December 2013 (UTC)

I tried to add this section of code to my common.js:

<nowiki>
// Adds User Rights link to sidebar
function toolboxUserRights() {
	mw.util.addPortletLink('p-tb', wgServer + wgScript + "?title=Special:ListUsers&limit=1&username=" + wgRelevantUserName, "User rights", "t-userrights", "Show user permissions");
 
	//Check if user exists
	if ( !mw.config.get( 'wgRelevantUserName' )) {
		return;
	}
}
addOnloadHook (toolboxUserRights);
</nowiki>

but it broke the accelerated creation links. Can help me fix my code, perhaps point me in the right direction? TeleComNasSprVen (talk) 20:39, 20 December 2013 (UTC)

First of all, get rid of the nowiki tags. --WikiTiki89 21:01, 20 December 2013 (UTC)

Nevermind, they're not actually on the page. --WikiTiki89 21:03, 20 December 2013 (UTC)

I assume you meant for the if statement to appear at the beginning of the function, rather than the end? —Ruakh_TALK 21:27, 20 December 2013 (UTC)

That fixed it, thanks! TeleComNasSprVen (talk) 21:32, 20 December 2013 (UTC)

When I use WT:ACCEL to create plural forms of Spanish adjectives, it uses Template:masculine plural of for the masculine plural, but it uses Template:plural of for the feminine plural. Is there any way to change the code so that it uses Template:feminine plural of for the feminine plural? —Mr. Granger (talk • contribs) 01:37, 21 December 2013 (UTC)

The markup generated by {{es-adj}} is correct (it uses "feminine-plural-form-of"), so the problem must be in WT:ACCEL itself. Does this happen with other languages? --WikiTiki89 02:19, 21 December 2013 (UTC)

The same problem appears to happen for Catalan. —Mr. Granger (talk • contribs) 02:47, 21 December 2013 (UTC)

I hopefully fixed it, the template to use wasn't set correctly in the script. I hope that it doesn't affect too many of the entries that were already created. —CodeCat 02:50, 21 December 2013 (UTC)

Yep, that did it. Thanks! —Mr. Granger (talk • contribs) 03:03, 21 December 2013 (UTC)

ISO 15924 gave two codes to the three scripts used by Georgian: Nuskhuri and Asomtavruli are Geok, Mkhedruli (the usual Georgian script) is Geor. Separately, the ISO gave the scripts 2–3 blocks of codes: the characters from Ⴀ-Ⴭ are Asomtavruli, and the characters right after them, from ა-ჿ, are Mkhedruli (); ⴀ-ⴭ is Nuskhuri. Currently, Module:scripts/data defines Geor (Georgian, i.e. Mkhedruli) as including the characters of Asomtavruli, but I recently added Geok (defined as including these same characters). FYI. (Note: because several of the aforementioned characters just look like boxes on my computer, I may have made some typos.) - -sche (discuss) 23:45, 21 December 2013 (UTC)

Is there any way to find all the terms that are in ja:カテゴリ:日本語_名詞_サ変動詞 but not in Category:Japanese type 3 verbs? Haplogy (話) 03:31, 22 December 2013 (UTC)

I'll take that as a no. Boy, it would be really nice if there were an easy way to do that. Haplogy (話) 00:08, 25 December 2013 (UTC)

If you know any programming language, it's not so hard, using the database dumps. You can process the xxwiktionary-yyyyMMdd-categorylinks.sql.gz dump to get the page-IDs of all pages in a given category, and the xxwiktionary-yyyyMMdd-pages-articles.xml.bz2 to get the titles of those pages (as well as to filter by namespace). You can then compare the two lists. (Let me know if you want me to generate that list for you.) —Ruakh_TALK 06:14, 25 December 2013 (UTC)

Well, I noticed this topic was brought up on Wikipedia, so I thought: why not discuss the relevance of our search function too? Basically speaking, I don't believe that the autocomplete feature which often suggests your searches for you so you save a few keystrokes is better suited toward encyclopedias and book catalogues and so forth, but I don't think it's as suitable for dictionaries. I think it's best for people to put put directly what they want to search for in the search bar, without the autocomplete distracting them along the way, and if no such term came up that they would be better encouraged to put in the request for the entry or the actual entry themselves. I know that there are ways to disable the Live Search like personal CSS/JS files and hitting Escape, but none of these are really intuitive for the average user. Even though so far I'm against it on this wiki, I would like to discuss some more of the pros and cons with this community, as well as their opinion on how the search function should behave. TeleComNasSprVen (talk) 06:36, 22 December 2013 (UTC)

I don't use the search box much, but I like the autocomplete. It can save typing for long words, and is a quick way to find words with a certain prefix. Equinox ◑ 06:38, 22 December 2013 (UTC)

I rely on autocomplete to find categories, templates and user pages. --Vahag (talk) 10:00, 22 December 2013 (UTC)

So do I. Sometimes I wish it gave a longer list of suggestions. —Michael Z. 2013-12-22 16:06 z

I use it too. —CodeCat 16:55, 22 December 2013 (UTC)

The only thing I don't like about live search is that if I type foobar and hit Enter, it takes me to foobar rather than to the search-page for foobar. That's never what I want, because when I want to go to a specific page I use the address bar rather than the search box. So I've started just clicking on the magnifying class to start with rather than typing in the search box, making the search box a bit pointless. (But that might just be me.) —Ruakh_TALK 17:58, 22 December 2013 (UTC)

The search submit button does not have a tabindex. If it had tabindex=2, then you could just hit tab, return to search instead of jumping. I added a comment to bug 29199. —Michael Z. 2013-12-22 20:06 z

Can someone edit MediaWiki:Gadget-CommentsInLocalTime.js to pull the Wikipedia version of the gadget? It seems to be more actively maintained. Keφr 22:28, 22 December 2013 (UTC)

I've been working on these modules for some time now, and I think I'm at a point where I have most of the important features in place, and everything seems to be working as I want it to. I was thinking about converting {{grc-cite}} into a redirect to it, as I did to {{grc-test}}. Before I did that, I was wondering if anyone was so incredibly bored that they felt like looking at my code and offering critiques. I'm still rather a novice programmer and I'll admit to using some inelegant approaches in the code. Many thanks. -Atelaes λάλει ἐμοί 02:48, 23 December 2013 (UTC)

Look nice. I've started Module:Quotations/la/data to get a better idea of how to use it. On thing is that it seems like you have a lot of boilerplate code in Module:Quotations/grc that should be moved to the main module (I reused most of it in Module:Quotations/la). DTLHS (talk) 06:15, 25 December 2013 (UTC)

• Some documentation would be nice. Should probably be combined with the usex module at some point. Lots of that functionality could be reused in a module for generating references which are currently dispersed in way too many templates. --Ivan Štambuk (talk) 10:53, 25 December 2013 (UTC)

  I suppose I should've thrown together some documentation before I asked for comments. I'll try and write some within the next few days. -Atelaes λάλει ἐμοί 06:28, 26 December 2013 (UTC)

  I've added some documentation at Module:Quotations/documentation. As the author of module, it is somewhat difficult to tell what is obvious and what is not. If there remain things which are unclear, please let me know. -Atelaes λάλει ἐμοί 02:31, 29 December 2013 (UTC)

  Why does each language need its own module? Can't all languages share that code, so that only the data itself needs to be split up by language? --WikiTiki89 03:11, 29 December 2013 (UTC)

  That is something I wrestled with for awhile, and am still not certain on. The advantages to having all the code in a single module are obvious, less work, easier to maintain. The advantages to having a module for each language are rather more subtle, but still real, I think. First of all, they allow for more language-specific conventions. For example, Ancient Greek has two works which are so important and oft-cited that they get their own convention, the Iliad and the Odyssey. As it stands, they can both be referenced solely by their abbreviation (Il. and Od. respectively), without the need to specify the author. As much as they're cited, this is a real advantage. Mind you, this could probably be accomplished with a single language-agnostic module, but it would require a fair amount of extra coding. The second advantage, and the one I'm more keen on, is it allows editors to be more flexible, and tailor the code to the needs of their language, and encourages more creativity in the early stages of development. As I see it, if this module ends up seeing widespread use, after a couple of years of development, it would be a relatively simple task to merge the individual language modules, and we could rest easy that the resulting code would be powerful enough to handle whatever situations it was likely to see. I worry that with a single module for all languages, it would be too much work to change conventions, or add new features, and so the process would be stifled from the start. -Atelaes λάλει ἐμοί 03:33, 29 December 2013 (UTC)

  Do we really need to be able to abbreviate the Odyssey and the Iliad? Is {{Q|grc|Homer|Odyssey|...}} really too much to write? I don't really see what there could be that needs to be tailored for each language, even the abbreviation feature does not actually need to be language-specific. Duplicating the same code for each language can cause many more problems than trying to add new features or change conventions in a centralized module. And it would definitely not be a "relatively simple task" to merge the individual language modules in the future. --WikiTiki89 03:42, 29 December 2013 (UTC)

  Having said that, you could (if you really wanted to) introduce a way to tweak the centralized module on a per language basis, but still have a centralized module do most of the work. --WikiTiki89 03:43, 29 December 2013 (UTC)

  The way would be to add more meta-programming capacity into the module, and then have it reference data in the data module. The problem is, I don't know what sort of thing people would want. -Atelaes λάλει ἐμοί 04:10, 29 December 2013 (UTC)

  Or you could just have a way to override the default functions, that way you don't have to anticipate anything. But I still don't think that that would even be necessary. --WikiTiki89 04:14, 29 December 2013 (UTC)

  I hope you haven't forgotten about this discussion. I still strongly believe that there should not be a whole module for each language. --WikiTiki89 18:57, 2 January 2014 (UTC)

  I have not. I will continue considering a way to bring all the logic into a single module, while retaining the flexibility I want. -Atelaes λάλει ἐμοί 19:02, 2 January 2014 (UTC)

  Can you list what kind of flexibility you currently have in mind? You don't have to think of how to do it yourself, I can help, but I have to understand what it is you want it to do. --WikiTiki89 19:07, 2 January 2014 (UTC)

Is it possible to display two (or more) entries in a single page? Having entries in a specific language loaded dynamically in alphabetical order as the user scrolls down would make a great user experience. --Ivan Štambuk (talk) 05:06, 23 December 2013 (UTC)

That would be nice. Viewing entries in alphabetical order adds enormously to the serendipity of using a dictionary or encyclopedia. Haplogy (話) 00:13, 25 December 2013 (UTC)

Or just an index list of links, with the current entry in the middle. OED and DARE online do this. It would be great. —Michael Z. 2013-12-25 02:16 z

That wouldn't be too difficult to make. Hardcode a list of lemmas in a Lua table, and display a subset of relevant ones in lexicographical order depending on page name as a floating table on the right. Perhaps even integrate it into headword templates. I'll put it on my TODO list. --Ivan Štambuk (talk) 10:46, 25 December 2013 (UTC)

...seems to fail when a diminutive (dim=) is provided; see e.g. kapuśniak, płaszcz, szczotka. - -sche (discuss) 08:52, 23 December 2013 (UTC)

The issue has apparently been resolved. - -sche (discuss) 19:20, 24 December 2013 (UTC)

Where is the search and replace function that you find under Advanced in the vector skin on other wikis? It is a pain in the rear end not having it here. --Njardarlogar (talk) 11:05, 23 December 2013 (UTC)

It appears as expected for me, on the far right-hand end of the "Advanced" section of the toolbar. Are you not seeing it? This, that and the other (talk) 09:02, 24 December 2013 (UTC)

Nope, it's not there. Can't remember the last time I saw it here; must have been many months ago. Can't see it in either Chrome or Firefox; and it holds true for two different computers. And for both computers and both web browsers can I see it just fine on other wikis. But, I just found out that I can see it when I log in with my bot account. So I guess there is some sort of setting that I need to change - or could my account actually be bugged? --Njardarlogar (talk) 10:37, 24 December 2013 (UTC)

I haven't been using Vector, but thought that search and replace would be nice, so I'm switching. After selecting the preference for the editing toolbar I still didn't see the icon in question, but after selecting the preference below the editing toolbar preference I did. The wording for that preference is a bit awkward, not making it clear that the search and replace is thereby selected. HTH. DCDuring TALK 13:44, 24 December 2013 (UTC)

Yeah, that was the issue. Is it not enabled here by default, or did I switch if off during an instance of sleepwalking? --Njardarlogar (talk) 14:08, 24 December 2013 (UTC)

Anyone know why categories like Category:Terms derived from Chukchi are showing up in Special:UncategorizedCategories? They are in fact categorized. - -sche (discuss) 22:09, 24 December 2013 (UTC)

There was a bug in the template that was fixed recently. The list hasn't been updated since then. —CodeCat 22:17, 24 December 2013 (UTC)

Yes. See my talkpage. TeleComNasSprVen (talk) 10:31, 25 December 2013 (UTC)

I wanted to make {{so-noun}} using {{head}} instead of duplicating the behaviour, but it seems that head can't support a rather unusual feature that Somali has, which is that nouns usually switch gender when pluralised. There are exceptions, however, and the plural gender should always be given. Should head be given a gpl= parameter, or should those few languages that need it have it in their own templates? —Μετάknowledge^{discuss/deeds} 04:37, 25 December 2013 (UTC)

You can do something like {{head|so|noun|plural|] {{g|f}}}} (it may be a better idea to just add a gpl parameter, I don't know). DTLHS (talk) 04:52, 25 December 2013 (UTC)

You can see what I ended up doing at {{so-noun}} (and you can clean it up if you want as well). I don't think I should've used {{l}} in the spans, but I needed to have diacritics removed for plurals... —Μετάknowledge^{discuss/deeds} 05:54, 25 December 2013 (UTC)

Bantu nouns also switch "gender" in the plural, except that we don't call them genders but classes. We handle those cases by specifying the plural gender as the second gender. So something like {{head|so|noun|g=m|g2=f|plural|aaaa}}? —CodeCat 23:12, 25 December 2013 (UTC)

Leaving Bantu languages aside as a different argument, that wouldn't work for Somali, because sometimes the singular's gender is disputed or varies by dialect (and the gender doesn't always change for the plural.) —Μετάknowledge^{discuss/deeds} 15:29, 26 December 2013 (UTC)

I made some changes to {{head}} and its module. It's now possible to specify alt form, script, gender etc for each form in the headword line. An example:

{{head|so|noun|g=m|plural|aaaa|f1g=f}}

December m (plural aaaa f)

Here "f1g" stands for "form 1 gender", because we couldn't use g1=, g2= etc as they were already taken. —CodeCat 04:31, 27 December 2013 (UTC)

Never, ever use {{head}} for custom inflection templates. Instead, code your own thing and use regular formatting. This is much more flexible anyway and allows you to do things that you could never do with {{head}}. -- Liliana • 15:39, 26 December 2013 (UTC)

Is there any way we can separate the rollback button and the thank‐you button so that they are not dangerously close to each other? --Æ&Œ (talk) 22:45, 25 December 2013 (UTC)

They are separated by the "undo" button. Beyond that, I'm not sure what could be done. People would probably complain if we inserted whitespace by default. Maybe someone will tip us off on how to customize the display of the buttons on a per-user basis, though... - -sche (discuss) 23:02, 25 December 2013 (UTC)

Which one is dangerously close? Are you worried that you'll accidentally roll back an edit that you'd intended to thank someone for, or are you worried that you'll accidentally be prompted to thank someone for an edit that you'd intended to roll back?
Also — are you talking about physical proximity on the screen? Like, are you worried that a tremor will lead to a misclick? Or are you talking about similarity of placement? Like, are you worried that you'll confuse the two links?
I ask because there are separate classes for the rollback-link and the thank-link, so you can easily make adjustments using CSS, but I don't really know what kind of adjustment you want. Do you want lots of whitespace after the rollback-link, or before the thank-link? Do you want one of those links to be hidden completely? Do you want one of the links to be a different color, or decorated in some way? All of those are possibilities.
—Ruakh_TALK 00:22, 26 December 2013 (UTC)

-sche, the FastRevert button and thank button are right next to each other. They’re only separated by two brackets that are dos‐à‐dos.
I am worried about accidentally clicking the rollback button. My motor skills aren’t great and sometimes I have tics (like accidentally clicking the mouse), and the proximity of the two buttons worsens the chances. I dun think that I’ll confuse the two. I just don’t want to accidentally rollback somebody’s edit when I meant to thank them. Whitespace is the best idea that I can think of now. --Æ&Œ (talk) 01:17, 26 December 2013 (UTC)

Oh, MediaWiki:Gadget-FastRevert.js. I wasn't familiar with that Gadget. Yeah, it could certainly be changed to add an em-dash or something before the (. Does anyone object to my doing that? —Ruakh_TALK 01:53, 26 December 2013 (UTC)

An em-dash seems like a good idea to me, especially since "unthanking" isn't feasible. What happens when one thanks an anon? Does the message stay as long as their session lasts? Longer? DCDuring TALK 15:03, 26 December 2013 (UTC)

It appears that it is impossible to thank anons. However, it is also nearly impossible to accidentally thank someone, because of the box that pops up asking you to confirm that you really want to thank them. —Μετάknowledge^{discuss/deeds} 15:40, 26 December 2013 (UTC)

Right, I'd forgotten about the confirmation. DCDuring TALK 17:10, 26 December 2013 (UTC)

O.K.,  done. Please revert, and/or fix, if you see any issues. —Ruakh_TALK 21:28, 26 December 2013 (UTC)

Is there any disadvantage to thanking anons who make good contributions? To me it seems to be a possible way to encourage good edits and, more likely, a way to encourage good contributors to register or at least register sooner.

I have no idea if this is feasible, but it fits in with WMF's interest in encouraging new contributors and so might get some prompt, favorable attention from the developers. I will investigate to see if it has been suggested, but won't make a suggestion or support any proposal if someone can identify significant drawbacks. DCDuring TALK 17:29, 26 December 2013 (UTC)

I don't see any such suggestion at Bugzilla. DCDuring TALK 17:48, 26 December 2013 (UTC)

See w:Wikipedia talk:Notifications/Thanks#IP thanking. For some reason I think we will not see an implementation soon. Keφr 18:52, 26 December 2013 (UTC)

Why don't you just leave a message on their talk page? DTLHS (talk) 19:19, 26 December 2013 (UTC)

Someone who isn't logged in may also not notice that their talk page has been blued or understand the implications. The red number thingy at the top of the page might grab more attention and thus lead to more actual receipt of the thanks. Limiting the thanks to a session also makes sure that the right anon gets thanked. I don't expect more than a few percent of such thanks to actually get read, certainly well less than 10 percent. DCDuring TALK 19:47, 26 December 2013 (UTC)

I think IPs do get an m:OBOD, though. On the other hand, as the name implies, the OBOD may be a bit scary. Keφr 20:26, 26 December 2013 (UTC)

Maybe the important thing is to make it easy to thank an anon while they are still around to get the message. That means that the 'thank' link should be available at Special:Watchlist and Special:RecentChanges. There are two 'bugs' at Bugzilla that request those capabilities. DCDuring TALK 22:10, 26 December 2013 (UTC)

Template:reply to, aka ping, has no documentation. It's fairly new on Wikipedia and extremely helpful there. If the template itself is the same, the doc should be just a matter of copying the Wikipedia doc, with such mods as may be necessary (pathnames, etc.). Not me, though. I follow the ancient dictum: If you don't understand it, don't mess with it. --Thnidu (talk) 21:07, 26 December 2013 (UTC)

Yes, it is the same. But no, it is not useful. ] gives the same effect with fewer Shift key presses and fewer templates. Keφr 22:07, 26 December 2013 (UTC)

Perhaps the documentation could serve to encourage folks to use ] instead. Where would one find the documentation for that??? DCDuring TALK 23:36, 26 December 2013 (UTC)

When new editors come here, people often have to fix some things that they didn't do quite right. That's not a problem in itself, everyone has to start somewhere. But it gets a bit tiresome when we have to notify them of the changes we made each time. If we don't tell them, they don't even realise we had to fix it, and they just keep doing it. So I wonder if it's possible to add this to the notification system. Something like, if someone makes an edit to content that you edited in the last X days, you get a notification. That way, people will automatically be notified when someone else fixes their edits, and maybe they'll make better edits. —CodeCat 18:09, 27 December 2013 (UTC)

How about adding a note to the welcome blurb (or sign-up page, or somewhere) telling them how to look at page histories? Teach a man to fish and all that. Equinox ◑ 18:10, 27 December 2013 (UTC)

How many people actually read that? It's useful but very generic, and I don't think people actually notice it. An actual notice might be... noticed more? —CodeCat 18:34, 27 December 2013 (UTC)

If people don't want to read stuff, they won't read it. We can dress it up in any kind of notice we want, but it will eventually be ignored by non-readers. Compare banner ads. Equinox ◑ 00:23, 28 December 2013 (UTC)

I've gotten notification when someone undid a rollback of mine, so it's already sort of there in at least one type of edit (not to mention auto-subscription to created entries, though newbies may not know about their watchlist. Maybe putting a count in the watchlist link at the top might prompt them to click it?). On the one hand, there are those hit-and-run newbies who don't know or care that the page they just created has all kinds of busted wiki-syntax coming out the seams. On the other are those whose addition of an interwiki or translation to a flawed page brings it to the attention of patrollers, leading to notification for corrections to other contributors' mistakes. Chuck Entz (talk) 00:22, 28 December 2013 (UTC)

When I notice an editor making the same mistake several times, I usually leave a message on their talk page. I think there's no beating that. --WikiTiki89 00:28, 28 December 2013 (UTC)

In your user preferences, under the Notifications tab all the way to the right, you can specify enabling notifications on Edit Reverts, and the tooltip says: "Notify me when someone reverts an edit I made, by using the undo or rollback tool." So the software and functionality are all there, we just gotta get the devs to 'adapt' it somehow if we really want this to pull through. TeleComNasSprVen (talk) 04:55, 28 December 2013 (UTC)

We could stand to give some attention to the experience of newcomers, from first visit to the point where they post to a discussion page, from which point they could be expected to speak up if they have a problem. We need to do it so that we continue to get new contributors, some of whom will be valued ones. WMF has found that positive feedback and constructive criticism are important for "editor engagement". (What a surprise!) Some users may not realize that they have a watchlist initially. To avoid losing them some more intrusive means of notification may be appropriate until they use the regular means of getting feedback.

It seems to me that the notification of reverts or undos of one's contributions should be more intrusive by default, not requiring going to the watchlist page, with the ability to switch off the notification at the preferences/editing tab being made clear.

It would be much better if changes other than undos or reversions could be noted automaically, because the absence of reversion means that there must have been some good content to the newcomer contribution. Such contributors are exactly the ones we want to encourage. The thanking mechanism achieves the purpose for those contributions that are sufficiently positive for a patroller or subsequent contributor to go through the thanking steps. But a newbie's contributions might be worth encouraging even if they would not merit a thanks if they were made by a veteran contributor.

So some fully automatic, or at least very easy, means of providing feedback to new registered contributors seems desirable. Shouldn't such "new" contributors or contributors be highlighted on recent changes, edit histories, and watchlists? DCDuring TALK 13:58, 28 December 2013 (UTC)

I didn't know what point Kephir was trying to make by reverting and unreverting my last comment because I had scrolled down and the notification line wasn't visible. (He was trying to show that the notification is very visible.) There is no substitute for a splash screen for true intrusion, but that should probably be limited to encouragements to register or to bad, obvious blunders. DCDuring TALK 15:08, 28 December 2013 (UTC)

But you got it, eventually. Perhaps one could extend the notifications UI to also show a balloon when the page is scrolled down. (Although for myself that would be too irritating and I would very quickly turn it off.) Keφr 16:44, 28 December 2013 (UTC)

I think it's visible enough. They will see it eventually. We don't want to cross the line between visible and annoying. --WikiTiki89 17:26, 28 December 2013 (UTC)

I was thinking of something that was only activated the first time, to try to draw users' attention to the watchlist, the notifications bar, and perhaps the users' talk pages. It would be a design question whether to do a splash screen or balloon, 1., once only, 2., until they responded to the notification bar the first time or otherwise disabled the more intrusive notice, or, 3., on some schedule (eg, every five notifications), until they respond or disable it.

Because it is intrusive, it would only be warranted for a very few serious purposes, eg, to attempt to cause unregistered users to register; to speed new contributors hooking into the watchlist, the notification bar, and their talk page; and for notification of some kind of radical action like an incipient block or loss of admin status. I think new users tolerate a limited amount of such intrusion for those kinds of purposes, presumably helping them. DCDuring TALK 18:54, 28 December 2013 (UTC)

I do see the use for new users, but I think I would like a feature like this for myself as well. I don't really want to watch every single page I edit, but it's nice to know when someone changed/fixed my edits. —CodeCat 19:02, 28 December 2013 (UTC)

What would you say about auto-expiring watchlist items? Keφr 19:32, 28 December 2013 (UTC)

Definitely, yes. But it should still be possible to watch some pages permanently. Also, the watchlist doesn't notify you, so it would only help when you know it's there. Auto-expiring watchlists wouldn't help completely new users, so. —CodeCat 19:42, 28 December 2013 (UTC)

So we have two issues: 1) how to enhance watchlists and 2) how to teach newbies to use them. For the first, we can pressure the developers to implement watchlist expiration, and combine watchlists with the notification system, maybe creating a second notification button (the latter part may be done in JavaScript, on our own even). For the second, some kind of post-registration screen could be created. Making "watch pages I edit" the default (if it is not already), maybe with auto-expiry time, could also help. Keφr 20:15, 28 December 2013 (UTC)

Good summary. The expiring-watched pages bug is helpful too. I haven't looked for existing bugs that bear on either of the stated needs. DCDuring TALK 21:02, 28 December 2013 (UTC)

The MediaWiki:Movepage-moved page, which is displayed after moving a page, is broken. When moving a page in a namespace other than the main namespace, the talk page links don't work. It's easy to see what the problem is (it does "Talk:Appendix:" rather than "Appendix talk:"), but I don't know how to fix it. --WikiTiki89 00:09, 28 December 2013 (UTC)

Isn't it just a matter of putting in a switch that displays differently depending on the namespace of %1? Chuck Entz (talk) 00:35, 28 December 2013 (UTC)

Well you'd have to make sure that the namespace isn't already a talk namespace, and then you'd have to make sure that the namespace actually has a talk counterpart. Is the talk namespace for namespace "X:" always "X talk:"? --WikiTiki89 00:39, 28 December 2013 (UTC)

You can use {{TALKPAGENAME}}: mw:Help:Magic words#Page names. —CodeCat 01:11, 28 December 2013 (UTC)

That would give you the name of the talk page of the page you are on (which is Special:MovePage), not the one that you moved. --WikiTiki89 01:28, 28 December 2013 (UTC)

Not necessarily. —CodeCat 01:34, 28 December 2013 (UTC)

Oh, I see: "As of 1.15+, these can all take a parameter, allowing specification of the page to be operated on, instead of just the current page." --WikiTiki89 01:58, 28 December 2013 (UTC)

 Done, thanks to CodeCat. --WikiTiki89 02:04, 28 December 2013 (UTC)

I just created an Ancient Greek entry for βράγχια (bránkhia) that categorizes into Category:Terms using script detection fallback/grc, and I'm not sure why. A randomly-selected form-of entry using the same templates, ἀγγέλου (angélou) doesn't. Do I have non-Greek characters in the page name, or am I missing something obvious? Chuck Entz (talk) 07:38, 28 December 2013 (UTC)

The only script configured for language-code grc is polytonic, and a string is identified as consistent-with-polytonic if it matches , that is, if it contains at least one character between U+1F00 and U+1FC0. Since the basic lowercase Greek letters are actually U+03B1 to U+03C9, this doesn't work as well as might be hoped. Presumably someone sought to give polytonic detection logic that would distinguish it from Grek (which we reserve for monotonic Greek), and therefore omitted the characters shared between the two scripts. Either they were not aware that grc was not configured to support Grek (or perhaps grc actually did support Grek at one point — I doubt it, but haven't checked), or else they didn't think about the fact that not all Ancient Greek words actually include polytonic-only characters.
Either way, I think the right fix is to augment the polytonic pattern to include the characters currently designated as Grek. We want all Ancient Greek text to appear in the same font, even if a given case doesn't actually include polytonic-only characters.
(Also, we might want to re-evaluate the use of script-detection logic when a language has only a single script configured anyway.)
—Ruakh_TALK 08:31, 28 December 2013 (UTC)

That would explain why there are so few Ancient Greek words in the category with initial vowels (breathing diacritics would force it into the polytonic range), and why adding an Ancient-Greek headword template to a Greek entry (which I'm still working on) would add it to the category. I'm glad I asked about that- the 2,933 pages currently in the category have to add up to a lot of wasted resources. Chuck Entz (talk) 08:52, 28 December 2013 (UTC)

This issue has been fixed. --Z 20:12, 29 December 2013 (UTC)

That left 57 entries instead of 2933, of which the majority just took a null edit to clear the problem, and the rest had the wrong language code, had only the transliteration without the original script, or had some error in template syntax. There are now exactly 4 (non-mainspace) entries left in the category. Thank you (or whoever did it)! Chuck Entz (talk) 23:31, 29 December 2013 (UTC)

It was ZxxZxxZ (talk • contribs), by editing Module:scripts/data. (Sorry, in my previous comment I stupidly failed to link to the relevant modules. I prefer to explain problems and let others fix them, so people learn how things work, but obviously that only works if I actually link to the code that needs to fixed.) —Ruakh_TALK 07:29, 30 December 2013 (UTC)

The problem was also partly from Module:utilities (it occurred after this change, I did that to find words written in wrong script , which will be listed in Category:Terms using script detection fallback/... now). --Z 07:57, 30 December 2013 (UTC)

Currently, script detection in Module:utilities just picks the first script that has any matches. But this doesn't work if you do something like {{l|sh|R-абвг}}, because it chooses Latn over Cyrl: R-абвг. A more sensible approach would be to count the number of matching characters, and choose the script with the most matches. Then it would choose Cyrl in the above case, because there are 4 matches for Cyrl versus 1 for Latn. As a special case, it could stop searching if it finds a script where the number of matches for a script equals the length of the string (that is, all characters match). —CodeCat 14:59, 29 December 2013 (UTC)

Another problem I noticed is that {{l|ru|ѣ}} (ѣ (jě), as opposed to {{l|ru|ѣ|sc=Cyrl}}: ѣ (jě)) for some reason gets script "Cyrs" instead of "Cyrl" even though "Cyrs" is not listed as a possible script for "ru". The biggest difference between "Cyrs" and "Cyrl" is the typography, not so much the characters, so there needs to be a way for it to know that if "Cyrs" is not listed for "ru" then use "Cyrl". --WikiTiki89 19:05, 29 December 2013 (UTC)

"Cyrl" doesn't match any of the old letters currently, so that's why. It's triggering the fallback where it tries every possible script for a match. —CodeCat 19:09, 29 December 2013 (UTC)

Well then what can be done about overlapping scripts? --WikiTiki89 19:51, 29 December 2013 (UTC)

They already do overlap, I don't think it's a problem. But ѣ is not in the range of characters for Cyrl, so as far as our modules are concerned, ѣ is not a Cyrl character, only Cyrs. —CodeCat 19:54, 29 December 2013 (UTC)

Why not just finding these rare cases and adding |sc=... to them by bot, instead of making the code more complicated and resource-eater? As long as we have "sc", it's not urgent to have a perfect script detector. --Z 20:09, 29 December 2013 (UTC)

My point was that if a character is not in any of the allowed for a language, then the fallback should be the language's default script rather than finding an disallowed script that does match. --WikiTiki89 20:39, 29 December 2013 (UTC)

I was replying to CodeCat actually. --Z 21:01, 29 December 2013 (UTC)

I was also replying to CodeCat. I guess I should have put that comment above yours. --WikiTiki89 21:20, 29 December 2013 (UTC)

I think in this particular case, we should think about what the difference is between Cyrs and Cyrl. If they have the same characters, then we don't need Cyrs because it is already supported by Cyrl. —CodeCat 21:22, 29 December 2013 (UTC)

I think it's because Cyrs fonts are absolutely inappropriate for Cyrl, and Cyrl fonts do not support Cyrs characters. -- Liliana • 21:34, 29 December 2013 (UTC)

Liliana beat me to it. To be more specific: ꙑ and ꙗ are the only Cyrs characters I know of that are not supported by most Cyrillic fonts. I still disagree with our choice of using ꙑ rather than ы, but ꙗ is still necessary. --WikiTiki89 21:37, 29 December 2013 (UTC)

I see them both in the same font, Cyrs just has bigger text. So what should be done when ѣ appears in Russian text? Should it fall back to Cyrs, or should we add ѣ to the characters for Cyrl, even when fonts may not have it? —CodeCat 21:39, 29 December 2013 (UTC)

ѣ is supported in (almost) all modern Cyrillic fonts, so there is no reason to fall back to Cyrs. It is mostly only ꙑ and ꙗ that don't exist in modern Cyrillic fonts. --WikiTiki89 21:42, 29 December 2013 (UTC)

If we want to support "old" Cyrillic with the code Cyrl then it can be changed in Module:scripts/data. —CodeCat 21:47, 29 December 2013 (UTC)

This chart shows the full Cyrillic character block. Cyrs covers U+0460 - U+0489 which Cyrl doesn't. In the Cyrillic Extended-B block , Cyrs covers U+A640 - U+A67F which Cyrl also lacks. —CodeCat 21:55, 29 December 2013 (UTC)

(after edit conflict) Careful with the word "old", I almost misunderstood you. Yes, we should support older Cyrillic characters, such as ѣ, ѵ, ѷ, ѳ, and even the yuses (ѧ, ѩ, ѫ, ѭ) in Cyrl, which were all used in the Civil Script, but not characters such as ѯ, ѱ, ѡ, ѻ, ѽ, ѽ, ѿ, ҁ, ꙗ, ꙑ, which were only used in the Slavonic scripts. --WikiTiki89 22:01, 29 December 2013 (UTC)

This template functions oddly, at least for me (Vector, FF 26.0, Win7). When I click on the ± the usage example disappears and nothing remains to restore it. Nor is there anything visible in the sidebar. Can this thing be disabled and disused until it does something useful rather than destructive? DCDuring TALK 15:40, 29 December 2013 (UTC)

What ±? There should be no ±. Can you provide more details (a screenshot)? . DTLHS (talk) 00:10, 30 December 2013 (UTC)

If you can't see it by moving your cursor over the usex at ], I will e-mail you the screen shot. DCDuring TALK 02:24, 30 December 2013 (UTC)

Try here. DCDuring TALK 02:28, 30 December 2013 (UTC)

I see. That must be the example sentence editor. Who wrote that? DTLHS (talk) 02:32, 30 December 2013 (UTC)

It didn't occur to me, as the only thing that happened was that the usex disappeared when I clicked on the ±. I've disabled the usex editor on my preferences and the "±" and its bad behavior are gone. Thanks

Yair may have worked on the JS for that. I guess we would need more active maintenance to keep all those things working right as the underlying software changes. A good policy from a user perspective is to select as little customization as possible. But that means that many of the gadgets will not have been tested and that eventually they will be (or already are ?) much more trouble than they are worth. Do we know which of the customizations are being used? Do we know which ones don't work? DCDuring TALK 02:53, 30 December 2013 (UTC)

I don't know, should we start requiring unit tests for every preference before it gets added globally? DTLHS (talk) 03:09, 30 December 2013 (UTC)

That might be too restrictive on experimental implementations. Perhaps experiments should have a period of experimentation before a decision is made to delete them, extend the experimentation if someone seems willing to fix defects, or make them permanent - and maintain them.

The problem at hand is that we have gadgets that are non-functioning, at least for some for some, and quite a few that seem unlikely to be in use and consequently may not actually work any more. Also some of the explanatory text is confusing. I suppose the impact of the defects on newer users isn't too bad because they don't know about the possibility. DCDuring TALK 15:04, 30 December 2013 (UTC)

The Muong language uses a modified Vietnamese alphabet, as described at w:Muong language. Would an administrator please correct Module:languages/data3/m? Just modify the entry for "mtq" to have scripts = {"Latn"}, – thanks! – Minh Nguyễn (talk, contribs) 23:00, 29 December 2013 (UTC)

 Done --WikiTiki89 23:26, 29 December 2013 (UTC)

Can we add either food or foods to Module:labels/data? I think it's a valid topic to be searching. TeleComNasSprVen (talk) 03:02, 30 December 2013 (UTC)

Many of us disagree that topics should be shown in context labels. --WikiTiki89 03:26, 30 December 2013 (UTC)

Really? I didn't know that. Anyway that's why I brought the issue here, to see what the community thinks of it. And in any case, according to the page, topical_categories are supported, like Category:en:Physics, so we can add them if we wanted to. TeleComNasSprVen (talk) 03:35, 30 December 2013 (UTC)

It creates confusion. For example:

1. (anatomy) hand

Does this mean that the term being defined means "hand" only in the context of anatomy and that there is another more usual term for "hand", or does it simply mean that the term is part of the topic of anatomy?

Any term used in the context of anatomy, likely belongs to the topic anatomy. But not every term in the topic anatomy is used exclusively in the context of anatomy. Therefore it is ok to have the anatomy context automatically categorize the topic, but it is not ok to use the context as a replacement for the topic. --WikiTiki89 03:39, 30 December 2013 (UTC)

Bingo. And in this specific case, I'm not sure any term could be restricted to the context / jargon of "food", so it wouldn't be appropriate to have a label "food" (because the only uses of such a label would be misuses). - -sche (discuss) 05:17, 30 December 2013 (UTC)

Indeed, context labels are supposed to be used where a context is needed or helpful, not purely for categorization. There was even a suggestion that adding stuff such as 'fish' or 'bird' to a context label should categorize but display nothing. There was a vote on this. I can't remember the name, someone will tell me. Mglovesfun (talk) 13:18, 31 December 2013 (UTC)

Shouldn't this start with a capitalized letter and end with a period to be aligned with {{en-past of}} and {{past participle of}}? TeleComNasSprVen (talk) 08:02, 30 December 2013 (UTC)

I think there isn't really a clear consensus on whether there should be capitals and periods in such templates. I think more people argued for removing at least the period, but I'm not sure. —CodeCat 14:11, 30 December 2013 (UTC)

I've made some major changes to this script, removing old code that wasn't needed and such. I don't think it has broken anything (I've tested all the templates in Category:Templates with acceleration), but scripts like this don't have neat lists of transclusions and it's possible that something crept through. So please test any templates you find and make sure the accelerated creation works properly for them. Report any problems here so that I can fix it, or fix it yourself if you can.

The biggest change I made was to convert the remaining languages/templates to the "internal" form of generation, where the script itself generates all the content rather than relying on a template. It's more flexible that way. The rules for generating the entries have been split off into a separate page, User:Conrad.Irwin/creationrules.js. So if you want to change anything about how entries for an individual language or form are created, you need to go there. You don't really need to edit the main script at User:Conrad.Irwin/creation.js anymore. —CodeCat 19:01, 31 December 2013 (UTC)

Is it January yet? --WikiTiki89 19:18, 31 December 2013 (UTC)

In some places, yes... —CodeCat 19:30, 31 December 2013 (UTC)

In any case I wanted to put it here so that it would be noticed, because I feel like people sometimes ignore discussions from past months. And this is important because it affects a wide range of things. —CodeCat 19:54, 31 December 2013 (UTC)

I thought we did the subpages precisely so old discussions are not forgotten about? -- Liliana • 20:01, 31 December 2013 (UTC)

You broke it. At least you broke the Bulgarian settings and I couldn't make it work for normal languages anymore when I created a dummy Spanish entry for it, using Chrome on a Mac. You sure you didn't remove any extra/old accel settings while you were cleaning up the code? In any case. Please fix it. Or just make it go back to how it was, it wasn't broken to begin with! Also, I'm using monobook and would like to continue using monobook even with the scripts and stuff. Thanks. --Neskaya _sprecan? 11:22, 2 January 2014 (UTC)

Or maybe you didn't entirely break it. It seems that bg-noun isn't accelerated anymore. I'm not convinced that this isn't the result however of your cleanup. It certainly worked last year when I last came about and then I come back this time and found it broken. --Neskaya _sprecan? 11:25, 2 January 2014 (UTC)

Next time check and think whether said old code is needed before you go removing things right and left. --Neskaya _sprecan? 11:26, 2 January 2014 (UTC)

I did remove the old settings because all the templates in Category:Templates with acceleration had been checked. If I missed any, then that's because they weren't in that category. And that's why I created this discussion in the first place, to make sure that any that may have been missed are checked and fixed. Thank you for reporting it. As for {{bg-noun}}, I looked through the history of the template and it looks like it has never been accelerated at all. —CodeCat 15:43, 2 January 2014 (UTC)

Oh, and there's an easy way to see whether acceleration is broken or just not available. If the link is just red, then it's not an accelerated link. If it's red but with green dashes underneath, that means it's accelerated but something went wrong. —CodeCat 15:44, 2 January 2014 (UTC)

There's a reason bg-noun wasn't accelerated -- it's sub templates and such like the one used in the inflection table at the parent page of https://en.wiktionary.orghttps://en.wiktionary.org/w/index.php?title=%D1%81%D0%BD%D0%B0%D1%85%D0%B8&action=history that were and still are accelerated but now they're broken. There's a reason they're not in the category, because the request to accelerate them was a long time ago and I don't think the category existed then. Bulgarian regular noun inflected forms because I didn't want to run a bot to create them. And by the way can you change it back to the way it used to be of having solid green links or at least make the underlining solid? It's very difficult to focus in the dashed underline and it doesn't look good in some browsers. On a high cognitive fog day it's harder to tell that the underline is there at all. I'd be willing to settle for a compromise of a solid underline but the dashed underline makes it significantly difficult to read the text above the underline and check which entry I'm creating until I get there. --Neskaya _sprecan? 22:59, 2 January 2014 (UTC)

The links are still green. Green dashes means that the script wasn't able to generate an entry for that link. A normal accelerated link, one that actually does work, is still green. —CodeCat 23:11, 2 January 2014 (UTC)

Oh okay. Apologies for snapping. But could you PLEASE make the Bulgarian nouns that were accelerated before work again? I can see if I can find you the original request that I submitted to Conrad, if that would help you any. --Neskaya _sprecan? 23:19, 2 January 2014 (UTC)

What do you mean with "again"? They have never been accelerated... —CodeCat 23:23, 2 January 2014 (UTC)

Yes. bg-noun-f-a1 WAS in fact accelerated. Go look at User talk:Conrad.Irwin/creation.js and you can find the original request. Go look about 600 or 700 back in my contributions and you'll see hundreds of new pages in Bulgarian created ACCELERATED. That template covers a majority of Bulgarian noun inflection tables, and was, until you broke it, accelerated. Did you even look at the 1 diff that I linked? It's a Bulgarian page. It was created with the accelerated script. Please. Fix. It. --Neskaya _sprecan? 23:42, 2 January 2014 (UTC)

Drop the attitude. If you want it fixed and can't be civil about asking for a fix, then you can fix it yourself for all I care. I added acceleration for Bulgarian nouns back in. I tested it on агентин and it seems to work. I added acceleration for some of the forms that had none before, but the definite object form and the count form are the same and this clashes. The template would need to be changed so that it combines these two forms when they're identical (unless they're always identical). —CodeCat 00:41, 3 January 2014 (UTC)

Actually, I can't fix it myself. I have no technical skills in terms of templates and scripts and coding, and I never have. Because of my dyslexia and the way it manifests, I probably never will. I do appreciate adding the acceleration to templates that didn't have them before, that'll give me more to do. If you give me a list of the templates that you added acceleration for the forms that had none before, I can look it over and check in my books as to whether the definite object form and the count form are always the same, and for which forms, and get back to you, so that that can be done.

Secondly, sure, getting cooperation is hard, but it certainly doesn't happen if you don't try to begin with. "so if every option is bad, I figure I might as well just do what I think is best." Regardless of if you're going to do it, it's still best practises to at the very least post a notice ahead of time. That's not too much to ask. If you're trying to improve something, I do understand that, but improvements should not be made at the cost of functionality and things falling through the cracks. I'd ask that you go through, look at the "old code" that you removed, and add back any template acceleration that you took out, because inevitably someone's going to go and try and use it. Inevitably there are going to be more usecases of templates which weren't in that category of yours, that previously had acceleration and are now broken. Fix the backend, but don't remove functionality. --Neskaya _sprecan? 01:32, 3 January 2014 (UTC)

That's not actually possible, because the original code wasn't set up on a language-by-language basis like the new one is. All languages used the same code, that's part of what made it so hard to maintain. It made many assumptions that were valid for some languages, but not for others. And then people kept adding exceptions to things until nothing did what it was originally meant to do. For example, when converting the Hebrew acceleration, I saw that they had used the gender template part (which are actually kind of obsolete to begin with) to put in a request for transliteration instead. It was so inflexible that people had to resort to things like that... Eventually someone had decided to write completely new code for making the entries, but they left the old code in with the new side by side, making it an even bigger mess. What I did was improve upon that new code, leaving them both for a while, and now I converted all the remaining generation rules to the new version. The new code is hopefully easier to customise. At the very least, it doesn't make any assumptions about how entries are formatted beyond the very basic things like language header, POS header, headword line, definition. And it's trivial to override the defaults too, it is specifically made so that it's easy to do that. —CodeCat 01:57, 3 January 2014 (UTC)

In Bulgarian, is the count form (when it exists) always identical to the object definite singular? Without any exceptions? If so, then I can change it so that it always creates an entry for both forms whenever you create an entry for one of them (as long as the noun has both forms). —CodeCat 02:15, 3 January 2014 (UTC)

Honestly, I'm still trying to figure that out, but it certainly looks like that to me. I haven't found a case yet (across all of the templates) where they're different, so I'd say that go ahead and change it so that when they both exist, it makes both forms? And in which case, I'd also say that the count form should be the second definition line. And again, thank you, and I'm sorry I snapped quite as much as I did initially. I do appreciate what you've done to fix this and make it work again. --Neskaya _sprecan? 08:46, 4 January 2014 (UTC)

In the future, please take the time to start a discussion about this BEFORE you undertake changing something like this. Find out what people are actively using it, in what languages. Because not everything is neatly in categories, not everything fits in the case and some things will ALWAYS fall through the cracks if you just go and "clean up old code" without talking to people first. I may not be the most technically inclined person, but even I can see that the way that you went about this is very far from ideal behaviour and consideration, especially for a sysop who is supposed to represent our community. --Neskaya _sprecan? 00:02, 3 January 2014 (UTC)

I'd like to see you try to get everyone to cooperate with you on things like this. A lot of the time people are just not interested and don't tell me anything when I ask, or they start asking completely irrelevant things rather than answering my request. It's only when things break that it gets their attention. Right now we have a module (Module:languages) that is ready for use and has been for weeks, but hasn't been implemented because nobody has been bothered to give their assent, and it seems that everyone has forgotten about it again. It's just one of many "changes" that are left half-finished because of inertia. —CodeCat 00:41, 3 January 2014 (UTC)

If you ask and no one says anything, that's one thing. If you don't ask at all, that's an entirely different story. --WikiTiki89 00:45, 3 January 2014 (UTC)

Well, more often than not, I ask, get no response, and then when I go ahead everyone acts like I never even discussed it. I can't win, so if every option is bad, I figure I might as well just do what I think is best. —CodeCat 00:49, 3 January 2014 (UTC)

It doesn't matter whether other people notice or not, you should always do what is right rather than what is easiest. You're doing great work, it would just be helpful if you let others know before making major changes. If no one wants to discuss it, that's their problem, but you need to give them a chance just in case. --WikiTiki89 00:53, 3 January 2014 (UTC)

When people respond, they often seem to have already decided to say no, and they're expecting me to convince them. But that's an uphill battle when it concerns technical changes that relate more to implementation details that nobody really knows or cares about. How can I convince them when they don't understand the subject matter? Some people also go with "if it's not broken, don't fix it", but when I try to explain what I'm trying to improve they don't care and just say no. Sometimes I think certain people are just being obstructive for the sake of it, or because they have personal issues with me. It's more politics and bureaucracy than it is a collaborative project... —CodeCat 01:04, 3 January 2014 (UTC)

Also, that is the nature of the task. People can't tell you something is broken until it's broken. If you do not wish to get yelled at, whinged about, sniped at, and so on do not volunteer to code. You can always make tools for yourself alone if you don't want to deal with the community. - Amgine/ ^t·e 01:07, 3 January 2014 (UTC)

Or I volunteer and just try to ignore people. I know a lot of people don't like that idea, but I suppose respect goes both ways. I make mistakes like everyone else, but why do people get upset instead of helping me fix them and improve things? I'll listen to criticism if it's constructive. I think after all this time, it has kind of gotten into my mind that people who can't give constructive criticism just aren't interested in improving Wiktionary. I figure, if they really wanted Wiktionary to be better, they would help others with making it better too. But instead they just complain and get upset with me. So I stop listening and just do my own thing. It doesn't matter either way. Wiktionary doesn't really have a community. It's just separate people who don't want others to get in their way. —CodeCat 01:22, 3 January 2014 (UTC)

It is certainly one approach and point of view. However, if you ignore input on widely used tools you may find yourself at odds with the community which does, in fact, exist and which agreed to give you your bits. I know you may be feeling persecuted at the moment, but consider that any fuss is feedback which just a few lines above you were complaining you did not receive. It may not be in the format you would prefer, but it is rather important it be acknowledged if you ever want to get more-constructive styles of input. - Amgine/ ^t·e 01:31, 3 January 2014 (UTC)

Also, Wiktionary does have a community. It's had a community for as long as I've been a part of this site. This community has in fact formed long term friendships, and such, and a fair number of such. It DOES have a community, though I do understand that you might not feel like part of it right now. --Neskaya _sprecan? 01:35, 3 January 2014 (UTC)

It seems like I am absolutely the only one on this project that holds this view, but I really appreciate CodeCat and their myriad technical improvements to the site. I tend to think they generally make their changes in a manner which respects the community and is open to its feedback. I also think they tend to take responsibility for their edits and clean up their messes. Also, they are absolutely, 100% correct about the fact that making proposals about technical matters nearly always amounts to nothing. No one gives a shit until something is broken, which invariably happens when major technical changes, even the most cautious, tested ones, are made. And Amgine, Neskaya, I'm really sorry, and I know that both of you have a lot of history on this site, but get over yourselves, please. Both of your contributions combined from the past year can fit on a single page. CodeCat is making sweeping improvements all over the board, and you just have to stop by and bitch about some minor feature that hasn't been used in seven years being broken? That's unreasonable, and it's not in the spirit of a healthy community, or at least one that hopes to retain useful contributors. -Atelaes λάλει ἐμοί 20:49, 3 January 2014 (UTC)

+1! Hyarmendacil (talk) 21:28, 3 January 2014 (UTC)

I think many editors here including me appreciate CodeCat's work here. It's not the work itself, but the way it is sometimes done that irritates people, not necessarily even the mistakes, but some of the design choices that could easily have been asked about first. --WikiTiki89 20:54, 3 January 2014 (UTC)

I've migrated to and away from this project over time, I admit. I'm not the most active sysop, I admit. But I do come, and I do work on things, and I've never entirely gone and said I left. Also, "minor feature that hasn't been used in seven years"? Okay, sure. WT:ACCEL might be a minor feature overall, but in fact it's still something that I use nearly every single time I edit. I use it across multiple languages and it's one of the most useful tools aside from perhaps the translation adder that we've had in terms of editing improvements, as I'm not one to run bots or the like. So please. I can understand perhaps if you don't use it, but don't go so far as to assume how much something is or isn't important to someone else? --Neskaya _sprecan? 08:46, 4 January 2014 (UTC)

Yes, Atelaes, you seem to feel some people are more equal than others. But if you re-read my comments above I didn't judge CodeCat's work - because I'm not qualified to do so. I commented on xyr interactions in this section - and how it is not possible to volunteer code without getting negative feedback. - Amgine/ ^t·e 19:08, 5 January 2014 (UTC)

• On a related topic, how can I request a template to be "Accelerated"? The one in question is Template:ast-adj. --Back on the list (talk) 09:24, 4 January 2014 (UTC)
  • There's some documentation at WT:ACCEL. Does that help? —CodeCat 19:13, 5 January 2014 (UTC)