I've been working on implementing the category redirect detection suggested by Lars Aronsson (https://sourceforge.net/tracker/?func=detail&atid=603141&aid=1722782...), but I have a question for other developers. A category redirect is implemented as a "soft redirect"; that is, a template is placed on the page marking it as a redirect, but it does not use the #REDIRECT magic word of the MediaWiki software, so the server doesn't treat it as a redirect. As proposed, a category page (p) that contains a "soft" category redirect would return True both to p.isRedirectPage() and to p.is_category_redirect(); the only way to tell hard redirects apart from soft redirects would be to do something like:
if p.isRedirectPage() and not p.is_category_redirect(): handle_hard_redirects_only()
The question is, if pages that are not hard redirects return True to p.isRedirectPage(), will this break anything else?
Russ
Russell Blau ha scritto:
The question is, if pages that are not hard redirects return True to p.isRedirectPage(), will this break anything else?
Russ
OK, nobody said anything, so I'm committing it.
As usual...
Policy should be inverted: patches + reviews = commits
Fewer problems (regressions, typos, bad code, 100 commits for 1 problem, strange ideas, etc...)
And, especially, so the dev team work as unit and do progress.
Due to mailing-list use, you are working 99.9% alone in rewrite branch. I am sorry, you undertook a lot of work.
"Francesco Cosoleto" cosoleto@free.fr said:
Russell Blau ha scritto:
The question is, if pages that are not hard redirects return True to p.isRedirectPage(), will this break anything else?
Russ
OK, nobody said anything, so I'm committing it.
As usual...
Policy should be inverted: patches + reviews = commits
Fewer problems (regressions, typos, bad code, 100 commits for 1 problem, strange ideas, etc...)
And, especially, so the dev team work as unit and do progress.
Due to mailing-list use, you are working 99.9% alone in rewrite branch. I am sorry, you undertook a lot of work.
I am sorry, too, Francesco, but I don't entirely understand your comments. Could you explain in more detail how you want the team to work? Anything that would lead to more cooperation and fewer bugs would be good.
Russ
Russell Blau ha scritto:
OK, nobody said anything [...]
As usual...
Policy should be inverted: patches + reviews = commits
Fewer problems (regressions, typos, bad code, 100 commits for 1 problem, strange ideas, etc...)
And, especially, so the dev team work as unit and do progress.
Due to mailing-list use, you are working 99.9% alone in rewrite branch. I am sorry, you undertook a lot of work.
I am sorry, too, Francesco, but I don't entirely understand your comments. Could you explain in more detail how you want the team to work? Anything that would lead to more cooperation and fewer bugs would be good.
Current state is this mailing-list is just ignored, almost no talks about the project and its development. Am I wrong? SVN commits are coming and there isn't certainty they are checked. Nobody know who is present, who is away...
We can try to force patch review and only to commit reviewed patches. This should improve code quality and cooperation, without compromising a lot development speed.
I can indicate some open source projects that take care of the code in this way.
While I am at it... Why not add a mailing-list for SVN log notification only? Looks bad mixed with the rest (http://lists.wikimedia.org/pipermail/pywikipedia-l/2009-January/thread.html). "pywikipedia-l" might be renamed "pywikipedia-devel", and continue to receive bug tracker data.
I was tempted in a first step to say that I would prefer to keep backward compatibility, having isRedirectPage to match only hard redirects, and changing our skip tests to ( p.isRedirectPage() or p.is_category_redirect() ) where necessary, to be sure that nothing breaks. But on a second thought... both approaches make sense.
I was worried that the maintenance on the category redirect pages would be hard to do with that change; but I checked replace.py in that view, and since content is retrieved with get_redirect=True, I found no inconvenient. I'll grep through our codebase to double check all usages of isRedirectPage and the raised IsRedirectPage ...
(If ambiguous usages are found, we could introduce a config+commandline variable, something along the lines of ignoreCategoryRedirects ... )
2009/1/13 Russell Blau russblau@imapmail.org:
I've been working on implementing the category redirect detection suggested by Lars Aronsson (https://sourceforge.net/tracker/?func=detail&atid=603141&aid=1722782...), but I have a question for other developers. A category redirect is implemented as a "soft redirect"; that is, a template is placed on the page marking it as a redirect, but it does not use the #REDIRECT magic word of the MediaWiki software, so the server doesn't treat it as a redirect. As proposed, a category page (p) that contains a "soft" category redirect would return True both to p.isRedirectPage() and to p.is_category_redirect(); the only way to tell hard redirects apart from soft redirects would be to do something like:
if p.isRedirectPage() and not p.is_category_redirect(): handle_hard_redirects_only()
The question is, if pages that are not hard redirects return True to p.isRedirectPage(), will this break anything else?
Russ
Pywikipedia-l mailing list Pywikipedia-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
pywikipedia-l@lists.wikimedia.org