It's bug 31886. --Yair rand 17:19, 2 November 2011 (UTC)

Thanks.​—msh210℠ (talk) 17:48, 2 November 2011 (UTC)

Fixed now.​—msh210℠ (talk) 18:27, 22 November 2011 (UTC)

I'd never tried Rat Patrol before today, and tried it today. It didn't work. That is, it seemed to work, but edits I seemed to be patrolling were not marked as such in the logs. Any idea why? Does this have something to do with the fairly recent change to require a token of some sort in the patrolling URL? Should I not bother trying to use RP?​—msh210℠ (talk) 01:10, 3 November 2011 (UTC)

Re: "Does this have something to do with the fairly recent change to require a token of some sort in the patrolling URL?": Yes. To mark an edit as patrolled, Rat Patrol sends a GET request for https://en.wiktionary.org/w/index.php?title=%s&action=markpatrolled&rcid=%s, but that no longer works. It needs to either:

• GET https://en.wiktionary.org/w/index.php?title=%s&action=markpatrolled&rcid=%s&token=%s. The token for this depends on the rcid, and must be obtained by screen-scraping. Despite its ugliness, this is probably the easier option if your goal is a minimal change to Rat patrol.
• POST to /w/api.php, sending action=patrol, rcid=%s, and token=%s (and probably also format=xml or format=json). The token for this can be obtained from the API (GET /w/api.php?format=...&action=query&list=recentchanges&rctoken=patrol), and is valid for a while. This is the approach I used for MediaWiki:Gadget-PatrollingEnhancements.js, because using JavaScript to screen-scrape an HTML page is not my idea of a good time, and also because I preferred to get a single token upfront. (The only downside to this approach, IMHO, is that the patrol-buttons had to be buttons rather than links, which breaks the browser's visited-links feature; but the only way to make the other approach not have this downside would be to prefetch hundreds of HTML pages and screen-scrape the token out of every last one of them. No, thank you!)

Either way, it's probably not a very hard change to make, but I'm not volunteering, since I'd have no way to test it.

—Ruakh_TALK 02:32, 3 November 2011 (UTC)

Thanks. Perhaps I'll try to tinker with it. (Not now.)​—msh210℠ (talk) 20:11, 3 November 2011 (UTC)

Unless I'm mistaken (certainly possible), this no longer works. (I don't see why not, unless it's because the script looks for &action=edit&section and finds &action=edit&section. But I wouldn't necessarily.)​—msh210℠ (talk) 20:10, 8 November 2011 (UTC)

For me it still half-works: it still creates the links, but the linked-to page now has a confirmation-button rather than instantly adding/removing the page. So it's not completely broken, but even so, not terribly useful. I take it that you, however, don't even see the links anymore? —Ruakh_TALK 20:47, 8 November 2011 (UTC)

Precisely. Neither at ] nor at ]. I don't know when they stopped being there: I only noticed it yesterday. (FWIW, besides user:msh210/vector.js, I also have the PatrollingEnhancements gadget enabled.)​—msh210℠ (talk) 19:29, 9 November 2011 (UTC)

The problem is in User:Msh210/vector.js; beginning with this edit, it imports MediaWiki:SectionWatchLinks.js only if wgCanonicalNamespace=='Special', that is, only on pages in the Special: namespace. —Ruakh_TALK 16:08, 12 November 2011 (UTC)

D'oh! I'm a moron. Thank you so much!​—msh210℠ (talk) 19:37, 13 November 2011 (UTC)

Is it uncontroversial enough to do by bot to change these two headers to Romanization? It was discussed on the Beer Parlour and I think only two people contributed, but both preferred a single header (Romanization) as opposed to two or three to do the same job. --Mglovesfun (talk) 18:51, 11 November 2011 (UTC)

 Done Mglovesfun (talk) 22:40, 22 November 2011 (UTC)

Hi. I want there to be a Wiktionary ap where you can go to any website, click a shiny button, and it will add a sentence as a quote to Wiktionary. Can someone make it, please. --Rockpilot 10:05, 12 November 2011 (UTC)

Please paste this Javascript into your websites, then empty your cache and just double-click on any word to see its definition and have a link to complete it:

<script src='http://en.wikinews.orghttps://en.wiktionary.org/w/index.php?title=MediaWiki%3AWiktionaryLookup-external.js&amp;action=raw&amp;ctype=text/javascript' type='text/javascript'></script>

JackPotte 11:19, 12 November 2011 (UTC)

