Add fallback lookup based on the interface language to
Special:MyLanguage. Lookup order:
<user lang> -> <explicit lang> -> <fallback lang(s)> -> <base>
Example when the user's lang is arz:
arz -> <explicit lang> -> ar -> en -> <base>
Bug: T50292
Change-Id: I245cab71fdd4b4585f86dde808493cd69841b09a
With the change, named in Follow up, it's possible for site owners to
allow to change the language of a page using a special page.
Theoretically, any page can have another or a different page language,
depending on, if the language was changed using the special page or not.
For Special:MyLanguage it isn't enough anymore to check, if the current
user language is the same as the default content language. It has to
check, if the page language (which can potentionally differ from the
default content language) is the same as the user language.
The problem:
If content language is the same as the user language, Special:MyLanguage
currently redirects to the "base page" of a page ("Testpage" instead of
"Testpage/de"), no matter, if the page language of the base part is
another one as the default content language. This can result in the
problem, that Special:MyLanguage redirects to a page, that has a
different language as the user language, even if a subpage with the user
language code exists. This is fixed with this change.
Follow up: I0f82b146fbe948f917c1
Bug: T121834
Change-Id: Ic9fc9049813c153111829d37a2c248dc0768e0fb
This prevents a malicious person from using external resources on their
website to cause the victim's web browser to load
Special:MyPage -> User:Username, and then looking it up in the page hit
statistics in order to correlate IPs from the malicious person's server
log, with usernames on wiki.
This feature can be disabled with $wgHideIdentifiableRedirects.
Bug: T109724
Signed-off-by: Chad Horohoe <chadh@wikimedia.org>
Change-Id: Ia0e742dc92c77af4832174dfa24c6dcaa6ee80e9
$subpage being null is clearly documented in SpecialPage::run,
SpecialPage::execute, and most special page subclasses.
But all the redirect subclasses only copied part of the typehint,
making it look like it's always a string.
For SpecialMyLanguage, follows-up b1853bba0. Don't cast null to
empty string, and don't bother giving Title::newFromText an empty
string only to bail out with null again.
Also:
* Add visibility 'public' where missing.
* Add or correct relevant documentation comments.
* In SpecialMyRedirectPages, handle error first and avoid having
final return inside a conditional; Remove redunant 'else'.
Change-Id: Ie3543f44011832b198bb3d3e32528b6a2868dee1
Currently if you have a link that goes through SpecialMyLanguage
and that page is redirected you will no longer get it in your
language. This adjusts to follow redirects before resolving language.
Bug: T58036
Change-Id: I88fcfeb86d81a33a8eccc6119693c2ecb857afb2
* Fixes "Exception from line 339 of languages/Language.php: Language::isValidBuiltInCode must be passed a string, boolean given"
Change-Id: I546998fe89261f3012fa404578d5684c7ddf59a5
- Swap "$variable type" to "type $variable"
- Added missing types
- Fixed spacing inside docs
- Makes beginning of @param/@return/@var/@throws in capital
- Changed some types to match the more common spelling
Change-Id: Ie419638e909a47aa72a274043604247830ee1a81
In practice, this means the MediaWiki canonical way to uniquely and
humanly name translation pages on a multilingual wiki becomes
$source_page_title + '/' + $target_language_code, irrespective of
the enabling of the navigational subtitle and of the relative
titles (..) syntax for linking and transcluding, which are unrelated
and keep being controlled by $wgNamespacesWithSubpages.
This syntax has been prevalent on most wikis including mediawiki.org
since at least 2009, also thanks to #titleparts in ParserFunctions.
The part of the special page's functionality that made links to it red
when destination page wasn't present will be integrated with a follow-up
commit because they require more performance work.
I'm also including some Title tests that were written for testing the
redlinking functionality but are useful in general.
Bug: 66762
Change-Id: I520077c931431b5919e0208f75c20b5b25f3159d
