Mailing List Archive

Brion Vibber wrote:

> and we can start to look at the boring stuff that needs to get done.
>
> http://meta.wikipedia.org/wiki/Development_tasks

Hm. This seems to assume we will be continuing to use the Phase-3
software for quite some time.

Is this the case? I thought we were going to re-write everything again
so we will no longer need to set up independent wikis for the different
languages. It should really all be one wiki, or at least the user should
think so.

At least I seem to have picked up something like that somewhere. Let me
know if I'm completely off-track. Of course, I'd be very willing to
participate in another complete re-write.

Greetings,
Timwi

Timwi wrote:

>> http://meta.wikipedia.org/wiki/Development_tasks
>
>
> Hm. This seems to assume we will be continuing to use the Phase-3
> software for quite some time.


It assumes we're using it *right now* and performance sucks *right now*
and we can make improvements *right now* with relatively little effort
(compared to a rewrite) focused on specific parts of the code.

> Is this the case? I thought we were going to re-write everything again
> so we will no longer need to set up independent wikis for the
> different languages. It should really all be one wiki, or at least the
> user should think so.


Someday, perhaps.

But complete rewrites take time, and introduce new and better bugs. ;)
Phase III still has bugs that weren't in and lacks features that were in
phase II, a year after we put it online.

Better to refactor the existing code bit by bit until it looks
completely different, and naturally that way. :)

-- brion vibber (brion @ pobox.com)

Brion Vibber wrote:

> But complete rewrites take time, and introduce new and better bugs. ;)
> Phase III still has bugs that weren't in and lacks features that were in
> phase II, a year after we put it online.
> Better to refactor the existing code bit by bit until it looks
> completely different, and naturally that way. :)

This sounds like you're opposed to another rewrite?

I don't think the current Phase 3 software can elegantly/efficiently be
enhanced to handle several languages within one server/installation.

Timwi

Timwi wrote:

> Brion Vibber wrote:
>
>> But complete rewrites take time, and introduce new and better bugs.
>> ;) Phase III still has bugs that weren't in and lacks features that
>> were in phase II, a year after we put it online.
>> Better to refactor the existing code bit by bit until it looks
>> completely different, and naturally that way. :)
>
>
> This sounds like you're opposed to another rewrite?

WorseIsBetter, my friend. While a rewrite can hypothetically be far
superior to the current code, it would take a while to get there, at the
expense of our present needs.

Switching from phase 2 to phase 3 set back the non-English installations
by months as existing development effort on unicode support and
translations got thrown away and new development effort was spent fixing
new bugs and restoring lost features. I'm not in a hurry to repeat that
experiment; it's not at all clear that the present code is better than
what we'd have if we'd spent the time fixing phase 2.

> I don't think the current Phase 3 software can elegantly/efficiently
> be enhanced to handle several languages within one server/installation.

Then _make_ it elegant. :) Refactor the code so those global variables
aren't so global and language-specific things are kept properly isolated.

Handling multiple languages, unfortunately, just *isn't* elegant. Each
language will have its own rules for sort order, capitalization,
acceptable letters in links, how to munge search indexes to match
properly, etc. Turning the namespace-title doublet into a
language-namespace-title triplet and zealously keeping track of it may
be a useful direction to look at, or it may not.

-- brion vibber (brion @ pobox.com)

Timwi wrote:


> I don't think the current Phase 3 software can elegantly/efficiently be
> enhanced to handle several languages within one server/installation.

I don't think a single server should handle several languages. We see
currently that two servers can't manage...I'm quite happy that wikipedia
can easily distributed on many servers. Even many web-severs supporting
one-language-handling-database server should work.

And at home.. whats the problem of some additional links to the source (or
even a copy) and some redirects in the web-server?

I don't know how come up with the matter, but I think it's very useless.

--
Smurf

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

First of all, Ich möchte dem deutschen Kontingent
danken -- für das Verwenden von Zeit, englisches zu
erlernen, Nutzen zu allen mit ihren Fähigkeiten und
Wissen dadurch gebend.

Back to business... I think its reasonable that now
be the time to deal with some of the vast and varied
ideas about software changes -- lofty or not -- and to
do so with some reasonable suggestion that not all of
this be upon Brion's shoulders. Since a journey of a
thousand miles begins with a single step, its not
unreasonable to start formalizing and accepting a
"roadmap" to the future of WP.

Lofty ideas abound, and though anyone can come up with
these, it ought be fair to say that no single
individual should be tasked with the job of keeping up
with an exponentially greater amount of admin tasks -
and the related bright ideas that necessitate them.
These two things -- staffing and development -- in an
*ideal world , should be unrelated.

