[Bug 38962] Design and decide how redirects should work

2014-01-07 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=38962

tobias.gritschac...@wikimedia.de changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l


[Bug 38962] Design and decide how redirects should work

2014-01-07 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=38962

tobias.gritschac...@wikimedia.de changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||tobias.gritschacher@wikimed
   ||ia.de
 Resolution|--- |FIXED

--- Comment #14 from tobias.gritschac...@wikimedia.de ---
Since the decision was made (according to the document linked in comment #13)
to implement option 2, I am closing this bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l


[Bug 38962] Design and decide how redirects should work

2013-12-21 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=38962

--- Comment #13 from Bene*  ---
I have created a page based on Daniel's mail. Just adding the link here, too.

https://meta.wikimedia.org/wiki/Wikidata/Development/Entity_redirect_after_merge

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l


[Bug 38962] Design and decide how redirects should work

2013-12-02 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=38962

Lydia Pintscher  changed:

   What|Removed |Added

 Blocks||57744

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l


[Bug 38962] Design and decide how redirects should work

2013-12-02 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=38962

Daniel Kinzler  changed:

   What|Removed |Added

 Status|PATCH_TO_REVIEW |ASSIGNED

--- Comment #12 from Daniel Kinzler  ---
@Bene: i mean Wikibase should handle redirects with the MediaWiki built-in
feature for them. That sort of thing is exactly why the Content interface
exists.

But I'm unsure how to go about it. I just sent a mail to wikidata-tech, asking
for feedback. Here's the mail:

~
Hello all!

Once more, I'm taking a whack at implementing support for entity redirects -
that is, we want Q1234 to become a redirect to Q2345 after we merged Q1234 into
Q2345.

My question is how to best model this.

First off, a quick primer of the PHP classes involved:

* We have the Entity base class, with Item and Property deriving from it, for
modeling entities.

* As "glue" for treating entities as MediaWiki page content, we have the
EntityContent base class, and ItemContent and PropertyContent deriving from
that
(along with their handler/factory classes, EntityHandler, ItemHandler and
PropertyHandler).

Presently, each type of Entity is assigned a MediaWiki namespace, and all pages
in that namespace have the corresponding content type.


Now, there are various ways to model redirects. I have tried a few:

1) first I tried implementing redirects as a "mode" any Entity may have. The
advantage is that redirects can seamlessly occur anywhere "real" entities can
occur, e.g. in dumps, diffs, undo operations, etc. However, many operations
that
are defined on "real" entities are not defined on redirects (e.g. "set label",
etc), so we would end up with a lot if "if redirect, do this, else, do that"
checks all over the code base.

2) second I tried implementing redirects as a "mode" any EntityContent may
have,
following the idea that redirects are really a MediaWiki concept, and should be
implemented outside the Wikibase data model. This still requires a lot of "if
redirect, do this, else, do that" checks, but only in places dealing with
EntityContent, not all places dealing with Entities.

3) third I tried using a separate entity type for representing redirects: a
RedirectContent points to an EntityContent, there is no "mode", no need for
extra checks, no chance for confusion. However, we break a few basic
assumptions, most importantly the assumption that all pages in an entity
namespace contain an EntityContent of the respective type.

None of these solutions seem satisfactory for the indicated reasons, and also
some additional consideration explained below.

4) This lead me to come fully cycle and consider another option: make redirects
a special *type* of Entity, besides Item and Property. This would again allow
straight forward diffs (and thus undo-operations) between the redirected and
the
previous, un-redirected version of a page; Also, it would not compromise code
that operates on Item on Property objects. But since there are still many
operations defined for Entity that make no sense for redirects, we would need
to
insert another class into the hierarchy (let's call it LabeledEntity) which
would be a base class for Item and Property, but not for Redirect.

This would require quite a bit of refactoring, and would introduce redirects as
a "first order citizen" into the Wikibase data model.


Which of the four options do you prefer? Or can you think of another, better,
option?


Below are some more points to consider when deciding on a design:


In a addition to the OO design questions outlined above, one important question
is how to handle redirects in the wb_entity_per_page table; that table contains
a 1:1 mapping of entity_id <-> page_id. It is used, among other things, for
listing all entities and for checking whether an entity exists. HOw should
redirects be represented in that table? They could be:

a) omitted (making it hard to list redirects),
b) or use the redirect's page ID (maintaining the 1:1 nature, but pointing to a
page that actually does not contain an entity),
c) or use the target entities page ID (breaking the 1:1 nature of the table,
but
associating the ID with the accurate place).

For b) and c), a new column would be needed to mark redirects as such.

When deciding on how to represent redirects internally, we need to consider how
they should be handled externally. Of course, when asking for an entity that
got
redirected, we should get the target entity's content, be it using the
"regular"
HTML page interface, the API, the linked data interface, etc.

