DanTMan | 1 Mar 2008 01:06

Re: Case insensitive links (not just titles).

^_^ Complete Title backend rewrite!? A Image backend rewrite is being 
worked on, why not start one for the Title class as a separate project.
We could compile a list of useful features in the Title system people 
want that we currently don't have.
And come up with the most optimum way to deal with titles.
However, I'm not a fan of storing both a normalized underscore version 
of the title, and a un-normalized space version of the title. I'm 
thinking display title for display, and normalized title for all the 
handling and other things. I think having the {{DISPLAYTITLE:}} function 
store the display title inside of the page table would be best. And if 
we made the normalized version depend on the display title then it 
wouldn't be possible for someone to remove the requirement that the 
displaytitle needs to normalize to the actual title. Some wiki would 
like to have that not there, and have a subtitle added when they don't 
match.
So DISPLAYTITLE and PAGETITLE stored in the database I would think. Or 
we could actually to a tripple, we could decide what would be best after 
considering all the possible features people might want to be able to 
add into the title system, and consider various hooks to add which would 
allow people to create Title modifying extensions without hacking core.

~Daniel Friesen(Dantman) of:
-The Gaiapedia (http://gaia.wikia.com)
-Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG)
-and Wiki-Tools.com (http://wiki-tools.com)

Simetrical wrote:
> On Thu, Feb 28, 2008 at 7:43 PM, DanTMan <dan_the_man@...> wrote:
>   
>>  From my understanding Title::secureAndSplit(); is the only place where
(Continue reading)

Ben | 1 Mar 2008 01:13
Picon

Re: Extension:SocialProfile

David Pean wrote:
> Hey everyone,
> 
> I'm Dave and I work for Wikia.  I've been a lurker on this list, but
> this is my first post and extension release, so go easy on me :P
> 
> I just wanted to let everyone know that we've bundled up some of our
> social features for Open Source, including basic profile information,
> friending, and "wall" messaging".   It's been tested and runnning on
> sites using MW 1.10.  More information can be found on the extension
> page http://www.mediawiki.org/wiki/Extension:SocialProfile.
> 
> If you want to see some of the features in action, check out:
> http://www.armchairgm.com/User:Romiezzo
> http://halo.wikia.com/wiki/User:ED
> 
> If anyone has any questions, suggestions, or issues, please let me know.
> 
> I'm looking forward to being apart of this great community!
> 
> Thanks!
> 
> David Pean

First, let me say, thanks for sharing :)

I like the extension.. I was especially interested in the "recent 
activities", "networks" and "statistics" sections of the user examples 
you gave.. unfortunately those aren't on there..

(Continue reading)

Brion Vibber | 1 Mar 2008 07:31
Picon
Gravatar

Re: Broken dump enwiki-20080103-pages-meta-current.xml.bz2

Lev Bishop wrote:
> The most recent enwiki dump seems corrupt (CRC failure when bunzipping).
> Another person (Nessus) has also noticed this, so it's not just me:
> http://meta.wikimedia.org/wiki/Talk:Data_dumps#Broken_image_.28enwiki-20080103-pages-meta-current.xml.bz2.29

This file's been regenerated, BTW; now passes bzip2 integrity check.

-- brion vibber (brion  <at>  wikimedia.org)
Huji | 1 Mar 2008 09:10
Picon
Gravatar

Re: CSS minus

Brion,

Thanks for your thorough and informative response. I'm afraid I haven't yet
got my answer here. What I'm asking is:

* Why do we import the dummy-titled CSS when no usecss parameter is passed?

Or even if there is really a reason to do that, which I'm missing
carelessly, I can extend my question to:

* Why should the dummy-titled CSS code return anything when no usecss
parameter is passed?

Hojjat

On Fri, Feb 29, 2008 at 11:02 PM, Brion Vibber <brion@...> wrote:

> Huji wrote:
> > This may be the dumbest question I've every asked, so go easy with me
> > please! In SkinTemplate.php we have this:
> >
> > $sitecss .= ' <at> import "' . self::makeUrl( '-',
> > "action=raw&gen=css$siteargs$skinquery" ) . '";' . "\n";
> >
> > I understand that it helps when a useskin parameter is passed; what I
> don't
> > understand is, why does it have to return a value when no such a
> parameter
> > is passed? It can simply return "nothing", can't it?
>
(Continue reading)

DanTMan | 1 Mar 2008 09:33

