Talk:UserTags

Translations
The script tries to translate itself automatically but it can't do so perfectly. To fully translate it, you will need to provide translations for the following messages: Note that the script does support languages that have male/female nouns (e.g. Amministratore [male] and Amministratrice [female] in Italian) so you can provide per-gender translations as well if needed. Please specify the language and list the messages in the same order as given above, if there are male/female variants then please separate them with slashes. Example: (Male, Female, Gender neutral/unknown)
 * 'Inactive'
 * 'Never Edited'
 * 'New Editor'
 * 'New Account'
 * 'Patroller'
 * 'Rollback'
 * 'Global Bot'
 * 'Amministratore' / 'Amministratrice' / 'amministratore/trice'

de

 * inactive: 'Inaktiv'
 * never edited: 'Keine Bearbeitungen'
 * new editor: 'Neuer Bearbeiter' / 'Neue Bearbeiterin' / 'Neuer Bearbeiter'
 * new account: 'Neuer Benutzer' / 'Neue Benutzerin' / 'Neuer Benutzer'
 * patroller: 'Kontrolleur' / 'Kontrolleurin' / 'Kontrolleur'
 * rollback: 'Zurücksetzer' / 'Zurücksetzerin' / 'Zurücksetzer'
 * global bot : 'globaler Bot'


 * Arkondi (talk) 07:09, September 26, 2012 (UTC)


 * Added. Thanks. Lunarity 07:25, September 26, 2012 (UTC)

pl

 * 'Inactive': 'Nieaktywny' / 'Nieaktywna' / 'Nieaktywny'
 * 'Never Edited': 'Nigdy nie edytował' / 'Nigdy nie edytowała' / 'Nigdy nie edytował' or short 'Brak edycji'
 * 'New Editor': 'Nowy edytor' / 'Nowa edytorka' / 'Nowy edytor'
 * 'New Account': 'Nowe konto'
 * 'Patroller': 'Patrol'
 * 'Rollback': 'Rollback'
 * 'Global Bot': 'Bot globalny'

  V u h    Dyskusja   E-mail   19:33, October 4, 2012 (UTC)
 * Added. It'll go live on the next code rollout (should be in an hour or two). Lunarity 03:30, October 5, 2012 (UTC)
 * Active Now. Thanks. Lunarity 04:01, October 5, 2012 (UTC)

Why are some tags overridden and others not?
I've noticed that the MediaWiki:User-whatever messages are sometimes overridden and sometimes not. The VSTF, Staff and ones of that ilk —the ones that basically most people shouldn't tinker with —are displaying whatever is the current state of the MediaWiki message. For example: tardis:User:Sarah Manley and tardis:User:Sulfur.

However, other messages like MediaWiki:User-identity-box-group-bureaucrat and MediaWiki:User-identity-box-group-sysop are being overriden by this script.

Is that intentional? It seems to me like it'd be more logical for either all MediaWiki messages to be overridden or none of them —unless I'm just not understanding an underlying theory at work here. — CzechOut 16:55, September 30, 2012 (UTC)


 * Those aren't being overridden per se, the mwGroups module fetches the core names of the groups from the server, it's using MediaWiki:group-sysop-member instead of MediaWiki:User-identity-box-group-sysop for those. The Staff/VSTF ones are actually not being touched at all, they're being left exactly as Oasis displayed them which is why they show User-identity-box-group messages. I suppose I can change it to prefer User-identity-box-group in all cases if you think it would make more sense to do that. Lunarity 17:34, September 30, 2012 (UTC)


 * Okay, I've altered the biases to prefer User-identity-... over group-...-member. Lunarity 18:49, September 30, 2012 (UTC)

You may want to change the place where the tags attach
I've noticed by looking at our users that have defined a real name that the tags seem to be attaching to. This is somewhat awkward on our wiki, because we don't accept that the h2 should be the Wikia default of. Some of our users, like tardis:User:Duncs Kinnear-Swift, have very long "real" names, so we use a  instead.

This makes the tags appear on a separate line after the h2 information, as is the case at tardis:user:Josiah Rowe.