Meine Entschuldigungen für die geschlachtete Google
Übersetzung oben.

Respektvoll,
-S-

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

Could we get the Arabic wiki nav bar to default to the
right side please, Brion?

This might be appropriate for the Hebrew wiki as
well.... though you might ask someone there...

-S-

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

steve vertigo wrote:

>Could we get the Arabic wiki nav bar to default to the
>right side please, Brion?
>
Sure... done. Reload pages as necessary.

>This might be appropriate for the Hebrew wiki as
>well.... though you might ask someone there...
>
Will ask.

-- brion vibber (brion @ pobox.com)

Thomas Corell wrote:

> Timwi wrote:
>
>> I don't think the current Phase 3 software can elegantly/efficiently
>> be enhanced to handle several languages within one server/installation.
>
> I don't think a single server should handle several languages.

I suppose I wasn't being very precise. It doesn't have to be a single
server (which is why I said "installation" also). It should, however, be
one consistent system as a whole, not several independent systems. I'm
talking on a more ideological level ("what it looks like to the user")
rather than the technical implementation of it ("what it looks like to
the system administrator").

Take LiveJournal, for example. (Ignore for the moment that it's the only
website/codebase I know in real detail ;-) ) ... They have several
webservers and a load balancer that distributes incoming requests to
them. They also have several database servers, called "clusters", and
users' journals are randomly distributed over these clusters. Yet
LiveJournal is a single system in the sense that it is possible to add
another user to your own friends list (to name just an example)
seamlessly even when you're on different clusters. There is only one
additional "global" database (the "master") which stores all the global
data (e.g. user preferences), which is tiny in size compared to the
clusters that store users' journal entries and the comments thereto.

What I find disturbing about the current Wikipedia setup doesn't really
have anything to do with running everything off multiple servers. It's
just that the different Wikipedia servers are too separate in the
following sense:
* You need an extra login on each of them.
* You have to change your preferences on all of them individually.
* You have to follow several watchlists/recent changes lists.
* You have to add Inter-Wiki links in *both* directions.
(Ideally, adding X to Y should add Y automatically not only to X, but
also to all other wikis that X links to.)

Ideally, Wikipedia should have one "master" database to take care of
passwords, preferences, watchlists, bans, etc. - which would be a
ridiculously small database compared to the language-specific contents,
whether or not it should also contain the entire User: namespace (which
would be an interesting topic for a separate discussion). Then each
language would have an own database; those databases could be put all on
one server first, and later they can be easily spread over several servers.

This is how I feel it /should/ work. Of course, if any of you can point
out disadvantages that I'm not seeing (except, of course, for the fact
that we don't have a software to do this yet), please feel free to reply
and discuss.

> I don't know how come up with the matter, but I think it's very useless.

Despite the fact that I can't make a lot of sense of this sentence, I
have a feeling it contains a trace of unnecessary polemics.

Greetings,
Timwi

Danke, Brion.

Quick Progress report...

Im in the process of translating the essential
links...
(got my little book out :) )

Bugs -- the frame size of the edit window gets too
big... on 1256 encoding, it looks like its fine, --
The font sizes tend to be smaller though -- my Unicode
font looks awesome... though im sad to say they only
show up as unicode in the edit window -- which makes
them pretty useless.

Am i doin something screwy?

-S-

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

correction -- the utf-8 seems to be only one that
works... I thought the bottom text on the frontpage
was unicode...

-S

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

steve vertigo wrote:

>correction -- the utf-8 seems to be only one that
>works... I thought the bottom text on the frontpage
>was unicode...
>
Terminology note:

"Unicode" is a _character set_, which maps abstract numerical code
points to characters. Unicode code points (and hence characters) may be
represented in a number of ways.

"UTF-8" is a _character encoding_, which maps Unicode code points to
variable-length sequences of bytes. UTF-8's primary feature is that it
is compatible with ASCII, which has made it popular in Unix and internet
contexts as a more or less backwards-compatible way of storing Unicode text.

"UTF-16" is another character encoding, which maps Unicode code points
to 16-bit integers. (Or, sometimes, to two 16-bit integers.) For
historical reasons and/or stupidity ;) UTF-16 (or its evil elder sister
UCS-2) may get called "Unicode" by some software. If you select
so-called "Unicode" encoding for a page that's encoded in UTF-8, you'll
probably corrupt the display.

There are also many domain-specific ways of encoding Unicode characters;
in HTML and XML (and SGML, if the document character set is defined as
Unicode) you can use sequences such as 〹 (decimal) or ሴ
(hexadecimal). Because these only use ASCII characters to do their dirty
work, they're robust through other character encoding conversions and
can be typed in any text editor (if you know the numbers). However they
are specific to that type of markup language, take up more space than
binary encodings, and don't necessarily survive forms well if let
through unencoded.

