MediaWiki talk:Gadget-HotCat.js/Archive03

Left-to-right mark

When a left-to-right mark is inserted before the closing ]], HotCat seems to ignore the category, even though the mark should be considered a whitespace and ignored completely, IMHO. (Example: Try to copy&paste [[Category:Tests‎]] (note the LRM between s and ]) to a page and then visiting the page with HotCat enabled.) --Mormegil (talk) 20:10, 26 November 2011 (UTC)

It appears that LRM and RLM are not whitespace characters: The JavaScript regular expresion "\s" doesn't match them,[1], and FileInfo also says they were punctuation characters: [2], [3]. Hmmm. It appears that the MediaWiki software strips U+200E, U+200F, U+202A to U+202E, and treats U+00A0 ( ), U+1680, U+180E, U+2000 to U+200A, U+2028, U+2029, U+202F, U+205F, and U+3000 as whitespace. So we'd probably need special case handling for U+1680, U+180E, U+200E, U+200F, U+202A to U+202F, and U+205F. (The others are covered by "\s"...). Not nice. Lupo 08:20, 28 November 2011 (UTC)

P.S.: note to self: above statement based on the code at Title::secureAndSplit. Lupo 08:25, 28 November 2011 (UTC)

You are obviously right, they are not whitespace (and should not be, it’s quite obvious when one thinks about it…), I got confused by MediaWiki’s handling of them. I guess an imitation of MediaWiki’s behavior is really what needs to be done… --Mormegil (talk) 12:42, 28 November 2011 (UTC)

Agree. But what's the right thing to do here?

1. User enters a category name with any of these: replace; also before getting suggestions.
2. For some reason, the MediaWiki software seems to not strip out the zero-width space (U+200B): it's neither stripped nor replaced by a normal blank.
3. Wikitext to be replaced on the page contains such markers: shall we keep LRM/RLM markers that are adjacent (and inside) to "[[" and "]]", or remove them?
4. What if the wikitext contains stripped characters inside the category name? We'd have to account for that possibility, which would considerably complicate things. Instead of just looking for e.g. "Category:" followed by "Foobar", we'd need to look for "Category:", followed by something like /[Ff][\x200E\x200F\x202A-\x202E]*o[\x200E\x200F\x202A-\x202E]*o[\x200E\x200F\x202A-\x202E]*b[\x200E\x200F\x202A-\x202E]*a[\x200E\x200F\x202A-\x202E]*r/. We'd also have to normalize the wikitext to also map all "strange spaces" to simple blanks before searching.
5. Do we have to account for stripped characters inside "Category" (or its localized equivalents), too?

That's all pretty hairy and frankly said, quite a bit of work. (Especially testing that it doesn't break anything!) Did you come across this case by chance, or does this occur frequently somewhere? Maybe on RTL wikis? If it's rare, I'd rather leave the code as it is, and make people either remove such spurious things manually or have them replace such categories manually. If it occurs frequently, it certainly would warrant proper handling in the code. If it occurs mainly on RTL wikis, I would need help with testing; I can't speak or read these languages, and I find even editing them highly confusing, so it's rather hard (viz: next to impossible) for me to tell whether or not HotCat would do the replacement right when I see a RTL diff. Lupo 14:37, 28 November 2011 (UTC)

Actually, I did not experience this myself at all. This was reported to me by another user asking for help. I agree the whole behavior of MediaWiki is ugly and complicated. I would say that generally, MediaWiki’s behavior in respect with some Unicode characters is… (or used to be, at least) imperfect. I tested it, and indeed, lrm is obviously completely ignored anywhere inside the brackets. A little bit unexpected.

To be honest, I do not care too much about this, as I did not come across this problem at all. Maybe it would be nice to know how much of raw lrm/rlm characters are there in the database? Or possibly create a piece of JS to remove them from the edit window prior to save? (Or an abuse filter to warn you/mark the edit?) I am not sure.

--Mormegil (talk) 10:51, 29 November 2011 (UTC)

Not sure that removing them altogether would be a good idea; I think they do have a raison d'être. Consider individual western words (such as proper names) in an otherwise RTL text, for instance the words "C++", "Java", or "Simula" at w:he:C++. They seem to use LRMs, and even ‎... However, I'm completely puzzled as to why User:ŠJů would have had LRMs at File:Masarykovo nábřeží, opravy, pracovní plavidlo.jpg. After all, Czech is a LTR language... If this is only an issue in a few isolated pages here at the Commons, then I'd really opt for not fixing this. There are other edge cases that HotCat doesn't handle properly; see /Archive02#Problem. (Though I might really one day fix the "more than one consecutive whitespace" thing. Forgot about that one. That at least shouldn't be too difficult...) Lupo 20:18, 29 November 2011 (UTC)

←It turned out that handling this in an "almost correct" way wasn't too difficult. HotCat now should handle correctly cases where Unicode BiDi override characters occur adjacent to and inside of the "[[" and "]]", or adjacent to the colon between the namespace name and the category name. It now also handles Unicode whitespaces the way the MediaWiki software does, including sequences of multiple whitespaces. The only thing missing now is replacing categories that have Unicode bidi override characters inside the wikitext of the category name or the category namespace name. It's unlikely that I'll ever implement that bit.

If you need the new functionality right now, refresh your browser's cache; otherwise, you'll get it when your browser automatically refreshes its cache sometime within the next 30 days. Lupo 16:44, 2 December 2011 (UTC)

Great. I’ll report that to the user, let’s see if it helps. Thanks. --Mormegil (talk) 11:19, 7 December 2011 (UTC)

Zero

On a slow connection, using the multi-cat mode, after the categories have been OKayed, clicking on Save multiple times (since the connection is slow, one is unsure as to whether it worked the first time and ends up clicking multiple times just to make sure it's working) results in Javascript alerts saying 0. For example: If I click Save 5 times, I get four 0 alerts before the edit page loads with the changed categories. The rest of it works fine, the categories are changed, the localized summary is present etc.

Not really a functionality problem, just a bit annoying :)

PS:Problem seen in Windows 7 home basic X64 using chrome 16.0.912.75 m. Haven't tried checking the "Prevent this page from opening any more alerts" option in the alert box.--Siddhartha Ghai (talk) 11:45, 10 January 2012 (UTC)

Form ID

Is it possible to add an ID to the form used to submit the changes? I would like to do some post-processing on the form without installing HotCat locally. Thanks.--Strainu (talk) 16:17, 19 January 2012 (UTC)

I could give it an ID, say "hotcatCommitForm", but how would you inject your post-processing? HotCat creates the form dynamically just before submitting, hence $('#hotcatCommitForm') won't find it. Doing $('body).delegate('#hotcatCommitForm', 'submit' function (evt) { /* Your code here */ }); won't work since submit events don't bubble up to the body. Hmmm. I would have to change HotCat to create the form up front, then you could do in a runWhenReady hook $('#hotcatCommitForm).submit(function (evt) { /* Your code here */ });. I'll take care of that later. Lupo 15:35, 20 January 2012 (UTC)

You could add another HotCat option - a callback to be executed when the form is submitted. On that note, you could add a whole bunch of callbacks to work with the form. However, creating the form upfront sounds like a simpler idea.--Strainu (talk) 16:31, 20 January 2012 (UTC)

 Done. See Help:Gadget-HotCat#Intercepting the page edit HotCat will make. (BTW, I was wrong about onsubmit not bubbling. My problem was that HotCat used form.submit(), and that doesn't trigger the onsubmit event.) Lupo 22:57, 20 January 2012 (UTC)

Thank you so much Lupo! In case you wanna see what I needed this for: [4]. I process any form to convert the old diacritics in the new ones. HotCat was one of the ways old diacritics could get in the page.--Strainu (talk) 15:11, 21 January 2012 (UTC)

Good to see it helped. BTW, you could use this in ro:MediaWiki:Diacritice.js inside the onsubmit handler. jQuery guarantees that it is set to the element defined by the selector.

//HotCat form
$('body').delegate( '#hotcatCommitForm', 'submit', function (evt) {
  sanitizePage(this);    
  return true;
});

Cheers, Lupo 16:22, 21 January 2012 (UTC)

Tool doesn't work when creating a category

I tried to use the tool to create category:Oiled birds but I had to create the category manually. Neither the simple category tool's "OK" button nor the multiple category's "save" button were functional. Teofilo (talk) 00:26, 23 January 2012 (UTC)

It's always been that way - it doesn't work on categories which don't exist yet. It would be useful if it did... Rd232 (talk) 01:01, 23 January 2012 (UTC)

No, that's a regression. It used to work on non-existing pages (except non-existing file description pages). Sorry about that. It's fixed now; should work again. Don't forget to reload your browser's cache. Lupo 06:57, 23 January 2012 (UTC)

Ha, well I've never seen it work :). Thanks. Rd232 (talk) 08:09, 23 January 2012 (UTC)

I will try it the next time I want to create a new category. Thanks. Teofilo (talk) 13:26, 23 January 2012 (UTC)

Default sort

Would it be possible to have HotCat able to edit the {{DEFAULTSORT:}} template (if it exists) on a page, as well as the categories? It's a pain to have to edit the page to alter or enter a default sort when you can so easy do the categories. Thanks for consideration, Inductiveload (talk) 13:12, 19 January 2012 (UTC)

I'll take a look at this. Lupo 23:24, 5 February 2012 (UTC)

Notes to self: seems HotCat would need to get all the possible aliases for the "defaultsort" magic word as it can be localized: German Wikipedia, Japanese Wikipedia. HotCat would need to know how to deal with {{SORTIERUNG:}}, too. And as of MW 1.19, there can be additional arguments after the sort key, too; see mw:Help:Magic words#Technical metadata. Hmmm. What if the sort key contains already "|"? Lupo 23:24, 5 February 2012 (UTC)

Hotcat and Category:Media needing category review

Commons:Village_pump#Hotcat_and_Category:Media_needing_category_review Bulwersator (talk) 14:07, 1 February 2012 (UTC)

And what does that have to do with HotCat? Lupo 20:21, 1 February 2012 (UTC)

Sorry, I forgot about essential part of my idea. I hope that I fixed my comment Bulwersator (talk) 21:17, 1 February 2012 (UTC)

And added additional explanation Bulwersator (talk) 21:34, 1 February 2012 (UTC)

On videos

HotCat doesn't seem to work on the following pages:

• File:ManlyFerryPullsIn.OGG
• File:Zadar Jadrolinija 1.ogg

Maybe it's just my config or the server being slow today. --  Docu  at 09:31, 5 February 2012 (UTC)

• http://commons.wikimedia.org/w/index.php?title=File:ManlyFerryPullsIn.OGG&action=history - it is working with my configuration Bulwersator (talk) 10:01, 5 February 2012 (UTC)

• I cannot reproduce this. Works fine for me. What browser/skin are you using? And what exactly doesn't work? Lupo 15:15, 5 February 2012 (UTC)

Request for it-wikipedia (Italian Wikipedia)

Can anyone modify that page MediaWiki:Gadget-HotCat.js/it in the right way that hotcat should remove automatically the it:template:categorizzare like does here in commons with the template:Uncategorized. Please. Thanks--Pierpao.lo (listening) 12:21, 1 March 2012 (UTC)

No, you should configure that at it:MediaWiki:Gadget-HotCat.js/local defaults. Lupo 12:31, 1 March 2012 (UTC)

uncat_regexp : /\{\{\s*([Uu]ncat(egori[sz]ed( image)?)?|[Cc]ategorizzare|[Nn]ocat|[Nn]eedscategory)[^}]*\}\}\s*(<\!--.*?--\>)?/g -- RE rillke questions? 12:37, 1 March 2012 (UTC)

Thanks a lot--Pierpao.lo (listening) 12:39, 1 March 2012 (UTC)

Not working?

Someone reported HotCat is not working. See bug 34857. Helder 17:54, 1 March 2012 (UTC)

I've replied there. Lupo 18:21, 1 March 2012 (UTC)

In short: the bug reporter uses some other "hotcats" (with "s"), not our HotCat here. Lupo 20:50, 1 March 2012 (UTC)

Complex plurals

Guys, why not to implement mw.language.convertPlural() in messages? Why not to select the suitable message with convertPlural and then substitute $1 with a number? Wizardist (talk) 11:20, 13 February 2012 (UTC)

Because HotCat is supposed to run also on any MediaWiki installation >= MW 1.15. It is being used (and maybe even hotlinked) from non-WMF installations. Older MediaWiki installations do not have mw.language.convertPlural. Besides, which messages are you talking about? Lupo 12:07, 13 February 2012 (UTC)

But couldn't it use the new features of recent versions of MediaWiki when available, and fallback to old behavior when necessary? Helder 15:35, 13 February 2012 (UTC)

It could, but it's overkill in this case. The message in question is apparently HotCat.messages.multi_change (see MediaWiki_talk:Gadget-HotCat.js/be-tarask#Cross-wiki gadget experience), which is always in plural. In a few other cases, HotCat does make use of new features and gracefully falls back if it isn't available, but if an old feature works, I see no reason whatsoever to program umpteen old-vs-new-mediawiki branches into HotCat. Lupo 16:17, 13 February 2012 (UTC)

←Wait... I think I see it now. If a language has more than one plural form (for instance a special form if the quantity is 2; c.f. dual), then using mw.language.convertPlural() makes sense, and that's indeed something HotCat can't deal with yet. So yeah, I guess Wizardist is right and I should add support for that. Sorry I didn't get it right away; my mother tongue doesn't have that grammatical form. Update is coming soon... Lupo 20:11, 13 February 2012 (UTC)

Ok, done. I see be-tarask has three different plural forms; one for last digit of quantity 1, one for last digit of quantity 2 to 4, and one for all other quantities. I don't know be-tarask at all, so I'll make something up: digit 1 shall be "categorA", digits 2 to 4 shall be "categorI", and anything else shall be "categorU". Then you'd define

  HotCat.messages.multi_change = ['$1 categorA', '$1 categorI', '$1 categorU'];

With your language set to be-tarask, that should then give you 1 categorA, 2/3/4 categorI, 5 categorU. See also Help:Gadget-HotCat#Localization. Lupo 21:22, 13 February 2012 (UTC)

I wanted to propose to change HotCat.messages.multi_change from string to array so all forms can be stored here and it will be up to convertPlural to decide which form to select (the script should just pass multi_change to convertPlural). I think my proposal is better because Slovenian, for instance, has 4 forms and the current approach isn't flexible enough. Wizardist (talk) 22:15, 13 February 2012 (UTC)

