There is a misunderstanding, our IP was blocked today as a "Remote Loader".
We DO NOT load wikipedia's pages live, we only CACHE the pages in our
server. We send a monthly request to update our cache for requested pages,
so I don't understand why our IP was blocked.
As you can check, we are still providing the cached pages FROM OUR SERVER:
http://www.ebaita.com/enciclopedia.asphttp://www.tiosam.com/enciclopedia/
I also make sure the license and link to wikipedia are in all pages.
Please remove the block so we can update the pages when necessary.
Thanks,
Tony
Webmaster TioSam.com and eBaita.com
Per Brions request I split the isues into single pieces (although I wanted to
avoid having different parallel threads on related issues):
1)
Usually UI interface links (such as "MediaWiki:Mainpage" that defines the URL
of the main page) are not localisable by default (pages
like "MediaWiki:Mainpag/de" get ignored). However you can whitelist their
i18n with "$wgForceUIMsgAsContentMsg = array();" individually in
LocalSettings.php.
2)
In the past maintenance/update.php did copy every UI message from the default
language UI message file into the wiki database. On whitelisted UI interface
links it even did copy the default language link target into the language
sub pages in every language if there wasn't one created by hand before (for
example the content of MediaWiki:Mainpage was copied into
MediaWiki:Mainpage/de if it was empty). So if there was the link target
existing in the default language it was not possible to link people in other
languages into non-existant "localised" pages after running
maintenance/update.php (side note: this specific behaviour of
maintenance/update.php can't have been an accidential not intended side
effect).
Now maintenance/update.php was changed that way that it doesn't copy UI trings
anylonger into the wiki and even removes the old automatically added entries.
This is in principle a good thing as this allows for some other fixes (for
example in mutilingual wikis) and reduces problems with hidden message
strings.
However one important thing was forgotten: The special treatment of
whitelisted interface links. Now they point into the nowhere by default after
running maintenance/update.php (since the link definitions from the localised
message string files get used now).
How to solve that (I don't want the old copy behaviour back as this is a
hakish solution)?
Change for link target strings (all that now need whitelisting) the
interface string resolution order from:
Mediawiki:$Message/$language-code ->$language-code-UI-String-File-$Message
[further steps left out]
to
Mediawiki:$Message/$language-code -> Mediawiki:$Message (default language) ->
UI-String-File-$Message (default language)
That way people don't get linked into nowhere on whiletlisted link targets -
and of course you also could entirely remove the need for
$wgForceUIMsgAsContentMsg switch in Mediawiki (and you
would get rid of one Wikimedia server maintence issue that fills your
Bugzilla).
Arnomane
> We provide regular database dumps to make the information freely available
> in a manner that is friendlier to our servers, and that is usually easier to
> process and import - it's much more convenient for both parties to import
> all the revision text at once, rather than crawling for it.
The last time the full enwiki dump (All pages with complete edit
history, pages-meta-history.xml.7z) completed was on 2006-11-04. Any
idea if the current one will finish?
--
mdd4696
So, my vanity Google Alert turned up this doozie yesterday:
http://www.vecosys.com/2007/01/29/wikipedia-adopts-microformats/
Per the post, "Wikipedia has just announced that are also looking at how
they can use Microformats on Wikipedia (and, more generally, in
WikiMedia)?"
I can't seem to find any such announcement; my guess is that it's either
a typical mixup of "Wikipedia" for "Wikia", or maybe just some blogger
getting his wires crossed.
In any event, Wikitravel's had uF's for a while now, and if there really
is someone working on this, I'd love to collaborate. I think uF's are
pretty cool and I'd like to see them more available for MW in general.
~Evan
________________________________________________________________________
Evan Prodromou <evan(a)prodromou.name>
http://evan.prodromou.name/
Some strange anomalies are reported on Japanese Wikipedia.
I am not sure if this is a bug in software or something else,
so I am reporting it here first.
#1 Three users indicated that their edit records include
edits they had never made - wrong attribution.
#2 One of those users reported that while he was editing,
he "became" another user - he was logged on as another user.
He could see email address, watchlist, etc. associated with
that account. The account he was switched to was also among
one of the three users mentioned in #1.
To be more specific, the following three users reported
wrong attribution.
http://ja.wikipedia.org/wiki/%E5%88%A9%E7%94%A8%E8%80%85:Avanzare
reported his edit record include edit(s) he never made.
http://ja.wikipedia.org/wiki/%E5%88%A9%E7%94%A8%E8%80%85:Trashwriter
said that he had never made this edit:
http://ja.wikipedia.org/w/index.php?title=%E4%B8%AD%E4%BA%AC%E9%AB%98%E7%AD…http://ja.wikipedia.org/wiki/%E5%88%A9%E7%94%A8%E8%80%85:Kunipoo
said that he had never made this edit:
http://ja.wikipedia.org/w/index.php?title=%E3%83%98%E3%82%A2%E3%83%8C%E3%83…
Also,
User:Trashwriter reported he once became User:Avanzare.
User:Kunipoo reported he once saw the user name displayed at
the upper right corner became NNNN or NNNNN. He experienced
other error messages and slow responce when this happened.
(User:NNNN and User:NNNNN do exist in Japanese Wikipedia,
although the former has only one edit and the latter none.)
Is this something that might occur in relation to server
overload?
Best,
Tomos
A new issue of the Python Wikipediabot framework has been released, and can
be downloaded at http://sourceforge.net/project/showfiles.php?group_id=93107
. Everyone who does not update from CVS is advised to download this. Note
that this release does not include the wordlists, those who want to use
spellcheck.py should download a wordlist from
http://pywikipediabot.cvs.sourceforge.net/pywikipediabot/pywikipedia/spelli…
and Dutch wordlists are available, the French one is only small).
Note that one is advised to have the most recent version of Python (2.5) to
use with the bot.
The main changes since the previous release are:
new bots:
* clean_sandbox.py: empties the Sandbox (except for what should not be
removed)
* disambredir.py: goes through disambiguation pages to (ask whether to)
change redirect links on these pages
* inline_images.py: Searches and removes images that are linked inline
* isbn.py: Converts ISBN-10 to ISBN-13
category.py:
* Mode 'listify' added: gets a list of the pages that are in a specific
category.
* category.py remove can have customized edit summaries using the -delsum
option
commons_link.py:
* Can also be used to find categories rather than galleries
* Puts its template above categories and interwiki instead of all at the
bottom
copyright.py:
* Various fixes and improvements
delete.py:
* More options to decide which pages to delete: -ref (pages linking to a
specific page), -page (a single page), -file (a file with the pagenames),
-images (all images on a specific page)
featured.py:
* Now puts the template before categories and interwikis instead of after
the interwiki link
* Gives its command line options when -help is used
image.py:
* New option -loose: replaces the image new everywhere where it occurs. This
means that no occurences of the image are skipped, but also that there's
more risk of making errors.
interwiki.py:
* Quicker removal of links to different namespaces (they are removed when
there is a correct link or the option '-autonomous' is used)
* When the -ignore option is used, the page is also ignored if found as a
redirect
* It is now possible to combine -cat and -start to do a part of a category's
pages
* The -whenneeded option becomes slightly stricter (it does not change links
if the only problem was that there were links to be removed)
* Option -link renamed -links
movepages.py:
* Option -new to work on the new pages
* Options -from and -to to specify on the command line from and to which
title to move the page
pagefromfile.py:
* Option -notitle to not include the line containing the title in the page
to be created
replace.py:
* New options -allowoverlap and -recursive to change overlapping and
recursive occurences
* New option -nocase to make all regexes case insensitive
* New option -summary for custom edit summaries
* Does not crash on meeting the spam filter, but tells the problem and goes
on with the next page
* replace.py -fix:interproject has been deprecated
selflink.py:
* New option -xml to work from an XML dump
solve_disambiguation.py:
* The -primary option now works when the page is a disambiguation page (for
cases where [[X]] is a redirect to [[X (subject)]] with a disambiguation
page at [[X (disambiguation)]])
* More ignored pages for nl:
template.py:
* Now works on templates that have brackets in their name
touch.py:
* Does not do cosmetic changes, even when the bot normally does do so
upload.py:
* Is better (though possibly not yet perfect) in checking whether the upload
succeeded
weblinkchecker.py:
* Fakes being Firefox because some websites block unknown user agents
for programmers:
* Page objects now have a protect() method
* new method setUserAgent(). Uses the same user agent always.
* pagegenerators.py has a class CommandLineGenerator to automagically add
generator options to a bot
* Page.getReferences() gets a parameter
general:
* if a certain Mediawiki message is not found in the list the bot has, it
will first try reloading the messages before spawning an error
* many bugfixes
* large code refactoring in interwiki.py, pagegenerators.py
* namespace names updated
* more localization of edit summaries
--
Andre Engels, andreengels(a)gmail.com
ICQ: 6260644 -- Skype: a_engels
An automated run of parserTests.php showed the following failures:
This is MediaWiki version 1.10alpha (r19696).
Reading tests from "maintenance/parserTests.txt"...
Reading tests from "extensions/Cite/citeParserTests.txt"...
Reading tests from "extensions/Poem/poemParserTests.txt"...
18 still FAILING test(s) :(
* URL-encoding in URL functions (single parameter)
* URL-encoding in URL functions (multiple parameters)
* TODO: Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)
* TODO: Link containing double-single-quotes '' (bug 4598)
* TODO: message transform: <noinclude> in transcluded template (bug 4926)
* TODO: message transform: <onlyinclude> in transcluded template (bug 4926)
* BUG 1887, part 2: A <math> with a thumbnail- math enabled
* TODO: HTML bullet list, unclosed tags (bug 5497)
* TODO: HTML ordered list, unclosed tags (bug 5497)
* TODO: HTML nested bullet list, open tags (bug 5497)
* TODO: HTML nested ordered list, open tags (bug 5497)
* TODO: Inline HTML vs wiki block nesting
* TODO: Mixing markup for italics and bold
* TODO: 5 quotes, code coverage +1 line
* TODO: dt/dd/dl test
* TODO: Images with the "|" character in the comment
* TODO: Parents of subpages, two levels up, without trailing slash or name.
* TODO: Parents of subpages, two levels up, with lots of extra trailing slashes.
Passed 489 of 507 tests (96.45%)... 18 tests failed!
Just something that came to my mind...
Google caches the wikipedia pages just like we were doing. Are you blocking Google as well?
-----Original Message-----
From: Webmaster [mailto:webmaster@tiosam.com]
Sent: Tuesday, January 30, 2007 12:27 PM
To: 'Wikimedia developers'
Subject: RE: [Wikitech-l] Our IP was blocked by mistake
Thanks. That explains it. Also, the IP shown is not enciclopedia.tiosam.com nor ebaita.com: it is www.tiosam.com where I just included the English version a couple of weeks ago (http://www.tiosam.com/Ingles/encyclopedia ). The load was probably google indexing the pages in English, not what we already have cached for the Portuguese version.
Anyway, I apologize for my ignorance. I'm downloading the dump and will start coding as soon as I find out how it works. Thanks guys.
-----Original Message-----
From: wikitech-l-bounces(a)lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] On Behalf Of Ivan Krstic
Sent: Tuesday, January 30, 2007 11:40 AM
To: Wikimedia developers
Subject: Re: [Wikitech-l] Our IP was blocked by mistake
Tim Starling wrote:
> No faked user agent string? So I suppose you were using "save as" in IE?
> Mozilla/4.0%20(compatible;%20MSIE%207.0;%20Windows%20NT%205.2;%20.NET%
> 20CLR%201.1.4322;%20.NET%20CLR%202.0.50727)
No, he was using the Microsoft.XMLHTTP object from ASP, as he indicated in a previous message. Said object identifies itself as MSIE and gives the .NET CLR version in the User-Agent.
--
Ivan Krstić <krstic(a)solarsail.hcs.harvard.edu> | GPG: 0x147C722D
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
http://lists.wikimedia.org/mailman/listinfo/wikitech-l