It might be a thought to allow end-user definition over where the tags will be placed —a sort of "attachwhere" variable —because tardis would certainly put it inline after the h1, not the h2. — CzechOut 16:55, September 30, 2012 (UTC)


 * It's actually just appending them to the end of hgroup tag, i.e. after everything. I forgot about the real names thing, I'll have to look into it. Where does Wikia put them in that case? Lunarity 17:41, September 30, 2012 (UTC)


 * Okay, I am emulating Wikia's tagging correctly but it's not working for you. I'll add a parameter that let's you specify a CSS selector to choose what element to place the things after. Lunarity 17:47, September 30, 2012 (UTC)


 * I've added a selector parameter, . Just set it to   and it should place the tags in the right place for you (including the Staff/VSTF ones). By the way, what did you want to change the Staff/VSTF tags for earlier? Tardis Wiki already has customised messages for User-identity for those. If you want to make the tags into links or add hover tooltips, I could try doing that. I'm reluctant to allow the order to be controlled on them, but I could be convinced otherwise. Lunarity 18:49, September 30, 2012 (UTC)


 * I've relaxed the restrictions around Staff/VSTF/etc. tags now. You can make them into links and add hover text to them if you want. You still can't move them or change the text though (order and m/f/u are ignored). Lunarity 01:54, October 3, 2012 (UTC)

Preferences
My preferences module is finished. I need a real demo now. Tell me which of the UserTags settings should be user-configurable and I'll build it. My suggestion would be to add languages and technical skills (JS/CSS/templates) and give the users the option to grade themselves on a scale for every ability they advertise. Interested? If so, anything else I should add? -- peco e s 21:49, September 30, 2012 (UTC)


 * The module docs are here. The Preferences specific problem you'd have to figure out is that you need to be able to access the user's settings for some other arbitrary user (viewer is a different person from the setter), I'm not clear on if the preferences system actually supports accessing some other user's configuration data. There's also a problem that UserTags is a wiki script, not a user script which means it won't follow the user to the preferences wiki when they click the configure button [makes showing the UI hard]. The UserTags specific problem is that tags are inherently static, I'm not sure how you would implement grading except for creating a whole swarm of group/tag pairs, or constructing the tags programmatically as needed; neither is particularly appealing on the customisation or i18n fronts (since localising numbers is really ugly, some languages have 6 different types of plurals).


 * As far as my scripts go, DisplayClock is probably the best candidate for converting (it already supports live altering of the format string whilst it's running so a live preview customisation UI wouldn't be too hard to do). It's reasonably light but would work as a proof of concept. I'd also like to convert HideRail2, although that is on the back-burner until I ascertain the amount of damage that occurs on Wednesday. Lunarity 22:57, September 30, 2012 (UTC)


 * "The Preferences specific problem you'd have to figure out is that you need to be able to access the user's settings for some other arbitrary user (viewer is a different person from the setter), I'm not clear on if the preferences system actually supports accessing some other user's configuration data."
 * True. I would still have to add that. As long as I make those "foreign" settings read-only there should be not much of a problem though. I could make it so that the preferences of the user whose page is visited are loaded by default.


 * Programmatically constructing tags is a bit more complicated, yes, but ask yourselves this: Wouldn't it be cool to see at first sight what languages a user speaks? Or what skills he wants to offer to the community and at what level? You've built a cool library with UserTags. It's time to use it for some cool stuff now! :)


 * DisplayClock strikes me as a very bad candidate btw. I cannot see myself changing the positioning of the clock or the time formatting - at least not where DisplayClock is installed as a site script. If it's good enough for the rest of the wiki, it's good enough for me. I'd rather not build an interface I wouldn't use myself. -- peco e s 00:12, October 01, 2012 (UTC)


 * Constructing the tags themselves won't be hard, although it does prevent the user from customising them since any attempt to override the text will lose the numbers/whatever. That can be worked around by the module taking configuration options to control the text itself instead of relying on the normal core behaviour to take care of that. I find multilingual string processing is a pain but if you want to do it then UserTags will handle it fine, just make sure to set the male and female parameters if they are relevant to the active UI language. Lunarity 01:58, October 1, 2012 (UTC)

