Hi!
> I.e., only about a quarter of users have been ported to
> user_properties. Why wasn't a conversion script run here?
In theory if all properties are at defaults, user shouldn't be there. The
actual check should be against the blob field.
Domas
_
On Mon, Aug 2, 2010 at 5:35 PM, Domas Mituzas wrote:
> Hi!
>
>> I.e., only about a quarter of users have been ported to
>> user_properties. Why wasn't a conversion script run here?
>
> In theory if all properties are at defaults, user shouldn't be there. The
> actual check should be against the
> That's what he did. Read the query.
;-) thats what happens when email gets ahead of coffee.
Domas
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hoi,
The big problem with upgrading MediaWiki is the upgrading of extensions. It
is not documented anywhere if extensions will work with a specific release
of MediaWiki. Being able to install extensions is a great thing when you
know upfront that the extensions you are interested in will actually w
Yep, thanks to your email, I realized a "mini dump" extracted randomly
is enough for my purposes.
Thanks Ilmari!
P.
On Tue, Jul 20, 2010 at 1:25 PM, Ilmari Karonen wrote:
> On 07/20/2010 09:51 AM, paolo massa wrote:
>> Thanks Gregor and yes, you are right.
>> I didn't think about your suggestio
On 28 July 2010 21:13, wrote:
> Seems to me playing the role of the average dumb user, that
> en.wikipedia.org is one of the rather slow websites of the many websites
> I browse.
>
> No matter what browser, it takes more seconds from the time I click on a
> link to the time when the first bytes o
On 28 July 2010 20:13, wrote:
> Seems to me playing the role of the average dumb user, that
> en.wikipedia.org is one of the rather slow websites of the many websites
> I browse.
>
> No matter what browser, it takes more seconds from the time I click on a
> link to the time when the first bytes o
On 2 August 2010 12:13, Oldak Quill wrote:
> On 28 July 2010 20:13, wrote:
>> Seems to me playing the role of the average dumb user, that
>> en.wikipedia.org is one of the rather slow websites of the many websites
>> I browse.
>>
>> No matter what browser, it takes more seconds from the time I c
> The first load of the homepage can be slow:
> http://zerror.com/unorganized/wika/lader1.png
> http://en.wikipedia.org/wiki/Main_Page
> (I need a bigger monitor, the escalator don't fit on my screen)
well, no wonder that first page load is sluggish, with 12 style sheets, and 12
javascript files
On 2 August 2010 13:25, Domas Mituzas wrote:
>> The first load of the homepage can be slow:
>> http://zerror.com/unorganized/wika/lader1.png
>> http://en.wikipedia.org/wiki/Main_Page
>> (I need a bigger monitor, the escalator don't fit on my screen)
>
> well, no wonder that first page load is slug
Hi,
Thanks for the detailed answer.
I have put some feedback on [1]. Unfortunately, on the sandbox page [2] the
wizard did not work. I think, it might already provide some functionalities
that I was suggesting. Could anyone point me to some page where it is working
properly on Firefox 3.6.8 Wi
2010/8/2 Michelle Knight :
> Hi,
>
> Upon creating a Selenium test to run through the Navigable Table of Contents
> on
> http://prototype.wikimedia.org/en-wp/index.php?title=Manchester_Small-Scale_Experimental_Machine&action=submit#External_links,
> I noticed the instruction:
> Verify that moving t
2010/8/2 Gerard Meijssen :
> Hoi,
> The big problem with upgrading MediaWiki is the upgrading of extensions. It
> is not documented anywhere if extensions will work with a specific release
> of MediaWiki. Being able to install extensions is a great thing when you
> know upfront that the extensions
2010/8/2 Tei :
> Maybe a theme can get the individual icons that the theme use, and
> combine it all in a single png file.
>
This technique is called spriting, and the single combined image file
is called a sprite. We've done this with e.g. the enhanced toolbar
buttons, but it doesn't work in all c
Please, tell me which data you need for setting up a project?
According to my information, data are:
* language
* language code
* type of project (Wikipedia, Wikinews etc.)
* logo
* the name of project in local language
* the name of the project namespace
* the name of the project talk namespace
> We branch and tag extensions along with versions of MediaWiki, so the
> code found at
> http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_15_5/extensions/
> is supposed to work with MW 1.15.5. However, this assumes that the
> trunk version of each extension worked with the trunk version of MW
> I've been looking at how WP works here and concluded this is
> basically not
> documented at all (from a developers perspective). On the WP
> IRC nobody
> seems to know anything about it, and my looking through the
> code itself has
> gotten me few insights into how updates and installation is
On Fri, Jul 30, 2010 at 06:35, Tim Starling wrote:
> However, the statistics presented by Qualys show that an alarming
> number of people are running versions of MediaWiki older than 1.14.1,
> which was the most recent fix for an XSS vulnerability exploitable
> without special privileges. There is
(CCing Rob and Jens who've traditionally been the major wiki creators
and also Roan, who helps out a lot. :-))
On Mon, Aug 2, 2010 at 9:45 AM, Milos Rancic wrote:
> Please, tell me which data you need for setting up a project?
> According to my information, data are:
>
> * language
I don't think
Hoi,
Pointing out that the maintainer of an extension is responsible for a proper
functioning of an extensions tells me who to blame. For a tool intended to
upgrade a MediaWiki environment this is hardly relevant particularly for
the extensions that the WMF does not run itself there is no way of k
On 02.08.2010, 18:01 Jacopo wrote:
> My gut feeling is that the "preference" for 1.12 is simply due to its
> inclusion in Debian stable [1]. The maintainer seems to be actively
> backporting security fixes [2], so while I agree that these versions
> may enjoy less community support, they should no
> I haven't read all the documents, but have these researchers taken
> into account backported fixes?
>
> My gut feeling is that the "preference" for 1.12 is simply due to its
> inclusion in Debian stable [1]. The maintainer seems to be actively
> backporting security fixes [2], so while I agree t
On Mon, Aug 2, 2010 at 11:24 PM, Roan Kattouw wrote:
> The resourceloader branch contains work in progress on aggressively
> combining and minifying JavaScript and CSS. The mapping of one
> resource = one file will be preserved, but the mapping of one resource
> = one REQUEST will die: it'll be po
On Mon, Aug 2, 2010 at 11:45 PM, Milos Rancic wrote:
> Please, tell me which data you need for setting up a project?
> According to my information, data are:
>
> * language
> * language code
> * type of project (Wikipedia, Wikinews etc.)
> * logo
> * the name of project in local language
> * the n
On 2 August 2010 15:24, Roan Kattouw wrote:
...
>> Maybe the idea than resource=file must die in 2011 internet :-/
>>
> The resourceloader branch contains work in progress on aggressively
> combining and minifying JavaScript and CSS. The mapping of one
> resource = one file will be preserved, but
On Mon, Aug 2, 2010 at 10:50 AM, John Vandenberg wrote:
> Does that approach gain much over HTTP pipelining?
Yes, because browsers don't HTTP pipeline in practice, because
transparent proxies at ISPs cause sites to break if they do that, and
there's no reliable way to detect them. Opera does pip
> Would it not be enough to hash all extensions on the distributor side, and
> to check the hash sum on the client side using https for the connection?
I guess this would suffice for ensuring integrity, but what about the other
distribution meta-data? Where to get it from, how to manipulate it, an
Hi guys,
At the moment we are discussing an opportunity to create full scale
true WYSIWYG client for media wiki. To the moment we have a technology
which should allow us to implement with a good quality and quite fast.
Unfortunately we are not sure
if there is a real need/interest for having such
Casey, thanks for pointing to the previous bug request!
John, thanks for the info for Wikisource!
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Jeroen De Dauw wrote:
>> Would it not be enough to hash all extensions on the distributor side, and
>> to check the hash sum on the client side using https for the connection?
>
> I guess this would suffice for ensuring integrity, but what about the other
> distribution meta-data? Where to get it
On Wed, Jul 28, 2010 at 2:37 AM, church.of.emacs.ml
wrote:
>
> On 07/28/2010 04:57 AM, Jason Spiro wrote:
>>
>> I think it would be nice for both "View history"[1] and "User contributions"
>> to
>> show bytes added/removed. This would make it easier to distinguish between
>> small contributions
On Mon, Aug 2, 2010 at 4:59 PM, Jason A. Spiro wrote:
> Has anyone ever done usability studies of newbies -- new Internet
> users, experienced Internet users who are non-editors, or new editors?
Yep, that's what the Usability Initiative does.
> Have the study conductors watched how they play wi
On Mon, Aug 2, 2010 at 5:18 PM, Aryeh Gregor
wrote:
>
> On Mon, Aug 2, 2010 at 4:59 PM, Jason A. Spiro wrote:
>
>> Has anyone ever done usability studies of newbies -- new Internet
>> users, experienced Internet users who are non-editors, or new editors?
>
> Yep, that's what the Usability Initiat
On Mon, Aug 2, 2010 at 5:28 PM, Jason A. Spiro wrote:
> Does the difference really matter so much that we must really use the
> more-obscure and more-technical term "bytes"?
In English, maybe not. In a lot of languages, they'll differ by a
somewhat unpredictable factor that can be as high as thr
Στις 02-08-2010, ημέρα Δευ, και ώρα 17:36 -0400, ο/η Aryeh Gregor
έγραψε:
> On Mon, Aug 2, 2010 at 5:28 PM, Jason A. Spiro wrote:
> > Does the difference really matter so much that we must really use the
> > more-obscure and more-technical term "bytes"?
>
> In English, maybe not. In a lot of lan
On 08/03/2010 01:48 AM, Ariel T. Glenn wrote:
> I would love it if the indicator was in characters instead of bytes.
> That's more meaningful for almost every project. Readers are looking at
> text after all, not at raw strings.
>
> Ariel
>
That would require introduction of another field to revi
2010/8/2 Aryeh Gregor :
> That I don't know. I don't know if descriptions of the Usability
> Initiative's studies are all public, or what. Maybe one of them could
> fill us in.
There are videos around, yes, but I'm not sure we have reports.
Digging around on usabilitywiki should turn stuff up, or
Павел Петроченко wrote:
> Hi guys,
>
> At the moment we are discussing an opportunity to create full scale
> true WYSIWYG client for media wiki. To the moment we have a technology
> which should allow us to implement with a good quality and quite fast.
> Unfortunately we are not sure
> if there is
On Mon, Aug 2, 2010 at 6:45 PM, Victor Vasiliev wrote:
> That would require introduction of another field to revision table,
> since byte count is not convertible to characher count in UTF-8.
No, we'd just have to repurpose rev_len to mean "characters" instead
of "bytes", and update all the old r
Roan Kattouw wrote:
> 2010/8/2 Aryeh Gregor:
>> That I don't know. I don't know if descriptions of the Usability
>> Initiative's studies are all public, or what. Maybe one of them could
>> fill us in.
> There are videos around, yes, but I'm not sure we have reports.
> Digging around on usabilityw
On Mon, Aug 2, 2010 at 10:16 AM, Lane, Ryan
wrote:
> Please Debian, keep your version of MediaWiki up to date at least to the
> oldest stable release, and please send your fixes upstream when you find
> unfixed bugs.
I am not a Debian developer, and I agree that sending fixes upstream
is good. Bu
Excerpts from Carl (CBM)'s message of Mon Aug 02 19:06:42 -0400 2010:
> I am not a Debian developer, and I agree that sending fixes upstream
> is good. But surely you're aware that the whole point of "Debian
> stable" is that it does ***not*** change to newer versions of programs
> after release, a
On 8/2/10 9:29 AM, Павел Петроченко wrote:
> Hi guys,
>
> At the moment we are discussing an opportunity to create full scale
> true WYSIWYG client for media wiki. To the moment we have a technology
> which should allow us to implement with a good quality and quite fast.
> Unfortunately we are not
> I am not a Debian developer, and I agree that sending fixes upstream
> is good. But surely you're aware that the whole point of "Debian
> stable" is that it does ***not*** change to newer versions of programs
> after release, apart from security fixes? Debian is well known for
> taking the word "
2010/8/3 Platonides :
> Were they asked to "Make this page appear under this different name"?
>
No, they were not. As I said, the focus was editing and general site
navigation, not viewing history, moving pages or a zillion other
things that, while they may appear elementary to us, are rather
advan
On Mon, Aug 2, 2010 at 7:35 PM, Ryan Lane wrote:
> Are they also backporting security fixes for all extensions as well?
I would assume that Debian, ideally, applies security patches for
extensions they distribute themselves. Programs a user has installed
outside the Debian system are always going
>> If Debian doesn't feel they should keep supported versions in their
>> repos, maybe they shouldn't distribute MediaWiki.
>
> That is, seriously, an absurd attitude for a Mediawiki Developer to
> have. It reflects a fundamental misunderstanding of the meaning of
> Debian's "stable version" syste
On 08/01/2010 10:55 PM, Aryeh Gregor wrote:
> One easy hack to reduce this problem is just to only provide a few
> options for stub threshold, as we do with thumbnail size. Although
> this is only useful if we cache pages with nonzero stub threshold . .
> . why don't we do that? Too much fragment
On Mon, Aug 2, 2010 at 5:36 PM, Aryeh Gregor
wrote:
>
> On Mon, Aug 2, 2010 at 5:28 PM, Jason A. Spiro wrote:
>>
>> Does the difference really matter so much that we must really use the
>> more-obscure and more-technical term "bytes"?
>
> In English, maybe not. In a lot of languages, they'll dif
On Tue, Aug 3, 2010 at 2:53 PM, Jason A. Spiro wrote:
> A question for the non-English wiki contributors out there: Do you
> honestly care that MediaWiki shows byte counts and not character
> counts? If so, why do you care?
If the count itself is useful (I don't think it is), then it is
probabl
Hi,
i've installed mediawiki for a wiki project.
now we have 4 sections on main page . like there are on wikipedia main page.
Now as its done in wikipedia these 4 boxes are tables and update on date
criteria.
Now i want to do is to give some kind a navigation bar like drop down or
paging.
so when
-- Forwarded message --
From: Noman
Date: Tue, Aug 3, 2010 at 10:04 AM
Subject: chanfing main page articles from drop down. help required
To: wikitech-l@lists.wikimedia.org
how
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
On 8/3/10, Aryeh Gregor wrote:
> No, we'd just have to repurpose rev_len to mean "characters" instead
> of "bytes", and update all the old rows. We don't actually need the
> byte count for anything, do we?
Byte count is used. For example in Chinese Wikipedia, one of the
criteria of "Did you know
This is a policy requirement, not a technical requirement, and can surely be
adjusted.
Am 03.08.2010 07:14, schrieb Liangent:
> On 8/3/10, Aryeh Gregor wrote:
>> No, we'd just have to repurpose rev_len to mean "characters" instead
>> of "bytes", and update all the old rows. We don't actually nee
* Noman [Tue, 3 Aug 2010 10:04:47 +0500]:
> Hi,
> i've installed mediawiki for a wiki project.
> now we have 4 sections on main page . like there are on wikipedia main
> page.
>
> Now as its done in wikipedia these 4 boxes are tables and update on
date
> criteria.
>
> Now i want to do is to give
55 matches
Mail list logo
