Wiktionary:Grease pit/2012/November

Editing raw watchlist[edit]

For quite some time now, the 'Edit raw watchlist' button on my watchlist does not work, giving an 'Internal Server Error'. I'm wondering why and whether anyone else has the same problem. --JorisvS (talk) 16:11, 1 November 2012 (UTC)[reply]

Works for me. —An gr 15:40, 2 November 2012 (UTC)[reply]
It happens if you have more than 'n' entries in your watchlist (where 'n' is some largish number). SemperBlotto (talk) 15:42, 2 November 2012 (UTC)[reply]
'n' has been somewhere around 21K. I'm unable to get it to work at 20,944. I can get it to load at about 22K, but not save. I am copying chunks of it to a userpage where I wikilink it and unwatch what I don't want. Ruakh also has some magic that will enable you to delete large blocks, based on the characters contained in the page names (eg "Citations:", non-ascii, initial caps, etc).

This is entirely unsatisfactory. I think I would like to clean out anything in principal namespace added (re-added?) to my watchlist by my activity more than a year ago. DCDuring TALK 17:00, 2 November 2012 (UTC)[reply]

I'm simply deleting everything on my watchlist that is in principal namespace except for items connected with taxonomic names and their vernacular equivalents. DCDuring TALK 04:53, 9 November 2012 (UTC)[reply]

Diminutive of adjectives[edit]

The {{diminutive of}} template seems to put things into a "xx noun diminutive forms" category, even if the word is not a noun. See (deprecated template usage) fericulus as an example. Can we do something about this? SemperBlotto (talk) 18:30, 3 November 2012 (UTC)[reply]

You can add a pos=adjective parameter to put the word into an "xx adjective diminutive forms" category. —An gr 18:43, 3 November 2012 (UTC)[reply]

Form of templates to the best of my knowledge are supposed to be used on definition lines, but aren't always. {{initialism of}} is another one that works well in etymologies. Mglovesfun (talk) 11:20, 4 November 2012 (UTC)[reply]

Audio bot[edit]

Could somebody please check if my bot does not spoil anything while adding audio files? I am not active on en.wiktionary and don't check latest policy changes. Bot contributions: Special:Contributions/DerbethBot. --Derbeth ^talk 08:31, 4 November 2012 (UTC)[reply]

I've checked before and never found a problem yet. Mglovesfun (talk) 11:23, 4 November 2012 (UTC)[reply]

Not a major issue, but "Alternative forms" sections are supposed to be before Pronunciation sections. diff --Yair rand (talk) 02:09, 5 November 2012 (UTC)[reply]

Ok, I have modified the bot to look for "Alternative forms". --Derbeth ^talk 19:49, 6 November 2012 (UTC)[reply]

Special characters and Lupin's popups[edit]

For those of us with Lupin's popups enabled, special characters in L2 headers like ǃXóõ (yes, I mean the IPA symbol (ǃ), not the exclamation mark (!)) make the L2 header not show up in Lupin's popups. For example if one hovers over ǯau, there is no header, and even worse if one hovers over zau, it gets swallowed up by the Lojban section and numbered as if it was another Lojban definition. Is there a quick fix to solve this? —Μετάknowledge^{discuss/deeds} 01:29, 5 November 2012 (UTC)[reply]

Yes: use exclamation points. --Wiki Tiki 89 07:58, 5 November 2012 (UTC)[reply]

That's like curing the common cold by killing the patient. —An gr 21:49, 5 November 2012 (UTC)[reply]

Problem with category display in tabbed languages[edit]

On the page yigirmi, the categories aren't being sorted into the correct tabs. The categories for the Old Turkish entry are appearing in the Crimean Tatar section. —CodeCa t 20:58, 6 November 2012 (UTC)[reply]

Fixed. — Ungoliant ^(Falai) 22:51, 6 November 2012 (UTC)[reply]

Oh, I see. I have seen this happen on other pages too, though. And I don't think the language name was the problem there. —CodeCa t 22:58, 6 November 2012 (UTC)[reply]

Do you remember any? Since Tabbed Languages might be enabled by default soon, we should look into any problems it has. — Ungoliant ^(Falai) 23:02, 6 November 2012 (UTC)[reply]

I don't remember which pages specifically but I think I mentioned it before. —CodeCa t 23:07, 6 November 2012 (UTC)[reply]

Special:UncategorizedPages[edit]

This pages and its relatives haven't been run since October 31, 2012. Usually they are run every 4 days or so, it seems to me. Does anyone know why? DCDuring TALK 20:13, 8 November 2012 (UTC)[reply]

It's really useful as well. Mglovesfun (talk) 22:20, 8 November 2012 (UTC)[reply]

If you are sure that this is not a monthly script, it might be worth to bring this up in https://bugzilla.wikimedia.org under product "Wikimedia" and component "Site configuration". --Malyacko (talk) 12:39, 9 November 2012 (UTC)[reply]

App for adding citations to Wiktionary[edit]

There should be an app for adding citations to Wiktionary. It would work like this: 1) go to a website 2) click on a word or phrase, which would bring up the corresponding Wiktionary page 3) Choose the corresponding definition on the WT page 4) press "save" and the quote would be added. --Adding quotes (talk) 21:18, 10 November 2012 (UTC)[reply]

I don't see how that could work in the general case, but apps might be designed for quotations from specific web-sites — that of The New York Times, say. (I'm not sure quite how useful it would be, but it's at least possible.) —Ruakh_TALK 21:45, 10 November 2012 (UTC)[reply]

template:audio[edit]

Although I think the new audio player is ugly (DCDuring rfced it for similar reasons), there's a more pressing problem: any entry that uses the template and hasn't been edited since the change no longer works. The old icon is there, but nothing happens if you click it. Is someone going to have to go through all the transclusions and do a null edit on the ones that haven't been edited? Chuck Entz (talk) 16:34, 11 November 2012 (UTC)[reply]

Does anyone know where the code for the audio player is located? {{audio}} gives me no hint as to that. --Wiki Tiki 89 16:40, 11 November 2012 (UTC)[reply]

It's a new extension that was deployed all across Wikimedia: mw:Extension:TimedMediaHandler. --Yair rand (talk) 22:21, 11 November 2012 (UTC)[reply]

Well it sucks (no offense). There should be a preference to be able to chose to use your browser's default player. --Wiki Tiki 89 09:35, 12 November 2012 (UTC)[reply]

If "your browser's default player" always works with any media and never has shown plugin and encoding issues that end up as questions in the Wikimedia support forums, and supports displaying subtitles that are translatable through user contributions, I'd say you're really lucky! Could you provide an example address for "The old icon is there, but nothing happens if you click it" please? And for specific problems with the new audio player please feel free to check existing (or file new) bug reports in bugzilla.wikimedia.org under "MediaWiki Extensions > TimedMediaHandler". Thanks for your help in improving it and make it suck less! ;) --Malyacko (talk) 13:16, 12 November 2012 (UTC)[reply]

Also see https://blog.wikimedia.org/2012/11/08/introducing-wikipedias-new-html5-video-player/ for more info. --Malyacko (talk) 13:17, 12 November 2012 (UTC)[reply]

I will admit I have not tried the video player, but the audio player is awful, with the menu always opening behind something (not to mention it is too big). Try listening to the audio clips on w:IPA vowel chart with audio and see for yourself. --Wiki Tiki 89 13:43, 12 November 2012 (UTC)[reply]

Yeah, that's tracked in https://bugzilla.wikimedia.org/show_bug.cgi?id=41928 --Malyacko (talk) 15:09, 12 November 2012 (UTC)[reply]

