Extension:PageTriage/pl
 Status wydania: stabilne |
|
|---|---|
 |
|
| Realizacja | Strona specjalna, Interfejs użytkownika |
| Opis | Facilitates reviewing and approving new pages |
| Autor(zy) | Ryan Kaldari, Benny Situ |
| Polityka zgodności | Snapshots releases along with MediaWiki. Master is not backward compatible. |
| MediaWiki | >= 1.40.0 |
| Zmiany w bazie danych | Tak |
| Tabele | pagetriage_log pagetriage_page pagetriage_page_tags pagetriage_tags |
| Licencja | Licencja MIT |
| Pobieranie | |
| Przykład | Special:NewPagesFeed on the English Wikipedia |
|
|
|
|
| Quarterly downloads | 16 (Ranked 157th) |
| Przetłumacz rozszerzenie PageTriage jeżeli jest dostępne na translatewiki.net | |
| Problemy | Otwarte zadania · Zgłoś błąd |
PageTriage is an extension that aims to provide a feature-rich interface for triaging newly-created articles. It is intended to replace the new page patrol core function while adding additional functionality for reviewing, tagging, and improving new articles. It adds a Special:NewPagesFeed page, and a page curation toolbar to new pages for those with the 'patrol' permission. It was developed by the Wikimedia Foundation's Features Engineering team. For additional details see Page Curation.
An important note is that some of the configuration and code is specific to the English-language Wikipedia's workflows and as it's constructed now the extension is pretty much impossible to internationalize. (See Phabricator:T50552.)
Simple install
Pobieranie
The extension can be retrieved directly from Git
[?]:
- Browse code
- Some extensions have tags for stable releases.
- Browse tags
- Select the tag
- Click "snapshot"
- Each branch is associated with a past MediaWiki release. There is also a "master" branch containing the latest alpha version (might require an alpha version of MediaWiki).
- Browse branches
- Select a branch name
- Kliknij "Kontynuuj"
Extract the snapshot and place it in the extensions/PageTriage/ directory of your MediaWiki installation.
If you are familiar with Git and have shell access to your server, you can also obtain the extension as follows:
cd extensions/
git clone https://gerrit.wikimedia.org/r/mediawiki/extensions/PageTriage.git
Instalacja
- Pobierz i umieść plik(i) w katalogu o nazwie
PageTriagew folderzeextensions/. - Dodaj poniższy kod na dole twojego pliku
LocalSettings.php:wfLoadExtension( 'PageTriage' );
- Uruchom skrypt aktualizujący, który automatycznie stworzy potrzebne tabele dla tego rozszerzenia.
Zrobione – Przejdź do Special:Version na twojej wiki, aby sprawdzić czy rozszerzenie zostało pomyślnie zainstalowane.
Do użytkowników używających wersji MediaWiki 1.24 lub wcześniejszej:
Powyższe instrukcje opisują nowy sposób instalowania tego rozszerzenia z wykorzystaniem wfLoadExtension().
Jeżeli chcesz zainstalować to rozszerzenie we wcześniejszych wersjach (MediaWiki 1.24 i wcześniejsze), zamiast wfLoadExtension( 'PageTriage' ); użyj:
require_once "$IP/extensions/PageTriage/PageTriage.php";
Checking for successful install
To actually see the extension working:
- Create a new page containing just a few sentences of text as an anonymous user.
- Visit Special:NewPagesFeed
The new page should appear, flagged as "Bez kategorii", "Sierota", etc. To see the page curation toolbar:
- Login as a user with the 'sysop' permission, or add a group with the "patrol" permission, and add some user to that group, and login as that user.
- Visit Special:NewPagesFeed
- Now you should see a "Przejrzyj" button next to the new page.
- Click this and you should see the page curation toolbar on the new page.
Advanced configuration
Additional extensions
For full functionality, you'll also need to install some additional extensions, although PageTriage works without them.
- Echo - Allows users to receive notifications for things like when an article they created has been marked as reviewed.
- ORES - In Special:NewPagesFeed, allows filtering by "predicted class" (
articlequality: stub, start, c-class, b-class, good, featured) and "potential issues" (draftquality: vandalism, spam, attack, copyvio). The predictions are done with machine learning. ORES AI is typically trained by editors via https://labels.wmflabs.org/ui/, or by analyzing reverts. The ORES database provides probabilities which are accessed via the ORES extension. A threshold (tolerable false positive rate) is applied to this data, and some of the thresholds are set in the ORES extension's extension.json file. - WikiLove - Adds a button to the Page Curation toolbar that allows you to leave a person a barnstar more easily.
Enabling draft namespace
By default, the draft namespace is disabled, but can be enabled with the following update to LocalSettings.php
// These three settings are optional, and will enable the Articles-for-Creation mode.
$wgPageTriageDraftNamespaceId = 118;
$wgExtraNamespaces[ $wgPageTriageDraftNamespaceId ] = 'Draft';
$wgExtraNamespaces[ $wgPageTriageDraftNamespaceId + 1 ] = 'Draft_talk';
When enabled, a new "articles for creation" tab will show up on Special:NewPagesFeed.
By default pages edited in the draft namespace will be "unsubmitted".
Articles in the draft namespace can be submitted for review by adding [[Category:Pending_AfC_submissions]] to the draft page. At which point they will show up under "awaiting review".
Note the toolbar controlled by the configuration variable $wgPageTriageEnableCurationToolbar does not show up in the draft namespace.
Cron jobs
To make sure old articles are eventually taken out of the new pages feed, you should set up a cron job to run the following file every 48 hours: cron/updatePageTriageQueue.php
Manual testing
Special:NewPagesFeed -> Articles for Creation
- Enable draftspace by following the directions above in the section #Enabling draft namespace.
- In Special:NewPagesFeed, to place a draft in one of the AFC states, you need to create a page in the "Draft" namespace, and add it to the following categories:
- Unsubmitted: (no category)
- Awaiting review: Category:Pending AfC submissions
- Under review: Category:Pending AfC submissions being reviewed now
- Declined: Category:Declined AfC submissions
Note: The Page Curation toolbar does not display for drafts.
ORES
Enwiki has the ORES extension installed, which provides machine learning predictions of an article's quality and of some common issues. ORES works fine in production, but requires some setup if you want to test in a localhost environment. It can be desirable to test with ORES turned on, for example, if you are changing the layout of Special:NewPagesFeed. Here is a localhost testing procedure:
- Clone Extension:ORES and add
wfLoadExtension( 'ORES' );inLocalSettings.php - Add this to
LocalSettings.php
$wgPageTriageEnableOresFilters = true;
$wgOresWikiId = 'enwiki';
$wgOresModels = [
'articlequality' => [ 'enabled' => true, 'namespaces' => [ 0 ], 'cleanParent' => true ],
'draftquality' => [ 'enabled' => true, 'namespaces' => [ 0 ], 'types' => [ 1 ] ]
];
- Run
php extensions/ORES/maintenance/BackfillPageTriageQueue.php
Extension configuration
The extension is based on the 'patrol' right. For more information about configuring patrolling, see Manual:Patrolling.
The following configuration variables can be set from your LocalSettings.php file:
| Variable | Default | Description |
|---|---|---|
$wgPageTriageEnableCurationToolbar
|
true
|
Set to false to disable the curation toolbar |
$wgPageTriageInfiniteScrolling
|
true
|
Whether or not to use infinite scrolling in the new pages feed |
$wgPageTriageMaxAge
|
90 | The age (in days) at which PageTriage allows unreviewed articles to become indexed by search engines (if $wgPageTriageNoIndexUnreviewedNewArticles is true). |
$wgPageTriageNamespaces
|
NS_MAIN | The namespaces that PageTriage is active in. |
$wgPageTriageNoIndexUnreviewedNewArticles
|
false
|
Set this to true if new, unreviewed articles should be set to noindex. In other words, if they should not be indexed by search engines until they are reviewed. |
See extension.json for the full list of config variables.
On-wiki configuration
It is possible to configure much of PageTriage on-wiki via the pages MediaWiki:PageTriageExternalDeletionTagsOptions.js and MediaWiki:PageTriageExternalTagsOptions.js, although the structure of the configuration may change in the future (to better accommodate wikis besides English Wikipedia).
You can get a general idea of how the configuration works by looking at the following:
- Dodaj tagi
- Defaults: modules/ext.pageTriage.defaultTagsOptions/ext.pageTriage.defaultTagsOptions.js
- English Wikipedia customization: w:MediaWiki:PageTriageExternalTagsOptions.js
- "Nominate for deletion" menu in Page Curation toolbar
- Defaults: modules/ext.pageTriage.defaultDeletionTagsOptions/ext.pageTriage.defaultDeletionTagsOptions.js
- English Wikipedia customization: w:MediaWiki:PageTriageExternalDeletionTagsOptions.js
From a coding perspective, the default .js file is loaded first, and the English Wikipedia customization file is loaded second. It's not either/or, both files are loaded. So if there is a variable set in the first file and in the second file, the second file's variable will overwrite the first one.
There are two top-level jQuery variables that define the curation templates that are listed in the curation toolbar under the 
(add tags) and 
(nominate for deletion) buttons.
These are:
$.pageTriageTagsOptions = {};
$.pageTriageDeletionTagsOptions = { Main: {}, User: {} };
The 'Main' and 'User' refer to the namespace of the page being curated. Each sub-item in the three sets above defines the tabs shown at the left side of the toolbar, and has the following form:
{
label: 'Short title',
desc: 'A longer description.', // Text only, no HTML or Wikitext markup
multiple: false, // Whether more than one of the tags can selected at once.
tags: { tag1 = {}, tag2 = {} }
}
Then the actual templates that are listed are defined under the above tags variable. Each deletion template has the following form:
{
tag: 'Actual_template_name', // Without the 'Template:' prefix.
label: 'Friendly template title',
desc: 'A longer description.', // Text only, no HTML or Wikitext markup
code: '',
params: {},
anchor: '',
talkpagenotiftopictitle: 'message-name', // The message name (e.g. pagetriage-del-tags-speedy-deletion-nomination-notify-topic-title) used as the section/topic title when posting to the editing user's talk page. Usually, you can reuse one of the existing messages (currently pagetriage-del-tags-speedy-deletion-nomination-notify-topic-title, pagetriage-del-tags-prod-notify-topic-title, pagetriage-del-tags-xfd-notify-topic-title). If you need a new one, file a task so $wgPageTriageDeletionTagsOptionsContentLanguageMessages or the PageTriage repository can be updated.
talkpagenotiftpl: 'Template_name' // The template that will be added to the editing user's talk page, not including the talk page heading (handled by talkpagenotiftopictitle).
}
At the moment, some tags must be present:
$.pageTriageDeletionTagsOptions.Main.xfd.tags.articlefordeletion
Przykład
So, if you don't want to use any of the built-in deletion templates (which can be imported from NewPagesFeed_Templates.xml, by the way) then you can replace them all with a single one by adding the following at the bottom of your MediaWiki:PageTriageExternalDeletionTagsOptions.js page:
var deletionSection = {
label: 'Deletion',
desc: 'Nominate for deletion.',
multiple: false,
tags: {
articlefordeletion: {
tag: 'delete',
label: 'Delete',
desc: 'Nominate this page for deletion.',
code: '',
params: {},
anchor: '',
talkpagenotiftopictitle: 'pagetriage-del-tags-xfd-notify-topic-title',
talkpagenotiftpl: 'Deletion notification'
}
}
};
$.pageTriageDeletionTagsOptions = { Main: { xfd: deletionSection }, User: { xfd: deletionSection } };
API
PageTriage adds the following API endpoints which can be used:
| API | Description | Type | Triggering action |
|---|---|---|---|
| pagetriageaction | Mark a page as reviewed or unreviewed, and logs the action in Special:Log. | Write |
|
| pagetriagelist | Retrieves the list of pages in the queue, and each page's metadata, including their reviewed status. To retrieve one page, you must provide the page_id. To provide multiple pages, you must select one of showreviewed/showunreviewed, and one of showredirs/showdeleted/showothers, or no pages will be returned.
|
Read |
|
| pagetriagestats | Retrieves stats about the number of pages in the queue for use in the header of Special:NewPagesFeed. | Read |
|
| pagetriagetagcopyvio | Mark an article as a potential copyright violation, and logs the action in Special:Log. | Write |
|
| pagetriagetagging | Add clean-up tags or deletion templates to a page, and logs the action in Special:Log. | Write |
|
Special:Log
The following logs are created by the extension:
| Speical:Log | log_type
|
log_action
|
Description | Notes |
|---|---|---|---|---|
| Page curation log | pagetriage-curation | delete, enqueue, reviewed, tag, unreviewed | Logs deletion tagging, maintenance tagging, marking page as reviewed, marking page as unreviewed | |
| Potential copyright violation log | pagetriage-copyvio | insert | Allows a bot to log potential copyright violations | Doesn't display unless you set $wgPageTriageEnableCopyvio to true
|
SQL tables
| Name | Prefix | Description | Old entry deletion strategy | Service classes (when refactoring, SQL queries should be moved to here) | Data classes |
|---|---|---|---|---|---|
| pagetriage_page | ptrp_ | The main table. Log of all pages created after PageTriage was installed. One entry per page. Stores the "mark as reviewed" statuses mentioned above. Also stores the last time a tag was placed on the page by PageTriage. Query ptrp_reviewed > 0 in this table to figure out if a page is marked as reviewed. No entry also means the page is reviewed.
|
All articles deleted once ptrp_reviewed > 0 (marked as reviewed) and older than 30 days. All redirects deleted after 180 days regardless of patrol status.
|
QueueManager, QueueLookup | QueueRecord |
| pagetriage_page_tags | ptrpt_ | Stores metadata about pages, to make the filters in the Page Curation toolbar work. For example, if you pick the filter "Were previously deleted", then PageTriage will query this table looking for the recreated tag ID. The tag ID is discovered by checking the pagetriage_tags table. See #pagetriage_page_tags for list of tags.
|
All article metadata deleted once ptrp_reviewed > 0 (marked as reviewed) and older than 30 days. All redirect metadata deleted after 180 days regardless of patrol status.
|
||
| pagetriage_tags | ptrt_ | A dictionary of page_tags, and their corresponding ID number. See #pagetriage_page_tags for list of tags. |
pagetriage_page_tags
pagetriage_page_tags data is updated by calling ArticleCompileProcessor::newFromPageId( [ $pageId ] )->compileMetadata(). This is called in the following hooks:
onPageMoveComplete()- runs when moving a pageonLinksUpdateComplete()- runs when saving an editonMarkPatrolledComplete()- runs when clicking the "Mark this page as patrolled" link in bottom right corner of certain pages
It is called asynchronously. The user will see that their edit succeeded and can continue browsing the website, and the page tags update will occur in the background, invisibly to the user.
List of tags
The pagetriage_page_tags are as follows:
- Author information
- user_id
- user_name - there's a filter where you can type in their username
- user_editcount
- user_creation_date
- user_autoconfirmed
- user_experience - Experience level: newcomer (non-autoconfirmed), learner (newly autoconfirmed), experienced, or anonymous. These experience levels are baked into core and can be accessed with
MediaWikiServices::getInstance()->getUserFactory()->newFromUserIdentity( $performer )->getExperienceLevel() - user_bot
- user_block_status
- Deletion tags - will display a black trash can icon if marked for deletion
- afd_status
- blp_prod_status
- csd_status
- prod_status
- Special:NewPagesFeed red warning text
- category_count - No categories
- linkcount - Orphan
- reference - No citations
- recreated - Previously deleted
- user_block_status - Blocked
- Page information
- page_len - size of article, in bytes
- rev_count - number of edits to the article
- snippet - text from beginning of article, used in Special:NewPagesFeed to preview the article
- afc_state - 1 unsubmitted, 2 pending, 3 under review, 4 declined
- copyvio - latest revision ID that has been tagged as a likely copyright violation, if any
Determining if a page is reviewed
Status codes
There are status codes used to track whether a page is reviewed or not. These are the values given when you query patrol_status, ptrp_reviewed, and ptrl_reviewed:
- Unreviewed
- 0 - unreviewed
- Reviewed
- 1 - reviewed (someone clicked the green check mark in the Page Curation toolbar)
- 2 - patrolled (someone clicked the "Mark as patrolled" link at the bottom right corner of a page)
- 3 - autopatrolled (someone with the
autopatroluser right created the page, or moved the page from a non-tracked namespace to a tracked namespace) - no result - will occur if the page is not in a tracked namespace (mainspace, userspace, and draftspace), if the article was created before PageTriage was installed, or if the article was reviewed for longer than 30 days (these records are deleted by a cron job)
Via the API
To check the review status of pages using an API query, you can use api.php?action=pagetriagelist&page_id=$PAGEID, and check the patrol_status field. Follow the directions above to interpret the values of this field.
Sample JavaScript code:
async function isReviewed(pageID) {
let api = new mw.Api();
let response = await api.get( {
action: 'pagetriagelist',
format: 'json',
page_id: pageID,
} );
// no result
if ( response.pagetriagelist.result !== 'success' || response.pagetriagelist.pages.length === 0 ) {
return true;
// 1, 2, or 3
} else if ( parseInt(response.pagetriagelist.pages[0].patrol_status) > 0 ) {
return true;
// 0
} else {
return false;
}
}
Via SQL
To check the review status of pages using an SQL query, you need to query the pagetriage_page table and the ptrp_reviewed field. Follow the directions above to interpret the values of this field.
/* By page_id */
SELECT ptrp_reviewed
FROM pagetriage_page
WHERE ptrp_page_id = 71318376
/* By page_title and page_namespace */
SELECT ptrp_reviewed
FROM pagetriage_page
JOIN page ON page_id = ptrp_page_id
/* For page_title, don't forget to use underscores instead of spaces. */
WHERE page_title = 'Živko_Kostadinović'
AND page_namespace = 0
NOINDEX
NOINDEX refers to the HTML code <meta name="robots" content="noindex">, which can be inserted into a page to stop the page from appearing in search engine results. In default installations of MediaWiki, all pages are indexed unless they contain the wikicode __NOINDEX__. When $wgPageTriageNoIndexUnreviewedNewArticles is set to true, PageTriage will take over deciding what pages are indexed.
First check
- First check: Noindex the page if ALL of the following are true:
$wgPageTriageNoIndexUnreviewedNewArticlesis turned on- Page age is less than
$wgPageTriageMaxAge(set to 90 days on enwiki) - Page is in
pagetriage_pagetable[1] - Page is marked as unpatrolled (ptrp_status = 0)
Second check
- Second check: If the wikitext has the
__NOINDEX__magic word, noindex the page if ALL of the following are true:- Page age is less than
$wgPageTriageMaxNoIndexAge(set to 90 days on enwiki) - If
$wgPageTriageMaxNoIndexAgeis not null, page is inpagetriage_pagetable[2]
- Page age is less than
The main use case for the __NOINDEX__ magic word is in deletion templates and maintenance tag templates that are transcluded into mainspace or draftspace. See this search.
Is the page in the pagetriage_page table?
In regards to the requirement "Page is in pagetriage_page table", there are several ways a for a page to get into this table:
- Not been deleted by a PageTriage cron job
- One cron job deletes redirects older than
$wgPageTriageRedirectAutoreviewAgedays old (default 180 days as of Sep 2022), regardless of patrol status. In other words, this cron job autopatrols them. - Another cron job deletes reviewed pages after 30 days of being reviewed
- One cron job deletes redirects older than
- In a namespace that PageTriage is configured to patrol
- Isn't an article that is so old it predates the installation of PageTriage
Toolbar
The toolbar has three states: maximized, minimized, and hidden. The maximized toolbar is the full-size toolbar with all buttons. The minimized toolbar still displays and floats, but simply says "Curation" and has an X you can click to close it. The hidden toolbar doesn't display at all, and can be re-opened by clicking the "Open Page Curation" link in the left menu.
Entry points
The extension's features can be triggered by various actions:
| Entry point type | File location | Notes |
|---|---|---|
| 5 APIs | includes/Api/* | |
| 1 special page | includes/SpecialNewPagesFeed.php | |
| 20 hooks |
|
|
| 1 cron job | cron/updatePageTriageQueue.php | runs every 48 hours |
| 7 maintenance scripts | maintenance/* | need to be run manually |
Here is a list of some actions and the corresponding entry points they trigger:
| Action | Entry points used |
|---|---|
| View Main page |
|
| Save an edit to the Main page |
|
| Type in search box, triggering search suggestions |
|
| View Special:NewPagesFeed |
|
| View an unreviewed article while logged in
and having the |
|
Hooks
| File | Group | Hook | Actions it performs |
|---|---|---|---|
| Hooks.php | Move page | onPageMoveComplete | Changes patrolled status, updates cache, updates metadata in pagetriage_page_tags table. |
| Edit page | onRevisionFromEditComplete | Handles marking redirects that flip to articles as unreviewed. DeferredUpdate. | |
| onPageSaveComplete | Add new articles to the New Pages Feed and pagetriage_page table. | ||
| onLinksUpdateComplete | DeferredUpdate of metadata / pagetriage_page_tags table. | ||
| Every page load | onArticleViewFooter |
| |
| Help:Patrolled edits | onMarkPatrolledComplete | Marking as patrolled (the patrol link shows up in template namespace, for example) will also mark as reviewed in PageTriage. | |
| Blocking and unblocking | onBlockIpComplete | Update article metadata / pagetriage_page_tags when a user gets blocked or unblocked. This is so Special:NewPagesFeed can display "Blocked" by articles created by blocked users. | |
| onUnblockUserComplete | |||
| onResourceLoaderGetConfigVars | Adjusts some config vars related to draft namespace ID. | ||
| Extension:Echo | onBeforeCreateEchoEvent | Code that makes PageTriage Echo notifications work. For example, the notification to article creators that their article was marked as reviewed. | |
| onEchoGetDefaultNotifiedUsers | |||
| onLocalUserCreated | |||
| Extension:ORES | onORESCheckModels | Code that makes PageTriage ORES filters in Special:NewPagesFeed work. For example, filtering by article size or by predicted vandalism/spam/copyvio. | |
| Help:Tags | onListDefinedTags | Code that makes PageTriage tags work. Tags can be attached to individual revisions to show that a tool helped make the edit. For PageTriage, it tags edits "PageTriage". | |
| onChangeTagsAllowedAdd | |||
| onChangeTagsListActive | |||
| API | onApiMain__moduleManager | Disables the pagetriagetagging API, if that feature is turned off in PageTriage's settings. | |
| Delete or undelete page | onPageDeleteComplete | If a page is deleted, also delete its data from the PageTriage queue, and remove it from the cache. | |
| HookHandlers/
UndeleteHookHandler.php |
onArticleUndelete | If a page is undeleted, add it back to the PageTriage queue, regardless of autopatrol status. Fixes a bug where undeleted pages were automatically marked as reviewed. | |
| HookHandlers/ Schema.php | SQL | onLoadExtensionSchemaUpdates |
|
External libraries
- front end
- Backbone.js
- jQuery
- jQuery Badge
- jQuery Waypoints
- jQuery UI
- Moment.js
- Mustache (template system)
- Underscore.js
Backbone and Underscore are unusual libraries to use in MediaWiki extensions, and jQuery UI is deprecated. Long term, we are interested in replacing these front end libraries, to make the extension easier to maintain.
Client-side hooks
PageTriage provides a specialized action queue system to allow other scripts and gadgets to integrate with it. This is similar to mw.hook except that it uses promises. This is done using the mw.pageTriage.actionQueue module. See the comments in the source code for documentation on how the system works.
The actionQueue module is available after the mw.hook ext.pageTriage.toolbar.ready fires.
PageTriage will give the action queue handler an Object with the following data, in addition to other data as noted below:
pageid— ID of the page being reviewed.title— Title of the page, including namespace.reviewer— Username of who is using PageTriage.creator— Username of the creator of the page.reviewed— Whether or not the page is currently or will be marked as reviewed.
Available actions
delete— Fired when the reviewer tags a page for deletion. The data given to the handler also includes:tags— An object of all the templates added to the page. The keys are the template title, and the values are an object of metadata, including things like the speedy deletion code.
mark— Fired when the review status of a page is changed. Also includes:note— The personal message the reviewer added for the creator of the page. This may be blank.
tags— Fired when maintenance tags are added to the page. Also includes:tags— An array of the titles of all templates that were added to the page.note— The personal message the reviewer added for the creator of the page. This may be blank.
Przykład
To use the action queue, register a function to be ran when an aforementioned action is fired. PageTriage will wait for any asynchronous code to complete before doing anything else, such as refreshing the page. For example, to edit Sandbox after a page has been marked as reviewed, you could use:
$( function () {
// You must first listen for the ext.pageTriage.toolbar.ready event using mw.hook, to ensure your handler is registered at the right time.
mw.hook( 'ext.pageTriage.toolbar.ready' ).add( function ( queue ) {
// Listen for the 'mark' action.
queue.add( 'mark', function ( data ) {
return new mw.Api().edit( 'Sandbox', function ( revision ) {
// Replace 'foo' with the note the reviewer left.
return revision.content.replace( 'foo', data.note );
} );
} );
} );
} );
Zobacz też
Notes
| To rozszerzenie jest wykorzystywane przez jeden lub więcej projektów Wikimedia. Oznacza to prawdopodobnie, że to rozszerzenie jest stabilne i działa wystarczająco dobrze, aby wykorzystywać je na stronach o dużym natężeniu ruchu. Odnajdź nazwę tego rozszerzenia w plikach konfiguracyjnych Wikimedia CommonSettings.php oraz InitialiseSettings.php, aby zobaczyć gdzie są zainstalowane. Pełną listę rozszerzeń zainstalowanych na określonej wiki można znaleźć na stronie Special:Version na danej wiki. |
| To rozszerzenie jest dołączone do następujących pakietów lub farm wiki: To nie jest pełna lista. Niektóre farmy/wiki mogą wykorzystywać to extension, nawet jeśli nie są tutaj wymienione. Zawsze sprawdzaj swoje farmy/hosty wiki, aby to potwierdzić. |