Toolserver:Tool considerations

There are a number of considerations that should be made when determining whether to or how to make a Toolserver tool. This page lists some of the most important considerations.

Necessity
The first thing that needs to be considered is whether a similar tool already exists. There is no authoritative directory of Toolserver tools, though there is Interiot's tstoc. While writing your own tool can be a good learning experience, it isn't always the best use of resources, especially developer time.

Another consideration to make, especially if you're coding in PHP, is whether your tool or script is better suited as a MediaWiki extension.

Multi-maintainer tools
Multi-maintainer projects are available to Toolserver tools. Setting up a multi-maintainer tool has a number of benefits, but to end users the biggest benefit is a stable URL.

Abstraction
Code abstraction is one of the more important considerations when designing a Toolserver tool.

As an example, it's trivial to create a script that takes the contents of the speedy deletion category on a certain wiki and arranges the content by size. However, this tool won't work for any project that doesn't use the category name "Candidates for speedy deletion". Even if you programmed the tool with every translation and iteration of the speedy deletion categories, it wouldn't support other categories that users might want to query.

A much better solution is to create a tool that allows the user to select a specific wiki database and select a specific category. The flexibility to this approach reduces tool duplication and provides a better service for the end users.

When possible, tools should be designed to support every active wiki database, though it's fine to set a default database if a database is unspecified (this is especially important for historical URLs).

Never hard-code namespace names or site URLs. These should always be queried from the Toolserver database.

Security
Sanitize user input. Always!

Ensure that you don't crash any browsers by outputting too many results.

Place reasonable limits on your code if it involves resource-intensive processes.

Internationalization
When designing your tools, remember that not every user will speak the language that your interface is in. Using icons and colors in place of or next to key elements in your interface will allow non-native speakers to understand how to use your tool.

Services like translatewiki.net can be employed to translate your tools, though I don't know much about how that works.