Malyacko, we don't have any use for subtitles here. We use audio for giving pronunciation samples. The "CC" button is useless here. --Yair rand (talk) 23:11, 12 November 2012 (UTC)[reply]

Problem with targeted translations[edit]

I noticed this oversight before but it kind of became really obvious now. When you want to select which languages you want in the targeted translations, you have to select them from the translation box. But what do you do if not all the languages you want are in there? Do you have to go and look for another entry that has translations for all the languages you want? What if there are none? —CodeCa t 23:58, 11 November 2012 (UTC)[reply]

I never thought of that. You can add a dummy translation, select the language for targeted translation, and press cancel instead of save. Or you can use water. — Ungoliant ^(Falai) 02:17, 12 November 2012 (UTC)[reply]

That's really a workaround though, not a proper solution... —CodeCa t 02:19, 12 November 2012 (UTC)[reply]

I agree. The whole setup isn't a very good design, but I can't figure out a good replacement design. --Yair rand (talk) 11:32, 18 November 2012 (UTC)[reply]

User:Babel AutoCreate[edit]

This user keeps re-creating Category:User zh and its subcategories even though they are all empty. How do we stop that from happening? —CodeCa t 13:46, 12 November 2012 (UTC)[reply]

Personally, I see nothing wrong with having these. --Wiki Tiki 89 13:50, 12 November 2012 (UTC)[reply]

They should be Category:User cmn instead, because 'zh' is not a language. Regardless of that though, why is it creating empty categories? —CodeCa t 13:54, 12 November 2012 (UTC)[reply]

Why do Babel boxes have to match up with Main namespace languages? If I had a Red Sox Babel box, does that mean we need a Red Sox language? --Wiki Tiki 89 13:55, 12 November 2012 (UTC)[reply]

The consensus (by vote) is that we only allow userboxes to show what languages you speak, and other skills useful for Wiktionary. Speaking 'Chinese' is not a useful skill for Wiktionary because we don't treat it as a language. It would be like stating you speak Slavic. If we want to start allowing user boxes for families then that would be a different matter... —CodeCa t 14:10, 12 November 2012 (UTC)[reply]

So {{User ang}} and friends are all out then also? There are people who can read and write Chinese but can't speak it at all. They can't really be said to know any spoken dialect like Mandarin or Cantonese so the best word for it is just "Chinese". --Wiki Tiki 89 14:19, 12 November 2012 (UTC)[reply]

As far as I know, even written Cantonese is distinct from written Mandarin. And I don't see why we wouldn't want a category of people who have knowledge of Old English, since Old English is a language on Wiktionary that one can contribute in. That said though, I think some time ago there was a proposal to include dialects and such in Babel so that we could be more specific about what we know. So that way we could say we know UK English, for example. —CodeCa t 15:03, 12 November 2012 (UTC)[reply]

I guess I was thinking of Literary Chinese ({{lzh}}), which we have as a separate language. --Wiki Tiki 89 15:21, 12 November 2012 (UTC)[reply]

I think Literary Chinese is more like what Latin was in the late first millennium, Sanskrit in the time of Middle Indic, or Church Slavonic; a language artificially frozen in to a standard written form that doesn't correspond to any currently spoken language. —CodeCa t 16:00, 12 November 2012 (UTC)[reply]

My solution: fuck with MediaWiki:Babel-autocreate-user and hope that some documentation crops up at mw: or somewhere. —Μετάknowledge^{discuss/deeds} 16:28, 12 November 2012 (UTC)[reply]

We could either block the user or protect the categories it's trying to create. —CodeCa t 17:04, 12 November 2012 (UTC)[reply]

The "User" is mw:Extension:Babel. I suspect that blocking Babel Autocreate and protecting the pages would have no effect. --Yair rand (talk) 23:14, 12 November 2012 (UTC)[reply]

When experimenting is ridiculously simple, I see no reason to only suspect something. So: I deleted and admin-protected Category:User zh. Let's watch what happens. Next step would be blocking, I guess. —Μετάknowledge^{discuss/deeds} 23:28, 12 November 2012 (UTC)[reply]

This "user" (actually a script) has been blocked, which I find comical. The script only adds categories for lects when users list proficiency in those lects; if an unwanted category is added, the solution is the fix/inform the users who are listing proficiency in the lect, and delete and protect the category against recreation; I had to do that to a Zazaki category. But mostly the script adds valid categories, so I've unblocked it. - -sche (discuss) 17:40, 13 November 2012 (UTC)[reply]

Expanding the list templates[edit]

We have had complaints that articles on Wiktionary take a long time to render. For example, the "a" article takes 50 seconds, much longer than the 30 second timeout. The main culprit (28 of those 50 seconds) is {{list helper}}. Basically, it's a flawed concept and should have been killed with fire shortly after it was introduced. Luckily it's fairly easy to put the genie back in the bottle: we can just run the individual list templates through Special:ExpandTemplates. That would turn Template:list:Latin_script_letters/da into this, or with a bit of manual editing, this.

When Lua is introduced, maybe you could reintroduce {{list helper}} as a Lua module. But I don't want to leave these articles broken for any longer than is necessary, and Wiktionary might never find a community member to write the relevant Lua module. -- Tim Starling (talk) 00:35, 13 November 2012 (UTC)[reply]

We have been trying to make that template a little easier to deal with. I don't think expanding the template is a good solution, because we do still want to keep the individual list templates in place. We can safely subst calls to {{list}} itself though, so a bot can run through and fix that now. I have a fairly good idea of what to do with {{list helper}}, but that will require fixing all of the list templates that use it. My idea is to just have a single parameter where one provides all words, instead of having one parameter per word, more parameters for alternative forms, etc. See {{zu-concord-table}} for a general idea: {{zu-concord-table}} fulfills the role of {{list helper}}, while its subtemplates are analogous to the individual list templates. —CodeCa t 00:51, 13 November 2012 (UTC)[reply]

I don't think substing calls to {{list}} will do much. I also don't think expanding the {{list helper}} uses is a good idea. We can leave it as is until Lua is deployed, rather than change all the templates just to undo them a few months later. I don't think we'll have trouble Lua-izing the templates. --Yair rand (talk) 01:15, 13 November 2012 (UTC)[reply]

CodeCat: Would you want to use {{list linker}} in the invocations of {{list helper}}? {{list linker}} by itself might be quite slow. Yair: I don't think it's acceptable for it to be left like it is for half an hour, let alone for a month or two. I can't believe you would put up with having articles just not work at all. -- Tim Starling (talk) 01:30, 13 November 2012 (UTC)[reply]

Substing calls to {{list}} will not help much with the slowdown, but it will not hurt either, and make the use of list templates a bit more transparent (why use {{list|en|days of the week}} when {{list:days of the week/en}} is clearer?). The problem with {{list helper}} currently is that it tries to handle all the formatting, which is fairly typical of Daniel's templates. They try to do everything, which makes them overly complex and slow. We don't need {{list linker}} really, because a lot of the complexity in that template is not necessary. I will try to make a replacement template for {{list helper}}, to show what approach I had in mind. —CodeCa t 01:37, 13 November 2012 (UTC)[reply]

{{list}} has been in common use for years. The entries appear to work. We might be able to speed up the template slightly be just wrapping the Xyzy around the whole list rather than each individual link. This would also allow eliminating multiple uses of languagex per linker. --Yair rand (talk) 01:39, 13 November 2012 (UTC)[reply]

