> Some things I've already done:
> * rewriting some parts to run over patTemplate
What are the pros/cons against current mediawiki development line and phpTAL?
> * splitted off the wiki into a (system-wide) library part and
> some very little stub for index.php -> allows multiple instances
> to share the same code and so ease updates.
Well, that's where the mediawiki development is heading.
> What I'm going to do:
> * database/storage abstraction (i.e. postgresql backend)
Nice idea. Though, the main idea is to separate data processing
code from UI, the data abstraction isn't too difficult to implement.
And even now we've got working versions of PostgreSQL mediawiki.
Possibly a working feature in 1.4 or later 1.3 versions :)
> * wiki middleware (for article storage, wiki-syntax parsing, ...)
Well, with object-oriented design mediawiki already has
classes for article storage (Article) and parsing (Parser).
What is going to be else?
> * support multiple parsers and converters (also xml<->wiki)
Parsing human text into computer text is a nice task.
Especially if your XML would be usable with XSLT.
> * frontend completely patTemplate-based
> * integration into contentbuilder2/baseTemplate2 framework
> (so the wiki is just a box and can be easily imported into
> some other application
I don't wear UI-hat, so I won't be able to measure the value of
theese additions. Still, I've got a question. What is your motivation?
Why do you write about theese features? Why is it called phase4
instead of someotherwiki? Does it really have the best value for project?
Cheers,
Domas
Hi,
This is a message I sent to the Python Wikipedia Bot mailing list today, which
should be of concern for MediaWiki development as there might be other
clients that send invalid UTF-8 (or even the MediaWiki software itself, as
seen in [[es:Wikipedia:Registro_de_borrados]]).
---------- Forwarded Mail ----------
Subject: [pyWikipediaBot-users] Bot messed up databases on UTF-8 wikis
Date: Sonntag, 18. Juli 2004 16:12
From: Daniel Herding <DHerding(a)gmx.de>
To: pywikipediabot-users(a)lists.sourceforge.net
Hi,
wikipedia.putpage() always sent its edit summary messages as Latin-1 or
something, even if it was editing a UTF-8 wiki which expected UTF-8 summary
messages. (This concerns all bot functions which can have non-ASCII
characters in their summary messages.)
This, of course, troubled the SQL databases, and if you look at
http://fr.wikipedia.org/w/wiki.phtml?title=10_mars&action=history
with Mozilla, it will show flashy question marks instead of special
characters. The same happened on nds:, where Andre ran the interwiki bot, and
probably on many other Wikipedias. I just can't believe that nobody noticed
this, and I'm quite angry that nobody reported this bug.
I fixed this bug yesterday, as you can see here:
http://fr.wikipedia.org/w/wiki.phtml?title=Utilisateur:Head&action=history
but the databases are already fucked up. The XML export special page (which
is used by interwiki.py) gives out crappy XML, which leads to a SAX parse
bug. And my newly created sqldump.py is unusable for these wikis.
So I guess we should ask the MediaWiki developers to help us out. Maybe they
can shut down the wiki for a while, then run over the 'old' database,
replacing every non-UTF-8-byte with a question mark.
Daniel
----------- End of forwarded Mail ---------------
It would be nice if someone could repair the databases on fr:, nds:, es:, and
other affected Wikipedias. You should also consider implementing a filter
that stops users from posting illegal characters. Mail me if you need
additional information.
Daniel
The one uploaded yesterday was based on an old version, this is a new
version i've fine-tuned a little more, please go over it hover as i
may have made some subtle mistakes i havent noticed.
es.wikipedia is now converted in utf-8. If somebody could clear the mediawiki: cache, that would be perfect :)
If everything goes well, it would have take less than an hour, without downtime, only readonly. The complete db dumped is 1GB
Shaihulud
Jens Frank wrote:
> Modified Files:
> Language.php LanguageFr.php LanguageDe.php LanguageZh.php
> Log Message:
> moved weekday, monthname etc to AllMessages arrays.
This change is going to have a noticeable and annoying effect on all
Wikipedias except for en, fr, de and zh where you adapted the language
files. Are you still planning to "fix" all the other language files too?
Greetings,
Timwi
On wikitech there is a discussion of the relative merits of having UTF-8 and monstrosities (for editors) like "è" or ᏲᏁᎦ/ᎩᎢᏏ
It seems that you can search wikipedia for èh or something. This will not find you èh. As wiktionary has many monstrosities, it would be best to convert them to something legible again.
I have been carefull not to add these things to en:wiktionary after I became aware of this problem, but I do know that many of these exist. In order to prevent them getting new ones, I think the best way of preventing this is by converting all wiktionaries to UTF-8.
I am still hoping that nl:wiktionary may soon be converted to UTF-8; there are many words that we cannot add to our dictionary because of this backwardness.
Thanks,
GerardMare many words that we cannot add to our dictionary
I would really like to move the fundraising page to the new foundation wiki,
but I can't until that wiki can support (at least) forms. Also, since there are
many ideas about how to improve that page that involve other parts of HTML that
we do no allow (for security reasons) by default, I think it would be best to
allow full HTML.
In short, this http://wikimedia.org/wiki/Fundraising , needs to look a lot more
like http://wikimediafoundation.org/fundraising soon.
Allowing full HTML will also make it possible for other language versions of
that page (which have already been written) to go live.
Also, could somebody move the whole wiki to wikimediafoundation.org? It was a
bad mistake to place it at the wikimedia.org domain name since;
1) we do not own the .com and many people naively put .com at the end of every
domain name.
2) it can be easily confused with wikipedia.org.
-- Daniel Mayer (aka mav)
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
Hello all,
on the Italian Wikipedia it has recently been discussed to make a bot that is
used for some maintenance work additionally convert characters like letters
with accents to HTML-entities (è etc.). Does this make any sense? And
if so, why was it.wikipedia converted to UTF-8 at all? And finally, if this
really makes sense, shouldn't this be handled by the software instead of
cluttering the edit window with &foobar;s that most people don't even
understand?
It has been argued that those characters can't be entered directly e.g. with
an American keyboard layout, but in my opinion this is at best a reason for
converting the entities to the corresponding characters, not the other way
round.
Sorry for taking this here, but the thought of having soon thousands of pages
interspersed with cryptic entities was rather shocking for me ;-) and thus I
hope to find some expert answers as soon as possible. Just imagine what the
German and French Wikipedias, just to name those, would look like with lots
of ä ß ç and the like in the middle of words.
If this has already been discussed, could someone please point me to the
relevant pages/threads. Thank you,
[[en:User:Leonard Vertighel]]
[[it:Utente:Leonard Vertighel]]
I've been playing around recently with CivicSpace, a Drupal-based
software package using PHP and MySQL that includes features such as a
blog, a calendar and an email list. After I did a test installation
at a domain where I also have a test installation of MediaWiki
running, I noticed a problem with MediaWiki. Whenever I tried to
access the wiki as a logged-in user, I got the following error
message:
>Fatal error: session_start(): Failed to initialize storage module.
>in /usr/www/users/rampton/wiki/User.php on line 146
After some experimenting, I discovered that the problem arises
because Drupal requires adding the the following lines to .htaccess
to modify the PHP configuration:
php_value session.save_handler 'user'
php_value session.cache_limiter none
Once I deleted those lines from .htaccess, the problem went away, and
I was able to get both CivicSpace and the wiki running on the same
server by simply putting a different .htaccess file in the
directories for each package. However, I thought I should call this
error message to the attention of developers here. If anyone ever
wants to develop MediaWiki into a Drupal module, this conflict might
give them some headaches.
--Sheldon Rampton