Talk:UserTags/Archive 1

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:

• 'Inactive'
• 'Never Edited'
• 'New Editor'
• 'New Account'
• 'Patroller'
• 'Rollback'
• 'Global Bot'

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:

• 'Amministratore' / 'Amministratrice' / 'amministratore/trice'

(Male, Female, Gender neutral/unknown)

ru

Inactive: Неактивный участник

Never Edited: Читатель

New Editor: Новый редактор

New Account: Новый участник

Patroller: Патрульный

Rollback: Откатчик

Global Bot: Глобальный бот

I think we don't need all nouns, they're long Rendann (talk) 07:20, November 28, 2015 (UTC)

Fixed translation. Wild 17:39, January 8, 2016 (UTC)

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'

VuhDyskusjaE-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)

it

ENG - IT Male / IT Female / IT Gender neutral or unknown

'Inactive': 'Inattivo' / 'Inattiva' / 'Inattivo'

'Never Edited': 'Mai modificato' / = / =

'New Editor': 'Nuovo contributore' / 'Nuova contributrice' / 'Nuovo contributore'

'New Account': 'Nuovo account' / = / =

'Patroller': 'Pattugliatore' / 'Pattugliatrice' / 'Pattugliatore'

'Rollback': 'Rollback' / = / =

'Global Bot': 'Bot globale' / = / =

leviathan_89 17:03, August 4, 2013 (UTC)

Done. —Wyz 18:09, August 21, 2013 (UTC)

uk

Ukrainian translation.

Inactive: Неактивний користувач

Never Edited: Читач

New Editor: Новий редактор

New Account: Новий користувач

Patroller: Патрульний

Rollback: Відкочувач

Global Bot: Глобальний бот

---

Капитан Джон Шепард^(Talk) 02:58, January 8, 2016 (UTC)

