wikipedia-l@nupedia.com 10 July 2002 3:53 pm, Jan Hidders wrote:
Actually, I wonder if we should not do exactly the opposite: have one code base with one database that serves all wikipedias. I have the feeling that in terms of software maintenance the non-English wikipedia's are getting a very raw deal indeed; reported bugs are fixed earlier on the English wikipedia and the major software changes always happen there first. I assume this creates a feeling of being left out there in the cold. Having one common system would in my opinion also strengthen the sense of community.
Just want to say that I think this would be an excellent idea (if it's feasible)! It really would lead to very tight integration of the projects (e.g. being able to choose which language to perform searches in among other things -- see below). This would also allow, as you said, for instant updating of all wikis at once (assuming any new hard-coded wording is translated). This is how most software is developed, why not here? (although the install routine of most other software requires choosing ONE and only one language; so I am not sure if multiple languages could run at the same time in the same program).
In addition, it would also be neat if users could then be able to set their preferences so that they could choose which languages pops up in their version of RecentChanges. Then Brion could watch all changes made to both the Esperanto wiki and the English wiki at the same time in the same Recent Changes, Anthere could do that with the French and English wiki and I could watch the English, Spanish and what the hell, Latin wikis in the same RecentChanges.
If a user wanted to, they could have a tower of Babel going on in their "Inter-wiki Recent Changes". For example: Clicking on de:atom in RecentChanges (or Cambios Recientes, Ostatnie zmiany, Changements Récents....) would take the user to the German article with all the sidebar links, the logo and hard-coded wording in German (even though the underlying php code would be exactly the same -- language meta tags could be affixed to each page in the database to ID the language the article was written in). The fr:, de:, eo:, en: or whatever would only be part of the display of the page's name in such a Inter Wiki RecentChanges and wouldn't be actually part of the article's name -- just like the current inter wiki links in the php software running the English wikipedia.
Of course, this feature would by default be set to only display the language of the wiki the user signed-in with for that session -- with no language codes in front of page names.
I don't know if this would be easier or harder than having separate software programs running the separate language wikis. But then, I could just as easily split the display of my web browser Konqueror into two panes - one with Recent Changes and the other with Cambios Recientes. But I'm lazy and stubburn. :-)
--maveric149
wikipedia-l@nupedia.com 10 July 2002 3:53 pm, Jan Hidders wrote:
Actually, I wonder if we should not do exactly the opposite: have one code base with one database that serves all wikipedias. I have the feeling that in terms of software maintenance the non-English wikipedia's are getting a very raw deal indeed; reported bugs are fixed earlier on the English wikipedia and the major software changes always happen there first. I assume this creates a feeling of being left out there in the cold.
For what it's worth, I'm one of the programmers and even *my* favored wiki (Esperanto) is still running the old crappy software despite several promises for an imminent upgrade. So don't feel bad folks, we're not doing it on purpose! We're just slow...
Having
one common system would in my opinion also strengthen the sense of community.
Daniel Mayer wrote:
Just want to say that I think this would be an excellent idea (if it's feasible)!
The current software is intended to be able to be run from the same source files, with the exception of a unique wikiLocalSettings.php for each wiki, which specifies among other things which localization file to use. (Note however that it expects everything to be in one directory, so symbolic links for everything but the settings file pointing to a master directory is the simplest way to achieve this.)
Thus, only one set of files will need to be updated to get all wikis upgraded. But any given access to the wiki will be only in one language at a time...
It really would lead to very tight integration of the projects (e.g. being able to choose which language to perform searches in among other things -- see below).
A while ago I whipped together a primitive meta-search page that will pop a search term into multiple language wikis: http://leuksman.com/misc/wikisearch.php
It's not too fancy, but nice if you want to check for articles on people, as names are usually the same...
In addition, it would also be neat if users could then be able to set their preferences so that they could choose which languages pops up in their version of RecentChanges. Then Brion could watch all changes made to both the Esperanto wiki and the English wiki at the same time in the same Recent Changes, Anthere could do that with the French and English wiki and I could watch the English, Spanish and what the hell, Latin wikis in the same RecentChanges.
I notice activity on the Latin wikipedia has dropped off a bit of late. Perhaps someone should advertise in alt.language.latin? ;)
If a user wanted to, they could have a tower of Babel going on in their "Inter-wiki Recent Changes". For example: Clicking on de:atom in RecentChanges (or Cambios Recientes, Ostatnie zmiany, Changements Récents....) would take the user to the German article with all the sidebar links, the logo and hard-coded wording in German (even though the underlying php code would be exactly the same -- language meta tags could be affixed to each page in the database to ID the language the article was written in). The fr:, de:, eo:, en: or whatever would only be part of the display of the page's name in such a Inter Wiki RecentChanges and wouldn't be actually part of the article's name -- just like the current inter wiki links in the php software running the English wikipedia.
Of course, this would be highly dependent on keeping all wikis on the same server, with all databases accessible to the same program. This may be considered as incentive not to fork. :)
In any case, while combining multiple languages into one view might be fun and occasionally useful, I think a more pressing question is that of linking between the language wikis.
As a number of people have pointed out, the current system (on the PHP software which currently only the English wiki is running) is fragile, and is going to become very hard to maintain: links to the article on the same topic in every other language must be manually inserted on each wiki... this is labor-intensive and prone to becoming out of sync as people add links on some wikis but not on others.
Proposals for improvements have included a separate database table to hold the links, or having each non-English wiki link just to the English article and having the software automagically grab the rest of the links from the English database. Personally I prefer a separate database table; people should be able to edit the link list from their own language environment without delving into the English wiki. In either case, though, the programs will all need access to the same shared link database, so we would need to keep things on the same server.
I don't know if this would be easier or harder than having separate software programs running the separate language wikis. But then, I could just as easily split the display of my web browser Konqueror into two panes - one with Recent Changes and the other with Cambios Recientes. But I'm lazy and stubburn. :-)
It wouldn't be harder per se, just different from the current setup, where each language is (logically) a separate server, with separate article and user databases.
-- brion vibber (brion @ pobox.com)
On Wed, Jul 10, 2002 at 09:06:47PM -0800, Brion VIBBER wrote:
The current software is intended to be able to be run from the same source files, with the exception of a unique wikiLocalSettings.php for each wiki, which specifies among other things which localization file to use. (Note however that it expects everything to be in one directory, so symbolic links for everything but the settings file pointing to a master directory is the simplest way to achieve this.)
On a more practical note. I assume that future changes will often involve adding new files, so Jimbo would have to add new links for every separate wikipedia every time. I would propose to divide the files in a 'local' and 'global' directory such that every wikipedia only needs a single link to the common scripts that doesn't change.
[...] Personally I prefer a separate database table; people should be able to edit the link list from their own language environment without delving into the English wiki. In either case, though, the programs will all need access to the same shared link database, so we would need to keep things on the same server.
I fully agree with all of the above. Another reason for keeping everything on the same DBMS server is that this is the only way we can build a page for checking if an uploaded file is used anywhere.
-- Jan Hidders
wikipedia-l@lists.wikimedia.org