User:PerfektesChaos/js/editToolStrIns/Project Customization

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

JS items beginning with a period are references to the particular application object.

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: See Details.
 * 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.
 * Details explains more about the   element.

Language oriented objects should provide

Standard items
Some items are supposed to be accessed by standard identifiers: Their content will be project and language specific and should be adapted.
 * (zero as string) – Standard display (appears by default)
 * – Some wiki syntax elements
 * – Standard templates

Namespace dependency

 * – specific to file description pages which may need insertion of information and license templates.

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 of the global script. This gives the opportunity to cut off some definitions and make the code a bit smaller, but is not recommended.

Project environment is supposed to limit loading on  values of   or.

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
 * is an object defining style properties of this separator.
 * permits redefinition of ellipsis between enclosing strings when generating tooltips

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.

CSS
Decorative styles are to be assigned on project definition level. The global script does not apply particular style information. See Details.

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.