Per T275894, Readers Web intend to increase the scope of the
UniversalLanguageSelector instrument to help them understand how
users are interacting with the Languages list in sidebar.
In order to keep the UniversalLanguageSelector extension focussed and
not overly Wikimedia-specific, it was agreed that the instrument would
be migrated to the WikimediaEvents extension, where other such
instruments are located.
Therefore, remove all code related to the UniversalLanguageSelector
instrument.
Bug: T275894
Depends-On: I2acee8ba8dc59c497dc6ba42cd5bd88dfd985c8b
Change-Id: I72b1d0ff35488521b3499e9606efee26baff8c00
Light refactor of existing code into reusable method to support
this.
Use Extension attributes to allow skins to provide ULS
additional configuration.
Bug: T274396
Change-Id: I7dcd49f05fae83fbc0c15768bee8ca93eab17bcc
This provides an alternative mechanism to
I0518ecdf402ebf5eb6bad2c430f6462322c0d8e1 for loading the compact
language link module. Instead of relying on the client, the HTML
is inspected.
Bug: T264824
Change-Id: I977a998388b3e70f7fe4d97fa05be3c1ac1bf676
Example usage:
Iabd4688c6081b4de391b9655b92a16f3a414e018
We will skip loading the compact link if we don't need
to compact the languages.
Note special handling is known for Timeless which stops
propagation of events. This will be fixed in Timeless at a
later date.
Bug: T264824
Change-Id: I0518ecdf402ebf5eb6bad2c430f6462322c0d8e1
These are disabled by default and on production. They are only enabled
in the beta cluster, which is not needed.
Change-Id: Ifa847fd8a1f3d7d2695a7c1c4a1a93f136091604
Previously UniversalLanguageSelector relied on the targets system
meaning the modules ext.uls.interface,
ext.uls.interlanguage and ext.uls.pt were
loaded on Minerva desktop skin unnecessarily and silently removed
on MobileFrontend which throws a warning.
Instead of doing this, check the skin
Bug: T237036
Bug: T235712
Change-Id: Ib38b041533cf959c3c4c30decc65869995c254fa
During MLEB 2020.07 release testing noticed that if $wgULSPosition
is interlanguage, the ULS was not appearing.
Revert some of the changes introduced in
I2843edde1bb45c70911d5acf2f7dafdff3bac53e to fix this
Tested this change on,
1. MW 1.34, Timeless (1b22886)
2. MW 1.34, Vector (f39a3f0)
3. MW 1.36, Timeless (e5e188f)
4. MW 1.36, Vector (3926ffa)
ULS appears in all scenarios
Change-Id: I84feaed26c4e32d74ae90152a2d006648d4d9b64
Instead use SkinAfterPortlet to force the language portal
to always display. This will work with all Wikimedia deployed skins that
use ULS (note the Minerva skin is not impacted but in future can benefit
from this change)
Depends-On: I438daa79d3d97e2518e6258c3213a805bd1f30e8
Bug: T253178
Change-Id: I2843edde1bb45c70911d5acf2f7dafdff3bac53e
As this extension supports MW 1.34 (and MW 1.33) in the master
branch, apply the usual ternary PHP registration and ternary
tricks.
Bug: T233676
Change-Id: I4d18bab53460b397d4f50485c4a149185a1db7b3
This change allows to use the ULS language changer without getting a
dialog for restoring the old language.
This change requires that the module is also loaded in this case.
Change-Id: Ie5169e986d0362034ede122b0bc29ce7a4aa481e
ULS currently supports MediaWiki 1.32+ which supports PHP 7.0+.
This change can reverted when the minimum required MediaWiki version is
1.34+.
Change-Id: I8115c4ae74c8aa91899899b1fb304ccbf1066ad8
setlang will now display a dialog to confirm with the user that
they would like to change their interface language. The preferred
language will only be updated if the user confirms.
The dialog will be displayed if the setlang parameter is present in
the query string and,
* A user is logged in, and their preferred language is not the same
as the one passed via setlang.
* For an anonymous user if the wgULSAnonCanChangeLanguage is true,
and the current interface language is not the same as the one
passed via setlang.
Bug: T63115
Change-Id: I882297d99a594fd82fd0aec3b4664e8bfd1eac3a
MediaWiki 1.33 is released. The next version MLEB 2019.07 will be
compatible with MediaWiki 1.32 and 1.33.
Change-Id: I9487706125fe84d02cb8d3fec0a10e1f10006e64
This could've been done longer ago (by defining ext.uls.common
in Hooks.php), but didn't notice it before.
The ext.uls.eventlogger was (if configured) loaded on all page
loads. Same as ext.uls.init (but without config condition).
ext.uls.ext is an empty shim around ext.uls.common, which is thus
also loaded on all pages. Merge this into there given has no
reason for being its own module. They are always loaded together.
Change-Id: Icdda6f27470a1d56a37275164c06541514a488a0
The modules 'ext.uls.init'/'ext.uls.common' provides only a library and
no own funtionality. The modules get automatically loaded through
dependencies by other modules when needed as library. An explicit
loading on all page is not necessary. For example the MediaWiki API
help page does not have any ULS elements.
Bug: T145186
Change-Id: Ida99704ca2846e6adf154255bee3148e80c957d8
Given the code no longer uses any EventLogging methods directly,
but rather mw.track(), this means it also doesn't need to declare
any dependencies, including for older MediaWiki versions this
will work as-is.
Change-Id: I8cdcef54321d0887c509fc3683acf132c113e628
