Topic on Talk:Reading/Web/Projects/Mobile Page Issues/Flow

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.

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.

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.

> 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.

@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.

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.

Strict and predefined matters in a global implementation are fine for basic and technical things, and unanimous abstraction of generic features.

However, things like unreferenced, notability, stub and more are far off from a common view of all wiki projects. There are very different needs of a wikisource, a wiktionary or a wikipedia on such topics, and a very different policy of each community. Some need even more and are left unsatisfied, some might not require any.

Areas like discussed here are highly dependant of the community view, and they are a bad subject for reusability across projects. The level is very close to individual decisions about content rather than a basic level of agreed technical support. Extensions and other global implementations should limit themselves to support generic tasks, not ask for preoccupation of high level editorial issues.

Is the "Unreferenced" template deeply and conceptually different in English, Russian, and French?

I understand that the template implementation may be a little different, and that the text may be a little different, too. I also understand that different communities may have somewhat different policies about what to consider "unreferenced".

But non of this is a reason not to have a generic global way to store metadata about an article that would have an "unreferenced" field. It's up to the communities how will they use it. But for machines there would a cross-wiki way to know that there's something to show.

Think also about a new wiki that is starting. Maybe they want completely different policies. If they want different policies, it's fine. But what actually happens is that a lot wikis import a bunch of templates from a language they know best, usually English, Spanish, French, or Russian. This makes things work superficially, but it is very time-consuming for new communities, which could invest their time in writing articles instead of importing templates, and it creates a lot of forks of code that is basically the same.

The concept how to deal with Unreferenced is very different between projects.

• On English Wikipedia there is a citation needed template at micro level, and an expectation what shall happen and how important that is.
• On German Wikipedia there is nothing like that on statement level, but on page or section level. Furthermore I presume that classification of importance differs.
• For a Wikisource this is quite meaningless in general, perhaps in a discussion.
• Same for Commons or our current host MediaWikiWiki.

The global idea that something is felt to require a citation source does not map globally on presentation level. But handling presentation is the outcome of this “common solution for all languages” and the question how to present important things on a mobile (what the embedding task is about). BTW it is not per language, but per project community.

A global assignment of “unreferenced” would result in patronizing the wiki projects since it defines the presentation level how attracting such things shall be displayed. That means your Extension will make the decision for the wiki communities how they are to handle and focus on unreferenced issues, or any other thematic question.

A global software product is only permitted to offer a scale of very important, important, less important, normal, not interesting things and present all down to a certain level. It is not upon a global software support to force how to deal with encyclopedic statements perhaps not based on sufficient sources.

I'm not suggesting anything that will "force how to deal with encyclopedic statements". I only suggest a global way to store and read pieces of article metadata. An "unreferenced" flag may be one of these pieces. What do communities actually do with this is up to them.

The fact is that more than 100 Wikipedias have an "unreferenced" template. This means that it was manually copied more than 100 times.

To compare, the policy about blocking users is also different in every wiki, but the blocking functionality is available everywhere as part of the software.

Blocking is part of Mediawiki software. It causes actions on server when IP or registered are attempting something.

Unreferenced is not a part of Mediawiki software. It has no consequences at all. It is not business of the software to deal with this situation. It is an editorial affair of content, and does not tell much whether really citation needed or even appropriate.

Templates are not a part of the MediaWiki software, but they are software. They are just implemented in a way that cannot be conveniently ported from one wiki to another. Sometimes it's not useful to reuse templates on many wikis. Sometimes it is. In case of Unreferenced, it's useful.

The fact that the unreferenced templates are not a part of the MediaWiki software now doesn't mean that they shouldn't be.

They shouldn’t be. They are neither an issue for MediaWiki core nor for a MediaWiki extension, but a decision and implementation of the local wiki and depend on a policy and processes which the local community has to agree upon first before establishing any mechanism.

And yet, the question is asked here by the developers how to deal with them on the mobile platform. Why should it have a completely different answer in every language?

And perhaps more importantly, why should each Wikipedia in a small languages have to reinvent it? Isn't their time better spent in writing actual articles than in maintaining a fork of a template that could be maintained centrally? It's a privilege to say "they shouldn't be easy to port to new languages" when you are editing in a wiki that already has them. Not everybody has this privilege.

Again, it is not a matter of any “language”, it is a matter of a community decision, and a French Wikisource might deal entirely different with an “unreferenced” situation as the French Wikinews, since for a Wikisource mainspace “unreferenced” is absolutely nonsense, but a Wikipedia has again an entirely different view on this, and on Commons or MedaWikiWiki your personal view is again stupid, and for some namespaces out of main space some views might be a bit interesting but not much.

And again, German Wikipedia community is dealing with “unreferenced” absolutely different than English Wikipedia does, and will refuse that you or your Extension or any MediaWiki developer attempts to patronize them and to set up global rules how any project has to deal with any matter of content. You are trying to force projects to follow your personal ideas how they are obliged and focus on certain things. This is not how wikis are working.

Developers asked how to present very urgent or very important or important or normal or less interesting things. This is fine, and they might support by framework. The judgement, what is how important is not up to you nor up to your “Extension” nor does any term of content, but the mapping is up to every single community who are to decide first which issues really matter for them and how they organize maintenance and community processes and which points they want to focus on and where to attract attention of readers.

EOD.

It appears, sadly, that we are talking about different things. At no point have I suggested anything that will judge what to do, but only a way to store relevant metadata about wiki pages, which will be readable in a uniform way.