We've really got to work on stabilizing the latest fun fun changes... and we can start to look at the boring stuff that needs to get done.
Stuff that's maybe not a sexy new Table of Contents or Auto-Generated Maps or Cool New Language Support or Skin That Doesn't Scare People Away, but that really needs to get done to keep the wiki running. Optimization, fixes for race conditions, minor but continuous usability problems. The stuff no one wants to touch. :)
If something strikes your fancy, please oh please claim one of these for your own:
http://meta.wikipedia.org/wiki/Development_tasks
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
and we can start to look at the boring stuff that needs to get done.
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:
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)
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)
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)
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
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.
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
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.
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 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
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
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
Timwi wrote:
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".
The part that works. ;-)
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.
Well, if you know perl, you pretty much know PHP. That's what I tell myself everytime I look at the code, at least.
I sympathize with you. And if you want to write the whole site over from scratch in perl, that's a bold undertaking. I suspect it'd be hard to get the people who have invested a lot of time in the current code to see the wisdom in doing that, esp. if the only real reason is yours and my knowledge deficit with respect to PHP.
--Jimbo
Jimmy Wales wrote:
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.
Well, if you know perl, you pretty much know PHP. That's what I tell myself everytime I look at the code, at least.
Superficially, yes, but ... for example, I was trying to program the "redirect /w/wiki.phtml?title=(.*?) URLs to /wiki/$1 when they don't contain an ampersand" feature yesterday, and I realised I had absolutely not the faintest idea how to do that. It's nice that PHP puts query string variables into PHP variables automatically, but it's not useful in this case ...
And if you want to write the whole site over from scratch in perl, that's a bold undertaking.
Well, yeah. I know.
esp. if the only real reason is yours and my knowledge deficit with respect to PHP.
That's not really the only reason. My major reason is that the currect code-base will be extremely difficult to enhance to support things like "single-signon" and inter-wiki co-ordination.
Greetings, Timwi
Timwi wrote:
Superficially, yes, but ... for example, I was trying to program the "redirect /w/wiki.phtml?title=(.*?) URLs to /wiki/$1 when they don't contain an ampersand" feature yesterday, and I realised I had absolutely not the faintest idea how to do that.
Hmm, yeah. Well, of course my mind immediately wanders to some deep voodoo of mod_rewrite, which could conceivably do that for us, although I'm sure I'll have nightmares tonight from even thinking the thought.
That's not really the only reason. My major reason is that the currect code-base will be extremely difficult to enhance to support things like "single-signon" and inter-wiki co-ordination.
Right, but what I'm saying is, there's a lot of perfectly good code that doesn't have anything to do with signing on, and it seems a shame (not to mention being error-prone for sure) to rewrite all that code in perl.
There's a lot of tricky code for handling individual language quirks, and a lot of code in the wiki parsing engine area, and so on. That stuff works pretty well, and rewriting it in perl, well, it'd be tedious.
Probably, I'm guessing, it'd be easier to go pick up a PHP book and spend an afternoon learning how to do the most basic stuff. That's my thinking, anyway.
Now, as for me, I *have* this PHP book over here, which I've been admiring the cover of for some *months*. :-)
--Jimbo
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.
You know more than you think you know. Good code is not dependent on language, but on logic. Thts the one thing I learned in comp sci. I would routinely write pseudo code programs or php programs, for my c++ projects and then just port them over, it made it sooooo much easier that way. plus php is so easy.. and the manual so good. There is a whole lot of built-in functionality, and php is designed from the ground up to work with web interfaces. Another thing is that Perl code is a little harder to understand than php since "TIMTOWTDI" . Perl tends to look a lot different depending on who programs it, while php doesnt so much because, frankly there is not allways that many ways to do it... Plus i might be biased cause i dislike perl cause I tried to learn it as my first programming langueage and i was rather confused and never got anything done... so I learned C, which I did ok with, but had a lot of trouble with stupid crap, then i discovered php.. which I loved because it reminded me of C while removing most of the tedious and confusing parts of it (dynamic memory allocation)....
Lightning
wikitech-l@lists.wikimedia.org