Hi,
I have just joined, I am from mumbai, india. I would like to get the
articles translated in marathi, my mother tongue. Looking at the effort
and no of volunteers, this will not be usable in any reasonable amount
of time.
That has made me think of alternatives - machine translation. A state
funded institute has a software available but I don't have access to it
yet.
Pl. comment about this approach. Has this been tried for any other
language earlier.
Thanks & regards,
Prasad Gadgil
________________________________________________________________________
Yahoo! India Matrimony: Find your life partner online
Go to: http://yahoo.shaadi.com/india-matrimony
Hello,
As wikipedia is slow at the busy time, I propose to get some new servers for our cluster.
- Some new web servers(3 or 4), P4 2,8Ghz with 2Go of RAM
- A server which could be a backup for nfs server, zwinger, with bigger disk, 80Go is very low, maybe 200 or 250Go
- Upgrading disk of zwinger to 200 or 250Go (or add a new one)
- A db server in 64 bits mode with 4Go of RAM (if we cant make working geoffrin), like this one :
http://www.macomp.com/products/servers/patriot2200.asp
With raid 10 disk system, 4 or 6 drives in raid and 1 stand-by. I prefer 15000rpm disk, but I can understand that they are more expensive
- Maybe another squid server
What do you think of that ?
Shaihulud
The Wikimedia board would be willing to make a trial of the developer
payment option upon a task : membership.
We chose this task because it is not specifically a wikipedia (or other
projects) task, but one primarily interesting the foundation.
We also chose it because basically no previous work as been done by
anyone yet on it.
We finally chose this task, because we would like membership to be set
before 2005.
I thought of describing the task... and after reading Tim Starling mail
this morning, I decided not to go very far in details :-)
Roughly, the goal is
* to add to preferences a mention of default joining the foundation when
creating an account, and adding a link to an opt-out option
* set a form to join as a contributing member. The paiement itself
should be multilingual, include several different amounts, and allow the
person to enter a preference for use of part of the fee. Generate a tax
receipt for us contributors (desactivated for now).
* Find a solution to add as contributing members, editors who paid fees
in a local chapter.
* store all data about the member as "confidential" data (another db or
encryption). Make it available automatically for voting.
* Generate an access and interface of some sort, so that someone can
consult/manage the list of members.
I may forget points of course. Comments welcome :-)
Since we have little idea of how long this would take, I think it is
best that those interested just join the discussion, and after
clarification of the task, declare interest for a certain amount (or for
nothing). Developer committee is welcome to participate and comment as well.
Cheers
Hello,
I am willing to know if we are willing to use a blog software to
communicate with wikipedians and mediawiki users.
Developpers and wikifarm administrators will be able to post lengthy
articles about the various things happening. Be it new servers added to
the farm, new features being developped or polling the user base to help
us make choices.
We already have this mailing list, irc to discuss issues but important
announcments are flooded with questions and generals ideas. We also have
the server admin log wich is great for the hour per hour action
logging as well as for internal documentation. But I think a blog will
attract more people and will easily provide rss feed + comments :o)
This afternoon I ported monobook to the serendipity blog software. You
can have a quick look at it on http://www.twenkill.net/serendipity/ .
cheers,
--
Ashar Voultoiz
Hello,
For the next 3 days I will be able to spend my full time on MediaWiki
development.
I am really willing to code an administration interface that will
superseed the install script and manually editing localsettings.php. My
idea so far is that the install script will just deal with things like
database and path, everything else will be available in the admin interface.
I am also willing to completly rewrite the rule system. Instead of
anonymous / logged in / Sysops / Bureaucrate, I am willing to assign
users to groups, each group having rights like "edit, move, special
page, site administration, mediawiki, protecting page ...".
Is there any dev already working on one of those two topics ? Do you
have any specific idea to share ?
Finally, should I start it now for the 1.4 release or wait for a later
release ?
cheers,
--
Ashar Voultoiz
Some time ago I wrote to this list that the local word for Nauruan
should be Nauruose, the source I quoted was the Nauruan wikipedia.
Consequently it was changed for use with interwikis. However, it has
transpired that the Nauruan wikipedia has been squated. Nobody knows
what language the content is in. I am afraid that Nauruose is propably
wrong.
Thanks,
GerardM
Yesterday, Erik Moeller mentioned that it might be best to hold off with
the wikidata development, and instead do that in a "quantum leap"
MediaWiki 2.0 version.
Which got me thinking: Should we start this (at least, plan it)?
There are quite some concepts and ideas that were proposed, but seem to
be hard to do with the current line of development. Examples:
* WikiData
* cur/old integration
* stable revision number for both cur/old
* single login
* XML parser
* use of wikicommons
* centralized interwiki link management
* stable/editable version management
* SVG support (editable SVG source?)
These are just the ones I come up with in a minute. There are, no doubt,
more.
Sure, some of them *can* be integrated into 1.3/1.4, but considering the
sum of the above, it might call for some radical break.
Which leads to the question: Fork or rewrite?
Seriously: If the database structure in 2.0 would greatly differ from
1.4 (which is to be expected), a rewrite of the core parts is in order.
* The parser will be rewritten anyway as XML-interpreting.
* We can probably keep the skin system
* Special pages will need a (partial) rewrite, depending on the new DB
structure
* Cache/squid/... can probably stay as they are
DATABASE REWRITE PROPOSAL
I vaguely remember there's one on meta, but I came up with this last
night (don't ask;-), so here goes nothing:
* Object list table. An object is a page (article, talk, etc.), an
image/media/binary file, or data; extensible with future types.
* A table for each object type, which holds the actual data: Article
text and user comment, revision number etc.
The object table only contains an ID and name (+namespace) for the
object, and an ID number for the actual object in its table.
So:
* OBJ_ID, OBJ_TITLE, OBJ_NAMESPACE identifies the object
* OBJ_TYPE (0 for page, 1 for image, 2 for data...)
* OBJ_DATA_REVISION identifies the current object data *in its table*
An article has
* ARTICLE_ID (matches OBJ_ID)
* ARTICLE_REVISION (both cur and old; OBJ_DATA_REVISION has the latest
ARTICLE_REVISION)
* the text of that revision, the user id, text and comment, and all the
other goodies
An image table would have
* IMAGE_ID, IMAGE_REVISION
* filename of the stored image, or reference to an external image
(commons), with a local description
Similar for data etc. (maybe even users?)
A table for changes would thus store an OBJ_ID. Recent Changes can then
look up what that object is, and then look up the changes in the
appropriate table.
As a result, we'd get
* an "universal" interface for everything we store in the wiki
* a (relatively) small table with all objects, equaling faster access
times, that only references the actual data (in the appropriate table)
Now you see why I think "rewrite" for this one. I also strongly believe
we should put *every* database access into the database class, capsuling
it from the rest of the software. Had we done this in 1.4, basically
only a rewrite of the database class(es) would be in order for the above
proposal.
Enough shocking you for now,
Magnus
I'm about to commit a major change to the 'old' table in HEAD. There
should ideally be no problems, but it's quite possible it will end up
corrupting your database, deleting articles or their histories, or
doing other bad things. There will almost certainly be minor bugs.
If you have anything important in a 1.4 version database, you MUST
backup your database before updating or you WILL lose it!
You have been warned.
Kate.
Hi!
I've posted about this before, but here it is again! :) In my
lex/yacc-based parser, I have now finished the table wiki syntax as well
as template inclusions. Please test everything! :)
http://timwi.dyndns.org/wiki/tmp.php
In particular, please test to see whether any invalid mark-up produces
an error. It shouldn't. It is always supposed to generate *something*.
If you do find an error, please e-mail me the full test case you entered
that produces it. (Alternatively, of course, ICQ and AIM work just as well.)
Things I know I haven't done yet:
- HTML tags (currently everything between <something> and </something>
is treated as an 'extension'; I need to limit that to <nowiki>, <pre>,
<math>, <hiero>, <music> and <chem> for now)
- [http://url/ These sort of links]
- hrs (horizontal rules)
- the new -{ language variants }- syntax
If there is absolutely anything else missing, please let me know!
(Please notice that the above URL is a bit slow at times when my
computer is a bit loaded. Also notice that it is only available when my
computer is turned on, which is during the day-time in the UK.)
Thanks!
Timwi
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
MediaWiki 1.3.5 is a security update, which contains a small fix for a
potential cross-site scripting vulnerability. All MediaWiki 1.3.x users
are strongly encouraged to upgrade to this latest release.
The only substantial change from 1.3.4 is in includes/RawPage.php, so
you can copy that one file in to perform a 'hotfix'. (Copy also
includes/DefaultSettings.php to update the version number.)
Changes from 1.3.4:
* Clean up input validation in 'raw' page output mode which was a
potential
cross-site scripting opportunity.
Release notes:
http://sourceforge.net/project/shownotes.php?release_id=271848
Download:
http://prdownloads.sf.net/wikipedia/mediawiki-1.3.5.tar.gz?download
Wiki admin help mailing list:
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
Bug report system:
http://bugzilla.wikipedia.org/
Play "stump the developers" live on IRC:
#mediawiki on irc.freenode.net
- -- brion vibber (brion @ pobox.com)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFBXGXdwRnhpk1wk44RAmIwAJ0RupGm+mNo1cZ433k8hHa7J50U2QCgnuG+
SZLnmAK5JuKaHyIaVkxvHbg=
=0PBU
-----END PGP SIGNATURE-----