I have now made an improved version: User:CodeCat/list helper. The basic setup of the template has not changed, but the giant list of 60 or more if-statements has been replaced with a single use of {{{list}}}. I have created a list template at {{list:days of the week2/nl}} to demonstrate how it's used. It barely differs at all from {{list:days of the week/nl}}, so fixing all of our old templates should be easy. —CodeCa t 02:16, 13 November 2012 (UTC)[reply]

This kind of loses the point. It doesn't automatically link anything. We should change over every one of our 416 list templates to a more complicated format, just to change them back afterward? --Yair rand (talk) 02:26, 13 November 2012 (UTC)[reply]

The automatic linking is what caused the slowdown in the first place. Manual linking is simpler, because you include exactly as many links as are needed. Just compare a single call to {{l-self}} to {{list linker}} and all the extra code in {{list helper}} surrounding it. I'm not sure what you mean by a more complicated format, though, nor do I understand what you mean with changing them back. —CodeCa t 02:35, 13 November 2012 (UTC)[reply]

After Lua is deployed, there won't be any need for manually linking each item. Thus, we'd probably change it back afterward. --Yair rand (talk) 03:13, 13 November 2012 (UTC)[reply]

@Yair rand: Lua will make the list-templates less expensive, but it won't make them more helpful or valuable. —Ruakh_TALK 20:10, 13 November 2012 (UTC)[reply]

Support CodeCat’s solution. Very simple, very effective. — Ungoliant ^(Falai) 03:31, 13 November 2012 (UTC)[reply]

I've now replaced all list templates called by a with my own. The page still loads much slower than it should, but I do think there is some improvement. I am curious whether my changes had any effect. Tim, can you see any difference? —CodeCa t 03:38, 13 November 2012 (UTC)[reply]

Yes, it is down from 50 to 27 seconds, with the lists still taking about 6 seconds of that 27. Well done. I will have a closer look at the other 21 seconds to see if there are some easy targets there. -- Tim Starling (talk) 03:47, 13 November 2012 (UTC)[reply]

6 seconds is still a fair bit just for a few template calls though. Are you able to see which part of the lists is using the most resources? —CodeCa t 04:28, 13 November 2012 (UTC)[reply]

I don't currently have a breakdown of where that 6 seconds goes, but I can try to get that for you. The other 21 seconds seems to be fairly diffuse, a combination of fast but heavily-used templates like {{term}} and {{etyl}}, and big tables like {{Portuguese personal pronouns}}. -- Tim Starling (talk) 04:40, 13 November 2012 (UTC)[reply]

Support CodeCat's solution. - -sche (discuss) 17:28, 13 November 2012 (UTC)[reply]

I think the simplest way to migrate these templates would be to use a different name for the new helper, like what CodeCat is doing at the moment except in the template namespace rather than the user namespace. Say, {{list wrapper}}. That way, you can migrate all the list templates without breaking anything, and delete {{list helper}} at your leisure. -- Tim Starling (talk) 03:17, 13 November 2012 (UTC)[reply]

I've always said Daniel Carrero was more interested in testing out his own ability to write templates than in writing templates we actually need. This is far from a one-off, though I'll also recognize all the good work here's done here. Mglovesfun (talk) 10:15, 13 November 2012 (UTC)[reply]

Streisand effect on WOTD[edit]

Someone modified the wording of the definition of (deprecated template usage) Streisand effect, and now it's out of sync with the definition in the WOTD template on the main page. Will someone please replace the definition in the WOTD template for today with the updated one? I'm not an administrator, so I do not have the ability to do this myself because today's template is protected through being featured on the main page. Astral (talk) 14:26, 13 November 2012 (UTC)[reply]

Done. - -sche (discuss) 17:30, 13 November 2012 (UTC)[reply]

bot task: categorise language proficiency categories[edit]

I have a list of uncategorised language proficiency categories here. Is it possible to automatedly add [[Category:User foo]] to each category in that list, where foo is extracted from the pagename, being the bit that's in between User and the hyphen? - -sche (discuss) 21:20, 13 November 2012 (UTC)[reply]

Done. DTLHS (talk) 22:54, 13 November 2012 (UTC)[reply]

Thanks. - -sche (discuss) 22:48, 15 November 2012 (UTC)[reply]

Hittite Wiktionary[edit]

Are there any entries in Wiktionary for Hittite? If so, can you please let me know the digraph for Hittite and how I can access all the entries. Is there a list of the other ancient languages for which there are Witionary entries?

Please see Category:Hittite language, where a directory of Hittite entries can be found, as well as metadata on Hittite, including the trigraph {{hit}}. —Μετάknowledge^{discuss/deeds} 06:44, 14 November 2012 (UTC)[reply]

Bureaucrats and sysops right configuration change[edit]

Hello,

I would like to notify you a pending configuration change will remove the possibility for the bureaucrats to remove administrator or bureaucrat flags. New requests will have to be asked on meta:Steward requests/Permissions.

A thorough configuration and bug database check have shown there isn't any indication the community requested the possibility of flags withdrawal, and so we're reverting to default behavior.

If you would like to keep this change, feel free to launch a local discussion. Note a discussion is probably needed too on meta. to know if this flag can be assigned to wiki and if so, under what conditions.

For more information, relevant pages are:

I'm at your disposal for more information on this issue. --Dereckson (talk) 19:51, 14 November 2012 (UTC)[reply]

We did not originally request this ability, but we noticed and have discussed it a few times, and while one editor objected to bureaucrats' ability to remove the bureaucrat priv, everyone seems to be on board with our ability to remove the admin priv. I've edited meta:Bureaucrat#Removing access to indicate that. —Ruakh_TALK 21:58, 14 November 2012 (UTC)[reply]

bugzilla:42113 is still waiting for someone to add a link to a discussion where clear consensus on this change can be found; please add one there. It's mainly the community's duty to determine what's valid consensus, so it can't be someone from outside to choose a current or old discussion among many. Thanks, Nemo 21:38, 26 November 2012 (UTC)[reply]

Wiktionary:Votes/2012-11/Bureaucrats and de-privving has begun. - -sche (discuss) 20:47, 4 December 2012 (UTC)[reply]

Import watchlist[edit]

On the right top of "My watchlist" in Monobook I see a clickable link "Import watchlist". This in fact does nothing more than bring up the watchlist editor, which can also be done from elsewhere on top of the the same page.

Could it be made possible to edit one's watchlist off-line? Or to add and subtract items based on the characteristics of the headword eg, containing characters from scripts for languages of no interest to a contributor? and, even better, based on characteristics of the entry: recency of revision, whether it is a lemma, etc? DCDuring TALK 22:15, 15 November 2012 (UTC)[reply]

Bug in Rhyme-Adding Application[edit]

Unaware that they weren't considered proper rhymes for that pronunciation, I added the words cowrie and dowry to Rhymes:English:-aʊɹi. When I clicked "save changes", everything seemed to work fine (diff)- until I reloaded the page. Both of them promptly disappeared. Thinking I had forgotten to save the changes, I tried it again- same result. Then I clicked "edit" and discovered the comment that said "*** Words such as "dowry" and "floury" don't belong here". Apparently the app saw the word "dowry" in the comment and rearranged the text so that the new words were added in new alphabetically-ordered lines before the line with "dowry". I think the fact that there was an "*" before the first alphabetic character in the line may have contributed to the error.

The average novice user would have no clue went wrong, and it's not good to have edits leaving invisible garbage like that- especially if it might encourage later attempts to do the same thing. Can someone who knows how to work with the code in such applications see if it can be taught to ignore comments? Chuck Entz (talk) 08:03, 17 November 2012 (UTC)[reply]

