Module:Protection banner/config: Difference between revisions

Content added Content deleted
Enwikipedia>Mr. Stradivarius
(further conversion)
Enwikipedia>Mr. Stradivarius
(get rid of the last of the numbered parameters, and move the binary matrix explanation down to the protectionCategories section)
Line 7: Line 7:
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------


-- PARAMETERS
--[[
-- 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
-- The values in the banner data can take parameters. These are specified
Line 148: Line 71:
-- create a blurb like "This template is semi-protected", or "This article is
-- create a blurb like "This template is semi-protected", or "This article is
-- move-protected until DD Month YYYY".
-- move-protected until DD Month YYYY".
--
-- ${VANDAL} - links for the specified username (or the root page name)
-- using Module:Vandal-m.
--]]
--]]


Line 160: Line 86:
-- specific banner config.
-- specific banner config.


cfg.masterBanner = {
-- All banner config messages can use the following parameters:

-- $1 = Intro blurb, e.g. "This page is currently
-- [[Help:Protection|protected]] from editing"
-- $2 = "until" or "or until" depending on the expiry
-- $3 = "disputes", with or without a section link
-- $4 = the type of the page, e.g. "article", "template", or "page"
-- $5 = the protection date
-- $6 = {{vandal-m|username}} replacement
-- $7 = protection level/type blurb, e.g. "create-protected" or "fully protected"
-- $8 = the expiry - " until DD Month YYYY". If protection is indefinite, this is the blank string.
-- $9 = A link to the page history or the move log, with display
-- msg['dispute-edit-link-display'] or msg['dispute-move-link-display']
-- $10 = A link to the protection log or the pending changes log, with display
-- msg['more-details-protection-log-display'] or msg['more-details-pc-log-display']
-- $11 = Talk page link
-- $12 = Edit request link
-- $13 = Request unprotection blurb
-- $14 = Adds links to edit requests and the talk page if we are on a subject page
-- $15 = Deletion links blurb
-- $16 = Deletion discussion link
-- $17 = Deletion log link
-- $18 = The explanation text, based on the protection action and level.

cfg.defaultBanner = {
text = '${INTROBLURB}.',
text = '${INTROBLURB}.',
explanation = '${EXPLANATIONBLURB}',
explanation = '${EXPLANATIONBLURB}',
Line 196: Line 98:
create = {},
create = {},
autoreview = {}
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',
}
}


Line 286: Line 200:


cfg.banners.edit.usertalk = {
cfg.banners.edit.usertalk = {
text = '${INTROBLURB} to prevent $6 from using it to make disruptive edits,'
text = '${INTROBLURB} to prevent ${VANDAL} from using it to make disruptive edits,'
.. ' such as abusing the'
.. ' such as abusing the'
.. ' {{[[Template:unblock|unblock]]}} template',
.. ' {{[[Template:unblock|unblock]]}} template',
Line 309: Line 223:


cfg.banners.move.dispute = {
cfg.banners.move.dispute = {
explanation = "This protection is '''not''' an endorsement of the $9",
explanation = "This protection is '''not''' an endorsement of the"
.. ' ${CURRENTVERSION}. ${EXPLANATIONBLURB}',
image = 'Padlock-olive.svg'
image = 'Padlock-olive.svg'
}
}


cfg.banners.move.vandalism = {
cfg.banners.move.vandalism = {
}

cfg.banners.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.banners.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',
}
}


Line 403: Line 306:
-- Protection categories
-- 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 = {
cfg.reasonsWithNamespacePriority = {