subject: [Wikipedia-l] Phase IV, Wikibooks.org/.com and WikimediaFoundation.org/.com (was Wikis and uniformity)

body:
Erik wrote:
>Making a site like Wiktionary or textbook.wiki
>international is a lot of work with the current
>setup. A copy of the code and a new database
>has to be created for each language, and the
>relevant texts have to be adapted.

Brion's idea for a multilanguage Phase IV where all the now separate Wikipedia
wikis would be in a single database under a single software installation
would help a great deal (skins would take care of localization).

We could extend that idea by having separate databases/software installations
only between different Wikimedia projects (which should all have their own
domain names anyway). Subprojects/language versions within the same Wikimedia
project would all be in the same database; each wiki page would need a
language/subproject tag - or table thingy - and those wiki pages would be in
their own directories (again the directories would be named after the
appropriate language code).

Side note: IMO, "MediaWiki" would be a good name for our officially nameless
software. "PediaWiki" never worked for me since the software is used in at
least several non-encyclopedia contexts and will likely be used by many more
in the next several years.

But all that is less important than optimizing the current code.

>It is better to wait a bit, but keep internationalization
>in mind from the start. The "textbook"-wiki will likely
>be relocated to wikibooks.org, where we can then
>use the scheme that Mav proposes.

Hm. The last thing we need is a porn site at wikibooks.org so since everybody
is referring to Wikibook as Wikibooks I went ahead and bought
wikibooks.org/.com too. And while I was at it I went ahead and purchased
WikimediaFoundation.org/.com as well.

All these domain names will be donated to Wikimedia as soon as it is able to
accept a legal transfer of ownership. It will be up to the Foundation to
decide what to do with all these domain names and whether or not it makes
sense to renew them (if so then I'll probably help to finance that too but
I'm sure I won't be the only one).

But for now they are safe from cyber squatters for at least the next year (I'm
still mad at myself for not purchasing wikimedia.com before a squatter got
it).

-- Daniel Mayer (aka mav)


list: wikipedia-l

source: pipermail-mbox

from_name: Karl Eichwalder

subject: [Wikipedia-l] Re: Wikis and uniformity

body:
"Hr. Daniel Mikkelsen" <daniel at copyleft.no> writes:

> Wiki syntax is essential to the purity of the content. And the purity
> of the content is essential to most Wiki sites. Especially to
> Wikipedia, where we want the content to be ready to use in print, on
> PDAs, for blind people, etc.

If this is your agenda, SGML/XML would be the way to go.  The so called
wiki syntax without HTML extentions is to limited and worse, it is
mostly layout oriented, and with HTML extentions it is the usual chaos.

Don't take me wrong, chaos isn't necessarily bad ;)

--
                                                         |      ,__o
http://www.gnu.franken.de/ke/                            |    _-\_<,
ke at suse.de (work) / keichwa at gmx.net (home)               |   (*)/'(*)


list: wikitech-l

from_name: Timwi

subject: [Wikitech-l] Re: Löschung

body:
Lars Aronsson wrote:

> In German, these different word endings are never (?) longer than the
> last two characters of a word, which made me suggest the following
> algorithm, from which I think the Swedish and Danish Wikipedia could
> also benefit:

As you've already pointed out in your other mail, this will return too
many false positives (e.g. Jack Mark Doe -> Jane Mary Dew; those are
just fabricated names, but you get the idea).

I'm also opposed to making it language-specific. That'd be too complex.

My suggestion on the mailing list was to introduce new mark-up that
makes it quicker to type an equivalent to
[[Heiliges R?misches Reich Deutscher Nation|Heiligen R?mischen Reiches
Deutscher Nation]]: either
	[[Heilige[s|n] R?mische[s|n] Reich[|es] Deutscher Nation]]
or
	[[Heiliges^n R?misches^n Reich ^es Deutscher Nation]]
I prefer the latter.

I know this looks a little bit complex at first, but I'm sure you'll
have figured it out in no time (esp. Germans who need it all the time).
Even if you can't get used to it or figure it out, that doesn't matter
much, because
	1) When you read the source text, you don't really need to know
	   *exactly* how the mark-up works, you can still easily guess
	   where the link goes to.
	2) When you *edit* the source text, you can always use the
	   original pipe notation.

A case where I've always wanted this in English:

	[[socialism^t]]

Greetings,
Timwi


from_name: Anthere

subject: [Wikitech-l] change to default settings on pl.wikipedia.org

body:
--- Erik Moeller <erik_moeller at gmx.de> wrote:
> Anthere-
> Look, we both agree that the current English logo
> sucks, OK?

I would not have been so...:-)

So basing an
> argument against a largely similar logo among all
> Wikipedias on the
> current logo is really not very fair. I have not
> voiced any objections to
> the French Wikipedia coming up with their own logo
> because it is
> reasonable for you to choose a French logo over an
> English one, but I
> would have preferred it if you had made an effort to
> push for a new,
> international logo instead.

Just a word there
I wonder if the "you" is general, or if it is "me".
If me, I will just indicate here that the logo was
changed less than a month after I got under my name on
the fr wiki. It was not discussed. We were few at that
time, so one editor just designed a logo, and send it
to Jason to have it placed. He then raised an uproar
becaues Jason hesitated to immediately place it,
without Jimbo aggrement.

As far as I remember, this lead to
1) noise on the international list
2) one of my first mail to the mailing list to try to
explain where that change came from (I was also
wondering, I found it
http://mail.wikipedia.org/pipermail/intlwiki-l/2002-June/000459.html)
3) a lot of noise afterward on the french wiki,
because that had been done without discussion before
hand

Afterhand, we decided to keep it :-) Two times, there
were some discussions to change it, with no result.
Several of us also participated on meta for the choice
of a mascott. From time to time, some people try to
raise the topic of changing the name for a more
french-sound.

I think your comment "I would have preferred it if you
had made an effort to push for a new, international
logo instead." is quite strange. Very strange.

when we made the change, there was *no* (I insist on
the no) communication between the french and the
english wikipedias. We were about 10 while you already
were hundred. We had about 600 pages. We were still
phase I. We were unwelcome on meta. We had no mailing
list. The wikipedia-l was for english matters only. I
think the only traveller with me was Youssef. There
was no place to discuss *anything* in common.

Which is why my first two participations on an english
mailing list was to try to explain to Jimbo the matter
of the logo, and to try to explain what could have
lead the spanish to fork.

I think the third was to call for help because we had
*no* sysop, and thus no one had any power against
vandals and no one could do house keeping.

And the fourth was to complain there had been an
unilateral decision on putting red underlined links
default, with no international being ask their
opinion. At that time, it was agreed we could have the
question marks as preference. It was never done.
Anyway, at that time, we were not even internationals.
We were basically nothing.

Consequently, I find your comment quite out of context
Erik. Now is different (I think in part of all the
noise I made :-)). But back then, the idea of french
wikipedians suggesting the english to change their
logo is totally...

> As for changing the default skin, the only wiki that
> has done so, so far,
> is the Esperanto wiki, and this was done by Brion
> without much (any?)
> discussion. We currently have no policy on this, and
> there are only two
> ways to set up such a policy within our current
> system:
> - decision by Jimbo Wales
> - authorization of a vote by Jimbo Wales
> - consensus among all Wikipedians, including Jimbo
> Wales (not gonna
> happen)

lol. Perhaps not.

> Since Wikipedia is not a dictatorship where
> everything that is not
> expressly allowed is forbidden, in the absence of a
> policy, it would be OK
> for any of the existing wikis to change its default
> skin. It would be
> courteous and wise to wait for a word from Jimbo
> before doing so.

quite true.
But we can discuss it :-)

> There is another effect: When I first visited the
> Esperanto Wikipedia out
> of curiosity, I didn't know about CB yet and
> initially wondered whether
> this was still part of the same project -- there was
> no logo, the site was
> called "Vikipedio", and it looked entirely
> different. Many other visitors
> have reported the same experience on the Village
> Pump and elsewhere. This
> kind of reaction goes against anything that a common
> project with a common
> name stands for. It deteriorates the Wikipedia brand
> and common identity.

Agreed. Having a the same time not the same skin, not
the same logo, and not the same name...is certainly a
pb

> > as long as *all* skins are available to *all*
> > wikipedias, I see not why we would make one
> wikipedia
> > unhappy
>
> Who will be unhappy? Are we really talking about
> strong tendencies within
> the Wikipedias, or only about single individuals who
> are very vocal?

Well, we can't know this for sure without a poll...

what about setting a poll system ?

Is
> there such a thing as a "cultural preference" for a
> certain skin? The
> numbers certainly do not indicate this. The
> following percentages of users
> have changed their skin from the default to "Cologne
> Blue":
>
> German: 19.4%
> English: 8.58%
> French: 11.8%
> Polish: 12%
> Chinese: 9.18%
> Dutch: 7.42%
> Swedish: 7.55%

very interesting numbers !
perhaps biased for a lack of choice though

> I conclude that the
> different cultures are
> reasonably similar for us to set an international
> default, and that it is
> only a vocal minority that opposes such a step.

I think the numbers would not be so obvious with one
or two good skins. Perhaps you go to quickly to the
conclusion. Let's wait Tarquin proposition :-)

> Regards,
>
> Erik

Best Erik

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com


from_name: Daniel Mayer

subject: [Wikipedia-l] Wikis and uniformity

body:
Anthere wrote:
>However, if we start going toward "uniformity",
>setting all new projects based upon english
>choices, and ask other projects to fit in the
>resulting frame later on is not likely to be very
>appealing :-)

Just because the current project isn't internationalized doesn't mean that the
needs of future non-English versions are not important or that the English
version will enforce all standards. That is just silly paranoia.

My point is that the English version doesn't even know what it wants to be yet
- let's focus on developing those basic parameters and then other-language
versions can be spun-off based on the /general/ theme developed for the first
project.

This is how Wikipedia was developed and IMO it has been very successful; the
different language versions are distinct enough to meet the needs of those
languages while similar enough to be one project called Wikipedia.

The same should be the case for Wikibooks.

-- Daniel Mayer (aka mav)


from_name: Tomasz Wegrzanowski

subject: [Wikitech-l] Re: Requests for the Hebrew 'pedia

references: <bf8jre$i0s$1@main.gmane.org> <8q50iAMCpVB@erik_moeller> <bf9av8$p7n$1@main.gmane.org> <bfbkvk$95s$1@main.gmane.org>

body:
On Sat, Jul 19, 2003 at 04:35:51PM +0200, Timwi wrote:
>
> Rotem,
>
> I think you are working from a few assumptions, some of which may not
> apply, and I would like to take some time to help you understand this.
>
> Firstly, you seem to have a certain perception of possession. You seem
> to think that if you are the one to create a Hebrew Wikipedia, you will
> be the one to have full command over it. This is probably similar to how
> some athors consider articles they write as "theirs" and get annoyed
> when other people edit them; however, one of the fundamental basics of
> Wikipedia is that we are a collaborative group, and neither an article,
> nor a whole Wikipedia, is under the control of anyone.
>
> Secondly, you seem to regard the Hebrew Wikipedia, or the idividiual
> Wikipedias in general, as more separate than they actually are (or
> should be). Although technically they are separate installations of the
> Wikipedia software and use separate databases, they should ideally be,
> or at least look like, parts of a whole. All the Wikipedias collectively
> form the entire complete Wikipedia project. If you'd change the licence
> of the Hebrew texts, it wouldn't be Wikipedia anyway. The different
> language Wikipedias are interwoven in many ways not only by the
> Inter-Wiki links, but also by ideologies like NPOV and the GFDL, as well
> as a common PHP codebase that will remain the same for all of them.