Interface design suggestion
We need to make a few design choices before we know how difficult the i18n might be...

Here's what I'd suggest for the tags:

En-4 CSS-3 and for the Script Preferences:



Actual HTML used:

Skills Do you have any technical skills you would like to make available to the community? (It's in your own interest not to advertise skills you don't have or don't want to share!)

peco e s 05:43, October 01, 2012 (UTC)


 * I looked around a little and a scale of 1 to 5 seems to be common for languages:


 * 1 basic - 2 intermediate - 3 advanced - 4 near native level - 5 native speaker


 * (I'm a 3.5 btw :) -- peco e s 13:11, October 01, 2012 (UTC)


 * Looks good to me, although it should be captioned as the Module name (Something like "Skills &mdash; UserTags" rather than just "UserTags" specifically since UserTags is an engine script rather than standalone and the Wiki will need to enable the relevant module in order for this to actually do something. I think alternating row colors would be a good idea as well, if possible, I find long strips of almost identical rows of data tend to wear on my eyes. These stats might also be useful to other scripts written by other people in the future so maybe it'd be better to store them under a fake addon name ("usersskills" or something) so that anyone can access them.


 * Do you intend to use those tag colors by default? That could be difficult given the large variety of color schemes across Wikia, plus the script isn't tooled for that, you'd have to do mw.util.addCSS manually, and watch out for the cascade order. Lunarity 14:37, October 1, 2012 (UTC)


 * Um. Let's leave graphic design choices aside for the moment. This is more of a conceptual sketch. I'll surely make a change or two... I will probably use the jQuery UI slider instead of radio buttons e.g.


 * I'll leave the CSS for the language and skill tags up to you. The only thing I wanted to suggest was the - syntax for the tags' contents.


 * Any addon can read any other addon's preferences. I don't plan on building in any security restrictions. At least not for the forseeable future. But, yeah, it might be a good idea to add a shared object that all addons can access without any knowledge of one another. I wouldn't want people to store godknowswhat in the shared section though. That creates a few policy problems. I have to mull that over a little... -- peco e s 15:02, October 01, 2012 (UTC)


 * "although it should be captioned as the Module name (Something like 'Skills — UserTags' rather than just 'UserTags' specifically since UserTags is an engine script rather than standalone and the Wiki will need to enable the relevant module in order for this to actually do something."
 * That's something I haven't thought about yet. I could either show all possible configurations for all scripts - regardless of whether the user has actually access to them - either through his own global.js or some wiki or other. Or: I could try to determine what addons the user actually has access to... -- peco e s 15:12, October 01, 2012 (UTC)

(Reset indent) That was what tripped me up with the /preferences.js only working on the Preferences Wiki. Wiki-wide scripts won't follow the user off the wiki but they are present if you stay on the wiki when changing settings. Going off the wiki makes that harder since you're going to have to create some sort of registry. Either every addon the user ever encounters is remembered somewhere (and they are definitely going to want a "never bother me about addon X" option, and a "delete memory" one); or you're going to have to get everyone to add their scripts to a central list page somewhere to pull from, but that could be overwhelming for the user to see every possible option for every script in existence everywhere.

IMHO, it makes more sense for the prefs page on the prefs wiki to configure global settings for scripts in the user's global.js and the /preferences.js sub-page should work on every wiki and set wiki settings for that wiki (or global settings in cases like this, as decided by the addon itself). [Or just have a mode switch link that refreshes the page with ?mode=global to switch between global and local without having to leave the wiki at all] Admittedly this is more complicated since you'd need to create a portable stylesheet (with the rail and article hiding stuff in it) that could load on any wiki and alter the isPrefsPage function to return a string ('global' for Preferences Wiki, 'local' for single-wiki sub-page, false for everything else). You've got the tabber creation logic in the core so you're already pulling the necessary logic around everywhere, right? You just need to load the tabber JS and whatever else when loading the UI page. Lunarity 16:19, October 1, 2012 (UTC)


 * So I would make a clean division between local and global settings then? If a global user-script has local settings, the user will have to hop from the global page at w:c:preferences to that particular wiki to make that change. And if a local user-script uses global preferences than the user would have to hop from that wiki's settings page to the global settings page. The clean separation will make the interface more intuitive, yes. But spreading the settings over two pages will cause different problems. Some users won't realize there's also the "other" page.


 * I could add not one but two links to the account navigation. That will make the duality a little more obvious right away. I could also add a notice in large letters to both pages (if needed) that says: "This addon also has global/local settings. Click here to go there".


 * That doesn't solve the problem of what extensions to show though. I still need to figure out how to determine which extensions the user and/or the wiki use. One possible solution would be to force every addon to register itself when it loads Preferences.js:


 * Come to think of it, I could combine that with a loader:

peco e s 18:52, October 01, 2012 (UTC)


 * Ah. I thought you already had that solved with the addon function, since every addon has to call that at some point, and if it calls it then it has configuration, which means it probably has a UI. You could just make the  function add a tab on demand although the tabber doesn't support that, it'd need to be modified.


 * You could display both sets of settings at the same time using two tabbers but I don't think that'd be very pleasant for the user or scripters. I do think dividing the settings cleanly is a good idea, leaving the global/local distinction entirely in the hands of each addon will probably result in massive amounts of unintuitive inconsistencies across each one. The addon can always just use global to alter its global settings on the local page if it really needs to.


 * For the preferences menu item, you probably don't want to add 2 items, just direct to the local wiki page and have a "To edit your global settings, click here" link in a slightly oversized font above the tabber, or as a fake tab at the end of the tabber if you can bind the event for it. Lunarity 19:41, October 1, 2012 (UTC)


 * The function above is meant to be copypasted into the code that uses Preferences.js. I've been through quite a few versions of how to load the preferences most efficiently and least inconveniently. This isn't perfect either, but not bad. Still, this is probably not the last version :)


 * The more I think about it, the more I like the physical and logical separation of local and global preferences. It sends me back to the drawing board big time, but it makes a lot of sense.


 * Speaking of the drawing board: You wanted to know how I'll make the preferences of other users available. How about a shared object? The shared object would exist in parallel to the local and the global object. Unlike the local and the global object it can be read by any user. And unlike the local and the global object it can be written to by any addon (that runs under the username). The shared object would be configured on the global page, but in a separate tab from the other addons. -- peco e s 20:56, October 01, 2012 (UTC)


 * * sigh* Wait. What about edit pollution? At preferences.wikia.com it doesn't matter if Special:EditCount and Special:WikiActivity are polluted by edits to User:Name/preferences.js but on pretty much any other wiki that could be a serious problem.
 * peco e s 21:20, October 01, 2012 (UTC)


 * Do you have a list of the design constraints and requirements somewhere? I usually make a list and do a rough UML-ish architectural sketch when I start. [Not that it always helps, UserTags was re-architected 3 times before I was satisfied, and has had an internal refactoring since I've published it :)] Lunarity 21:52, October 1, 2012 (UTC)


 * When you say "shared object", do you mean a function like "dev.preferences.shared(username)" [readonly] and "prefsObj.shared" [readwrite] which fetch the relevant subset of the global data from a different user and return a Map?


 * If you're going to split the shared stuff into a separate UI, who's going to be responsible for the form? If multiple addons use the same property, it isn't clear who should actually assemble the UI. The MediaWiki Gadgets project use a definition block for this sort of stuff where people just declare "I have property X which is a number between A and B and should be displayed as a slider using description message Y"  but this starts to walk into framework territory.


 * I'm not sure what part I'm suggesting is a do-over, it's mainly just a UI change rather than an architectural one; unless you're going to store the preferences data in multiple separate JS files on the prefs wiki, like, one JS file per wiki or such? Lunarity 21:43, October 1, 2012 (UTC)


 * "Speaking of the drawing board: You wanted to know how I'll make the preferences of other users available. How about a shared object?" - Pecoes


 * 1) Apologies for interjecting, since I've been partially but not carefully following this conversation, but why are we considering making preferences of user X available to user Y again (in any way, shape or form)? This seems like a very bad road to travel down in just about every way imaginable: privacy, intuitiveness and code complexity.


 * 2) Hindsight is 20/20, but you do realize this is the talk page for UserTags and most of this conversation has very little to do with UserTags right? (Just like the previous segment on Talk:UserBadges :P)


 * If you skip up to the initial part of the discussion before the image, the problem is that the Preferences framework can't support Pecoes' UserTags module idea in its current state. In order for a user to declare "I can do CSS at an Advanced level", every user needs to be able to open that user's user page and have UserTags pull their settings data in order to find out the value of "CSSSkillLevel" they set.
 * There isn't any privacy implication: this is a wiki, the data is stored on a public JavaScript page, anyone can just open the JS page for any user and read their settings data if they want to, the only thing being discussed is formalising that fact as a code interface. [This is not inherently desirable, no, but until MW1.20 is released with its Options API for storing this stuff on the server in the private area alongside the user's Special:Preferences config options, this is the best we can do]
 * The initial discussion was about using the preferences framework to create a UserTags module, it branched off when it became clear that the preferences system needs changes to accommodate it.
 * Lunarity 23:41, October 1, 2012 (UTC)

