Hi everybody!
I decided to install pictures for my wiki site. But dump of images which I
saw approximately a month ago, was disappeared now. I would like to know can
I still download it from somewhere? And why was it removed from
http://download.wikimedia.org/?
Thanks
Sergey
Hi,
look at this:
----------------------
There are 1163 total pages in the database. This includes "talk" pages,
pages about BMF-Wiki, minimal "stub" pages, redirects, and others that
probably don't qualify as content pages. Excluding those, there are
18446744073709551584 pages that are probably legitimate content pages.
-----------------------
What is :) 18446744073709551584 ?? Little bit to much for us ;).
How can i correct this counter?
We use Mediawiki 1.4.8
Regards
Switching dump format from SQL to XML offers a posibility of
very easy incremental dumps.
I did some tests on Polish Wikiquote database dumps (most
wikis have only a single xml dump, pl.q has two).
=== Raw data ===
Full dumps, compressed:
20050713_pages_current.xml.gz 1 105 966
20050814_pages_current.xml.gz 1 187 754
20050713_pages_full.xml.gz 3 796 056
20050814_pages_full.xml.gz 4 213 036
Full dumps, uncompressed:
20050713_pages_current.xml 3 874 225
20050814_pages_current.xml 4 158 544
20050713_pages_full.xml 30 882 758
20050814_pages_full.xml 33 708 595
Diffs -slow, hardly compresses anything:
current.diff 524 191
current.diff.gz 134 817 (11.5%)
full.diff 28 371 190
full.diff.gz 3 859 489 (91.6%) - I suspect the horrible result is due to the data being reordered
Xdelta (xdeltas are automatically gzipped):
current.xdelta 92 074 (8.3%)
full.xdelta 163 110 (4.2%)
gzip and xdelta were called with zlib compression level parameter -9
$ time xdelta delta -9 20050713_pages_current.xml.gz 20050814_pages_current.xml.gz current.delta
real 0m1.023s
user 0m0.548s
sys 0m0.124s
$ time xdelta delta -9 20050713_pages_full.xml 20050814_pages_full.xml full.delta
real 0m3.749s
user 0m1.731s
sys 0m0.217s
=== Conclusion ===
We should simply generate xdeltas every time a dump is generated.
It cuts the amount of data that needs to be transferred,
easy to add to the backup script, extremely fast, available everywhere,
and standard enough.
I doubt other compression methods (DTD-aware XML-deltas or whatever)
will be significantly better than that, and if they are, it's
certainly going to cost a lot more effort than simply using xdelta.
Hi all,
I've been occasionally reading this list through the archives but I
thought I'd finally subscribe so I can participate a bit more. I
wanted to say "hi" immediately 'cause I understand some wikipedians
are nervous about where I work and I don't want to alarm anybody if I
delurk on another post.
I was tangentially involved in the rel='nofollow' development here and
I've followed those discussions with interest. It makes me happy to
see you care about the quality of the internet outside of wikipedia as
well as quality within.
Before Google, I helped build LiveJournal -- though LJ then was
pretty different from LJ now -- and I understand you use(d?) some of
our software (I contributed a tiny bit to memcached).
Anyway, I mostly wanted to say that I'm a huge fan of what y'all do
and I'm eager to see your success in the future. Maybe I can provide
advice or answers in the areas I'm knowledgeable about.
(Oh, and a disclaimer: I don't speak for the company.)
I've written a feature (applied to HEAD) that enables administrators
to add a license selection box to Special:Upload, they have to write a
MediaWiki:Licenses message with information which will be used to
construct the form, a sample message would look like:
* Free licenses
** GNU Licenses
*** GFDL|GNU Free Documentation License
*** GPL|GNU General Public License
** Creative Commons licenses
*** ....
The bullets that have the form "Template|Text" are selectable
templates, if they're selected {{Template}} will be added to the file
page under a == License == subheading, the bullets that have the form
"Text" are selecteble but have no effect, both can be localized
through the MediaWiki namespace, for instance one could add "Frjálsa
GNU handbókarleyfið" to MediaWiki:GNU Free Documentation License and
"Frjáls leyfi" to MediaWiki:Free licenses to translate the
corrisponding items into Icelandic.
hello,
apologies if this is the wrong list to post/discuss this (i read through
the mailing lists wiki page and this one seems to be the most suitable).
after not finding the functionality (acronym tooltip + glossary link)
that i was looking for in mediawiki (including extensions) i would like
to add an extension that supports the below:
1. provide a tag to markup an acronym/abbreviation: when moused over,
a tooltip will be displayed (using the 'title' html attribute) that
provides the expansion of the acronym.
2. additionally, if a glossary page is specified then the text is linked
to the relevant section of that page. alternatively, if a page with
the acronym as its title is present, the text is linked to that page.
with regards to this idea, i have a set of questions:
1. is this already done/possible?
assuming, not:
2. is it possible to use wiki markup rather than an HTML tag:
{{gl|XML}} or some such, rather than <gl>XML</gl>
would i do this using templates plus the extension?
3. the acronym list needs to be stored somewhere, either implicitly
in the glossary page or externally. one possible location is the
MySQL DB. is modifying the DB (for extension dev) frowned upon?
comment:
feature item #2 (glossary/page link) perhaps is better left to regular
wiki markup (since it can already be done that way)...
any thoughts or comments appreciated!
--ravi
> Maybe the dump job could scan a completed dump file for </mediawiki> and
alert when missing?
> This will detect aborted dumps.
Well simply logging succesfull completion to a separate dump_progress file
at the end of each dump step will do I guess.
After all dumps are done, this file could be auto scanned for missing
confirmations.
Erik Zachte
DE full xml dump 20050713_pages_full.xml.gz is corrupt
So last usable dump is 1.4 file 20050623_old_table.sql.gz ?
Do we still see dumps as a contingeny measure?
If worst comes to worst and all live db servers get corrupted (we got very
close to that at least once),
do we ask "Would all contributors on de: please reapply the edits they made
in the last 2 months?"
Suggestion: maybe the dump job could scan a completed dump file for
</mediawiki> and alert when missing?
This will detect aborted dumps.
Erik Zachte
The DE dump file ends with
A database error has occurred
Query: SELECT old_flags,old_text FROM `text` WHERE old_id='3538710' LIMIT
1
Function: Database::selectRow
Error: 2006 MySQL server has gone away (10.0.0.101)
Backtrace:
GlobalFunctions.php line 424 calls wfbacktrace()
Database.php line 395 calls wfdebugdiebacktrace()
Database.php line 345 calls databasemysql::reportqueryerror()
Database.php line 712 calls databasemysql::query()
Database.php line 731 calls databasemysql::select()
HistoryBlob.php line 207 calls databasemysql::selectrow()
Revision.php line 464 calls historyblobstub::gettext()
SpecialExport.php line 400 calls revision::getrevisiontext()
SpecialExport.php line 326 calls wikiexporter::dumprev()
SpecialExport.php line 292 calls wikiexporter::outputstream()
SpecialExport.php line 225 calls wikiexporter::dumpfrom()
dumpBackup.php line 61 calls wikiexporter::allpages()
dumpBackup.php line 135 calls backupdumper::dump()