Talk:Wikimedia Scripts

Anyone can edit

I disagree with allowing anyone to edit userscripts. This right should be limited to the creator of the script and trusted users (read: admins) for security reasons. I would consider some kinda of content management system where every edit to a script has to be checked before it goes live. πr² (t • c) 02:00, 16 February 2013 (UTC)

As I already wrote here, at point #10, «Final users will get updates only when a revision of the script is accepted by a patroller/administrator»! --Ricordisamoa 11:13, 16 February 2013 (UTC)

A bunch of questions

Ivony tower: Gadgets 2.0 ?

• mw:RL/V2SPEC — I don't know how much of it or of your proposal has been implemented yet. Some aspects look similar. -- Rillke (talk) 14:59, 17 February 2013 (UTC)

Indeed. Helder 01:34, 21 September 2013 (UTC)

i18n

• How will scripts effectively load i18n? -- Rillke (talk) 14:59, 17 February 2013 (UTC)
• How will translators be able to contribute? -- Rillke (talk) 14:59, 17 February 2013 (UTC)

Many subpages would be created, one for each language, for each script; there would be a GUI to edit all i18n messages (like in Wikidata for entities). Then, there would be a special JavaScript module in MediaWiki, that would load dynamically all messages for the desired language, and those would be easily requested by each script. --Ricordisamoa 15:35, 17 February 2013 (UTC)

Gadgets as RL modules in Wikis?

• How will the list of gadgets be published to the wikis? -- Rillke (talk) 14:59, 17 February 2013 (UTC)
• Will be all gadgets published to each wiki? If no, who / how one will config this? -- Rillke (talk) 14:59, 17 February 2013 (UTC)

No, they would not be hosted on each Wiki project, but on scripts.wikimedia.org (or similar), and requested if the user has enabled them, on every wiki. --Ricordisamoa 15:41, 17 February 2013 (UTC)

Really all ?

• This will be quite a lot... who should review all of them? -- Rillke (talk) 14:59, 17 February 2013 (UTC)

Detailed comment

Thank you for your efforts. Your goals are desirable.

However, I am afraid that this plan for a Wiki project will not be sustainable for various reasons.

Concurrent activities

• mw:Extension:Gadgets
• labsconsole:
  • There is such a thing like a project maintained by several users who can continue work when someone resigns.
• On mw:, there is something called ResourceLoader; also plans for a Gadget: name space (which might contain resources currently in Mediawiki: name space) and an idea for user script support called RL3, which could pop up within this decade.
  • I would really appreciate to retrieve the latest versions of my scripts by a timestamped URL.
  • Apparently, these efforts felt asleep in spring 2012.
  • However, infrastructural considerations have been made there from a more inside view.
  • One day, RL3 might provide such a derived gadget store as you are longing for.
• A list of recommended world wide gadgets may be maintained on mw: right now. There is no need to establish an entire project.

Stages of script prosperity

Typically, the life time cycle of a user script looks like that:

1. One user is bothered by routine work or needs a button for a functionality to support her or his personal working style.
2. After writing such a script, it may be shared with some close friends working in the same area and similar needs.
3. One day, after creating a documentation page, the script may be advertised on a project (wiki) wide page, like
   • w:en:Wikipedia:WikiProject User scripts/Scripts
   • w:de:Wikipedia:Technik/Skin/Benutzerskripte
4. If a large number of users require one particular script, that one may be listed on the preferences page as a gadget.
   • From now on, the community (which is everyone and no one) takes some responsibility to maintain that gadget, even if the author leaves the project, since many users are relying on this functionality. It has to be checked carefully for security issues and proper execution.
   • Only very few user scripts will gain this gadget state.
   • Otherwise, the preferences page will be overwhelming and confusing, flooded with 50 or 100 entries; many of them buggy, no longer working, with security leaks or misbehaviour.
