https://bugzilla.wikimedia.org/show_bug.cgi?id=46306
Philippe Verdy <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #112 from Philippe Verdy <[email protected]> --- 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 [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
