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 midom.li...@gmail.com 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
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
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 nos...@vyznev.net wrote:
On 07/20/2010 09:51 AM, paolo massa wrote:
Thanks Gregor and yes, you are right.
I didn't think about
On 28 July 2010 21:13, jida...@jidanni.org 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
On 2 August 2010 12:13, Oldak Quill oldakqu...@gmail.com wrote:
On 28 July 2010 20:13, jida...@jidanni.org 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
2010/8/2 Tei oscar.vi...@gmail.com:
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
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 at
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 tstarl...@wikimedia.org 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
(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 mill...@gmail.com wrote:
Please, tell me which data you need for setting up a project?
According to my information, data are:
* language
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 not be
On Mon, Aug 2, 2010 at 11:24 PM, Roan Kattouw roan.katt...@gmail.com 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
On Mon, Aug 2, 2010 at 11:45 PM, Milos Rancic mill...@gmail.com 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
On 2 August 2010 15:24, Roan Kattouw roan.katt...@gmail.com 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
On Mon, Aug 2, 2010 at 10:50 AM, John Vandenberg jay...@gmail.com 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.
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, and
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 from,
On Wed, Jul 28, 2010 at 2:37 AM, church.of.emacs.ml
church.of.emacs...@googlemail.com 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
On Mon, Aug 2, 2010 at 4:59 PM, Jason A. Spiro jasonspi...@gmail.com 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
On Mon, Aug 2, 2010 at 5:18 PM, Aryeh Gregor
simetrical+wikil...@gmail.com wrote:
On Mon, Aug 2, 2010 at 4:59 PM, Jason A. Spiro jasonspi...@gmail.com wrote:
Has anyone ever done usability studies of newbies -- new Internet
users, experienced Internet users who are non-editors, or new
On Mon, Aug 2, 2010 at 5:28 PM, Jason A. Spiro jasonspi...@gmail.com 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
Στις 02-08-2010, ημέρα Δευ, και ώρα 17:36 -0400, ο/η Aryeh Gregor
έγραψε:
On Mon, Aug 2, 2010 at 5:28 PM, Jason A. Spiro jasonspi...@gmail.com 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
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 revision
2010/8/2 Aryeh Gregor simetrical+wikil...@gmail.com:
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
Павел Петроченко 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 a
On Mon, Aug 2, 2010 at 6:45 PM, Victor Vasiliev vasi...@gmail.com 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
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 usabilitywiki
On Mon, Aug 2, 2010 at 10:16 AM, Lane, Ryan
ryan.l...@ocean.navo.navy.mil 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
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, apart
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 stable
2010/8/3 Platonides platoni...@gmail.com:
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,
On Mon, Aug 2, 2010 at 7:35 PM, Ryan Lane rlan...@gmail.com 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
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 system.
Note
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
On Mon, Aug 2, 2010 at 5:36 PM, Aryeh Gregor
simetrical+wikil...@gmail.com wrote:
On Mon, Aug 2, 2010 at 5:28 PM, Jason A. Spiro jasonspi...@gmail.com wrote:
Does the difference really matter so much that we must really use the
more-obscure and more-technical term bytes?
In English, maybe
On Tue, Aug 3, 2010 at 2:53 PM, Jason A. Spiro jasonspi...@gmail.com 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),
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
-- Forwarded message --
From: Noman nom...@gmail.com
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
On 8/3/10, Aryeh Gregor simetrical+wikil...@gmail.com 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
43 matches
Mail list logo