It's you who is mistaken. It's not about any individual's control over
Hebrew Wikipedia, but about all Hebrew Wikipedians' control over it.
If you aren't Hebrew Wikipedian, why should you have anything to say
about that ?

Second, it's many individual Wikipedias, not one Wikipedia with many
languages, and it's going to stay that way. GFDL and NPOV are the only
policies that all Wikipedias must follow - about everything else -
and certainly the layout - should be decided by Wikipedians of each Wikipedia.


from_name: Rotem Dan

subject: [Wikipedia-l] Re: Wikis and uniformity

body:
tarquin wrote:

> Rotem Dan wrote:
>  >Each wikis is, after all, an independent internet website.
>
> But whenever we talk about better links between them, people start
> saying "it's ONE encyclopedia in many languages!".
> Make up your mind!
>
> The problem is that (YET AGAIN) people are focussing on STYLE OVER CONTENT.
> You do NOT make the he: pedia good by designing a flashy new logo & a
> new skin. You make it good by putting your nose to the grindstone and
> writing ARTICLES. It shouldn't matter what it looks like as long as it's
> clear and the content is good.
>
> ONE skin, ONE logo, across all wikipedias, running the SAME SOFTWARE
> please.
> Let's present a unified front to the world, in many languages, instead
> of a hotch-potch patchwork of different colours and styles.
>
> -- tarquin
> (and please pass on to the he: guys that their comments are welcome and
> indeeed requested on my current work on a new default skin)

Actually I am more focused in completing the articles about Mathematics
and Set theory I'm currently working on. Taking care of
style/logo/administration/embassy stuff is just something no one on the
Hebrew wiki is doing, and as I said before, I am really not interested
in these things so I thought I would quickly kill those last language
transition bugs, tune the layout and help oragnizing the logo votes.

I was really surprised in the amount of opposition I got on the mailing
lists for my request for permission to make simple, non-harmful
modifications to he-pedia's layout (and I gave the exact details, see
previous posts on Wikitech-l).

If you say it's complicated, then you probably know what you're talking
about, to me it looks like changing a few HTML tags (all modifications I
wanted to do can be overwritten quickly in an update from CVS). I am
getting truely disgusted from talking about this any longer.

Rotem


from_name: tarquin

references: <bf8jre$i0s$1@main.gmane.org> <8q50iAMCpVB@erik_moeller> <bf9av8$p7n$1@main.gmane.org> <bfbkvk$95s$1@main.gmane.org> <20030719150705.GA11036@tavaiah>

body:
Tomasz Wegrzanowski wrote:

>It's you who is mistaken. It's not about any individual's control over
>Hebrew Wikipedia, but about all Hebrew Wikipedians' control over it.
>
Well, that's wrong too.
That way lies segregation, not integration.

>If you aren't Hebrew Wikipedian, why should you have anything to say
>about that ?
>
For the same reason that writers on the Hebrew Wikipedia are welcome to
get involved on this discussion list, or on any other wikipedia for that
matter.

>Second, it's many individual Wikipedias, not one Wikipedia with many
>languages, and it's going to stay that way.
>
It is many wikipedias in different languages. That still means we should
present a unified face to the world.
We are regrettably partitioned into many groups which have trouble
intercommunicating. (perhaps we should all learn Esperanto?)

It may seem like a small thing, but if they all look the same, then they
all look like home to me, even if I don't understand the words -- and I
hope everyone else can feel that way too :-)
It saddens me every time I see the da: and the sv: logos that have the
country flags overlaid -- it feels like stepping abroad (and Wikipedia
should not be about nations, only languages). I go to the Japanese pedia
and it's just like walking into a different room where people are
talking in a different language.

-- tarquin


body:
--- Erik Moeller <erik_moeller at gmx.de> wrote:
> Anthere-
>
> > Just a word there
> > I wonder if the "you" is general, or if it is
> "me".
>
> Well, I had no idea how long the logo has been
> there. Apologies if it was
> not possible at the time to discuss these things.

first days of June 2002. More than a year ago.


from_name: Thomas Corell

body:
Tomasz Wegrzanowski wrote:

>
> Second, it's many individual Wikipedias, not one Wikipedia with many
> languages, and it's going to stay that way. GFDL and NPOV are the only
> policies that all Wikipedias must follow - about everything else -
> and certainly the layout - should be decided by Wikipedians of each Wikipedia.

Unfortunalty it's not this way. But, live is hard and we have to live with
this little inconviniences.

--
Smurf

smurf at AdamAnt.mud.de
-------------------------  Anthill inside! ---------------------------


subject: [Wikitech-l] Re: Script available for uniform statistics for all Wikipedias

body:
Erik Zachte wrote:

> I'd like to test the script with the huge English SQL dumps, but I can't
> download a 1600Mb file without transmission errors.

You should use a Download manager that can resume your download in the
case of an error. Try, for example, http://www.getright.com/ (but that's
just an example, I don't favour any particular one).

Timwi


subject: [Wikitech-l] Bug list for Hebrew wikipedia

body:
Note: this has nothing to do with the previous debate over layout/logo
policies etc. and I am currently the only person who gives feedback for
users for these problems:

The following bugs or support issues were reported by users and verified
(most has to do with right-to-left issues, not all are solvable):

* In Mozilla (only), spacing (:), dots (*) and definitions don't show up
properly (they are tied to the right, ie. not structured properly) --
probably due to partial RTL support, apparently not solvable.

* In IE, After entering a special page (statistics, orphans, etc.) and
pressing "Back" and then "Forward", the browser doesn't return to the
special page. It seems that the URL is broken (bad encoding probably) --
I don't know if this is solvable, (I know, IE sucks, but works best with
the site due to the bug above) :-)

* TeX markup looks written backward when presented as HTML. -- *Highest
priority to fix*. Either <div dir=ltr> is added to all formulas or TeX
should be always rendered as PNG (I already tell users to change to that
option in prefs, but there is currently no solution for anonymous users
except changing the defaults)

* With the sliding bar on the left (for hebrew), Konqourer shows pages
much wider than necassery. -- Don't know about this, I don't use linux
but may be a browser support issue. The user who reported this said this
is becuase the site doesn't use W3C HTML. (don't know if that's true)

* Enhanced recent changes shows left to right and small icons for
opening/collapsing don't show (i.e. not usable right now) --  Not urgent
to fix right now, but may be easy.

That's about it. The most urgent one is the problem with TeX (should
always show as PNG for anonymous and registered users). Fixing the IE
problem with "back" "forward" would also be nice (if possible).

Cheers,

Rotem


subject: [Wikipedia-l] Wikis and uniformity

body:
Erik Moeller wrote:

>Every user can experiment with skins if they are tired of the
>default look.
>
I hope in the future we can have more skins, so users have more choice.

>>The argument that all wikis should be identical because there is a
>>minority of bilingual pepole
>>
>>
>
>Bilingual people are hardly a minority given how the international school
>system is set up.
>
Bilingual people are the glue that binds the different language pedias
together! they are vital to the project!

-- tarquin


from_name: Erik Moeller

subject: [Wikipedia-l] Wikis and uniformity

body:
Rotem-
> Each wikis is, after all, an independent internet website.

Wrong. Each wiki is part of the Wikipedia/Wikimedia project and has to
follow some rules and conventions that are largely identical for each of
them. All wikis are based on a common codebase; changes to the individual
codebase of a single wiki are not allowed for the reasons I have given on
wikitech. Each and every Wikipedia is governed by Jimmy Wales of Bomis.com
as "benevolent dictator".

If you want an "independent internet website", set up your own one.
However, I doubt that the majority of the Hebrew users shares your
feelings.

> I find it
> really boring and dull that all the wikis look and feel the same.

In usability, "boring and dull" can be a good thing. It avoids unnecessary
surprises. With 20 or so websites, having a different look and feel for
each of them will be confusing and annoying. If you want better skins,
make one. Every user can experiment with skins if they are tired of the
default look.

> A basic rule in marketing is to satisfy your audience. Since the
> audience of, for example, the Hebrew wiki, is not the audience of, say,
> the Polish wiki. I think each audience should have the right to choose
> how their website would look and work.

"Each audience" should have the right to participate in a vote to
determine the default skin for the project as a whole. Once we have
improved the standard skin to be somewhat nicer looking, all wikis should
use it, including Esperanto. That's why it's called the "standard skin".

> The argument that all wikis should be identical because there is a
> minority of bilingual pepole

Bilingual people are hardly a minority given how the international school
system is set up. Almost anyone who had another language in school can
understand it on a basic level, which is sufficient to do stuff like
interlanguage link insertion. Furthermore, this is hardly the only
argument you have already been given for not having a different look and
feel for every Wikipedia.

> Here's a better argument: I will design the hebrew site so it will
> be very intuitive and will take almost no effort to learn how to use it,
> yes, it would be different but very easy to use.

No. Here's what you can do: Design a skin that you and your readers like.
It will then be a user preference for all wikis. If an international
majority approves it, it can be made the international default.

What you most certainly WILL NOT do is make changes to the Hebrew wiki
without these changes going through the standard Wikipedia code approval
process. I have explained this before and I will not explain it again.

Regards,

Erik


body:
There seem to be consensus to apply that.

Warning to certain people: some Polish Wikipedians want to change default
skin too, and there's nothing non-Polish Wikipedians can do to stop it,
would consensus on it emerge among Polish Wikipedians.
-------------- next part --------------
--- LanguagePl.php.orig	2003-07-19 21:16:34.000000000 +0200
+++ LanguagePl.php	2003-07-19 21:16:48.000000000 +0200
@@ -25,9 +25,9 @@
         "quickbar" => 1, "underline" => 1, "hover" => 1,
         "cols" => 80, "rows" => 25, "searchlimit" => 20,
         "contextlines" => 5, "contextchars" => 50,
-        "skin" => 0, "math" => 1, "rcdays" => 3, "rclimit" => 50,
+        "skin" => 0, "math" => 1, "rcdays" => 3, "rclimit" => 150,
         "highlightbroken" => 1, "stubthreshold" => 0,
