Page MenuHomePhabricator

Permission error message for editing MediaWiki namespace
Closed, ResolvedPublic

Description

When viewing source for pages in the MediaWiki namespace on wikis where I am not a syop, I am told:

"You do not have permission to edit pages, for the following reason:
This page provides interface text for the software, and is locked to prevent abuse."

But I can edit pages in other namespaces, so it should only say that I am not allowed to edit pages in the MediaWiki namespace.


Version: 1.13.x
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=30127
https://bugzilla.wikimedia.org/show_bug.cgi?id=32683

Details

Reference
bz14246

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:11 PM
bzimport set Reference to bz14246.
bzimport added a subscriber: Unknown Object (MLST).

crochet.david wrote:

Yes
If "You do not have permission" seem to say, you are "not allowed to edit pages in the MediaWiki namespace".

So, what is the problem ?

Perhaps "You do not have permission to edit pages" should be changed to "You do not have permission to edit this page"

Yes. I didn't feel like a whole bunch of new interface messages for actions as well as rights.

Some background. This originates from the following code:

/var/www/w/includes/OutputPage.php: $text = wfMsgNoTrans( 'permissionserrorstext-withaction', count($errors), $action_desc ) . "\n\n";

Message:
'permissionserrorstext-withaction' => 'You do not have permission to $2, for the following {{PLURAL:$1|reason|reasons}}:',

$action_desc = wfMsg( "right-$action" );

Quite bad from an i18n perspective... Ideally the messages Andrew didn't want to add, need to be added, unless a for is found that can use right-* in all languages.

This is a kind of patchwork message in French, because the message does not support the contextual elision at end of

"Vous n’avez pas le droit de $1"

into

"Vous n’avez pas le droit d’$1"

which is mandatory when $1 starts by a vowel (e.g. "accéder à [[Special:SimilarEditors]]", translating "access to [[Special:SimilarEditors]]").

Note that this could happen as well with user names or other proper names or product names in $1, but it is less critical for such names where elision may be avoided (this is not true for regular verbs like "accéder").

Are there plans in Mediawiki to support common grammatical elisions (at least before an initial vowel in French, the case of the initial "h" is more complex, depending if that word has an "aspirated h" before another vowel, where elision of a previous short term like "je", me", "te", "se", "ne" is grammatically and orthographically forbidden; whereas the "mute h" for other cases requires that elision, , i.e. dropping their final "mute e" and gluing the term with an apostrophe not followed by any space). Most often in French, the leading "h" is mute, whereas "aspirated h" are common exceptions (usually noted in French dictionnaries by an asterisk "*" just before "h" in the phonetic transcription or in the orthography of the lemma entry).

One solution would be to allow inserting some "meta-mark" (like "{{GRAMMAR:set|elide|0}}" or "{{GRAMMAR:set|elide|1}}") in translations of units like

"accéder à..." => "{{GRAMMAR:set|elide|1}}accéder à...",

and then allow the translation unit containing a reference to "$1" to use a contextual form

"Vous n’avez pas le droit {{GRAMMAR:if|elide|$1|d’$1|de $}}"

or with explicit selectors "1=" and "0=":

"Vous n’avez pas le droit {{GRAMMAR:if|elide|$1|1=d’$1|0=de $}}"

The syntax "{{GRAMMAR:if|mark|text|forms...}}" would just see if the text as a value set for the given meta-mark to select one of the provided forms; that meta-mark value just needs to be a simple integer (or parsable as a common symbolic boolean value "yes"/"no"/"false"/"true", which can be converted to simple integers 0 or 1); and the last specified form is used as a commion fallback if the meta-mark has no value detected.

The grammatical parser could also support automatic elision detection (e.g. here in French for all words starting by a vowel, in "[aàâeéêëiîïoôuùyÿ]" and their associated capital letters for normal French, it would not be needed to use that "meta-mark". As well the parser could support automatic determination (for known lists of exceptions such as the "aspirated h", using a builtin dictionnary of words like "haricot" which is aspirated, or prefixes, definable by a set of words or regular expressions for prefixes like "^homo"; outside this dictionnary, words starting by "h" would be using an "unaspirated h" where the "elide" would be 1=true, words starting by other consonnants would have "elide" set to 0=false).

Contextual grammatical meta-marks would also be useful for mutations in Celtic languages, or other contextual uses notably in Slavic languages like Russian (where translation is still not easy and requires using strange forms that look mor like enumerations or terms rather than normal sentences). Each language could provide their own set of supported contextual grammatical meta-marks.

They would also be useful to provide contextual info such as the grammatical gender, plural or case.

A reverse situation can also occur where the embedding context changes the way the embedded subunit would translate: a subunit could also use the "{{GRAMMAR:if|mark||forms...}}" syntax to select one of several forms to return, according to the embedding context (which would use the same syntax "{{GRAMMAR:set|mark|value}}" to set a context just before embedding "$1", and could remove it just after with "{{GRAMMAR:set|mark|value}}$1{{GRAMMAR:unset|mark}}": contexts are then evaluated from start to end as a dictionnary of small variables that can be passed on.

It could be used as well for other classifications of terms (such as "animated", "inanimated", or other lexical classes used in some African languages), allowing to properly select pronouns used for backward/forward references to the term elsewhere in the sentence.

(this is a generalization of the syntax for plural forms; the syntax proposed here is for completeness, there may be some additional shortcuts; including for the existing "plural" mark, or as an alternative when it cannot work reliably).

@Verdy_p please open a new task for this. Let me know if you need help.