From: Peter Gervai <grin(a)tolna.net>
Subject: Re: [Wikipedia-l] Switching everything to
Hi Peter, that was a long and interesting message.
I thought of perhaps adding a couple of words to
complete what you wrote.
>What was the memory footprint of opera 4,5 or
>you use? What browser do you use regularly, under
>operating system? How much memory do you have?
>I just checked: opera 7.21 uses 35MB virtual (20MB
>resident) memory, I believe this is not outrageous
>for a graphical browser. (Latest opera is 6.03 for
>Mac as far as I see, but I won't downgrade mine.)
I will first reassure you, I finally found a solution
with Netscape 7.02. Not perfect (slow in particular,
and sometimes unexpectedly crash, but that was my best
option). My mac is a 128 mo, and I use a bit of
virtual memory. System 9.04. I can't check memory
requirement of Opera 6. It was so desastrous I put it
in the trashcan. Netscape 7 is currently at 53 Mo.
Opera 5 is at 25 Mo. The system is at 34 Mo. IRC at
nearly 1 Mo. And Photoshop is at 47 Mo...hum...I would
have said Photoshop would require more than Netscape.
Curious. But no images are open. I get in trouble when
on top I open QuarkXPress and Canvas :-)
>> The upgrade is perfectly ok if you have a recent
>> computer. But you cannot expect every user to have
>> There was a big campaign about 4 years ago in
>> and many many people bought some imacs.
>That's a problem. I can't tell you about Mac
>apart from the fact that I see "Mac OS/X" (whatever
>might be) in Mozilla download pages. Don't Mac have
>any more recent browsers than Opera 6.03 or Netscape
>4.xx? (I see netscape 6.2.xx for MacPPC.)
OS 9 is the previous system. X is the new one.
Requires quite a bit of memory. Running system X on my
computer would be problematic. Many machines are still
in OS 9. Opera 6 is the most recent one. Netscape 7 as
well. And there are plenty of good browsers, but they
work only on X. The jump between 9 and X was
...well... it is really different.
>I'm sure you going to have troubles with that "fine
>for internet" soon. dmoz.org is going to be changed
>to utf-8 "real soon now" (see
>utf8 categories, like Catalan or Arabian), and most
>international project are either already utf-8
>or going to be soon.
As I said, I solved the problem. What I fear is that
most people I know who bought macintosh around 3 to 4
years, are usually quite "unable" with computers, and
have no idea how to upgrade a browser or a system.
They really do not. It is no joke. These people use
the computer they brought from the shop, and they do
not change anything on it, unless they have a nephew
able to fix the stuff for them. They will keep the
computer as is, till the they change it because the
dvd reader is dead because kids put chewing gum in it.
These people are also our public. Better even, as far
as I am concerned, they are the people I try to reach
to be editors.
Also, some people only have access to computers in
public libraries (there are two in my city...computers
in the main library I mean...not much he ?), or in
school (there are more in my kids school than in the
Most of these computers are *not* changed very often
(understatement). Even in universities. Students do
not pay very expensive fees for their studies, the
drawback is that material is not great, not replaced
Though I am quite a joke in computer stuff, I was the
one who explain my daughter teacher how to use her
computer last year; she have some pedagogic games for
the kids on it. Good stuff. The least I can say, the
computer was not brand new...but it was connected to
internet. Just seeing how she approached the "thing",
I can tell you she won't upgrade the stuff. Which does
not mean she will not show the kids great stuff.
But I think she, and the kids, are also our public,
and perhaps our editors.
>Can your browser edit utf-8 articles which does NOT
>contain non-latin1 characters?
>> I know it is not possible for these users to use
>> 6, and not possible to switch to system X.
>I believe you, but then, they are in a dead end, and
>they can expect more and more problems as unicode
>gets used more widely. usemod wikis just being
>to utf-8, we'll see what happens.
They are not in a dead end, they are just "old"
computers. Newer ones do not have problems.
>Edit, enter your browser and opsys, and see what
I did. Of course, this will work well, since my
browser is now working.
Peter, *my* problem is solved now, or I promise I
would be screaming with the idea of switching the
french wikipedia utf 8 *now*.
All what I say is that there are still people with
these, and I really do not feel like telling them, "go
away". That is all I mean.
>> I do not understand that comment.
>If the iso8859-1 encoded page contains illegal
>it breaks if you edit it with a standards compliant
I did a good old edit with my favorite browser on your
test page as well :-))))
>> > Can you figure manually correcting each time
>> user ?
>Well, I'd revert it and tell the user to use a
I understand. This is not a good option to my opinion,
but I am sure Brion and co will find a good solution
that will be acceptable to all of us :-)
>> and perhaps those editing
>> wikipedia right now are people technically better
>> equipped that the average human being connected to
>Definitely, if you count in the Albanian orphans and
>the chinese peasants.
Hum...about 6 months ago, I was at the technical level
of an albanian orphan then :-)
I could perhaps launch a subscription for a new
>Otherwise no. I can run opera well on a pentium 233
>32 MB of memory (and on 16MB either, but it's much
>How much is a P233 nowadays? $10? (convert to FFR at
Peter...we are in euros...
Peter...I have no idea what a P233 is. I suppose
memory. But in truth, Peter, some people just *do not
know anything* about all this.
>Most end-users are using windoze, and it is well
>with utf-8 conform browsers.
I would regret it if we gave another motive for
windows to win over other systems :-)
>I stay silent, and let the old timers decide. If I
>be any technical help, I'll start talking again.
I do as well, because I can't help at all :-(
>Hoping the best,
Thanks Peter :-)
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
The following is a point that I raised with Angela as part of my attempt
to deal with what I see as the ongoing problem of Votes for Deletion. I
would like to seek constructive solutions to that.
When it comes to deletions my first rule would always be to resolve the
benefit of the doubt in favour of keeping. Secondly I would put delete
only when an article falls squarely into a specified category. The
first two (and there would be others) clear categories would be
(a) Obvious bad-faith nonsens such as infantile comments, alphabet
soup and insults (the kind we all know when we see it), and
(b) Clear tyupographical errors in an article title
The general class of articles that I want to consider now is that of
those articles that belong in another member project of the Wikimedia
family. Such an article will likely have valuable information, but the
contributor has just put it in the wrong place. That group has a number
of number of possible sub-classes:
1. dictionary type entries; (They belong in Wiktionary)
2. foreign language entries: (They belong in the Wiktionary for the
3. entire quoted books; (They belong in Wikibooks)
4. memorials; (They belong in what is now the 9/11 Memorial, which
could be expanded to cover forgetable victims of other disasters)
One observation that I have about the current listing of things to be
transferred to Wiktionary is that it is somewhat useless where it is. A
person that devotes his entire Wiki time to work on Wiktionary may not
see it and may not even know that it's there. To solve this I would
propose a Transwiki:
namespace on all projects. I first thought of using the word "Transfer"
for this, but decided that a coined word would avoid any possible
ambiguities. Currently Thou <http://en2.wikipedia.org/wiki/Thou> is the
first entry on Wikipedia:Things to be moved to Wiktionary
. To deal with this I would create an article in Wiktionary called
[[Transwiki:Thou]] to which everything that is now in Thou
<http://en2.wikipedia.org/wiki/Thou> could be copied as is. A
Wiktionarian who is looking for something to do could then work at
co-ordinating that article with what really should be on Wiktionary
according to Wiktionary rules. Once that is done the Transwiki article
could be deleted.
Since this idea can be applied to transfers between any two projects, I
would suggest that the name "Transwiki" be applied uniformly across all
projects. This is important for foreign language entries That way a
worker in the source project will know exactly where to put something in
the target project without knowing anything about the target language.
Staying so long with ISO 8859 was a mistake.
So I propose converting all Wikipedias that aren't using UTF-8 yet to UTF-8.
Procedure should be like that:
1. new LanguageXX.php prepared and put under some name
2. make backups
3. create tables curutf8 and oldutf8
4. disable write access
5. convert all data - numeric HTML codes are going to be replaced by UTF-8 characters too.
6. rename tables cur and old to cur88591 and cur88591
7. rename tables curutf8 and oldutf8 to cur and old
8. replace old LanguageXX.php with utf8-enabled version
9. reenable write access
The conversion script should be tested on test.* Wikipedia first.
During step 5 Wikipedia is going to be read only. It may take some time,
especially with English Wikipedia, so it's better to do conversion of each Wikipedia
separately. During steps 6-8 Wikipedia may not work at all, but it's going to
take less than a minute.
Does anybody have any really good reason why shouldn't I proceed ?
These reasons aren't good enough:
* broken URLs - all old URLs are going to work after upgrade
* size increase - size is going to stay about the same
* broken browsers - they should be upgraded, if someone has browser so old
that it doesn't grok UTF-8, it's not going to grok CSS,
PNGs, and other things we're using either.
Unless we want to remove all CSS and PNGs, there's
no point in not using UTF-8.
* ISO 8859-N is good enough - no, it's not. Not if someone wants to write about
people and places from countries where non-8859-1 Latin
characters are used, or about linguistics, or math, etc.
Peter Gervai wrote:
>Could you point us to the page and revision of the problem?
This happens on meta's Main Page often. Ask Anthere and Erik for other
>I'm curious what kind of problem it might have been, as many
>of the Wikipedias are in UTF-8 from the start, and we had no
Probably because their browsers work nicely in UTF-8 because they have to. If
they didn't they would be useless for any language where UTF-8 is required.
In places where UTF-8 isn't required, browsers that can't support it tend to
slip by without being fixed or upgraded. If it ain't broke...
>However we *do* have problems with english wikipedia when
>pages contain unrepresentable literal characters, which makes
>the page break after editing. See "Budapest" article on wikitravel,
>where every special dash and curly quote marks became question
>marks. Truly ugly.
I don't understand. Is Wikitravel in UTF-8?
-- Daniel Mayer (aka mav)
On Tue, Nov 18, 2003 at 04:28:32AM -0500, Daniel Mayer
> Peter Gervai wrote:
> >Could you point us to the page and revision of the
> > couple examples:
> > This happens on meta's Main Page often. Ask
Anthere and Erik for
>I see. First is not a good example, Opera 5 is
>_ancient_, you can't expect that anyone would support
>it, as upgrading is clearly painless.
This is NOT true. I tried upgrading to Opera 6, and it
was unworkable, because it needed to much memory for
my computer to handle it. Sure enough, I did not break
anything any more, but the browser had great
slowliness, and crashed on average every 30 mn. This
is not precisely what I call *painless*
I kept it for a while, just to edit meta page, then
gave up because it was just too much hassle.
The upgrade is perfectly ok if you have a recent
computer. But you cannot expect every user to have so.
There was a big campaign about 4 years ago in France,
and many many people bought some imacs. I doubt very
much the casual user just bought a brand new computer
since then. Except for wikipedia, I did not meet any
problem with it, fine for power, fine for dvd, fine
for internet. Just problem on wikipedia. And I bought
a boosted one.
I know it is not possible for these users to use Opera
6, and not possible to switch to system X.
>Second example is indeed valid, but it isn't a
problem >for you: if the page does not contain
non-8859-1 >characters, nothing gets garbled. If it
>does contain others then, well, you *need* utf-8 on
>that page anyway. (Embed codes are a little bit slow
>to type, don't you agree? If not, write your
>reply manually by using embeds. :))
I do not understand that comment.
French people suggested they could just by hand
correct broken caracters.
This is not an option I fear
I just made an example : this is what appear after my
edit : http://meta.wikipedia.org/wiki/Lorraine
Can you figure manually correcting each time after a
I have the plain answer : I saw a couple of reaction
on meta to my destructive edits; I was just reverted;
I know very well that if we switch to utf-8 on all
wikipedias without a technical tweak to automatically
insure "translation", the user of this browser,
perhaps just a mother at home with a 4 years old imac,
perhaps a student in Algeria, perhaps a kid in Brasil,
will just be kicked out.
Perhaps is it just 2%, and perhaps those editing
wikipedia right now are people technically better
equipped that the average human being connected to
internet, and perhaps we just do not want to keep it
that way, and perhaps we want liberty and openess.
Depends on what is important.
>I understand your problem, it is valid, and that's
>probably the reason it's topic on wikitech. Still I
>believe we can expect editors to use non-ancient
>browsers (remember, reading is not a problem).
But perhaps we do not want to exclude these people
from editing ?
>As far as I know most
>browsers handle this very well (including, for
>example, unix character
And perhaps most users know nothing about unix
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
>If UTF-8 has enough advantages (and many people seem
>to think it does), then telling 2% of the userbase
>that their browser is outdated and corrupts pages
>when editing seems acceptable.
The pages will only get corrupted by their browsers
/if/ we switch to UTF-8! So why lock out 2% of our
user base just to make it a bit easier to have
non-Latin scripts on a Latin-based language wiki?
[NOTE: I agree that UTF-8 makes sense on meta though;
there the advantages /do/ outweigh the benefits.] But
if those 2% can be accommodated as is and we can have
UTF-8, then great. Otherwise my idea of having a
separate UTF-8-friendly edit window for language codes
would solve the language link problem (which, IMO, is
the only issue that has real merit here).
Sorry, but as a long-time Linux desktop user I get a
bit pissed whenever somebody brings up the "only x%"
arguments. It is often used as an excuse to prevent me
from using certain websites. When I see "You need to
upgrade your browser" I leave and never come back. We
needn't repeat the "only x%" type of attitude here.
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
>I know very well that if we switch to utf-8 on all
>wikipedias without a technical tweak to automatically
>insure "translation", the user of this browser,
>perhaps just a mother at home with a 4 years old imac,
>perhaps a student in Algeria, perhaps a kid in Brasil,
>will just be kicked out.
Exactly! We should be as inclusive as practically possible. If that means that
we have to be just 'good enough' in our technical capabilities and forgo
being 'great', then so be it. This is why wikitext works great for our goals
(creating content) while HTML does not, even though much more can technically
be done with HTML. But if we can be both inclusive /and/ be technically
'great', then all the better!
Hm - that reminds of wikitables and wikitemplates. Whatever happened to those
-- Daniel Mayer (aka mav)
>Please! Let's all return to the 6-bit ASCII set,
>everything else is bloat, and unsupported by
Nobody is advocating that - certainly not me. But where there are perfectly
acceptable alternatives that are nearly universal (read: ASCII quotes and
hyphens), then we should use those instead of slightly fancier alternatives.
>Please, also, keep your Netscape 4 and watch it break
>every standard and recommendation that W3C proposed.
I use Konqueror 3.1.3, which IIRC is more standards compliant the IE. However
many people still use their pre-installed versions of Netscape 4 or whatnot
because that is what came with their computer. Most of these people simply
want their computer to do things for them; they don't care about things like
browser versions and compatibility. Therefore, in their view, if a website
they visit doesn't work on their browser their first thought is that the
website is broken, not their browser.
So if their browser works fine on a Latin-1 wiki as is, then why should we
change things to 'break our website' for them? They may also not have the
time, interest, confidence, hardware, bandwidth, OS version or permissions
needed to upgrade.
You shouldn't assume others are like you and don't mind upgrading things. Most
people I know have /never/ upgraded /anything/! Everything comes
pre-installed when they get a new computer.
-- Daniel Mayer (aka mav)
I noticed on the fr: Bistro
(http://fr.wikipedia.org/wiki/Wikip%E9dia:Le_Bistro) that a university
lecturer is planning on getting students to write articles as part of
Some of you may remember this happened with the en: wikipedia a few
I suggest that we create a page on Meta of guidelines for this sort of
thing, since I imagine we'll be seeing more of it.
* we welcome it! :)
* make sure your students understand NPOV
* and so on
-----BEGIN PGP SIGNED MESSAGE-----
> Following my demand, the Ouvaton cooperative has offered to host a read only
> mirror of the French Wikipedia with a budget of 1000 euros for a year in
> hardware and bandwidth. For that it is necessary that a non profit
> organisation to be set up in France. I drafted a project of status for this
> according to French law. It is available at
I think I may not have been very clear.
Ouvaton is a cooperative of independant webmasters. As an example, it is
supportive of our ideas (free software, etc.). It offers to host a mirror of
Wikipedia for FREE. They would give Wikipedia up to 1000 euros a year in
material and bandwidth. A few people in the French Wikipedia have already
offered to take care of the technical details of this mirror. Now I have been
told than a mirror in France would not help much. How the offer of Ouvaton
can be used?
Secondly Ouvaton asked than an organisation (not an individual) need to be
legally responsible for this mirror. Upon further asking, it said that
Wikimedia Foundation or a European organisation can be this organisation.
The idea of a French or European non profit organisation was also to collect
donations. Potential avantages : easing money transfer and issuing tax
deductible receipts. Yes a French non profit can collect donations and issue
tax deductible receipts.  There is also the possibility in Belgian law to
set up a European organisation with similar capabilities.
cf. http://www.notaire.be/info/societes/031_loi_sur_les_asbl.htm (in French)
We have more and more requests for public talks about Wikipedia in France :
three in 2003 and two more are already planned in 2004. A local organisation
would help to organise this (to print leaflets, posters...). Someone also
suggests to set up an French non profit called "The friends of Wikipedia" for
this. What do you think?
 "La loi n°87-571 du 23 juillet 1987 sur le développement du mécénat
précise que désormais, le don manuel (celui qui n'est pas pratiqué sous acte
notarié) est légalement autorisé pour toutes les associations déclarées."
http://www.non-violence.org/ | Site collaboratif sur la non-violence
http://www.forget-me.net/ | Alternatives sur le Net
http://fr.wikipedia.org/ | Encyclopédie libre
http://www.forget-me.net/pro/ | Formations et services Linux
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
-----END PGP SIGNATURE-----