-- brion vibber (brion @ pobox.com)

Timwi wrote:
> * You need an extra login on each of them.
> * You have to change your preferences on all of them individually.
> * You have to follow several watchlists/recent changes lists.

I've traditionally referred to this group of features as "single
sign-on". I don't think that there's any opposition to these features
at all, and they are much desired.

> This is how I feel it /should/ work. Of course, if any of you can point
> out disadvantages that I'm not seeing (except, of course, for the fact
> that we don't have a software to do this yet), please feel free to reply
> and discuss.

Well, there is one potential complication. Right now, someone could
be signed up as 'John' on the en.wikipedia.org, and someone else could
be signed up as 'John' on the de.wikipedia.org, and they might not
even know each other or realize that there's a collision.

So when we merge usernames across the wikipedia, we have to deal with
that _somehow_, and doing so in a sensitive way that doesn't annoy too
many people is a good idea.

But, really, I think that the main obstacle here is just code. It's
an easy thing to want something, it's a harder thing to make it
happen.

And I tend to agree with Brion and others who have come down on the
side of a need for immediate performance gains and bug fixes *for
right now*, as opposed to grand plans for the future.

But, you know, if you're interested in working on a grand plan for the
future, by all means... :-) I'd be eager to see single sign-on, that's
for sure.

--Jimbo

Jimmy Wales wrote:

> Timwi wrote:
> I've traditionally referred to this group of features as "single
> sign-on". I don't think that there's any opposition to these features
> at all, and they are much desired.
>>This is how I feel it /should/ work. Of course, if any of you can point
>>out disadvantages that I'm not seeing (except, of course, for the fact
>>that we don't have a software to do this yet), please feel free to reply
>>and discuss.
> Well, there is one potential complication. Right now, someone could
> be signed up as 'John' on the en.wikipedia.org, and someone else could
> be signed up as 'John' on the de.wikipedia.org, and they might not
> even know each other or realize that there's a collision.
>
> So when we merge usernames across the wikipedia, we have to deal with
> that _somehow_, and doing so in a sensitive way that doesn't annoy too
> many people is a good idea.

There is the problem that some users want and have different usernames in
different wiki's. The only way to handle this is keeping all those 'lokal'
users and first of all allow additional sigle-signon on the 'Master user
DB' which should handle not only single-sign-on, but even all those lokal
user accounts. I remember to designed some DB-schema to handle this, but I
don't remember if I posted it. If it is from interest, I try to search or
rebuild it, not realy a problem. And should work inside phase 3.

--
Smurf

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

Well, thanks for clearing *that up. -- %)

-S-

> "Unicode" is a _character set_, which maps abstract
> numerical code
> points to characters. Unicode code points (and hence
> characters) may be
> represented in a number of ways.
>
> "UTF-8" is a _character encoding_, which maps
> Unicode code points to
> variable-length sequences of bytes. UTF-8's primary
> feature is that it
> is compatible with ASCII, which has made it popular
> in Unix and internet
> contexts as a more or less backwards-compatible way
> of storing Unicode text.
>
> "UTF-16" is another character encoding, which maps
> Unicode code points
> to 16-bit integers. (Or, sometimes, to two 16-bit
> integers.) For
> historical reasons and/or stupidity ;) UTF-16 (or
> its evil elder sister
> UCS-2) may get called "Unicode" by some software. If
> you select
> so-called "Unicode" encoding for a page that's
> encoded in UTF-8, you'll
> probably corrupt the display.
>
> There are also many domain-specific ways of encoding
> Unicode characters;
> in HTML and XML (and SGML, if the document character
> set is defined as
> Unicode) you can use sequences such as 〹
> (decimal) or ሴ
> (hexadecimal). Because these only use ASCII
> characters to do their dirty
> work, they're robust through other character
> encoding conversions and
> can be typed in any text editor (if you know the
> numbers). However they
> are specific to that type of markup language, take
> up more space than
> binary encodings, and don't necessarily survive
> forms well if let
> through unencoded.
>
> -- brion vibber (brion @ pobox.com)
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@wikipedia.org
>
http://mail.wikipedia.org/mailman/listinfo/wikitech-l


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

> And I tend to agree with Brion and others who have
> come down on the
> side of a need for immediate performance gains and
> bug fixes *for
> right now*, as opposed to grand plans for the
> future.
>
> But, you know, if you're interested in working on a
> grand plan for the
> future, by all means... :-) I'd be eager to see
> single sign-on, that's
> for sure.
>
> --Jimbo