Fixed translation. Wild 17:38, January 8, 2016 (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 .UserProfileMasthead .masthead-info h2. This is somewhat awkward on our wiki, because we don't accept that the h2 should be the Wikia default of display:inline. Some of our users, like tardis:User:Duncs Kinnear-Swift, have very long "real" names, so we use a display:block 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, oasisPlaceBefore. Just set it to '> h2' 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? -- pecoes 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, UTCClock 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. -- pecoes 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-4CSS-3

and for the Script Preferences:

Actual HTML used:

<fieldset><legend>User Tags</legend>
<fieldset><legend>Languages</legend>
<p>What languages do you speak and want to be contacted in by other users?</p>
<table><tr>
<td><input type="button" value="add" id="ub-langs-add" /></td>
<td colspan="5"><select id="ub-langs-select"><option>Aafrikaans</option></select></td>
</tr><tr>
<td><input type="button" value="remove" id="ub-langs-rem" /></td>
<td><input type="checkbox" id="ub-langs-en" checked /><label for="ub-skills-js">English</label></td>
<td><input type="radio" class="ub-langs-en-rating" value="1" disabled /> basic</td>
<td><input type="radio" class="ub-langs-en-rating" value="2" disabled /> intermediate</td>
<td><input type="radio" class="ub-langs-en-rating" value="3" disabled /> advanced</td>
<td><input type="radio" class="ub-langs-en-rating" value="4" checked disabled /> native speaker</td>
</tr></table>
</fieldset>
<fieldset><legend>Skills</legend>
<p>Do you have any technical skills you would like to make available to the community?<br /><span style="font-size:80%;">(It's in your own interest not to advertise skills you don't have or don't want to share!)<span></p>
<table><tr>
<td><input type="checkbox" id="ub-skills-wiki" /><label for="ub-skills-wiki">Templates</label></td>
<td><input type="radio" class="ub-skills-wiki-rating" value="1" checked disabled /> basic</td>
<td><input type="radio" class="ub-skills-wiki-rating" value="2" disabled /> intermediate</td>
<td><input type="radio" class="ub-skills-wiki-rating" value="3" disabled /> advanced</td>
<td><input type="radio" class="ub-skills-wiki-rating" value="4" disabled /> professional</td>
</tr><tr>
<td><input type="checkbox" id="ub-skills-css" checked /><label for="ub-skills-css">CSS</label></td>
<td><input type="radio" class="ub-skills-css-rating" value="1" /> basic</td>
<td><input type="radio" class="ub-skills-css-rating" value="2"  /> intermediate</td>
<td><input type="radio" class="ub-skills-css-rating" value="3" checked /> advanced</td>
<td><input type="radio" class="ub-skills-css-rating" value="4"  /> professional</td>
</tr><tr>
<td><input type="checkbox" id="ub-skills-js" /><label for="ub-skills-js">JavaScript</label></td>
<td><input type="radio" class="ub-skills-js-rating" value="1" checked disabled /> basic</td>
<td><input type="radio" class="ub-skills-js-rating" value="2" disabled /> intermediate</td>
<td><input type="radio" class="ub-skills-js-rating" value="3" disabled /> advanced</td>
<td><input type="radio" class="ub-skills-js-rating" value="4" disabled /> professional</td>
</tr></table>
</fieldset>
</fieldset>

pecoes 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 :) -- pecoes 13:11, October 01, 2012 (UTC)

Looks good to me, 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. 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 <language code/skill name>-<level> 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... -- pecoes 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... -- pecoes 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:

(function (addon) {
    (((window.dev = window.dev || {}).preferences = window.dev.preferences || {}).usedAddons = window.dev.preferences.usedAddons || []).push(addon);
}('UserTags'));

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

function loadPreferences (addon) {
    var module   = ((window.dev = window.dev || {}).preferences = window.dev.preferences || {}),
        deferred = new $.Deferred(),
        prefs    = 'User:' + mw.config.get('wgUserName') + '/preferences',
        link     = 'w:c:preferences:',
        script   = 'MediaWiki:Preferences.js',
        files    = mw.config.get('wgDBname') === 'preferences' ? [prefs, script] : [prefs, link+prefs, link+script];
    (module.registry = module.registry || {})[addon] = { deferred: deferred };
    if (!module.loaded && !module.loading) {
        module.loading = true;
        importArticles({ type: 'script', articles: files });
    }
    return deferred.promise();
}

pecoes 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 form() 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. -- pecoes 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.

pecoes 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" { property: 'Name', type: 'number', rangeMin: 0, rangeMax: 10, rangeStep: 2, description: 'Example of a shared number property', uiHint: 'slider' } 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) Mathmagician ƒ(♫) 23:06 UTC, Monday, 1 October 2012

1. 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]
2. 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. pecoes 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 :) Mathmagician ƒ(♫) 00:53 UTC, Tuesday, 2 October 2012

If by "questions" you mean feature suggestions, we better discuss them now and here.

pecoes 01:00, October 02, 2012 (UTC)

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

1. 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.
2. 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?

1. 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.
   
   
2. 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.

pecoes 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. Mathmagician ƒ(♫) 02:17 UTC, Tuesday, 2 October 2012

(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. -- pecoes 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 :) Mathmagician ƒ(♫) 02:47 UTC, Tuesday, 2 October 2012

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 :) -- pecoes 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

UserTagsJS.modules.newuser = {
	days: 7,
	edits: 15,
	namespace: 0
};

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

UserTagsJS.modules.metafilter = {
	'newuser': ['bot', 'bot-global', 'util', 'council', 'vstf', 'helper', 'staff']
};

however the tag still appears there.

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

Spike¹⁴⁴ (talk) 12:35, October 9, 2012 (UTC)

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

BTW, bot-global tag doesn't appear on global bot accounts at all, which is probably the main source of all other problems. -- Spike¹⁴⁴ (talk) 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 {{Special:EditCount/Wikia/0}} (this is what the script is doing internally), you get zero. If you do {{Special:EditCount/Wikia}} 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: [1] to this: [2]. This: [3] 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 allusers as well as users so it should work correctly now. Lunarity 22:44, October 9, 2012 (UTC)