-		"previewontop" => 1, "editsection" => 1, "showtoc" => 1
+	"previewontop" => 1, "editsection" => 1, "showtoc" => 1
 );

 /* private */ $wgQuickbarSettingsPl = array(


body:
Tomasz-
> There seem to be consensus to apply that.

A consensus of one, I presume.

> Warning to certain people: some Polish Wikipedians want to change default
> skin too, and there's nothing non-Polish Wikipedians can do to stop it,
> would consensus on it emerge among Polish Wikipedians.

If the project leadership decides that Wikipedias are not allowed to
change their default skin, they are not allowed to do that, and any change
to that effect will be reverted. If, however, the project leadership
approves of giving each wiki the right to change the default skin, this is
indeed a choice you can make.

Regards,

Erik


body:
On Sat, Jul 19, 2003 at 09:22:02PM +0200, Tomasz Wegrzanowski wrote:
> There seem to be consensus to apply that.
>
> Warning to certain people: some Polish Wikipedians want to change default
> skin too, and there's nothing non-Polish Wikipedians can do to stop it,
> would consensus on it emerge among Polish Wikipedians.

Yeah, as if it could possibly work.

There's error: except Nl, no LanguageXX.php overrides method
getDefaultUserOptions, so %wgDefaultUserOptionsXX variables
are useless in language files.

Fix for Pl.

Already applied to pl.wikipedia.org
-------------- next part --------------
--- LanguagePl.php.orig	Sat Jul 19 19:45:59 2003
+++ LanguagePl.php	Sat Jul 19 19:44:33 2003
@@ -25,9 +25,9 @@
         "quickbar" => 1, "underline" => 1, "hover" => 1,
         "cols" => 80, "rows" => 25, "searchlimit" => 20,
         "contextlines" => 5, "contextchars" => 50,
-        "skin" => 0, "math" => 1, "rcdays" => 3, "rclimit" => 50,
+        "skin" => 0, "math" => 1, "rcdays" => 3, "rclimit" => 150,
         "highlightbroken" => 1, "stubthreshold" => 0,
-		"previewontop" => 1, "editsection" => 1, "showtoc" => 1
+	"previewontop" => 1, "editsection" => 1, "showtoc" => 1
 );

 /* private */ $wgQuickbarSettingsPl = array(
@@ -1108,6 +1108,11 @@

 class LanguagePl extends LanguageUtf8 {

+	function getDefaultUserOptions () {
+		global $wgDefaultUserOptionsPl ;
+		return $wgDefaultUserOptionsPl ;
+	}
+
         function getNamespaces() {
                 global $wgNamespaceNamesPl;
                 return $wgNamespaceNamesPl;


body:
On Sat, Jul 19, 2003 at 09:35:00PM +0200, Erik Moeller wrote:
> Tomasz-
> > There seem to be consensus to apply that.
>
> A consensus of one, I presume.

Was discussed on wikipl-l.

> > Warning to certain people: some Polish Wikipedians want to change default
> > skin too, and there's nothing non-Polish Wikipedians can do to stop it,
> > would consensus on it emerge among Polish Wikipedians.
>
> If the project leadership decides that Wikipedias are not allowed to
> change their default skin, they are not allowed to do that, and any change
> to that effect will be reverted. If, however, the project leadership
> approves of giving each wiki the right to change the default skin, this is
> indeed a choice you can make.

There is no global "project leadership" here, unless you count Jimbo's
control over servers. Certainly YOU have nothing to say about that.


from_name: Lightning

subject: [Wikitech-l] Re: Replacing the standard wikipedia logo on the Hebrew wikipedia

body:
> Lightning wrote:
>
> > Here is the screenshots.
>
> What you're seeing in IE is the "This page doesn't contain any text"
> message. It seems like it has transmitted the URL wrongly or something.
> I'm afraid I can't help you with this; it works in my IE.
>
> I'm particularly confused because it doesn't display the page title
> correctly.
>
> Could you please try the following? Go to
> http://he.wikipedia.org/wiki/Timwi
> I've put a link to the logos page there. Does it work if you follow that
> link?
>

as far as i can tell, it works from your link. maybe its OE's fault...

Lightning


subject: [Wikipedia-l] Re: Wikis and uniformity

body:
Erik Moeller wrote:

> If you want an "independent internet website", set up your own one.
> However, I doubt that the majority of the Hebrew users shares your
> feelings.

I am sick of discussing this. But that was actually proposed, not by
myself (by another user, because of lag and time zone problems, mostly).

Yes be surprised as I strongly support being a part of Wikimedia, I
strongly support all articles to be released under GFDL, and written,
hopefully from NPOV. I strongly encourage users of the Hebrew 'pedia to
read and post on the mailing lists.

I do support having (some) uniform Logo for all languages, but I don't
think that all wiki users feel good about Hobbes' quote. And by the way,
I declared I will not vote for any specific logo.

 From the Hebrew pedia's [[Wikipedia:Administrators]] page I wrote
(translated from hebrew):

"These users should not be seen as any authority on this site, decisions
that relate to policies, site-wide issues etc. are done democratically,
with an emphasis on consensus from all users. Administrators will only
engage in keeping the site from vandalism and deleting inappropriate
content (such as gibberish articles, dictionary definitions, copyright
infrigiments etc.)"

from
http://he.wikipedia.org/wiki/%D7%95%D7%99%D7%A7%D7%99%D7%A4%D7%93%D7%99%D7%94:%D7%9E%D7%A4%D7%A2%D7%99%D7%9C_%D7%9E%D7%A2%D7%A8%D7%9B%D7%AA

Please stop mischaracterizing my intentions every time I say something
you don't agree with, and yes I do think different wikis should be
allowed to have a unique personality.

Rotem


body:
Tomasz-
> There is no global "project leadership" here, unless you count Jimbo's
> control over servers.

Jimbo's control goes beyond server control, it extends to the domain and
project name as well. You can't run a "Wikipedia" without following the
rules Jimbo lays out. As for me, I will enforce the existing policies, one
of which is that no changes are made without going through CVS. Hm, I
notice that you have not bothered to commit your change to CVS. Oh well,
it wasn't important anyway.

Regards,

Erik


subject: [Wikipedia-l] Re: Wikis and uniformity

body:
Rotem-
>> If you want an "independent internet website", set up your own one.
>> However, I doubt that the majority of the Hebrew users shares your
>> feelings.

> I am sick of discussing this.

Then don't. I am quoting your own words above. Express yourself better if
you do not want to be misunderstood.

> Yes be surprised as I strongly support being a part of Wikimedia, I
> strongly support all articles to be released under GFDL, and written,
> hopefully from NPOV. I strongly encourage users of the Hebrew 'pedia to
> read and post on the mailing lists.

Having a common codebase is associated with being part of Wikimedia. You
have still not acknowledged that simple rule, or even made clear that you
understand why it is important.

Regards,

Erik


from_name: Erik Zachte

subject: [Wikitech-l] Script available for uniform statistics for all Wikipedias

body:
To Erik Moeller:

Thanks for splitting the file. I have downloaded and reassembled
everything without problems.

To TimWi:

>You should use a Download manager that can resume your download in the
>case of an error. Try, for example, http://www.getright.com/ (but
that's
>just an example, I don't favour any particular one).

I'm not talking of interrupted downloads, TimWi. As said I downloaded
the same 100 Mb file 8 times. All downloads made it till the end. All 8
files have the same byte count. Yet 4 have the correct MD5 checksum, 4
have not, each one different. I experienced problems like this before,
hence the test.

I'm not an expert on this, but might the TCP/IP internal checksum be so
small that every once in a while a transmission error by chance produces
a correct checksum for the garbled block? Such a rare event would only
be noticed on huge transfers. If one in 400,000 small HTML GETs fails
one would not notice. I one file is sent as 400,000 small packages then
it will be noticed in this all or nothing scenario.

Erik Zachte


subject: [Wikitech-l] Skins, usability, i8n and cheese

body:
Ok, well there is all this arguing about skins and different usability of
certain visible elements, and cheese (etc.) . I mentioned templates the
otehr day. We need them, it's the only way to put an end to this stuff, plus
It'll make The whole process of changing the look of the wikipedia a lot
easier. This is the standard I am proposing, if anyone wants to start coding
this cheese up drop me a line and we'll do it, I don't have CVS access but I
have a sourceforge account, besides I don'nt need it, I'll just submit it as
a patch because it might not even get accepted. Point being, heres my idea

Template sytem: SMARTY (http://smarty.php.net)

-/WIKIROOT
 |-/skins
  |-/skin1
   |-view_article.php
   |-edit_article.php
   |-preview_edit.php
   |-/templates
    |-template1.tpl
    |-template2.tpl
    |-template3.tpl
    ...
  |-/skin2
  |-/skin3
...

You get me? Baiscally wiki.phtml just gathers the data, places it into
variables and then includes() the necessary file from the correct skin
directory. That file puts the data into its necessary templates and then
spits it out. What do you think?

Here is the crucial part. HTML should completely disappear from the rest of
the script. EVERYTHING. no HTML and no strings in the code, AT ALL. strings
go into a localization file, HTML goes into templates. The apropriate *.php
file from the skin's dir.

i8n is handled by the main program, the skin files should be "dumb" to a
certain degree. They should be handed all the data they need, all they have
to do is put it in the right place and format it a little bit. To acomodate
localization correctly we should have a couple of flags, for example one for
bi-di. The rest is up to the skin.

Markup. This is kinda weird.. because if the main script handles it then we
break the no HTML thing, but then again, if it doesn't we have a bunch of
skins with different mark-up parsers? I don't know. The only thing I can
think off is to have a file especially for that function. Skins should
include() that file and use that function, but if it comes down to it. we
could just switch files for different markup parsers. eg, we could have a
normal html one, and one that makes totally valid, (no depracated) html, and
even one that spits out XHTML. of course It'd be important to make sure
these are synched up. anyways, what does everyone think? Anyone want to Join
me on this task?? I mean I want to do it, but if no one really thinks this
is a good idea it's kind of a lot of work to do, so I only really would be
willing to do it if people think this is a worthwhile effort.

Lightning


body:
Anthere wrote:

>As for editors, a default skin is no pb. If they want
>to edit several wikipedia, they just need to go to the
>prefs and set the same one.
>
>as long as *all* skins are available to *all*
>wikipedias, I see not why we would make one wikipedia
>unhappy with refusing them something that appears to
>be no big deal.
>
>Why would not we have a very simple skin as Rotem
>seems to suggest ?
>
>
Because all English-speaking mathematicians agree that we want maths
articles to appear in the Cologne Blue skin.
Mathematicians prefer it!

The other articles in the english wikipedia can stay as they are. we
don't care.


body:
Anthere-
> Please Erik, would you explain what you exactly mean
> by "the project leadership" ?

Currently the project leader is Jimbo Wales, in his absence represented by
Magnus Manske. In the future there will possibly a Wikimedia board that
can make decisions. For the remaining power structure, see

http://meta.wikipedia.org/wiki/Power_structure

Regards,

Erik


subject: [Wikitech-l] Wikipedia logo

body:
hey, I had like an idea, so i ripped offo ne of the logo's I saw on the
hebrew wikipedia, which i figured was OK because its GFDL, and I did a
little change to it... you can all see it here:
http://www.wikipedia.org/wiki/User:Lightning

 thats my proposal for a logo, I like it, I think it would work on all
wiki'd too and its just cooler than the one we have, partly because its
prettier, partly because it has no language/culture attachment whatsoever,
partly because I made it and partly because I feel it represents both the
encyclopedia aspect and the electronic aspect of our project. This is not a
finished product, its just like an idea, I dont understand the butterfly,
but it looks nice, and i like the way the book looks. mail me ideas and
suggestions.

big heads up for ROTEM DAN!
ok, now that i hope i have your attention, would you mind asking whoever
submitted the base for the logo I modified if he/she hasa a higher
resolution version or something I could toy around with? I would do it
myself, but there is the issue of language, thanks

Lightning


body:
Anthere wrote:

>Puisque des cat?gories vont ?tre mises en
>place...imagine...quelque soit la skin choisie par
>d?faut, d?s qu'on arrive sur un article dans la
>cat?gorie math?matique, hop, cologne blue (la plus
>belle de toutes fa?ons)
>
c'etait de la rhetorique.
quelle horreur!


subject: [Wikipedia-l] Wikis and uniformity

body:
Anthere-

>> No - we are one project at one website. It was a
>> mistake to internationalize
>> based on subdomains because it incorrectly gives the
>> impression that we are
>> on different websites. A much better system is to
>> have internationalization
>> based on folders; http://wikipedia.org/en/ = English
>> version,
>> http://wikipedia.org/de/ = German version, ect.

> Could the textbook site be made international then
> please ?

Making a site like Wiktionary or textbook.wiki international is a lot of
work with the current setup. A copy of the code and a new database has to
be created for each language, and the relevant texts have to be adapted.
It is better to wait a bit, but keep internationalization in mind from the
start. The "textbook"-wiki will likely be relocated to wikibooks.org,
where we can then use the scheme that Mav proposes.

Regards,

Erik


subject: [Wikitech-l] making rc smaller

body:
Tomasz Wegrzanowski wrote:

>* not generating </li>			1249 bytes saved
>
yuck!

>* not using class='internal'
>  (by making this default case)		4555 bytes saved
>
seems a good idea to do this across the pedia.
internal links are the more common.


body:
Anthere-

> So, to your opinion, Jimbo is the only one (currently,
> since there is no board yet) to have the power to say
> whether yes or no, an international wikipedia can have
> a logo not written in english, or have a different
> default skin (picked up in the list of all skins
> available for all wikipedias of course) ?

Look, we both agree that the current English logo sucks, OK? So basing an
argument against a largely similar logo among all Wikipedias on the
current logo is really not very fair. I have not voiced any objections to
the French Wikipedia coming up with their own logo because it is
reasonable for you to choose a French logo over an English one, but I
would have preferred it if you had made an effort to push for a new,
international logo instead.

As for changing the default skin, the only wiki that has done so, so far,
is the Esperanto wiki, and this was done by Brion without much (any?)
discussion. We currently have no policy on this, and there are only two
ways to set up such a policy within our current system:
- decision by Jimbo Wales
- authorization of a vote by Jimbo Wales
- consensus among all Wikipedians, including Jimbo Wales (not gonna
happen)

Since Wikipedia is not a dictatorship where everything that is not
expressly allowed is forbidden, in the absence of a policy, it would be OK
for any of the existing wikis to change its default skin. It would be
courteous and wise to wait for a word from Jimbo before doing so.

> I am more dubious of the arguments given for not
> allowing non similar default skin for example. I
> maintain that very likely, a reader will limit himself
> "most of the time" to one language only.

While that it is quite possibly true, even if only a minority of authors
spends time on two or more wikis, and even if this time is spent 90/10 on
one wiki vs. the other, having different skins will be confusing. I speak
from first hand experience: To do some usability testing on the Cologne
Blue skin (which I personally have grown to dislike quite strongly) I have
set up my account on de: to use CB. Now when I switch between en: and de:,
finding the navigational elements becomes *very* difficult, because CB is
so much different from the standard skin.

There is another effect: When I first visited the Esperanto Wikipedia out
of curiosity, I didn't know about CB yet and initially wondered whether
this was still part of the same project -- there was no logo, the site was
called "Vikipedio", and it looked entirely different. Many other visitors
have reported the same experience on the Village Pump and elsewhere. This
kind of reaction goes against anything that a common project with a common
name stands for. It deteriorates the Wikipedia brand and common identity.

> If they switch, they will perhaps not be "new" to
> wikipedia concept,

It's *especially* the new users that will likely check out other languages
simply to see what's there.

> as long as *all* skins are available to *all*
> wikipedias, I see not why we would make one wikipedia
> unhappy

Who will be unhappy? Are we really talking about strong tendencies within
the Wikipedias, or only about single individuals who are very vocal? Is
there such a thing as a "cultural preference" for a certain skin? The
numbers certainly do not indicate this. The following percentages of users
have changed their skin from the default to "Cologne Blue":

German: 19.4%
English: 8.58%
French: 11.8%
Polish: 12%
Chinese: 9.18%
Dutch: 7.42%
Swedish: 7.55%

The only Wikipedia here that has a substantially different number from all
others is the German one. Is this because Cologne is a city in Germany?
Probably not -- the current German main page has been heavily changed in
favor of Cologne Blue, and there has been lots of propaganda for CB on
some German Wikipedia pages and on the mailing list, raising awareness of
the existence of the skin. I conclude that the different cultures are
reasonably similar for us to set an international default, and that it is
only a vocal minority that opposes such a step.

Regards,

Erik


subject: [Wikitech-l] making rc smaller

body:
Some data about size of Recent Changes and possible optimalizations.

RC (Polish, anonymous) for 250 articles has 198 720 bytes.

Some possible improvements:
* not generating space after <li>	 249 bytes saved
* not generating newlines		 356 bytes saved
* using <i> not <em>			 319 bytes saved
* using <b> not <strong>		1219 bytes saved
* not generating </li>			1249 bytes saved
* not using class='internal'
  (by making this default case)		4555 bytes saved
* not generating title="..."		7329 bytes saved
* using relative links for links to
  http://pl.wikipedia.org/wiki/...	7713 bytes saved
* not generating PHPSESSID=... in links 9674 bytes saved

So:
* trivial markup changes - 2143 bytes, or 1.1% saved
* ... + making internal links default - 6698 bytes, or 3.4% saved
    (this is trivial and doesn't affect anything)
* ... + relative links - 14411 bytes, or 7.3%
    (still doesn't affect anything, but implementing generation of relative
     links may be a bit tricky as we allow many different paths to
     the same thing)
* doing all these changes except not generating </li> - 31414 bytes, or 15.8% saved
    (it may have some minor effect on functionality)
* doing all these changes - 33047 bytes, or 16.6% saved
    (won't be xhtml-compatible, but perfect html)


subject: [Wikitech-l] Re: Wikipedia logo

body:
Lightning wrote:
>>Lightning-
>>
>>>hey, I had like an idea, so i ripped offo ne of the logo's I saw on the
>>>hebrew wikipedia, which i figured was OK because its GFDL, and I did a
>>>little change to it... you can all see it here:
>>>http://www.wikipedia.org/wiki/User:Lightning
>>
>>Looks nice, but:
>>
>>1) There should be a "WikipediA" (with the letters between the W and A in
>>small caps) text below the logo, at least for the Latin Wikipedias.
>
> It was just a rough, I didnt add text cause I didn't want to upset anyone
> who doesnt use the same character set as me, you can never be too careful
> these days... ;)
>
>>2) Where does the butterfly come from? If it is copied from elsewhere,
>>there might be problems with using it.
>
> Ask the original author, I just modified it to flow into the numbers.. I got
> it from the hebrew wikipedia logo contest, i just added a couple of
> photoslopped details to it.
>
>>3) Which book do we see there, or is it just a stylization?
>
> see 2
>
>>4) Most annoying: the butterfly is cut off at the top left corner.
>
> yes i know. i would get in contact with the original author, but there is
> the slight problem of language, since i can't know who it is because I have
> a problem with reading hebrew (i can't). So until our friendly ambassador
> from the he wiki gets back here I can't contact the original author to see
> if i can get a higher res original i could play with.
>
> Lightning

The author's name is Liad Vainberger, you can contact him at
http://he.wikipedia.org/w/wiki.phtml?title=%D7%A9%D7%99%D7%97%D7%AA_%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:Wliad&action=edit

(just write something in the box)

I have announced the International logo contest on the hebrew 'pedia and
asked new submissions to be directed to the International contest
instead of the localized one. I hope we'll have an agreement on a
universal logo, participance from other wikipedias should also be
encouraged, please announce it on all languages.

--Rotem


subject: [Wikitech-l] making rc smaller

body:
Tomasz-
> * not using class='internal'
>   (by making this default case)		4555 bytes saved

I support these changes except for this one, unless it is changed
throughout the entire code base. It is also questionable whether the
"history" links are really necessary.

Regards,

Erik


body:
Lightning wrote:

> Here is the screenshots.

What you're seeing in IE is the "This page doesn't contain any text"
message. It seems like it has transmitted the URL wrongly or something.
I'm afraid I can't help you with this; it works in my IE.

I'm particularly confused because it doesn't display the page title
correctly.

Could you please try the following? Go to
http://he.wikipedia.org/wiki/Timwi
I've put a link to the logos page there. Does it work if you follow that
link?

Greetings,
Timwi


subject: [Wikitech-l] Statistics for English WP now online

body:
> I have written a PERL script that parses the SQL dumps (cur & old)
> and generates a html file, containing lots of info about
> wikipedians articles and database for each month
> since the project started:

> Please note that the script produces historical growth figures
> per Wikipedia based on the
  ** new (link) counting system **
> right from the first month.

>>> Now a report for the English WP is available as well <<<

The script parses 6 GB of data in 33 min. on my 1.2 GHz PC, which ihmo
is not too bad.

http://members.chello.nl/epzachte/Wikipedia/Statistics

I propose to run this script weekly on the new SQL dumps for all WP's
and put the resulting html files in a public folder.

ToDo:
unicode support
prepare a consolidated report for all Wikipedias
prepare a csv file e.g. for import into Excel (for graphics)

Erik Zachte


body:
Daniel-
> Brion's idea for a multilanguage Phase IV where all the now separate
> Wikipedia wikis would be in a single database under a single software
> installation would help a great deal (skins would take care of
> localization).

Well, having a single codebase (as in, set of PHP files) for all
Wikipedias is not that difficult even with the current code. Brion (or was
it Lee?) just chose to set it up as completely separate installations.
Having a single *database* is much more difficult because all the tables
and queries need to be adjusted accordingly. Merging the tables is
certainly undesirable as this would substantially slow things down (the
OLD table of the English wiki is currently 8801714176 bytes and dog slow).
However, the software could be rewritten to be always multilingual in all
available translations, and to create the necessary tables on demand.

> Side note: IMO, "MediaWiki" would be a good name for our officially nameless
> software.

Yup. Many potential wiki users have been scared away by the "Wikipedia"
name. "Isn't this just for encyclopedias?" is a question I have heard
several times. Then people end up with something useless and scary like
TWiki. How are we ever supposed to get decent competition like that? :)

> Hm. The last thing we need is a porn site at wikibooks.org

You're quite right. The erotic furry Star Trek slasher fan fiction should
be at porn.wikibooks.org ;-)

