Talk:Wikimedia Apps

Previous page history was archived for backup purposes at Talk:Wikimedia Apps/LQT Archive 1 on 2015-07-10.

I am not sure if this is the right place to discuss features of the Android app. I really love Wikipedia and the app and thus I have 70 tabs open. However, I am really not interested in managing these tabs, as I prefer to use the search function. Can I disable to use tabs or close all tabs regularly?

Thanks for your support and work for Wiki!

They could create applications for the other projects as well. It is common for several news sources to create applications. It would be nice for Wikinews to have one too.

There's a Wikimedia Commons app that's developed by volunteer developers: https://commons.wikimedia.org/wiki/Commons:Mobile_app

Likewise, I think a Wikinews app is far more likely to happen as a volunteer effort than as a Foundation project, unfortunately. The existing apps are open source, of course, and anyone could build on them.

 Dear Charlotte, Dmitry, Cooltey, Sharvani, & Robin (ie, Wp Android app team):
 Thx so much for creating & perfecting (your conscientious effort is quite obvious) this Wp app. I've used Wp almost every day since discovering it ~2005; saving 100s of trips to my local library, and improving my quality of life enormously. I have contributed $50 now & then (tho I am poor, by US stds).
 ~March 2020 I finally took a chance (my Moto E 5 Play smart phone has limited secondary storage) & installed the Wp app. My Wp user experience has improved even more.
 I contributed my first article edit last week, and last night when the app enthusiastically invited me to contribute by tagging some pics, and later to create a Onjayoxnay Wp Commons Page, I did both. 
 Returning to my purpose here today, thank you all very much for all your work on the app. It is such a blessing (dubious word choice?? I am a Deist...) to my life.
 Be well, all.
 -- John Knox

Thank you so much! That's extremely kind of you, and the whole team very much appreciates it. :)

Thank you, for using and for your kind words.

Thank you! so kind of you! :)

Thanks a lot for your kind and encouraging message! @Onjayoxnay

I've been adding tags to images from the suggested edits section in the Android app. Just trying to do my part. I've been a user and reader for several years, occasionally donating when I can. Now that we all have extra time on our hands, I thought, why not help the site I use everyday. It's actually been really fun tagging the images from the suggested edits tab on the App. I would tag a few, later on I would get notified about my contributions. I have to say I really do like helping, even if it's just a little.
Wikipedia would suggest images/photos, I would spend a few minutes researching a tag. Making sure that it was actually adding usefulness to the image. I did a few around noon today, expecting to see those added to my small number of contributions (quite proud of 😁). 
This evening the user/Admin  A.Savin left the message on my user talk page "Please do not contribute nonsense-edits. Vandalism is not appreciated." 
I couldn't figure out what I did that would make one of the Admins think this. I'm new to editing and don't have anything of a profile, but I can't help but to think if I ever try editing/tagging anything again that required approval would be biased. I know that's what I would think if I looked at a new users edit and saw that. Now the only thing on my user talk page is this message blaming me for doing something I would never do.
I wish they could have just fixed it and messaged me about my mistake. I'll try tagging again tomorrow. If anyone looks at my edits could you please suggest what I'm doing wrong.

Hi @Recurringintensity. First, let me thank you for your edits and your desire to help Wikipedia and Wikimedia Commons. It's appreciated. The problem here isn't you, but the suggestions you've been given.

In short, this is a new feature (still in beta) and we've been testing it, hoping that it would be a good way to help newcomers edit. Depicts (the tags) is a new feature, and the computer-aided tagging even newer. It's become clear that there's a disconnect between what the computer-aided tagging suggests and what the existing community of editors who are looking after Commons expect. The suggestions have been fairly general: railway, railway station and so on, but the community wants the new feature to be more specific: Peterborough railway station. This means that you've been caught in between, doing your best, given the material you've been given. We're currently addressing this by moving away from the automatic suggestions, and steering users towards the information about the files. People like you, who have been testing the feature, have been crucial in making us understand what we need to do development-wise. Thank you.

Hello! I wanted to report that on the Wikipedia Android app, hatnotes aren't shown. This is an issue because people going to, say, the "coronavirus" article won't see the "This article is about the group of viruses ..." hatnote and therefore may not understand why they can't find any information on the current pandemic.

This will be fixed as soon as the next version of the Android app is released. You can test it in the beta version, of you want to see how it works.

https://phabricator.wikimedia.org/T245322#5942391

Hi,

the mobile app (both android and iOS) automatically shows a Picture / Logo as a Header-Image of Articles, if there is one at Wikidata.

Unfortunately with logos, this doesn't look very good, as the app zooms in and therefore crops some parts of the logo (see Screenshot – tested with the german article HateAid with this wikidata-item.