I can confirm, that it works perfectly now, thanks. -- Spike¹⁴⁴ (talk) 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. -- Spike¹⁴⁴ (talk) 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 -- Spike¹⁴⁴ (talk) 08:08, October 11, 2012 (UTC)

"newuser" tag

Hello, is it possible to set the newuser tag via UserTagsJS.modules.newuser, 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"

Spike¹⁴⁴ (talk) 23:06, October 12, 2012 (UTC)

Hmm. newuser and mwGroups 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?

UserTagsJS.modules.newuser = {
    namespace: 0,
    computation: function(days, edits) {
        // Return false = not newuser, return true = newuser
        return edits < 30 && (edits < 10 || days < 5) && days < 14;
    }
    // NOTE: Computation would be mutually exclusive with days/edits, those params would stop working when you define your own function.
};

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

It looks very interesting. -- Spike¹⁴⁴ (talk) 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. -- Spike¹⁴⁴ (talk) 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 Special:Contributions?target=Blah only, not Special:Contributions/Blah, 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)

It happens here too when i am logged in. Like you said, when you log out it shows the correct tags, but just to point out it seems like it happens again.

Penguin-Pal (talk) 16:17, July 1, 2013 (UTC)

Oh, it looks file now. Penguin-Pal (talk) 19:15, July 1, 2013 (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'});

 Aethelhelm  Talk  Contribs  Yogscast  15:03,11/9/2012 

That's the purpose of metafilter. It removes tags as indicated by the rules. You've got it set so that 'sysop' is removed when 'bureaucrat' or 'founder' is present, 'bureaucrat' is removed when 'founder' is present, and 'chatmoderator' is removed when 'sysop' or 'bureaucrat' is present. If you don't want that, just remove the entries from the UserTagsJS.modules.metafilter configuration block. Lunarity 16:24, November 9, 2012 (UTC)

Thank you very much, now I know that aswell.:)

 Aethelhelm  Talk  Contribs  Yogscast  16:48,11/9/2012 

Tags not showing up (2)

So I used the script for bureaucrat and councilor tags could also appear on How I Met Your Mother Wiki. It set them in the following order:bureaucrat, admin, councilor. However, only the bureaucrat tag is showing up on my User Page. Here is the code I am using:

window.UserTagsJS = {
	modules: {},
	tags: {
		bureaucrat: { order: 0 },
		sysop: { order: 1 },
		council: { order: 2 }
	}
};

Babar Suhail 23:09, April 18, 2013 (UTC)

You're using the default configuration. The default configuration removes "Admin" and replaces it with "Bureaucrat" for bureaucrats, if you don't want that then you'll have to customise it. For the councillor tag, that's missing because Wikia aren't pushing the councillor tag to users who are local admins and you haven't configured UserTags to look up councillors manually.

window.UserTagsJS = {
	modules: {},
	tags: {
		bureaucrat: { order: 0 },
		sysop: { order: 1 },
		council: { order: 2 }
	}
};
UserTagsJS.modules.inactive = 30;
UserTagsJS.modules.newuser = true;
UserTagsJS.modules.autoconfirmed = true;
// NOTE: bannedfromchat displays in Oasis but is not a user-identity group so must be checked manually
UserTagsJS.modules.mwGroups = ['bureaucrat', 'chatmoderator', 'patroller', 'rollback', 'sysop', 'bannedfromchat', 'bot', 'bot-global', 'council'];

Lunarity 07:08, April 21, 2013 (UTC)

Thanks for your help. Babar Suhail 08:30, April 21, 2013 (UTC)

Tags aren't showing up

Okay, I figure I'm messin something up heavily, but nothing is working. I've been trying to add tags for the Blood Brothers Wiki, but nothing is happening at all. Could someone kindly check the code at http://bloodbrothersgame.wikia.com/wiki/MediaWiki:Common.js and tell me what I'm doing wrong? :( Thanks in advance!