And that's exactly what I implemented. See above and also at Help:Gadget-HotCat#Localization. For Slovenian, just use an array with four elements. Lupo 22:44, 13 February 2012 (UTC)

Oh, I'm sorry, it was late so I by some means misunderstood the code :) Wizardist (talk) 15:31, 14 February 2012 (UTC)

No problem. Now you just need to tell me what the values for be-tarask shall be, so that we can complete the be-tarask localization. (And some stuff needs to be copied to be-x-old:MediaWiki:Gadget-HotCat.js/local_defaults; see MediaWiki_talk:Gadget-HotCat.js/be-tarask#Cross-wiki gadget experience. I can't do that, as I'm not an Admin there.) Lupo 20:07, 14 February 2012 (UTC)

  HotCat.messages.multi_change = ['$1 катэгорыя', '$1 катэгорыі', '$1 катэгорыяў'];

Wizardist (talk) 15:40, 16 February 2012 (UTC)

Thanks. I just noticed that this is also one of the definitions that must go into be-x-old:MediaWiki:Gadget-HotCat.js/local_defaults. I've updated the list at MediaWiki_talk:Gadget-HotCat.js/be-tarask#Cross-wiki gadget experience. Could you get a be-x-old Admin to copy these lines over? Lupo 22:43, 16 February 2012 (UTC)

OK, I've made a request in be-x-old:. Thank you very much :) Wizardist (talk) 11:31, 17 February 2012 (UTC)

Oh world! Did developers get rid of mw.language in 1.19? Wizardist (talk) 13:49, 14 March 2012 (UTC)

Shee-it. Well, unless I'm mistaken, the worst that happens is that you get the wrong plural, right? I think you could fix this by adding module "mediawiki.language" to the dependencies of HotCat in be-x-old:MediaWiki:Gadgets-definition: "HotCat[ResourceLoader|dependencies=mediawiki.language]|HotCat.js". Lupo 14:53, 14 March 2012 (UTC)

P.S.: if that indeed works, please report back here so that I can update the help page. Lupo 15:01, 14 March 2012 (UTC)

OK, I'll play with it in the evening. As I understand, MediaWiki moves towards full ResourceLoader dependance? Wizardist (talk) 15:49, 14 March 2012 (UTC)

As a temporary solution I've added mw.loader.using(['mediawiki.language']) to Common.js, because in Gadget-definition the proposed changed made HotCat not working at all. :( Wizardist (talk) 16:08, 14 March 2012 (UTC)

Yes, it does work. I just tried it a de.wikiversity.org. However, I needed to purge the MediaWiki:Gadgets-definition page. Without the purge, it didn't work indeed. After the purge, everything went fine. Lupo 21:06, 14 March 2012 (UTC)

I'll take it for my consideration. But I hope I will use it in other places too so it will be loaded every time. Wizardist (talk) 10:12, 15 March 2012 (UTC)

Documentation for gadget authors

We're trying to start a library for gadget authors to use. Please check it out and post any questions or comments there. -- ☠MarkAHershberger☢(talk)☣ 01:58, 9 March 2012 (UTC)

Access key for save button

I was thinking that it could be useful to have access key 's' for the save button when changing multiple categories. Like the save button below the edit box when editting pages has. /Ö 09:29, 18 March 2012 (UTC)

Unnecesary check

The check if (typeof (window.HotCat) == 'undefined') window.HotCat = HotCat; in line 192 is unnecesary since it's already inside an if block that checks that (line 32). --Locos epraix ~ Beastepraix 03:21, 22 March 2012 (UTC)

Yeah, could be cleaned up. Just "window.HotCat = {...}; is good enough. It's a harmless leftover from a quick fix for ResourceLoader compatibility. Lupo 08:12, 22 March 2012 (UTC)

Using namespace aliases

Currently HotCat has a single variable category_canonical for the summary and the addition to the page. MW 1.16+ converts this automatically to the localized namespace name. However, for hi-wp, I find this to be a bit long for the editsummary where anything over 4-5 categories gets cut off. We have a namespace alias श्र for the category namespace (full name श्रेणी). I'd like to have the ability to use the full namespace name in the category added to the page, but the alias for the editsummary. Could a variable (something like category_summary) be added for this which would default to category_canonical if not defined? Thanks.--Siddhartha Ghai (talk) 11:15, 8 April 2012 (UTC)

Multiple cat tool is OK now

Just to say that I have tried it again here and it is OK (follow up of this earlier bug) Teofilo (talk) 16:46, 19 April 2012 (UTC)

(+⁺) mode

Please, add another button to (+⁺) mode which could submit changes without a user interaction. See User talk:Waldir#HotCat. Incnis Mrsi (talk) 19:14, 21 April 2012 (UTC)

I won't do so. Waldir should take a look at Help:Gadget-HotCat#Intercepting the page edit HotCat will make; he is free to enable such functionality for himself if he doesn't want to cross-check the script's modifications and have a way to back out before they're submitted. Lupo 16:18, 18 May 2012 (UTC)

Order

Would it be possible to implement a function to add (+) a category in between existing categories. Like here you can only add the category at the end, not in between. This means that the categories are getting less unorganized. Maybe a better organization + the new option would be:
Categories (+⁺): (+) | Category 1 (−)(±)(↓)(↑) | (+) | Category 2 (−)(±)(↓)(↑) | (+)

Please respond,

-Kippenvlees1 (talk) 11:45, 18 May 2012 (UTC)

That would be a larger modification I don't have the time to do; the code handling the "(+)" currently assumes that this is always the last entry in the category list. Besides, the MediaWiki software sorts the display order of categories already; the order in which they appear in the wikitext source has no effect on the display order. Sorting them automatically in wikitext is not a good alternative either; Unicode sorting is complicated, and whatever the script did would have to work for all languages. Lupo 16:23, 18 May 2012 (UTC)

On the Dutch wikipedia categories aren't sorted automatically so that's a thing to implement on the Dutch wikipedia and not for HotCat. Thanks for your response. - Kippenvlees1 (talk) 15:55, 19 May 2012 (UTC)

Namespace aliases

Re: Using namespace aliases (User:Siddhartha Ghai, 2012-04-08): this is possible now in V2.19 by defining HotCat.messages.short_catchange = '[[श्र:$1]]';. Lupo 18:24, 21 May 2012 (UTC)

instructions

In Help:Gadget-HotCat#User_configuration the documentation appears to recommend using Special:Mypage/monobook.js - this doesn't appear to work (not the default) - shouldn't it be Special:Mypage/common.js..

I made some chages to the documentation as it is a little confusing to people not familiar with which skin is default. http://commons.wikimedia.org/w/index.php?title=Help%3AGadget-HotCat&diff=72116643&oldid=71438973

Please check this , thanks.Oranjblud (talk) 18:01, 4 June 2012 (UTC)

Thanks for doing this. The text was written before support for common.js existed (or at least when it was very new, don't remember exactly). I had intended to improve on this, but forgot. Lupo 05:51, 5 June 2012 (UTC)

Empty sortkey

I'm not sure, whether this edit shows a bug in HotCat or whether it's just a mistake done by the user. What seems to have happened is this:

The user removed one category and changed an other one using the gadget. For some reason, [[Kategorie:North Dakota nach Ort|]] was inserted (note the trailing pipe), which was expanded by MediaWiki on saving to [[Kategorie:North Dakota nach Ort|North Dakota nach Ort]], leading to a wrong sortkey. --Schnark (talk) 09:43, 25 August 2012 (UTC)

Commons:Administrators%27_noticeboard#HotCat_shortcuts

Hello, could you give your opinion on Commons:Administrators'_noticeboard#HotCat_shortcuts ? Thank you. --Foroa (talk) 08:34, 7 November 2012 (UTC)

HotCat shortcuts

It's been suggested to formalise some standard shortcuts for HotCat, to make categorisation with certain maintenance categories easier. This would mean creating certain redirect categories just for the purpose, so for example Category:tpp would redirect to Category:Template:painting possible. Please see Help:Gadget-HotCat/shortcuts and proposals at Help talk:Gadget-HotCat/shortcuts. PS background discussion is Commons:Administrators'_noticeboard#HotCat_shortcuts. Rd232 (talk) 12:40, 10 November 2012 (UTC)

I've seen the proposal. If I understood correctly, the point is not to create category redirects, but to list shortcuts (and replacements) and have HotCat handle them automatically as if they were redirects? Lupo 22:45, 10 November 2012 (UTC)

That's correct, it is to avoid even more category clashes and by preference based on a list per user as management of long global shortcut lists seems not realistic to me. --Foroa (talk) 19:11, 22 November 2012 (UTC)

I don't have the time to program something big and complicated, like parsing some wiki pages. So we'll have to keep this as simple as possible in terms of implementation effort. Also, you'd want to have that user-configurable.

The easiest would be to have the site-wide global default shortcuts in MediaWiki:Gadget-HotCat.js/local_defaults, as Javascript. Using Javascript for this is not complicated; it might look like this:

HotCat.shortcuts = {
  "bar" : "Category name that shall replace bar",
  "foo" : "Category name that shall replace foo",
  "foobar" : "Category name that shall replace foobar"
};

I think maintaining such a structure should be possible even for people with no Javascript knowledge.

Individual users could override and add to these entries in their own common.js files.

The devil is, as usual, in the details. Two thing off the top of my head:

• What to do if there is a category (or a redirect) with the same name as one of the shortcuts? Even if that may be unlikely, the script would need to handle it.
• What to do if the shortcut is a prefix of some category name. If there's the shortcut "Bar" with the replacement "Bavarian Alpine Resorts", and there is a category "Barbequeue", that mustn't become "Bavarian Alpine Resortsbequeue". So, prefix shortcuts are out. (That is, the following usage is not possible: shortcut "Ppl" : "People"; input "Ppl from Australia" cannot be replaced automatically by "People from Australia".)

Would a special replacement character be acceptable? I.e., mark shortcuts specially. Then we could allow such uses. The special marking character would need to be something normally not allowed in page titles, like "#". Then one could write "#ppl from Australia" and have that be replaced by "People from Australia". One could also write "#ppl from #ppl from #bar" to get "People from People from Bavarian Alpine Resorts". (Doesn't make much sense, but I hope you get the idea.) Using such a shortcut indicator character avoids both problems and simplifies handling in the script considerably. It boils down to a simple replacement, without having to worry about existing categories.

Shortcuts would be handled only for category names, not within sort keys. Input "#ppl|#bar" would be expanded to "People|#bar".

Additional syntax would be needed to have such variable substitution if no blank follows. For instance, If in addition to the "ppl" shortcut, you have "ppls" as a shortcut to "Privileged Policemen Living Solitarily", what does "#ppls" mean? Is it "Privileged Policemen Living Solitarily" or "Peoples"? For such cases, you'd need more syntax, for instance using [] (which also are not allowed in page titles). Then you can write "#[ppl]s" to get "Peoples", and "#ppls" or "#[ppls]" to get the privileged policemen.

Lupo 07:37, 23 November 2012 (UTC)

Great, that is about what I had in mind. Personally, I doubt very much that we need a global list upfront, only a user level one in the first place, as this avoids discussions and management, and unavoidably many conflicts. Moreover, it simplifies implementation as the possible collision with existing names is the responsibility of the user then. It would already allow for a quick first level implementation with or without special characters. A global list could be used only with special prefixes, such as #US for "United States" that might be replaceable in the middle of a cat name, but that seems less urgent. Lets first look at a local user list, a global list could be proposed as sample for the personal ones. --Foroa (talk) 08:20, 23 November 2012 (UTC)

Global and user list or only user lists doesn't really matter in terms of implementation effort. Ok then, I'll go for the replacement approach, using # and [], as outlined above. That'll cause the least surprises, and also the least possible conflicts with existing categories (namely none, since these characters cannot exist in category names). I'll ping you once I'll have a prototype ready. Lupo 09:38, 23 November 2012 (UTC)

"loadURI " is referred as "loadUR"

The function "loadURI " is mispelled in the call, please see the revision history where the mistake happened. http://commons.wikimedia.org/w/index.php?title=MediaWiki%3AGadget-HotCat.js&diff=85279306&oldid=83132026 anyone having edit permission please fix. Deepugn (talk) 08:36, 19 December 2012 (UTC)

• Fixed. odder (talk) 09:17, 19 December 2012 (UTC)

Great, Thank You! Deepugn (talk) 11:29, 19 December 2012 (UTC)

Maybe put redirects in italics

I think people would make more of an effort in categorization if redirects in HotCat suggestions were in italics. Otherwise people often put stuff in categories that are too general, or not really correct. HotCat automatically resolves the redirect to the correct category name upon saving the category addition. But many people will not notice this. If people knew immediately from viewing the italics in suggestions they might search for a more apt category.

Redirects make categorization easier. When people use search or HotCat they see redirects too, and thus are able to categorize even if their English comprehension is not at the level of a native speaker. But people need to know right away that they are using a redirect, and may want to look further for a better category, subcategory, etc..

See also Bugzilla:5346 - "make category redirects appear as italics or different colored links." It seems that category redirect links at the bottom of file pages will now be in italics. Read the comments at the bottom of the bug thread. It talks about Gerrit change #40781. I don't know how long it will take for that to show up here on the Commons though. See this discussion too: Commons:Administrators' noticeboard#Category redirect links will be in italics. --Timeshifter (talk) 12:18, 28 December 2012 (UTC)

That discussion has been moved here:

Commons:Requests for comment/Hard category redirects REDIRECT --Timeshifter (talk) 12:33, 2 January 2013 (UTC)

Internationalization

Hello there,
I recognized, that sometimes edit-comments (sample) with HotCat are not in english, but (for example) in french. I'm not sure if this depends on HotCat (maybe its a config-option), or if the editor has changed his version of HC (so this might be the wrong place here). However, I think it's really... bad, due to that Commons is an absolutely international project. I don't want to guess whats written there or to take always the translator. Any opinions?
(And sorry for my bad english..) Best regards, --#Reaper (talk) 14:17, 20 January 2013 (UTC)

Indeed. Somebody was over-eager with the configuration. Undone. Lupo 14:44, 21 January 2013 (UTC)

Thank you very much! Best regards, --#Reaper (talk) 15:39, 21 January 2013 (UTC)

Idiot-proof way to make HotCat always auto-save?

Help:Gadget-HotCat#Intercepting the page edit HotCat will make provides some example code to make HotCat do this, but it doesn't seem to work for me. I have tried flushing my browser's cache (Firefox 18.0.1, Win7). Am I missing something obvious? --moogsi (blah) 15:08, 5 February 2013 (UTC)

on for all accounts?

Is HotCat automatically turned on for all accounts (or all new accounts?) If so, I'll rewrite the help text I just added. Thanks, -- Phoebe (talk) 01:21, 28 February 2013 (UTC)

Module namespace

{{Editprotected}} Please, disable this gadget for new Module namespace. It should work as in Template namespace. I think it is enough adding a new line in disable function:

 ,disable            :

              || ns === 828 // Module

--V.Riullop (talk) 10:17, 23 March 2013 (UTC)

 Done. Jean-Fred (talk) 16:54, 24 March 2013 (UTC)

IIFE und geschützte Bereiche

Wäre bei

 ,disable            :
    function () { // Return true to disable HotCat. HotCat guarantees that the wg* globals exist here.

(in HotCat) ein IIFE nicht schöner? So wäre es gleich eine Variable und keine Funktion...

bei

wikitext.replace(/<\!--(\s|\S)*?--\>/g ...

fehlen noch <source> und <syntaxhighlight> und noch so manch andere Extension, denke ich. -- Rillke^(q?) 17:35, 7 May 2013 (UTC)

Was disable angeht: vielleicht. Aus Gründen der Rückwärtskompatibilität wäre es aber keine gute Idee, dieses public API nun zu ändern. Existierende Konfigurationen verwenden das evtl. so wie's jetzt ist. Und da HotCat auf vielen anderen Projekten verwendet wird, gilt es hier zu vermeiden, dass Änderungen in all diesen anderen Projekten nötig werden.

Was <source> etc. angeht: das stimmt wohl, gab aber in der Praxis noch nie Probleme. Wohl weil dort kaum je Kategorien vorkommen, und diese Tags auch kaum auf Hauptnamensraum-Seiten oder Kategorienseiten vorkommen. Könnte bei Bedarf erweitert werden.

Lupo 20:40, 7 May 2013 (UTC)

Not working

See also: COM:VP#Scripts broken.

HotCat doesn't seem to be working with anything other than the Default Skin. This to say Cologne Blue, Modern and MonoBook do not work. JIrate (talk) 19:34, 11 June 2013 (UTC)

Works fine for me in monobook & modern. Didn't test Cologne Blue. Also appears to be working fine for anybody else, otherwise there'd have been many more reports. So I suspect it's something on your computer. Did you try reloading your browser's script cache? Lupo 05:41, 12 June 2013 (UTC)

It only seems to be a problem on commons not on wikipedia? Yes I have purged multiple time. It not only happens on FF but I just tested IE and get the same. I tested it on a public computer yesterday with IE and got the same. I done all the purge several times. If the fault isn't universal then it is with the account, not the machine.Irate (talk) 11:38, 12 June 2013 (UTC)

Just checked with a second commons acc and got the same.Irate (talk) 11:44, 12 June 2013 (UTC)

Are there any JavaScript-related messages in the error console of Firefox? If so, what do they say? (I'm not interested in CSS-related messages. The error console can be opened using Command-Shift-J on a Mac, on a PC probably using Ctrl-Shift-J. Or via the "Tools→Web Developer" menu.) What other gadgets do you have enabled? Lupo 14:57, 12 June 2013 (UTC)

And could you please explain how exactly you "purged"? Lupo 15:01, 12 June 2013 (UTC)

Finally, is it not working on any page, or only on specific pages? And what exactly does "not work" mean? You don't get the "(+)"/"(–)" etc. links? Or do you get them, but they're non-functional? Or they appear and clicking "(+)" does open a category editor, but you don't get suggestions? Or can't save? Lupo 15:23, 12 June 2013 (UTC)

There are no JavaScript errors that I can see. I have done a shift reload, then a Ctrl-Shift-Del and selected to clear everything and finally gone to options->advanced and cleared the web content cache. By not working I mean there is no (+) etc. I did another test on a public machine with IE and it worked back home and neither IE or FF work. The on significant difference was that I'm using XP the public machine was Windows 7. So it is something about this machine, not the account.Irate (talk) 18:06, 12 June 2013 (UTC)

I just did a search for hotcar and found a message but when I try to upload it here I get a message saying my NetGear router had blocked it. I'be uploaded the message here https://docs.google.com/document/d/1GHJQdISZ_kD5JxUP_rb-M8lylLkqFSe3sWIlK2zoISk/edit?usp=sharing . Roter confirms it did the block but given no explanation and the firewall is off. Sorry for causing the trouble. Irate (talk) 18:35, 12 June 2013 (UTC)

Even puting the term "jquery*Msg" into this comment without the * freaks the router. Irate (talk) 19:56, 12 June 2013 (UTC)

The router msg claims it is tripped by trying to access "bits.esams.wikimedia.org" which when entered directly produces "Error 403 Requested target domain not allowed." from Varnish cache server. Can someone point me in the right direction? I'm going for a lie down. Irate (talk) 20:09, 12 June 2013 (UTC)

←So it seems clear that this is not a HotCat problem, and probably not even a script problem we could do anything about here. bits.esams.wikimedia.org are the cache servers in Amsterdam. Those are alive and well according to [5], and I also get a response when pinging that DNS name. I'm sorry, but I don't see how I could help you to sort out the troubles with your router. Lupo 21:12, 12 June 2013 (UTC)

That is the way it looks. Irate (talk) 21:48, 12 June 2013 (UTC)

Not work is someboy use "Nascidos em 19x0" in wiki-pt

Hi! In wiki-pt the hotcat do not work if somebody pot "Nascidos em 19x0" or "Mortos em 19x0" What happened there? Thaks in advanced! Vitor Mazuco^Msg 20:40, 22 June 2013 (UTC)

It's the configuration at w:pt:MediaWiki:Gadget-HotCat.js/local defaults: the line HotCat.blacklist = /^(Pessoas vivas|(Mortos|Nascidos) em [1-9][0-9]*( a\.C\.)?)$/; forbids these categories. Talk to w:pt:User:Opraco; he added this in January/February 2013: [6]. I have no idea why this blacklist entry was added, and whether it does what it should do. Lupo 09:12, 24 June 2013 (UTC)

Ok, thanks for your help. Vitor Mazuco^Msg 21:13, 24 June 2013 (UTC)

Edit page

When I use "change category" or "add category", after clicking "OK" button for few weeks I'm being transfered to straight edit page, earlier everything was made by the script. What's the problem? Opera 12.15, WinXP, (MonoBook and Vecotr) Mix321 15:44, 30 June 2013 (UTC)

Is that here at the Commons or at pl-Wiki? In multi-edit mode (i.e., after you clicked the (+⁺) link), you normally are shown the edit/diff screen. When you only change a single category (i.e., click (+), enter category, click "OK"), then the edit should be made right away. At the Polish Wikipedia, HotCat is configured to always show you the diff screen. I see that you override this at w:pl:User:Mix321/common.js. I also see that w:pl:User:Mix321/monobook.js looks suspicious: document.write should not be used anymore to load scripts, and it should be "window.hotcat_no_autocommit = false", not "var". Note that with this setting, you still get the diff screen for multi-edits. See Help:Gadget-HotCat for how to suppress the diff screen for multi-edits, too. Lupo 06:13, 1 July 2013 (UTC)

I did what you said and just from curiosity I've opened Chrome. On Chrome everything is okay, on Opera still shows edit page. Mix321 (talk) 21:12, 1 July 2013 (UTC)

Gadget-HotCat.js is not working for me

Hi there,

I'm a bit confused. Until some hours ago I was able to change categories in a way like shown at Help:Gadget-HotCat#User interface. Now I can't, so I went to the Help:Gadget-HotCat and tried to find (as emntioned at the top end of the Help:Gadget-HotCat page) the "Gadgets" tab of Special:Preferences. But to my surprise there is no Gadgets-tap within my user-interface.

What am I doing wrong? --AKor4711 (talk) 11:26, 14 July 2013 (UTC)

Down for me for the last hour too and no sign of the gadgets tab. No idea what is going on. -- Mattinbgn (talk) 12:22, 14 July 2013 (UTC)

There are issues with the servers. Gadget-CSS and the API are affected.

RoanKattouw: We've blocked some IPs sending lots of requests to the API and RoanKattouw: The API should be mostly up now, with reduced capacity, as I understand it may be relevant. -- Rillke^(q?) 12:56, 14 July 2013 (UTC)

HotCat is still not working. --ŠJů (talk) 14:03, 14 July 2013 (UTC)

Same problem here.M♦Zaplotnik ^{my contributions} 14:05, 14 July 2013 (UTC)

it's working again for me - both: the gadget itself and the Gadgets-tab within my user-interface ... thank you :-)

Autosaving problems

I have added

window.hotcat_no_autocommit = true;

in my common.js. But sometimes (not always) when adding a single category the change is still saved automatically. Is there anything I can do about this? /Ö 15:59, 1 August 2013 (UTC)

Can it be something about in which order different scripts are loaded? /Ö 14:45, 7 August 2013 (UTC)

Yes, now the jQuery's ready event happens before user's skin.js files are loaded. HotCat should check all of its setting when they're needed, not on ready. (Or you could try hooking to window's 'load' event instead.) Matma Rex (talk) 20:59, 8 August 2013 (UTC)

Or you add a dependency to user (and HotCat fails if the user breaks their js) or you store user options in user.options -- Rillke^(q?) 23:55, 8 August 2013 (UTC)

Hm, good point. Rillke, are you volunteering to implement the second solution? ;) (I've actually got a pretty sweet framework to handle configuration in this way, with UI on separate config page, on pl.wp with a few gadgets using it – see pl:Wikipedia:Narzędzia/gConfig and pl:MediaWiki:Gadget-gConfig.js / .css – and I'd be happy to help migrate it here if you want it, please poke me on IRC.)

If not, could somebody please wrap window.jQuery(document).ready(run) near the end of the script with mw.loader.using('user', function(){ … }) – this should be a good enough solution. Matma Rex (talk) 17:03, 9 August 2013 (UTC)

This does not work on old versions of MW (without RL) and bugzilla:32537 may be also involved and must be considered. -- Rillke^(q?) 14:51, 14 August 2013 (UTC)

Blergh. Well, then let's just hook to window.onload, maybe if mw && mw.loader && mw.loader.getState('user') !== 'ready'? Matma Rex (talk) 16:39, 14 August 2013 (UTC)

{{Editprotected}}

Okay, here's the final version. Please replace:

  if (window.jQuery) {
    window.jQuery(document).ready(run);
  } else {
    addOnloadHook (run);
  }

With:

  // Run as soon as possible. This varies depending on MediaWiki version;
  // window's 'load' event is always safe, but usually we can do better than that.
  if (window.jQuery) {
    // Post-ResourceLoader. Check for version to avoid MediaWiki bug 32537.
    var mwVersion = (window.mediaWiki && mediaWiki.config) ? mediaWiki.config.get('wgVersion') : window.wgVersion;
    if (parseFloat(mwVersion) > 1.20) {
      // We can safely trigger just after user configuration is loaded.
      mw.loader.using('user', function(){ jQuery(document).ready(run); });
    } else {
      // mw.loader.using('user', ...) could have unintended side-effects. Fall back to DOMContentLoaded.
      jQuery(document.body).on('DOMContentLoaded', run);
      // And in case we're loaded after DOMContentLoaded fires or in a browser that doesn't support it,
      // fall back to addOnloadHook (which is definitely supported on MW 1.20 and lower).
      // The run function itself protects against double initialization, so it's okay.
      addOnloadHook(run);
    }
  } else {
    // Pre-ResourceLoader. 
    addOnloadHook(run);
  }

Matma Rex (talk) 17:33, 14 August 2013 (UTC)

It made sense to me so I applied it. Thank you! −ebraminio^talk 10:33, 17 August 2013 (UTC)

Thanks to everyone who helped fixing this. Now this i working fine for me. /Ö 12:15, 17 August 2013 (UTC)

Bug: The tool removes categories on its own without informing about this

See here: MediaWiki talk:Gadget-HotCat.js/Archive01#Duplicate categories. Please remove this code again. Look at w:de:MediaWiki Diskussion:Gadget-HotCat.js#Bug fixen and w:de:WP:FZW#Bug bei HotCat. The tool sometimes removes pages out of categories without even informing the editor about this, just because it means they would be duplicate. Adding a new sortkey to the category removes the category, the category was gone and the category didn’t list the page anymore, so it had to be added manually again. I didn’t realize this at all while editing (there was no notice at all about this category removal). I saw it hours later by chance in my contributions list, because I had removed nothing, but the edit showed –… bytes instead of +… bytes, so I began checking this edit. It’s because of the include tags around the first category. Perhaps it’s the same with categories in comments, so please don’t let the tool remove any categories on its own, especially not without informing about the removal, so that the editor at least has a chance to realize and check this. Otherwise the tool isn’t useable anymore for me with this bug, then it’s easier to do such category changes manually and be sure that there’s no such removal of categories. And I don’t find a description anywhere on the help pages that categories are being removed by the tool of its own. I’m asking myself, what else the tool might do which also isn’t wanted? It is like the VisualEditor, you have to check each edit after saving, because there might be unwanted removals. --Typokorrektör (talk) 01:03, 18 August 2013 (UTC)

HotCat cannot deal with these includeonly/noinclude things, which is why it's disabled in the template namespace, where these occur very frequently. I have no time to change HotCat's behavior in any way. A possible work-around is to disable HotCat on user pages, too. Or to set auto_commit to false, so that you always get shown the diff screen, and then fix these rare cases by hand before submitting the change. Lupo 07:41, 19 August 2013 (UTC)

Hint: The discussion on w:de:WP:FZW is now on w:de:Wikipedia Diskussion:Helferlein/HotCat#Doppelte Kategorien und includeonly/htmlcomment.

This issue may not only occur on user pages but also especially on Wikipedia pages (but maybe also in other namespaces), so it would be no benefit to disable the tool in even more namespaces. The benefit would be bigger to disallow the tool to remove any double categories (as long as it doesn't differ between these different cases) than to disable the tool on a few namespaces. I even don't see any benefit in removing double categories. They don't disrupt anything. But if a category which seems to be double, is been removed, and it wasn't double, then it's a mistake. So it would be better, if the tool stops removing categories on its own. This is not, what the tool is supposed to do. And there even is no description anywhere that the tool does such things. --Typokorrektör (talk) 09:03, 19 August 2013 (UTC)

The diff screen would be another solution, but it should only be shown, when the tool finds double categories which it wants to remove, not in any other normal case. Then the editor can check this before saving the edit. Then there should be an invitation to check, it the double category can be removed with a description that it shouldn't be removed, if one of the two occurrences of this category is in includeonly or onlyinclude or noinclude tags or in a html comment. There should be buttons "confirm removing double category" and "save edit, but do not remove double category" and a third button "discontinue/cancel edit", or something like that. So the editor can also cancel the whole edit, if he doesn't know what to do with it. If this is to difficult, then the tool shouldn't remove any double categories, because they don't disturb anything. --Typokorrektör (talk) 09:03, 19 August 2013 (UTC)

Another idea: Perhaps the tool can check, if there's any occurrence of an "includeonly", "onlyinclude" or "noinclude" tag or a html comment on the whole page. If the tool finds a double category, it could only remove it, if it doesn't find any of these tags and no html comment on the whole page. If it finds such a tag or html comment anywhere on the page, it could leave the double category, where it is, and just remove it in case it finds no such tag or comment. Then there's no need to ask the editor. And the double categories which are not in such tags, but on the same page as such a tag, don't disturb anyone. So this would be better than now. --Typokorrektör (talk) 09:12, 19 August 2013 (UTC)

Does not work

The gadget simply does not work form me now (it is maybe 1 week), i tried even mulitple browsers and computers. Works OK on another wikis (enwiki, cswiki). --Jklamo (talk) 14:53, 29 August 2013 (UTC)

ditto. Meclee (talk) 17:50, 3 September 2013 (UTC)

Mysteriuous disappearance

Well useful gadget hace disappeared from my upload form.... why ? Daniel Villafruela (talk) 14:44, 6 September 2013 (UTC)

Not displaying arrow when ther is not subcat

Hi,

I'm a big user of Hotcat and here's a little idea : is it possible to not display the "(↓)" link when there is no subcategories ?

Cdlt, VIGNERON (talk) 10:41, 10 September 2013 (UTC)

BotMoveToCommons

Why does the gadget not remove this template? -- Bojan  Talk  04:07, 9 September 2013 (UTC)

Why would it supposed to be? --Leyo 09:13, 9 September 2013 (UTC)

It should not be removed. Template:BotMoveToCommons is mainly about making sure that moved files have correct author, source and license information. This usually means that the file page needs to be edited to at least change "author=Original uploader was User:X at wikipedia" to "author=User:X at wikipedia". When changing categories with Hot-cat I think most users don't do other changes to the file page (and changing a single category doesn't even show the edit window). It is better that the BotMove template is removed manually in the edit that fixes author information. /Ö 16:00, 15 September 2013 (UTC)

Copying HotCat to another wiki

Section Copying HotCat, step 4 "Important: set isCommonsVersion to false (it's near the top of the file, first field in the HotCat object)". This doesn't appear in MediaWiki:Gadget-HotCat.js. Please can this section get updated? Rob Kam (talk) 13:16, 17 October 2013 (UTC)

No longer needed; statement on the help page removed. Lupo 13:49, 18 October 2013 (UTC)

jQuery

At the end of section Copying HotCat it states that as HotCat uses jQuery(document).ready() to start itself and if this is not provided the startup of HotCat will need to be changed as appropriate. Please could some info be added on how to do this - that is where to check whether the wiki provides jQuery(document).ready() and if not what changes to make? Rob Kam (talk) 14:02, 17 October 2013 (UTC)

It means that you should use window.onload directly as outlined on [7]. Ruslik (talk) 18:59, 17 October 2013 (UTC)

It says on the help page that HotCat uses jQuery if available and the old addOnloadHook otherwise. Only if your MediaWiki installation provides neither you'll have to find some other way to start HotCat. Lupo 13:50, 18 October 2013 (UTC)

JQuery has shipped with MediaWiki since the 1.16 release. Since 1.17 all resources should be loaded through ResourceLoader. Please can this section be updated, as it is now it's confusing. Rob Kam (talk) 17:33, 18 October 2013 (UTC)

HotCat disappeared

This section is resolved and can be archived. If you disagree, replace this template with your comment. Rillke^(q?) 10:25, 1 November 2013 (UTC)

{{Editprotected}} Hello. I changed nothing and since about 1 month, my HotCat is not visible anymore. Though it is still active in my preferences, and Cat-a-lot as well. I still use personalised monobook. User:Coyau has changed his ToolbarMH.js. No problem when I import it. But when in my monobook.js I add one button to the toolbar, this new button works, but HotCat is not visible anymore, and in my console I get an error message: "mw.toolbar not defined" (strange, because the button is added and works). (I am not fluent in javascript). What happens ? Jack ma (talk) 08:42, 1 November 2013 (UTC)

I don't know what happens but this error message suggests that it is completely unrelated to HotCat. If you break your personal JavaScript file, HotCat may fail because it's waiting for your personal JavaScript file to be loaded for being able to respect your HotCat settings. -- Rillke^(q?) 10:25, 1 November 2013 (UTC)

mw.loader.using('user', function(){ jQuery(document).ready(run); }); is where it actually stops then. 'user' is a "module" representing your user-defined JavaScript files (both, your common.js and your skin.js). -- Rillke^(q?) 15:08, 1 November 2013 (UTC)

Might that be the reason for the numerous reports about HotCat not working anymore, which I never was able to reproduce? Perhaps it might be a good idea to start HotCat also if the user module fails to load. var startHotCat = function(){ jQuery(document).ready(run); }; mw.loader.using('user', startHotCat, startHotCat); Lupo 13:38, 2 November 2013 (UTC)

Yes, I think so, especially in regard to the upcoming JavaScrpipt deprecation-removals. -- Rillke^(q?) 14:28, 2 November 2013 (UTC)

 Done. Lupo 16:00, 2 November 2013 (UTC)

No more HotCat when creating a category

Yes. Any possibility to fix? --A.Savin 21:40, 4 November 2013 (UTC)

That was caused by the [now active JavaScript deprecation-removals. Should be fixed now. If you reload your browser's cache, HotCat at least should function again on non-existing category pages. Lupo 22:45, 4 November 2013 (UTC)

If these deprecation-removals cause other problems, with HotCat or other scripts, I have no time to fix them. Unless somebody else takes over, this will mean end-of-life for some scripts. Lupo 22:45, 4 November 2013 (UTC)

Thanks. --A.Savin 23:10, 4 November 2013 (UTC)

HotCat problem

This section is resolved and can be archived. If you disagree, replace this template with your comment. Rillke^(q?) 11:45, 8 November 2013 (UTC)

When i set commons interface in serbian language (српски / srpski) HotCat doesnt work, when i add category to i file it uses serbian word for Category (Категорија) instead of english word example --Milićević (talk) 20:35, 7 November 2013 (UTC)

This is because MediaWiki:Gadget-HotCat.js/sr does override the defaults. It should check whether mw.config.get('wgContentLanguage') is sr and only in this case, it should touch the edit summaries. -- Rillke^(q?) 21:33, 7 November 2013 (UTC)

Will this solve problem [8]? --Milićević (talk) 22:11, 7 November 2013 (UTC)

Replied there. -- Rillke^(q?) 11:45, 8 November 2013 (UTC)

Left another comment there. Lupo 16:20, 8 November 2013 (UTC)

RTL

I want propose this diff to fix this RTL bug. −ebraminio^talk 08:56, 14 November 2013 (UTC)

 Done with a little twist, since I discovered that the scroll state of the browser window is reported differently in RTL than in LTR, and even differently in different browsers. Change. Lupo 22:41, 17 November 2013 (UTC)

HotCat Problem

I am having a problem, I have HotCat enabled in my Gadgets section of preferences, but for some reason it isn't showing up on any of the pages Either the + / -. I am currently using the Vector Skin, with Google Chrome version 31.0.1650.57 m with OS being Windows 7. --Clarkcj12 (talk) 19:13, 26 November 2013 (UTC)

Never mind, it works on here. I meant this to go on the English Wikipedia as such it isn't working on there.. --Clarkcj12 (talk) 19:46, 26 November 2013 (UTC)

I've seen several reports about HotCat not working at the English Wikipedia for some people, but I have no idea what might be causing it. It works for me over there, and seems to work for other people, too. Just for some people, it doesn't. Reports about that started appearing after this change, but I have not been able to reproduce any problem, nor do I see what might be wrong there. Perhaps somebody else can take a fresh look? Lupo 08:29, 27 November 2013 (UTC)

Usual advice, empty your vector.js and/or commons.js, switch off other gadgets and see if it starts working again. If it does, re-enable gadgets one by one and after that, reinstate your .js files gradually, till it breaks again, to find the conflicting code. Akoopal (talk) 12:33, 27 November 2013 (UTC)

HotCat doesn't understand a category with diacritics?

HotCat refused to move some files, perhaps the problem is with diacritics in the original category name? Images whee to be moved from Category:Osiedle Tysiąclecia (Katowice) to Category:Church of St. Mary of Piekary Śląskie in Katowice. Done! All pages are processed. Return to page The following pages were skipped, because the old category could not be found: File:Katowice July 2013 008.JPG File:Katowice July 2013 010.JPG File:Katowice July 2013 007.JPG File:Katowice July 2013 009.JPG File:Katowice July 2013 013.JPG File:Katowice July 2013 011.JPG

Similarly, image File:Katowice July 2013 017.JPG couldn't be moved to Category:Rondo Sławika w Katowicach‎.

Interestingly, HotCat was able to move images into the Category:Osiedle Tysiąclecia (Katowice) category yesterday so unless something was changed in the last 24h or so, the problem is with the part of the script that tries to find a category that needs to be moved from. Please ping me when this is fixed so I can move the listed images (or just tell me it was done). Cheers, --Piotr Konieczny aka Prokonsul Piotrus ^Talk 14:33, 3 January 2014 (UTC)

That's not HotCat, but some other tool. Perhaps Cat-a-lot? Lupo 16:48, 3 January 2014 (UTC)

Doh, my wrong, sorry. --Piotr Konieczny aka Prokonsul Piotrus ^Talk 15:20, 4 January 2014 (UTC)

Feature request 1: visual indication of loading

I'm not sure if this is the right place to make feature requests, but I have one anyway: HotCat should have a visual indication of when it is still waiting for search results, and when it has already made a request and just didn't find anything. For example, suppose I wanted to categorize a photo of the street "Millergasse" in my hometown, which has no category yet: if I type "Millerg" quickly, I can't easily tell if the absence of any suggestions means that there is no category that starts with what I entered, or the connection is slow and HotCat is still waiting for results. An icon like while waiting for a server response would do the job. darkweasel94 20:44, 8 January 2014 (UTC)

Feature request 1: changing the order

Hi, I love this hot cat gadget! Thanks a lot for this  !!! I would appreciate if it is possible to add 2 small arrows (←) (→) to each category so that I can change the order of the categories easily. For example to move the category 20xx deaths at the end of each category list of pages about persons. Or it would be very helpfull to harmonize the order of categories of various pages of the same category. Just an idea, Thanks a lot. --W like wiki (talk) 00:32, 6 February 2014 (UTC)

Conflict with hidden categories when not shown

I think HotCat doesn't work when there are hidden categories in the page and user has selected in his preferences not to show hidden categories - I just checked in Catalan Wikiquote that enabling hidden categories in preferences fixes the problem.

If I'm right, the advice to enable hidden categories in preferences should be added to Help:Gadget-HotCat#How_to_enable.--Pere prlpz (talk) 11:24, 8 March 2014 (UTC)

allow to remove sort key when replacing cats

When replacing a category, the sort key is kept, even if it was deleted in the input field for the new category. This means taking the ± control will show me X|key, which I replace all by Y alone, but the effect will be that still there is [[Category:Y|key]] created in the file. Of course there is a workaround to add the new and delete the old category, but this needs an extra save. regards --Herzi Pinki (talk) 11:06, 10 March 2014 (UTC)

Did you read the the manual? Lupo 15:14, 10 March 2014 (UTC)

now I did, thanks for the RTFM hint. Who the hell ever reads a manual upfront? :-) It took me about one year to unveil the feature of navigating up and down the category tree (of course without consulting the manual). --Herzi Pinki (talk) 19:28, 10 March 2014 (UTC)

Popup box "HotCat edit hook"

For each of HotCat on Commons, I get a popup box with the message "HotCat edit hook", and only an OK button. It started a view weeks ago, and continues. What is the means to dismiss this? I don't get the same behaviour at other wikis, and they call the gadget here, so I am a little confused.  — billinghurst sDrewth 06:22, 21 March 2014 (UTC)

You added that yourself. I have no idea why you did that. (If you wanted to make HotCat auto-save always, the code to add is not that example code, but the real implementation shown at Help:Gadget-HotCat#auto-save-code.) Lupo 06:54, 21 March 2014 (UTC)

Thanks. Interesting on the timing whne the error message appeared, and no memory of why I did it, or what I was trying to resolve at the time.  — billinghurst sDrewth 00:39, 22 March 2014 (UTC)

Icons for browsing sub- and parent cats

seems that the icons in the Category line have changed from arrow up and arrow down to just question marks for browsing sub- and parent cats. The arrows have been much more intuitive, I think --Herzi Pinki (talk) 10:51, 29 April 2014 (UTC)

Edit summaries have also been broken, in the same manner. eg Instead of ±Category:Charmouth→Category:Stanton St Gabriel its now showing as ±Category:Charmouth?Category:Stanton St Gabriel--Nilfanion (talk) 10:59, 29 April 2014 (UTC)

Sorry. That was an unwanted change. Both fixed; to make sure you get the fixed version, clear your browser's cache and re-load. Happened when I automatically changed indentation in the code from spaces to tabs; the tool I used for that wasn't UTF-8-aware and replaced all those arrows by question marks. Lupo 11:09, 29 April 2014 (UTC)

chinese ime support

in currert version if we use ime for input,after we type the first work,it will be break. so i make a patch for chinese ime support

https://github.com/SLboat/Gadget-HotCat-Mediawiki/commit/1a143ad4c806a9991c89ddbe51e3a61f806c6b41

I really am no expert with IMEs, and that patch has too many open questions for me. From looking at e.g. [9], it appears that every keydown event during IME composition is received with keycode 229, but we do get the keyup events. I would have to check what HotCat normally gets when someone types "å" (ASCII 229). Hopefully something consistent over all browsers (I wish!). Furthermore, it appears there are also keyup events after that keydown 229, and even a keydown 229 before or after composition ends. So, how do we know for sure IME input is done? The approach taken in that patch appears flaky. There appear to be compositionstart and compositionend events, but I'm unsure about which browsers (and which versions) do support them. Or does this even depend on the IME used? Or is it enough to treat any pair (keydown=229, followed by keyup != 229) as IME input to be ignored and consider the pair keydown=229 followed by keyup=229 as "å"? Also, remains the question of how to detect the end of IME input, i.e., when the IME actually modifies our input field. Just after that we'd want to trigger getting a new suggestion list. Lupo 12:14, 29 April 2014 (UTC)

How IME input is handled seems to be heavily browser/OS/IME dependent. imehandler.js from Google Closure gives some hints at the complexities involved, and [10] lists some event sequences in some scenarios. Looks like for a cross-browser, cross-OS, cross-IME compatible handling of IME input, one needs to handle compositionstart, compositionend, keydown with keycode 229, possibly also textInput and compositionupdate, and then account for various quirks. Also, not using an IME myself, I can only guess that the desired behavior would be to suppress getting suggestion lists while IME composition is going on (i.e., between compositionstart and compositionend). Or should one also get suggestions at compositionupdate? (Might not cleanly possible on older browsers that don't have this event.) Lupo 15:14, 29 April 2014 (UTC)

And what happens when the text field on which the IME was active loses/re-gains focus? Does that cancel and undo the input? This is a can of worms... Lupo 15:56, 29 April 2014 (UTC)

Tried using some IMEs.

• Firefox 28 works well with the traditional Chinese Pinyin IME on OS X 10.7.5. I also didn't notice any problems with FF3.6.27 on Windows XP using the default IMEs for PRC and Taiwan Chinese from Microsoft.
• Safari has problems. Safari 6.1.3 (7537.75.14) on OS X does start the IME, but then the ACSII input appears in the input box, a suggestion list based on whatever character it is (in my case 'N') is shown, and the IME disappears again, making composition impossible. Safari 4 (530.17) on Win XP does present a suggestion list from a search for a blank when composition starts, no suggestion list updates during composition, and not after the composition has ended either. That clearly needs some work.
• Didn't test Chrome or IE since I don't have them. Didn't get my old IE6 to run at all, may have a chance later to try out a Win7/IE8 combo.

So from these preliminary tests, it looks as this needs indeed some work. If someone else wants to test HotCat with IMEs with Chrome or IE, please do so. report here what IME you used, which browser and OS, and describe the symptoms as clearly as possible. If there are suggestions displayed or updated: when (start, end , or during a composition?), and what's the content?

Fixing this may take some time, mainly because of having to test so many combinations of browser/IME/OS. Lupo 10:25, 30 April 2014 (UTC)

Ok, so I don't understand more than half of what Lupo said above. And I don't understand what the patch does (or is intended to do). Nevertheless, I gave it a try. Here's what I've tried:

System Environment:

Test page: w:hi:सदस्य:Siddhartha_Ghai/sandbox18

IME: Google Input Tools for hindi

Browser: Google Chrome Version 34.0.1847.131 m

OS: Win7 X64

Steps:

Input a

What Happens:

In the IME menu अ appears, the a in the input box becomes an A (case changes). At this point the IME menu is still visible, but the original input shown in the IME is still a.

The XHR ([11][12]) is sent, and when it completes, the suggestions menu pops up with the first suggestion selected. But the selection is grey and the input box still has a blue outline (it's still the focus element???)

Also, once the suggestions appear, undesirably, the IME menu has disappeared. (This means that the IME output is lost.)

Now consider the following:

Steps:

Input ag

What Happens:

In the IME menu अग appears, the text in the input box becomes Ag (again, case change). At this point the IME menu is still visible, but the original input shown in the IME is still ag.

The XHR ([13][14]) is sent. But since there are no categories starting from ag on hindi wikipedia, no suggestions menu shows up.

Since no suggestions show up, the IME menu stays intact. (Hence the IME output is not lost.)

Point to note: Whenever another character is input into the IME, the text in the input box momentarily shows the first char in lowercase before going back to uppercase. Also, if the IME menu is open, simply clicking the left or the right arrow key also causes this momentary change. The up and down arrow keys do not cause this since they're used for choosing between the IME output suggestions.

I haven't had a good look at the key/composition events yet. I'll post something about those when I have something informative.

Note1: The best way of tracking key events I've found yet is this article

Note2: I'll be going on a two-month wikibreak in a day or two, so I may not be able to find something about the events before the break (I'll try though).

Best of luck in figuring this out :) --Siddhartha Ghai (talk) 13:43, 30 April 2014 (UTC)

Thanks. That seems to be the same problem as in Safari (unsurprisingly, as it uses webkit, just like Chrome). Basically HotCat must not try to get suggestions or do anything with the inputbox while an IME composition is going on. Only once a character is composed, it should do this. Not too hard to fix (bar browser quirks, especially on older browsers), but will take quite some testing. I'll install the Google input tools on my ancient Win XP box. Lupo 15:08, 30 April 2014 (UTC)

@Siddhartha Ghai: if you're not yet on your wikibreak and have a moment, @anybody: there is now a version of HotCat that plays nicely with IMEs. I tested it with

• OS X 10.7.5 & 10.9.2: Firefox 28, Safari 6.1.3 (7537.75.14), Safari 7.0.3 (9537.75.14), with the OS X built-in Pinyin Simplified Chinese IME.
• Win XP: Firefox 3.6.27, Safari 4 (530.17), with the Microsoft Pinyin Chinese (PRC) IME and with Google input tools Hindi.
• Win 7: Firefox 28 & 29, Chrome 34.0.1847.131 m, IE 8; also with MS Chinese (PRC) IME (Classic input scheme) & Google input tools Hindi.

Now, absent from this list are IE9 and IE10 since I don't have those, and have no machine where I could install them. (The Win7 machine I used for testing isn't mine; I cannot/should not update IE there.) Also, I have no Linux box to test on.

It'd be great if somebody could test IE10 and/or IE9. To do so, disable the HotCat gadget and instead importScript User:Lupo/c2.js in your /common.js; then re-load. If anybody wants to test at hi-wiki, go to hi:User talk:Lupo, disable the gadget in your prefs there, import the development version User:Lupo/c2.js (or the copy at hi:User:Lupo/vector.js) in your /common.js there, and re-load. Then start using HotCat with an IME. Expected behavior is:

• With input set to an IME, the IME should become active as soon as you start typing a category name. Different IMEs have different UIs, though.
• While you're in the IME, no suggestions should pop up or be updated, and there should be no autocompletion. Typing up/down arrow keys should not disrupt the IME.
• Once you're done composing in the IME, HotCat should fetch a suggestion list and possibly do autocompletion.

On Windows, using the Microsoft Chinese (PRC) Simplified Pinyin IME (Classic input scheme), typing "da4" should give "大". It'll still be underlined, signifying you're still in the IME. Type a space: the underline should vanish, and here at the commons you should (currently) get four suggestions. At no point should HotCat start showing suggestions for "Da" or change the category input field, and the IME should remain active until you typed the space. If you enter "ko1" (or "ko", left arrow, then select the appropriate one by typing the corresponding number), you should get "口". Then type a space to leave the IME. There is only one category for this prefix at the Commons, Category:口, so HotCat should not show a suggestion list, but it should still show the icon.

For testing at hi-wiki, I used Google input tools on Windows. Inputs "a" ("अ") or "f" ("फ", or "फ़") should result in HotCat displaying suggestion lists.

In all cases, it should be possible to input several characters successively. Try "ag" in Hindi, or "da4" "ko1" in Chinese. (Probably doesn't make sense, but that's not the point.)

Once you're done testing, remove the importScript of the development version from your /common.js, re-enable the gadget, and re-load. Otherwise you'd keep using the development version instead of the stable gadget. I don't guarantee that my development version works at all times; it may break when I'm in the process of changing something, so it should be used only for such tests.

If you see any problems, please report them here. (Also if everything seems fine!) I'd really like to have at least a test report on IE10 before letting this go live. Lupo 10:01, 1 May 2014 (UTC)

Tested at hi.wp on Google Chrome Version 34.0.1847.131 m and IE 11 on Win7 X64. Seems fine. Autocompletion works in IE 11 but not chrome.--Siddhartha Ghai (talk) 10:38, 1 May 2014 (UTC)

Thanks a lot! I had completely missed that IE is already at 11... Lupo 10:47, 1 May 2014 (UTC)

 Done Fixed the remaining autocomplete issue and went live. Lupo 05:50, 2 May 2014 (UTC)

Unicode Normalization

It seems HotCat itself doesn't check for unicode normalization. For example, in this edit, I added a category named फ़िल्म. The IME I use (Google Input Tools) input into the category box the character U+095E instead of the character combination U+092B and U+093C.

So even after XHR requests to [15] and [16] were completed successfully, I didn't get any options in the dropdown, the image remained the cross (i.e it didn't change to a tick), and when I clicked ok, HotCat showed the category name as a redlink.

And when the page saved and reloaded, the normalization was done and the correct category had been inserted.

So HotCat should've detected that the category with the properly normalized name existed, shown a tick, a bluelink instead of a redlink.

Note that I didn't use the multi-editing mode.

Best Regards.--Siddhartha Ghai (talk) 15:37, 26 April 2014 (UTC)

That's ugly. It appears your IME opts for NFC, while the MediaWiki software uses NFD. (Correction: it appears your IME uses un-normalized Unicode, while MediaWiki uses NFC. Lupo 12:28, 28 April 2014 (UTC)) Making the suggestion lists work for this case is easy; but autocompletion won't work, and getting the "exists" icon to display correctly will need an additional server call. Autocomplete won't work because it's active only if the content of the input field is a prefix of the first suggestion received. With your example, the content of the input field is "\u095e\u093f\u0932\u094d\u092e", but the first suggestion is "\u092b\u093c\u093f\u0932\u094d\u092e", so autocompletion will not be done. And for the same reason, the icon will not show up correctly, as that also compares the input field against the first suggestion. So to determine whether there is a category corresponding to whatever is in the input field, the gadget would need to query for that page exactly and just look at the page id returned without considering titles at all (-1 meaning "doesn't exist"). Too bad that JavaScript has (not yet) a built-in unicode normalization. (EMCA script 6 will, I think, have String.prototype.normalize(). But that's the future.) I'll see what I can do. Lupo 13:48, 27 April 2014 (UTC)

I did make a change to account for Unicode normalization differences. Please test at hi-wiki and report back whether the issue is fixed. Suggestion list and "exists"-icon display should be working; autocompletion might not work if the content of the input field is normalized differently from what the MediaWiki software does. Lupo 14:42, 27 April 2014 (UTC)

Thanks for the speedy response. Unfortunately though, the issue doesn't seem to be fixed. Still no suggestions, incorrect "exists"-icon, and a redlink. Here's the diff.

Note though that the autocompletion feature doesn't work well with this particular IME (and I'm not really bothered much with that), probably because of the way the IME works. The text in the input box is originally the latin alphabet, with a dropdown menu near the input box showing options for the phonetic transliteration into devanagari. It is only when the spacebar is pressed that the devanagari text is actually inserted into the input box. So until the spacebar is pressed, HotCat basically gives suggestions according to the latin text, not the devanagari text. Also, if one pauses long enough for the suggestions to load, the IME dropdown vanishes and the text in the HotCat input box becomes the default latin text. The only way to work around this problem is to either type fast enough that the XHRs don't return before one completes typing the word; or once the problem has occured, to type again, or to copy-paste from somewhere. I haven't mentioned this here before since I doubt there's anything HotCat can do about this (other than providing an option to disable autocompletion, which I'm guessing you already do). Anyways, if you do want to check this out, there's a "Try it online!" page at http://www.google.com/inputtools/try/ although it doesn't work exactly as the windows version. There are some videos on YouTube showing what it looks like in windows. You could check them out if you're interested in fixing the autocompletion too.

Best regards--Siddhartha Ghai (talk) 18:43, 27 April 2014 (UTC)

It's a caching problem. I couldn't get it to work with my usual browser over at hi-wiki either; as it already had the previous version of HotCat cached. Interestingly, the normal cache clearing didn't help. However, when I opened hi:User talk:Lupo in some other browser with which I had never visited hi-wiki, it worked right out of the box: it did get suggestions when I pasted the "\u095e\u093f\u0932\u094d\u092e" version of फ़िल्म into the edit box. So, try again after some 24h, or with some browser you normally don't use. Lupo 19:41, 27 April 2014 (UTC)

Now it should work, if you clear your browser's cache while being over at hi-wiki. I had to purge the script here in order to get it to be reloaded over at hi-wiki because of the "&smaxage=21600&maxage=86400" in hi:MediaWiki:Gadget-HotCat.js. After purging, the new version got loaded, and I did get suggestions when pasting the "\u095e\u093f\u0932\u094d\u092e" version of फ़िल्म into the edit box. Lupo 20:36, 27 April 2014 (UTC)

Just noticed: besides autocompletion, redirect resolution also won't work for these cases. For both of these operations, HotCat needs to compare strings, which gets messy without normalization. I'm not going to include unorm in HotCat, and it doesn't appear to be available in the sitewide JS (jQuery, or the mediaWiki stuff). So, for the time being and until there are browsers that do bring the ECMAscript 6 String.prototype.normalize(), these two features won't work in HotCat if there are normalization differences between the input and MediaWiki. BTW, Unicode in JavaScript appears to be "fun". Lupo 07:25, 28 April 2014 (UTC)

Ok, so does the "&smaxage=21600&maxage=86400" need to be removed? It was added by User:Krinkle for some reason (no idea why).

So the icon, suggestions, and link color appear to be fixed. Thanks for the info on redirect resolution. We'll keep an eye out in the tracking categories.

Thanks for fixing this. Best regards--Siddhartha Ghai (talk) 09:34, 28 April 2014 (UTC)

No, just leave the "&smaxage=21600&maxage=86400" in. It just means that you'll get fixes from the Commons only after a couple of hours. maxage is a client cache directive, it instructs your browser to keep the page in its cache for at most a day (so, once per day your browser will actually go ask the WMF servers for a new version of the script); smaxage is a directive for the server-side squids telling them to fetch a new version if the cached one is older than 6 hours. If you clear your browser cache 6 hours after a change and then request the script, you should get the newest version. Lupo 10:26, 28 April 2014 (UTC)

I dug a little deeper, and I think maybe you've stumbled upon a bug in the Unicode normalization as done by either the MediaWiki software or by the Google input tools. It turns out that U+095E is a special character that is, if I understood the relevant Unicode specifications correctly, excluded from composition. It's one of a grand total of 1120 special Unicode characters excluded from composition; they're all listed at [17] and specified at [18].

I cannot tell whether the bug would be in the Google input tools (should it generate "\u092b\u093c" instead of "\u095e" in the first place?) or in MediaWiki (should it not decompose "\u095e" into "\u092b\u093c"?). One of the two appears to get it wrong. Based on the mention in [19] that "\u095e" is a "canonically decomposable characters that are generally not the preferred form for particular scripts", I guess Google has it wrong. (At least if they wanted to produce NFC. Of course, one can also argue that both are correct: MediaWiki using NFC with the non-composed form, and Google producing un-normalized Unicode. Then we're back to the problem of JavaScript not having any support for doing Unicode normalization.)

Lupo 12:20, 28 April 2014 (UTC)

I don't know what normalization form the IME uses (if any). I have, however, sent an email to their feedback email address, giving some information on the issue, requesting a setting for choosing the normalization type the IME uses, and including a permalink to this discussion (just before this edit), and links to the gadget documentation and js source. Thanks for the help :) --Siddhartha Ghai (talk) 16:01, 28 April 2014 (UTC)

Cool. It would certainly be helpful if the Google tool produced NFC normalized Unicode. As I understand it, that's what's most often used on the web. I'm still looking if I can get autocompletion and redirect resolution get to work without having to normalize in JS. I have a few ideas about that... Lupo 16:59, 28 April 2014 (UTC)

@Siddhartha Ghai: Now even autocompletion and redirect resolution should work. The point is that the server does actually return for both kinds of suggestion queries the NFC normalized version of the search key. If HotCat then detects a difference in the search key passed in and gotten back, it knows that the input in the field is not NFC, and since it just got the NFC version from the server, it can try to update the input field accordingly. That will result most of the time in the input field being correctly NFC normalized, and thus the string comparisons in autocompletion and redirect resolution (against NFC strings obtained from the server) will actually work.

As before, to test that at hi-wiki, wait 6 hours from now, then clear your browser's cache and re-load a page a hi-wiki. I tested this myself over there and didn't see any problems (otherwise I wouldn't have dared to update the script here). But it's still possible that you see something I missed. Lupo 10:37, 29 April 2014 (UTC)

BTW, Siddhartha, since you mentioned some problems with the suggestions and your IME, could you also take alook at the section #chinese ime support? Lupo 15:20, 29 April 2014 (UTC)

OK, so the autocompletion and redirect resolution are both now working (test diff). Thanks :)

I'll have a look at #chinese ime support now.--Siddhartha Ghai (talk) 12:21, 30 April 2014 (UTC)

 Done I still think Google input tools should produce NFC normalized Unicode, but HotCat now works also with non-normalized input. Lupo 05:52, 2 May 2014 (UTC)

Does not work

HotCat, turned on by default, does not work for me. I do not get any fields at all near the category section. What am I missing? --David Hedlund (talk) 20:15, 10 May 2014 (UTC)

Do you have JavaScript enabled? Do other gadgets work for you – for example, do you have an "Uploads" link between "Contributions" and "Log out"? darkweasel94 20:20, 10 May 2014 (UTC)

It works now, why is it turned on by default at commons.wikimedia.org but not at wikimedia.org? This is confusing and should be mentioned to someone who made decisions about it. --David Hedlund (talk) 20:39, 10 May 2014 (UTC)

Individual projects make their own decisions about which gadgets should be enabled by default. The English Wikipedia tried it once, but then decided against having it enabled by default. Lupo 21:11, 10 May 2014 (UTC)

Double save?

I'm puzzled by the sudden requirement of saving HotCat changes in the editor window. Previously it was sufficient to click the OK button in the category bar and your changes would be saved. As of today though, I'm getting the full editor window for anything I'm editing via HotCat. Has there been some change I'm unaware of? De728631 (talk) 20:23, 10 June 2014 (UTC)

Server-side change. They newly require one parameter more. Should be fixed now. Reload your browser's cache, and it should save again right away. Lupo 21:23, 10 June 2014 (UTC)

P.S.: the glitch was caused by gerrit:134047. Evidently, we didn't get the follow-up change gerrit:137506. Lupo 21:36, 10 June 2014 (UTC)

It's working again. Thanks for the info and the quick fix. De728631 (talk) 21:57, 10 June 2014 (UTC)

Hassle with double space

Since for quite a while now, if you type in another space after or before an existing space in a cat name, the text cursor is automatically moved to the end of the entry. This is a serious PITA for me and really musses up my workflow as most of my work on Commons is with HotCat and most of the time I copy-paste certain things, then modify. When (and it's often) I get thrown to the end I must first delete whatever I typed, then return where I was, then make sure I'm not going to double-space again, then repeat whatever I was doing. IIRC, previously any double spaces were automatically removed as part of the saving procedure. Please restore that, or at the very least, provide a user preference to toggle between the two. --Pitke (talk) 15:25, 19 June 2014 (UTC)

I see what you mean. I'll have to check why this is so. I'll take a look as soon as I have some time. Lupo 16:14, 19 June 2014 (UTC)

Thanks! --Pitke (talk) 18:56, 19 June 2014 (UTC)

 Done Should be fixed. If you reload your browser's cache, behavior with such double spaces should be OK again. Lupo 21:24, 19 June 2014 (UTC)

Works for me too. Thanks a lot for the quick fix! --Pitke (talk) 22:38, 19 June 2014 (UTC)

{{Check categories}} removal does not work

I've been trying to remove {{Check categories}} from File:Schützenkompanie.JPG using HotCat, and I get this error message:

Unable to remove "Check categories" with the API

redirect-appendonly

You have attempted to edit using the "redirect"-following mode, which must be used in conjuction with section=new, prependtext, or appendtext.

HotCat didn't remove the template, and I didn't remove it manually either so that you can reproduce it. darkweasel94 09:27, 22 June 2014 (UTC)

I don't understand this. HotCat has nothing to do with {{Check categories}}. It's not clear to me what you did. Lupo 12:10, 22 June 2014 (UTC)

Oh, maybe that's MediaWiki:Gadget-Hotcatcheck.js. If so, please contact User:Rillke. Lupo 12:13, 22 June 2014 (UTC)

Ah thanks, I didn't know this was a separate gadget. I will copy my report to that gadget's talk page. darkweasel94 12:49, 22 June 2014 (UTC)

Perhaps it's worth considering to disable this hacky MediaWiki:Gadget-Hotcatcheck.js to reduce maintenance efforts. Nicht funktionierender Kram ist schlimmer als gar nichts. -- Rillke^(q?) 17:17, 22 June 2014 (UTC)

Working on edit window

HotCat on french Wikipedia works on edit window. Could you can make such? --Arystanbek (talk) 12:33, 5 July 2014 (UTC)

I can't, as I do not have time for serious development here these days. I only do bugfixes and maintenance of HotCat, but I don't implement new functionality. Besides, the French Wikipedia uses a completely different script, not this one here. I would also be worried about inadvertently breaking some editor out there (built-in, WikiEd, Visual Editor, and whatnot). This script here is used on many projects, so adding this functionality would need to be done with great care to ensure it works right everywhere. I don't have the time for that. Lupo 14:23, 5 July 2014 (UTC)

HotCat is not working when adding a toolbar component to common.js - Wikisource

HotCat gets disabled when I enable an "mw.toolbar.addButton" code. When I disable this code, HotCat again appears as it should. Please see the code at the end of my commom.js at: https://en.wikisource.org/wiki/User:Ineuw/common.js where the action is currently disabled. - I am using the legacy toolbar with the following common.css code: https://en.wikisource.org/wiki/User:Ineuw/common.css. Ineuw (talk) 17:02, 5 August 2014 (UTC)

@Ineuw: You can't use the function mw.toolbar.addButton before it is defined. Its definition is on module "mediawiki.action.edit", which is loaded when you are editing a page but not when you are reading it. You can confirm this in the console of your browser. When I copied your code to my personal JS page, these were the error messages I got:

• (on Firefox) and
• (on Google Chrome)

To fix you script, you need to load the module (but only when editing) and make sure your code is only executed after the module is executed. For this, you should use mw.loader.using.

Something like this should make the button and HotCat to work. Helder 19:12, 5 August 2014 (UTC)

Many thanks for your explanation and help.Ineuw (talk) 19:45, 5 August 2014 (UTC)

@Helder I copied your sample code - not wanting to make a mistake since I am not a javascript coder and everything works fine as it should. Just to clarify - the code relating to the advanced wiki editor is not being used. I went back to the old toolbar. --Ineuw (talk) 20:23, 5 August 2014 (UTC)

@Ineuw: I took the liberty of commenting out other three lines of code which would call the function you disabled. Helder 21:34, 5 August 2014 (UTC)

@Helder Thank you. It's perfect--Ineuw (talk) 22:36, 5 August 2014 (UTC)

overzealous removal of the "uncategorized" template

With this edit, a user using HotCat inadvertently removed the "uncategorized" template. The problem is that this template was not transcluded but intentionally shown in wikitext between "nowiki" tags. It would be great if HotCat would not remove occurrences of the "uncategorized" template call when it is contained within a "nowiki" element.

But this is just a very minor issue – let me take this opportunity to thank the makers of HotCat for this great, useful gadget! --UV (talk) 20:16, 7 August 2014 (UTC)

Korean Wikipedia Hotcat Problem

Hello. I'm Korean Wikipedia User Kang-cheol Lee(이강철)

Ko wiki Hotcat is inactive. Most of ko-wikipedian checked hotcat Box, but it's not active. Thanks to read it. --이강철 (talk) 13:28, 29 August 2014 (UTC)

I don't think I can do anything about this. When I load pages at the Korean Wikipedia, I get the error "Error: Unknown dependency: mediawiki" on the request https://bits.wikimedia.org/ko.wikipedia.org/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=monobook&version=20140828T190951Z . This happens with HotCat enabled or disabled; so it's got to come from somehwere else. That error should be fixed first. Lupo 15:15, 29 August 2014 (UTC)

hot cat mistakes {{See also}} as Category redirect

On Wikimedia Commons the hot-cat extention responses to {{See also}} and {{See also cat}} as if they are category redirects, making it impossible to ad a category that has these templates in them to a file using the extension. This happened to me when I tried adding the category "Gemeentelijke monumenten in Oisterwijk" and would constantly end up with "Rijksmonumenten in Oisterwijk". Vera ^(talk) 09:01, 30 August 2014 (UTC)

I cannot reproduce this behavior. Lupo 10:33, 30 August 2014 (UTC)

I'm using w:Opera (browser) mobile classic, version 12.10 on Android. - Vera ^(talk) 21:12, 31 August 2014 (UTC)

I can't help you with that; I don't have access to that. In any case this looks rather like a bug with that Opera or some other problem on your side. HotCat does redirect resolution only for categories that are either "hard" redirects (using #REDIRECT) or that themselves are directly in Category:Category redirects. None of the {{See also}} templates add this category, and Category:Gemeentelijke monumenten in Oisterwijk is also not a member of that Category:Category redirects. The only other possibility would be that HotCat recognized the category as a disambiguation category, but it does that only for categories that themselves are directly in Category:Disambiguation, which again is not the case here. I just looked over the corresponding code again, and it looks correct to me. Lupo 21:55, 31 August 2014 (UTC)

I can see only one possibility of this happening if there's a bug in that Opera. Does that Opera have a console where you can enter so e simple Javascript and see the output? If so, please enter typeof (window.sdfgsfh) == 'string' and tell me what that yields. Then for good measure let's try typeof window.sdfgsfh and then window.hasOwnProperty('sdfgsfh'). I would expect false, 'undefined', and false as the result. If your Opera yields true for the first, then that's the bug in Opera. If it then gives false for the last, I know how to fix the code so that it'll work also on that Opera. Lupo 22:18, 31 August 2014 (UTC)

On the Dutch Wikipedia it ads "alles" ("everything") to pages instead of the category you just typed out. - Vera ^(talk) 22:21, 31 August 2014 (UTC)

What? Sounds like that Opera is completely broken. Where would that come from? You see, if it did that for everybody, this page here would be overflowing with complaints. Since you're the only who seems to have that problem, I strongly suspect it's got to be something on your end. Lupo 22:24, 31 August 2014 (UTC)

Is this on by default now?

If yes, the can be activated in the "Gadgets" tab in the introductory part should probably be changed to disabled. Same for the section How to enable. Also, Template:Please link images should probably be updated. --El Grafo (talk) 15:07, 3 September 2014 (UTC)

Looks like it is on by default since July 10, 2013 as a result of this proposal. Yes, somebody should probably go through the help pages and adapt them as needed. Lupo 15:43, 3 September 2014 (UTC)

Automatic Esperanto x-system conversion doesn't work well with HotCat

On eowiki, in order to type the special characters ĉ ĝ ĥ ĵ ŝ ŭ, users can enter cx gx hx jx sx ux (the "x-system"), and when editing, all of these special characters are automatically displayed in the x-system. Someone who wants to enter a literal ux has to type uxx into the editing box (and so on, i.e. to get uxx you need to type uxxxx, etc.). HotCat doesn't seem to work with that, which just confused a user (Dima41) who accidentally broke two filenames. I was able to reproduce this behavior here. HotCat should leave these character sequences alone. I don't know how the conversion is implemented technically (KuboF might know a bit about it?), so I don't know what you need to change. darkweasel94 21:17, 17 October 2014 (UTC)

@Darkweasel94: I think that solving this bug should fix the problem. --KuboF (talk) 21:19, 22 October 2014 (UTC)

In any case HotCat isn't doing anything with these character sequences. Whatever made the conversion is unrelated to HotCat. HotCat just makes a regular page edit. The user would have had the same problem if he had added the category manually (unless he edited only the last section; HotCat opens the whole page for editing). Lupo 11:30, 24 October 2014 (UTC)

This is what HotCat does. This is what manual editing does. I suspect that HotCat is reading the original text as it is in the database (with proper special characters), then saving that back (after making changes), which makes the server attempt to convert all x-es to special characters. As I understand, if you edit a page on eowiki with the wikitext editor, all special characters in the database are converted to the x-system server-side, and if you save the page, they are converted back. I don't know what the API does though. The entire Esperanto conversion is a bit of a mess and it might not really be your responsibility to work around it, but it does cause problems and currently they are attributable to HotCat. darkweasel94 11:52, 24 October 2014 (UTC)

I see. The API gives text as it is in the database, i.e., one level of 'x'es removed. For a user who has this strange x-system enabled (apparently all? I see no way to say at eo-WP "enable/diasable x-system"...), HotCat would need to apply the transformation normally done on the server side in LanguageEo.iconv, because the servers will, when HotCat makes its edit (which is done by the user using HotCat; it's not a bot!), apply the inverse conversion. With your example of "uxx": stored in the database is "ux". For normal editing though the edit page, the server already gives back "uxx". You edit, send back the "uxx" to the server, which converts to "ux" and stores. With HotCat (or other JavaScripts, I suspect), things go wrong: the script requests the text via the API and gets "ux". The user has the x-system enabled. The script sends back "ux" through the edit form, and we end up with "ŭ".

Drat. Making the edit through the API won't help either, as that internally also goes through EditPage. And I don't see any way to request from the API "give me the page text, but as if it was destined for an edit form". So, what's up with bugzilla:60677? Is this x-system going to be disabled? If so, the problem will vanish. If not, I guess one solution would be to hook into the edit and apply the transformation (adding one level of 'x'es). That could be done in /local_defaults, which I cannot edit. Or in your personal /common.js, as I don't see HotCat listed at eo-WP as a gadget? Code would need to be something like:

(function () {
  var xReplacement = {
    'ĉ': 'cx', 'ĝ': 'gx', 'ĥ': 'hx', 'ĵ': 'jx', 'ŝ': 'sx', 'ŭ': 'ux',
    'Ĉ': 'Cx', 'Ĝ': 'Gx', 'Ĥ': 'Hx', 'Ĵ': 'Jx', 'Ŝ': 'Sx', 'Ŭ': 'Ux'
  };
  $('body').delegate('#hotcatCommitForm', 'submit', function () {
    this.wpTextbox1.value = this.wpTextbox1.value.replace(
      /([cghjsuĉĝĥĵŝŭ]x*)/ig, // See LanguageEo.php
      function (match) {
        var first = match.charCodeAt(0);
        var result = first <= 255 ? String.fromCharCode(first) : xReplacement[match.substr(0, 1)];
        return result + match.substr(1).replace(/x/ig, '$0x');
      }
    );
    return true;
  });
})();

And then don't forget to remove that code once that x-system magic is switched off! Warning: above code is untested. Lupo 22:40, 26 October 2014 (UTC)

HotCat is a gadget on eowiki. It's called "Varma Kato" there. Thanks for the fix, I'll look into it when I have time; where exactly are we supposed to add it if HotCat is located here? And yes, the x-system is enabled for everyone. darkweasel94 01:33, 27 October 2014 (UTC)

Oh, eo-WP copied it. Well, then they're on their own, but basically still at /local_defaults. Besides, that version is two years and several releases behind the current version here at the Commons. Lupo 16:14, 30 October 2014 (UTC)

New feature request: noinclude tags in Commons:Deletion requests/ subpages

DR could benefit of HotCat to document FoP cases or note undelete dates.

But as all the DR are embedded on one page, categories must there be embedded in <noinclude></noinclude> tags.

It would so be interesting if, when added a category to a Commons:Deletion requests/ page who doesn't have already a category, HotCat adds the <noinclude></noinclude> tags.

Implementation suggestion: I'm pretty sure we have or will have in the future other similar pages, so it could be interesting to create an array, instead to hardcode the Commons:Deletion requests/ check.

--Dereckson (talk) 13:56, 15 October 2014 (UTC)

Lupo: what do you think of the idea? --Dereckson (talk) 20:19, 6 November 2014 (UTC)

Could be done, but I don't know when I will have the time for this. And yes, the page name must not be hardcoded, if only because HotCat is used on many wikis. Maybe a regular expression. But I'd have to think first what might be a good way to do this at all. Lupo 22:40, 6 November 2014 (UTC)

Opacity problem

{{Edit protected}} Please add CSS background:white code to HTML select element, so text inside won't conflict with the rest of the page. --Rezonansowy (talk) 13:11, 27 October 2014 (UTC)

@Lupo: Could you fix this please? --Rezonansowy (talk) 10:10, 29 October 2014 (UTC)

What exactly is the problem? Can you show me what you're seeing, and where it happens? Lupo 16:15, 30 October 2014 (UTC)

I made a screen, just add a white background to the list of the suggested categories. --Rezonansowy (talk) 09:21, 31 October 2014 (UTC)

I cannot reproduce this. What browser and skin are you using? Lupo 10:24, 1 November 2014 (UTC)

I use Vector and Firefox, but it appears only with one computer, please just add it, so any userscript won't conflict with it. --Rezonansowy (talk) 15:25, 3 November 2014 (UTC)

I'm reluctant to add something that shouldn't be necessary in the first place. Does it also happen if you switch off all the JavaScript stuff in your /common.js (and CSS in /common.css), and other gadgets? Perhaps whatever userscript or gadget conflicts with it should be fixed instead. Lupo 20:46, 3 November 2014 (UTC)

Unfortunately, I disabled my common.js and all gadgets, but the problem is still persistent. I use FF 33 on Linux Mint. --Rezonansowy (talk) 19:28, 8 November 2014 (UTC)

Mmmh, Ok... A Linux-specific problem, then, I guess. Compare this old report about something else by a user using iceweasel. This is too stupid. Unfortunately, my FF33 produces strange things if I explicitly set the background of the select element to white: it omits the right and bottom borders, and doubles the left and top borders. So I'd rather not change anything in HotCat for this. I suggest you fix this on your end by including select { background-color: white !important; } in your /common.css. Lupo 12:53, 9 November 2014 (UTC)

Bug in resolving redirects

See this thread. The problem seems to be that HotCat tries to replace a category redirect by the first link to a category that appears on the redirect page. But: the first entry in the list of links returned by the API is not the first in oder of appearence but the first alphabetically. In this example (and some more), the redirect page contains another category link that alphabetically precedes the actual soft redirect link. A solution could be to disregard links to a category of which the redirect page is a member. — HHHIPPO 22:05, 13 November 2014 (UTC)

Ack. That would work for this case. As would changing that second link on Category:Youth organisations to point to some page explaining this, as opposed to yet another category. Yet another possibility would be to make HotCat ignore blacklisted categories as redirect resolution candidates, and then blacklist Category:Redirects from alternative spellings or even all categories starting with "[Rr]edirect" in /local_defaults. Lupo 23:11, 13 November 2014 (UTC)

Yes, they would all work. I'd usually prefer using an algorithm over trusting a blacklist or the styling of the redirect categorization templates, since they rely more on manual maintenance. With all those solutions, the problem is we can't be sure to cover all (present and future) instances. How about this as an extended version:

• Make a list of categories linked from the redirect page.
• Remove all those where the redirect page is a member.
• Remove all those starting with "[Rr]edirects".
• If the resulting list has exactly one entry, use that. Otherwise,
  • Put the redirect page in a tracking category, such as 'Non-machine-readable category redirects'.
  • Open the page the user is on in diff mode, the suggested change being to use the redirect category, but with an html comment explaining that this is a redirect that needs to be manually resolved.

Then one can monitor the tracking category to find and fix new problems, that is, to make the redirects machine-readable and to fix the pages where the user saved the suggestion without resolving the redirect. — HHHIPPO 09:31, 14 November 2014 (UTC)

Your third bullet is the blacklist, since I'm not going to hardcode "[Rr]edirect" into HotCat. That would certainly be wrong on many other projects.

As for the first two: while it's certainly doable, I don't like such implicit assumptions. Who says that for instance the French Wikipedia, or even the English Wikipedia in the future, categorizes spelling redirects in the correctly spelled category so that anyone visiting the category can see which alternate spellings are already considered? (Doesn't strike me as entirely illogical; might perhaps even be useful, who knows.) HotCat is used on many projects and even on non-WMF MediaWiki sites, so I like to avoid too many built-in and hard to change assumptions. Simply using the first category link is/was of course also such an assumption. I guess I was just lucky that it has worked so well for so long.

I'll have to think about the tracking category.

Lupo 19:15, 14 November 2014 (UTC)

All right, here's something that works pretty well. For soft-redirect and disambiguation categories:

1. Look at all category links, don't just take the first one.
2. Ignore links to blacklisted categories.
3. If we end up with one eligible category, resolve to that one.
4. If we end up with more than one eligible category: handle like a disambiguation, even if it's a soft redirect. (I.e., present the possible targets as suggestions to the user and let her choose.)
5. If we end up with no eligible categories as potential targets: something's wrong with that disambiguation or soft-redirect.
   1. If a tracking category is configured (new HotCat configuration), propose that category with the problematic redirect/disambig category name as key.
   2. If no tracking category is configured, just don't resolve the redirect (i.e., leave it alone).

Note that I cannot add the problematic category itself to the tracking category: The user is editing page P and wants to add category XYZ. Now if XYZ is such a problematic category, HotCat would need to edit XYZ to add the tracking category. I am not going to make HotCat edit other pages than the current one. So the next best thing is to propose adding the tracking category, say "HotCat redirect problems", with XYZ as key (i.e., add "HotCat redirect problems|XYZ") to page P.) To resolve the problem, one will have to change either the blacklist or category XYZ. To find the problem, visit the tracking category, then the history of the page P listed there (under X), find the edit there (or look in the source of P for the tracking category), find its key (XYZ), then visit Category:XYZ and check what's up.

This is a rather convoluted process for that tracking category, so I think maybe it's better to just not resolve the redirect if there are no eligible target categories and not do this tracking category stuff at all.

Lupo 16:21, 15 November 2014 (UTC)

That sounds pretty good to me, thanks for looking into this. I agree that tracking the current page would be an un-elegant solution, and editing another page without the user's consent as well, so it's probably best to not include tracking in HotCat. One could consider giving the job of checking category redirects for HotCat compatibility to a bot that's already patrolling those cats to empty them, but I don't know which one that'd be and it's also not that big an issue.

By don't resolve the redirect (i.e., leave it alone), do you mean to categorize the page in the redirected category, or to not categorize at all? I'm undecided what's better. — HHHIPPO 18:08, 15 November 2014 (UTC)

I mean to categorize it in the soft-redirect category. It's the best option. AFAIK, non-empty soft-redirect categories end up in Category:Wikipedia non-empty soft redirected categories anyway, where a human can pick them up and see what happened, or a bot can re-categorize them correctly. Lupo 19:21, 15 November 2014 (UTC)

Right. And there we more or less have our tracking category for free. — HHHIPPO 20:17, 15 November 2014 (UTC)

•  Done. May need clearing your browser's cache to see the change. Otherwise it'll propagate as MediaWiki sees fit. Lupo 22:27, 15 November 2014 (UTC)
•  Oppose Please stop again categorize to redirect categories. ↔ User: Perhelion (Commons: = crap?)  11:49, 11 December 2014 (UTC)

  !voting here in this manner will not do any good. I presume you came across some other mis-categorization? Care to elaborate what happened where? Lupo 12:04, 11 December 2014 (UTC)

  OK yes, I do often a bit shit with HotCat. So you mean HotCat has solved the problem already? Then sorry, I take a proposed name from HotCat only without test the dissolving of this name in another.Special:Diff/142253661 ↔ User: Perhelion (Commons: = crap?)  12:21, 11 December 2014 (UTC)

  I don't quite understand what the "problem" is. That diff doesn't tell me much. How did you arrive at Category:Black and white 19th century photographs? This doesn't exist; it's not linked to, and is not a redirect, and HotCat clearly indicates to me that it doesn't exist when I enter "Black and white 19th century photographs" in HotCat's edit box. HotCat has no way of figuring out that you meant Category:Black and white photographs in the 19th century. So where did HotCat propose "Black and white 19th century photographs"? (P.S.: if it's easier for you, we can also discuss this in German.) Lupo 12:40, 11 December 2014 (UTC)

  No, as I meant I'm sorry. HotCat proposed 20th century and not 19th but 19th exists too, but not with a redirect, so "I proposed manually" 19th. So I suggest anyway to block HotCat for red-links (non-existing)!? ↔ User: Perhelion (Commons: = crap?)  13:54, 11 December 2014 (UTC)

  I see. HotCat has always allowed adding non-existing categories. Some people have a workflow where they do that, and then create the missing category by clicking the resulting red link. I wouldn't change that behavior now... Lupo 14:29, 11 December 2014 (UTC)

  Aha, es scheint man ist verwöhnt von den Vorschlägen der Art von Google. Ehrlich gesagt benutze ich die Vorschläge von HotCat so gut wie nie, da ich sie (wie man sieht) für nutzlos halte und die normale Suche bis jetzt nicht ersetzen kann (alleine schon dass man die Buchstaben immer in der richtigen Reihenfolge eingeben muss erübrigt jede weitere Suche). Wie dieser “workflow” funktionieren soll erschließt sich mir jetzt auf Anhieb nicht. PS: Es sei denn du meinst wit workflow, man erstellt die Cat über HotCat was ich persönlich für völligen Blödsinn halte, eine Cat sollte immer schon exististieren bevor man sie stetzt. Fazit: hier würde ich Verbesserung anraten in einer Art Verlinkung (new tab) aber nicht Setzung der Kat! Ausserdem besteht hier erhebliche Gefahr dass redundante Kats erstellt werden wenn eine Suche direkt umgangen wird! ↔ User: Perhelion (Commons: = crap?)  14:45, 11 December 2014 (UTC)

  Kann ich teilweise nachvollziehen. Die Vorschläge basieren halt auf dem, was die Server so hergeben. Wie Du mit Google etwas findest ohne die Buchstabenreihenfolge einzuhalten ist mit allerdings unklar. Google liefert auch keine Treffer für "black" wenn ich da die Reihenfolge durcheinanderbringe und "bkalc" eingebe. (Zugegebenermassen kann Google besser mit einfachen Schreibfehlern umgehen als die MediaWiki-Software. Daran kann ich aber nichts ändern.) Dass man (noch) nicht existierende Kategorien einfügen kann, scheint aber bis anhin kein grosses Problem gewesen zu sein. Entweder korrigieren die meisten Leute, denen so etwas passiert, das dann gleich, oder legen die Kategorie an. (Übrigens, weshalb hast Du nicht auch Category:Black and white 19th century photographs als redirect angelegt, wo es doch Category:Black and white 20th century photographs schon gibt?) Lupo 17:48, 11 December 2014 (UTC)

  Ja niemand postuliert gerne seine eigenen Fehler trotzdem bleiben das völlig sinnlose Edits (meistens, ich würde gerne mal eine Umfrage machen wer sowas tatsächlich braucht!?!). Nunja ganz einfach, zwar würde das eine Konsistenz herstellen allerdings sehe ich hier persönlich konkret auch nicht mehr Bedarf als bisher war. ↔ User: Perhelion (Commons: = crap?)  18:39, 11 December 2014 (UTC)

Unicode characters

It seems that HotCat is adding special Unicode characters which are reported as errors by the Check Wikipedia project. Please have a look at the last two edits here. ToSter (talk) 19:29, 24 November 2014 (UTC)

HotCat doesn't, the user does. The user entered an LRM mark (U+200E). HotCat does not remove those. Compare en:Wikipedia talk:HotCat#Unicode control characters. I don't know why some people enter or copy-paste those, or where they come from in the first place. Lupo 06:28, 25 November 2014 (UTC)

Undo mistake?

I've done again shit, is there an easy option (function) to undo or repair an done operation (70 files)?? ↔ User: Perhelion (Commons: = crap?)  18:35, 11 December 2014 (UTC)

Not in HotCat. It always operates on one file only, and undoing a HotCat edit is just like undoing any other edit. MediaWiki talk:Gadget-Cat-a-lot.js might be useful for mass-recategorizations. Lupo 18:48, 11 December 2014 (UTC)

Ok thank you anyway, I need to distinguish this similar gadgets (I guess there are some very similar function in it). ↔ User: Perhelion (Commons: = crap?)  19:06, 11 December 2014 (UTC) Done

switching search to searchindex does not work

I tried to toggle the search engine to searchindex as described, but then the suggestion box does not suggest anything. Neither through the selection of 'searchindex' (or German Suchindex) in the HotCat UI, nor by setting it in my commons.js to

window.hotcat_suggestions = "searchindex";

Standard UI language is German. I tried to prefix my selection with 'Category:', but when entering the trailing colon, the prefix vanishes. So what I expected to be a workaround also did fail. I miss the case-insensitive variant (which was the default before) so much. --Herzi Pinki (talk) 21:16, 16 December 2014 (UTC)

Thank you for reporting this. Looks like the MediaWiki server return different results than they once did when that code was written. I wonder for how long this has been broken...

 Done Should be fixed. You might need to reload your browser's cache to get the fix. Lupo 23:26, 16 December 2014 (UTC)

Was broken by this change, which was merged into core on November 27, 2014. Don't know when that went live where. Lupo 23:42, 16 December 2014 (UTC)

This was part of MediaWiki 1.25/wmf11, which was rolled out on December 9, 2014. So this would have been broken since then. Lupo 09:10, 17 December 2014 (UTC)

Thanks for the prompt fix. better now --Herzi Pinki (talk) 23:56, 16 December 2014 (UTC)

Implementation to action=edit and UploadWizard

The Hot-Cat gadget is very brilliant - simple, intuitive, almost indispensable. That's why I feel lack of such a function in some interfaces where it doesn't work.

The interface "action=edit" doesn't enable to use this tool. I think, it should be not more difficult than in Special:Upload form where it works successfully. Now, creating a new page, the user is motivated to save an uncategorized page and categorize them subsequently using Hot-Cat.

A big problem is that UploadWizard has no similar function, although its set as the default upload interface. That causes that many users don't know the category tree and use categories only as keywords, and even experienced users are frustrated by this UploadWizard's imperfection (absence of common wiki edit tools is next one). The idea to return Special:Upload back as the default upload interface didn't succeed. Is there a hope to implement Hot-Cat's functions to UploadWizard in foreseeable future? --ŠJů (talk) 13:07, 30 December 2014 (UTC)

Enabling HotCat on edit pages is simply too much testing work. We have several different editors that people use: plain old style, then with some toolbar, then that with arbitrary scripts hooking into that toolbar, then WikiEd, then VisualEditor, and whatnot. Chances are that if HotCat is hooked into the plain edit form, it'll break arbitrarily when one of the other editors is used. It'd be up to the various editors' developers to integrate categorization functionality in their editors. I also won't do anything in HotCat for the UploadWizard: AFAIK, the wizard already does have similar functionality (on the "describe" page). Lupo 13:59, 30 December 2014 (UTC)

The "Describe" page of the UploadWizard enables only something like the "+" function - to insert the category name, with autocomplete function. However, that page has no function to go through the category tree down or up (↑ and ↓ functions). Category name can be used as "keywords" but the categorization system (structure) is not available for the uploader. --ŠJů (talk) 20:55, 30 December 2014 (UTC)

Errors in webconsole - deprecated

Tracked in Phabricator
Task T86142

Hi, I'm getting a lot of deprecation errors in webconsole, when visiting any page at MediaWiki.org (full paste from webconsole) since this week's update.

"Use of "wgVersion" is deprecated. Use mw.config instead."
"Use of "wgNamespaceNumber" is deprecated. Use mw.config instead."
"Use of "wgIsArticle" is deprecated. Use mw.config instead."
"Use of "wgAction" is deprecated. Use mw.config instead."
"Use of "skin" is deprecated. Use mw.config instead."
"Use of "wgTitle" is deprecated. Use mw.config instead."
"Use of "wgArticleId" is deprecated. Use mw.config instead."
"Use of "wgServer" is deprecated. Use mw.config instead."
"Use of "wgScriptPath" is deprecated. Use mw.config instead."
"Use of "wgPageName" is deprecated. Use mw.config instead."
"Use of "wgCurRevisionId" is deprecated. Use mw.config instead."
"Use of "wgNamespaceIds" is deprecated. Use mw.config instead."

That last one dozens of times.

I think that mw:Manual:Interface/JavaScript#mw.config explains what needs to be fixed, but I'm not sure.

(I asked in IRC, and a dev says that these things can mostly all be fixed by replacing, e.g.

wgTitle => mw.config.get( 'wgTitle' )

Hope that helps. Quiddity (WMF) (talk) 22:05, 8 January 2015 (UTC)

See mw:ResourceLoader/Default_modules#mediaWiki.config for exactly how to use mw.config in general. Mattflaschen (WMF) (talk) 22:09, 8 January 2015 (UTC)

Pfff. HotCat takes care of that. These are false positives. And your dev is wrong. In HotCat, you could simply replace those with mw.config, but first you have to make sure that on all sites using HotCat (including non-WMF sites that hotlink to here--don't know if there are any) /local_defaults replaces any usage of wg-Globals by mw.config. Otherwise things will break. I don't see the point behind that whole idea of deprecating the wg-Globals. Lupo 22:34, 8 January 2015 (UTC)

Is this using Object.prototype.__defineGetter__() to produce the deprecation warnings? --Dschwen (talk) 22:45, 8 January 2015 (UTC)

It makes use of Object.defineProperty and also throws? warnings when the property is set which HotCat allegedly does "will still force publishing the wg* globals in the window object". -- Rillke^(q?) 23:18, 8 January 2015 (UTC)

Please avoid polluting the global namespace from within HotCat. Exporting a public interface is great, but keep other variables to the local scope. Perhaps use the import feature of mw.config. It allows you to maintain a compact object with the relevant configuration variables. Maybe use something like this:

var config;
if (window.mw) {
    config = mw.config.get([
        'wgAction',
        'wgVersion',
        'skin'
        // ..
    ]);
} else {
    config = {
        wgAction: wgAction,
        // ...
    };
}

Or abstracted:

var config,
    configKeys = [
        'wgAction',
        'wgVersion',
        'skin'
        // ..
    ];
if (window.mw) {
    config = mw.config.get(configKeys);
} else {
    config = {};
    $.each(configKeys, function (i, key) { config[key] = window[key]; });
}

// Example usage:
if (config.wgAction !== 'edit') {
    // ..
}

Or a quick hack like this:

var config = window.mw ? mw.config.get() : window;

–Krinkle^talk 19:11, 9 January 2015 (UTC)

PS: Just for your information: I noticed HotCat makes use of an undocumented implementation detail. Namely that wgLegacyJavaScriptGlobals = true and new mw.Map(true) result in mw.config.get() returning === global. This is no longer the case as of mediawiki-core@24f84b08. –Krinkle^talk 19:20, 9 January 2015 (UTC)

I still don't see the point. This is just make-work for people.

Can you provide me a list with all WMF wikis that:

1. use this version of HotCat here (as opposed to some local copy), and that
2. use in their MediaWiki:Gadget-HotCat.js/local defaults the wgGlobals directly

Possibly that list is empty :-), but maybe not.

Once we have that list and have replaced all those uses, we can go about replacing the wgGlobals stuff here. I'll do that then in a backward-compatible way so that non-WMF wikis that might hotlink to here don't get broken. Lupo 14:03, 10 January 2015 (UTC)

I've asked shell users to run mwgrep to this purpose (the bug here is rather severe). Judging from [20], I think the content to search for would be simply:

1. "MediaWiki:Gadget-HotCat.js&action=raw" in ns8,
2. some combination of HotCat AND wg* in ns8, there aren't many containing both.

Right? --Nemo 20:52, 10 January 2015 (UTC)

More or less. I think the second point should be a check if the wiki has a page "MediaWiki:Gadget-HotCat.js/local_defaults" and that page contains wg\w+ not preceded by a single or double quote. Lupo 10:49, 11 January 2015 (UTC)

Be aware that some people move "action=raw" to other places in the URL, so it might not be after the title "MediaWiki:Gadget-HotCat.js". Helder 16:33, 12 January 2015 (UTC)

The new MediaWiki version has rolled out to Commons and the impact was worse than I thought. HotCat actually broke mw.config for the JavaScript execution in general due to in incorrectly thinking it runs an old MediaWiki version and replacing mw.config with an empty one map. I've disabled the gadget for the moment. –Krinkle^talk 20:06, 13 January 2015 (UTC)

Re-enabled after changing HotCat. If any /local_defaults anywhere breaks because of this, people at those wikis are on their own (replace s/\b(wg\w+)/mw.config.get('\1')/g ). Lupo 20:21, 13 January 2015 (UTC)

Filter out invisible LTR marks

I noticed that very often Hotcat users insert the invisible character U+200E (LTR mark) at the end of the category name, just before the closing double brackets. You can use this tool to actually see the invisible character. Some examples: [21] [22] [23] [24] These LTR marks come from cut-and-pasting a subcategory name from a category. Is it possible to filter out this invisible character every time a user insert it? Thanks in advance! -- Basilicofresco (msg) 12:38, 17 January 2015 (UTC)

See en:Wikipedia talk:HotCat#Unicode control characters. Lupo 12:44, 17 January 2015 (UTC)

There could be some use of these mark inside a text, but not inside the category markup since:

• the category markup does not create visible text
• these character are forbidden in category names.

Basilicofresco (msg) 13:21, 17 January 2015 (UTC)

Yes, they're not allowed in page titles, but they're allowed in wikitext. I don't know how RTL editors (Hebrew, Arab, Farsi, ...) work and what LTR/RTL marks they might use in wikitext to get the handling they want inside the editor when editing the wikitext. Which is why I'm wary of just removing these from the user's input. And I don't quite understand why people bother at all about these being in the wikitext. Do they hurt? Lupo 14:03, 17 January 2015 (UTC)

Well, sometimes they cause some problems and confusion. By the way the text entry boxes for the category name is not for wikitext or multilanguage descriptions: it is just for a category name. I'm not talking about removing LTR marks from wikitext, but just removing them from HotCat's text boxes (where they make no sense) and therefore from category markup (where they make no sense). -- Basilicofresco (msg) 08:27, 18 January 2015 (UTC)

Problem with 'special' characters?

Sorry if this is a known issue, but I've noticed sometimes that where an apostrophe or diacritic character occurs in a category name, at the bottom of a member page the cat is displayed with only a pipe separating it from the one following it in the list, with no (±) or (−) link next to it. In the case of the apostrophes I saw, they had even been ‘escaped’ as an HTML codepoint in the wikitext, with no effect. Any solution or workaround?—Odysseus1479 (talk) 07:56, 7 February 2015 (UTC)

Show me an example and I'll take a look. Note that categories that get transcluded from some template do not get the (±) or (−) links. Lupo 09:56, 7 February 2015 (UTC)

Thanks. Apostrophe: File:Princes and other statesmen; twenty portraits. Engraving by Wellcome V0006828.jpg, the two de' Medicis. E-acute: File:Mathematicians and astronomers; twenty portraits. Engraving Wellcome V0006817.jpg, René Descartes.—Odysseus1479 (talk) 20:50, 7 February 2015 (UTC)

I see. That's going to be quite some work. Note that the encoding as HTML entities is not necessary, Category:Lorenzo de' Medici (written in wikitext as [[Category:Lorenzo de' Medici]]) works just as well and lets HotCat handle it correctly. There's simply no reason whatsoever to write it as [[Category:Lorenzo de' Medici]]. The bot that uploaded this should be fixed, and should clean up after itself. I'm not sure it'd be worth investing time to make HotCat be able to deal with this. Lupo 11:52, 8 February 2015 (UTC)

Are you saying the glitch is caused by the HTML codes? —if so, I‘ll fix any I come across. Or just that they’re no help?—Odysseus1479 (talk) 19:00, 8 February 2015 (UTC)

Yes, the problem is caused by the HTML encoding. HotCat doesn't know how to deal with this; it sees one version with an apostrophe and cannot find it in the wikitext and thus refuses to do anything with it. I would have to rewrite a substantial part in HotCat related to finding categories in wikitext just to deal with this borderline case. And indeed these HTML entities are no help at all, and are completely superfluous. I don't know why Fae (or his bot) used them in the first place. Lupo 19:44, 8 February 2015 (UTC)

Just speculating, but they may have come from the format of the keywords on the source website. (They’re used in the description text as well.)—Odysseus1479 (talk) 20:01, 8 February 2015 (UTC)