Interface part 2
(Reset indent) That's my cue to leave isn't it? :) No problem. The concept is clear enough to me to rewrite the code (again). Once the next version is finished I'll also write the documentation and we'll have a proper place for such discussions.   peco e s 00:22, October 02, 2012 (UTC)


 * Ah-- you don't have to leave. I was just curious about the decision making process behind preferences, as it went in a very different direction than I would have taken it (which is why this isn't my script). Thanks for clarifying. I still have more questions, but I'll wait for you to finish preferences first I suppose :)


 * If by "questions" you mean feature suggestions, we better discuss them now and here.
 * peco e s 01:00, October 02, 2012 (UTC)


 * Here are my main two concerns, although I'm not sure they're really "feature requests"


 * Suppose I have a script that uses only localStorage or cookies to save data. I want to use your preferences to help with 1) the UI for options my script uses and 2) as a way to store/get information globally. Underneath, does preferences support "localStorage + cross-domain messaging" as a mutually exclusive alternative to "put the preferences on a page w/ automated edit via MW API". For privacy purposes, I may have a script that I want to save settings... but I don't want other people to see them, and so localStorage really is the only acceptable option.
 * How exactly does a UI for options work? Different scripts will need different UIs. I might have a script that needs 3 dropdown boxes and 2 radio buttons for the user to select their settings, or another script that just needs 10 checkboxes. I can build such a UI with HTML, but how do tell preferences to honor it?


 * I can't think of a solution without a server-component that has any hope of guaranteeing full privacy. That localStorage/iframe/interwindow-messaging solution isn't any more private. It's more obscure, yes, but no more private. You do realize that localStorage is public to whatever else runs in the window, don't you? The Facebook JS accesses localStorage e.g. If there's one script I'd worry about, it would be that one.