Citations of undefined terms[edit]

There are very many citations of undefined terms that are not in Category:Citations of undefined terms anymore. See Citations:eigensheaf as an example. Any ideas why? SemperBlotto (talk) 08:39, 18 November 2012 (UTC)[reply]

The {{citation}} template needs to be on the page for that to work. DTLHS (talk) 17:25, 18 November 2012 (UTC)[reply]

The template is seriously bodged. It fails to categorize if there is only one redlinked argument or the argument is implicit. It only categorizes into Category:Citations of undefined terms if argument 2 or higher is red. See Citations:eigensheaf now. If there are multiple arguments, one of which is red, it categorizes into Category:Citations of undefined terms even though the entry does exist. See Citations:preference. DCDuring TALK 18:24, 18 November 2012 (UTC)[reply]

I've

fixed the problem whereby "It fails to categorize if there is only one redlinked argument or the argument is implicit". (I have not touched the problem whereby "If there are multiple arguments, one of which is red, it categorizes into Category:Citations of undefined terms even though the entry does exist", because that seems to have been an intentional design decision, and I'm not sure what the correct behavior would be. Should it only base its categorization on the first link, under the assumption that that's the primary/correct/defining entry?) —Ruakh_TALK 19:28, 18 November 2012 (UTC)[reply]

I think that would be OK. It might be even better if it ignored other arguments and/or had an option to show "and inflected forms" and/or user-selected text. It seems quite complicated for what it really needs to do, but it must have been fun to try to enhance the necessary functionality. DCDuring TALK 19:44, 18 November 2012 (UTC)[reply]

Sorry, I don't follow. What is the behavior that you want? —Ruakh_TALK 22:54, 18 November 2012 (UTC)[reply]

I think that I'm glad I wasn't clear, because I think it could be very simple.

Rather than have any dependence of categorization behavior on template arguments, perhaps it could just categorize if there was no corresponding principal namespace entry or if there were a {{only in}} in principal namespace. The display behavior could be simply user controlled, defaulting to the principal namespace headword.

Is that clear? Does it seem sensible? I don't know whether this really covers all the instances in which it has been deployed, but I think it covers every case in which it should have been deployed. DCDuring TALK 23:13, 18 November 2012 (UTC)[reply]

I just realized that I hadn't mention that it should work for each language section with language-specific categorization based on the absence of the corresponding L2 section, unless only English has attestation on the Citations pages. I have seen instances of non-English citations in Citation space. DCDuring TALK 23:21, 18 November 2012 (UTC)[reply]

Sorry, what you describe isn't really possible. Categorization has to be inside the wikitext, which means it can't use any of JavaScript we have for really examining the contents of a page. There are some hackish things we can attempt by actually transcluding the mainspace page and examining what we've transcluded, but . . . that would be very ugly and expensive, and I greatly oppose trying it. Instead, we should restrict ourselves to checking for redlinks. (If desired, we could actually put [[Category:Citations of undefined terms]] directly inside citations-pages where the mainspace-page exists but doesn't have an appropriate non-{{only in}} L2 section. We could even run a bot occasionally to add/remove that.) —Ruakh_TALK 02:45, 19 November 2012 (UTC)[reply]

Ugly and expensive is not what we need. We just need something that helps us attain the approximate result. I have no problem with requiring some explicit arguments for the template to achieve the result or an approximation for lower frequency cases like {{only in}} and multiple-language-related complications. Occasional bot help for cleanup would be lovely. DCDuring TALK 03:22, 19 November 2012 (UTC)[reply]

Template:tø[edit]

