This has probably been discussed before, but why does mediawiki (or at
least, wikipedia) default to showing the interface in the language of
the wikipedia, rather than in the language of the browser? E.g., when
I visit ru.wikipedia.org, common sense dictates that the interface
should be shown in English, the language defined in my browser
preferences. Sure, I can change it by creating an account and defining
my preferences, but even that is difficult enough on a foreign
language Wikipedia, and extremely difficult for a non-Roman script.
What's the thinking here?
Steve
I've been trying to compile an overview of what the various
WikiProjects on the Swedish and Norwegian Wikipedias (sv,no,nn)
have accomplished. The reason is that some of the best work is
done within WikiProjects, and I want to find success factors and
bring inspiration for other projects to improve.
Most projects have a list of participants and some way to indicate
which articles they try to cover. However, the people who do
actual work within a project are not necessearily the same who
have listed themselves as participants. And an edit in an article
isn't necessarily "part of" the project. For example, if I edit
[[Napoleon]] to describe a disease he had, that edit is possibly
part of WikiProject Medicine, but not part of WikiProject War.
To better assess the amount of activity within each project, it
would really help if each edit could be tagged as belonging to a
WikiProject. This is how I think it could work: In order not to
make things complicated for beginners, the default behaviour will
be just as it is today. But in the personal settings, I should be
able to specify a list of tags for tasks, projects or teams that
I'm involved in. The elements of this list would then appear as a
<select><option> drop-down in the edit page. If a tag is
selected, it is saved in the revision history and can perhaps be
seen in RecentChanges and article history. Recent Changes and user
contributions could use these tags as selectors, so you could get
a recent changes per WikiProject.
This is just a suggestion. I'm not about to implement this. If
you think this is a good idea, feel free to use it.
What I propose is just a single, free form plain text tag to be
associated with each edit. I don't suggest that the system must
verify that such a WikiProject exists. The scheme is not limited
to WikiProjects. But there is where I see its first use.
Here are two examples of team statistics on other websites, that
might serve as further inspiration:
On PGDP.net (Project Gutenberg's Distributed Proofreaders)
volunteers proofread pages from scanned books. It's also a
competition to get a high page count. But members can join teams
and teams compete on the sum of their members' page counts.
On LibraryThing.com, members are able to catalog their personal
libraries and bookshelves. They can also join discussion groups,
and each group has a list of which members have the most books. A
sum of counts is also presented for each group.
--
Lars Aronsson (lars(a)aronsson.se)
Aronsson Datateknik - http://aronsson.se
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
Recently I volunteered to help establish a system for providing an
extension manager\repository combination for MediaWiki. During this
time I have devoted some thought regarding how such a system would work,
here I hope to summarize what ideas have been bounced around so far and
stimulate further discussion that can be built upon.
To begin with, most of my effort went into designing and building a
repository, doing this first was a bad idea, however; a manager that can
be used without a repository is needed first before the specification
for a repository can be made. Regardless thought has already been put
into this (mostly in IRC discussions on #mediawiki) so it would be
worthwhile listing ideas them here.
- It is *extremely* dangerous to create a system that automatically
downloads files that will be executed from the Internet and installed
into an environment such as MediaWiki, if the repository that is being
used is compromised via DNS spoofing or similar attacks, arbitrary
access to the file system the client MediaWiki is running on and any
data held in the wiki could be made available (without anyone knowing,
if the malicious attack was crafted carefully).
- For this reason signing should be used to facilitate transferring
files between the repository and MediaWiki in a way similar to aptitude
(Linux package manager). Perhaps done using SSL or some other system
(maybe using public\private keys).
- It should be possible for multiple repositories to be hosted, even
if an official one were to exist some projects might like to have one so
that their wikis can access custom extension and many other reasons.
Once I develop my repository system I plan to release it under an open
source license in a generalized way so it could be used by third parties
as well as on a pseudo-official one probably hosted on the toolserver
(maybe even the stable server after a while).
- Due to the high demand such a system would receive static
generated information would be desirable as opposed to a dynamic API.
- Support for different versions of MediaWiki would be essential,
presumably from the version of MediaWiki available when the extension
manager is released onwards (therefore future backwards compatibility
would be essential).
That's all I could think of for the repository, please add more in a
reply if you can think of anything.
Moving on to the client (extension manager) many more factors would have
to be covered.
- One of the earliest problems I encountered was providing a system
for updating configuration, it would be very difficult to maintain
variables in a file so moving to configuration in the database is
probably the only choice here (possibly both a database based and file
based choices, but this could become hard to maintain). Validation on
input would be required and so more coding would need to be made by
extension authors (or the repository managers, if the maintainer of the
extension wasn't willing to put effort into validation functions), this
could probably be done using a configuration class for each extension
extend from a main configuration class. This would most likely fit best
into a separate configuration file so it could be loaded without the
rest of the extension.
And I've gone and put all my points about an extension manager client
into one bullet, discussion about this would be great; at least now I've
written it out I understand better what it is I was planning so
hopefully (providing someone doesn't find any flaws in my ideas) I might
be able to start some coding. For now this will most likely have to
stay as an extension as it will be too unstable to begin with, but
hopefully once the project takes off it could be bundled in core along
with a few common extension (which would then be able to be installed
without configuration file editing due to this interface). Perhaps
even, in the long run, the bulk of configuration could be moved into a
configuration manager special page and validation classes -- this would
certainly help many users.
If anyone else would like to contribute to an extension manager (I've
noticed a couple of other people interested on IRC) maybe we could set
up an IRC channel and collaborate on it -- work out some UI mock-ups,
design basic code, discuss ideas in greater detail etc. -- if not I'll
work out some basic code that can then be expanded on or twisted as
required by anyone who wants to help.
Thanks,
MinuteElectron.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkfdlGoACgkQkJvUlhoE3wSEWQCgt4NQuEJuNIVKJUKo4Z9itOEk
cAYAn2WMTMrfz7dtwUgI9PjFrLs6qk+P
=QsBY
-----END PGP SIGNATURE-----
On Thu, Mar 20, 2008 at 5:20 AM, <vasilievvv(a)svn.wikimedia.org> wrote:
> * cat_hidden doesn't work. why?
Because it was added for future use. I've noted this in tables.sql.
On Thu, Mar 20, 2008 at 7:20 AM, <raymond(a)svn.wikimedia.org> wrote:
> - $r = '<table cellpadding="0" cellspacing="0" border="0"><tr>';
> + $r = '<table class="mw-cl-cbg" cellpadding="0" cellspacing="0" border="0"><tr>';
As a general rule, cryptic abbreviations like "mw-cl-cbg" are probably
not the best choices for this kind of thing. We're not going to run
out of letters if you use 15- or 20-character class names. Something
like "mw-changes-block" would probably be better, and something like
"mw-changes-item" for "mw-cl-rci".
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
We had some sort of network outage starting a bit after midnight UTC;
heavy packet loss (33%-39% range) was visible on a number of networks,
and the Tampa servers became difficult to reach for a time.
Additionally, there was some DST packet overload on our primary load
balancer, making the wikis inaccessible through it.
Packet loss was largely reduced by about 01:05 UTC; some poking at the
load balancer apparently reset things to where it was happy with the
network again by around 01:18 UTC.
Sites are accessible and seem reasonably happy at this time.
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkffGwsACgkQwRnhpk1wk47FGQCg0zfrzTU4A8UTq3dKMhu+NDN2
0c8An01aTNr+oWq+M4/m66PVRTC+YJmc
=DaL1
-----END PGP SIGNATURE-----
I'd like to see this generate the TOC for {{:Page}}, but not include the
content.
Links in the TOC should go to the original location in Page.
This would enable me to drastically reduce the giant wiki page at
http://wiki.laptop.org/go/VistA_Monograph_Wiki
to a more reasonable size.
Something along like:
http://wiki.laptop.org/go/WV_VM
--
Drew Einhorn
Brion and I are planning a pilot of the CentralAuth (account merging and
unification) extension on Wikimedia wikis. The general idea is to enable
it for admins only for the duration of this pilot. Admins make good beta
testers for this extension because:
* They're responsible enough to report bugs instead of ignoring them
* They're more likely to use their first hand experience to write
documentation or otherwise pass on their knowledge to others
* Allowing admins first choice of username reduces the potential for
name-squatting by trolls
Access to global usernames is generally on a first-come, first-served
basis. We can deal with imposters when we have to, but it's going to be a
pain so it's best if we can keep the number of incidents a minimum.
Also, we hope that limiting it to admins will make the volume of support
requests more manageable.
I don't think we'll need to schedule an exact time, or set a site notice
or anything like that. When we accidentally enabled it for a brief period
last week, hundreds of people knew about it within half an hour. It
appears on the first page of your preferences when it's enabled, and word
spreads fast.
For general information about CentralAuth, please read the documentation at:
http://meta.wikimedia.org/wiki/Help:Unified_login
-- Tim Starling
Hello. I tried many hooks, but I cannot find any, with which I can use for overwriting variale, that is defined in the LocalSettings.php. Any suggestions? Thanks. -MGrabovsky