I don't think the lack of full privacy is much of problem though. I cannot really imagine a scenario where an addon would try to store sensitive data like passwords or credit card numbers.


 * The preferences module doesn't interfere with your UI design in any way. It provides a method for inserting your HTML - whatever it may be - at the correct spot. And it provides an event that is triggered when the user clicks the "Save" button. You can use that event to evaluate your form and alter the preferences before the module saves them.

Oh, and one more thing: The module keeps a registry of scripts it should load when and if the preferences page is loaded. That way they can all be loaded very performantly in a single importArticles call. And you can keep the code that creates and evaluates the form completely separate from the code that uses the data.
 * peco e s 02:02, October 02, 2012 (UTC)


 * 2) Okay, works for me. 1) It is a bit more private. User X's user scripts don't run in User Y's browser. I do not have any access to what's in your localStorage from a user script level. I suppose I *could* write a site-wide script on a wiki where I'm an admin, and then wait for you to come onto that wiki to expose your localStorage contents. (Since it's running in your browser, the information would then need to be transmitted to me - and you might detect this hijacking attempt.) Contrast this with preferences just being saved in a JS page via automated edit - you have absolutely no clue who or how many people are viewing that wiki page.

(Unrelated): When processing another user's preferences data, make sure you do not execute it. That's a major security flaw if a user modifies their JS settings file by hand to include attack code and then some other unsuspecting user tries to cross-load that user's settings and triggers the attack code in their browser. You'll have to manually extract the data using JSON.parse instead, the surrounding frame code that makes it executable in the first place is consistent so this shouldn't be difficult to do. Lunarity 02:23, October 2, 2012 (UTC)


 * Good point! That'll be easy though. The current plan is to store the shared data separately from the global and the local data. So that's User:Name/preferences.js and User:Name/shared.js. The idea behind that separation is that it should be possible to request several shared data sets without causing huge traffic. -- peco e s 02:30, October 02, 2012 (UTC)


 * P.S. I do agree on the point of "I don't think the lack of full privacy is much of problem though." - in almost all cases, it won't be. To give you an example, in the case of Railgun, I consider the friend's list to be "semi-secure" information: I've always viewed it as more of a "stalking list" than a "guestbook". I'd be perfectly content with obfuscating the data with a crappy encryption algorithm before passing it to preferences though, that way at least it isn't human-readable when placed on the page via automated edit. Anyways -- I'll let you finish preferences now :)


 * Don't want to put a damper on things but I don't think you can run scripts from the prefs page anymore =/. -- Kangaroopowah  ( Talk ) 04:25, October 2, 2012 (UTC)


 * You're a little late to the party on that :). Pecoes is using User:Name/preferences.js to show the UI instead. Adding an extra menu item to the User pulldown in the Wikia Header to link to it. Lunarity 04:52, October 2, 2012 (UTC)


 * heh, fail. And if you want any backend support, I have a server begging to be used.... ;). -- Kangaroopowah  ( Talk ) 05:24, October 2, 2012 (UTC)


 * That's kind of you to offer Kangaroo, but I'd rather not take you up on that. Right now this all very small scale. It might stay that way for some time to come. Maybe forever. But if it does take off, it will obliterate your server. The amount of traffic a site like Wikia can throw at you, is pretty scary. I too have a server or two somewhere whose package offers more traffic than needed and that I could advertise here. But I won't. You shouldn't either! Seriously! The risks are uncalculable.


 * I've started a Preferences page and added a new demo btw :) -- peco e s 17:41, October 03, 2012 (UTC)


 * Trust me pecoes, we can use it for a demo. ;) -- Kangaroopowah  ( Talk ) 02:21, October 4, 2012 (UTC)

