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
Preliminary, experimental IPv6 support has been added to Wikipedia.
The wildcard A record now has an AAAA entry for our IPv6 proxy host.
This will probably be tested for the next few days, and may be removed
if it proves unworkable. However, until then, IPv6-enabled users can
access Wikipedia (only - not any other projects, yet) via IPv6 just as easily
as IPv4.
Please let me know about any issues, problems or other comments
during the test period.
Kate.
Hi
I will implement downloadable PDF export to my customised MW, so that readers
can export any wikipage in PDF. This code can be made available under GPL.
Is there anybody who would like to work with me on this, or is the MW team
interested in incorporating this code in MW1.4?
--
NSK
Admin of http://portal.wikinerds.org
Project Manager of http://www.nerdypc.org
Project Manager of http://www.adapedia.org
Hi!
After downloading the cs: database dump and importing it to my local
MediaWiki installation, I played a little with the database and I have
found some problems. We have already known about some of them, some
others were quite surprising. We would like to clean the database, but
I don't know if this is the right place to ask.
The problems are:
Article named "kniha_nahrávek" in Wikipedia namespace -- note the
first lowercase letter, which makes the article inaccessible. This was
a badly named entry in LanguageCs.php corresponding to the "Upload
log". Because of that, there are many duplicate copies of the article,
cur_ids: 237, 238, 365, 367, 457, 459, 461, 463, 487, 528, 529, 538,
643, 654, 656, 689, 691, 693, 698, 700, 702, 704, 708, 710, 712, 714.
We would like to get them all deleted.
Article named "kniha_nahrávek_" in Wikipedia namespace -- in addition
to the lowercase letter, there is a space at the end. cur_id = 836,
the article should also be deleted.
" Psaní_dat" in Wikipedia namespace -- beginning with a space, which
makes it also inaccessible (automatic redirection to "Psaní dat"),
cur_id = 1265. The article should be also deleted.
Duplicate "Sirotčí_stránky" in Wikipedia namespace, cur_ids 716, 733.
One or both of them should be deleted.
Duplicate "26._října" in the main namespace, cur_ids 3326, 3327. One
of them should be deleted (or both, it is a simple redirect that could
be simply recreated).
"Wikipedie:Co_je_článek" in the main namespace (cur_id = 49) -- note
that the czech name of Wikipedia namespace is "Wikipedie". So that its
name collides with the namespace name (it was probably created when
the namespace name was not yet translated), and its name is invalid.
The article has been deleted by a sysop, but without real success, it
still appears in e.g. Special:Uncategorizedpages etc. The article
should be deleted.
"" (empty name) in Media namespace (cur_id = 3614) -- it should
obviously be removed.
Could someone with database access please fix those problems? Or, if
there is a better place to ask these requests, just tell me.
Thanks,
[[cs:User:Mormegil|Petr Kadlec]] (sysop/bureaucrat on cs: Wikipedia)
I have been directed by User:IMSoP to contact this mailing list in regards
to uploading MIDI files for use on wikipedia. See:
http://en.wikipedia.org/wiki/Wikipedia_talk:Sound#Trying_to_upload_MIDIs
At least two wikipedians (including myself) would like to be able to add and
use MIDI files on wikipedia, as was the capability in the past. We believe
they are a common format and allow for smaller file sizes. It has been
suggested by User:Raul654 that MIDI files are unsuitable because their
performance is unpredictable, and by User:Camembert that they are not
currently allowed for security issues.
I request that someone with the capabilities "modify the file
includes/DefaultSettings.php" as per
http://meta.wikimedia.org/wiki/Help:Images_and_other_uploaded_files to allow
the uploading of MIDI files. If this is not possible or unadvisable, I would
request an explination either here or or at
http://en.wikipedia.org/wiki/Wikipedia_talk:Sound#Trying_to_upload_MIDIs.
That way we can settle the issue and inform the interested parties of the
reasons why.
Thanks,
Mikhail, wikipedia User:Hyacinth
_________________________________________________________________
Get ready for school! Find articles, homework help and more in the Back to
School Guide! http://special.msn.com/network/04backtoschool.armx
Hi,
I'd like to join the development of the wiki2xml parser, and especially
using the xml to generate LaTeX, PDF, etc. There seems to be a lot of
different projects about this, perhaps someone could give me a hint on
where to join or which projects have died?
Timwi's parser at http://timwi.dyndns.org/wiki/tmp.php (offline right
now). I suppose that is the same as in CVS/flexbisonparse, is this
correct? This project seems to be quite active, is it going to be
included in mediawiki any time soon?
http://meta.wikimedia.org/wiki/Wikipedia_DTD - quite comprehensive draft
for a DTD, but is there some sort of implementation?
http://meta.wikimedia.org/wiki/Wikipedia_lexer - ???
http://meta.wikimedia.org/wiki/XML_export - ???
The background for my interest is that I'm the author of the wikipdf
script at http://wiki.auf-trag.de/ which is written in python. A lot of
people are asking me about new features or bugfixes, but re-inventing
the wheel for every feature in mediawiki is really a pain, and the code
is already a big mess. So I'd really like to help develop a wiki->xml
parser. I'm no expert in php, but I have some knowledge in lex and yacc.
Regards,
Stephan
I just downloaded the old table for ca.wikipedia.org, and compressed it
with my new concatenated gzip history compression feature. The idea is
that by concatenating the text from adjacent revisions before
compressing with gzip, the gzip algorithm can take advantage of
similarities between revisions and thereby acheive a better compression
ratio than it would by compressing individual revisions.
The old table in question had 38,697 rows. 36,536 were already
compressed with gzip, 2,159 were uncompressed and 2 had an invalid
old_flags field. The SQL dump was 46.3 MB.
I compressed it with a maximum chunk size of 10. I wrote an algorithm to
change the chunk size depending on compressibility, but it was disabled
for this test for performance reasons. With these parameters, the SQL
dump after compression was 22.1 MB, 0.48 times the size of the original.
If you take out the headers (edit comments, attribution, etc.) and SQL
detritus, the decompressed text is 99.0 MB and the compressed text is
17.6 MB, so that's a compression ratio of 82%.
CRC32 checksums of the decompressed text were recorded before and after
the test to check data integrity. There were no errors.
Hopefully we will be able to improve the compression ratio still
further, but after this test I would consider the feature to be good
enough for a beta release. The obvious direction for future development
is to try some sort of diff algorithm.
-- Tim Starling