Talk:Reading/Web/Archive 1

Extension:MobileFrontend vs. Mobile_Web

Hello, it's not immediately clear how the pages Extension:MobileFrontend vs. Mobile_Web relate to each other. I guess Extension:MobileFrontend is the "product" of the Mobile_Web team. It would be helpful if there were clear links from one to the other! Bjoern (talk) 16:31, 5 January 2015 (UTC)

Agreed. Hopefully it makes more sense now Bjoern Jdlrobson (talk) 21:05, 11 January 2015 (UTC)

Thanks! Bjoern (talk) 00:18, 12 January 2015 (UTC)

concerning about article size transfer to the reader

Hello, sorry if this question is in the wrong place and for my bad english. Recently, ptwiki havê been discussing what would be an ideal size for an article in kilobytes to a user friend experience. We have some articles with a file size of 900kB and we don't know if it's too big to mobile transfers. Should we worry about that? CAN anyone help? Thanks!OTAVIO1981 (talk) 02:46, 3 April 2015 (UTC)

It depends how they are embedded in the page. If you use thumbnails, bear in mind that 320px is a typical mobile screen size so anything larger than that will be wasteful. I wouldn't worry too much about this talk - this is something the software should take care of and you shouldn't have to think about :-) We have some ideas about drastically improving the speed of page loads in mobile which we hope to experiment with in the next month or two.Jdlrobson (talk) 19:54, 6 April 2015 (UTC)

Configuring the Wikipedia Home page

When viewing cy-Wikipedia (Welsh) on a mobile, the search window is missing. Home page is here. Any links to instructions, please? Llywelyn2000 (talk) 08:15, 13 May 2015 (UTC)

MobileFrontend fiefdom saga

It's clear that discussing the matter directly is pointless, but I'd like to add some links to past efforts given [1] proves the MobileFrontend maintainers have not yet given up on abusing the extension to bypass consensus, policy, code review and so on. Nemo 10:47, 15 May 2016 (UTC)

• phabricator:T55069 (there should be more: [2] [3])
• The separate world of Mobile
• phabricator:T106463/phabricator:T71366

phabricator:tag/Reading-Web-Local-Wiki-Issues

This tag has a very unclear descripion. As far as I can understand, it was supposed to be about issues with MobileFrontend which depend on some wiki-specific situation, such as local JavaScript/CSS, templates or other content. Now however some read it as being about any and all issues with Common.css, Common.js, local gadget code etc. --Nemo 14:28, 28 April 2017 (UTC)

I can clarify the tag accordingly and mention the existing ones to reduce overlap. I'd also link Reading/Component responsibility, which lists the areas where one can expect some interest/help or not. --Nemo 09:38, 3 May 2017 (UTC)

Given the lack of objections, I've clarified the project description. I've also removed the existing names because they're misleading (and more appropriate for other tags). Let's see if usage of the tag improves. --Nemo 11:17, 8 May 2017 (UTC)

Jon helped clarify that they also care about the impact on the apps (presumably via the various mobile APIs such as mobileformat, mobileview, TextExtracts?), thanks! I restored "wiki-specific" however, since it's about issues which don't happen on any and all MediaWiki wikis and "local wiki" is too easily misunderstood to be about any local wiki issues which have nothing to do with mobile. --Nemo 09:04, 29 May 2017 (UTC)

The prefix `Reading-Web-` is used here which should communicate this is an internal tag. There should be no reason to use this if you are not part of the reading web team. Jdlrobson (talk) 17:20, 30 May 2017 (UTC)

It tends to be not so clear to people what falls within the scope of a specific team, so it happened that the tag was added to very generic tasks. Having a precise description always helps, but avoiding overly generic alternative tag names is also useful.

Components are typically defined by where the code resides, rather than by process: if a project means "team X thinks Y of this task", then it should normally be a tag (yellow) or other non-component project, and each task would have a component to indicate where the change needs to happen (e.g. MobileFrontend, or core, or other). --Nemo 18:56, 31 May 2017 (UTC)