Can somebody explain to me why this template exists? Isn't it redundant to {{l}}, or, y'know, a good old fashioned [[foo#Language|foo]]? —Μετάknowledge^{discuss/deeds} 20:05, 18 November 2012 (UTC)[reply]

It exists because it's important (or someone felt that it was important) to have a standardized template for translations regardless of whether a FL wiktionary exists. Ideally it lessens the proliferation of ad-hoc translation formatting by various editors. DTLHS (talk) 20:47, 18 November 2012 (UTC)[reply]

Also, it's probably easier to bot-update {{tø}} to {{t}}, {{t+}} or {{t-}} as appropriate as more languages get Wiktionaries, than it would be to have the bot figure out when to change {{l}}. - -sche (discuss) 22:42, 18 November 2012 (UTC)[reply]

For some reason, {{t}} and {{l}} have very different parameter names, so you can't just replace one with the other. I would support a move to bring them into line with each other, though (whether to ultimately deprecate one or keep both). —CodeCa t 01:44, 19 November 2012 (UTC)[reply]

Hmm. {{l}} serves a different purpose than {{t}} and is used in an almost entirely different set of places. I don't know if they need to be "standardised" or not. They certainly shouldn't be combined (the term "eierlegende Wollmilchsau" comes to mind). - -sche (discuss) 02:57, 19 November 2012 (UTC)[reply]

Well, it would be nice if the parameters they shared were used in the same way. {{l}} has the second parameter while {{t}} has alt=, but {{t}}'s second and third parameter correspond to {{l}}'s g= parameter. I can't really think of a very good reason for this difference behaviour; in theory both template would need to override the displayed term equally often. We are not in the habit of including genders with {{l}} though, nor is it common to include glosses with translations. So perhaps we could standardise that the second parameter is the alternative form in {{t}} (deprecating alt=) while using the third/fourth parameters for the gender in {{t}} only (and using g= for {{l}}?). —CodeCa t 03:18, 19 November 2012 (UTC)[reply]

Further question since I don't remember the discussion: why was it decided to have 3 separate templates rather than just {{t}} with the first parameter determining whether to create the FL link? DTLHS (talk) 03:02, 19 November 2012 (UTC)[reply]

Probably for speed reasons. —CodeCa t 03:08, 19 November 2012 (UTC)[reply]

DTLHS' question above has lead me to wonder, somewhat unrelatedly: is it more taxing on the servers if a page calls one template 50 times, or if it calls two templates 25 times each? What about if it calls 25 templates twice each? (Assume that all the templates in this thought experiment are equally complex.) - -sche (discuss) 03:08, 19 November 2012 (UTC)[reply]

Ceteris paribus, I'd expect the latter to be more expensive, because it would require more trips to the database, and more space in the various caches. —Ruakh_TALK 21:15, 19 November 2012 (UTC)[reply]

Avoiding looking up script, is this sort of edit helpful?[edit]

I was wondering if this sort of edit is considered helpful? That is to say, specifying sc= (whatever the script name is) inside {{l}} to avoid {{l}} having to look up what {{frm/script}} is? When I say helpful, I mean will it make pages load quicker? {{frm-noun}} unlikely to be used more than twice on any page, it seemed like a good test case, but not likely to be a good practical application of the idea because it will probably effect no page on this wiki by more than a few milliseconds. Mglovesfun (talk) 22:23, 18 November 2012 (UTC)[reply]

Technically yes, it will make pages load slightly quicker (but only slightly — it will still use {{Xyzy}} and {{Xyzy/script}} and {{Latn}}, so the only template it bypasses is {{frm/script}} itself), but really I just don't think that {{frm-noun}} should be using {{l}} at all. Performance aside, it defeats some of the point of using templates for consistent and customizable formatting, because {{l}} doesn't (and shouldn't) support face=, so the end result is that {{frm-noun}} itself has to add explicit bolding. {{l}} is a great convenience in entries, but I don't think it should ever be used as a "helper" template inside other templates. —Ruakh_TALK 22:53, 18 November 2012 (UTC)[reply]

Audio in the WOTD template on the mobile version of the site[edit]

See Wiktionary talk:Word of the day/November 19. Could we suppress the audio link in the template on the mobile version of the site? (I imagine having audio links in the entries is still preferable.) - -sche (discuss) 09:08, 19 November 2012 (UTC)[reply]

Present participles using template:third person singular of[edit]

While paging through Special:WhatLinksHere/Template:third-person singular of, I started to notice words ending in -ing. Lots of them. Apparently TheCheatBot (talk • contribs) had a bug about 5 years ago that caused it to use the wrong templates for whole batches of form-of entries it was creating. The earliest ones I noticed were in the October 1, 2007 batch, and the latest were in the December 15, 2007 batch. I would guess that here are upwards of a couple hundred of them under this template alone. The same bug also put present participle templates in past tense forms, among other errors.

I'm not sure what to do about the other errors, but it should be fairly easy for a bot to replace "third-person singular of" with "present participle of" for all single-word entries ending in "ing". That should put a dent in the mountain of edits required to fix this. Any takers? Chuck Entz (talk) 09:31, 19 November 2012 (UTC)[reply]

Wiktionary:Todo/English verb form cleanup. I'll probably look at more problem cases later. DTLHS (talk) 09:55, 19 November 2012 (UTC)[reply]

A proposal to get rid of script templates[edit]

Script templates are kind of annoying. We use them because we have to, because text can look strange otherwise. However, script templates have two functions, not just one:

Setting the CSS class, so that the correct font is used.
Adding the lang= HTML attribute, to specify the language.

We need the lang= attribute, and it would not be desirable to remove it (screen readers use it to figure out what language to pronounce words in). However, we could get rid of the CSS class and extra coding in several of our script templates. CSS allows you to select elements in the page based on the value of an attribute on that element. So... why not select based on the lang= attribute? Currently, for example, to display a Russian word with {{term}}, that template calls {{Xyzy}} which calls {{ru/script}} to find out that {{Cyrl}} is needed, which is then called and which then specifies class="Cyrl" and lang="ru". Under my proposal, we would specify lang="ru" directly and let the CSS indicate that all elements with "ru" as the language need Cyrillic fonts. That way, most script templates, if not all, would no longer be needed as all the script support would be handled by the CSS instead, and we could also avoid using the relatively expensive {{Xyzy}} and {{ru/script}}-type templates. Of course this would mean that we always require an element with lang= to surround the text, but we already do that indirectly with templates like {{l}}, {{t}}, {{term}} and such, so we wouldn't need to change what we already do. —CodeCa t 02:32, 24 November 2012 (UTC)[reply]

Forgive my ignorance, but then how would stuff like {{sh/script}} or {{ms/script}} work? Or is that not a problem? —Μετάknowledge^{discuss/deeds} 03:10, 24 November 2012 (UTC)[reply]

For those situations we may want to continue to use script templates. But what we can eliminate is the need for script templates for the default script of each language. And there are only a few languages that need more than one script, anyway. —CodeCa t 03:15, 24 November 2012 (UTC)[reply]

But how would it know whether to go to the /script and check for another script if a langcode is thrown at it? Would you designate exceptions in the CSS? —Μετάknowledge^{discuss/deeds} 03:20, 24 November 2012 (UTC)[reply]

Currently, if a language like sh uses a script other than its default (Cyrl in this case) then we specify sc=Cyrl. The {{Cyrl}} template then adds the CSS class class="Cyrl". We could keep this the way it is, but presumably, if an element has both a language code and a script class, we want the script class to take precedence. I think that would be possible with CSS but I'm not sure on the details. —CodeCa t 03:26, 24 November 2012 (UTC)[reply]

I like the idea.

Do we need to specify the script explicitly if the script to be selected is Latin? As the default for plain text is English (not explicitly specified) and it renders correctly, browsers must be correctly defaulting to Latin script. As many languages use Latin script, this should make it possible to further simplify. For example, a one-letter position parameter could indicate Latin, a blank indicating the need to look up script based on language. DCDuring TALK 03:28, 24 November 2012 (UTC)[reply]

We wouldn't need to specify the script explicitly at all. The script and resulting formatting would be implicit in the language code via CSS. So if you write {{l|fr|attention}}, then the {{l}} template would expand this to: [[attention#French|attention]], while {{l|ru|добрый}} would become [[добрый#Russian|добрый]] —CodeCa t 03:38, 24 November 2012 (UTC)[reply]

How large would the CSS have to be to allow for all possible languages? If it doesn't allow for all possible languages, how would the others be handled when they turn up? DCDuring TALK 05:23, 24 November 2012 (UTC)[reply]

It will get a bit bigger, yes. I'm not sure where the CSS is located or how to edit it, but the CSS isn't downloaded each time a page is loaded as far as I know. The browser ought to keep it in cache. There are different ways to do this depending on which kind of CSS you use, but here is how it could be done in CSS2 (See [1]; I'm not sure how well it's supported by browsers):

.Cyrl, :lang(bg), :lang(ru), :lang(sh)
{
    font-family: /* Cyrillic fonts */;
}

.term.Cyrl, .term:lang(bg), .term:lang(ru), .term:lang(sh)
{
    font-style: normal; /* Do not use italic for "term" in Cyrillic */
}

Unfortunately we'd have to duplicate the whole list of languages whenever we want to override how, say, bold text, headword or text with "term" is displayed. But I don't think that would be a huge issue as we'd only ever need to change the list when we set the script for a language that had none set before. —CodeCa t 14:30, 24 November 2012 (UTC)[reply]

Firstly — that CSS is wrong. It doesn't do what you think it does. (I mean, it's fixably wrong, so that's not necessarily a reason to avoid this change; but this should give you pause.) Secondly — according to MSDN, language selectors were not supported by IE until IE 8. We can probably ask the sysadmins what proportion of our users are using earlier versions of IE. Thirdly — have you actually checked to confirm your statement that script templates only add CSS classes and lang="..."? (That's a rhetorical question: you haven't, or else you'd know that it's not quite true.) Note that if it were completely true, then we could trivially eliminate script templates themselves even without your proposed change, because the contents of a script template would be completely predictable just from its name. (Well, almost-trivially. We'd still have to handle all the cases where script-templates are called directly in entries, rather than via {{Xyzy}}.) —Ruakh_TALK 15:32, 24 November 2012 (UTC)[reply]

Actually I have checked and I know that it's not quite true. They also handle things like how "term" does not italicize all scripts but only some, and how "head" makes some scripts big instead of bold. But as I tried to demonstrate above, that can also be included in the CSS. I'm not suggesting that this solution will work in all cases, at least not with this initial proposal. But it would eliminate the vast majority of them. We have a very easy way to try this out, though. We can apply this just for Gothic script; Gothic is the only language that uses it, so it should be relatively easy to see what happens. —CodeCa t 16:39, 24 November 2012 (UTC)[reply]

Category:Languages by script currently contains about 200 non-Latin languages (and there may be some more). Do you really want to stick all that in a CSS? Wouldn't the CSS file get really big like this? -- Liliana • 18:13, 24 November 2012 (UTC)[reply]

It probably would, but is that really such a big issue? Let's say that we need 15 characters for each language's selector in the CSS... that's still only 3 kB extra which is trivial even on dialup. I have tested a little bit with Gothic, and it seems to work just fine. See User:CodeCat/common.css, where I've defined some CSS classes. On User:CodeCat/script test you can see how it works (you'll need to copy the CSS to your own to see it). —CodeCa t 18:24, 24 November 2012 (UTC)[reply]

If we switch from {{term|word|lang=bar}} and {{l|bar|word}} to {{term/bar|word}} and {{l/bar|word}}, as (partly) suggested in the discussion on the Tabbed Languages vote page, does that make it unnecessary or even undesirable to eliminate script templates? - -sche (discuss) 18:31, 24 November 2012 (UTC)[reply]

Why would that make it undesirable? Presumably, a template like {{term/got|𐌰𐌲𐌾𐌰𐌽}} would expand to [[𐌰𐌲𐌾𐌰𐌽#Gothic|𐌰𐌲𐌾𐌰𐌽]]. So there would be no need for a script template there anymore; the script styling and fonts would be inherent in the lang="got" and class="term" parts. —CodeCa t 18:38, 24 November 2012 (UTC)[reply]

A few problems:

IE6 and IE7 make up 0.78% and 2.79% of Wikimedia traffic, respectively. The lang selector is supported by neither of these browsers, and the attribute selector is not supported by IE6.
I haven't actually checked it, but I suspect this is going to be some pretty heavy CSS. (If anyone wants to find out exactly how heavy, Chrome has a CSS profiling tool in the Developer Tools that could say how many milliseconds we're talking about.)

Maybe we could just eliminate the final script templates, like {{Latn}}? It seems that all they really do is add a tag with a class that matches their name. I don't see why we couldn't do that directly without calling an extra template (class={{{sc|{{{{{lang}}}/script}}}}}, maybe with a bot adding the scs regularly...) --Yair rand (talk) 08:48, 25 November 2012 (UTC)[reply]

We could do that as an initial step. Script templates currently do a bit more than that, they also decide what styling to use for headwords, term-links, bold text etc. But if we move that into the CSS, we'll have a good start, and we can look at the script selection later. (Note: script selection is still a bigger cause of slowdown than the script templates themselves are)

Actually, what happened to WebFonts? In theory, it would eliminate the script issues almost entirely (I think), and the bug that was stopping us from using it before has since been fixed. --Yair rand (talk) 19:11, 25 November 2012 (UTC)[reply]

If that's true, let's re-run the vote. I'm sure it'll pass if the people who hang around the GP don't find anything amiss. —Μετάknowledge^{discuss/deeds} 03:26, 26 November 2012 (UTC)[reply]

Wiktionary:Votes/2012-12/Enabling WebFonts extension. --Yair rand (talk) 16:49, 3 December 2012 (UTC)[reply]

IE6 support[edit]

(split from previous discussion)

I don't think it's really necessary to still support IE6. It's so old and buggy and hardly anyone uses it anymore. And those who do use it are probably accustomed to sites that look wrong. :P Why don't we make a formal announcement that we are dropping support for it, so that those few people have a chance to upgrade? There's only so much we can do to support all users, and letting old browsers hold us back from improving the experience for the vast majority of users is never good. —CodeCa t 13:06, 25 November 2012 (UTC)[reply]

Obviously, nearly 1% of users use IE6. With tabbed languages we are writing off those with laptops and large type selected in the browser. Those with slow broadband connections can't edit some of our entries.

How many classes of users do we want to write off for having inferior hardware or software or slow IP connextions?

You do realise that the purpose of this proposal is to improve speed, so that more people can use and edit Wiktionary? —CodeCa t 15:34, 25 November 2012 (UTC)[reply]

How many existing users would you like to write off in pursuit of speed for the others? DCDuring TALK 17:11, 25 November 2012 (UTC)[reply]

Make that question a bit less loaded please? —CodeCa t 17:20, 25 November 2012 (UTC)[reply]

Are you willing to write off IE6 users to get a speed advantage for everyone else? DCDuring TALK 18:53, 25 November 2012 (UTC)[reply]

IE6 is 11 years old. That's ancient in computer terms. So I would like to reverse that question: are we willing to hold back on our ability to improve Wiktionary, because we want to support 11 year old browsers used by less than 1% of our users? I realise compatibility is important but I mean... this is IE6 we're talking about. It's the antithesis of compatibility. Why should we attempt to be compatible with it when Microsoft made no attempt to be compatible with like, the internet, 11 years ago? —CodeCa t 19:09, 25 November 2012 (UTC)[reply]

To add on to that: we widely use transparent PNG images on Wiktionary. IE6 doesn't support those, either. So we already don't support IE6 anymore. I also noticed that Youtube and Facebook no longer support it either. —CodeCa t 19:23, 25 November 2012 (UTC)[reply]

They can readily financial justify writing off poverty-stricken users whom advertisers don't care about. We seem to pride ourselves on being non-commercial. Is that so that we can do good for those in need or is it just a tax dodge? DCDuring TALK 19:31, 25 November 2012 (UTC)[reply]

Are you suggesting poor people can't afford a browser that's better than IE6? That's complete nonsense. IE actually costs more than Firefox or Chrome because you have to pay for Windows to use it. —CodeCa t 19:49, 25 November 2012 (UTC)[reply]

I'd rather not write off anyone, but in certain instances, where we simply can't provide a feature to a group of users, we provide it to those we can. In this case, if we use attr or lang selectors, we should have a fallback available for non-supporting browsers. I suspect they won't end up being the best solution anyway. However messed up and awful IE6 is (and it's pretty awful), if our users use it, we should support the browser as much as we are able to. --Yair rand (talk) 19:53, 25 November 2012 (UTC)[reply]

But at what cost? If we could cause a (possibly significant) speedup by eliminating the need to look up scripts with templates like {{Xyzy}}, and other possible future improvements that we haven't thought of yet, should we say no to that just because we want to keep supporting IE6? Is an improvement for 99% of our users worth putting off for the benefit of 1%? (Wait... where have I heard that before? :p) —CodeCa t 19:59, 25 November 2012 (UTC)[reply]

I predict that the rest of this discussion is going to be entirely unproductive. --Yair rand (talk) 20:17, 25 November 2012 (UTC)[reply]

Comment. Like many of our arguments, this one is premature. If it's possible to eliminate script templates by using CSS language selectors, then it's very likely also possible to eliminate them in a way that IE6 and IE7 support. For example, instead of lang="he", we can use lang="he" class="lang-he", and then use .lang-he instead of :lang(he) in our CSS. (I say "very likely" because another limitation of IE6 is that it doesn't support, or doesn't reliably support, selectors that include multiple classes at the same level; so HTML like class="lang-he mention" does not necessarily enable CSS like .lang-he.mention if we care about IE6. But still, I think it's premature to start arguing about whether we're willing to sacrifice IE6 support for everyone else's benefit, given that we all seem to agree that we might as well preserve IE6 support if there's no cost.)
Also, a small point, but — IE7 is only six years old. I think it's cheating a bit to describe IE6 as "11 years old", given that it was the most-recent Internet Explorer until six years ago.
—Ruakh_TALK 20:22, 25 November 2012 (UTC)[reply]

We already use multiple classes per element (see {{Latn}}), so that part of IE6 support is already broken. Your solution would require writing things like class="{{{sc|lang-{{{lang}}}}}}". And for things like {{term}} or {{head}}, where we need a separate style, it would be class="{{{sc|lang-{{{lang}}}}}}-term" or class="{{{sc|lang-{{{lang}}}}}}-head" (and we'd have to add classes like Cyrl-head and lang-he-term to the CSS). It works, but it's not very nice... —CodeCa t 21:13, 25 November 2012 (UTC)[reply]

Re: first sentence: No, sorry, you've misunderstood. We do not use selectors like .class1.class2 anywhere in our site CSS, except for a bit of CSS in MediaWiki:Vector.css that addresses a Mozilla-specific issue (so isn't relevant to IE anyway). We have HTML like class="class1 class2" in many places, but that in nowise harms our IE6 support. Re: second sentence: Well, I imagine we'd want to separate the {{{sc|}}} from the lang-{{{lang|}}}. Re: third sentence: This is a bit of a separate discussion/decision/issue, but I think we can eliminate the whole "head"/"bold"/"term"/"ital" thing, and just use  and , plus appropriate CSS. Re: fourth/last sentence: I think the most important part of that is it works. You are really not going to convince DCDuring to prefer the "solution" that doesn't work for IE6 and IE7 when its only downside is slightly uglier HTML inside templates that are already very ugly. —Ruakh_TALK 04:08, 26 November 2012 (UTC)[reply]

Hmm... apparently {{Latn}} already uses mention-Latn instead of Latn-term which I just suggested. —CodeCa t 21:17, 25 November 2012 (UTC)[reply]

Discussed every now and then again (for example a few months ago on wikitech-l mailing list), no new arguments, please move along, nothing to see here? :) Browser stats are available here by the way, and keep in mind what 1% means in total numbers for a website like Wikipedia. --Malyacko (talk) 12:34, 27 November 2012 (UTC)[reply]

Dump analysis request - Yiddish[edit]

I have another dump analysis request that has come up after my discovery of what a horrid mess our Yiddish entries are on the whole. The first step is making sure that entry titles are using the right characters (i.e. that they are searchable on a Hebrew keyboard and standardized per YIVO/WT:AYI). To this end, I would really appreciate it if someone could place (maybe at User:Metaknowledge/Yiddish) a list of entries with the L2 header ==Yiddish== and any of the following characters in the title: א פ װ ױ ײ. Redirects and entries which transclude {{yi-unpointed form of}} shouldn't be listed, nor entries with pointed forms of the previous characters (those would be: אַ אָ פּ פֿ). Thank you so much! —Μετάknowledge^{discuss/deeds} 18:52, 24 November 2012 (UTC)[reply]

You missed a few cases:

א is acceptable as the first letter of a word when followed by any of י יי ײַ ו וי.
ײ is acceptable in the combination ײַ.

And there will still be many false positives when a word is derived from Hebrew. --Wiki Tiki 89 19:24, 24 November 2012 (UTC)[reply]

Actually, I didn't forget about those cases. For the first case, it is a trivial job for a human to weed those out, but presumably more difficult to program. For the second, I thought it was a different codepoint (evidently I am incorrect in that assumption). And the etymological spellings will provide a lot of false positives, but there's no foolproof way around that, and I think a lot of the ety-spellings need plurals to be given to {{yi-noun}} anyway, so it wouldn't be bad to look them over. —Μετάknowledge^{discuss/deeds} 20:27, 24 November 2012 (UTC)[reply]

There is a separate codepoint for ײַ but we don't use it (we use ײ + patakh). And the א + vowel letter exceptions are no harder to program than the א + vowel point point exceptions and will save a lot of weeding out. It may also be worth looking for incorrect usage of final and non-final letters (כ מ נ פֿ צ in final position, or ך ם ן ף ץ in non-final position) --Wiki Tiki 89 20:44, 24 November 2012 (UTC)[reply]

Hi! With the help of the Android program kiwidict you can select list of Yiddish entries (or translations).

select "Source language" with the language code "yi" (1. Set checkbox "Source language", 2. Write "yi")
write the letter in the search input field, e.g. א
use w:Wildcard character (% and _) in order to get list of words, e.g. type in the search input field: "א% %" .

But, this software uses dump of English Wiktionary, as of October 2011 :(. Sure, it will be updated in the future. -- Andrew Krizhanovsky (talk) 15:09, 25 November 2012 (UTC)[reply]

Erm, I don't own a phone and that's more than a year old anyway. I'm afraid that's not very helpful in this case, although I appreciate your work on the app. —Μετάknowledge^{discuss/deeds} 16:02, 25 November 2012 (UTC)[reply]

Tabbed languages implementation[edit]

Can anything be done to increase the space for actual context in the middle of the page? I select type size=17 in FF so I don't have to wear glasses and, on pages with project boxes, only about 3/8 of my screen has content. In many entries that means that definitions don't appear on the landing screen. One some not until the second pagedown.

Some steps toward resolving such problems for the users affected:

The project boxes could be made more compact;
the far left-hand side could appear in smaller type because little of it changes so users can handle smaller type;
the same is probably true for language names;
for monolingual users the language tabs need not appear at all.

Further, the Etymology and Pronunciation sections could be made to appear under {{rel-top}} or other means could be used so that the section content only appeared when the user selected it. At the very least, cognates could be placed under {{rel-top}} if not placed in the entry of common descent. DCDuring TALK 14:15, 25 November 2012 (UTC)[reply]

By "project boxes" you mean the boxes linking to sister projects? There are alternatives to the large ones, like {{slim-wikipedia}}, which we might want to use more often. --Yair rand (talk) 15:35, 25 November 2012 (UTC)[reply]

Yes, that's what I meant. However, {{slim-wikipedia}} is the only "slim" box. It about 1.0mm less wide than {{wikipedia}} and the others. Occupying half as much vertical screen space can enable more text to occupy the rightmost 24% of my screen. DCDuring TALK 17:19, 25 November 2012 (UTC)[reply]

Tartessian language[edit]

Could someone, please, add the family information about the Tartessian language (txe)? Category:Old Portuguese terms derived from Tartessian looks a bit strange without family information. Thanks! --MaEr (talk) 16:47, 25 November 2012 (UTC)[reply]

Done. —CodeCa t 16:53, 25 November 2012 (UTC)[reply]

Thank you! It looks much nicer now :) --MaEr (talk) 17:04, 25 November 2012 (UTC)[reply]

Requesting comment: MediaWiki talk:Common.css#Hide collapsible tables' content[edit]

--Yair rand (talk) 16:53, 27 November 2012 (UTC)[reply]

Template:lv-conj[edit]

For some reason, this template was deleted a couple of weeks ago; but I was working on it, so the deletion actually made me lose quite a lot of work. Is there some way to bring it back? (I note that, when I look at templates that transclude it, like template:lv-conj-2, I can still see the table as it should be, but template:lv-conj itself is gone, and when I use template:lv-conj-2 in an entry, I only get a red link to template:lv-conj (see tulkot). --Pereru (talk) 11:35, 29 November 2012 (UTC)[reply]

An admin can restore it (I'm not an admin). But in the future, you should work on templates in your userspace until they are functional and ready to be used. --Wiki Tiki 89 12:11, 29 November 2012 (UTC)[reply]

Restored. --Yair rand (talk) 12:13, 29 November 2012 (UTC)[reply]

Oh, OK. I didn't know that templates had to be previously chiseled in one's own userspace; I'll do that next time. Thanks for restoring the template. --Pereru (talk) 13:06, 29 November 2012 (UTC)[reply]

They don't have to be but you shouldn't leave templates that don't work yet in the template namespace. --Wiki Tiki 89 13:52, 29 November 2012 (UTC)[reply]

Bad-Interwiki abuse filter not working[edit]

Special:AbuseFilter/11. This is supposed to filter out edits that include an interwiki that points to a page with a different name from the current one. However, it doesn't seem to work. I added [[nl:incorrect]] to test but it allowed the edit, even when I was logged out. Does anyone else know what's wrong with it? —CodeCa t 17:28, 29 November 2012 (UTC)[reply]

This is a bit subtle, but . . .

Although the edit-window always includes a newline at the end, that newline is not actually part of the page's wikitext. As a result, when you add a new line to the end of a page, you are also adding a newline before it (not after it). Also, a newline is considered to be part of whatever line it follows. Therefore, when you add a new line to the end of the page, the erstwhile last line is considered to be modified by your edit, so it appears in both the added_lines and the removed_lines variables. (This could be considered a bug; note that the diffs shown in the UI are smarter than that, and don't show this line as changed. We might want to file a report in Bugzilla.)

In the case of your edit to [[test]], the last line had been [[zh:test]], and then you added a new line [[nl:incorrect]]. Therefore, [[zh:test]] appeared in the added_lines. (See Special:AbuseFilter/examine/18986480.) Therefore, your edit satisfied the added_lines regex good check, and was considered a good edit.

This can probably be fixed by using a fancier regex, with a zero-width negative lookahead assertion, that specifically looks for bad interwikis (as opposed to what we currently have, which looks for any interwikis and then for good ones and considers it a problem if it finds the former but not the latter).

By the way, I oppose setting this filter to reject bad edits. Some of the edits that trigger this filter do not deserve to be blocked.

—Ruakh_TALK 01:22, 30 November 2012 (UTC)[reply]

I'm not really sure how to fix it though. I didn't write the regex to begin with. And what edits that trigger this filter (or would trigger it, if it worked right) are good edits? —CodeCa t 03:23, 30 November 2012 (UTC)[reply]

Re: how to fix it: I haven't tested even a little bit, but I'd think we'd want something like this:

article_namespace === 0 &
action === 'edit' &
(bad := "\[\[(?! *(" + str_replace(rescape(article_text), " ", "[ _]+") + "|\{\{subst:(BASE)?PAGENAME\}\}) *\]\])[^\]]+\]\]" ;
rcount(bad, added_lines) > rcount(bad, removed_lines))

Re: your not having written it: Don't worry, I didn't think you had.
Re: edits that trigger this filter that shouldn't be blocked: e.g. this one.
—Ruakh_TALK 04:28, 30 November 2012 (UTC)[reply]

But that's exactly the (kind of) edit I had hoped to block with it. I realise that if the edit is just blocked, the people making the edit are none the wiser. That's why I added a description to the filter that explains the mistake and how they can correct it. —CodeCa t 04:33, 30 November 2012 (UTC)[reply]

Why should we block people from adding content when their only mistake is a bad interwiki that a) we can warn them about and b) can and will be fixed by a bot? DTLHS (talk) 04:48, 30 November 2012 (UTC)[reply]

Our "bad interwiki" filter doesn't look for bad interwikis. That's hilarious. - -sche (discuss) 04:01, 30 November 2012 (UTC)[reply]

That particular edit added the wrong interwiki but added a citation to a term that needed it. A warning to the user and a flag seem much better than blocking the content unless the ratio of bad content to good content added with bad interwikis is very high indeed. DCDuring TALK 08:13, 30 November 2012 (UTC)[reply]

Why not block with a warning? If blocking the edit can force the user to fix it, why is it harmful? —CodeCa t 14:08, 30 November 2012 (UTC)[reply]

Re: "blocking the edit can force the user to fix it": ^{[citation needed]} I see how it can prevent the user from submitting the unfixed version, but I don't see how it can force the user to fix and resubmit. —Ruakh_TALK 15:00, 30 November 2012 (UTC)[reply]

Well, either they fix it, or they don't submit the edit. The truth is we don't know what they would do in that situation, but we can probably assume that as long as they read and understand the warning message, they will fix their edit. —CodeCa t 16:39, 30 November 2012 (UTC)[reply]

I agree. The problem is, I'm not convinced that they'll read and understand the warning message. It is very hard to write such error-messages in a way that makes sense to end-users. (Have you ever gotten an error-message from a compiler that you didn't immediately understand?) I'd much rather allow the edit and have a human being leave a message on the editor's talk-page. —Ruakh_TALK 16:53, 30 November 2012 (UTC)[reply]

I've tried to write it at MediaWiki:Abusefilter-warning/bad-iw. You can try to improve it if you know how. —CodeCa t 17:03, 30 November 2012 (UTC)[reply]

TemplateSandbox[edit]

"TemplateSandbox" has been deployed here, and it apparently gives us new tools like a "Preview page with this template" box at the bottom of template edit screens, as well as a Special:TemplateSandbox for testing templates. See mw:Extension:TemplateSandbox#Usage. --Yair rand (talk) 22:59, 29 November 2012 (UTC)[reply]

Sounds great! Thanks for sharing. — Ungoliant ^(Falai) 23:14, 29 November 2012 (UTC)[reply]

Wiktionary:Grease pit/2012/November

Contents

Editing raw watchlist[edit]

Diminutive of adjectives[edit]

Audio bot[edit]

Special characters and Lupin's popups[edit]

Problem with category display in tabbed languages[edit]

Special:UncategorizedPages[edit]

App for adding citations to Wiktionary[edit]

template:audio[edit]

Problem with targeted translations[edit]

User:Babel AutoCreate[edit]

Expanding the list templates[edit]

Streisand effect on WOTD[edit]

bot task: categorise language proficiency categories[edit]

Hittite Wiktionary[edit]

Bureaucrats and sysops right configuration change[edit]

Import watchlist[edit]

Bug in Rhyme-Adding Application[edit]

Citations of undefined terms[edit]

Template:tø[edit]

Avoiding looking up script, is this sort of edit helpful?[edit]

Audio in the WOTD template on the mobile version of the site[edit]

Present participles using template:third person singular of[edit]

A proposal to get rid of script templates[edit]

IE6 support[edit]

Dump analysis request - Yiddish[edit]

Tabbed languages implementation[edit]

Tartessian language[edit]

Requesting comment: MediaWiki talk:Common.css#Hide collapsible tables' content[edit]

Template:lv-conj[edit]

Bad-Interwiki abuse filter not working[edit]

TemplateSandbox[edit]

Navigation menu

Wiktionary:Grease pit/2012/November

Editing raw watchlist[edit]

Diminutive of adjectives[edit]

Audio bot[edit]

Special characters and Lupin's popups[edit]

Problem with category display in tabbed languages[edit]

Special:UncategorizedPages[edit]

App for adding citations to Wiktionary[edit]

template:audio[edit]

Problem with targeted translations[edit]

User:Babel AutoCreate[edit]

Expanding the list templates[edit]

Streisand effect on WOTD[edit]

bot task: categorise language proficiency categories[edit]

Hittite Wiktionary[edit]

Bureaucrats and sysops right configuration change[edit]

Import watchlist[edit]

Bug in Rhyme-Adding Application[edit]

Citations of undefined terms[edit]

Template:tø[edit]

Avoiding looking up script, is this sort of edit helpful?[edit]

Audio in the WOTD template on the mobile version of the site[edit]

Present participles using template:third person singular of[edit]

A proposal to get rid of script templates[edit]

IE6 support[edit]

Dump analysis request - Yiddish[edit]

Tabbed languages implementation[edit]

Tartessian language[edit]

Requesting comment: MediaWiki talk:Common.css#Hide collapsible tables' content[edit]

Template:lv-conj[edit]

Bad-Interwiki abuse filter not working[edit]

TemplateSandbox[edit]

Navigation menu

Search