On mobile (or pc) browsers the logo is just shown at the infobox, as it is intended – and with correct dimensions. If an article's wikidata item has no logo/picture, the app doesn't show a header-image, which in the case of my screenshot would look better.

Do you have an idea on how to fix this (except from removing the logo from wikidata, which would remove the header-image completely)? Is there a setting that makes the app not zoom-in?

Bests regards --~~~~

Thanks for your feedback, @Johannnes89. We'll get back to you.

The developers are currently discussing this. We'll see what comes out of it.

Thank you!

Unfortunately, the images don't actually come from Wikidata but are selected by the PageImages extension. This makes it more difficult to handle, but we might find some workaround, i.e. "SVG of a certain size" or something like that.

Ahh thanks for clarifying!

I wanted to point out phab:T212610 here. Basically, because of a long-known iOS bug (or anomaly), CSS tooltips remain sticky on mobile devices. Apparently, the mobile version (.m domain) is able to handle the problem well; the iOS app however behaves just like the desktop version. I feel like that should be fixed quickly, after all it is specifically the iOS app!

I've added the ticket to the iOS app bug project on Phabricator.

Hi,

The mobile app team used to respond to queries in the #wikimedia-mobile channel. It looks like this is not the case anymore. I recently tried to get a clarification in the IRC twice and didn't receive any responses both the time.

Is this discussion page considered a better place to contact the mobile app team for any clarifications or is there some other point of communication?

Hi Kaartic,

The team still hangs out on IRC but we failed to respond to your question. Generally, it's easier for us to respond asynchronously here or on Phabricator. In this case, where your question was about incorrect data in the app, I'd suggest filing it on the Android team's backlog on Phabricator.

Thanks for the update! I was reluctant to do that as I previously thought "Suggested edits" was an alpha only feaute. Looks like its available even in the production version.

That said, I'm seeing consistent values for pageviews now. I don't see any drop in paveviews all of a sudden (which is what I observed before). I'll file a task if I come across it again in the future.

I'd like to install the Wiktionary app on a Kindle for kids to use. It's on the Google Play store but not on the Amazon store. Is the released version available as an APK somewhere? Is it still being actively developed? Thanks.

Hi, is that the developed by User:Pfhayes? You could ask on their talk page! It's not developed by any of the Wikimedia Foundation teams, so I don't have the answer, I'm afraid.

The android app is displaying a "on this day" card with a structured timeline of events for english, but not for other languages. How is this data extracted, so that we can implement this for other languages?

I'd like to know, too.

I'm so sorry I didn't see this question!

The 'onthisday' data is served via this rest endpoint. Here's an example of a call to the endpoint:

https://en.wikipedia.org/api/rest_v1/feed/onthisday/events/01/15

The endpoint extracts this data by teasing out some structure from "day pages", like https://en.wikipedia.org/wiki/January_15.

It's not a perfect approach - ideally we'll get this data from wikidata at some point (or use this endpoint to seed wikidata records for days of the year?) - but it's been useful in the mean time.

The structure of these day pages varies a bit (or a lot) by language wiki, so I tried to abstract away the language logic. Here's a mirror of the file that contains the language specific logic used by the onthisday parser (which I wrote). I added handling for a few languages which, at the time, seemed to have a page for each day of the year, but I got side-tracked by other work since.

I'd like to circle back and audit the state of all language wikis' day page coverage again. If a language has a page for every day of the year the parser isn't too hard to update iirc. I seem to remember it taking an hour or 2 per lang?

Hope this helps!!

Thanks! It's a start.

Here's an idea for a future improvement: Instead of collecting month names and section names in all languages, could you make a standardized set of internal formats and names that could be used in all languages? For example, instead of "January 16, 2019" people would write "2016-01-16"? If people really want dates written in words in page titles, it could probably be handled with redirects.

Another idea is to reuse the same ultramagical parser that automatically converts dates written with words into an internal presentation on Wikidata.

And instead of section names, could it have HTML classes or ids that would be the same across all languages?

Or maybe these section names could be made into a translatable file and translated on translatewiki? This would be far easier to contribute to than to submit Git pull requests to JS code.

Oh, and what about the other main page sections, such as "In the news"?

@MHurd (WMF) thank you. Please check this https://github.com/wikimedia/wikifeeds/pull/3/files

@Amire80 the existing approach is ok since it doesn't need wiki modifications. Using special structure, even in the form of templates, onwiki would make other tools break and make contribution harder.

Well, yeah, that's the nature of change :)

Making it more uniform will make it easier to do for all languages. Currently, it can be done only for languages that created their own structure and submitted a Git patch.I propose to reduce the number of steps by making the Git patch unnecessary.