User:PerfektesChaos/js/editToolStrIns/Project Customization

This page describes how sysops might configure the entire local project.

Localization
Projects might create their own  object, or reuse another localization, accessed by similar language code.

Instead of the standard project identity the configuration variables  and   may be used to access another   explicitly.

If not defined by setting, the algorithm tries to guess appropriate localization objects, falling back to English if failure.

Create a particular localization
If you are not happy with the existing localization objects, a sysop might provide a new one.

Please share with other WMF projects, if successful and meaningful for reusing.

Note: Create objects with string identifiers; some browsers would not find them otherwise.
 * Create a  object, named by a particular identifier as described below under naming convention.
 * Provide one until four elements as described below.

Naming Convention
Consider rules when assigning an identifier. If subclassed by hyphen, use underscore  instead, like. e.g. e.g.. e.g. If you made your choice for example, the object is created as
 * Lowercase ASCII only to identify project and language.
 * Language: Use ISO 639 code
 * Project:  project identifier
 * Project type
 * subclass distinct versions by underscore

Elements
One to four elements may be declared: In most cases it is meaningful to declare some specific definitions, e.g. compose the standard menu:
 * This needs to be an object describing which titles appear as items in the control, in which order, and which definitions are linked to the items.
 * For technical details about the  element see Format.
 * For technical details about the  element see Format.
 * See Format on further details.
 * See Format on further details.

Language oriented objects should provide

Code location
Usually JS code for the entire project is written into the project Mediawiki: namespace. The global script will be imported by mw.loader.load; before or after load call the application object may be created and populated.

Another way is to resign updates and insert a copy. This gives the opportunity to cut off some definitions and make the code a bit smaller, but would not be recommended.

Customization variables
Two variables may be defined in order to override the project DB and language: Further standard project settings are:
 * will be used instead of
 * will be used instead of
 * enables memorising a charset selection from previous page edits, see below.
 * permits redefinition of separator between groups
 * permits redefinition of ellipsis between enclosing strings

Resolving algorithm
The standard token definitions are taken always from an appropriate project type and project language. Therefore the inserted strings will be compliant with the project environment.

The GUI elements (hints, choice) are taken with respect to the user language, where possible. This shall provide a familiar appearance, and readability if the user even cannot read the script of a project visited as a guest.

Cookie
If  is set to a non-empty string a session cookie will be created which shows the most recent selection of a subset on previous pages. By default no cookies are used. If requested, set to name string:
 * In 2010/2011 the English Wikipedia uses a  cookie for this purpose.

Removing unnecessary stuff

 * For the sake of smaller code a sysop may remove  projects from a local copy of the script which cannot be assigned ever.
 * Language oriented definitions could be maintained; they help users with particular language skills. English is the fallback position and should not be discarded.
 * Character sets should be supported even if not referenced by the current project standard offer. Users working on exotic issues might want to access them by personal configuration.