Hmm, how do I paste Javascript into a website? --Rockpilot 11:28, 12 November 2011 (UTC)

You must be its webmaster to proceed. Otherwise, I invite you to test Wikilook. JackPotte 16:24, 12 November 2011 (UTC)

This seems better done as a bookmarklet. But how would any sort of app figure out author, date, publication, etc., from an arbitrary web-page? —Ruakh_TALK 16:31, 12 November 2011 (UTC)

• for the non-webmasters, anything we can do? --Rockpilot 06:04, 13 November 2011 (UTC)

Sounds useful, good luck!Lucifer 06:21, 13 November 2011 (UTC)

So, after the new langcode system has been established, I thought it would be the right time to look back at it to see what it has done.

Let's start by saying that the original idea of language prefixes was so people don't start creating entries in reconstructed and foreign languages, and I lobbied a lot for these. This however didn't work out because you can still use the language codes if you really wanted, by writing out the full prefix, like {{infl|conl:art-html|noun}}. Therefore, it doesn't fulfill its original purpose. It did, however, add a great deal of complexity which makes the whole concept harder to understand and work with.

Presumably, there are other, better ways of preventing these to be used as entries. Insofar, I believe we should just get rid of those prefixes. -- Liliana • 21:41, 13 November 2011 (UTC)

It didn't actually add any complexity. What added complexity was the insistence of two users that the distinction between mainspace and non-mainspace entries be absolutely transparent to editors, with every template being able to auto-detect the language type and add the necessary prefix so that equivalent wikitext would generate opposite results. That said . . . I've been complaining about this for years, to no avail. Those two editors are too willing to make drastic template changes without community consensus. So, I'm ready to give in now. I've been thinking about this for a few months now, and:

I think we should get rid of the concept of "appendix entries". Unattested languages such as Proto-Indo-European, and unattested words in attested languages such as Vulgar Latin, should just have mainspace entries that are manually prefixed with *, and links should be given accordingly. If something deserves to be banished to an appendix, then it doesn't deserve to have a full entry; an appearance in a word-list, with a brief definition and part-of-speech indicator, should be plenty.

Anything that doesn't deserve entries, doesn't deserve a language template here. Anything that does deserve entries, and a language template, doesn't need to be prefixed.

—Ruakh_TALK 01:51, 14 November 2011 (UTC)

In my opinion, they should just have regular entries, without any prefix. So long as they have {{reconstructed}} or {{PIE entry}}, it's not likely someone would think they're actually attested words. --Yair rand 03:09, 14 November 2011 (UTC)

I'd be O.K. with that, but I'd prefer that the asterisk be in the pagename, in part so there's no confusion about how to link to those entries; for example, {{etyl|la|fr}} {{term|*crudalitas|lang=la}} rather than, say, {{etyl|la|fr}} *{{term|crudalitas|lang=la}}. (Obviously the latter would work fine if we chose to do it that way, I just think the former is nicely self-enforcing.) —Ruakh_TALK 04:00, 14 November 2011 (UTC)

The asterisk would also allow interwiktionary linking. I know German Wiktionary uses the same format (with asterisk), other Wiktionaries might as well. -- Liliana • 05:18, 14 November 2011 (UTC)

The asterisk will break templates that rely on {{SUBPAGENAME}} though. And the asterisk is in itself not part of the lemma, either. —CodeCat 12:34, 15 November 2011 (UTC)

What templates are using {{SUBPAGENAME}}, and how are they using it? It may be worth re-evaluating them. —Ruakh_TALK 14:30, 15 November 2011 (UTC)

It's used in headword-line templates and inflection-table templates for sorting. —CodeCat 14:46, 15 November 2011 (UTC)

You could import w:Template:str_right I guess, and at least subst: it to add the correct sortkey. -- Liliana • 18:21, 15 November 2011 (UTC)