Overmage 12:29, June 18, 2013 (UTC)

First, What is the "Moderator" tag you made in the code? There is no "Moderator" in MediaWiki groups.

That might be the problem why it does not work. -Logo 08:51, July 15, 2013 (UTC)

We added a custom mediawiki group called 'Moderator'. Also I was under the impression that the code should be able to tolerate custom groups (for example, the user below is using 'Regalis' and says it works now).

I'll try removing them and give it a shot, but in the meantime, if you don't mind, could you let me know how I would go about adding a custom mediawiki group that already exists (in this case Moderator) into this custom tag? Thank you so much!

Edit: nope, removing doesn't work. I'm putting it back in for now since it's busted either way, can anyone help?

Code looks like this atm:

window.UserTagsJS 
= {
	modules: {},
	tags: {
		'bureaucrat': { u: 'Bureaucrat' },
		'inactive': { u: 'Inactive' },
                'moderator': { u: 'Moderator' }
	      }
};
 
UserTagsJS.modules.inactive 
= 50; // 50 days
 
UserTagsJS.modules.mwGroups 
= ['bureaucrat', 'moderator', 'bannedfromchat']; // add corresponding tags to users
 
importArticle({type:'script', article:'w:c:dev:UserTags/code.js'});

Overmage 15:09, July 26, 2013 (UTC)

There are errors in your Common.js:

SyntaxError: Unexpected EOF ~ UltimateSupreme 15:48, July 26, 2013 (UTC)

Not really sure how to go about fixing them :/

Overmage 17:53, September 13, 2013 (UTC)

