I've added the maxvals functionality to getValueByLang and the infobox in https://en.wikipedia.org/wiki/GNU_Bison now only shows one value.

@srishakatux The code produced would reside entirely in a module on-wiki, probably developed on Commons (or perhaps enwiki, but that's less likely) and ported to other wikis as required. As we expect editors to deploy the infobox in their native wikis, good documentation is a an essential part of the concept. It certainly looks more like an Outreachy project from my perspective.

In T273109#6781836, @Mike_Peel wrote:

Based on my initial thoughts at T270429. @RexxS might you be interested in being a co-mentor of this project?

Zulip's okay: not my favourite, but I'm used to using it from Google Code-In.

@srishakatux thanks for contacting @Pavithraes - I'm sure she'll be an excellent co-mentor and her skills in technical writing will be invaluable. I understand that it's hard to commit to full-time support for the intern, but I'm sure that whatever time she can give will be greatly appreciated.

Hi folks - sure, I'd be glad to help out, of course. All the materials I used for GCI are available under CC-BY-SA anyway from [[:en:User:RexxS/GCI]] but I can release them as CC-0 if that's easier for anybody to use.

In T248457#6330283, @Iniquity wrote:

There are no sources in your template either, this is not the subject of conversation.

Yes, you could do that and get laughed at. Nobody has said Wikidata adds garbage except you. What happens, though, is that it adds content that may not abide by the local policies and that is a fundamental flaw.

If you don't want to abide by the policies on the English WIkipedia, you need to stop adding content to the English Wikipedia. It's not a difficult concept.

I dispute that the template I created was a strange decision. My action was prompted by the appearance of sub-titles on mobile and app view for the English Wikipedia which were not derived from enwiki content. These sub-titles also appeared as disambiguators for search results on mobile view. Each Wikipedia has its own content policies and unfortunately they often differ between Wikipedias and other sister projects such as Wikidata. These subtitles were being taken from the description field of Wikidata entries, which beside being prone to vandalism, were unable to reference a source for their content. The latter flaw left them prone to violate verifiability and BLP policies which govern all content on a Wikipedia.

In T248457#6006312, @Mike_Peel wrote:

In T248457#6004246, @Alsee wrote:

In T248457#6003779, @Mike_Peel wrote:

I really hope this never happens

There was repeated consensus on this, and if you recall you participated in one. The Foundation handled things badly, but committed to terminating wikidata descriptions when we reached 2 million local descriptions. I expect the result would be Bad all around if the Foundation were to renege.

Yes, my comment there still seems to hold true. "I personally think it is a bad idea and a waste of developer time." Add to that the massive waste of editor time to add those local descriptions, which can't even be copied back to Wikidata due to copyright restrictions. This whole situation sucks.

The reason why The South Pole Telescope has the location "South Pole, Antarctic Treaty area" is that according to Wikidata, the South Pole is not located in Antarctica; it's only located in the administrative territorial entity of the Antarctic Treaty area. That's just a simple mistake in the organisation of Wikidata, and nothing to do with fetching Wikidata for infoboxes. As it stands, no SPARQL query for what's located in Antarctica will give you the South Pole, which is a bit worrying.

In T249565#6035934, @Zaiva_Igor wrote:

Greetings! I see that some of the articles on the WP work, but many of the articles that I wrote or the rules in the last weeks-days are broken, for example, Ross, Malcolm (balloonist). On occasion, as a regular here is not in the know when they will be restored and will they be restored at all? VD fell off. What to do, where to write, who else to ask? I don't know anyone here :( Sorry if there are errors, I do not know English well.

In T184000#6011411, @JeanFred wrote:

In T184000#6007325, @RexxS wrote:

It is unfortunate that Wikidata chose to use prose fragment case, as that never gets used in any application that I'm aware of.

I don’t understand why this would be unfortunate. One can trivially convert prose fragment case to the case you desire (by upper-casing the first letter), while the reverse is not-trivial (one cannot just lower-case the first letter, because it might be a proper noun). Or am I missing something else?

Compared to the 14,986,105 entries with an English label but no English description. How does the bot-added English description "Wikimedia list article" help anyone create a label for Q1831702? or the description "scientific article (publication date: June 2006)" help anyone create a label for Q28242786?

In T184000#6007957, @Bugreporter wrote:

Wikidata description is to be used with labels, so users in Wikidata will see:

set
fundamental mathematical concept related to the notions of belonging or inclusion

Georgia
state of the United States of America

In addition, not all items have an English label, so adding description will let users know what they are.

If you look at a large article with lots of references, the usefulness of seeing the references in preview mode is even more obvious. If you look at

Wikidata is not an application, so I'm not sure of the value of its expectations., I'm unaware of any application that adds the description after the label in the way you describe, Perhaps you can name some examples?

The advice given to editors adding short descriptions on enwiki is to use the same case as would be used in article titles, e.g. "American politician", "Largest city in England", "eBay Founder". Those are the correct case to use on any sub-heading such the search on mobile and the sub-heading on the Wikipedia App. It is unfortunate that Wikidata chose to use prose fragment case, as that never gets used in any application that I'm aware of.

Well it didn't seem to cause a problem for all of the statements imported from the various Wikipedias.

The thing is, Mike, that the descriptions on Wikidata are monolingual. There is a separate description for every language, so it's not a matter of a central repository that can be used across all projects. The Wikidata description field is potentially useful for the corresponding language Wikipedia and the handful of multilingual Wikis, so it really doesn't find as many uses as statements do. Also unlike statements, it is not capable of being linked to a reliable source. so there's no inherent mechanism to promote reliability.

Just a "heads-up" that a search on enwiki articles for hastemplate:"short description" yields 2,083,124 results.

Thanks for the report. I don't think it's urgent or crucial, but it would save some to-and-fro on-wiki as editors change back and forth between the two versions. Since applications that reveal the short description such as the "Wikipedia App" render it immediately below the article title and before any other content, I think it makes sense to match that order in the wiki-text. It's a small issue, but would benefit from attention at some point in the future.

I would decline any consideration for myself. I'd much prefer to let one of our younger mentors get the experience. This year I certainly found Martin and Étienne doing a lot of work on tasks, on IRC and behind the scenes. I'd endorse either of them as first choice, but I know that the others put a lot of effort in as well.

I could certainly look at a Lua solution, but I must say that my preference will always be for a solution that works at the user level. Anything running in Lua would normally impact every reader, whereas I think this request is for the benefit of a small number of editors. In these sort of cases, the combination of a small piece of user-loaded JavaScript plus user CSS fits the bill exactly. If @Nirmos's code does the job requested, it would seem to be a better solution than anything I could cook up in Lua.

We started using Scribunto to read Wikidata items in exactly that way - just loading the entire entity as an object and working from that. There are two downsides that became apparent:

The priority for me would be to have mw.wikibase.getDescriptionByLang with no language fallback (the way that mw.wikibase.getLabelByLang already works). as we already have a request for that functionality.

For anyone who is experimenting with Lua here is the link I mentioned to the Scribunto reference manual:

As I'm not going to be using my main account "on the road", I am only concerned with security of my main account at home where nobody is going to be overlooking my typing. Since my main account passphrase contains over 30 characters, typing blind is becoming noticeably more error-prone as I get older. So I share the concern raised by the OP.

Of course, I'd be happy to present this workshop.

If we find a couple of assistants as suggested, we could manage a larger audience if the demand was there.

I'd like to have a complete collection of api calls exposed to Scribunto. I should be able to get the following:

We have functionality that you'd like to have, but that is not implemented at present. I wouldn't call that a bug.

You use an infobox based on a module that permits suppression of named fields.

I can't do that because your infobox https://de.wikipedia.org/wiki/Vorlage:Infobox_Software fetches references directly from Wikidata, which isn't realistic to implement on English Wikipedia, so I haven't implemented it.

If you use the WikidataIB module, you have to specify |fetchwikidata=ALL in the article to enable fetching info from Wikidata. That ensures that in each article, there has to be an active effort to "opt-in" to the use of Wikidata.

As I mentioned during the office hours, it would be sensible to make use of structured data captions in the projects. But I obviously didn't make clear enough that there are two very different and distinct pieces of text associated with images in Wikipedias.

The English Wikipedia module WikidataIB has the code to filter out by default any statement that is unsourced or whose only source is "Imported from Xyz Wikipedia".

Yes, I've just found that out by testing.

Thank you @Tgr.

In T193857#4183293, @JJMC89 wrote:

In T193857#4183281, @Pbsouthwood wrote:

I see that JJMC89 changed my task name. I would like to know why, as the new name does not make sense to me.

It was renamed because the magic word stores the short description in the database; it does not return anything.

In T193857#4183283, @RexxS wrote:

The renaming is because JJMC89 is only considering the functionality of storing a value of prop=description. Perhaps he wasn't aware that the Wikipedia app actually returns the value as rendered text close to the top of the article displayed.

An API/app returns what is in the database.

The renaming is because JJMC89 is only considering the functionality of storing a value of prop=description. Perhaps he wasn't aware that the Wikipedia app actually returns the value as rendered text close to the top of the article displayed.

If {{SHORTDESC}} appears more than once on an article's page, then the text in the final instance takes precedence.

I agree that caching would introduce predictable lag whenever a short description is changed, but I doubt that the descriptions are going going to be changed very often, if at all.

We may be considering different things here. As I understood it, Mike's suggestion was to be able to display English short descriptions in a page on Commons. That would be what you're thinking of as "where it's used". If the code on the Commons page pulled the value of the short description via the API every time the page was reloaded (but not otherwise), I can't see where we would need to notify the Commons page of any potential changes to the value. That's merely the reciprocal of the situation where we don't see that a Commons image has changed until we refresh a Wikipedia page that contains that image.

It was Mike Peel who asked for the capability, not I, but the result is the same.

There have already been requests for short descriptions to be available within the text of a wiki-page, especially for Commons, where a page or category may be linked to an article on a Wikipedia. I can imagine the same functionality being of use in other projects as well.

It's probably best to consider why we're diverting short descriptions from Wikidata to the local Wikipedia.

I've now enabled the magic word on some 4600 articles on English Wikipedia:

The reason why different projects develop different modules is that different communities have different demands. Working on the English Wikipedia has led me to alter the original line of coding that I developed early on.

Commenting on Andre's questions/suggestions:

In T181738#3911500, @srishakatux wrote:

For the task review part: I wonder if each task should have only one or two admins assigned to it and also tasks are equally distributed among admins. And, that way perhaps we would be able to increase slightly the number of tasks that get reviewed before the due date.

I've found the limit of 1500 characters quite restrictive. Taking beginners through their first steps in a new language is rewarding, but requires a lot of detail in the instructions to keep them "on the rails".

It's probably a feature. :)

I will mentor this in Google-Code-in-2017

I will mentor this in Google-Code-in-2017

I will mentor this in Google-Code-in 2017.

From an organisational point-of-view, I'd be interested in hearing other folks' opinions - and that probably should include the students - about tasks marked as Basic. I marked the first of my batch of "Learning Lua" as Basic to try to encourage beginners to try them. This was especially as some students might not find many tasks that they feel they could do, I'm hoping that those students may get some sense of accomplishment, at least.

I will mentor this in Google-Code-in 2017.

I will mentor this in Google-Code-in 2017.

I will mentor this in Google-Code-in 2017.

I will mentor this in Google-Code-in 2017.

I will mentor this in Google-Code-in 2017.

I will mentor this in Google-Code-in 2017.

I will mentor this in Google-Code-in-2017

I will mentor this in Google-Code-in-2017

I will mentor this in Google-Code-in-2017

I will mentor this in Google-Code-in-2017

Well, the root category for Commons templates is at https://commons.wikimedia.org/wiki/Category:Commons_templates

The |+ is of course the wiki-markup for a caption, so there's nothing more cryptic about it than any other markup.

Many screen readers have the ability to call up a list of table captions and allow the user to jump directly to a table, which is very helpful for users who wish to revisit a table, or just look up information from a particular table. Where a table immediately follows a section heading, the caption becomes somewhat redundant if it simply repeats the heading, because screen readers can generally navigate to particular sections (and many users will be accustomed to navigating Wikipedia articles in that manner).

The choice of cells for markup for row headers and row scope is rather more problematical. Priority should be on adding scope for column headers as that should be easily achievable and much less likely to encounter opposition.

I think that whatever solution is reached, it should comply with relevant policies on the Wikipedias that are affected by it. On enwiki, (https://en.wikipedia.org/wiki/Wikipedia:Image_use_policy#Displayed_image_size), the following policy is in place:

On English Wikipedia we have https://en.wikipedia.org/wiki/Module:Wikidata and https://en.wikipedia.org/wiki/Module:WikidataIB as examples of using Lua to get values from Wikidata. Each of them deals with multiple values for a property reasonably well in most cases, particularly when the values represent items that are internally wiki-linked.

Just to answer the question in your example: although all text is related to a font-size setting, images are generally not sized in relation to the base font size. In other words, zoom is not synonymous with changing font size. Of course registered users wanting to change the balance between image size and font size don't need buttons to change font size, as they can set different default image sizes in their preferences.