Talk:Reading/Web/Projects/Mobile Page Issues

Jump to navigation Jump to search

About this board

Please give us feedback on your thoughts regarding this project so we can change and improve it. Each language is welcome in this discussion!

TheDJ (talkcontribs)

This is a brain dump of some of the (semantic) properties of Message boxes as I see it:

  • This is a notice (i don't like the 'issue' terminology)
  • A notice can be page level or section level (latter mostly indicated by the toggle 'small')
  • The notice has a severity. This is currently triggered by type and translated into a visual style.
  • The notice has a type. This type generally groups the type of actions or behaviour it expects of the reader (do something, watch out for something, modify the text etc)
  • The notice has a page type (intended namespace). This dictates the visual style.
  • The notice has information (mbox-text, freeform)
  • The information has an intended audience (user group, often implicit)
  • The notice sometimes has a terse version of this information (xbox-text minus hide-when compact)
  • Optional properties like:
    • A 'date added'
    • The creator (nominated for deletion by)
    • A deadline after which it is no longer valid
    • actions (links for admins to do things for instance. Actions are often audience/user group specific)
    • An image that overrides the images provided by the type/severity
    • A decorative 2ndary image
    • Various categories to be applied to pages
    • A position (both stub templates and deletion notices are page level, but they are at different locations within the presentation, dictated by where the template was added in the wikitext)
  • A notice can indicate it is a group of other notices. (Not sure what to do with this)
  • A hatnote is essentially a notice too, even though it is not a message box...
  • Edit notices are also notices, but in a different view of the page..... hmmm.
OVasileva (WMF) (talkcontribs)

Hi - thanks for writing this up! A couple of notes from our side:

  • I agree on the terminology but "notice" is already an ambox type so I'm afraid that might cause some confusion. It was called "warning template" in the RfC but that sounds even more threatening in my opinion. We're brainstorming finding something to name these that is both accurate as well as recognizable.
  • for the first part of this project we're only looking at page level issues/notices

The remainder - we're considering some of properties you identified - severity, template, template type (at least for amboxes). Others we're hoping to improve on once we have template styles.

Reply to "Semantics"

A common solution for all languages: Extension

Amire80 (talkcontribs)

On this page there is not a lot of discussion about the fact that these templates are different in each language. Also, there's no discussion at all about the fact that these templates are visual and not semantic: to an experienced edmitor in a given language each of them is meaningful, but to the MediaWiki software each of them is just one of out thousands of other templates.

These are the actual root causes for the difficulties of handling them.

MobileFrontend relies of the design of English Wikipedia's Ambox templates. This obviously doesn't work for other languages.

A better solution would be to give communities guidelines for using some common code in templates of this kind, for example HTML classes. This is far from being robust, because it relies on presence of people who know how to use HTML classes and who read user manuals in each of the 800+ wikis.

The real solution would be to make an extension that stores metadata of this kind about the article—unreferenced, notability, style, perhaps also "stub". Customizations for each language should probably be possible, but a basic set of "page issues" could be made that covers most languages' and sites' common needs. When we have this as an extension, MediaWiki would be able to read this information meaningfully, and present it appropriately on desktop, mobile and elsewhere. Editors would be able to change them in a more convenient and structured way, instead of memorizing template names.

This is the discussion that we really should be having, instead of hacking MobileFrontend around the current local templates in each wiki.

Saint Johann (talkcontribs)

Your better solution was quite enough. Having another extension that can be supported only by a handful of developers and will be enforcing a strict model for such templates among the languages without the consent of their communities is not the best way to go. Template extensions are incredibly bad for a handful of reasons: they are non-customisable and supported only by WMF or especially zealous volunteers because the code is shut away in an environment that one must first learn themselves.

The experience of extensions like Babel shows that we should make less extensions of such kind, not more. If you want a best solution, have WMF developers do customisable, non-invasive, configurable modules. It would be a lot better than building an extension, because then the tasks about simplest things that are wrong with those extensions won’t have to be waited for long, long time to be acted upon.

Amire80 (talkcontribs)

An extension has advantages that a template doesn't have: proper internationalization, ease of installation on any wiki site, uniform functionality. And no, "uniform" doesn't necessarily mean "strict", as you say.

The clear advantage of a template is that it's easy for community members on a local wiki to update. Other than that, they are highly problematic. (Making templates easily reusable across projects would make them much better, however.)

If extensions were as easy for all community members to update as templates are now, without having to go through the current long and difficult cycle of review and deployment, this wouldn't be a problem at all. That's exactly what I'm talking about towards the end (1:04:14) of my interview on WikiJabber.

(I am intentionally saying "review and deployment", and not "development". Evidently, development is not a problem—the more active communities are clearly capable at developing templates in wiki syntax and modules in Lua. The fact that extensions are in PHP and JavaScript and templates are in wiki syntax and Lua is not a problem at all. In fact, extensions' initialization code has to be in PHP, but that's easy boilerplate code, and the functional parts of extensions can already be written also in Lua. I don't know why isn't it practiced more than it is now. So the programming language is really not an issue.)

As for Babel, it's a funny example. Clearly it's better to manage one extension than a set of literally thousands of the same templates in hundreds of projects. But what's particularly funny about Babel is that if you look at its history and documentation you see how strongly it tried to emulate what templates on projects are doing. This resulted in the need to write hundreds of lines in the server configuration files. Look at InitialiseSettings.php, search for wmgBabelCategoryNames. You'll find hundreds of repetitive lines that could be made default. So Babel emulated the functionality of "User xx" categories and Babelbox templates appearance on user pages too closely instead of doing what it really should have done: create a way to store metadata about a user with a list of languages that they know, and let other parts of the software do whatever is needed, for example show a box on a userpage, add a page to a category, etc.

And that's why I propose an extension that stores metadata about a page, which would be available for any use.

TheDJ (talkcontribs)

> these templates are visual and not semantic

Well yes and no.. each mbox has a page/contenttype (tmbox,fmbox,ambox etc) and a notice type. There is already some semantics in that combination, and these dictate the styling (so not the other way around). At least that is what it is supposed to be and thats how we designed it back in 2008. "hide when compact", which was added to that later on indeed is a bit of a hack. mbox-inside denotes a grouping of mboxes

I think this can definitely be improved, but I'm not in favor of an extension, mostly because of what Saint Johann says. Annotations perhaps. But making a MediaWiki:PageIssues.json that describes the semantics for each language (a bit like citations templates are described for Citoid) seems most viable and effective to me. Especially since these all are generated by templates, it should be easy to have some basic in place, and then create extra options to 'enhance' the mobile results.

Amire80 (talkcontribs)

@TheDJ, they are "semantic" only on one wiki, and they are not semantic to the software that processes them. If I understand correctly, the English Wikipedia templates were made "semantic" to MobileFrontend, but this doesn't scale to all Wikimedia projects, let alone non-Wikimedia wikis.

The need to prepare separate Citoid configurations for each wiki is a symptom of the same problem: things that should have been global and default are made local per wiki for no good reason. You can say, of course, that the reason is that for many people it's too hard to push an extension through the exhausting review and deployment cycle, and it's even true, but it's not a good reason.

TheDJ (talkcontribs)

Past experiences show that dealing with reality tends to end better, than grand schemes that are consequently rejected by all the majors wikis as being inflexible and disruptive to their processes. The flexibility of wikitext (structure, and the HTML it can generate) is a feature after all. It's a terrible feature from a design and software perspective, but a feature none the less and it's heavily ingrained in the userbase.

Once you have a good json design, you can even add default implementation and UI for those who have NOT provided their own templates, effectively moving the other group to an 'opt-out' state from the default software and creating huge benefit to smaller wiki's (although this follow through seems particularly lacking often). And i'm totally in favour of putting actual semantic definitions in an extension (how else would you read that json file) as well as adding parser functions that allow this extension to consume some of the information.

But we shouldn't forget the incredible amount of domain knowledge you would have to capture in an extension in order for it to effectively displace even 50% of the constructs that wikis have in place right now. And the further you get, the harder it will be (we see the same issue with TemplateData for instance). This creates a huge transition problem where often you can't switch to something new unless everything can move to the new methodology. And that is very unlikely to be the case within a year or so, you might even find out half way you built the wrong thing. In my opinion it is therefore important to design any solution to be so flexible that it can coexist with the current implementation.

Reply to "A common solution for all languages: Extension"
Nami-ja (talkcontribs)


In the beginning, why do not you pose various problems on mobile?


In the Japanese version, I saw a case where many mobile users are blocked as vandalism not responding to dialogue.


However, I do not think Wikipedia itself wants that many mobile users will be excluded from Wikipedia.

Malyacko (talkcontribs)

Hi, thanks for your comment. Could you explain how this is related to technical issues which happen on mobile pages? What does "pose various problems on mobile" mean? Thanks!

Reply to "Mobile users can not talk?"
脂肪酸钠 (talkcontribs)


When in mobile view, the 'question-text' in <quiz> will overflow.

Reply to "About <quiz> of mobile view."
Dave Braunschweig (talkcontribs)

What I haven't seen mentioned so far is the difference between screen sizes vs. a generic mobile vs. desktop discussion. An iPad Pro has a mobile operating system, but has much better screen size and resolution than most of the "desktop" devices I use. Rather than optimizing for "mobile", we should be optimizing for screen or window size. I only know enough about responsive design to be dangerous, but I believe this should be a responsive design discussion rather than a mobile design discussion. If we're going to invest the effort, we should create something that works with media queries and addresses all devices rather than just "mobile".

Reply to "Responsive Design"
Tpt (talkcontribs)

Instead of using RDFa it would probably be easier to use Microdata (W3C spec). It's an HTML extension that follows the same goal as RDFa and is more used on the web[1]. The big advantage of using it is that the MediaWiki parser already supports Microdata tags so no change to the parser would be required to implement such system. It is already used by a few wiki to embed easily machine readable data in wiki pages. It also has the advantage of not conflicting with the Parsoid HTML output that is using RDFa for annotations (e.g. to tag that a node is a template call...)..

You may also want to have a look at that is a project endorsed by W3C and run by search engine companies to create a shared vocabulary for RDFa/Microdata/Embedded JSON-LD.

Reply to "Microdata"
There are no older topics