Regards,

Erik


subject: [Wikitech-l] Re: making rc smaller

body:
Tomasz Wegrzanowski wrote:
> * using <i> not <em>			 319 bytes saved
> * using <b> not <strong>		1219 bytes saved

<em> and <strong> should be used, not <i> and <b>. The reasons are
complicated and have to do with accessibility and text browsers. I don't
really understand those reasons myself, but from my experience it seems
to be consensus to use <em> and <strong>. I think <i> and <b> are even
deprecated in the newest version of HTML, or something...


subject: [Wikitech-l] making rc smaller

body:
On Sun, Jul 20, 2003 at 01:47:00AM +0200, Erik Moeller wrote:
> Tomasz-
> > * not using class='internal'
> >   (by making this default case)		4555 bytes saved
>
> I support these changes except for this one, unless it is changed
> throughout the entire code base.

Yeah, hard to do it to RC only.

> It is also questionable whether the
> "history" links are really necessary.

Well, that would mean some functionality lost. Better do those improvements
that don't affect functionality first.


subject: [Wikitech-l] Re:  TeX bug fixed on LanguageHe.php please update

body:
Rotem Dan wrote:
> That's about it. The most urgent one is the problem with TeX (should
> always show as PNG for anonymous and registered users). Fixing the IE
> problem with "back" "forward" would also be nice (if possible).
>
> Cheers,
>
> Rotem

Defaults on LanguageHe.php on meta are now:

/* private */ $wgDefaultUserOptionsHe = array(
	"quickbar" => 2, "underline" => 1, "hover" => 1,
	"cols" => 80, "rows" => 25, "searchlimit" => 20,
	"contextlines" => 5, "contextchars" => 50,
	"skin" => 0, "math" => 0, "rcdays" => 7, "rclimit" => 50,
	"highlightbroken" => 1, "stubthreshold" => 0
);