Re: CSS minus

Probably missed them in Brion's comments but:

We import the dummy-titles CSS when no usecss parameter is passed, 
because it then imports the default for the user.

So, the usecss is merely a extra parameter passed when needed to prevent 
the defaults from being loaded instead of the skin being temporarily 
viewed. We still import it when usecss is not passed because then it 
returns the default stuff, for the default skin which is being viewed, 
so it still does return stuff we want.

And it should return stuff because that dummy titled css is returning 
css relevant to the user's preference no matter what skin you're in. It 
doesn't matter if you are in a temp skin, or the user's default, you're 
still loading their preferences and those are needed.

~Daniel Friesen(Dantman) of:
-The Gaiapedia (http://gaia.wikia.com)
-Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG)
-and Wiki-Tools.com (http://wiki-tools.com)

Huji wrote:
> Brion,
>
> Thanks for your thorough and informative response. I'm afraid I haven't yet
> got my answer here. What I'm asking is:
>
> * Why do we import the dummy-titled CSS when no usecss parameter is passed?
>
> Or even if there is really a reason to do that, which I'm missing
(Continue reading)

subscribe | 1 Mar 2008 11:42
Picon

Re: Case insensitive links (not just titles).

> Explicitly, yeah, but any associative array using title strings as
> keys will automatically be case-sensitive, just because array lookups
> (and string comparisons generally) are case-sensitive.  I have no idea
> how many of those there are scattered about.

Is there many of them - such things? The only one I found was LinkCache
class. 
Parser, Linker, Title use only methods of LinkCache, when it's about
Good|BadLinks.
Maybe there are no other cases of use title string as keys of associative
array?
Ilmari Karonen | 1 Mar 2008 14:48
Gravatar

Re: [MediaWiki-CVS] SVN: [31385] trunk/extensions/ConfirmEdit

Brion Vibber kirjoitti:
> 
> The simplest possible interface here would be to provide an HTML 
> fragment containing the challenge; though that brings with it potential 
> issues of safety/sanitization or HTML rendering requirements.

No HTML in API responses, please.  If I wanted to parse HTML, I'd be 
screen scraping the wiki interface anyway, not using the API.

URL + MIME type, plus possibly some explanatory text, should really be 
enough for any CAPTCHA.  They're supposed to be pretty self-explanatory 
anyway.

One could even use "data:" URLs for short in-line CAPTHAs if one wanted.

--

-- 
Ilmari Karonen
Roan Kattouw | 1 Mar 2008 21:33
Picon
Favicon

Re: [MediaWiki-CVS] SVN: [31385] trunk/extensions/ConfirmEdit

Ilmari Karonen schreef:
> URL + MIME type, plus possibly some explanatory text, should really be 
> enough for any CAPTCHA.  They're supposed to be pretty self-explanatory 
> anyway.
>
> One could even use "data:" URLs for short in-line CAPTHAs if one wanted.
>
>   
Text responses (text/plain for SimpleCaptcha and text/tex for 
MathCaptcha) are currently presented using the 'question' field rather 
than the 'url' field.

Roan Kattouw (Catrope)
Simetrical | 2 Mar 2008 01:16
Picon

Re: Tag intersection, crazy idea

On Fri, Feb 29, 2008 at 6:35 PM, Steve Sanbeg <ssanbeg@...> wrote:
>  That was my thinking; that categories without a page ID are probably
>  typos, and anyway less useful for intersection; if not, the articles could
>  be added.  So using the IDs and some recursion could be simpler and more
>  scalable than using a hash.

I don't really see that it's simpler or more scalable, particularly.
It does have moderately better locality of reference, although it's
still not great.  The denormalization means that half of a category's
entries are scattered across the entire table, where it's in the
second position, and only the half (on average) where it's first will
be clustered in the same pages.  I don't know if there's a very good
reason to prefer either way.

Domas, do you have any thoughts on this scheme?
Simetrical | 2 Mar 2008 01:25
Picon

Re: Extension:SocialProfile

On Fri, Feb 29, 2008 at 7:13 PM, Ben <chuwiey@...> wrote:
>  Also as a side note, the installation requires modification to
>  AjaxFunctions, which deters a bit from installing due to having to
>  remember that you made that change..

Don't a few Wikia people have commit access precisely so they can add
hooks to avoid file edits?  The change looks like it could be done
pretty easily by adding a new hook.

Gmane