5. One day the script is really out of date, the prerequisites are not longer valid, the environment changed completely. The script will be buried.
6. Your suggestion is obviously to provide a world wide canonical selection of maintained, bug free, trusted, save resources, which is most obviously based upon such preferences pages.
   • Those are interesting for a minority of users, only if advertising in local language is present; if not, they will be ignored.
   • I know only a rare number of scripts which have such required functionality and are world wide useful and supported, like HotCat and WikEd.
     • See mw:Extension:Gadgets #List of gadget scripts – not all of them are really up-to-date and should be recommended.

Multilingual support

• It is not done with localized button labels.
• You will also need translated documentation pages; and a localized talk where users can file bug reports, ask questions, submit proposals for additional features.
• Currently there is no world wide support for user script text fragment translations. There is the translatewiki process, which is not available for user scripts right now.
  • Developers can feed it now manually by mw.messages.set() but need to provide those text pieces internally.
• Personally, I equip all my scripts which could be useful on any wiki with a hooked repository for multilingual support, e.g.:
  • w:en:User:PerfektesChaos/js/watchlistTools #Other languages
  • mw:User:PerfektesChaos/js/resultListSort #Other languages
• Most developers write their user scripts to be used in their own project, in their native language. No one can force them to provide localization features everywhere rather than simply a string.

Review, trusting, release, security, maintenance

• Any script perforates the browser security by width of a barn door.
• Only scripts with trusted author and proven safety are to be included into the recommended subset.
• Review of new versions is extremely time consuming and needs highly skilled developers.
• For the world wide PHP implementation of the Mediwiki server software a community has been built over years, with a lot of experience and making tiny steps cautiously, reviewing every line twice and deploying weeks later.
• The central JS resources are written by a small number of developers, most of them employees of WMF with five or even ten years experience.
• After some five years, the JavaScript technology in WMF context changed dramatically.
  • Looking at 2008, we are not working any longer on a single monobook.js, with wikibits.js support and addOnloadHook() call, without jQuery and mw objects.
  • A five year old script has a lot of limitations, obsoleted calls, depreciated methods. The entire design is not matching current architectural needs; this cannot be helped by renaming some function calls.
  • The original authors will keep their babies alive as long as possible.
  • A successor will not repair an unflexible, outdated, unfitting old tool. To reach the same goals as before, but with better browser support, localization, configurable by user options, exploiting library functions wherever possible, avoiding global variables, and much more functionality – you will create a new user script.

Human resources

• User scripts are written by – users.
• Users take pride in their own work, in their own tool.
• They are volunteers.
• Some users help to maintain tools from people no longer active, if that gadget is really useful and widely needed.
• As long as a script author is present, development is done by a single person. Sometimes one or two close friends give support and provide hints or pieces of code.
• Doing a review for one change takes hours; looking into the code and testing in various scenarios. This is generally done by the main authors theirselves – and later by the bug reports of community.
• The experienced script authors you expect to do all the review and release versions, programming on other peoples scripts and take responsibility for all that stuff – they are already working to full capacity. Such crowds of patrollers and administrators with leisure are simply not existing.
• I just quote, but I want not to comment on They will follow coding conventions and policies.

Missing resources

• There are not only JavaScript resources.
• There are also CSS resources in use nowadays.

  sure, they also would be included. --Ricordisamoa 15:52, 17 February 2013 (UTC)

• There are similar source code resources which might need such deployment, like Visual Basic for Applications and others.

Common common.js

• I take it from your proposal that you want a shared common.js for SUL on all WMF sites.
• Such a thing might be created one day, executed with something like centralauth.common.js + centralauth.skin.js and centralauth.common.css + centralauth.skin.css on any site before the user site resources come into effect.
  • That might look like bits.wikimedia.org/central/load.php?modules=user&only=scripts&skin=vector&user=PerfektesChaos&version=20130210T213034Z&*
• However, you will still need to maintain a site common.js etc., since only a few resources are really needed and applicable to all projects. Some other are not meaningful, and you would slow down the page building process with piles of garbage.

Greetings --PerfektesChaos (talk) 15:36, 17 February 2013 (UTC)