ie. I changed "math" => 1 to "math" => 0 to make TeX always render as
PNG thus fix the RTL display bug with TeX (see the bug report in
previous message for more about this).

In the case of Erik who does not seem to trust me, see
http://he.wikipedia.org/wiki/%D7%AA%D7%95%D7%A8%D7%AA_%D7%94%D7%A7%D7%91%D7%95%D7%A6%D7%95%D7%AA

Note one of the formulas on this article about set theory shows " {A =
{a,b,c " instead of " A = {a,b,c} " when TeX is set to be rendered as
HTML. (The same problem exists in another formula later on the article)

Please update http://meta.wikipedia.org/wiki/LanguageHe.php to
http://he.wikipedia.org and CVS

Rotem


body:
Anthere-

> Just a word there
> I wonder if the "you" is general, or if it is "me".

Well, I had no idea how long the logo has been there. Apologies if it was
not possible at the time to discuss these things. But it could be worse:
The first Wikipedia logo was an American flag. Imagine trying to impose
that on every 'pedia :-)

>> Who will be unhappy? Are we really talking about
>> strong tendencies within
>> the Wikipedias, or only about single individuals who
>> are very vocal?

> Well, we can't know this for sure without a poll...
> what about setting a poll system ?

Ohhh, voting systems -- I'm all for it :-). However, Jimbo has not yet
authorized voting as a general decision making process, otherwise I'd be
happy to set up a vote on what kind of changes can and cannot be made to
the various international wikis. Note also that there may be cases where
Jimbo has a different opinion than the majority of users; for example,
Jimbo certainly has a strong interest in preserving and strengthening the
Wiki[mp]edia brand, which is somewhat undermined by too large variations
in the look and feel.

>> German: 19.4%
>> English: 8.58%
>> French: 11.8%
>> Polish: 12%
>> Chinese: 9.18%
>> Dutch: 7.42%
>> Swedish: 7.55%

> very interesting numbers !
> perhaps biased for a lack of choice though

I'm all for new skins. Send me a good HTML mock-up and I might even make
one myself. I like Tarquin's proposal for the most part, even though it is
not much different from the standard skin. I do think the bottom links
should not have been removed.

Regards,

Erik


subject: [Wikipedia-l] Wikis and uniformity

body:
Daniel-
> My point is that the English version doesn't even know what it wants to be
> yet - let's focus on developing those basic parameters and then
> other-language versions can be spun-off based on the /general/ theme
> developed for the first project.

Whoa there, do I hear you advocating a planning process instead of
entirely chaotic development? Man, that's music in my ears ;-)

Regards,

Erik


subject:
[Wikipedia-l] Re: Phase IV, Wikibooks.org/.com and WikimediaFoundation.org/.com
 (was Wikis and uniformity)

body:
Erik Moeller wrote:

> Merging the tables is
> certainly undesirable as this would substantially slow things down (the
> OLD table of the English wiki is currently 8801714176 bytes and dog slow).

Are you sure the size makes it slow? The way I understand it, it
doesn't; if you split it up into several tables, it'll still have to
organise those different tables. Either way, a row look-up will be O(n)
without an index and O(log n) with an index.

What makes a database slow is the number of reads and writes it has to
perform (mainly the writes because they block the reads).

So, if my perception of this all is correct, the best way to optimise
things is to use efficient queries (trying to minimise writes,
especially on the most heavily read-from tables) and things like
MemCacheD (which heavily reduces the number of reads), and not to split
things up into several tables.

Greetings,
Timwi


subject: [Wikitech-l] Re: making rc smaller

body:
On Sun, Jul 20, 2003 at 02:18:30AM +0200, Timwi wrote:
> Tomasz Wegrzanowski wrote:
> >* using <i> not <em>			 319 bytes saved
> >* using <b> not <strong>		1219 bytes saved
>
> <em> and <strong> should be used, not <i> and <b>. The reasons are
> complicated and have to do with accessibility and text browsers. I don't
> really understand those reasons myself, but from my experience it seems
> to be consensus to use <em> and <strong>. I think <i> and <b> are even
> deprecated in the newest version of HTML, or something...

Wasting bytes where it's critical to make RC as small as possible
for "complicated reasons" doesn't really convince me.

And no, they're not deprecated in HTMl 4.01.


subject: [Wikitech-l] Re: More prefs from CVS

body:
Rotem Dan wrote:

/* private */ $wgDefaultUserOptionsHe = array(
	"quickbar" => 2, "underline" => 1, "hover" => 1,
	"cols" => 80, "rows" => 25, "searchlimit" => 20,
	"contextlines" => 5, "contextchars" => 50,
	"skin" => 0, "math" => 0, "rcdays" => 7, "rclimit" => 50,
	"highlightbroken" => 1, "stubthreshold" => 0, "previewontop" => 		1,
"editsection" => 1, "showtoc" => 1
);

Additionally, I updated more prefs from CVS: ("previewontop",
"editsection", "showtoc")

Rotem


subject: [Wikipedia-l] Re: Phase IV, Wikibooks.org/.com and WikimediaFoundation.org/.com (was Wikis and uniformity)

body:
Timwi-
> Are you sure the size makes it slow? The way I understand it, it
> doesn't; if you split it up into several tables, it'll still have to
> organise those different tables.

It certainly will, but it won't have to perform, e.g., a fulltext search
on the entire index, but only on the index for that table. Compare the
fulltext search of the English wiki with the one on the German wiki --
that is certainly no O(log n) scalability. That's why we had to disable
the English fulltext search. Now, if we merged the two into a single
index, all the fulltext searches would be as slow as the English one is.

You're right, of course, that merging the tables would especially
highlight unoptimized queries. But frankly, I'm not sure these need to be
"highlighted" any more than they are already ;-)

Regards,

Erik


subject: [Wikitech-l] Be bold in improving Wikipedia's ugly layout!

body:
tarquin wrote:

> We could have:
> * default
> * power user
> * old browsers (Netscape etc)
> * text browsers
>
> if the British summer turns REALLY lousy, I could make something with
> DHTML menus at the top!

I will help too, but I'm interested mostly in making a very simple skin
(default), to present a friendly and beautiful encyclopedia for those
journalists, readers, and reviewers who give a strong emphasis on
presentation and layout. (Just look at the Israeli internet directories,
  the biggest three give wikipedia a rating of C- probably just because
of its "so early nineties" look, but Everything2 gets an A. They don't
really bother to read their content or anything, they wouldn't
understand it anyway)

And I myself think it is very important because Wikipedia, at least the
English version, is no longer a "toolbox to create an encyclopedia", but
a regarded encyclopedia in it's own right, let's make justice for the
great content it has.

Just tell me where is the PHP code you're working on, Tarquin. Let's get
this forward, I want to update it on the wiki.. Here's my motto: "Be
bold in improving Wikipedia's ugly layout!" or "..yadda yadda.. learn
how you can improve this website's ugly look /right now/! ;-)

Rotem


subject: [Wikitech-l] Wikipedia logo

body:
> Lightning-
> > hey, I had like an idea, so i ripped offo ne of the logo's I saw on the
> > hebrew wikipedia, which i figured was OK because its GFDL, and I did a
> > little change to it... you can all see it here:
> > http://www.wikipedia.org/wiki/User:Lightning
>
> Looks nice, but:
>
> 1) There should be a "WikipediA" (with the letters between the W and A in
> small caps) text below the logo, at least for the Latin Wikipedias.
It was just a rough, I didnt add text cause I didn't want to upset anyone
who doesnt use the same character set as me, you can never be too careful
these days... ;)
> 2) Where does the butterfly come from? If it is copied from elsewhere,
> there might be problems with using it.
Ask the original author, I just modified it to flow into the numbers.. I got
it from the hebrew wikipedia logo contest, i just added a couple of
photoslopped details to it.
> 3) Which book do we see there, or is it just a stylization?
see 2
> 4) Most annoying: the butterfly is cut off at the top left corner.
yes i know. i would get in contact with the original author, but there is
the slight problem of language, since i can't know who it is because I have
a problem with reading hebrew (i can't). So until our friendly ambassador
from the he wiki gets back here I can't contact the original author to see
if i can get a higher res original i could play with.

Lightning


subject: [Wikitech-l] Wikipedia logo

body:
--- Lightning <lightning at chaos-productions.com> wrote:
> > 4) Most annoying: the butterfly is cut off at the
> top left corner.
> yes i know. i would get in contact with the original
> author, but there is
> the slight problem of language, since i can't know
> who it is because I have
> a problem with reading hebrew (i can't). So until
> our friendly ambassador
> from the he wiki gets back here I can't contact the
> original author to see
> if i can get a higher res original i could play
> with.
>
> Lightning

What about putting on the book, not a butterfly which
does not hold a lot of meaning (but is pretty :-)),
but instead one of the animal thought of possible
mascot for wikipedia ?

Several propositions were made, and some met a lot of
interest. see
http://meta.wikipedia.org/w/wiki.phtml?search=mascot&go=Go

Look, there is an *absolutely* beautiful

ant

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com


from_name: James D. Forrester

subject: [Wikitech-l] Re: making rc smaller

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 20 Jul 2003 02:39, Tomasz Wegrzanowski wrote:

> On Sun, Jul 20, 2003 at 02:18:30AM +0200, Timwi wrote:
>
> > Tomasz Wegrzanowski wrote:
> >
> > > * using <i> not <em>			 319 bytes saved
> > > * using <b> not <strong>		1219 bytes saved
> >
> > <em> and <strong> should be used, not <i> and <b>. The reasons are
> > complicated and have to do with accessibility and text browsers. I
> > don't really understand those reasons myself, but from my
> > experience it seems to be consensus to use <em> and <strong>. I
> > think <i> and <b> are even deprecated in the newest version of
> > HTML, or something...
>
> Wasting bytes where it's critical to make RC as small as possible
> for "complicated reasons" doesn't really convince me.

OK, I'll have a stab at this: the original concept of the <I> and <B> tags were to make the text they encapsulated italicised and emboldened, respectively. This is obviously a Bad Thing, as it implicitly promotes the (false) concept that HTML is a print mark-up language, as opposed to a text mark-up language, for display, printing, being read aloud, being encoded into light pulses, etc.
This isn't really 'complicated' per se, it just requires people to understand the underlying philosophy of HTML.

And a far more useful byte-stripper would be to install mod_gzip (or is this being used already?).

> And no, they're not deprecated in HTML 4.01.

To quote: "[These] elements specify font information. Although they are not [...] deprecated, their use is discouraged in favour of style sheets."

So, they are "something" similar to deprecated.

Yours,
- --
James D. Forrester
<mailto:jon at eh.org> | <mailto:csvla at dcs.warwick.ac.uk>
<mailto:jamesdforrester at hotmail.com> | <mailto:james at jdforrester.org>

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBPxoEOZJ95FMWcicdEQJPbACcCkURO1xmKi7HghHWVYYVzhMTpxwAoI1t
UgYq6+HMj9cMQw4aucwqJa5h
=Pocc
-----END PGP SIGNATURE-----


subject: [Wikitech-l] Re: making rc smaller