In RDF dumps, we would probably want redirects to show up as owl:sameAs
relations (or something similar that allows one URI to be indicated as the
primary one). Should redirects also be present in JSON dumps? If so, should it
also be possible to retrieve the JSON representation of entit

[Bug 38962] Design and decide how redirects should work

2013-12-01 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=38962

Bene*  changed:

   What|Removed |Added

 CC||benestar.wikimedia@googlema
   ||il.com

--- Comment #11 from Bene*  ---
(In reply to comment #10)

If you say "on the level of MediaWiki" I guess you mean on the level of
WikibaseRepo extension, right? Or do you mean Wikibase should handle redirects
with the MediaWiki built-in feature for them?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l


[Bug 38962] Design and decide how redirects should work

2013-11-29 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=38962

Daniel Kinzler  changed:

   What|Removed |Added

   See Also||https://bugzilla.wikimedia.
   ||org/show_bug.cgi?id=57744

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l


[Bug 38962] Design and decide how redirects should work

2013-11-29 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=38962

--- Comment #10 from Daniel Kinzler  ---
Redirects will be implemented to be supported on the level of EntityContent,
but not Entity. That is, they exist on the level of MediaWiki, not on the level
of the Wikibase data model.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l


[Bug 38962] Design and decide how redirects should work

2013-11-27 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=38962

Lydia Pintscher  changed:

   What|Removed |Added

   Severity|normal  |major

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l


[Bug 38962] Design and decide how redirects should work

2013-11-26 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=38962

--- Comment #9 from Gerrit Notification Bot  ---
Change 89810 had a related patch set uploaded by Daniel Kinzler:
Allow ItemContent to represent a redirect.

https://gerrit.wikimedia.org/r/89810

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l


[Bug 38962] Design and decide how redirects should work

2013-11-26 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=38962

Gerrit Notification Bot  changed:

   What|Removed |Added

 Status|NEW |PATCH_TO_REVIEW

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l


[Bug 38962] Design and decide how redirects should work

2013-08-05 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=38962

filceolaire  changed:

   What|Removed |Added

 CC||filceola...@gmail.com

--- Comment #8 from filceolaire  ---
I have been using the 'Merge' tool and even with our current (fairly low) level
of activity I often get a message telling me the tool could not create a delete
message because of an edit conflict. 

If the merge tool automatically created a redirect then these edit conflicts
would not happen.

If the conversion to a redirect could be reversed easily then it would not be
necessary to limit access to the revert tool to special approved persons and it
could be made available to anyone using the merge tool.

Suggested workflow to revert a redirect:
* go to the redirect destination page.
* click "What links here"
* select the link to the redirect page.
* Revert the redirect (via the history page or a special tool or whatever code
magic you come up with).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l


[Bug 38962] Design and decide how redirects should work

2013-07-10 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=38962

--- Comment #7 from T. H. Kelly (Pink&)  ---
One technical note: On your standard MW redirect, you're still "on" the
redirected page, instead of on the target. I.e., if you go to [[Foo]], you're
viewing the content of [[Foobar]], but the URL still reads
http://en.wikipedia.org/wiki/Foo. It occcurs to me that this behavior could be
rather inconvenient with Wikibase: Redirects will, inherently, be somewhat less
stable than normal Q#s (since someone can always change a redirect's target),
so we want to incentivize people to use the "right" Q#; also, the URL is
normally the only place a non-bot user can figure out an item's Q# without
having to click somewhere else. So, once a redirect system actually gets built,
I think it would be best if the URL actually redirected, like with a special
page. (I don't know how technically feasible this is, of course.) And then we
could have, like, a &redirectfrom= URL parameter, which would generate that
familiar "redirected from Q000" text.

Oh, also...

(In reply to comment #5)

> * Diff would show all content in the entity on the left before the redirect
> and
> on the right something to signify the redirect (maybe #Redirect [[Q12345]])
> is
> we want to stay along the lines of MW

Ewww, no #REDIRECT. Wikibase already takes advantage of ContentHandler's having
liberated us from unnecessary use of MediaWiki markup. I'm sure some of the
devs can make us some pretty new Wikibase-type redirect content model. For diff
view, it could just be "redirect-target: Q000" or something like that.

(That's assuming we even want to have the pre-redirect history shown... seeing
as the redirect's target should have all the data the redirect had, we *could*
have it that either only deleted items can be redirected, or that redirecting
an item automatically deletes its old history.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l


[Bug 38962] Design and decide how redirects should work

2013-07-10 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=38962

--- Comment #6 from Legoktm  ---
(In reply to comment #5)

> What happens when you try to EditEntity a redirect through the API?
> * This is an interesting one :/ I almost feel like saying you cant.. Imagine
> if
> a bot were to get a list of items and work on them throught a day, during the
> day one of the items gets redirected by another user, the bot then comes
> around
> to make its edit, if it had the ability to edit it may simply overwrite the
> page, which may not be the right thing to do. Perhaps a parameter to not
> follow
> redirects, so by default they would be followed, but if you really want to
> you
> can still edit the entity from the api (there may be a case this is needed)

In the standard API you can use the &redirects parameter
(https://www.mediawiki.org/wiki/API:Query#Resolving_redirects). Something like
that would work.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l


[Bug 38962] Design and decide how redirects should work

2013-07-10 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=38962

--- Comment #5 from Addshore  ---
Just a few comments / ideas on the above down so I don't forget :)

What happens when you are on a redirect page and edit?
* If you are on a redirect page and edit you should have the ability to edit
the redirect, but when visiting the redirect in the first place you would ,, be
redirected to the target item, genrally you would only find yourself on the
actual redirect page you are there because you want to be there and edit it.

What happens when you try to EditEntity a redirect through the API?
* This is an interesting one :/ I almost feel like saying you cant.. Imagine if
a bot were to get a list of items and work on them throught a day, during the
day one of the items gets redirected by another user, the bot then comes around
to make its edit, if it had the ability to edit it may simply overwrite the
page, which may not be the right thing to do. Perhaps a parameter to not follow
redirects, so by default they would be followed, but if you really want to you
can still edit the entity from the api (there may be a case this is needed)

How do history and diffs of redirects look like?
* History simply shows the changes made to the item up to the point of redirect
and then the redirecting edit.
* Diff would show all content in the entity on the left before the redirect and
on the right something to signify the redirect (maybe #Redirect [[Q12345]]) is
we want to stay along the lines of MW

Undo on redirects?
* Naturally there should be an undo button incase mistakes are made.
Potentially this could be something limited via permissions.

How to display redirected entities in the UI?
* Pretty much the same as in core, a simple (Redirected from Q12345). In core
this is just below the title of an article. It could go in the same place in
wikidata (below the label), it could also go just above, benefit of this would
be no content moving slightly from one non redirected item to another non
redirected.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l


[Bug 38962] Design and decide how redirects should work

2013-07-10 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=38962

denny vrandecic  changed:

   What|Removed |Added

   Priority|Normal  |High

--- Comment #4 from denny vrandecic  ---
What happens when you are on a redirect page and edit?
What happens when you try to EditEntity a redirect through the API?
How do history and diffs of redirects look like?
Undo on redirects?
How to display redirected entities in the UI?
How should ChangeOps deal with redirects?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l


[Bug 38962] Design and decide how redirects should work

2013-06-21 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=38962

--- Comment #3 from Addshore  ---
My speedy analysis shows approximately 218,060 items that are deleted and that
could more than likely be redirected to another item.

These are simply items that reference another item in their deletion summary.

As far as I know this is 218,060 out of 532,144 which is about 40%.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l


[Bug 38962] Design and decide how redirects should work

2013-06-21 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=38962

--- Comment #2 from Addshore  ---
I agree with everything that has been said in the comment above.

Being able to redirect items would greatly reduce the work of admins having to
delete items that have been merged, the user right mentioned above could be
assigned to a group of people that have proven they know how to merge items
without losing any data.

This feature would make it allot easier for external sites to use data on
wikidata, the risk of an item 'moving' from one unique id to another would be
reduced.

Also once this is implemented it would be great to go back through every
deleted item and try to 'redirect' as many as possible to their new locations.
Many deletions currently include a link to the new / merged item in the
summary. I will try to write a script to do some analysis of this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l


[Bug 38962] Design and decide how redirects should work

2013-06-04 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=38962

T. H. Kelly  changed:

   What|Removed |Added

 CC||pinkampersand.wikimedia@gma
   ||il.com

--- Comment #1 from T. H. Kelly  ---
I think redirects should be created through two processes:

Through special pages: For things like bug 38664, where a built-in tool will
exist to make some sort of change that results in the elimination of an item,
where there's another item on the same topic as the now-irrelevant item.

Manually: There should be a 'redirectitem' user right (the assignment of which
would be determined by the community, but would probably by default only be
given to admins), which would allow a user who holds it to redirect a deleted
item to another item. This would be primarily for cases where an item's been
merged manually (i.e. all current merges, since there's still no special page
for merges, and, presumably, some merges nonetheless even once we have a
special page), as well as for cases such as when an item's been deleted after
its linked article was deleted, but then the linked article is created and a
new item is made for it (see also bug 49100). There have also been some cases
where a vandal removes a sitelink from an item, and then a bot just creates a
new item for that link. All of these aren't huge issues right now, but are
clearly something we're going to need to deal with if we expect third-party
sites to want to use our information - it would be very difficult to deal with
Q#s suddenly becoming invalid, and their topics being replaced by new numbers.

I'm obviously not commenting on the technical part of this, since I know
nothing about that stuff, but I'm just giving a user-experience perspective of
the situations where item redirects are necessary, and how they should be
implemented.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l


[Bug 38962] Design and decide how redirects should work

2012-08-02 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=38962

denny vrandecic  changed:

   What|Removed |Added

   Priority|Unprioritized   |Normal

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l