Last modified: 2014-06-05 10:50:28 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T18119, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 16119 - Add $wgSpecialPageAliases similarly to $wgNamespaceAliases
Add $wgSpecialPageAliases similarly to $wgNamespaceAliases
Status: NEW
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
1.14.x
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-25 23:11 UTC by Danny B.
Modified: 2014-06-05 10:50 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Danny B. 2008-10-25 23:11:28 UTC
MediaWiki allows to make aliases for special pages. However, these aliases can be only hardcoded in software and can't be supplemented with additional aliases nor any conflicting alias can be removed.

Typical issue from WMF projects:
Main namespace is called "article", "book", "module", "word", "news-article" or so. Now you have say Special:UncategorizedPages - that would be UncategorizedArticles, UncategorizedBooks, UncategorizedModules, UncategorizedWords, UncategorizedNews-Articles etc... Users are called Users, Wikipedians, Redactors etc. -> ListUsers, ListWikipedians, ListRedactors... And many other examples... This is of course much more obvious in other languages than English.

It would be practical to have some additional page to Special:AllMessages similar to http://translatewiki.net/wiki/Special:AdvancedTranslate?module=special&language=en available for admins or bureaucrats or any specially designed group, where local names can be set easily without necessity to hack the code.

----

(Maybe even full http://translatewiki.net/wiki/Special:AdvancedTranslate would be handy, but that would be either to open new bug or change the summary of this one, however, other translations are much more stable and universal than special pages, since you can change the special page title on Special:AllMessages)
Comment 1 Niklas Laxström 2008-10-26 15:37:40 UTC
I do not find this very desirable. We should get rid of the SomePagesWithConditionInNamespaceFoo pages, and only general term for pages in all namespaces is page. In addition the titles of the pages can already be changed, just not the names in the url.
Comment 2 Siebrand Mazeland 2008-10-26 17:36:43 UTC
Keyword accessibility removed ("Blocks the accessibility of a wiki (e.g. to blind or partially-sighted people, screen readers, etc.)")
Comment 3 Danny B. 2008-10-27 16:47:28 UTC
(In reply to comment #1)
> I do not find this very desirable. We should get rid of the
> SomePagesWithConditionInNamespaceFoo pages, and only general term for pages in
> all namespaces is page. In addition the titles of the pages can already be
> changed, just not the names in the url.
> 

That was just an example, since it's the most obvious one. Besides (it has already been discussed elsewhere) you can not have one general page for all namespaces in some cases (typical example: WantedTemplates - that lists _inclusions_ of such templates, while WantedPages lists _links_ to such pages.) However this is subject of other discussion.

Please keep in mind, that not only Wikimedia projects use MediaWiki. And other wikis would like to customize their stuff without hacking the code. One example from recent past: Some people turned to me asking me to help with the configuration and one of the tasks was - they did not want to call categories "Category" but either "Tag" or "Keyword". Now that meant to rename all stuff to WantedTags, UntaggedPages etc. Yes, via Spacial:AllMessages you can simply override page title, but without hacking the code you can not override the local special page name (namespace names as well, but that's relatively easily configurable in LocalSettings).

And still - even if we had one page per purpose with namespace selector, we are back to the same problem - even if we had Special:Uncategorized (thus no UncategorizedPages, UncategorizedTemplates, UncategorizedCategories...), still in this case it would be necessary to rename the local special page name to Special:Untagged. So your suggestion has nothing in common with this bug.

The deal is - if we allow easily to rename page title, we should allow to easily rename the page URL as well to keep it consistent. QED.
Comment 4 Ilmari Karonen 2008-10-27 17:16:41 UTC
To turn categories into "tags" properly, you're going to have to add a namespace alias anyway.  Adding some special page aliases while you're at it doesn't seem too hard.
Comment 5 Niklas Laxström 2008-10-27 17:20:04 UTC
(In reply to comment #3)
> The deal is - if we allow easily to rename page title, we should allow to
> easily rename the page URL as well to keep it consistent. QED.

I don't agree with this, but it is just me.

Changing them is already possible with some configuration:

$wgHooks['LanguageGetSpecialPageAliases'][] = 'myFunction';
function myFunction( $aliasArray, $code ) {
        array_unshift( $aliasArray['Allpages'], 'All_tables'  );
        return true;
}
Comment 6 Danny B. 2008-10-27 20:03:58 UTC
(In reply to comment #5)
> (In reply to comment #3)
> > The deal is - if we allow easily to rename page title, we should allow to
> > easily rename the page URL as well to keep it consistent. QED.
> 
> I don't agree with this, but it is just me.
> 
> Changing them is already possible with some configuration:
> 
> $wgHooks['LanguageGetSpecialPageAliases'][] = 'myFunction';
> function myFunction( $aliasArray, $code ) {
>         array_unshift( $aliasArray['Allpages'], 'All_tables'  );
>         return true;
> }
> 

Keep in mind, not every sysop/bureaucrat has shell access.

Also, is that hack documented somewhere? And I do not consider it easy. Easy is $variable = "value"; in LocalSettings.
Comment 7 Ilmari Karonen 2008-10-27 20:34:34 UTC
Any random sysops/bureaucrats should _not_ be changing namespace names.  This is a wiki configuration issue, not just interface eye candy.

Yes, there should be an easier way to add local special page aliases.  "$variable = 'value'; in LocalSettings" sounds just about right.
Comment 8 Danny B. 2008-10-27 20:44:12 UTC
(In reply to comment #7)
> Any random sysops/bureaucrats should _not_ be changing namespace names.  This
> is a wiki configuration issue, not just interface eye candy.
> 
> Yes, there should be an easier way to add local special page aliases. 
> "$variable = 'value'; in LocalSettings" sounds just about right.
> 

Who is talking about namespaces here? This bug is about special pages aliases.
Comment 9 Ilmari Karonen 2008-10-27 20:53:58 UTC
(In reply to comment #8)
> 
> Who is talking about namespaces here? This bug is about special pages aliases.

You were, in comment #3, where you brought up the use case of wanting to consistently rename the "Category" namespace to "Tag".  My point was that, since you need to tweak LocalSetting for that anyway, it shouldn't be too hard to add aliases for any relevant special pages at the same time as well.

Except that there definitely should be an easier way to do that than writing a custom hook function.  Something like

  $wgSpecialPageAliases['Allpages'] = 'All_tables';

in LocalSettings.php would sound like reasonable syntax to me.
Comment 10 Nemo 2014-06-05 10:50:28 UTC
(In reply to Ilmari Karonen from comment #9)
> Except that there definitely should be an easier way to do that than writing
> a custom hook function.  Something like
> 
>   $wgSpecialPageAliases['Allpages'] = 'All_tables';
> 
> in LocalSettings.php would sound like reasonable syntax to me.

Reflected this conclusion in bug summary.
However, $wgNamespaceAliases doesn't supplant the "top" name of a language, it only adds a redirect. Given that there is a 4 lines configuration solution in comment 5, this may be considered a WORKSFORME.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links