body:
On Sun, Jul 20, 2003 at 03:53:45AM +0100, James D. Forrester wrote:
> On 20 Jul 2003 02:39, Tomasz Wegrzanowski wrote:
> > On Sun, Jul 20, 2003 at 02:18:30AM +0200, Timwi wrote:
> > > Tomasz Wegrzanowski wrote:
> > >
> > > > * using <i> not <em>			 319 bytes saved
> > > > * using <b> not <strong>		1219 bytes saved
> > >
> > > <em> and <strong> should be used, not <i> and <b>. The reasons are
> > > complicated and have to do with accessibility and text browsers. I
> > > don't really understand those reasons myself, but from my
> > > experience it seems to be consensus to use <em> and <strong>. I
> > > think <i> and <b> are even deprecated in the newest version of
> > > HTML, or something...
> >
> > Wasting bytes where it's critical to make RC as small as possible
> > for "complicated reasons" doesn't really convince me.
>
> OK, I'll have a stab at this: the original concept of the <I> and <B>
> tags were to make the text they encapsulated italicised and emboldened,
> respectively.

What we want to say is exactly "this should be in italics",
and "this should be in bold font", not "this should be emphasized",
"this should be strongly emphasized". As what we want is exactly *font information*,
we should be using font markup.

Just think for a moment - when read aloud it should be read the same way
as the rest of text, not with any emphasis added

Anyway code style doesn't really matter here - we should use whatever
results in smaller Recent Changes.

>  This is obviously a Bad Thing, as it implicitly promotes
> the (false) concept that HTML is a print mark-up language, as opposed
> to a text mark-up language, for display, printing, being read aloud,
> being encoded into light pulses, etc.
> This isn't really 'complicated' per se, it just requires people
> to understand the underlying philosophy of HTML.

Underlying philosophy is "primitive text display markup language later
extended to support other media types, but not very good at it"

> And a far more useful byte-stripper would be to install mod_gzip (or is this being used already?).

Completely unrelated.

> > And no, they're not deprecated in HTML 4.01.
>
> To quote: "[These] elements specify font information. Although they are not [...] deprecated, their use is discouraged in favour of style sheets."
>
> So, they are "something" similar to deprecated.

This is far from that. There's really no reason to use <span class='italics'>
instead of <i>.


subject: [Wikitech-l] Re: making rc smaller

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 20 Jul 2003 04:27, Tomasz Wegrzanowski wrote:

> On Sun, Jul 20, 2003 at 03:53:45AM +0100, James D. Forrester wrote:

[Snip]

> What we want is exactly *font information*, we should be using font
> mark-up.

No, 'we' want text mark-up, '''you''' seem to want font mark-up. Font
mark-up is inherently evil and wrong in the context of a web-based
system. Feel free to fork a print-medium version of the Wikipedia; this
isn't what we are about, and never has been - Wikipedia isn't a print
medium, as is expostulated in a large variety of discussions and pages,
notably on meta.

> Just think for a moment - when read aloud it should be read the
> same way as the rest of text, not with any emphasis added

Sorry, but this is Just Plain Wrong; if you read italicised or
emboldened text as plain-spoken text, you're Doing It Wrong (tm).

> Anyway code style doesn't really matter here - we should use whatever
> results in smaller Recent Changes.

No. 'Philosophical' this point may be, but abject utilitarianism isn't a suitable method for standards design or adherence. What you propose would render the Wikipedia unusable for some people; surely this runs entirely contrary to the concept of open use that the Wikipedia aims for?

[Snip]

> > This isn't really 'complicated' per se, it just requires people
> > to understand the underlying philosophy of HTML.
>
> Underlying philosophy is "primitive text display mark-up language later
> extended to support other media types, but not very good at it"

No. NOT 'display'. Honest.

> > And a far more useful byte-stripper would be to install mod_gzip
> > (or is this being used already?).
>
> Completely unrelated.

Err, no. This can dramatically reduce the number of bytes transmitted,
which is what any and all suchwise effort is geared towards. It's certainly
not unrelated.

[Snip]

Yours,
- --
James D. Forrester
<mailto:jon at eh.org> | <mailto:csvla at dcs.warwick.ac.uk>
<mailto:jamesdforrester at hotmail.com> | <mailto:james at jdforrester.org>

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBPxoi/JJ95FMWcicdEQLgdgCfV4OsUcWRC9hNm7xgMykh4LHNZzMAn38G
Z+umOPCmNYo7z72rdxw7I/NB
=3WWI
-----END PGP SIGNATURE-----


subject: [Wikitech-l] Re: TeX bug fixed on LanguageHe.php please update

body:
Timwi wrote:
>
>> In the case of Erik who does not seem to trust me, see
>> http://he.wikipedia.org/wiki/%D7%AA%D7%95%D7%A8%D7%AA_%D7%94%D7%A7%D7%91%D7%95%D7%A6%D7%95%D7%AA
>
>
>
> On this page I am seeing a little layout problem (though nothing
> TeX-related). I've made a screenshot of it so you can see:
>
> http://meta.wikipedia.org/upload/3/3c/Screenshot_of_a_problem_with_the_current_Hebrew_layout.png
>
>
> I'm using Mozilla 1.4 in Windows 2000.
>
> Timwi
That's the problem with indenting and spacing I mentioned on the
previous post:

 >* In Mozilla (only), spacing (:), dots (*) and definitions don't show
 >up properly (they are tied to the right, ie. not structured properly)
 >-- probably due to partial RTL support, apperantly not solvable.

Do you have any idea if there's a solution for this?

Rotem


subject: [Wikipedia-l] Re: [Wikitech-l] Wikipedia logo

body:
--- Lightning <lightning at chaos-productions.com> wrote:
if i can get a higher res original i could play
> with.

Ditto

but I put my own proposition nevertheless (which could
be improved with the high res)

http://meta.wikipedia.org/wiki/International_logos

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com


subject: [Wikitech-l] Wikipedia logo


subject: [Wikipedia-l] Re: Logo contest launched

body:
--- Timwi <timwi at gmx.net> wrote:
> Erik Moeller wrote:
>
> > I have set up a new logo contest at
> >
>
http://meta.wikipedia.org/wiki/International_logo_contest
>
> There seems to be an ambiguity in this:
>
>  > The voting method for the second question may be
> simple yes/no vote,
>  > given that there are only two options.
>
> Myself, I don't see an ambiguity, but the French
> translator did:
>
>  > La m?thode de vote pour la deuxi?me question sera
> simplement oui/non ?
>  > partir du moment ou il y a uniquement deux
> options (note du
>  > traducteur : on ne sait pas si la d?cision sera
> choisi ? la majorit?
>  > ou au consensus).
>
> If someone would rectify this, I'd be grateful.
>
> Timwi

have not looked at the translation yet (Agiss good
work I think)

will do later :-)

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com


subject: [Wikitech-l] Wikipedia logo

body:
Lightning-
> hey, I had like an idea, so i ripped offo ne of the logo's I saw on the
> hebrew wikipedia, which i figured was OK because its GFDL, and I did a
> little change to it... you can all see it here:
> http://www.wikipedia.org/wiki/User:Lightning

Looks nice, but:

1) There should be a "WikipediA" (with the letters between the W and A in
small caps) text below the logo, at least for the Latin Wikipedias.
2) Where does the butterfly come from? If it is copied from elsewhere,
there might be problems with using it.
3) Which book do we see there, or is it just a stylization?
4) Most annoying: the butterfly is cut off at the top left corner.

Regards,

Erik


subject: [Wikipedia-l] Logo contest launched

body:
Wikipedians,

I have set up a new logo contest at
http://meta.wikipedia.org/wiki/International_logo_contest

Please consider adding a link to this meta page, or a translation in your
language, to the Main Page of your respective Wikipedia, so that the
largest possible number of talented artists can be directed to this page.

The deadline for logo submissions is August 20. All further discussion
should take place on the Meta talk page.

Regards,

Erik


subject: [Wikitech-l] Wikipedia logo

body:
Erik Moeller wrote:

>Lightning-
>
>
>>hey, I had like an idea, so i ripped offo ne of the logo's I saw on the
>>hebrew wikipedia, which i figured was OK because its GFDL, and I did a
>>little change to it... you can all see it here:
>>http://www.wikipedia.org/wiki/User:Lightning
>>
>>
>
>Looks nice, but:
>
>1) There should be a "WikipediA" (with the letters between the W and A in
>small caps) text below the logo, at least for the Latin Wikipedias.
>
I think it would be better if the logo has no text. Then the same
graphic can be used on all sites without any conversion.

I like it by the way :-)


body:
Lightning wrote:

>Ok, well there is all this arguing about skins and different usability of
>certain visible elements, and cheese (etc.) . I mentioned templates the
>otehr day. We need them, it's the only way to put an end to this stuff, (**snip**) Anyone want to Join
>me on this task?? I mean I want to do it, but if no one really thinks this
>is a good idea it's kind of a lot of work to do, so I only really would be
>willing to do it if people think this is a worthwhile effort.
>
>
>
I can help with making the HTML templates :)
It would be much easier to make skins if they are put into the system as
HTML documents.

We could have:
* default
* power user
* old browsers (Netscape etc)
* text browsers

if the British summer turns REALLY lousy, I could make something with
DHTML menus at the top!


subject: [Wikipedia-l] Re: Wikis and uniformity

body:
Daniel Mayer <maveric149 at yahoo.com> writes:

> No - we are one project at one website. It was a mistake to internationalize
> based on subdomains because it incorrectly gives the impression that we are
> on different websites. A much better system is to have internationalization
> based on folders; http://wikipedia.org/en/ = English version,
> http://wikipedia.org/de/ = German version, ect.

No :) I'd expect http://wikipedia.org/en/, http://wikipedia.org/de/,
http://wikipedia.org/fr/, etc. would be identical contently, just
translated.  Using subdomains means there will be subtle differences
concerning contents, layout, etc.

--
                                                         |      ,__o
http://www.gnu.franken.de/ke/                            |    _-\_<,
ke at suse.de (work) / keichwa at gmx.net (home)               |   (*)/'(*)


body:
Rotem Dan wrote:

>
> Just tell me where is the PHP code you're working on, Tarquin. Let's
> get this forward, I want to update it on the wiki.. Here's my motto:
> "Be bold in improving Wikipedia's ugly layout!" or "..yadda yadda..
> learn how you can improve this website's ugly look /right now/! ;-)
>
I don't know PHP.
I started work on a redesign of the default skin.
You can see my work in progress here:
http://meta.wikipedia.org/wiki/Paddington_skin

note this is *work in progress*.
comments are welcome!


from_name: Andre Engels

subject: [Wikitech-l] Wrong date for move

body:
On May 30, user Hooft moved [[nl:Huidziekten]] to [[nl:Dermatologie]].
However, in the database this was for some reason dated on December 28,
a time when Hooft had not started working on Wikipedia yet.

My questions:
* Is this a known bug, and if so, is its cause known?
* Has it been or will it be corrected?
* Could this one case be changed by hand?

Andre Engels


body:
Lightning wrote:
> Your link sends me here: if i copy and paste it, it works, good times. but
> if i click on it.....
>
> http://he.wikipedia.org/wiki/%D7%95%D7%99%D7%A7%D7%99%D7%A4%D7%93%D7%99%D7%94:%D7%9C%D7%95%D7%92%D7%95_%D7%91%D7%A2%D7%91%D7%A8%D7%99%D7%AA
>
> the link shows up as above, but when I click on it in on OE it opens an ie
> window with the URL below. funny aint it?
> http://he.wikipedia.org/wiki/?.?T???T???"?T?":?o?.?'?._?'???'???T??
>
>
> thats about as useful as I can be..
>
> Lightning

