Hi All,
How is the translations box on Wiktionary (for example, see here:
http://en.wiktionary.org/wiki/power) achieved? Is it some kind of
template? What's the best way to do it?
Thanks,
JW
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
yurik(a)svn.wikimedia.org wrote:
> + list( $host, $lag ) = $wgLoadBalancer->getMaxLag();
> + $data[] = array (
> + 'host' => $host,
> + 'lag' => $lag);
While we're happy to tell everyone the hostnames of our own database
servers here at Wikimedia, as a general rule this would be considered an
information disclosure vulnerability.
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGkomhwRnhpk1wk44RAsOfAKCK6dv3YzvLzk9qOfmC9c1QRTpWtgCfb0K/
HLgK0roZb/p315oG1jXfl7A=
=FwHS
-----END PGP SIGNATURE-----
Hi! I need to evaluate some parameters related to Wikipedia systems
performance. Where can I find this kind of measurements (e.g. averaged
response times, averaged database acceses, averaged database access time,
squid hit rates, memcached uses,...)
thanks in advance...
Hello.
Something 'strange' is happening with 7zip dumps of the largest editions.
Jawiki page tells the 2007-06-06 dump is still in progress, while the 2007-07-02 dump seems to have finished, but reports 169.5 MB for the 7zip dump size. It is not possible, since the April 2007 dump had about 1,2 GB.
Same incorrect size for dewiki 2007-07-01 (reported as finished ok).
Even worse enwiki: 2007-04-02 link points to a list of md5 sums file, but no links to the acutal dumps, 2007-05-27 failed and 2007-06-28 seems to be aborted.
It's important that we can trust the dump process if we want to automate it using the new RSS feeds.
Any schedule for the next attempt for 7zip enwiki dump?
Thanks.
Felipe.
---------------------------------
Sé un Mejor Amante del Cine
¿Quieres saber cómo? ¡Deja que otras personas te ayuden!.
No wonder my wiki is so popular when measured according to bandwidth
needs. It's all brand name searchengines sniffing up those non-existent
page links. I'm not sure what ought to be done.
==> logs/radioscanningtw.jidanni.org/http.2880196/access.log <==
74.6.20.76 - - [05/Jul/2007:19:35:33 -0700] "GET /index.php?title=Talk:%E5%8F%B0%E4%B8%AD%E7%B8%A3%E8%AD%A6%E5%AF%9F%E5%B1%80%E6%9D%B1%E5%8B%A2%E5%88%86%E5%B1%80&action=edit HTTP/1.0" 200 4896 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)"
On 10/07/07, rainman(a)svn.wikimedia.org <rainman(a)svn.wikimedia.org> wrote:
> Revision: 23928
> Author: rainman
> Date: 2007-07-09 23:38:54 +0000 (Mon, 09 Jul 2007)
>
> Log Message:
> -----------
> Add --redirects-only switch to refreshLinks.php, which refreshes the redirect table, maybe this should be done by default as well.
It should.
Rob Church
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
robchurch(a)svn.wikimedia.org wrote:
> Make WatchlistEditor use arrays of strings, which are far less
> expensive than Title objects, so Brion can now add 5000 pages to his
> watchlist without sapping up all his memory. Also, use the current
> user's preference for raw edit box size, and while we're on the
> subject, use $wgUser to make the difference explicit.
Looking good - I can copy my entire en.wikipedia.org watchlist into my
local wiki without it breaking now. :)
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGkpGgwRnhpk1wk44RAsPHAKCEsa/U37ZjJyTwFHcsWdeynEP3/QCg2VX7
4K8Pm3K9rsKRdCIie/7RmHg=
=ZS9Y
-----END PGP SIGNATURE-----
Hi all,
I have some questions about the way the templating system would work in an
ideal world (not necessarily how it works today). I'm attempting to write a
template processor that mimics the ideal behavior of MW's templating engine.
I'm running into difficulties when considering edge cases. Take for example
four nested brackets: {{{{a}}}}
I would have thought that this was equivalent to calling the template whose
name is output after calling {{a}}. So if Template:A contains just "b", I'd
expect {{{{a}}}} to be equivalent to {{b}} - however this is not the case,
and the raw text "{{{{a}}}}" is returned.
In the #mediawiki IRC channel, someone helpfully suggested {{{{void}}{{a}}}}
- which does what I expected {{{{a}}}} to do. However, this doesn't really
help me from a requirements standpoint - as it doesn't answer whether
{{{{a}}}}'s behavior is an intentional, conscientious design choice, or
merely a missing feature.
Another thing I've noticed is that template parameters (three brackets) bind
more tightly than template calls (two brackets). So five brackets like this
{{{{{a}}}}} is similar to {{ {{{a}}} }}. However, six brackets like this
{{{{{{a}}}}}} resolves to {{{ {{{a}}} }}} and the inner parameter is
replaced leaving {{{a's value}}}. The outer triple is left as plain text.
Generally speaking, as long as there are breaks, it appears the parser can
figure out the intent, which is why {{{{void}}{{a}}}} succeeds where
{{{{a}}}} fails.
Any advice on how to handle these edge cases (nested brackets beyond 2 or 3)
would be much appreciated.
-- Jim R. Wilson (jimbojw)
remove matt(a)educause.edu
> -----Original Message-----
> From: wikitech-l-request(a)lists.wikimedia.org
> [mailto:wikitech-l-request@lists.wikimedia.org]
> Sent: Monday, July 09, 2007 1:51 PM
> To: wikitech-l(a)lists.wikimedia.org
> Subject: Wikitech-l Digest, Vol 48, Issue 20
>
> Send Wikitech-l mailing list submissions to
> wikitech-l(a)lists.wikimedia.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.wikimedia.org/mailman/listinfo/wikitech-l
> or, via email, send a message with subject or body 'help' to
> wikitech-l-request(a)lists.wikimedia.org
>
> You can reach the person managing the list at
> wikitech-l-owner(a)lists.wikimedia.org
>
> When replying, please edit your Subject line so it is more
> specific than "Re: Contents of Wikitech-l digest..."
>
>
> Today's Topics:
>
> 1. Re: userCan changes (Rob Church)
> 2. Re: userCan changes (Andrew Garrett)
> 3. Re: userCan changes (Simetrical)
> 4. Re: userCan changes (Rob Church)
> 5. Re: userCan changes (Andrew Garrett)
> 6. Re: userCan changes (Andrew Garrett)
> 7. Re: searchengines sniffing up non-existent page links
> (jidanni(a)jidanni.org)
> 8. Re: [MediaWiki-CVS] SVN: [23823] trunk/phase3 (Brion Vibber)
> 9. Re: [MediaWiki-CVS] SVN: [23823] trunk/phase3 (Yuri Astrakhan)
> 10. Re: searchengines sniffing up non-existent page links
> (Simetrical)
> 11. Re: [MediaWiki-CVS] SVN: [23895]
> trunk/phase3/includes/WatchlistEditor.php (Brion Vibber)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 9 Jul 2007 14:03:40 +0100
> From: "Rob Church" <robchur(a)gmail.com>
> Subject: Re: [Wikitech-l] userCan changes
> To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org>
> Message-ID:
> <e92136380707090603na823749l8a3668bd12db03fd(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 09/07/07, Andrew Garrett <andrew(a)epstone.net> wrote:
> > On second thoughts, I wonder if this'd make it harder to
> take and use
> > the parameters, which are passed back in the array currently, but
> > you'd have to do some string parsing to get them with your
> > suggestion...
>
> Yes, I thought of that one a minute ago, too.
>
> The main thing I'm concerned about here is that the first
> parameter be some sort of constant value, because message
> keys change for various reasons, and we want to be as free as
> possible to change them when needed without hunting down 49
> odd files...
>
> ...although I suppose we could just do a s/Simetrical// ;)
>
>
> Rob Church
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 9 Jul 2007 23:06:25 +1000
> From: "Andrew Garrett" <andrew(a)epstone.net>
> Subject: Re: [Wikitech-l] userCan changes
> To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org>
> Message-ID:
> <2916cbf60707090606r666d8f4ewff1b2f0224ef63(a)mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 7/9/07, Rob Church <robchur(a)gmail.com> wrote:
> > On 09/07/07, Andrew Garrett <andrew(a)epstone.net> wrote:
> > > On second thoughts, I wonder if this'd make it harder to take and
> > > use the parameters, which are passed back in the array currently,
> > > but you'd have to do some string parsing to get them with your
> > > suggestion...
> >
> > The main thing I'm concerned about here is that the first
> parameter be
> > some sort of constant value, because message keys change
> for various
> > reasons, and we want to be as free as possible to change them when
> > needed without hunting down 49 odd files...
>
> I suppose it wouldn't kill any small furry animals if we
> tacked a constant on the beginning and shifted it off before
> passing to call_user_func_array( 'wfMsg' )...
>
> >
> > ...although I suppose we could just do a s/Simetrical// ;)
> >
> >
> > Rob Church
> >
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 9 Jul 2007 09:08:22 -0400
> From: Simetrical <Simetrical+wikilist(a)gmail.com>
> Subject: Re: [Wikitech-l] userCan changes
> To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org>
> Message-ID:
> <7c2a12e20707090608l553e3022x4aa06451fcf6d1f2(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 7/9/07, Rob Church <robchur(a)gmail.com> wrote:
> > The main thing I'm concerned about here is that the first
> parameter be
> > some sort of constant value, because message keys change
> for various
> > reasons, and we want to be as free as possible to change them when
> > needed without hunting down 49 odd files...
> >
> > ...although I suppose we could just do a s/Simetrical// ;)
>
> For what it's worth, I agree constants are a better way to go. :P
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 9 Jul 2007 14:11:21 +0100
> From: "Rob Church" <robchur(a)gmail.com>
> Subject: Re: [Wikitech-l] userCan changes
> To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org>
> Message-ID:
> <e92136380707090611jd6212farb73c7a00098e5bc9(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 09/07/07, Andrew Garrett <andrew(a)epstone.net> wrote:
> > I suppose it wouldn't kill any small furry animals if we tacked a
> > constant on the beginning and shifted it off before passing to
> > call_user_func_array( 'wfMsg' )...
>
> You could just use the message key as the constant value, of
> course, then you wouldn't need to shift it off at all.
>
>
> Rob Church
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 9 Jul 2007 23:13:41 +1000
> From: "Andrew Garrett" <andrew(a)epstone.net>
> Subject: Re: [Wikitech-l] userCan changes
> To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org>
> Message-ID:
> <2916cbf60707090613g5a7afec8t27f54371da978ac2(a)mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 7/9/07, Rob Church <robchur(a)gmail.com> wrote:
> > On 09/07/07, Andrew Garrett <andrew(a)epstone.net> wrote:
> > > I suppose it wouldn't kill any small furry animals if we tacked a
> > > constant on the beginning and shifted it off before passing to
> > > call_user_func_array( 'wfMsg' )...
> >
> > You could just use the message key as the constant value,
> of course,
> > then you wouldn't need to shift it off at all.
> >
>
> That was my original intention. I was under the impression
> that your objection was that message keys can change, for
> various reasons, and that it would be better to have a
> separate constant that wasn't being used for anything else.
>
> >
> > Rob Church
>
> Andrew
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 9 Jul 2007 23:47:46 +1000
> From: "Andrew Garrett" <andrew(a)epstone.net>
> Subject: Re: [Wikitech-l] userCan changes
> To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org>
> Message-ID:
> <2916cbf60707090647v7eb49bc1jecb20a6b33ffd182(a)mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> After a conversation with Brion, my intentions have changed.
> I intend, now, to maintain userCan in its current form, as a
> wrapper for a new function which will have the changes made to it.
>
> Andrew
>
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 10 Jul 2007 03:05:53 +0800
> From: jidanni(a)jidanni.org
> Subject: Re: [Wikitech-l] searchengines sniffing up non-existent page
> links
> To: wikitech-l(a)lists.wikimedia.org
> Message-ID: <873azxflda.fsf(a)jidanni.org>
> Content-Type: text/plain; charset=us-ascii
>
> >>>>> "S" == Simetrical writes:
>
> S> robots.txt:
> S> Disallow: /index.php
>
> S> Assuming you're using URL rewriting, this will have the robots
> S> request only actual wiki pages, not edit pages/history pages/etc.
>
> Nice solution. (But sites that linked to your pages before
> rewriting will now have those links not indexed in search
> engines (minor issue).
> Also if rewriting was so cool, then it would be the default
> and one wouldn't need to follow instructions to implement
> it.) But mainly:
> those links should have nofollow in their <a> tags. OK, thanks.
>
>
>
> ------------------------------
>
> Message: 8
> Date: Mon, 09 Jul 2007 15:16:49 -0400
> From: Brion Vibber <brion(a)wikimedia.org>
> Subject: Re: [Wikitech-l] [MediaWiki-CVS] SVN: [23823] trunk/phase3
> To: wikitech-l(a)lists.wikimedia.org
> Message-ID: <469289A1.8030605(a)wikimedia.org>
> Content-Type: text/plain; charset=ISO-8859-1
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> yurik(a)svn.wikimedia.org wrote:
> > + list( $host, $lag ) =
> $wgLoadBalancer->getMaxLag();
> > + $data[] = array (
> > + 'host' => $host,
> > + 'lag' => $lag);
>
> While we're happy to tell everyone the hostnames of our own
> database servers here at Wikimedia, as a general rule this
> would be considered an information disclosure vulnerability.
>
> - -- brion vibber (brion @ wikimedia.org) -----BEGIN PGP
> SIGNATURE-----
> Version: GnuPG v1.4.2.2 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFGkomhwRnhpk1wk44RAsOfAKCK6dv3YzvLzk9qOfmC9c1QRTpWtgCfb0K/
> HLgK0roZb/p315oG1jXfl7A=
> =FwHS
> -----END PGP SIGNATURE-----
>
>
>
> ------------------------------
>
> Message: 9
> Date: Mon, 9 Jul 2007 15:28:45 -0400
> From: "Yuri Astrakhan" <yuriastrakhan(a)gmail.com>
> Subject: Re: [Wikitech-l] [MediaWiki-CVS] SVN: [23823] trunk/phase3
> To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org>
> Message-ID:
> <5bef50f90707091228ve10e470hca739c22e005cc60(a)mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> MediaWiki already exposes the most lagging server in the
> wiki.php (called from index.php):
> Any reason to hide others? Either we should hide all the db
> servers, or expose them all?
>
> function checkMaxLag( $maxLag ) {
> global $wgLoadBalancer;
> list( $host, $lag ) = $wgLoadBalancer->getMaxLag();
> if ( $lag > $maxLag ) {
> header( 'HTTP/1.1 503 Service Unavailable' );
> header( 'Retry-After: ' . max( intval( $maxLag ), 5 ) );
> header( 'X-Database-Lag: ' . intval( $lag ) );
> header( 'Content-Type: text/plain' );
> echo "Waiting for $host: $lag seconds lagged\n";
> return false;
> } else {
> return true;
> }
> }
>
>
> On 7/9/07, Brion Vibber <brion(a)wikimedia.org> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > yurik(a)svn.wikimedia.org wrote:
> > > + list( $host, $lag ) =
> $wgLoadBalancer->getMaxLag();
> > > + $data[] = array (
> > > + 'host' => $host,
> > > + 'lag' => $lag);
> >
> > While we're happy to tell everyone the hostnames of our own
> database
> > servers here at Wikimedia, as a general rule this would be
> considered
> > an information disclosure vulnerability.
> >
> > - -- brion vibber (brion @ wikimedia.org) -----BEGIN PGP
> > SIGNATURE-----
> > Version: GnuPG v1.4.2.2 (Darwin)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iD8DBQFGkomhwRnhpk1wk44RAsOfAKCK6dv3YzvLzk9qOfmC9c1QRTpWtgCfb0K/
> > HLgK0roZb/p315oG1jXfl7A=
> > =FwHS
> > -----END PGP SIGNATURE-----
> >
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l(a)lists.wikimedia.org
> > http://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
>
>
>
> ------------------------------
>
> Message: 10
> Date: Mon, 9 Jul 2007 15:43:18 -0400
> From: Simetrical <Simetrical+wikilist(a)gmail.com>
> Subject: Re: [Wikitech-l] searchengines sniffing up non-existent page
> links
> To: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org>
> Message-ID:
> <7c2a12e20707091243y6d1e60ddw14ddab8fedc59428(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 7/9/07, jidanni(a)jidanni.org <jidanni(a)jidanni.org> wrote:
> > Also if rewriting was so cool, then it would be the default and one
> > wouldn't need to follow instructions to implement it.
>
> It would be the default except it requires configuration that
> we can't necessarily do. We can't, for instance, predict
> what target directory you may want to use. If you install
> and /w/ and rewrite to /wiki/, great, but maybe you install
> to / or /mywiki/ or /wiki/ or want to rewrite to / or
> /mywiki/ or /w/. All we can do, which we *do* do if
> possible, is use index.php/ as the pseudo-directory to
> rewrite to, because we can guarantee that exists and should
> be unused by anything else.
>
> rel="nofollow" in those links might be reasonable anyway, of course.
>
>
>
> ------------------------------
>
> Message: 11
> Date: Mon, 09 Jul 2007 15:50:56 -0400
> From: Brion Vibber <brion(a)wikimedia.org>
> Subject: Re: [Wikitech-l] [MediaWiki-CVS] SVN: [23895]
> trunk/phase3/includes/WatchlistEditor.php
> To: wikitech-l(a)lists.wikimedia.org
> Message-ID: <469291A0.20503(a)wikimedia.org>
> Content-Type: text/plain; charset=ISO-8859-1
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> robchurch(a)svn.wikimedia.org wrote:
> > Make WatchlistEditor use arrays of strings, which are far less
> > expensive than Title objects, so Brion can now add 5000
> pages to his
> > watchlist without sapping up all his memory. Also, use the current
> > user's preference for raw edit box size, and while we're on the
> > subject, use $wgUser to make the difference explicit.
>
> Looking good - I can copy my entire en.wikipedia.org
> watchlist into my local wiki without it breaking now. :)
>
> - -- brion vibber (brion @ wikimedia.org) -----BEGIN PGP
> SIGNATURE-----
> Version: GnuPG v1.4.2.2 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFGkpGgwRnhpk1wk44RAsPHAKCEsa/U37ZjJyTwFHcsWdeynEP3/QCg2VX7
> 4K8Pm3K9rsKRdCIie/7RmHg=
> =ZS9Y
> -----END PGP SIGNATURE-----
>
>
>
> ------------------------------
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> http://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
> End of Wikitech-l Digest, Vol 48, Issue 20
> ******************************************
>