"New Editor" still appears on "User:Wikia" account
Hello, we set

and "New Editor" still appears on w:c:bloons:User:Wikia account. I supposed that the tag was shown there, because User:Wikia had no mainspace edits, so I set also

however the tag still appears there.

Please, can you check our w:c:bloons:MediaWiki:Common.js, if there is something wrong there?

12:35, October 9, 2012 (UTC)


 * I have checked the issue again, and we have the same problem with  tag, that we disabled via Meta Filter on   group too (appears for example on w:c:bloons:User:CreateWiki script).


 * BTW,  tag doesn't appear on global bot accounts at all, which is probably the main source of all other problems. --  13:32, October 9, 2012 (UTC)


 * That's correct, the problem is that you have newuser set to namespace 0 (Main), the Wikia bot does not edit articles, only user talk and message walls. Try running  (this is what the script is doing internally), you get zero. If you do   then you get 4000-something. Unfortunately, this is functioning as designed.


 * The problem with global bots is a frustrating one, I've actually noticed that myself on the wiki I administer but I didn't know what to do about it. It's a bug in Wikia's servers; the servers don't admit that an account is in the bot-global group, it pretends that the user is normal. Compare this: to this: . This:  appears to work the way it's supposed to though. I'll cook up a new module that queries specifically for global bots, shouldn't take long (I hope). Lunarity 21:44, October 9, 2012 (UTC)


 * Okay, I actually modified the way mwGroups behaves to simultaneously query for  as well as   so it should work correctly now. Lunarity 22:44, October 9, 2012 (UTC)


 * I can confirm, that it works perfectly now, thanks. -- 09:05, October 10, 2012 (UTC)