I foolheartedly agree.

-S-
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@wikipedia.org
>
http://mail.wikipedia.org/mailman/listinfo/wikitech-l


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

Thomas Corell wrote:
> There is the problem that some users want and have different usernames in
> different wiki's. The only way to handle this is keeping all those 'lokal'
> users and first of all allow additional sigle-signon on the 'Master user
> DB' which should handle not only single-sign-on, but even all those lokal
> user accounts.

Hmmm, that's interesting. Complicated but interesting.

At Yahoo, I notice that I can have multiple 'profiles' for a single
login. I'm not 100% sure what that means, but I suppose it's similar
to what you are saying?

Under a system like you're proposing, I could create a new 'master'
account, 'Jimbo Wales', and then consolidate all of my 'local'
accounts under it, so for example, 'Jimbo Wales' could "own" 'en:Jimbo
Wales' and 'de:Jimbo Wales' and even 'jp:Yojimbo' (just a joke, I
don't really have such an account as that.

I love the concept, but does it introduce a layer of unfriendly
complexity for the end user?

-----

The way I was thinking of it is that people could have a single signon
across all the wikipedias, and if they want a different id on one,
then they could just create it, and it would work everywhere of
course, but they'd just have two accounts and could use one on 'jp'
and one on 'en' if they wanted.

Your solution is more elegant, in that it does away with the problem
of namespace collisions, I guess.

But it could be very confusing for users in some cases?

--Jimbo

Jimmy Wales wrote:

> Under a system like you're proposing, I could create a new 'master'
> account, 'Jimbo Wales', and then consolidate all of my 'local'
> accounts under it, so for example, 'Jimbo Wales' could "own" 'en:Jimbo
> Wales' and 'de:Jimbo Wales' and even 'jp:Yojimbo' (just a joke, I
> don't really have such an account as that.
>
> I love the concept, but does it introduce a layer of unfriendly
> complexity for the end user?

Well, it should work exacly this way, but only for existing accounts.
I try to explain some steps of the concept, I hope it helps:

Creating a user will only works on the 'master'. All the names used on any
other language could be blocked, if we want 'Jimbo Wales' give a change to
keep 'Jimbo Wales', if not, the master has no limits in choosing names.

If we want that you can make 'en:Jimbo Wales' a master account, we ask on
the login form if and where (here: en) you have an old account. And we
query the passwort. If everything matches fine, we create the master
account Jimbo Wales and now you can add additional accounts from other
languages. We can present each language a 'Jimbo Wales' is known, and ask
for Passwort to activate the name on the master. If no 'Jimbo Wales' in any
other languages is left to add, we can ask to remove all old accounts on
the languages and remove the data about the other language links in the
master and mark it as 'full converted' user. Than you have single sign on.

There may be some more questions on the login form, but and that why I
created this proposal, someone with different names on different languages
can keep those names. Without broken links in the Article-Histories etc.
(Additionaly I still think a user_right 'deleted' should be added, to
handle this mater of broken Username links properly.) And new users get
automatically single-sign-on. Of course we can adding different profiles on
different languages, but first of all my idea was to get rid of those
language specific account, without the need to give everybody a new
username and get long protest mails.

The proposal try to follow the idea: single-singn-on for new users, and
giving old users a chance to keep their old name. More technical stuff
(more inteligence in the database) is better than unlucky users.

Additionaly we can search for old, unused users and remove them (no
reference to them in article histories, texts etc.) to keep the
User-Databases clear. But thats a mainainance issue.

> The way I was thinking of it is that people could have a single signon
> across all the wikipedias, and if they want a different id on one,
> then they could just create it, and it would work everywhere of
> course, but they'd just have two accounts and could use one on 'jp'
> and one on 'en' if they wanted.

Well the concept tries to get rid of those 'language-usernames' but it
support's them, for old users. Of course we can add the complexer way to
create language users as 'subusers' even for newusers, but that's not what
I indended in the beginning.


> Your solution is more elegant, in that it does away with the problem
> of namespace collisions, I guess.
>
> But it could be very confusing for users in some cases?

I think we have enough helpful users, if there are some confused ones.

Please write me if I wrote things you don't understood, my english is not
so good, that I'm sure all the time I wrote all the right way. And
describing proposels without seeing questionmarks on the other face is
difficult.

--
Smurf

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

Smurf wrote:

>There is the problem that some users want and have different usernames in
>different wiki's.

I wouldn't call that a *problem*.
If we merge usernames across the various wikis,
then these people will have 2 (or more) usernames.
So naturally they'll have to set preferences for each separately
and log on to each separately, and watchlist each separately, etc.
But this is no worse for them than things are now.