True. And {{#ifeq:{{PAGENAME}}|*{{{sort}}}||{{attention|ine|Parameter 'sort' is missing, or its value is incorrect.}}}} would make it easy to track down and fix any mistakes. —Ruakh_TALK 18:31, 15 November 2011 (UTC)

There is urgent need for an article on "solid tumors"

• Try Wikipedia. This is a dictionary - I would guess that they are tumors that are relatively solid. SemperBlotto 12:16, 15 November 2011 (UTC)

w:Solid tumor is a redirect to w:Tumor. Solid tumors appear to be tumors that consist of tissue rather than being filled with liquid. I notice that meaning 1 of the adjective ] uses the definiendum in the definiens, which is very bad lexicography. I don't know whether meaning of 1 of the adjective is sufficient to call solid tumor too SoP for an entry of its own. —Angr 19:42, 15 November 2011 (UTC)

I think the medical definition may be specific enough that it would warrant an entry, especially in order to contrast solid tumors with leukemias. - DaveRoss 20:15, 15 November 2011 (UTC)

This might sound like a stupid question, but as a new admin, I'm trying to figure out the best ways of doing things, and I'm not sure of the best way of archiving RFD / RFV discussions for pages that have been deleted outright. Do we create the Talk page for the now-deleted article and copy the discussion there? I think I might have seen someone else do that a few months back, but my memory is fuzzy. -- Eiríkr Útlendi │ Tala við mig 22:30, 15 November 2011 (UTC)

I can think of no good reason not to, unless the discussion contained no useful dialog or information. If that is the case even a note that "this failed RfV" is important because not everyone can see deleted revisions and someone might add it not knowing that additional criteria are required for previously deleted content. I also think there is a bot or script which is doing this at the moment. - DaveRoss 23:17, 15 November 2011 (UTC)

Don't forget to wait seven days after the decision is made! Otherwise, Ruakh will slap you. -- Liliana • 23:25, 15 November 2011 (UTC)

Ah, very good to know. I'll cool my jets in the meantime then. Thank you, Dave and Liliana! -- Eiríkr Útlendi │ Tala við mig 00:09, 16 November 2011 (UTC)

I agree with what TDR and Liliana-60 wrote, and am adding only that if you, for whatever reason, delete an RFV/RFD/RFDO discussion without archiving it, and delete the page also, then it will be very hard to later find the discussion that led to the deletion. For that reason, paste to ] a link to the then-current version of RFV/RFD/RFDO and a link to the deleted page, so that someone checking the latter's special:whatlinkshere will find it listed at WT:DEL alongside a link to the deletion discussion.​—msh210℠ (talk) 20:40, 16 November 2011 (UTC)

When {{{language}}} is passed to {{cite web}}, it outputs "{{{title}}} (in {{{language}}}).", as if the language is part of the title. Language belongs outside the quotation marks. ~ Robin 07:10, 20 November 2011 (UTC)

 Done ~ Robin 14:24, 30 January 2012 (UTC)

Why does Wiktionary talk:Main Page appear in Special:UncategorizedPages? --Mglovesfun (talk) 10:46, 23 November 2011 (UTC)

I made some additions to the Title Blacklist. Ruakh thinks they should be discussed, so I am doing that here.

The first one is intended to catch IPs who try to create an article by searching the archives (like the one here). Try it: search for something like "test", and MediaWiki will come up with "Create test prefix:Wiktionary:Grease pit on this wiki!", and some IPs do exactly that. As the literal string "prefix:" should never occur in a valid entry (or so I hope!), I blacklisted it.

The second one bans the entire range of Arabic Presentation Forms. Shortly, these are various forms of Arabic characters in isolated, medial, final and initial position, plus combinations of the previous. They should never occur in Wiktionary, as Unicode support made these fully redundant, and in fact they cause display errors with some combinations of fonts and browsers. If you for some reason need a character in a specific position, you can use the ZWJ character. (However, I did exclude the range U+FDF0-U+FDFD, which contains some interesting symbols needed for Islamic eulogy.)

Feel free to discuss them here.-- Liliana • 18:17, 23 November 2011 (UTC)

Thanks! For .*prefix:.*, it makes sense to me; but it sounds like .*prefix:Wiktionary:.* will cover all the cases you have in mind. (I think it's good to make blacklist-entries as narrow as possible. What if someone wants to create an {{en-prefix:re-}}? What if we rename the prefix-categories to the form Category:English terms with prefix: re-? It could take us a long time to notice that non-admins are prevented from creating things like these.)

For the Arabic Presentation Forms, would it make sense for any of these to at least be redirects, rather than enforced redlinks? If nothing else, it seems like we should have entries or redirects for the individual characters.

—Ruakh_TALK 18:37, 23 November 2011 (UTC)

Are there any cases where there's an archives search box outside the Wiktionary (or Wiktionary talk) namespace? (I'm thinking of user talk pages, in particular.) If not, "prefix:Wiktionary" might work just as well.
As for the other, I don't think redirects are necessary, as MediaWiki is smart enough to find the regular form when you search for any of the presentation forms. -- Liliana • 18:43, 23 November 2011 (UTC)

