Somebody disabled miser mode on de.wikipedia.org in LocalSettings.php.
That may have been there for a while, I don't know, it wasn't labeled.
Heavy special pages on de were weighing down the database A LOT, so
I've taken it out and locked them off again. Load on suda has fallen
from 8-10 to 4-6 and response is much better.
I've also put the locks back on pl, and temporarily disabled the
'magic' parameter for bypassing miser mode.
-- brion vibber (brion @ pobox.com)
Hello,
I am willing to complete the languages localisations files. Lot of new
messages have been added to the software but are not localised in the
langages.php files, instead they have been customised through the mediawiki
namespaces.
My idea is to get a dump of the mediawiki namespaces for all wikipedias and
use it to update the different hardcoded langagesXX.php files through a
script to be build.
The script could:
1/ look at each value existing in the database
2/ if it doesnt exist add it
else ask what to do (ignore / update)
3/ generate new arrays
A problem I noticed, is that lot of mediawiki namespaces are using "/wiki/"
or "Wikipedia". What are the best variables to replace that ? I am thinking
about $wgScriptPath & {{ns:4}}, are they valid choices ?
Once the datas from wikipedia got imported, we could ask people to updates
the refreshed langagesXX.php files.
cheers,
--
Ashar Voultoiz
http://fr.wikipedia.org/Utilisateur:Hashar
OK, here's the plan:
1. We disallow the creation of new users (for the following, which won't
take long)
2. We add a "user_single_id" field in the user table of each wikipedia,
initially 0
3. We generate a list from all wikipedias, containing user name and user
password hash
4. We merge every two entries on our list (#3) that have both the same
name *and* the same password hash (same name and password = same user)
5. We create a new, separate user database
6. We fill it with all unique user names from our list, and fill the
"user_single_id" for every user with that name in all wikipedias the
"user_id" from the new database
7. We generate a new user in our new database for each remaining
'double' from out list; its password hash is blanked
8. We allow creating user names again (see, didn't take *that* long:-)
with the following mechanism:
* New users can *only* be created if that user name isn't already taken
in the new database, where it will then be added
* The 'local' wikipedia database gets a new user account as well, with
the "user_id" set to the "user_single_id" from the new database
A user trying to log in evokes the following rules:
* If there is no user in the local database with that name, password is
checked against the new database; if it matches, a local account is created
* If the "user_single_id" is *non-zero*, password is checked against the
new database
* If the "user_single_id" is *zero*, password is checked against the
local database
For any user with a conflicting user name, that means (s)he can still
log on to the usual wikis, but can't create new accounts on other
wikipedias under that name.
REASOING:
* Easy to set up (new db and a script)
* Minor changes to the MediaWiki scripts (login and preferences only)
* Minor changes to the database (adding a single field)
* Everyone can keep working under his/her username
* Most users can instantly enjoy the new, unified login
* Conflicting user names can be easily listed and resolved in time
* New functions (My contributions/Watchlist/Recent changes in all
wikipedias) can be introduced over time
Comments? Volunteers? ;-)
Magnus
Hi,
I notice that my watchlist takes significantly longer to load
than articles, diffs, edit pages or anything else. Is this
because it takes that long for the server to generate it? I
frequently reload my watchlist every 5 minutes or so, is this
bad? Does using more shared watchlists help? My watchlist is
of moderate size, a little over 1000. Thanks for any suggestions.
Arvind
--
Its all GNU to me
Once more I would like to ask whether someone would be willing to
actually start a Wikimedia project for the collection of images and
possibly other media files that can be used in Wikipedia and similar
projects. From reactions to earlier proposals of the same sort I am
getting the impression that this is not unlikely to work out well,
but I would need to have the wiki set up, the domain name decided
etcetera to actually be able to get started. If someone is both
willing and able to do so, then I would be delighted.
Andre Engels
Hello there,
This message is mostly for the core developper team (the guys that keep
flooding cvs with HUGE changes and new features).
As I still havent found any roadmap for the development of mediawiki, I
will assume the main page of test.wikipedia.org act as a roadmap.
The new features are:
* New skin
* Links in thumbnails
* Template syntax
* Tweaks to localisation
* Automatic conflig merging
* Greyed subsection in comments
* Categories
* XML Import
* RSS syndication
* Hieroglyphs
I am wondering if all of those are ready to make a 1.3 "stable" release or
if there is still some work to be done.
If everything is fine, what are we waiting for to release 1.3.0 ? If not
wich part should I look at and help finish ? ;)
cheers,
--
Ashar Voultoiz
http://fr.wikipedia.org/Utilisateur:Hashar
On Apr 22, 2004, at 16:06, Gabriel Wicke wrote:
> Modified Files:
> Language.php
> Log Message:
> sileced iconv for now
What messages were you getting out of it? I'd prefer to fix if
possible...
-- brion vibber (brion @ pobox.com)
It was mentioned on
http://apache.slashdot.org/article.pl?sid=04/03/26/1428225 that gopher
might expericence its second spring.
Is there any group which might find a gopher-wikipedia useful, such as
people without these great DSL modems and flat rate access? Any PC which
runs a gopher client will be able to run links or lynx, I guess.
The only 'real' use would be publicity. Chances are almost 1 to get a /.
mention for this...
Yours,
Mathais
--
nach uns der synflood.
On Apr 21, 2004, at 14:02, Luc Van Oostenryck wrote:
> Modified Files:
> SpecialDeadendpages.php
> Log Message:
> Don't include redirects in dead-end pages
By definition there should *be* no dead-end redirects, unless they are
faulty. So... we'd _want_ to see them if there are any, right?
-- brion vibber (brion @ pobox.com)
I really don't think it's a good idea to have separate hard-coded logo
image files for IE and everything else. It's already bad enough that
you have to overwrite files installed as part of MediaWiki to set the
logo displayed by Monobook (*separately* from the other skins), now you
have to do two, and remember to do the one that your browser never
shows?
It just seems like a lot of trouble to maintain.
-- brion vibber (brion @ pobox.com)