The messed-up highlighting should give you a clue. This line: UserTagsJS.modules.mwGroups = ['bureaucrat', 'moderator, 'bannedfromchat']; is missing a ' after moderator. Not sure if there are more after that, I'm not familiar with this script. ~Bobogoobo (talk) 20:30, September 13, 2013 (UTC)

Tag doesn't show up after Implosion

I made a very long code for the userTag, and it is glitched that the tag doesn't show up. However, It all happened after I made the implode command.

UserTagsJS.modules.implode = {
	'lab-guard': ['chatmoderator','rollback']
};

This is what I made in the code. Then it showed something like "¿Lab_Guard?" in the tag. So i added a tag in UserTagJS.

window.UserTagsJS = {
	modules: {},
	tags: {
		labguard: {u:'Lab Guardian', order:-1/0},
	},
	oasisPlaceBefore: 
};

This is what I added in the UserTagJS, excluding all other tags (Because they worked before the bug exist)

Oh, and I acutally DID rename 'lab-guard' to labguard in the implode function to check if it would work.

Can someone tell me if this is actually the correct way to add the tag, or did I made some typing errors in the code? -Logo 09:10, July 15, 2013 (UTC)

For the whole code, please look at here. -Logo 14:58, July 16, 2013 (UTC)

Someone Help? -Logo 11:20, August 18, 2013 (UTC)

There were errors in your Common.js I've fixed. I'm not sure your implode would work because there is no one on the wiki having patroller, rollback and chatmoderator rights all together. —Wyz 13:25, August 18, 2013 (UTC)

Thanks a lot, because I was a rollback+chatmod, so I made that (Asked an admin to add it to the page). However, it did not work, and now I am a bureaucrat in that wiki... -Logo 13:42, August 18, 2013 (UTC) Oh, and why is it making everyone a new editor?

Edit: I fixed it. But still one thing, the bureaucrat does not work...

Bureaucrat works for me... —Wyz 14:21, August 18, 2013 (UTC)

No it doesn't for me... I have refreshed the cache. You sure it is "Conception Grandmaster" instead of "Conception Master"? -Logo 14:27, August 18, 2013 (UTC)

Edit: Found it. But it only works for the owner? Why?

As told, works for me: http://imm.io/1fHFz. —Wyz 18:15, August 21, 2013 (UTC)

This is what I see: http://prntscr.com/1n4hka
is there something wrong with it?

Tags don't show up at all

For some reason none of the tags are showing up on any of the user pages on my wiki. I've checked over the page several times and I can't seem to find the solution.

Here's the page with the code on my wiki: http://containmentbreach.wikia.com/wiki/MediaWiki:Common.js

Also for some reason whenever I add the new code to the common.js, the scripts on my Wikia.js page stops working entirely.

--Dr.Mark 23:53, July 15, 2013 (UTC)

You're missing commas. Should look like this:

// Custom User Tags
/* Setting up tags */
window.UserTagsJS = {
	modules: {},
	tags: {
		founder: { order: -1 },
		regalis: { u: 'Creator of Containment Breach', order: 1 }
	}
};
/* Founders */
UserTagsJS.modules.custom = {
	'Dr.Mark': ['founder', 'sysop'],
	'Tremorfan94': ['founder', 'sysop'],
	'Mrpeanut188': ['founder', 'sysop'],
	'Regalis11': ['regalis', 'sysop']
};

Not sure if there are more problems, but that'll at least fix something. ~Bobogoobo (talk) 00:50, July 16, 2013 (UTC)

It's working properly now, thank you. --Dr.Mark 02:01, July 16, 2013 (UTC)

Banned from chat tag not showing

Banned from chat isn't showing on banned users. Here is my configuration:

window.UserTagsJS = {
	modules: {},
	tags: {
		inactive: { u:'Inactive', order:-1/0 }
	}
};
UserTagsJS.modules.inactive = 30;
UserTagsJS.modules.newuser = true;
UserTagsJS.modules.autoconfirmed = false;
UserTagsJS.modules.mwGroups = ['bureaucrat', 'chatmoderator', 'patroller', 'rollback', 'sysop', 'bannedfromchat', 'bot', 'checkuser'];
UserTagsJS.modules.metafilter = {
	sysop: ['bureaucrat', 'founder','bot'],
	bureaucrat: ['founder'],
	chatmoderator: ['sysop', 'bureaucrat','bot'],
	rollback: ['sysop', 'bureaucrat','bot'],
	patroller: ['sysop', 'bureaucrat','bot']
};

Any help? 21:01, August 4, 2013 (UTC)

Hi. bannedfromchat user right was removed last year: w:User_blog:Sarah_Manley/Updates_to_Wikia_Chat —Wyz 14:46, August 17, 2013 (UTC)

Is there any way to keep it on the Masthead? 14:52, August 17, 2013 (UTC)

That is a good question. I don't have much time but I'll try at least to understand how this is pulled... I don't promise to have a fix ready soon. —Wyz 14:58, August 17, 2013 (UTC)

Ok, thank you. 15:01, August 17, 2013 (UTC)

Tags don't show up.

My tags won't show up. Here is the code. Please help!!

Spydar007 (Talk) 10:18, August 11, 2013 (UTC)

@import url is CSS, not JS. Use importArticles (recommended), importScript, importScriptPage or $.getScript. TK-999 (talk) 11:22, August 11, 2013 (UTC)

Ok...I've corrected that but it still doesn't work!!

Spydar007 (Talk) 18:03, August 11, 2013 (UTC)

Someone help!!!

Spydar007 (Talk) 15:18, August 16, 2013 (UTC)

Hi.

window.UserTagsJS = {
	modules: {},
	tags: {
		coding: { u:'Templates & Coding' },
		patroller: { u:'Patroller' },
	}
};

Try removing the last comma, after "patroller: { u:'Patroller' }". —Wyz 20:14, August 16, 2013 (UTC)

Nope. Still nothing.

Spydar007 (Talk) 13:32, August 17, 2013 (UTC)

There was an error in MediaWiki:Common.js/editbuttons.js, preventing the rest of MediaWiki:Common.js to load. It's fixed now. —Wyz 14:36, August 17, 2013 (UTC)

VSTF and Helper groups

I'm a member of the VSTF and helper groups. On my wiki, where I'm bureaucrat, I'd like those groups to show up too. Here the code I'm using:

window.UserTagsJS = {
	modules: {},
	tags: {}
};
UserTagsJS.modules.inactive = 30;
UserTagsJS.modules.newuser = true;
UserTagsJS.modules.autoconfirmed = true;
// NOTE: bannedfromchat displays in Oasis but is not a user-identity group so must be checked manually
UserTagsJS.modules.mwGroups = ['bureaucrat', 'chatmoderator', 'patroller', 'rollback', 'sysop', 'bannedfromchat', 'bot', 'bot-global', 'staff', 'helper', 'vstf'];
UserTagsJS.modules.metafilter = {
	sysop: ['bureaucrat', 'founder'],
	bureaucrat: ['founder'],
	chatmoderator: ['sysop', 'bureaucrat']
};

Thanks. leviathan_89 18:27, September 7, 2013 (UTC)

UserTags#Limitations. It should be there by default (Your vstf doesn't appear on c:vstf either).-- ~ UltimateSupreme 07:39, September 8, 2013 (UTC)

Tags and errors help

I've got a problem with the tagging information and tried adding but resulted with errors. Can't figure out what it is.

Could you please check it?

User:RGL Victor The Great (talk) 16:42, September 12, 2013 (UTC)

Having a problem with adding the tag information and errors along with it. Where for example "PL.FOUNDER" appears as "¿PL.FOUNDER?" with no tag information. Dunno what to do so I tried adding the code below, but didn't work. Can you please help?

Well, Here's the code:

// Tags
importScriptPage('UserTags/code.js', 'dev');
window.UserTagsJS = {
   tags: {
       founder: {
           u: 'Founder of Lucky Fred Wiki'
       },
       Special Agent Master: {
          u: 'Bureaucrat and Administrator of Lucky Fred Wiki'
       },
       Special Agent: {
           u: 'Patroller, Rollbacker and Chat Moderator of Lucky Fred Wiki'
       },
       es.founder: {
           u:'Founder of Spanish Lucky Fred Wiki'
       },
       es.founder2: {
           u: 'Founder of Spanish Lucky Fred Wiki'
       },
       es.admin: {
           u: 'Administrator of Spanish Lucky Fred Wiki'
       },
       pl.founder: {
           u: 'Founder of Polish Lucky Fred Wiki'
       }
   },
   modules: {
       autoconfirmed: true,
       inactive: {
           months: 1,
           namespaces: [0],
           zeroIsInactive: true
       },
       mwGroups: ['bannedfromchat', 'bureaucrat', 'sysop', 'chatmoderator', 'patroller', 'rollback'],
       newuser: true
   }
};
UserTagsJS.modules.custom = {
       'Felix900': ['es.founder'],
       'LFO': ['es.founder2'],
       'Burtbolivia': ['es.admin'],
       'Azaphen': ['es.admin'],
       'AgenteAly': ['es.admin'],
       'MicoTheGreat': ['pl.founder'],
};
UserTagsJS.modules.implode = {
       'Special Agent Master': ['sysop', 'bureaucrat'],
       'Special Agent': ['chatmoderator', 'patroller', 'rollback']
};

User:RGL Victor The Great (talk) 07:05, September 28, 2013 (UTC)

Same thing is happening to me also

--Erika was here
^{Wall • Contribs
My Website} 01:54, November 10, 2015 (UTC)

Found a fix to this problem.

Sophie Profile Talk/Message Wall Contributions 10:54, November 21, 2015 (UTC)

Not working

The UserTags won't show up! Please help! Here's my wiki's Common.js: http://aether.wikia.com/wiki/MediaWiki:Common.js --IStoleThePies | Message Wall | Contributions 22:02, September 20, 2013 (UTC) The following code should fix your problems. Add this in your Common.js

window.UserTagsJS = {
	modules: {},
	tags: {
		devcode: { u:'Aether Team', title:'Developer', order:-1/0 },
		devtexture: { u:'Aether Team', title:'Texture Artist', link:'Chase', order:-1/0 },
		devart: { u:'Aether Team', title:'Artist/Concept Artist', link:'OscarPayn', order:-1/0 },
		devwriter: { u:'Aether Team', title:'Lore Writer', link:'Liberty', order:-1/0 },
		devmusic: { u:'Aether Team', title:'Music Composer', link:'Emile van Krieken', order:-1/0 },
		owner: { u:'Current Owner', title:'Adopted Wiki', order:-1/0 },
		bureaucrat: { u:'Bureaucrat' },
		founder: { u:'Original Founder' }
	}
};
 
UserTagsJS.modules.inactive = 35; // Inactive if no edits in 35 days
 
UserTagsJS.modules.userfilter = {
	'IStoleThePies': ['sysop', 'bureaucrat']
};
 
UserTagsJS.modules.custom = {
	'IStoleThePies': ['owner'],
	'LibertyPrimeTF2': ['devwriter'],
	'OzzAR0th': ['devart']
};
importArticle({type:'script', article:'w:c:dev:UserTags/code.js'});

Also you had some Css in your Javascript page and some Javascript in your Css page.
So I would suggest you to add the following to this page.

.tag.usergroup-bureaucrat {
	background-color: gold;
	color: black;
}
.tag.usergroup-owner {
	background-color: white;
	color: black !important;
}
.tag.usergroup-devmusic,
.tag.usergroup-devcode,
.tag.usergroup-devwriter,
.tag.usergroup-devart,
.tag.usergroup-devtexture {
	background-color: blue;
	color: white;
}

Captscurvy (talk) 00:19, September 21, 2013 (UTC)

I put them in but nothing happened! By the way I only put in the Javascript part because I want to make sure it works. --IStoleThePies | Message Wall | Contributions 03:16, September 21, 2013 (UTC)

Please help! --IStoleThePies | Message Wall | Contributions 16:29, September 21, 2013 (UTC)

If anyone could help I'd really appreciate it! --IStoleThePies | Message Wall | Contributions 20:13, September 23, 2013 (UTC)

Remove the css from the js page.-- ~ UltimateSupreme 15:07, September 24, 2013 (UTC)

It still isn't working! What's going on? Did I do it right? --IStoleThePies | Message Wall | Contributions 21:09, September 24, 2013 (UTC)

Never mind, got it working. I'm really happy it works, but is there a way to add a tiny bit more spacing between the UserTags? --IStoleThePies | Message Wall | Contributions 21:19, September 24, 2013 (UTC)

Does anyone know? --IStoleThePies | Message Wall | Contributions 20:22, September 28, 2013 (UTC)

An easier way to add user tags to more than one user?

Hi. I'm having this problem. I use the user tag set up, the one in the walk through (that seems to be the only one that seems to work for me, like A LOT!). I try adding multiple users to it, like a specified user tag for all the users that I have classified under it. But, as I try it out, it just disappears on either my profile, or the other users profile, or both of our profiles! I need help, on this problem. If anyone can help me, thanks!

Also, in case if you don't know which one I'm using, I'm using this one

window.UserTagsJS = { modules: {}, tags: { jshelper: { u: 'JavaScript', order: 100 }, csshelper: { u: 'CSS', order: 101 }, templatehelper: { u: 'Templates', order: 102 }, bureaucrat: { order: 1 } } }; UserTagsJS.modules.custom = { 'Lunarity': ['csshelper', 'templatehelper', 'jshelper'] // NOTE: order of list here does NOT matter }; UserTagsJS.modules.mwGroups = ['bureaucrat', 'sysop']; importArticle({type:'script', article:'w:c:dev:UserTags/code.js'});

If anyone could help, It would make me feel like the happiest user in this wiki!!!

Do you hear that? That's the grape roaring. (talk) 23:14, September 28, 2013 (UTC)