https://bugzilla.wikimedia.org/show_bug.cgi?id=46306

Philippe Verdy <verd...@wanadoo.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |verd...@wanadoo.fr

--- Comment #112 from Philippe Verdy <verd...@wanadoo.fr> ---
So apparently what is wanted is:
* Possibility for users to disable ULS completely:
  - This can be made temporarily for the session (including for non-loggeg in
users
  - the ULS icon disappears
  - on page refresh, the ULS javascript is no longer loaded of it is just a
stub
  - For logged in users, the ULS feature is within the Gadgets preferences
* With URL still ebabled, we can disable each of its 5 features (keeping its
associated settings)
  - disable the icon at the top: the gadget preferens are still accessible in
user preferences or by following a link that allows reopenng the ULS dialog to
reenable the icon
  - diable/enable input methods assistants
  - diable/enable per-langage font overrides (all languages in one operation,
but keep their settings so that we can enable them again without having to
reconfigure them all)
  - disable only webfonts (per-language font overrides may continue to work if
they are effective, but users may have to install these fonts); this includes
the Autonym font

But I don't see any point for enabling/disabling the user language selection if
ULS is still active, even uf the icon is hidden at top of page. It is a grear
thing that we can switch the UI lanuage without having to visit the full User
prefenreces pages: two clicks for switching.

For non logged-in users, the possibility of switching the UI language is a key
feature, notably on multilingual sites like Commons, Incubator, and Beta
Wikiversity.

But the UI language selection is not really a key feature of ULS, it just
offers a smart dialog equivalent to the Language selection combobox of the user
preferences. For this reason I think it should be kept (and probably the icon
at top of page too).

And yes trying to reduce the footprint of ULS in terms of bandwidth added to
load a page should be a priority (but this is not exclusive to ULS, other
gadgets or accessibility features (often very desirable) should be minimized as
well.

There's only one situation where ULS should be disabled completely in user
preferenes within Gadgets: incompatibilities or problems with the user's own
assistive technologies (using external tools, e.g. Braille readers) or some
security tools (that may filter some javascripts conditionnally, or could
modify them on the flow so that they could be broken) or form input assistants
(e.g. password fillers...= or when it causes compatibility problems with some
simpler devices (e.g. on some smart TVs or settop boxes, or smartphones, that
embed a basic web browser often full of bugs and never updated, such as Opera
Mini, or Opera Embedded, or Basic Android browser).

Note that for smartphones, Wikimedia may offer a mobile version of the wiki
which uses a simpler interface. In //*.m.wikipedia.org for example UTL cannot
work, even if users are logged in, but the mobile version requires another ULS
implementation. But mobiles visitings the mobile version of the wiki still have
the option to visit the web version, and the web version should continue to
work, and ULS should not add too much fullprint;

You don't need to live in rural thirld world area to test this: use a basic
Android smartphone to connect via a Wifi hotspot (NOT Wifi N or not connected
to a fast broadband), then look with an indoor 3G+/HSDPA connection (which may
switch to 3G/UMTS or even to 2G+/EDGE or 2G/GPRS with poor reception)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to