Re: [Wikipedia-l] server maintenance on June 1, 3 a.m. UTC

Jens Frank wrote:
> We'll create some new indexes that should improve site
> performance. To do this, we need to set the wikis to
> read only at 3 a.m. UTC (5a.m. Berlin/Paris, about
> 10 p.m. Chicago). The downtime will take about 2 hours.

While we're on this, that would be a good time to run the password hash
salting.

We'd originally held off on that because a migration to shared user
accounts could change user IDs (and thus the salt), breaking all
password hashes. However it looks like the type of shared account system
we'll end up with is going to be a central account + local accounts, and
a mass migration isn't necessary: people will 'upgrade' their accounts
and be able to punch in their password for confirmation at the time.

For that type of scheme the salt will not be an issue, so we've got no
excuse not to do it.

(For those who didn't notice, Slashdot ran a scaremongering "story"
today about a list of troll accounts Tim made almost a year ago by
comparing password hashes under the title "Wikipedia Leaks Some Users'
Passwords". Slashdot's fun, but it's not journalism; don't expect to
ever get an e-mail from a Slashdot editor asking for comment or
confirmation on facts... Anyway, at least it reminded us we haven't
finished the salted hash transition.)

-- brion vibber (brion  <at>  pobox.com)

Re: Re: [Wikipedia-l] server maintenance on June 1, 3 a.m. UTC

Brion Vibber wrote:
> Jens Frank wrote:
>> We'll create some new indexes that should improve site
>> performance. To do this, we need to set the wikis to
>> read only at 3 a.m. UTC (5a.m. Berlin/Paris, about
>> 10 p.m. Chicago). The downtime will take about 2 hours.
>
> While we're on this, that would be a good time to run the password hash
> salting.

Done.

The other indexes are still building, we'll be back online soon enough... :)

-- brion vibber (brion  <at>  pobox.com)

_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/wikitech-l

Re: Feature addition to the gallery

Ed W wrote:
> Do you mean this bug:
> http://bugzilla.wikimedia.org/show_bug.cgi?id=684
> 
> What's wrong with the code as is?  Looks great to me?
> 
> Please advise what's wrong and I will fix it up - seems great for my 
> purpose
> 
> Thanks
> 
> Ed W

I wrote this patch. I stopped working on it after a cold reception--my 
contributions weren't met with much enthusiasm so I stopped pursuing 
trying to make them.

Brion wants it changed to not allow \' and \" as escapes for ' and " 
inside quoted strings and to not allow whitespace between the opening < 
and the name of the tag.

Also, Ævar notes that the patch doesn't work on the current HEAD, as the 
code the patch applies to has probably changed since the patch was 
written, so it needs some cleaning up.

Hope that helps. Good luck.

- David Friedland

Re: Re: Intended changes to namespace management

"Erik Moeller" <erik_moeller <at> gmx.de> wrote in message 
news:429C002F.3020207 <at> gmx.de...
[snip]
> Whether we should create synonyms beyond the simple Image=>File redirect 
> when we don't have special ways of dealing with these file types yet is 
> arguable. The current behavior would be that [[Sound:soundfile.ogg]] would 
> link to the file description page for that file, but not embed it (so 
> would [[Image:soundfile.ogg]]). But it might be enough to have 
> [[File:Soundfile.ogg]] for this purpose for now.

I suppose it would be too much to hope that we could extend the {{}} syntax 
to images, wherein {{Image:Some-nice_picture.jpg}} embedded the image and 
[[Image:Some-nice_picture.jpg]] simply linked to the description page?
--

-- 
Phil
[[en:User:Phil Boswell]] 

Re: Re: Feature addition to the gallery

> Brion wants it changed to not allow \' and \" as escapes for ' and " 
> inside quoted strings and to not allow whitespace between the opening 
> < and the name of the tag.

Brion,

I read this comment on the bugzilla.  Whilst I agree that "&quot;" 
should be supported I am a little unsure what is wrong with supporting 
the \" syntax? 

Personally I dont do a lot of web development and my first instinct 
would have been to reach for \" to put quotes within quotes.  Surely the 
goal is to have a syntax which is understandable to the general public?

Lets be clear though.  Are we talking about stuff like the following:

<gallery caption="Ed said: \"Here is my gallery\"">

Which you think should *only* be allowed as:

<gallery caption="Ed said: &quot;Here is my gallery&quot;">

The former doesn't feel "inconsistent" to me? (But I am not a hardcore 
web worker)

Can we not compromise and offer both syntax?  Either way it seems like a 
small detail which is holding back an otherwise very useful patch that 
seems quite low risk.  Eyeballing the patch it looks fairly 
selfcontained, although my first thought is that we only need the one 

image dump