I don't get the point, I think. Please, explain briefly:

• critiques on things that can be improved
• the situation of similar projects
• critiques on things that cannot be improved

--Ricordisamoa 15:51, 17 February 2013 (UTC)

Explanation

I simply don't agree with the current scripts system:

• To install a script, I have to edit all my 'common.js' etc.

  solution: on a global 'store', I click

  Install

  and it's done

• If I have a suggestion, I cannot simply edit a script, because it's in the User: namespace

  solution: I, as autopatrolled user, could edit it

• There could be many useful scripts spread on all projects, but I have to rewrite one

  solution: on a global 'store', the Main Page would list them

• A non-english user couldn't use most of the scripts

  solution: users would be able to i12ize any script (as descripted above)

If you know a better (and maybe already existing) manner to do all this, ring the bell. --Ricordisamoa 16:19, 17 February 2013 (UTC)

P.S.: RL/V2SPEC looks really interesting! --Ricordisamoa 16:22, 17 February 2013 (UTC)

• One correction:
  • The statement There could be many useful scripts spread on all projects, but I have to rewrite one is simply not true.
  • Look at mw:User:PerfektesChaos/js/resultListSort#Usage. That one is located on mediawiki.org, but you can use it from any WMF project, even more from any Wikia.com project; simply from any private site running MediaWiki software.
• You want an easy approach.
  • This is well understood. We all want this.
  • You just want to click on [install] for any user script, and everything is working. You don't want to think about.
    • This expectation is simply wrong. You are not aware of any security risk.
    • You are responsible for any damage. You are responsible for any security violation.
    • You expect that anybody is taking this burden from your shoulders. Someone else should check all these scripts for proper functionality and safe execution, and shall be blamed. No one will do so. These are user scripts. They are provided under responsibility of the author or later maintainer, and they will be executed under your responsibility, whatever they do. These are user scripts, NOT Mediawiki software.
• You want to change other peoples software, since you are an autopatrolled user.
  • I will crucify you if you would ever make an attempt.
  • My scripts are quite sophisticated. I can hardly keep them working bug-free myself. You won't be able to make a trustable improvement.
    Attention, please: in that case, 'I' stood for 'a general user'! --Ricordisamoa 23:14, 20 February 2013 (UTC)
  • My sysops are permitted to edit them, but they will never try. I promise.
  • If my script modification is causing a page corruption, I am blamed. I test carefully to avoid this before releasing an update. If ten people, even autopatrolled users, were editing the script – who knows later what causes the problem? I, as the author, won't understand my own script any longer. Who is responsible for the misfunction now? Who will repair all the broken pages?
  • If you have write access to a script, you can build a malicious backdoor. Just wait until a sysop will use that gadget, then you gain sysop privileges.
• For a limited number of scripts there might be a solution as global gadgets.
  • For one or two dozens, really useful ones, perhaps. I linked above to ResourceLoader.
  • There might be a shared SUL common.js one day. That's all.

You aren't a programmer, are you? --PerfektesChaos (talk) 17:37, 17 February 2013 (UTC)

Probably you're right, so let's wait for RL/V2SPEC. should I declare Wikimedia Scripts as 'closed'? --Ricordisamoa 17:46, 17 February 2013 (UTC)

I wouldn't mind if we would have a central documentation repo (not only for gadgets but also for user scripts). Currently information is mainly spread between MediaWiki and Wikipedia. It should also contain some "list" of specific implementations. I had to use Google to find Cacycle's diff module and only by accident, I discovered Schnark's implementation of it.

As for the security risk; yes, one has to be careful but the situation in German Wikipedia really sucks: at least 3 users who are not administrators write a lot of good tools that are not available as gadgets and they fail to see how it is a hassle for users to read all their f****** manual just to read how to install them best.

They won't believe it but some users even don't get it copying one line from the documentation and pasting it into their js (this is not the only js I corrected at Commons) -- Rillke (talk) 15:05, 19 February 2013 (UTC)