Wiktionary:Grease pit/2015/June

specific definition url references

It should be possible to reference a specific definition via url. So someone could, elsewhere on the web, hyperlink words mid-sentence to the specific definition for clarity, perhaps using some sort of GUID in the case that definitions are added/removed. When visiting the link, it should be an anchor on the definition page. It should also have some sort of highlighting via CSS3 :target or some such

P.S. not only is this great for humans, it's great for machines too. — This unsigned comment was added by Tailspinhead (talk • contribs).

It's possible to create sense-specific anchors using {{anchor}}. I imagine that the reason sense-specific anchors are not created automatically is that Wiktionary, as a work in progress, tends to reorder senses, add senses (sometimes between existing senses), delete senses, and reword senses. Automatic anchors based on sense-number would break whenever the first three of those things happened; anchors based on definition (e.g. if the definition begins "A feeling of sadness and...", the software might come up with #afeelingof as an automatic anchor) would presumably break if someone reworded the sense. (Of course, such anchors would work if used on permalinks...) Bear in mind that it's only recently that someone proposed a fix to the bug that stops linking to a second ===Etymology=== section on a page that has a ===Etymology 2=== section. - -sche (discuss) 03:38, 2 June 2015 (UTC)[reply]

The issues you mention is exactly why I say to use a GUID. It should be automatic and no user intervention should be required. EVERY definition should AUTOMATICALLY have these things. It is a technical problem requiring a technical solution. (i.e. I consider it a bug in the software that it doesn't already do this, as it is obvious to a computer scientist that a dictionary should work this way) Tailspinhead (talk) 11:15, 4 June 2015 (UTC)[reply]

I think that reliably maintaining these IDs automatically would be quite tricky given the unstructured or free-form nature of Wikipedia editing. With each edit, the program would need to match "before" and "after" entries, and figure out which were intended to be the same (but maybe edited), which were new, which were deleted. With simple edits this would not be a problem, but with complex edits that changed a lot of stuff or moved it around, it would be pretty difficult I think. 86.152.161.103 23:58, 4 June 2015 (UTC)[reply]

"given the unstructured or free-form nature of Wikipedia editing" -- bug. Tailspinhead (talk) 12:11, 9 June 2015 (UTC)[reply]

It seems like you should file a feature-request on Phabricator. Automatic addition of sense-specific anchors would be within the control of the devs, not Wiktionarians. (I would file a report for you, but I don't have a Phabricator account.) I imagine the devs will themselves see the hurdles that have been pointed out in this thread (you should link to this thread from your Phabricator post), but you might persuade them that sense-specific anchors would still be useful because they could be employed in combination with permalinks to specific revisions of pages, and in that way would enable reliable links to specific definitions despite ongoing edits to Wiktionary. Mention that they will need to account for our occasional use of sub-senses and even sub-sub-senses, i.e. that most definitions begin with '#' on a new link, but some (nested below a '#') begin with '##' and potentially even '###', etc. - -sche (discuss) 17:49, 9 June 2015 (UTC)[reply]

Template:archive-top

How come this doesn't support "kept", "deleted", "speedy kept" and "speedy deleted" anymore? I tried to make it support those and now it doesn't. It needs to support those if at all possible. Purple backpack89 20:44, 3 June 2015 (UTC)[reply]

It supports "passed", "failed", and "archived", what more do you need? Speedy deletions theoretically don't have discussions, and speedy keeps theoretically don't exist; when either of those is not the case, "archived" is the correct option because whatever happened was technically not a result of the discussion. --Wiki Tiki 89 20:50, 3 June 2015 (UTC)[reply]

As I said above, "kept", "deleted", "speedy kept" and "speedy deleted"; the first and third synonymous with passed and the other two synonymous with failed. It's confusing at the present time for the template to support so few parameters; it would be less confusing if more parameters were supported. As for "why do we need speedy keep and speedy delete?", there are things that are at RfD, and an admin comes alonh, speedy deletes them long before the time limit ends, and closes the discussion. Those discussions would best be characterized as "speedy deleted". Purple backpack89 20:53, 3 June 2015 (UTC)[reply]

As I said, speedies are not a result of the discussion and so "archived" suffices. If something was speedy deleted, it would have been speedy deleted even if there weren't a discussion. --Wiki Tiki 89 20:59, 3 June 2015 (UTC)[reply]

But why shouldn't it support "kept" or "deleted" as parameters synonymous with "passed" and "failed"? Discussions are closed that way, why doesn't the template support those? Purple backpack89 21:04, 3 June 2015 (UTC)[reply]

Why should it? You need to make a better case here. —CodeCa t 21:27, 3 June 2015 (UTC)[reply]

Because the closers of discussions use the words "kept" and "deleted" rather than "passed" or "failed" to introduce the summary of findings. Because it's confusing to not have it. That's really all the argument I need. Purple backpack89 21:42, 3 June 2015 (UTC)[reply]

I'd like to see the ability to close discussions as "RFD kept" rather than "RFD passed". RFD is neither a test or verification, so it cannot "pass". Thus, I ask that Kephir restores the version of the template that supports this. Actually, since RFD is "request for deletion", "passed" even suggests the request will be satisfied and the entry deleted. --Dan Polansky (talk) 06:51, 7 June 2015 (UTC)[reply]

It's time for a party who hasn't participated in this discussion to close this as add "keep" and "delete" as parameters. There are clearly at least two people in support of adding these, and nobody has provided an argument as to why they shouldn't be included. Purple backpack89 18:31, 25 June 2015 (UTC)[reply]

This is no longer a technical issue, so if you want these parameters to be added, we need a WT:BP discussion to work out the details. I will start one. --Wiki Tiki 89 18:42, 25 June 2015 (UTC)[reply]

`{{a}}`

In the entry burrë, an editor wants {{a|Arvanite}} or {{a|Arvanites}} to link to w:Arvanites. I can’t locate the proper place to add this, and I don’t know if it’s even needed. —Stephen ^(Talk) 22:50, 3 June 2015 (UTC)[reply]

@Stephen G. Brown: It seems to me that you would create {{accent:Arvanite}} (as in {{accent:US}}, {{accent:UK}}, etc.) Why this is not done with nice pretty module that just has a data page is bizarre to me. I may remake this template some time soon. —John C5 05:52, 7 June 2015 (UTC)[reply]

Thanks. I started to make {{accent:Arvanite}} based on {{accent:US}}, but there are a couple of terms in it that I do not know what to do with. —Stephen ^(Talk) 06:53, 7 June 2015 (UTC)[reply]

@Stephen G. Brown: voilà: (Arvanitika) —John C5 07:37, 7 June 2015 (UTC)[reply]

Oh, thanks! —Stephen ^(Talk) 11:41, 8 June 2015 (UTC)[reply]

Declension cases ordering preference

[I doubt this is the correct place for this, a feature request, but I'm lost.]

Is there a way that a user preference could be set up to control the order in which cases are listed in Latin declensions? (Ditto for other languages too, if there is demand from some users about eg German, Celtic.)

I just find the Latin order displayed currently is bruising my brain.

many thanks for all the outstanding work, CecilWard (talk) 08:01, 4 June 2015 (UTC)[reply]

@CecilWard: I totally sympathize with you struggle. I too have found other orderings in other books and on other sites terribly confusing and frustrating. To my knowledge, however, no such change could be implemented easily as many language declension templates are coded very differently from one another and some languages have case systems of such hideous complexity that a user would go mad specifying all of their orders.

I cannot say it won't happen with certainty, but it seems extremely unlikely. Again, sorry for the inconvenience, but we strive to present case tables in the standard ordering according to English language scholarship. I will point out that the German declension templates ({{de-decl-noun}}) do not use the standard order, which should be NOM, ACC, GEN, DAT, but instead is the Latinate order NOM, GEN, DAT, ACC. —John C5 08:35, 7 June 2015 (UTC).[reply]

For reasons unknown, I was brought up with nom - voc - acc - gen - dat - abl - loc ordering for Latin, and so I continue to suffer. CecilWard (talk) 09:47, 16 June 2015 (UTC)[reply]

Broken links to discussions

In Wiktionary there seem to be quite a few broken links to discussion pages, and no easy way to find the original target of those links. For example, at right there is a big banner at the top with a link "Please see the discussion on Requests for cleanup", but the link does not work. Supposing that the relevant content had been archived, I tried typing "right" into the "Search in the archives of Request for cleanup" box, but this produced nothing useful. I wonder if a better mechanism could be found to either prevent these links from breaking in the first place, or at least to make it easier to find the relevant entry in the archive. 86.152.161.103 20:54, 4 June 2015 (UTC)[reply]

That rfc was placed on 20 September 2011. If there was a discussion on WT:RFC, it probably has been moved to an archive by now. —Stephen ^(Talk) 02:50, 5 June 2015 (UTC)[reply]

Module Errors at 愛

This entry spontaneously develops module errors from time to time, and it's easy to see why: Etymology 4 says "Used as ateji in various names. 愛 is a very common element in many, many names.", which is followed by proper noun entries for 50 different names spelled with this character (not compounds- just the one character). If there's anything slowing the system down, all the module-execution time for the page has been used up before it gets to the 50th.

Is there any way to optimize these, given that we know the language and script and we don't need to add the same categories 50 times? I was thinking we could leave the first one alone, and have a bare-bones version for the other 49.

Data

The wikitext of the first one, as an example (The only thing that changes is the hiragana- "あづみ" in this case) :

# {{given name|female|lang=ja|sort=あづみ}}

"Templates used in this section":

Module:languages/data2

Module:links

Module:script utilities

Module:scripts

Module:scripts/data

Module:utilities

"Parser profiling data":

CPU time usage 0.232 seconds

Real time usage 0.248 seconds

Preprocessor visited node count 104/1000000

Preprocessor generated node count 0/1500000

Post-expand include size 1420/2097152 bytes

Template argument size 38/2097152 bytes

Highest expansion depth 5/40

Expensive parser function count 0/500

Lua time usage 0.207/10.000 seconds

Lua memory usage 1.45 MB/50 MB

Categories added by the wikitext in the section:

Category:Japanese lemmas

Category:Japanese proper nouns

Category:Japanese terms spelled with fourth grade kanji

Category:Japanese terms written with one Han script character

Category:Japanese terms spelled with 愛

Category:Japanese female given names

Category:Japanese single-kanji terms (hidden)

As far as I can figure out, the only non-redundant things that are being done:

The hiragana is getting the standard Module:links treatment
1. If the hiragana is a redlink, the link is accelerated for preloaded entry-creation
The hiragana is being used to create a standard (Module:links) link to its romaji (romanization- "Azumi" in this case).

Category:Japanese female given names has a different sort key, but I seem to remember that a given page has only one sort key for a given category- so 49 of the 50 sort keys are ignored.

Thanks! Chuck Entz (talk) 23:44, 6 June 2015 (UTC)[reply]

Do we know why only sometimes it produces module errors? Is it related to caching?

Knowing that more diverse and much larger page a only needs 3 seconds I think there's something wrong in the implementation of (probably) ja-pos.

Re for 1.1: if ja-pos really checks for the existence of the hiragana then that might be it.

Why not create a specialized {{ja-proper noun}} ?...--Dixtosa (talk) 13:12, 7 June 2015 (UTC)[reply]

I don't remember anyone having explained it, but I've noticed that such problems correlate with the generation of things like Special:WantedCategories. I suspect that competition from a process running in the background is increasing the time it takes for operations to complete, so that anything that's close to the 10-second limit is going to be pushed past it. Chinese-character pages, in general, are very module-intensive because many of the specialized modules have huge tables and do sophisticated things with the data. That gives less room for other operations, though I see from the parser stats that I just added above that this section alone takes more than 1/50 of the 10 seconds: if it weren't for the fact that some of that is shared rather than additive, it would run over every time. As for {{ja-proper noun}}, wouldn't it be doing the same check for the existence of hiragana? I was thinking of just hardcoding the 愛, but there's the matter of script support and of the processing of the hiragana and romaji. I'm a little reluctant to create a specialized template just for one extreme entry, especially since I don't really edit Japanese entries except to fix obvious problems. Chuck Entz (talk) 15:15, 7 June 2015 (UTC)[reply]

Default continuation mode for action=query will change soon; bots may be affected

As announced in Tech News, "the default continuation mode for action=query requests to api.php will be changing to be easier for new coders to use correctly" and some bots may need to be updated; the posting I link to suggests several seemingly simple fixes. - -sche (discuss) 01:01, 9 June 2015 (UTC)[reply]

Missing space in malm

The wikitext has a space between the context label and the form of template: {{context|colloquial|lang=de}} {{de-verb form of|malmen|1|s|g}}. But the displayed text in the entry does not: (colloquial)First-person singular present of malmen. But the displayed text does have a space here: (colloquial) (deprecated template usage) First-person singular present of malmen. What's going on? I am using Windows and see the issue in Firefox, Opera and Internet Explorer; I can provide more details if others aren't seeing the same issue. - -sche (discuss) 15:58, 12 June 2015 (UTC)[reply]

Fixed. Apparently categories steal preceding spaces: foo [[Category:Sandbox]]bar = foo bar. --Wiki Tiki 89 17:47, 12 June 2015 (UTC)[reply]

What an interesting problem. Thanks for fixing it. - -sche (discuss) 18:00, 12 June 2015 (UTC)[reply]

Adjective short form template sought

What's the right template or template call for Russian adjective short forms? --Anatoli T. ^{(обсудить}/^вклад) 08:25, 13 June 2015 (UTC)[reply]

If there is no {{ru-infl of}} or ({{ru-inflection of}}) then {{inflection of}} is the only other option. (Note: if this is not the case we should change that).

благоро́ден is defined as {{inflection of|благородный||m|short|lang=ru}} which produces: masculine short of благородный (blagorodnyj).

But something like this would be shorter (and better?): {{ru-infl of|благородный|short}}. Gender is guessable. --Dixtosa (talk) 13:30, 13 June 2015 (UTC)[reply]

Thank you. After posting the question I tried to rollback my edit, since I find the template but something happened with the rollback but I didn't notice that it wasn't rolled back. I've used it in интересно - {{inflection of|интере́сный||n|s|short form|lang=ru}}. I prefer the more detailed form, since it adds the gender. Ideally there should also be a category for short adjective forms. --Anatoli T. ^{(обсудить}/^вклад) 13:39, 13 June 2015 (UTC)[reply]

Can we change the way this fucking page works?

You ever wrote a ten ton block of text which someone edit conflicted into? Then had to rewrite it again, for the same thing to happen once more? Not cool, innit? Is it technically possible that the page be changed so that the text you wrote is not obliterated when a conflict happens? Korn [kʰʊ̃ːæ̯̃n] (talk) 16:43, 13 June 2015 (UTC)[reply]

...? Don't you get a page that shows you both the text someone else wrote and your text, such that you can copy-and-paste your text rather than retyping it? (It should say something to the effect of "only the text in the top window will be saved", and if you scroll down, you'll see the diff between your revision and the other one, and then another edit window with your text in it.) - -sche (discuss) 16:54, 13 June 2015 (UTC)[reply]

I'll have to check my browser next time I have that trouble. If I should get that window, I've not noticed it in years of editing. Korn [kʰʊ̃ːæ̯̃n] (talk) 18:38, 13 June 2015 (UTC)[reply]

If you don't get such a window, let us know, because that would be quite a bug. (In fact, with a little co-ordination we could engineer some edit conflicts e.g. in the WT:SANDBOX for testing purposes]].) Also note Dixtosa's comment, which hilariously got edit-conflicted, that "Every self-respecting desktop browser saves all texts in all text areas of the previous page. So just going back should work." Edit conflicts are still frustrating, but it should be possible to recover any text you lose to them. - -sche (discuss) 18:49, 13 June 2015 (UTC)[reply]

Going back a page used to work for me in the past, but not today. Though, while trying to make another post on our German talk earlier today I also had my text booted due to "loss of session data", a first time event for me. Does that mean anything to you? Korn [kʰʊ̃ːæ̯̃n] (talk) 23:25, 13 June 2015 (UTC)[reply]

It sometimes happens to me that my edit is not saved due to loss of session data. It usually works to try saving it again. —Stephen ^(Talk) 23:29, 13 June 2015 (UTC)[reply]

Script flags totally benign edit as "harmful" and "vandalism"

I just tried to edit "Talk:euphemism" in the following way:

There was a question reading:

Isn't a euphemism something like a [[meiosis]]? At least in the Netherlands, a euhpemism is often considered a antonym of [[hyperbole]] (even my teacher did it). Is it just bad education or is true? [[User:Mallerd|Mallerd]] 19:51, 3 October 2008 (UTC)

I changed that to:

Isn't a euphemism something like a [[meiosis]]? At least in the Netherlands, a euhpemism is often considered a antonym of [[hyperbole]] (even my teacher did it). Is it just bad education or is true? [[User:Mallerd|Mallerd]] 19:51, 3 October 2008 (UTC)
:It is true in the sense, that a euphemism is a meiosis of 'badness' or 'evilness'. - A special case of meiosis, if you will. --~~~~

in order to answer that question. And I gave the following summary in the summary field:

"meiosis <--> euphemism explained."

The system will not let me save this edit, but instead shows the following warning message:

Warning: This action has been automatically identified as harmful. Unconstructive edits will be quickly reverted, and egregious or repeated unconstructive editing will result in your account or IP address being blocked. If you believe this action to be constructive, you may submit it again to confirm it. A brief description of the abuse rule which your action matched is: probably vandalism. If you believe your edit was flagged in error, you may report it on the Wiktionary:Grease pit.

I can not understand how my contribution could be construed to be vandalism. - Please explain, or fix the script so that it doesn't accuse innocent, well-meaning people, who just want to help as vandals. :-( - So I am following the advice the warning message gave, and report it here.

Perhaps I should add, that I wanted to improve the euphemism and dysphemism pages by respectively synchronizing the "Examples" sections, but now am afraid of doing so, because I anticipate, that my effort will be in vain.

Respectfully, but saddened, --91.39.75.239 11:02, 15 June 2015 (UTC)[reply]

I'm not sure why your edit was flagged as harmful, but it seems all you had to do was re-submit it. --Wiki Tiki 89 12:38, 15 June 2015 (UTC)[reply]

I tried that about half a dozen times, initially, suspecting just a 'hickup' somewhere. Then I tried changing punctuation, and triple-checked w/ the "differences" function, whether I had unintentionally deleted any preexisting text. - Then tried again five minutes later. - Then wrote the above message.

Now (meaning 60 seconds ago) I have tried to save the same change again, and it still doesn't work

Nonetheless I have been able to edit other articles. --91.39.75.239 12:56, 15 June 2015 (UTC)[reply]

I figured it out. It is picking up on the word "Hello" earlier on the page (which you didn't even add). @Kephir, can you fix this, since this is your filter? Not everybody who says "hello" is a vandal, anyway. --Wiki Tiki 89 13:14, 15 June 2015 (UTC)[reply]

Thank you, WikiTiki89, for figuring this out. :) - You have made a simple wiktionarian very happy. :) --91.39.75.239 13:50, 15 June 2015 (UTC)[reply]

And, for now, I've commented out the offending "Hello", which should be restored once the filter is removed or revised. You should be able to make your contribution without further problem. I'll be that the filter is interested in "Hello" only for edits by anons. If you were to register (a good idea anyway) and login, I suspect you could even say "hello". DCDuring TALK 14:17, 15 June 2015 (UTC)[reply]

I think the fact that the "hello" filter is enabled for discussion pages is just an oversight. It was probably intended just for articles, where many vandals do add things like "hi". --Wiki Tiki 89 14:37, 15 June 2015 (UTC)[reply]

@DCDuring: Thanks a lot. - However it's still not working. - Perhaps the filter is also allergic to the words "evilness" or "badness"? - And I have to admit that I do have an account. - I just don't have the credentials at hand right now (neither those for my e-mail), and don't want to create a "sockpuppet" or throw-away-account. - I also thought that this issue might be a stumbling block for very infrequent or first-time users also, or that something might be fundamentally broken. - (And besides: I have to admit that I enjoy editing anonymously once in a while, too.) --91.39.75.239 16:37, 15 June 2015 (UTC)[reply]

DCDuring seems to have had undone his changes before you tried it again. This time, just try removing the word "hello" together with your edit and if it succeeds, one of us will add it back. --Wiki Tiki 89 16:54, 15 June 2015 (UTC)[reply]

Sorry, I got distracted after checking to see whether I triggered the filter. That would not be likely for whitelisted users et al, but I had to check. DCDuring TALK 17:31, 15 June 2015 (UTC)[reply]

What is the point of making a filter private if you are just going to loudly talk over every of its conditions here? Fixed. Not saying how. — Keφr 17:50, 15 June 2015 (UTC)[reply]

Oops, I didn't think about that... but I didn't really reveal much. Thanks for fixing it. Also, see my addition to the filter notes. --Wiki Tiki 89 18:00, 15 June 2015 (UTC)[reply]

To be fair, that filter mostly blocks vandalism by people of the sort which do not even bother to look at edit filters. So it probably matters little. Filters 31 and 32 (and 9, 22, and 23) should be rules-1-and-2-compliant, however. (Replied.) — Keφr 18:32, 15 June 2015 (UTC)[reply]

Ok thanks. --Wiki Tiki 89 18:39, 15 June 2015 (UTC)[reply]

How to deal with untranslatable English terms?

if even the closest translation is just too far from being close, I think shorter form of this "this has no equivalent in this language" would add value to the translation table. This will be useful in emptying translation requests-type of categories too. We can make the second parameter of {{t}} optional, or make a new temlate. Maybe {{notrans}}?--Dixtosa (talk) 16:43, 15 June 2015 (UTC)[reply]

There’s {{not used}} for a subset of these situations.

If we are to create {{notrans}}, how can we make sure it won’t be misused by people who simply weren’t able to find a translation? — Ungoliant ^(falai) 17:09, 15 June 2015 (UTC)[reply]

Not even some kind of circumlocution? Schadenfreude, often considered untranslatable, can be glossed into English as "happiness at another's troubles" (or more wordy expression). DCDuring TALK 17:39, 15 June 2015 (UTC)[reply]

no transliteration necessary in headword line

Sometimes no transliteration is necessary for a headword. E.g., [[ישב#Etymology 3]]. At some point, {{head}} (well, its underlying module) was edited so that it indicates "transliteration needed" if there's no transliteration. Can someone who knows Lua (I do not) please add in the ability to turn off this message with a template parameter (perhaps tr=[empty string] or a new parameter)? (Pinging Ruakh just because of a conversation we once had.)—msh210℠ (talk) 05:26, 18 June 2015 (UTC)[reply]

This can already be done. --Wiki Tiki 89 14:20, 18 June 2015 (UTC)[reply]

Ah, thanks.—msh210℠ (talk) 18:09, 18 June 2015 (UTC)[reply]

Why is no transliteration necessary? —CodeCa t 18:25, 18 June 2015 (UTC)[reply]

Not only unnecessary but undesirable, and here's why: There are two different forms there, neither of which is a lemma (nor even such that the other can really be said to be a form of it), and which have different transliterations, which are noted on the definition lines in the manner accepted at WT:T:AHE.—msh210℠ (talk) 03:41, 21 June 2015 (UTC)[reply]

Then they should have separate POS sections and headword lines. —CodeCa t 21:09, 23 June 2015 (UTC)[reply]

Discussion among the Hebrew editors has led to a conclusion opposite of what you've just put forth. (I can't find the bulk of that discussion, but some early parts of it are at [[User talk:Msh210/Archive/niqqud and excessive spellings, redux]], and the conclusion is mentioned at [[Wiktionary:Beer parlour/2011/June#Separate entries for reflexive verbs?]].) If you wish to argue for your conclusion (which you haven't done here), I invite you to do so at WT:T:AHE, but, for now, that's not the way it's being done.—msh210℠ (talk) 16:28, 29 June 2015 (UTC)[reply]

class="vsSwitcher vsClass-pronunciations" no longer working?

<div class="vsSwitcher vsClass-pronunciations"> does not seem to be working any more, affecting templates such as {{grc-IPA}} and {{zh-forms}} which are now always expanded. Was there an edit that affected this function? Wyang (talk) 01:08, 20 June 2015 (UTC)[reply]

Yes, I wasn't aware that this was even in use at all. —CodeCa t 01:51, 20 June 2015 (UTC)[reply]

I fixed those two templates now. Are there any more? —CodeCa t 01:54, 20 June 2015 (UTC)[reply]

Thanks! The only other module using it is Module:User:ZxxZxxZ/pronunciation, used by User:ZxxZxxZ/sandbox. Wyang (talk) 02:04, 20 June 2015 (UTC)[reply]

Please make fixes to Module:languages/data3/a and Module:languages/data3/s

I don't have administrative privileges.

Could someone (@CodeCat, Wikitiki89, Atitarev etc.) please change the entries for the following languages in Module:languages/data3/a and Module:languages/data3/s to read as follows:

For Module:languages/data3/a:

 
m["abv"] = {
	canonicalName = "Baharna Arabic",
	otherNames = {"Bahrani Arabic"},
	type = "regular",
	scripts = {"Arab"},
	family = "sem-arb",
	entry_name = {
		from = {u(0x0671), u(0x064B), u(0x064C), u(0x064D), u(0x064E), u(0x064F), u(0x0650), u(0x0651), u(0x0652), u(0x0670), u(0x0640)},
		to   = {u(0x0627)}},
}

m["acq"] = {
	canonicalName = "Ta'izzi-Adeni Arabic",
	otherNames = {"Southern Yemeni Arabic"},
	type = "regular",
	scripts = {"Arab"},
	family = "sem-arb",
	entry_name = {
		from = {u(0x0671), u(0x064B), u(0x064C), u(0x064D), u(0x064E), u(0x064F), u(0x0650), u(0x0651), u(0x0652), u(0x0670), u(0x0640)},
		to   = {u(0x0627)}},
}

m["acw"] = {
	canonicalName = "Hijazi Arabic",
	otherNames = {"Hejazi Arabic", "West Arabian Arabic"},
	type = "regular",
	scripts = {"Arab"},
	family = "sem-arb",
	entry_name = {
		from = {u(0x0671), u(0x064B), u(0x064C), u(0x064D), u(0x064E), u(0x064F), u(0x0650), u(0x0651), u(0x0652), u(0x0670), u(0x0640)},
		to   = {u(0x0627)}},
}

m["aec"] = {
	canonicalName = "Saidi Arabic",
	otherNames = {"Sa'idi Arabic", "Upper Egyptian Arabic", "Upper Egypt Arabic"},
	type = "regular",
	scripts = {"Arab"},
	family = "sem-arb",
	entry_name = {
		from = {u(0x0671), u(0x064B), u(0x064C), u(0x064D), u(0x064E), u(0x064F), u(0x0650), u(0x0651), u(0x0652), u(0x0670), u(0x0640)},
		to   = {u(0x0627)}},
}

m["ars"] = {
	canonicalName = "Najdi Arabic",
	type = "regular",
	scripts = {"Arab"},
	family = "sem-arb",
	entry_name = {
		from = {u(0x0671), u(0x064B), u(0x064C), u(0x064D), u(0x064E), u(0x064F), u(0x0650), u(0x0651), u(0x0652), u(0x0670), u(0x0640)},
		to   = {u(0x0627)}},
}

m["avl"] = {
	canonicalName = "Eastern Egyptian Bedawi Arabic",
	otherNames = {"Bedawi Arabic", "Levantine Bedawi Arabic"},
	type = "regular",
	scripts = {"Arab"},
	family = "sem-arb",
	entry_name = {
		from = {u(0x0671), u(0x064B), u(0x064C), u(0x064D), u(0x064E), u(0x064F), u(0x0650), u(0x0651), u(0x0652), u(0x0670), u(0x0640)},
		to   = {u(0x0627)}},
}

m["ayh"] = {
	canonicalName = "Hadrami Arabic",
	otherNames = {"Hadhrami Arabic"},
	type = "regular",
	scripts = {"Arab"},
	family = "sem-arb",
	entry_name = {
		from = {u(0x0671), u(0x064B), u(0x064C), u(0x064D), u(0x064E), u(0x064F), u(0x0650), u(0x0651), u(0x0652), u(0x0670), u(0x0640)},
		to   = {u(0x0627)}},
}

m["ayn"] = {
	canonicalName = "Sanaani Arabic",
	type = "regular",
	scripts = {"Arab"},
	family = "sem-arb",
	entry_name = {
		from = {u(0x0671), u(0x064B), u(0x064C), u(0x064D), u(0x064E), u(0x064F), u(0x0650), u(0x0651), u(0x0652), u(0x0670), u(0x0640)},
		to   = {u(0x0627)}},
}

For Module:languages/data3/s:

m["sqr"] = {
	canonicalName = "Siculo-Arabic",
	type = "regular",
	scripts = {"None"},
	family = "sem-arb",
}

m["ssh"] = {
	canonicalName = "Shihhi Arabic",
	type = "regular",
	scripts = {"Arab"},
	family = "sem-arb",
	entry_name = {
		from = {u(0x0671), u(0x064B), u(0x064C), u(0x064D), u(0x064E), u(0x064F), u(0x0650), u(0x0651), u(0x0652), u(0x0670), u(0x0640)},
		to   = {u(0x0627)}},
}

m["shu"] = {
	canonicalName = "Chadian Arabic",
	type = "regular",
	scripts = {"Arab"},
	family = "sem-arb",
	entry_name = {
		from = {u(0x0671), u(0x064B), u(0x064C), u(0x064D), u(0x064E), u(0x064F), u(0x0650), u(0x0651), u(0x0652), u(0x0670), u(0x0640)},
		to   = {u(0x0627)}},
}

This puts these languages in line with other Arabic spoken languages that use the Arabic script, and adds alternative names in line with Wikipedia (and fixes the family for Siculo-Arabic).

Thanks.

Benwing (talk) 08:42, 21 June 2015 (UTC)[reply]

@Benwing

Done. --Anatoli T. ^{(обсудить}/^вклад) 09:06, 22 June 2015 (UTC)[reply]

@Atitarev Thanks! Benwing (talk) 08:18, 23 June 2015 (UTC)[reply]

Undo and thank links in the recent changes?

Can these two options be added for each change in recent changes? It would be a lot less cumbersome than going to the diff all the time. It might make editors more inclined to use undo instead of rollback too, which is something a few people have complained about. —CodeCa t 23:24, 22 June 2015 (UTC)[reply]

Yes. How do you know if you should thank or undo without going to the diff? Do you use any inline diff tool?--Dixtosa (talk) 20:12, 23 June 2015 (UTC)[reply]

If one uses "Navigation popups" (called such in Prefs; historically called Lupin popups) one can hover over "diff" links to see them without actually clicking on them and leaving the page one is on. - -sche (discuss) 21:02, 23 June 2015 (UTC)[reply]

There should be a "like" button for every page and edit as well. Wyang (talk) 03:32, 27 June 2015 (UTC)[reply]

Red "D" delete button no longer works in recent changes

The patrolling gadget's red "D" delete button no longer works; clicking it displays "notoken: The token parameter must be set". The blue "m" mark-as-patrolled button does work. - -sche (discuss) 00:30, 23 June 2015 (UTC)[reply]

Can you point me to the gadget? What's its name? --Dixtosa (talk) 20:12, 23 June 2015 (UTC)[reply]

It's in prefs as "Patrolling enhancements – makes it faster and easier to mark edits as patrolled." Ruakh wrote it. - -sche (discuss) 21:02, 23 June 2015 (UTC)[reply]

Edit filter to discourage edits to main WT:TR page

This has happened several times, albeit mostly from the same user under various IPs. Can we craft an edit filter to stop it? Protecting the page won't work because it affects how users can edit sections of the page (per the commentary in the page protection log). - -sche (discuss) 18:42, 23 June 2015 (UTC)[reply]

The "Edit" button is hidden on this page (WT:Grease pit) using JS I guess. So, do the same for Tea room and Beer parlour too.--Dixtosa (talk) 20:12, 23 June 2015 (UTC)[reply]

Hmmm. Not hidden for me. Sometimes I enjoy having admin privilege, if that's what it is. DCDuring TALK 16:17, 24 June 2015 (UTC)[reply]

It is hidden in Vector.--Dixtosa (talk) 16:36, 24 June 2015 (UTC)[reply]

I use Vector. I get a warning banner when the edit frame opens. I have not knowingly done anything to make that happen. DCDuring TALK 17:20, 24 June 2015 (UTC)[reply]

And un-hidden for sysops. — Keφr 09:08, 27 June 2015 (UTC)[reply]

Added Special:AbuseFilter/43. — Keφr 09:08, 27 June 2015 (UTC)[reply]

dump request: English nouns

Can someone please generate for me a list of all pages (or all ns0 pages) in category:English nouns and all its subcategories except English noun forms and English plurals? (That is, don't exclude something just because it's in English noun forms/plurals, if it's also in category:English nouns or a different subcat; but don't include it just because it's in English noun forms/plurals.) It can be from the most recent dump or from the live version.

I know of no tool that does this — CatScan grabs only [[…]] categories, not templatized ones, and the API limits the number of results — and directing me to such a tool would be great instead of doing it for me, if one exists.

Thanks very much. I have to mention that this will be for my personal use rather than for the betterment of enwikt.—msh210℠ (talk) 19:45, 23 June 2015 (UTC)[reply]

AWB can do that. Yes 238 thousand is too many but still probably the easiest solution. I have queried Category:Spanish lemmas (38,306 entries) it was pretty waitable. --Dixtosa (talk) 20:12, 23 June 2015 (UTC)[reply]

Thanks for the advice. I downloaded AWB and attempted the task just for category:English nouns. (I don't see that there's a way to include only some subcats, so I figured I'd do them one by one, though of course it's not ideal.) When it told me "List complete!" and stopped working, the list had but 24998 entries on it (and when I saved the list to a file, the file, too, had only 24998 entries), even though the category reports that it has 238412 entries. (Granted, I omitted non-ns0 pages from the AWN list whereas the category includes them, but that obviously doesn't account for all the difference.) It seems AWB conked out after blockmaker (or doesn't like blockmaking). I don't see anything in w:'s AWB manual about curtailed results. Does anyone have advice on how to make AWB work with large categories, or a non-AWB solution for me?—msh210℠ (talk) 21:22, 23 June 2015 (UTC)[reply]

I use Python scripts with Pywikibot for this kind of thing. I could show you how, if you would like that. It takes some learning, but the sky is the limit once you get it. —CodeCa t 21:34, 23 June 2015 (UTC)[reply]

Oh, I used to use pywikipediabot (as it was called then IIRC) and stopped when the version I had stopped working and the new version I downloaded wouldn't work either (IIRC). I taught it to myself the first time and can do so again, presumably, but thank you for the offer. On the other hand, if it's really easy to run this script and someone's willing to do so for me…. :-) —msh210℠ (talk) 05:03, 24 June 2015 (UTC)[reply]

Teach a Wiktionarian to fish, and all that... —CodeCa t 13:16, 24 June 2015 (UTC)[reply]

Maybe this AWB plugin, for large categories w:Wikipedia:AutoWikiBrowser/NoLimits plugin? -- Curious (talk) 18:19, 26 June 2015 (UTC)[reply]

Thank you.—msh210℠ (talk) 06:07, 28 June 2015 (UTC)[reply]

You can also request an account on the Tool Labs to have access to a replicate of the current Wiktionary database. From there you can make any kind of request in SQL to get what you want. This requires to know a bit about command-line and SQL queries though. — Dakdada 13:15, 24 June 2015 (UTC)[reply]

Thanks for the suggestion. However, since, as I said, I'll be using it for my own purposes, it doesn't seem right to request an account there.—msh210℠ (talk) 14:51, 24 June 2015 (UTC)[reply]

You can pay MW back later, by using your honed skills more directly for project benefit. DCDuring TALK 16:15, 24 June 2015 (UTC)[reply]

Actually, I realize that the list of categories I specified above isn't precisely what I need, so, on the off chance that someone is actually thinking of doing this for me, don't. (I'm doing it via pywiki.) But thank you.—msh210℠ (talk) 17:29, 24 June 2015 (UTC)[reply]

I got as far as putting this Python script together, using the API (it's hard to use the dumps for this, because of the template issue). May or may not be useful; I have always found pywiki somewhat enraging to work with. ;-) -- Visviva (talk) 17:40, 24 June 2015 (UTC)[reply]

Thank you. I myself tried category.py listify -from:English_nouns, but kept getting HTTP 5xx and other errors for reasons unknown to me.—msh210℠ (talk) 22:59, 24 June 2015 (UTC)[reply]

Language code for Dothraki

We now have two entries derived from this constructed language (Dothraki, the name of the language itself, and Khaleesi, a title used as a girl's name). Should it now have its own language code? Two other constructed languages in Category:English terms derived from constructed languages (Black Speech, Klingon) with just two entries have their own language codes. Maybe "dki?" That doesn't seem to be in use. -Cloudcuckoolander (talk) 02:09, 26 June 2015 (UTC)[reply]

It's never a good idea to hijack unused codes for languages- they tend to eventually get assigned other languages by the ISO. We would need to create a code starting with "art-", as we did with Black Speech ("art-bsp"). If you're wondering why the code for Klingon isn't like that, it's because it was actually assigned by the ISO. Chuck Entz (talk) 03:33, 26 June 2015 (UTC)[reply]

Are we even sure it is a constructed language rather than merely a fictional one? Does it exist beyond some staple words? Korn [kʰʊ̃ːæ̯̃n] (talk) 09:40, 26 June 2015 (UTC)[reply]

There isn't much of it in the books, but in the TV series (I believe starting with the second season), they have entire conversations in it. According to Wikipedia, "As of September 2011, the language comprised 3,163 words, not all of which have been made public." I'm not sure how sophisticated the grammar is. --Wiki Tiki 89 14:36, 26 June 2015 (UTC)[reply]

It's a fully functional conlang, and many people other than David Peterson, its creator, are perfectly capable of composing poetry and other extended texts in it. We should certainly have a code, something along the lines of art-dth. —Μετάknowledge^{discuss/deeds} 18:30, 26 June 2015 (UTC)[reply]

It makes sense that they've had to develop Dothraki into a functional language when they're scripting entire scenes in it. There's only so far they could have gone with just writing random exotic-sounding gibberish. I think people are often able to discern structure even when they can't discern meaning; that is, they can tell a foreign language they don't understand from gibberish.

Anyway, I support using "art-dth", "art-dki", or something similar as an internal language code for Dothraki. -Cloudcuckoolander (talk) 20:34, 26 June 2015 (UTC)[reply]

I was thinking "art-dtk", in case we don't have enough suggestions... --Wiki Tiki 89 21:01, 26 June 2015 (UTC)[reply]

I don’t think we accept any new constructed languages, only the older major ones. For one thing, I believe that Dothraki is copyrighted. See discussion at Wiktionary:Beer_parlour/2014/July#Inclusion_of_Dothraki. —Stephen ^(Talk) 09:55, 27 June 2015 (UTC)[reply]

It can be put into Module:etymology language/data, then. — Keφr 10:18, 27 June 2015 (UTC)[reply]

The Beer Parlour discussion above led to a removal of Tolkien's languages and I'm not sure if the idea was right. Weren't they not made as integral part of his literature, but the other way round? He initially was mainly a conlanger who made some literature in his languages, to put them to some use, innit? It seems more useful to me if we just keep all the potentially copyrighted languages until somebody actually complains. We might encounter lenience or even benevolence and even if someone tells us to take it down, then we just take it down and that's that. Or am I missing something? Korn [kʰʊ̃ːæ̯̃n] (talk) 10:41, 27 June 2015 (UTC)[reply]

@Stephen - The goal here isn't to create a complete lexicon of Dothraki, only to document Dothraki words that have entered into English. It's clearly within fair use. -Cloudcuckoolander (talk) 17:52, 4 July 2015 (UTC)[reply]

Correct. Now the question: should the language code go in Module:etymology language/data (if we're only going to have entries on words that have entered English or other languages), or Module:languages/datax (if we anticipate having a very small appendix of other illustrative words under a de minimus claim). I would think Module:etymology language/data, but it seems all of our art- codes are actually in Module:languages/datax. - -sche (discuss) 18:13, 4 July 2015 (UTC)[reply]

I have added "art-dtk" to Module:languages/datax; it is not a dialect of any other language, so adding it to Module:etymology language/data would have required users to write e.g. {{etyl|art-dtk|en}} {{m|und|foo}}. Users are expected not to add many words in the language, per the previous discussion. - -sche (discuss) 16:33, 5 July 2015 (UTC)[reply]

Actually, why not fix Template:mention so that mentions of etymology-only languages could be tagged with the proper language? (No link, just tag with the script and language code.) — Keφr 17:29, 5 July 2015 (UTC)[reply]

@Kephir go for it. Some (most?) of the etymology-only codes are dialects of other languages that should in fact link, but that can (and may already, to an extent) be handled with mapping in Module:etymology language/data. - -sche (discuss) 06:38, 5 August 2015 (UTC)[reply]

Lowercase option for Template:wikipedia

In this discussion, User:Brantmeierz pointed out that the {{wikipedia}} template on zdotu'a links to the wrong page on the Lojban Wikipedia. Page titles on the Lojban Wikipedia are case-sensitive, and because {{wikipedia}} automatically capitalizes the first letter of the title, the link goes to w:jbo:Zdotu'a instead of w:jbo:zdotu'a.

After looking at the template documentation, I can't find a way to address this. I would appreciate it if someone familiar with template syntax could edit the template to add an optional parameter that keeps the title lowercase. Thank you. —Mr. Granger (talk • contribs) 15:05, 27 June 2015 (UTC)[reply]

Pinging @CodeCat, @Daniel Carrero, and @Kephir, the most recent editors of this template. —Mr. Granger (talk • contribs) 06:26, 5 August 2015 (UTC)[reply]

The calls to {{ucfirst:...}} are what is triggering the capitalization. It sounds like we need a special flag in Module:languages/data3/j to indicate that capitalization should not happen in Lojban. Benwing (talk) 08:41, 5 August 2015 (UTC)[reply]

If someone will be looking at this and the inline interproject templates, I would appreciate a switch to allow italics, eg, "i=1". It reinforces the 'proper' use of italics and gives a more consistent appearance in External links. IMHO it is not worthwhile to make finer formatting, as there are difference between viruses and other living things, and we don't have all that many subspecies, section, and varieties entries, for which 'subsp.' etc are not supposed to be italicized. DCDuring TALK 12:48, 5 August 2015 (UTC)[reply]

Third person plural past forms of Estonian verbs

I hope this is the correct place to say this. The third person plural past forms of Estonian verbs are conjugated wrong in Wiktionary. The form is always the same as the second person singular past form. The verb 'to speak' is rääkima in Estonian. If you want to say "they spoke", it is nad rääkisid, but the conjugation table says "rääkisivad" instead of the correct "rääkisid".

The present tense ending for the third person is -vad, but the "va" is dropped when forming the past and also the conditional, which is currently conjugated correctly in Wiktionary. The same way, the -b suffix of the third person singular does not appear in past nor conditional, hence although "s/he speaks" is ta räägib (not *ta rääg) in Estonian, if you want to say s/he spoke, it is ta rääkis and not *ta rääkisib.

Could anyone fix this? The -va- in third person plural past forms of Estonian verbs should be dropped, leaving the same form as second person singular. 88.112.130.243 15:46, 28 June 2015 (UTC)[reply]

I've fixed it now. I've tried to improve our coverage of Estonian in the past, but I'm not an Estonian speaker so I've had to rely on whatever information I'm able to gather. If you know Estonian well, your help in improving things would be much appreciated! —CodeCa t 15:59, 28 June 2015 (UTC)[reply]

Need help for sortable table

Hi, I made a sortable table and I needed to uses some html code to be able to have different background & script colour in headers. But now the arrow are invisible, but I can sort the column... What to do to have them back ?

Also I want to know if it possible to have underline for all the links automatically insides the table without adding "ins" "/ins" or "u" "/u" to each words but with a code in table condition ? Because of the colour of the background the blue of the link is not very visible, so I use "font color""/font" but then we can't see that these terms are link... So I want automatic underline for the link in the table, can someone help ? Thank

https://en.wiktionary.org/wiki/User_talk:Nemzag#The_Keys

Mangêzd (talk) 14:38, 30 June 2015 (UTC)[reply]