This is one of the bugs with some unicode URLS on explorer, I mentioned
it in the known Hebrew wikipedia buglist. (The same happens if you enter
a special page on the heb-wiki, press "Back" then "Forward", it becomes
this mess and gives a 404 wiki error :( ).

Rotem


body:
Your link sends me here: if i copy and paste it, it works, good times. but
if i click on it.....

http://he.wikipedia.org/wiki/%D7%95%D7%99%D7%A7%D7%99%D7%A4%D7%93%D7%99%D7%94:%D7%9C%D7%95%D7%92%D7%95_%D7%91%D7%A2%D7%91%D7%A8%D7%99%D7%AA

the link shows up as above, but when I click on it in on OE it opens an ie
window with the URL below. funny aint it?
http://he.wikipedia.org/wiki/?.?T???T???"?T?":?o?.?'?._?'???'???T??

thats about as useful as I can be..

Lightning

----- Original Message -----
From: "Timwi" <timwi at gmx.net>
To: <wikitech-l at wikipedia.org>
Sent: Sunday, July 20, 2003 8:19 AM
Subject: [Wikitech-l] Re: Replacing the standard wikipedia logo on the
Hebrew wikipedia

> Lightning wrote:
>
> >Timwi wrote:
> >
> >>Could you please try the following? Go to
> >>http://he.wikipedia.org/wiki/Timwi
> >>I've put a link to the logos page there. Does it work if you follow that
> >>link?
> >
> > as far as i can tell, it works from your link. maybe its OE's fault...
>
> Okay. Now, the original link was:
>
http://he.wikipedia.org/wiki/%D7%95%D7%99%D7%A7%D7%99%D7%A4%D7%93%D7%99%D7%94:%D7%9C%D7%95%D7%92%D7%95_%D7%91%D7%A2%D7%91%D7%A8%D7%99%D7%AA
> What is the URL you get when you click on my link? (I should have asked
> that in the previous mail...) Does it differ from this one?
>
> Trying to figure out a bug,
> Timwi
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


from_name: Gareth Owen

subject: [Wikitech-l] Re: making rc smaller

body:
"James D. Forrester" <james at jdmf.demon.co.uk> writes:

> No. 'Philosophical' this point may be, but abject utilitarianism isn't a
> suitable method for standards design or adherence. What you propose would
> render the Wikipedia unusable for some people; surely this runs entirely
> contrary to the concept of open use that the Wikipedia aims for?

In principle, I agree with you

... but ...

In practice, non-text based HTML renderers treat <i> and <b> in exactly the
same way as <em> and <strong>.  So although what we're doing is bad and wrong,
doing it the right way won't actually make it more accesible (and will slow
load times ... ironically making it *less* accesible.)
--
Gareth Owen
"It's not a human or civic right to edit wikipedia."
                                 -- kq cuts to the core of the banning debate


subject: [Wikitech-l] Be bold in improving Wikipedia's ugly layout! (Rotem Dan)

body:
Paddington skin leaves even less screen space for the article itself.
Remember we will have an oversized TOC soon as well.
People with 800x600 screens (still plenty of them) will see hardly any
text without scrolling.

Headers are still way oversized. Newspapers use headers this big
whenever a Titanic sinks somewhere.

'Wikipedia English' in two different point sizes and grey for the
variable part, very bad to the eyes.

This design (in progress, I know) will produce even more cases of Severe
Wikipedia Reader Stress Syndrome.

Erik Zachte


from_name: Delirium

references: <bfco4n$2v4$1@main.gmane.org> <8qD1V0UhpVB@erik_moeller> <bfee26$3v0$1@main.gmane.org> <bfepoq$jmc$1@main.gmane.org>

body:
Timwi wrote:

> I have asked my friend and he confirmed by suspicion.
>
> If you have several large tables A, B, C, ... etc. with identical
> columns and types (that could, for example, be the recentchanges
> tables for the different languages), you can always combine them into
> a big table with an extra (indexed) integer or other fixed-length
> column that specifies what original table the row came from (i.e. what
> language it's in), and it won't be any slower.

This is true in theory, and I believe true in some "big iron" production
database systems (Oracle, etc.), but I'm not sure it's true in practice
in many of the free DB systems.  In particular, big tables and big
indexes can mess up caching algorithms.  In fact sometimes it seems to
even be beneficial to split into entirely separate databases (not just
separate tables in the same database).  Why this is true I don't know
enough about the internals of the various DB systems to say, but
splitting seems to have resulted in a large speedup at kuro5hin.org,
among other places that use MySQL.

-Mark


body:
Lightning wrote:

>Timwi wrote:
>
>>Could you please try the following? Go to
>>http://he.wikipedia.org/wiki/Timwi
>>I've put a link to the logos page there. Does it work if you follow that
>>link?
>
> as far as i can tell, it works from your link. maybe its OE's fault...

Okay. Now, the original link was:
http://he.wikipedia.org/wiki/%D7%95%D7%99%D7%A7%D7%99%D7%A4%D7%93%D7%99%D7%94:%D7%9C%D7%95%D7%92%D7%95_%D7%91%D7%A2%D7%91%D7%A8%D7%99%D7%AA
What is the URL you get when you click on my link? (I should have asked
that in the previous mail...) Does it differ from this one?

Trying to figure out a bug,
Timwi


body:
> In the case of Erik who does not seem to trust me, see
> http://he.wikipedia.org/wiki/%D7%AA%D7%95%D7%A8%D7%AA_%D7%94%D7%A7%D7%91%D7%95%D7%A6%D7%95%D7%AA

On this page I am seeing a little layout problem (though nothing
TeX-related). I've made a screenshot of it so you can see:

http://meta.wikipedia.org/upload/3/3c/Screenshot_of_a_problem_with_the_current_Hebrew_layout.png

I'm using Mozilla 1.4 in Windows 2000.

Timwi


subject: [Wikitech-l] Re: making rc smaller

body:
Tomasz Wegrzanowski wrote:

> On Sun, Jul 20, 2003 at 02:18:30AM +0200, Timwi wrote:
>
>>Tomasz Wegrzanowski wrote:
>>
>>>* using <i> not <em>			 319 bytes saved
>>>* using <b> not <strong>		1219 bytes saved
>>
>><em> and <strong> should be used, not <i> and <b>. The reasons are
>>complicated and have to do with accessibility and text browsers. I don't
>>really understand those reasons myself, but from my experience it seems
>>to be consensus to use <em> and <strong>. I think <i> and <b> are even
>>deprecated in the newest version of HTML, or something...
>
> Wasting bytes where it's critical to make RC as small as possible
> for "complicated reasons" doesn't really convince me.

Could you please explain to me why you think it's critical to make RC as
small as possible? Our biggest current problem is database performance,
not bandwidth usage.

If you really want to make it as small as possible, then you should use
gzip; once that is installed, using <em> vs. <i> won't make a difference.

Timwi


subject: [Wikitech-l] Re: Wrong date for move

body:
Andre Engels wrote:

> On May 30, user Hooft moved [[nl:Huidziekten]] to [[nl:Dermatologie]].
> However, in the database this was for some reason dated on December 28,
> a time when Hooft had not started working on Wikipedia yet.

This is indeed a known bug; the bottom five entries in my
"Contributions" list on the English Wikipedia are dated 2002. I think
someone told me they are dated by the last edit, so it happens whenever
you move a page that hasn't been edited in ages.

Timwi


subject: [Wikitech-l] Re: making rc smaller

body:
On Sun, Jul 20, 2003 at 02:36:38PM +0200, Timwi wrote:
> Tomasz Wegrzanowski wrote:
> >On Sun, Jul 20, 2003 at 02:18:30AM +0200, Timwi wrote:
> >
> >>Tomasz Wegrzanowski wrote:
> >>
> >>>* using <i> not <em>			 319 bytes saved
> >>>* using <b> not <strong>		1219 bytes saved
> >>
> >><em> and <strong> should be used, not <i> and <b>. The reasons are
> >>complicated and have to do with accessibility and text browsers. I don't
> >>really understand those reasons myself, but from my experience it seems
> >>to be consensus to use <em> and <strong>. I think <i> and <b> are even
> >>deprecated in the newest version of HTML, or something...
> >
> >Wasting bytes where it's critical to make RC as small as possible
> >for "complicated reasons" doesn't really convince me.
>
> Could you please explain to me why you think it's critical to make RC as
> small as possible? Our biggest current problem is database performance,
> not bandwidth usage.

Because most people are using 56kbit modems and recent changes size is huge.
It's not about server bandwidth at all.

> If you really want to make it as small as possible, then you should use
> gzip; once that is installed, using <em> vs. <i> won't make a difference.

It's not supported by too many browsers.


subject: [Wikitech-l] Re: making rc smaller

body:
On Sun, Jul 20, 2003 at 06:05:00AM +0100, James D. Forrester wrote:
> > Anyway code style doesn't really matter here - we should use whatever
> > results in smaller Recent Changes.
>
> No. 'Philosophical' this point may be, but abject utilitarianism isn't
> a suitable method for standards design or adherence. What you propose
> would render the Wikipedia unusable for some people; surely this runs
> entirely contrary to the concept of open use that the Wikipedia aims for?

So show one case when using <i>/<b> actually breaks something or
no discussion is needed.


subject: [Wikipedia-l] Re: Logo contest launched

body:
Erik Moeller wrote:

> I have set up a new logo contest at
> http://meta.wikipedia.org/wiki/International_logo_contest

There seems to be an ambiguity in this:

 > The voting method for the second question may be simple yes/no vote,
 > given that there are only two options.

Myself, I don't see an ambiguity, but the French translator did:

 > La m?thode de vote pour la deuxi?me question sera simplement oui/non ?
 > partir du moment ou il y a uniquement deux options (note du
 > traducteur : on ne sait pas si la d?cision sera choisi ? la majorit?
 > ou au consensus).

If someone would rectify this, I'd be grateful.

Timwi


subject: [Wikitech-l] Re: making rc smaller

body:
Tomasz Wegrzanowski wrote:

>Because most people are using 56kbit modems and recent changes size is huge.
>It's not about server bandwidth at all.
>
>
I have a 56k.
The slow speed I get from RC *is* due to Wikipedia, the database I
presume. While RC is chugging s-l-o-w-l-y I can get Google results up in
no time :)

One enhancement to RC I suggested a LONG time ago was a link at the foot
of the page saying:

"Show next 100 | 250 | 500 changes"

With this, compulsive RC addicts could check a whole 24 hours of edits
in small chunks.
This might be better for the database too?


subject: [Wikitech-l] Re: Be bold in improving Wikipedia's ugly layout! (Rotem Dan)

body:
Now here's something you should see, *this* is what I call a website:
(this really rocks the boat!)

http://www22.brinkster.com/rotemdan/Wikipedia-Vorbis-site-rip.html

The original site was http://www.vorbis.com

(Basically I ripped the Vorbis site as is, I didn't upload all the
images to brinkster so there should be dead placeholders on top)

I am willing to work (if i'll find the time) for a new layout based on
standard XHTML/CSS (I can also do basic PHP), so that's just an example
to give a general idea of what I consider the layout for an average
website in the 21st century. ;-)

Rotem


subject:
[Wikitech-l] Be bold in improving Wikipedia's ugly layout! (Rotem
 Dan)

body:
Erik Zachte wrote:

>Paddington skin leaves even less screen space for the article itself.
>Remember we will have an oversized TOC soon as well.
>People with 800x600 screens (still plenty of them) will see hardly any
>text without scrolling.
>
>Headers are still way oversized. Newspapers use headers this big
>whenever a Titanic sinks somewhere.
>
>'Wikipedia English' in two different point sizes and grey for the
>variable part, very bad to the eyes.
>
>This design (in progress, I know) will produce even more cases of Severe
>Wikipedia Reader Stress Syndrome.
>
>
>
Yes, those are good points.
Recent comments & yours lead me to conclude we need 2 new skins:

* default: a simple, clear, "light" skin. most "system" links either
removed or only present in the footer. This is aimed at casual users,
readers, etc -- the Great Unwashed Masses who don't use Special Pages or
maybe don't even edit
* a redesign of our current standard skin. Most registered users may
want to set this in their preferences


body:
Erik Moeller wrote:

> Rotem-
>
>>Now here's something you should see, *this* is what I call a website:
>>(this really rocks the boat!)
>
>
>>http://www22.brinkster.com/rotemdan/Wikipedia-Vorbis-site-rip.html
>
>
> 1) We need all the screen width we can get for articles, otherwise
> floating tables, images etc. won't work very well. The design contains no
> navigational elements at all, BTW.
> 2) Having some dynamic content at the side may seem like a good idea, but
> it really gets old quickly -- literally. After browsing 10 articles,
> you'll be very tired of that "New articles" box.
> 3) The technobubbles in the table headers are inappropriate for an
> encyclopedia.
>

Ofcourse ofcourse!!! I just ripped the site as is! these are really
small things (I actually did remove the bar on the right but then I
didn't have a place to write some explanations, of course it shouldn't
be there!)

What I like is the great use of color and graphics, the boxes, the
backgrounds, the great font that looks good on 800x600 resolution (not
too big).

Tasks like "Edit this page" etc. would be put as icons wherever we want
to put them (probably on top) with very intuitive symobls.

just a second, I will remove the bar on the right and put that version
on another file, It would be on:

http://www22.brinkster.com/rotemdan/Wikipedia-Vorbis-site-rip2.html

Rotem


subject: [Wikitech-l] Re: making rc smaller

body:
tarquin-

> One enhancement to RC I suggested a LONG time ago was a link at the foot
> of the page saying:

> "Show next 100 | 250 | 500 changes"

Definitely. This is already in my TODO list. I would go so far to say that
the current linkbar could be replaced with such a linkbar, and that the
default number would only be set in the user preferences. Furthermore, it
might be useful to store the timestamp of the last check in the user
table, and to only show the changes since the last check by default --
that could substantially decrease database usage.

Regards,

Erik


body:
Erik Moeller wrote:

> Timwi-
>
>>Are you sure the size makes it slow? The way I understand it, it
>>doesn't; if you split it up into several tables, it'll still have to
>>organise those different tables.
>
> It certainly will, but it won't have to perform, e.g., a fulltext search
> on the entire index, but only on the index for that table.

First of all, I have to admit I was was being short-sighted again by
forgetting to consider fulltext searches. My apologies.

However, I'm not convinced that this really matters. It would only have
to search on the entire fulltext index if you actually wanted to search
the entire table (an inter-language search). If you had an integer
column that specifies the language of an article, and an index on that,
then searching only the English text would be equal in speed to having a
separate table for the English text.

At least this is how I understand it. Of course I may well be wrong.
I'll ask a MySQL expert later on, when he's online :-)

> Compare the
> fulltext search of the English wiki with the one on the German wiki --
> that is certainly no O(log n) scalability.

No, certainly not. What I said about O(n) and O(log n) applies to
selection of a single row from a simple key on a fixed-length column.
What I was thinking of was combining the tables to form one whole
Wikipedia database so we could have one single Watchlist and one
inter-language Recent Changes page. Then generating an English-only
Recent Changes page from the combined table should not be slower as it
is now.

Timwi


references: <bfbt7d$blp$1@main.gmane.org> <bfdlp6$kc2$1@main.gmane.org> <bfe1kj$n9p$1@main.gmane.org> <bfe4gk$vtq$1@main.gmane.org>

body:
Rotem Dan wrote:

> Timwi wrote:
>
>> On this page I am seeing a little layout problem (though nothing
>> TeX-related). I've made a screenshot of it so you can see:
>> http://meta.wikipedia.org/upload/3/3c/Screenshot_of_a_problem_with_the_current_Hebrew_layout.png
>
> That's the problem with indenting and spacing I mentioned on the
> previous post:  [...]
> Do you have any idea if there's a solution for this?

It seems to be a known problem in Mozilla.
http://bugzilla.mozilla.org/show_bug.cgi?id=198869

I should have searched Bugzilla for this earlier...

Timwi


subject: [Wikitech-l] Re: making rc smaller

body:
Tomasz Wegrzanowski wrote:

> On Sun, Jul 20, 2003 at 02:36:38PM +0200, Timwi wrote:
>
>>Tomasz Wegrzanowski wrote:
>>
>>>Wasting bytes where it's critical to make RC as small as possible
>>>for "complicated reasons" doesn't really convince me.
>>
>>Could you please explain to me why you think it's critical to make RC as
>>small as possible? Our biggest current problem is database performance,
>>not bandwidth usage.
>
> Because most people are using 56kbit modems and recent changes size is huge.
> It's not about server bandwidth at all.

A 56kbit modem can transmit 56 Kilobits per second! With TCP's ~3.8%
overhead (let's exaggerate to 4% for simplicity), it means you can
transmit 53.76 Kbit/sec = 6.72 KB/sec. The Recent Changes list as I see
it now (last 50 changes) is 40.8 KB ... this would therefore, under
perfect server performance, take almost exactly 6 seconds.

According to your own calculations, you can save up to 16.6% - that
takes it down to very close to 5 seconds.

I'm not convinced this unnoticeable improvement is worth the hassle.

>>If you really want to make it as small as possible, then you should use
>>gzip; once that is installed, using <em> vs. <i> won't make a difference.
>
> It's not supported by too many browsers.

That doesn't matter. The server can detect when the browser accepts gzip
(the Accept-Encoding HTTP header), so those that don't can still be
served the pages non-gzipped. Besides, enough modern browsers support it.

Timwi


subject: [Wikitech-l] Phase IV layout engine based on a new CMS

body:
I am starting to work on designing (and creating) a completely new,
professional layout engine for all wikimedia websites that should be
launched with phase IV of the software.

First, from what I understand, the main idea for phase IV is that all
wikipedias sit on a single software installation (and that's great!), I
will add: (Just to give the general direction to tease you up)

* Layout should be separated completely from the PHP code. I will check
out a template engine like smarty (http://smarty.php.net/) to see how to
do that effectively.

* Site look will be redesigned to fit the 21st century (new "kick-ass"
look, yes that's its name :) ). The main problem with all current
designs is that they basically still think in terms of "UseModWiki". ie.
sooooo 95' single content HTML with no color, dynamics, and no usability
features and even GodDamnHorribleCamelCase.

I think more in terms of making a Content Management System, dynamic
content type layout, which means:

* Boxes, structure and order. Everything on the page is structured
dynamically. (every editable box can have a cute "edit" and "print"
button on the top right corner, for example)

* Graphics, color, icons, friendliness, [put a cool thing here], ... (of
course not too much stickyness .. :-))

* A page can present more than just the article. Additional content may
be: TOC on the side box. Previous versions. Recent changes,
announcements, news, etc. (whatever we'll choose, or the user will
customize)

* No more dedicated stand-alone "special pages". These are important
features that deserve to be integrated (somehow) into the engine itself.
ie. forget those yellow backgrounds etc. etc.

* Discussions can be integrated into the layout. ie. they may sit after
the article itself like blogs do, and may or may not be a wiki. (just an
idea)

* Interface can change to whatever language the user specifies in their
preferences. A side effect of the single installation, a user will able
to work, say on an article in Swedish with the English interface..
(don't flame me for this, I don't know if technically it would be
viable, just giving a direction...)

* W3C XHTML 1.0 Transitional/CSS. A really basic one for a modern site
(I even use the strict XHTML 1.1 on my site). And yes, I will make sure
it uses features that are compatible with browsers from IE 4.0+ and
Netscape 6. See http://www.w3.org/ and http://www.w3schools.com/

* etc. etc. etc..

See http://www22.brinkster.com/rotemdan/Wikipedia-Vorbis-site-rip.html
for a little inspiration of what I'm talking about. (I basically ripped
the vorbis site, pasted the seinfeld article and made some changes to
the text, there's still junk on the bottom and side).

This is an enormous task. But I really think this encyclopedia deserves
to look like a modern site. I predict it will take about 2-3 months to
formulate the main targets and to understand what I'm dealing with. (and
to have a small working version of the engine)

I have enough PHP skills (but not too much free time as I'm a full-time
student) to make a basic version of a content system. I was employed for
about about a year in a software company (a couple of years ago) and
worked with ASP and SQL a lot so I know a bit about dynamic content. (I
think I'm getting the PHP thing..)

If anyone is interested in working on this or a similar project, please
let me know. Also, please give me a complete list of the Phase IV design
targets so I can generally understand how exactly the new website would
be formed.

Cheers,
Rotem

P.S: please don't start coming with specific suggestions on how this and
that feature should/shouldn't be/look/behave. The time spent on
discussions should be put in actually writing the PHP/XML code (and
applying some common sense). Replying to long messages on mailing lists
is really time consuming for me. I would just rather work on a preview
version/design etc. get feedback, work, get feedback etc..


from_name: Richard Grevers

subject: [Wikitech-l] Wikipedia logo

body:
On Sun, 20 Jul 2003 00:02:55 -0400, Lightning <lightning at chaos-
productions.com> gave utterance to the following:

> hey, I had like an idea, so i ripped offo ne of the logo's I saw on the
> hebrew wikipedia, which i figured was OK because its GFDL, and I did a
> little change to it... you can all see it here:
> http://www.wikipedia.org/wiki/User:Lightning
>
The blue butterfly is very reminiscent of early Wordperfect!
--
Richard Grevers
Computers don't laugh at a three-and-a-half-inch floppy


subject: [Wikitech-l] Re: making rc smaller

body:
On Sun, Jul 20, 2003 at 06:35:28PM +0200, Timwi wrote:
> Tomasz Wegrzanowski wrote:
> >On Sun, Jul 20, 2003 at 02:36:38PM +0200, Timwi wrote:
> >>Tomasz Wegrzanowski wrote:
> >>>Wasting bytes where it's critical to make RC as small as possible
> >>>for "complicated reasons" doesn't really convince me.
> >>
> >>Could you please explain to me why you think it's critical to make RC as
> >>small as possible? Our biggest current problem is database performance,
> >>not bandwidth usage.
> >
> >Because most people are using 56kbit modems and recent changes size is
> >huge.
> >It's not about server bandwidth at all.
>
> A 56kbit modem can transmit 56 Kilobits per second! With TCP's ~3.8%
> overhead (let's exaggerate to 4% for simplicity), it means you can
> transmit 53.76 Kbit/sec = 6.72 KB/sec. The Recent Changes list as I see
> it now (last 50 changes) is 40.8 KB ... this would therefore, under
> perfect server performance, take almost exactly 6 seconds.
>
> According to your own calculations, you can save up to 16.6% - that
> takes it down to very close to 5 seconds.
>
> I'm not convinced this unnoticeable improvement is worth the hassle.

50 changes is next to useless. 100 is minimum that's any useful, and
250 or 500 is needed to really know what's going on.

250 changes is about 200 kB, or 29s, with 16.6% less to transfer, it's 24s.
Sounds significant enough to me.