"Blocked" tag doesn't appear
Hello, the "Blocked" tag stopped to appear on blocked users, for example on w:c:bloons:User:Monkey Engineer. If I remember well, it worked on our wiki a day or two ago. -- 20:19, October 10, 2012 (UTC)


 * Sorry, I've corrected the problem. I made a blind idiot mistake when I was trying to make it faster; the code was reading the Wikia tags off the page then just throwing them away instead of passing them on for further processing. I didn't notice when I created the feature because it only happens when your cache is hot, and the cache goes cold every 60 minutes so it worked whenever I looked at it (because my cache was always cold) but it was broken for anyone with a hot cache. Lunarity 01:13, October 11, 2012 (UTC)


 * Now it works perfectly. Thanks -- 08:08, October 11, 2012 (UTC)

"newuser" tag
Hello, is it possible to set the  tag via , that it disappears after "X edits OR Y days" instead of "X edits AND Y days"? Or, maybe a more complex condition for example like:

"30 edits OR (10 edits AND 5 days) OR 14 days"

23:06, October 12, 2012 (UTC)


 * Hmm.  and   are the two most complex modules so I'm becoming progressively more hesitant to make large changes to them (I seem to keep breaking them in the various stupid ways each time I try). That said, it should be reasonably easy to support optionally operating as an OR instead of just an AND if you'd like. The more complex expression format is more of a problem; accepting an AbuseFilter style string describing the expression is possible but, frankly, that's overly complicated (involves writing a parser). I could make it accept a JavaScript function that lets you define your own computation if you'd like that?


 * ? Lunarity 04:24, October 13, 2012 (UTC)


 * It looks very interesting. -- 07:58, October 13, 2012 (UTC)


 * I've coded it up and deployed it [may take a few minutes to kick through load.php], you can try it out now (syntax is exactly as shown above). I've updated the docs. Lunarity 08:57, October 13, 2012 (UTC)
 * We have been testing the "computation funtion", and all seems to work correctly. Thanks. -- 13:38, October 13, 2012 (UTC)

Bureaucrat tag bug?
If you have a look at http://bloons.wikia.com/wiki/Special:Contributions?target=AlthaBlade, you'll notice that he has a bureaucrat tag even though he's not a bureaucrat, while User:Rasengan553's contributions page has both tags although he's not a part of either group. This bug appears with  only, not , etc. — SW8573 (Talk) 07:03, October 21, 2012 (UTC)


 * Hmm. I'm not sure what I broke since I haven't touched the loader much recently. The problem you're seeing is that it's not detecting the contributions page properly (again), it's showing you your own tags on their page (I see "new editor" when I look at it because that's my tag). It's probably just a bad regex , I'll fix it. Lunarity 09:21, October 21, 2012 (UTC)


 * Turns out Special:Contributions is a royal annoyance. I never considered the possibility of URL rewriting happening with ?target on a pretty URL. I've generalised the code to handle all the (currently known) possibilities. Please tell me if you find more of these. Lunarity 09:37, October 21, 2012 (UTC)

Tags not showing up.
First of all. Sorry if the answer is explained on the UserTags page but this coding stuff is very new to me and it just is chinese for me. Also sorry for the bad English.

Some tags are not showing up, bureaucrats only have the "bureaucrat" tag and not the "admin" tag. Same with admins the "admin" tag shows but "chat mod" does not. But others like "rolback" does shown up as second tag.

I use the basic code because it said that is easier if you wanted to change something. I also put in the part on Wikia.css and Monobook.css as explained on UserTags. window.UserTagsJS = { modules: {}, tags: {} }; UserTagsJS.modules.inactive = 30; UserTagsJS.modules.newuser = true; UserTagsJS.modules.autoconfirmed = true; UserTagsJS.modules.mwGroups = ['bureaucrat', 'chatmoderator', 'patroller', 'rollback', 'sysop', 'bannedfromchat', 'bot', 'bot-global']; UserTagsJS.modules.metafilter = { sysop: ['bureaucrat', 'founder'], bureaucrat: ['founder'], chatmoderator: ['sysop', 'bureaucrat'] }; importArticle({type:'script', article:'w:c:dev:UserTags/code.js'});