just finished downloading the en image dump, tried extracting it with winrar - 
only to get an error - 'the archive is corupt' - though doing it with a 
different extractor, not only doesnt preserve the folders, there only seems to 
be 9200 images in the dump.... could well be more, as i havent extract it all, 
because of this folder thing

anyone of an extracter that does a folder intact job

once that is extracted - how will my wiki know where the images are for each 
artical, and thus include them within each artical?

thanks

Re: Re: Re: Intended changes to namespace management

On 01/06/05, Phil Boswell <phil.boswell <at> gmail.com> wrote:
> I suppose it would be too much to hope that we could extend the {{}} syntax
> to images, wherein {{Image:Some-nice_picture.jpg}} embedded the image and
> [[Image:Some-nice_picture.jpg]] simply linked to the description page?

Well, it might well be too much to hope that all articles on
Wikipedia, and all old versions of those articles, could be either
converted to obey that rule or somehow activate a
"backwards-compatibility" mode.

Besides, while it makes sense that displaying an image is an
inclusion, this doesn't actually extend very well to, for instance,
sounds - unless we go the route of embedding plugins, sounds will
always be more like a fancy link than an "inclusion". (For an example
of what I think such a "fancy link" might look like, see my mockup at
http://meta.wikimedia.org/wiki/Multimedia#Software_features )

--

-- 
Rowan Collins BSc
[IMSoP]

Re: Re: Re: Intended changes to namespace management

On Wednesday, June 01, 2005 4:01 PM, Rowan Collins <rowan.collins <at> gmail.com>
wrote:

> On 01/06/05, Phil Boswell <phil.boswell <at> gmail.com> wrote:
> > I suppose it would be too much to hope that we could extend the {{}}
> > syntax to images, wherein {{Image:Some-nice_picture.jpg}} embedded the
> > image and [[Image:Some-nice_picture.jpg]] simply linked to the
> > description page? 
> 
> Well, it might well be too much to hope that all articles on
> Wikipedia, and all old versions of those articles, could be either
> converted to obey that rule or somehow activate a
> "backwards-compatibility" mode.
> 
> Besides, while it makes sense that displaying an image is an
> inclusion, this doesn't actually extend very well to, for instance,
> sounds - unless we go the route of embedding plugins, sounds will
> always be more like a fancy link than an "inclusion". (For an example
> of what I think such a "fancy link" might look like, see my mockup at
> http://meta.wikimedia.org/wiki/Multimedia#Software_features )

Hmm. If you link to a sound-file with {{Image:}} (or {{Sound:}} you'd want
to transclude it, even if the software won't let you. [[Sound:]] would then
be a link to the sound, and the overall manner of links would make more
sense.

Yours,
--

-- 
James D. Forrester -- Wikimedia: [[W:en:User:Jdforrester|James F.]]

Re: Re: Re: Intended changes to namespace management

On 01/06/05, James D. Forrester <james <at> jdforrester.org> wrote:
> Hmm. If you link to a sound-file with {{Image:}} (or {{Sound:}} you'd want
> to transclude it, even if the software won't let you. [[Sound:]] would then
> be a link to the sound, and the overall manner of links would make more
> sense.

Sorry, I don't follow what you're saying here - are you saying that
"transcluding a sound" *is* the same as displaying a specially
formatted set of links/player, or that it isn't? Like I say, I can see
how "transcluding an image" could mean displaying it inline, but I'm
not sure that "transcluding a sound" is really a meaningful concept.
At the moment, you can transclude the *description page*, but I don't
think anyone would really miss that ability.

Don't get me wrong, I can see the argument for having a different
syntax for "display inline" than for "link to", I'm just not 100%
convinced that this is logically the same as "transclude from".

--

-- 
Rowan Collins BSc
[IMSoP]

Re: image dump

On 01/06/05, james <jamessampford <at> supanet.com> wrote:
> just finished downloading the en image dump, tried extracting it with winrar -

> anyone of an extracter that does a folder intact job

http://download.wikimedia.org/images/README_ABOUT_FILE_FORMAT.txt
mentions how to extract them correctly under *NIX system - so one way
would be to get cygwin up and running. A quick search also turned up
this Windows port of a "libarchive" which seems like it may include a
compatible "tar" utility -
http://gnuwin32.sourceforge.net/packages/libarchive.htm

> once that is extracted - how will my wiki know where the images are for each
> artical, and thus include them within each artical?

For that, you need to download the "image" and "imagelinks" database
tables from http://download.wikimedia.org/#en.wikipedia to go with
your "cur" dump (the "imagelinks" one could probably be rebuilt
programmatically, but that's likely to be slower than just downloading
it).

--

-- 
Rowan Collins BSc
[IMSoP]