The autoreview feature for FlaggedRevs does not work in the Hungarian
Wikipedia because of a configuration problem with a group name. This
causes a lot of extra work for the patrollers, and a lot of extra
waiting for everyone else for their edits to appear.
It has been about forty days since I filed a bug about this; in the
meantime, I asked twice for help on wikitech-l (not to mention the
several personal emails and IRC messages I and other Hungarian editors
sent). After my first wikitech-l mail, there was a short and
unsuccessful attempt to fix the problem without actually understanding
what we asked for; before and after, in those seven weeks, nothing
happened.
This is very disappointing. To fix the bug, one would need to replace
all occurrences of 'confirmed' with 'trusted' in the huwiki flagrev
config file - that takes about 20 seconds. If one wanted to be
thorough about it and move users from the old group to the new, one
would need to construct an appropriate SQL query - maybe 5 more
minutes. There are about a hundred patrollers on hu.wikipedia
(including admins). If we suppose they only have to work one extra
minute a day each (a very unrealistic lower estimation), that adds up
to about sixty hours. Which is about a thousand times twenty seconds.
Is staff time really a thousand times more valuable than volunteer
time, so that no one can be bothered to make this trivial fix, even if
many hours of other people's time could be spared? I'm aware it is
summer, and Wikimania is going on, and everyone has a lot on their
hands, but even so I can't believe none of the people with shell
access can find a minute to make the fix.
Letting the time of the most active community members go to waste like
this is not only very discouraging them, and not only does it
undermine their trust in the revision flagging system (which proved to
be a very valuable anti-vandalism tool, but it was always hard to get
enough people involved), it also creates a rift between WMF and the
local community. People perceive that the foundation does not respect
their volunteer work at all, and it is only quick when it is creating
problems (their previous contact with WMF was when someone shot down
the statistics script that ran with community consensus, without as
much as a question or comment), and not when it should be solving
them.
If you want to broaden participation and involve more people into
meta-projects, start with actually caring about issues like these. And
now please, please find someone to finally fix bug 19885.
On Fri, Aug 28, 2009 at 12:46 PM, Anon Sricharoenchai<anon.hui(a)gmail.com> wrote:
> Hi,
>
> Some question about lucene-search-2 binary,
>
> 1. Do I need apache's lucene library when building lucene-search-2 binary?
> Or it is already included in lucene-search-2 source tree?
>
> 2. Did lucene-search-2 in wikimedia (before migration to 2.1) use the
> same binary as found in sourceforge,
> http://sourceforge.net/projects/lucene-search/files/ ?
>
> 3. Which version of lucene library is used to build binary found in
> sourceforge and in wikimedia?
>
> Best regards,
> Anon.
>
> _______________________________________________
> foundation-l mailing list
> foundation-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>
Forwarding to wikitech-l. Not a foundation-l issue and the people
on wikitech-l will probably be more helpful for this :)
-Chad
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi there,
in our wiki (http://wiki-de.genealogy.net) we have enabled user-to-user
mail and notifications of page edits.
Since we have changed
$wgPasswordSender = "Genwiki(a)genealogy.net";
$wgPasswordSender = "GenWiki Nachrichten <KeinEmpfang(a)genealogy.net>";
Mediawiki stops sending notifications (without any syslog entries at
wiki and mail hosts), but still remains sending user-to-user mail.
We are working with
$wgEnotifUserTalk = true;
$wgEnotifWatchlist = true;
and
$wgUserEmailUseReplyTo = true;
for well known reasons.
Has anybody suggestions which screw is to tighten?
THX in advance.
Uwe (Baumbach)
U.Baumbach(a)web.de
GenWiki - The wiki for German genealogists
- --
Besuchen Sie den 61. Deutschen Genealogentag!
11.-14. September 2009
http://www.genealogentag.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkqW/hgACgkQFEbayCH8zXlAjACgknRtV/epuzxahmsfiLfNWVp2
fDAAn1UwmY8Wf3cl0+xbX4piSspYOHhy
=YoU7
-----END PGP SIGNATURE-----
For various reasons I have noticed that several files independently compute the value of $IP. For example, maintenance/Command.inc and includes/WebStart.php both calculate its value. One would expect this value to be computed in one place only and used globally. The logical place is LocalSettings.php.
Sprinkling the computation of $IP all over the place is just looking for trouble. At some point the code used to make this computation may diverge and you will have bugs introduced. My first reaction to this problem was to wonder why these files didn't just require LocalSettings.php. However, since it is a fairly complex file doing so might not be desirable because: 1) there are values in LocalSettings.php that would interfere with values in these files, 2) there is some ordering problem that might occur, or 3) there are performance considerations.
If it isn't possible and or desirable to replace the distributed computation of $IP with require_once('LocalSettings.php'), then I suggest breaking LocalSettings into two parts, say LocalSettingsCore.php and LocalSettingsNonCore.php (I am sure someone can come up with better names). LocalSettingsCore.php would contain only those calculations and definitions that do not interfere with the core MW files. LocalSettingsNonCore.php would contain everything else now in LocalSettings.php. Obviously, the first candidate for inclusion in LocalSettingsCore.php is the computation of $IP. Once such a separation is carried out, files like maintenance/Command.inc and includes/WebStart.php can require_once('LocalSettingsCore.php') instead of independently computing $IP.
On Fri, Aug 14, 2009 at 5:23 AM, Gregory Maxwell<gmaxwell(a)gmail.com> wrote:
> On Thu, Aug 13, 2009 at 2:56 PM, Cox, Serita<Serita.Cox(a)bridgespan.org> wrote:
>> Google's new search engine, Caffeine, is supposedly kicking Wikipedia
>> entries further down results page. Thoughts? Comments?
>> http://software.silicon.com/applications/0,39024653,39484015,00.htm
> [from my comments in #wikimedia-tech the other day]
> "So— I tried 20 random words, and the WP result was lower in four of
> them, the same in the rest."
> "No pattern really... We still have the problem with "article at funny name;
> redirect from common name; common name search on google gives squat",
> which I consider to be much more major."
A simple solution to this is using the canonical tags which all major
search engines started supporting earlier this year.
<http://www.mattcutts.com/blog/canonical-link-tag/?
Wikia's GPL code to add this to MediaWiki is available here:
<https://wikia-code.com/wikia/trunk/extensions/wikia/CanonicalHref/Canonical…
More info on it in Nick's blog post at
<http://www.techyouruniverse.com/wikia/google-canonical-href-with-mediawiki>
Angela
New test results were added at
http://www.mediawiki.org/wiki/SVG_benchmarks
This looks even better than my first attempt. Nonetheless, it is clear
that batikd is not ready to use but needs to be worked on.
Okay, so I made this nice new Html class lately to mostly replace Xml
for HTML output. One of the major purposes of Xml, and now one of the
major purposes of Html, is to provide convenient wrapper functions for
particular elements that are more concise than Html::element( 'foo',
array( 'x' => 'y', 'z' => 'w' ) ). Here's what the input() method
currently looks like:
public static function input( $name, $value = null, $type =
'text', $attribs = array() ) {
There are three "special" attributes: name, value, and type. In the
Xml version, the special attributes are instead name, size, and value.
The problem with this is that 1) none of these three are actually
required, and at least two of the three frequently just use the
default; and 2) the order isn't obvious or easy to remember.
Moreover, in practice, the $attribs are usually specified, so the
parameter defaults don't help much. If we have "convenience"
shortcuts like this for many other elements, they'll indeed be more
concise, but hard to actually understand or use.
So we could do this . . .
public static function input( $attribs = array() ) {
. . . but that's not really convenient at all.
So one way that Xml handles this is to just have even more specialized
functions, like:
public static function hidden( $name, $value, $attribs = array() ) {
The nice thing here is that there's practically no reason you'd ever
want to make a hidden input without both name and value specified, but
often those are the only things you want to specify. So often you can
replace Html::element( 'input', array( 'type' => 'hidden', 'name' =>
'myName', 'value' => 'foo' ) ) with just Html::hidden( 'myName', 'foo'
), and that's pretty clear, since hidden inputs logically have two
things they almost always need to have specified, and there's an
obvious order (key then value).
So I'm thinking that the general tactic should be 1) have special
parameters for anything that's required or practically always used,
but 2) relegate everything else to the $attribs array. So if we had a
hypothetical Html::a(), it would look like:
public static function a( $href, $attribs = array() ) {
and img might be:
public static function img( $src, $alt, $attribs = array() ) {
On the other hand, this would mean you'd have to do something like
public static function input( $name, $attribs = array() ) {
which is fairly verbose in practice. Of course, as noted, you
normally need to use $attribs anyway for input, so it's not really
that much worse than necessary.
What are other people's thoughts on what a nice interface would look
like here? (Other than "PHP should have named parameters like
Python"? :) ) Xml is very inconsistent on this score, and it would
be nice if we had a consistent format for Html.
Hi,
with regard to the recent discussion on SSL, it would be
really nice to have the certificates issued by CAcert (whose
root certificate will not be included in many browsers for
some time) published on a trustworthy server (a footer on
<URI:https://www.wikimedia.org/> perhaps?). I'm primarily
thinking about the certificates for:
- wikitech.leuksman.com
- www.wikimedia.de
(Feel free to append if you encounter others.)
TIA,
Tim
Dear Jimmy Wales,
Could you ask those in charge to make the wikimedia.org mailing lists
searchable again?
There may be good reasons why they aren't,
but of course one cannot find them,
because they are not searchable!
Thanks.
--- On Mon, 8/24/09, Chad <innocentkiller(a)gmail.com> wrote:
> Why skip trying to find the location?
> If MW_INSTALL_PATH
> is already missing, what have we got to lose from trying
> to guess the location? The vast majority of people don't
> screw with the default structure, so it should be just
> fine.
That's a reasonable question, stating in another way the useful maxim, "if it ain't broke, don't fix it." The problem is I think it's "broke".
Here is my take on the pros/cons of leaving things unchanged:
Pros:
* Some administrators are used to simply typing the line php <utility>.php. Making them type:
MW_INSTALL_PATH=/var/wiki/mediawiki php <utility>.php
would be inconvenient.
In answer to this, for the MW installations running on unix, it is pretty simple to alias "MW_INSTALL_PATH=/var/wiki/mediawiki php" and put the definition into .bash_profile (or the appropriate shell initialization script). This is a one time effort and so the change isn't as onerous as it might seem. I assume there is a similar tactic available for windows systems.
Cons:
* The use of file position dependent code is a problem during development and much less of a problem during installation and production (as you suggest). Right now there are ~400 sub-directories in the extensions directory. It seems to me reorganization of the extensions directory would help understanding the relationship between individual extensions and the core. For example, having two subdirectories, one for cli utilities and another for hook based extensions would clarify the role each extension plays. However, currently there are 29 extensions where $IP is set using the relative position of the file in the MW directory structure (a couple of other extensions set $IP based on MW_INSTALL_PATH). Reorganizing the directory structure has the potential of breaking them.
* CLI utilities are moved around for reasons other than a reorganization of the extensions directory. For example, as I understand it, DumpHTML was moved from maintenance/ to extensions/. dumpHTML.php sets $IP based on its relative position in the distribution tree. It was a happy coincidence that when it was moved, its relative position didn't change. However, it is unreasonable to think such reclassifications will always be as fortunate.
Since the cons outweigh the pros, I remain convinced that the change I suggested (using die()) improves the code.
Dan