Changes
get rid of the last of the numbered parameters, and move the binary matrix explanation down to the protectionCategories section
--------------------------------------------------------------------------------
--[[-- The following banner data fields are available:-- text, explanation, tooltip, alt, image, category---- When the module is asked to retrieve one of these data fields, it looks in-- the cfg.bannerData table. It uses five properties in its search:-- 1. the expiry date-- 2. the namespace-- 3. the protection reason (e.g. "dispute" or "vandalism")-- 4. the protection level (e.g. "sysop" or "autoconfirmed")-- 5. the action (e.g. "edit" or "move")-- -- For each data field, the module will check to see if the field exists in the-- table with the key corresponding to all five parameters. For example, a-- user page semi-protected from vandalism for two weeks would have the key-- "temp-user-vandalism-autoconfirmed-edit". If no match is found, the module-- changes the first part of the key to "all" and checks the table again. It-- keeps checking increasingly generic key combinations until it finds the-- field, or until it reaches the key "all-all-all-all-all".---- This makes it possible to specify fine-grained distinctions in banner text.-- For example, data defined for the key "all-user-vandalism-all-edit" can be-- used for user pages that are protected either temporarily or permanently,-- and either fully protected or semi-protected, but it won't be used for-- articles or for pages protected against sockpuppetry.---- Note that the fields don't have to be in the same table. A given banner-- might use text from "temp-user-vandalism-autoconfirmed-edit" but a-- category from "all-all-vandalism-all-edit".---- The module uses a binary matrix to determine the order in which to search.-- This is best demonstrated by a table. In this table, the "0" values-- represent "all", and the "1" values represent the original data (e.g.-- "indef" or "file" or "vandalism").---- expiry namespace reason level action-- order-- 1 1 1 1 1 1-- 2 0 1 1 1 1-- 3 1 0 1 1 1-- 4 0 0 1 1 1-- 5 1 1 0 1 1-- 6 0 1 0 1 1-- 7 1 0 0 1 1-- 8 0 0 0 1 1-- 9 1 1 1 0 1-- 10 0 1 1 0 1-- 11 1 0 1 0 1-- 12 0 0 1 0 1-- 13 1 1 0 0 1-- 14 0 1 0 0 1-- 15 1 0 0 0 1-- 16 0 0 0 0 1-- 17 1 1 1 1 0-- 18 0 1 1 1 0-- 19 1 0 1 1 0-- 20 0 0 1 1 0-- 21 1 1 0 1 0-- 22 0 1 0 1 0-- 23 1 0 0 1 0-- 24 0 0 0 1 0-- 25 1 1 1 0 0-- 26 0 1 1 0 0-- 27 1 0 1 0 0-- 28 0 0 1 0 0-- 29 1 1 0 0 0-- 30 0 1 0 0 0-- 31 1 0 0 0 0-- 32 0 0 0 0 0---- In this scheme the action has the highest priority, as it is the last-- to change, and the expiry has the least priority, as it changes the most.-- The priorities of the expiry, the protection level and the action are-- fixed, but the priorities of the reason and the namespace can be swapped-- through the use of the cfg.bannerDataNamespaceHasPriority table.------ PARAMETERS
--
-- The values in the banner data can take parameters. These are specified
-- create a blurb like "This template is semi-protected", or "This article is
-- move-protected until DD Month YYYY".
--
-- ${VANDAL} - links for the specified username (or the root page name)
-- using Module:Vandal-m.
--]]
-- specific banner config.
text = '${INTROBLURB}.',
explanation = '${EXPLANATIONBLURB}',
create = {},
autoreview = {}
}
cfg.defaultBanners.autoreview.autoconfirmed = {
alt = 'Page protected with pending changes level 1',
tooltip = 'All edits by unregistered and new users are subject to review',
image = 'Padlock-silver-light.svg'
}
cfg.defaultBanners.autoreview.default = {
alt = 'Page protected with pending changes level 2',
tooltip = 'All edits by users who are not reviewers or administrators are'
.. ' subject to review',
}
cfg.banners.edit.usertalk = {
text = '${INTROBLURB} to prevent $6 {VANDAL} from using it to make disruptive edits,'
.. ' such as abusing the'
.. ' {{[[Template:unblock|unblock]]}} template',
cfg.banners.move.dispute = {
explanation = "This protection is '''not''' an endorsement of the " .. ' $9"{CURRENTVERSION}. ${EXPLANATIONBLURB}',
image = 'Padlock-olive.svg'
}
cfg.banners.move.vandalism = {
}
-- Protection categories
--------------------------------------------------------------------------------
--[[
-- The protection categories are stored in the cfg.protectionCategories table.
-- Keys to this table are made up of the following strings:
--
-- 1. the expiry date
-- 2. the namespace
-- 3. the protection reason (e.g. "dispute" or "vandalism")
-- 4. the protection level (e.g. "sysop" or "autoconfirmed")
-- 5. the action (e.g. "edit" or "move")
--
-- When the module looks up a category in the table, first it will will check to
-- see a key exists that corresponds to all five parameters. For example, a
-- user page semi-protected from vandalism for two weeks would have the key
-- "temp-user-vandalism-autoconfirmed-edit". If no match is found, the module
-- changes the first part of the key to "all" and checks the table again. It
-- keeps checking increasingly generic key combinations until it finds the
-- field, or until it reaches the key "all-all-all-all-all".
--
-- The module uses a binary matrix to determine the order in which to search.
-- This is best demonstrated by a table. In this table, the "0" values
-- represent "all", and the "1" values represent the original data (e.g.
-- "indef" or "file" or "vandalism").
--
-- expiry namespace reason level action
-- order
-- 1 1 1 1 1 1
-- 2 0 1 1 1 1
-- 3 1 0 1 1 1
-- 4 0 0 1 1 1
-- 5 1 1 0 1 1
-- 6 0 1 0 1 1
-- 7 1 0 0 1 1
-- 8 0 0 0 1 1
-- 9 1 1 1 0 1
-- 10 0 1 1 0 1
-- 11 1 0 1 0 1
-- 12 0 0 1 0 1
-- 13 1 1 0 0 1
-- 14 0 1 0 0 1
-- 15 1 0 0 0 1
-- 16 0 0 0 0 1
-- 17 1 1 1 1 0
-- 18 0 1 1 1 0
-- 19 1 0 1 1 0
-- 20 0 0 1 1 0
-- 21 1 1 0 1 0
-- 22 0 1 0 1 0
-- 23 1 0 0 1 0
-- 24 0 0 0 1 0
-- 25 1 1 1 0 0
-- 26 0 1 1 0 0
-- 27 1 0 1 0 0
-- 28 0 0 1 0 0
-- 29 1 1 0 0 0
-- 30 0 1 0 0 0
-- 31 1 0 0 0 0
-- 32 0 0 0 0 0
--
-- In this scheme the action has the highest priority, as it is the last
-- to change, and the expiry has the least priority, as it changes the most.
-- The priorities of the expiry, the protection level and the action are
-- fixed, but the priorities of the reason and the namespace can be swapped
-- through the use of the cfg.bannerDataNamespaceHasPriority table.
--]]
cfg.reasonsWithNamespacePriority = {