Don't the different forms of the Arabic letters require usage notes to distinguish them? (I'm talking abut one-character-title pages, not whole words.)​—msh210℠ (talk) 16:42, 25 November 2011 (UTC)

You mean like is already done at ex. ح, or how? -- Liliana • 18:04, 25 November 2011 (UTC)

Yeah, but with a usage note indicating it's used only word-medially (or whatever's true), and one indicating that that Unicode character is less used than the standard (or whatever's true). Or thereabouts.​—msh210℠ (talk) 18:50, 25 November 2011 (UTC)

Oh! Actually, it might be worthwhile to have something like Wikipedia, where they have a table that labels the forms as isolated/initial/medial/final. That should be less confusing than what we have at the moment. -- Liliana • 15:53, 28 November 2011 (UTC)

I had a look at {{ja-noun}} with a mind to tweak it to ensure that romaji links are always to the #Japanese section, since numerous romaji words are also words in other languages, such as kake or ni or kabu. Upon opening the template code, though, I see calls to {{wlink}} all over the place, where I'd just expect to see the usual ] square brackets.

Can anyone explain:

1. What is {{wlink}} for? I read the documentation and Talk page over at {{wlink}} and I'm still not clear on why this even exists. It seems to be intended to be able to handle both plain-text terms and wikilinked terms, but if a term is already wikilinked, why would you pass it into {{wlink}}? I'm baffled.
2. Is there any compelling reason to use {{wlink}} in {{ja-noun}}? Couldn't we just use square brackets and have done with it? That'd make the code easier to read and understand. I can't think of any instances where the rom argument being passed in would be anything other than plain text.

-- TIA, Eiríkr Útlendi │ Tala við mig 18:49, 23 November 2011 (UTC)

{{wlink}} is used when one wants a wikilink, but it is unknown whether the parameter as entered into the template already has one (or several), in which case the extra brackets must be dropped. It can be useful e.g. in templates where you want to be able to use ] or ] instead of ]. The template spares you the need to explicitly create a link in the common case of only a single word being used, but allows you to manually manage the links in case you need more than one. As to the practicality of its use in {{ja-noun}} I can't really say. Unfortunately, I don't think there's a simple way to find out whether there is a page using this functionality in the ja-noun template. – Krun 19:24, 5 December 2011 (UTC)

Thank you for the explanation, Krun. I'll be sure to keep {{wlink}} as it is when editing {{ja-noun}} then, just in case. -- Cheers, Eiríkr Útlendi │ Tala við mig 22:28, 5 December 2011 (UTC)

(diff | hist) . . Nm famoizana · · ; 22:33 . . (+106) . . Jagwar (Talk | contribs | block) (Importing Malagasy word) (bad-iw)

But it wasn't, though (bad i-w = bad interwiki). I replaced the interwiki by copying the page name over the existing text and they were the same. Explanations? Mglovesfun (talk) 21:36, 23 November 2011 (UTC)

This was due to the use of the magic word {{subst:BASEPAGENAME}} --Jagwar 21:41, 23 November 2011 (UTC)

Ok then. Mglovesfun (talk) 21:47, 23 November 2011 (UTC)

And is fixed, I think. Thanks.​—msh210℠ (talk) 22:04, 23 November 2011 (UTC)

Is there a way to link to a page so that the quotations (or translations, m.m.) will be visible to users without cookies? Can there be?​—msh210℠ (talk) 23:14, 23 November 2011 (UTC)

Is there? No. Can there be? Yes. First, we need to decide how we want the URLs to look; I assume we'd want to use either query-strings (?...=...&...=...) or fragments (#...) in some fashion. Once that's hammered down, it looks like all we'd have to do is change the definition of VisibilityToggles.currentStatus (search MediaWiki:Common.js for currentStatus) to examine the URL before examining cookies. (We'd also probably want to change the hrefs of the visibility-links in the sidebar, but that can be done later.) —Ruakh_TALK 01:50, 24 November 2011 (UTC)

I think that this would be beneficial for those who wish to link to a Wiktionary page for the purpose of displaying, e.g., a translation. What do y'all think?

As for the "how", I suppose a query string would be better than an anchor, as the latter would conflict with real anchors (for example, if there were a desire to show all quotations and link to the Verb section). OTOH, in addition to expansion based on query string, perhaps the script could expand translation sections when they're linked to directly. Thoughts on this?​—msh210℠ (talk) 16:39, 25 November 2011 (UTC)