To be sure, the following is a reasonable /additional/ feature request,
and there's no reason to avoid it:

>The only way to handle this is keeping all those 'lokal'
>users and first of all allow additional sigle-signon on the 'Master user
>DB' which should handle not only single-sign-on, but even all those lokal
>user accounts. I remember to designed some DB-schema to handle this, but I
>don't remember if I posted it. If it is from interest, I try to search or
>rebuild it, not realy a problem. And should work inside phase 3.


-- Toby

Jimmy Wales wrote at first:

>Timwi wrote:

>>* You need an extra login on each of them.
>>* You have to change your preferences on all of them individually.
>>* You have to follow several watchlists/recent changes lists.

>I've traditionally referred to this group of features as "single
>sign-on". I don't think that there's any opposition to these features
>at all, and they are much desired.

You mean that /changing/ this group is "single sign-on", yes?
^_^


-- Toby

Toby Bartels wrote:
> >>* You need an extra login on each of them.
> >>* You have to change your preferences on all of them individually.
> >>* You have to follow several watchlists/recent changes lists.
>
> >I've traditionally referred to this group of features as "single
> >sign-on". I don't think that there's any opposition to these features
> >at all, and they are much desired.
>
> You mean that /changing/ this group is "single sign-on", yes?
> ^_^

Yes, yes! Sorry for the lack of clarity. All of those things
are bad. Getting rid of them is good, and I call the good thing
'single sign-on'.

Jimmy Wales wrote:

> Well, there is one potential complication. Right now, someone could
> be signed up as 'John' on the en.wikipedia.org, and someone else could
> be signed up as 'John' on the de.wikipedia.org, and they might not
> even know each other or realize that there's a collision.

Well, I've thought about the issue of merging user accounts, and I have
come to a conclusion. Do we need to do that at all?

I mean, we're not hosting anything for the users except for their
preferences. A user can re-create an account (and re-set all
preferences) within a few minutes. Wouldn't it be worth starting with a
whole new userbase? It has the added bonus of getting rid of inactive
users in the old system.

Or perhaps we could make it so that a Phase-IV user can "claim
ownership" of a Phase-III user (by entering their e-mail address and
password) and then all their article history and contributions will be
transferred to them.

That takes the issue off our shoulders, and it will take every user no
more than a few minutes to do.

> But, you know, if you're interested in working on a grand plan for the
> future, by all means... :-) I'd be eager to see single sign-on, that's
> for sure.

If I started this as another whole new Phase-IV software, would there be
a chance it would be used on Wikipedia? As I'm sure you understand, I'm
reluctant to starting it if it's not going to be used anyway. And I
can't really judge this because I haven't been here for very long yet.

If yes, would anyone object if I bring us back to Perl this way? :-)

Greetings,
Timwi

Timwi wrote:
> I mean, we're not hosting anything for the users except for their
> preferences. A user can re-create an account (and re-set all
> preferences) within a few minutes. Wouldn't it be worth starting with a
> whole new userbase? It has the added bonus of getting rid of inactive
> users in the old system.

Well, all of the article histories attribute edits to particular
people. So, you know, just starting over willy-nilly seems like a bad
idea to me.

> Or perhaps we could make it so that a Phase-IV user can "claim
> ownership" of a Phase-III user (by entering their e-mail address and
> password) and then all their article history and contributions will be
> transferred to them.

Sure, something like that makes sense.

> If I started this as another whole new Phase-IV software, would there be
> a chance it would be used on Wikipedia? As I'm sure you understand, I'm
> reluctant to starting it if it's not going to be used anyway. And I
> can't really judge this because I haven't been here for very long yet.
>
> If yes, would anyone object if I bring us back to Perl this way? :-)

Yikes, I wouldn't recommend doing that. I personally wish it was perl
all along, but since I have only rarely coded anything since the old
UseMod days, and since I'm embarassed at how crufty my coding is (you
should see the bailing wire and chewing gum that holds Bomis
together!)...

But, really, it seems like we have a *lot* of really good code that
should be reused, even in a radical refactoring of the code?

--Jimbo

Jimmy Wales wrote:

> But, really, it seems like we have a *lot* of really good code that
> should be reused, even in a radical refactoring of the code?

The problem there is that you need someone to reuse the code; this
someone would have to be able to tell what is "really good code". I know
no PHP apart from the obvious, so this someone won't be me ;-) Judging
from the proportion of what I know about PHP to what I know about Perl,
I think as long as Wikipedia will be on PHP, I won't be able to submit
anything beyond bugfixes and minor cosmetic changes.

Greetings,
Timwi