Wikipedia pages violating CC-BY-SA license
Closed, ResolvedPublic

Description

Wikipedia articles on the Mobile App (like on the Android App) do not provide attribution to article authors.

See also https://bugzilla.wikimedia.org/show_bug.cgi?id=34673


Version: unspecified
Severity: normal
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=34673

bzimport set Reference to bz35616.

Assigning to Tomasz so he can adjust priority down and/or find someone to fix this.

I think you got blocked by/blocks reversed, fixing.

philinje wrote:

This bug refers to the mobile site, which is referred to as the Mobile App in the first comment.

Yes -- "mobile site" is what I intended, sorry for the confusion!

philinje wrote:

As noted in bug 34673, the mobile site currently provides a way to see the Desktop view, which includes the "View history" tab. This is not an elegant solution but at least provides CC-BY-SA compliance.

As an interim step, we can include a way to navigate directly to "View history" in both the app and mobile site via the new navigation UI.

(In reply to comment #5)

Yes -- "mobile site" is what I intended, sorry for the confusion!

Updating product/component.

We could add a link to the footer of the non-beta site to ensure compliance to the majority of visitors.
This would be a quick fix whilst we wait for the new navigation menu.

(In reply to comment #8)

We could add a link to the footer of the non-beta site to ensure compliance to
the majority of visitors.
This would be a quick fix whilst we wait for the new navigation menu.

Could you do this ASAP?

philinje wrote:

Let's discuss this potential change, and it should happen in the beta, if anything. The first issue is how the History page looks in Mobile View. Some Footer changes will be finalized this week.

The history page always displays in desktop site mode.

Created attachment 10376
patch to add a history link to the footer on the regular site

Note this wouldn't effect the beta leaving us free to experiment with the design and since the beta is opt in this shouldn't be such an issue?

Attached: historylinklabel.diff

Tfinc added a comment.Apr 4 2012, 5:38 PM

Changing the current mobile web experience doesn't make much sense to me. A change like that would only live for a week (as we only have a handful of blockers on the new design) and then we would be back here discussing the issue.

Changing it on the new mobile web beta design which is launching soon would give us the long term presence that were looking for.

Also, lets take a step back here and remember that as long as we provide a link to the Article which can in turn show you history we *are* in compliance with CCbySA. I've talked to Mike Godwin a bunch of times about this as we ran into this exact issue with the offline wikipedia projects. If you provide a link that can lead you to the article contributors then you are in compliance. I agree that we want a better solution (and we'll have one) but calling it a violation would be going against what the former general counsel of the wikimedia foundation said.

philinje wrote:

We are considering what to call this. In the new nav design, there will be a history function as currently exists in the apps (in the browser that is just a browser function). Lindsey's current idea is to make a new section heading called "Article history" which would then link to the View history page in the Desktop view. That will be somewhat jarring, but maybe the best solution for now.

Really this change applies more to the apps, and we definitely have confusing terminology to deal with there. But in terms of prototyping, it might be better to try some options in the mobile site first, with the intention that the design would apply uniformly across the site and apps.

Also please note that there is currently no footer in the apps.

(In reply to comment #13)

I've talked to Mike Godwin a bunch of times about this as we ran into
this exact issue with the offline wikipedia projects. If you provide a link
that can lead you to the article contributors then you are in compliance.

Thanks for the this detail. It really helps my perspective.

Planning to use same solution used in bug 34292 - should either be sent for review tonight or early Monday...

Add Comment