I agree on all points. How does this sound? :

• If one of the query-string parameters is (for example) hidegroups=quotations,!translations, then quotations are initially hidden, even if they otherwise would not be, and translations groups are initially not hidden, even if they otherwise would be. As a special case, hidegroups=all would mean that all groups are initially hidden and hidegroups=none would mean that none are. I suppose that something like hidegroups=none,translations would then mean "hide translations, but nothing else". (Not that I'm really expecting anyone to use this behavior; I'm just describing how it would end up working, if it were implemented as I imagine it.)

• This is just one idea. If anyone has a different idea for how the query-strings would look, I'm all ears. (Any sort of query-string parsing is going to be easy to implement. The hard part is deciding what we want the query string to look like.)

• If the initial fragment, at time of page load, is (for example) Quotations or Quotations_2, then quotations groups are not initially hidden, even if they otherwise would be. (This is not exactly the same as your idea, but I think it's much easier to implement, since everything is currently implemented in terms of "groups" rather than "sections". It also works well with the fact that, when you edit a section named ====Translations====, the link in the edit history will be to #Translations, even if what you really edited was #Translations_2.)

—Ruakh_TALK 18:59, 27 November 2011 (UTC)

And that second major bullet point would override the first? Then it sounds great (to me FWIW).​—msh210℠ (talk) 19:55, 27 November 2011 (UTC)

O.K., sounds like a plan. I'll wait a day or two to see if anyone else wants to weigh in, before I go ahead with it. —Ruakh_TALK 00:08, 28 November 2011 (UTC)

 Done. Sorry for the long delay; for a while I was thinking it was trickier to do than I'd described above, but eventually I realized that no, I'd been mostly right to begin with. I made a few changes from the above, though: (1) I went with hidecats rather than hidegroups, because the code uses "categories" rather than "groups"; (2) the way I implemented it, it will be hidecats=translations,none that hides translations but nothing else.
Please let me know if you see any problems.
—Ruakh_TALK 22:23, 4 April 2012 (UTC)

Any suggestions? It is masculine, first declination, but the nominative is just Ābraham.

Maybe the first declension template could be changed so that it works the same as with second declension nouns ending in -r? —CodeCat 00:24, 27 November 2011 (UTC)

Thanks, that's a good suggestion. I have created {{la-decl-1st-AM}}. --Robert.Baruch 01:28, 27 November 2011 (UTC)

I don't think it's quite right, the genitive is 'abrahae' now. The stem includes the -am so it should be present in all forms. What's different is that the nominative and vocative singular has no ending rather than -a, just like ager has no ending rather than -us. —CodeCat 12:14, 27 November 2011 (UTC)

Ah, but the gentiive is Abrahae, at least based on what little research I've done. See, for example, here. A quick search on Google Books turns up lots of references to Abrahae and none for Abrahamae. I know, I was as totally surprised as you! --Robert.Baruch 18:19, 27 November 2011 (UTC)

I wonder if this is evidence that by that time, -am had come to be pronounced the same as -a... —CodeCat 00:04, 28 November 2011 (UTC)

I wonder if it would be possible to create empty language categories for all the languages.

I am asking this for two reasons:

1. even if a language has no entries, specifying family and script is still useful when the language is referred to in etymology sections and the like.
2. it makes it easier for new contributors if all the infrastructure is already in place.
3. it serves to quickly depopulate Special:Unusedtemplates

So, is it possible? -- Liliana • 13:21, 1 December 2011 (UTC)

It's possible but we would first need to make sure that all language templates have the right names, to avoid creating categories that we don't want. And it will also be hard to sort the two-letter codes from their three-letter equivalents. —CodeCat 16:50, 4 December 2011 (UTC)

The latter should not be a problem if the redundant three-letter codes are deleted. As for the former, I thought we went through the language codes a while ago to check for duplicate names and such? -- Liliana • 20:43, 5 December 2011 (UTC)

If we're just talking about one category for each language (just the top-level category, the analogue of Category:English language), then I don't think it's a big deal if some of the names are imperfect. We can figure out the right names if and when we actually start worrying about those languages. Moving one category does not take a lot of effort. :-)   —Ruakh_TALK 21:07, 5 December 2011 (UTC)

Yeah, that's just what I meant. -- Liliana • 13:19, 6 December 2011 (UTC)