On Thu, Dec 05, 2002 at 08:41:21PM -0800, Jonathan Walther wrote: meta and sep11 are similar to "languages". They are not namespaces, they have a db of their own and a domain of their own. Links like [[m:bla bla bla]] are treated different to language-links. They are rendered inline, similar to a [http://www.blabla.com/] link. JeLuF

On Sat, 2002-12-07 at 00:11, Jonathan Walther wrote: In the text instead of spirited up to a list at the top of the screen. eg the wikicode: This [[m:Linking gone mad at meta-wikipedia|link to meta]] is in the text. But [[fr:Liens, liens sans fin|this French one]] isn't. renders as: Other languages: <French> Some Page from Wikipedia, the free encyclopedia This <link to meta> is in the text. But isn't. unless you're in a talk page or on meta or sep11, in which case you get: Talk:Some Page from Wikipedia, the free encyclopedia This <link to meta> is in the text. But <this French one> isn't. WikiName:ArticleTitle is the standard interwiki link syntax; the language codes are just abbreviated forms of the wiki name. That local namespaces and interwikis both involve some text followed by a colon shouldn't bug us too badly... after all, URLs start the same way! (And we really _should_ allow URL links in the same double-bracket style as wikilinks; newbies try it naturally and get confused when it doesn't work.) -- brion vibber (brion @ pobox.com)

On Sat, 2002-12-07 at 00:47, Jonathan Walther wrote: (language links & inline appearance) Sounds nice; a link vanishing from the middle of the text is confusing, but the edges are where 'magic' can be reasonably expected to take place. Note that a few pages have the lang links stuck at the bottom instead of the top, and whitespace is common. "de:Deutschland" is shorter and more site-specific than "DeWikiPedia:Deutschland", but functionally the same (seeing the special prefix, we use a stored URL associated with the prefix and slap the remainder of the title onto the end of the URL as an external link, instead of treating it as an internal wiki link - ie checking for page existence, linking to our own server, using an edit link form if the page doesn't exist). That we sometimes move the link to the top of the screen and name it for the language is just a UI matter. Historical cruft; our wikicode syntax is largely inherited from UseModWiki. I think the freelink syntax ([[foo|bar]]) was added after the single-bracket named URL links; the space isn't usable as the separator for free links since they can contain spaces in the link portion. The space should be maintained for compatibility, but allowing the pipe to work as expected would be a very good thing. At that point, using double brackets would give a working link with an extra pair brackets around it; though some find that annoying. I would prefer having the double-brackets work 'as expected'. -- brion vibber (brion @ pobox.com)

On Sat, 2002-12-07 at 01:25, Jens Frank wrote: Please comment and encourage others to comment at http://meta.wikipedia.org/wiki/Thoughts_on_language_integration ! I want to hear from people who have concerns *so we can address them*. It would be trivial to make partial database dumps for each language available for download, so if someone wants to exercise their right to fork and only wants to take material from one language, that's easy enough to accomodate. Rejoining later wouldn't be more difficult than it is now; if every single contributor for that language had left for the forked wiki, we could simply replace every changed article by importing their db dump. If some people remained at Wikipedia while others worked on a forked project, we would have to integrate them. Of course, forking isn't the only thing you can do -- getting involved and becoming part of the Wikipedia development and maintenance team to improve it where it's got problems is always an option. -- brion vibber (brion @ pobox.com)

Clutch wrote in part: What's missing for me is why. Wikipedia pages now have a 3level name structure: language (or meta or sep11), namespace (possibly empty), and title. What's wrong with this? -- Toby

On Sun, 2002-12-08 at 16:27, Jonathan Walther wrote: I would disagree. User pages should be available per-language as they are now. The namespace names also should be localizable, and must not be explicitly and forever tied to some particular foreign language (ie English). Special page names are English-only at the moment, and that is a deficiency that should be repaired. That's not an "english image", it's an english *image description* page. Description pages are text, which is in some language. Language has to be explicitly known so we can output Content-Language headers for browser config and search engine filtering; select the default user interface language to use, in some cases use a slightly different layout (right-to-left support?); select which bookseller links to use for ISBN links, etc. If language and namespce are squished into one level, we would still need to have a language<->namespace map, both to get the language of a given page and to select pages in multiple namespace that belong to a language; this would also make it a lot harder to track certain kinds of pages across languages (ie, all talk pages; all user pages; all article pages) since we'd need a map of namespace to namespace functionality... which pretty much brings us back to square one -- the namespace-language key and namespace-functionality key would be functionally indentical to the distinct language and namespace keys. There may be some advantage to an extra level of indirection there, but I don't know what. In a use where you only ever have one language/section, you'd just only ever _use_ one section. Just as you could run the current phase III software and only ever use pages in the "" namespace, it would sit in the background and you'd pay it no mind. -- brion vibber (brion @ pobox.com)

On Mon, Dec 09, 2002 at 10:14:09AM -0800, Toby Bartels wrote: Well, since we are doing a redesign, why not have 4? If that floats your boat. Just figure out what changes would need to be made to the schema on http://www.wikipedia.org/wiki/User:Clutch/mod_wiki Jonathan -- Geek House Productions, Ltd. Providing Unix & Internet Contracting and Consulting, QA Testing, Technical Documentation, Systems Design & Implementation, General Programming, E-commerce, Web & Mail Services since 1998 Phone: 604-435-1205 Email: djw(a)reactor-core.org Webpage: http://reactor-core.org Address: 2459 E 41st Ave, Vancouver, BC V5R2W2

On Mon, Dec 09, 2002 at 07:45:02PM +0100, Tomasz Wegrzanowski wrote: I like the Wikipedias version of what it is to be a "Wiki", and want to use it for many other projects, groups, and committees. For that purpose, I am doing the redesign, so I and others can easily deploy the Wikipedia software in a wide variety of contexts. So, whether Wikipedia ever uses it or not, I am doing this. But I want to ensure that we COULD host the Wikipedia on it. And because it is written in C as a custom Apache module, with Postgres backend, I will be able to make it very fast and efficient. If we switch to Postgres, to get the benefits of Postgres we must do a redesign of the table schema, at least. Did anyone notice that Postgres is now fully SQL92 compliant? And a redesign of table schema means we can design it so that generating a regular wiki page only involves ONE query, instead of the current TWELVE. A long term redesign of the software could definately be beneficial. The better we design the future Wikipedia software, the easier it will be to write, maintain, and extend. In the process of the redesign, we hope to make it so that current issues with the Wiki software are natural and easy to solve. Join in if you like. http://www.wikipedia.org/wiki/User:Clutch/mod_wiki Jonathan -- Geek House Productions, Ltd. Providing Unix & Internet Contracting and Consulting, QA Testing, Technical Documentation, Systems Design & Implementation, General Programming, E-commerce, Web & Mail Services since 1998 Phone: 604-435-1205 Email: djw(a)reactor-core.org Webpage: http://reactor-core.org Address: 2459 E 41st Ave, Vancouver, BC V5R2W2

On Mon, Dec 09, 2002 at 08:22:42PM +0100, Tomasz Wegrzanowski wrote: Yes, but we were limited by MySQL each time. Have you used Postgres or Oracle or Sybase before? I have a hard time expressing briefly how great SQL92 compliance is compared to the subset that MySQL supports. Using MySQL for this is walking the long way around the bay when you could paddle the Postgres canoe directly across it in a fraction of the time. I agree and I would love to see your thoughts on all of these issues, and how best to solve them. The last two items should be fairly simple, if we require users to install Apache on their local boxes. How can we improve markup? I too feel it might be lacking somehow. What do you mean by media independance? By using C, we can use lex and yacc to make an excellent LALR parser Postgres will solve the slow database issue. No, Postgres really does require a full redesign to reap the benefits. Replication (database mirroring) comes with Postgres; we have a choice of the dbmirror, and the dbbalancer contributed modules. We can choose synchronous or asynchronous; I recommend asynchronous for speed. Jonathan -- Geek House Productions, Ltd. Providing Unix & Internet Contracting and Consulting, QA Testing, Technical Documentation, Systems Design & Implementation, General Programming, E-commerce, Web & Mail Services since 1998 Phone: 604-435-1205 Email: djw(a)reactor-core.org Webpage: http://reactor-core.org Address: 2459 E 41st Ave, Vancouver, BC V5R2W2

Jonathan Walther wrote: There are other wiki software projects that aim at a broad range of uses. This one is for running wikipedia. If others can use it too, fine. Focus should remain on wikipedia. OK, I understand that, and though I don't have experience with Postgres, I agree about the C part. I wrote a C++ wiki parser as proof-of-principle once, and it was fast as hell on my local machine, compared to the PHP software (which was using cached pages!). It got lost in some systems crash or Linux update, though ;-) Now *that* would really help! Magnus

On Mon, Dec 09, 2002 at 01:53:19PM -0800, Brion Vibber wrote: Add a third one: we need to know if the user has read his Talk page since it was last modified. For the second one, don't we just need to check the existance and type of the linked pages? Why bother about the size? We do also need to get the size of the primary page. What do the "restrictions" on a page consist of? Whether it is readable or editable? Still, that is a 2/3 savings. Jonathan -- Geek House Productions, Ltd. Providing Unix & Internet Contracting and Consulting, QA Testing, Technical Documentation, Systems Design & Implementation, General Programming, E-commerce, Web & Mail Services since 1998 Phone: 604-435-1205 Email: djw(a)reactor-core.org Webpage: http://reactor-core.org Address: 2459 E 41st Ave, Vancouver, BC V5R2W2

On Tue, Dec 10, 2002 at 02:54:49PM -0800, Brion Vibber wrote: Ah. I was assuming that empty articles wouldn't exist unless they had been purposely cleared in an edit war. *cough*RK*cough* Even though we are storing the text in UTF-8? Is that safe? Ok, fair enough. It is the permissions scheme that I was hoping could be redesigned, but I agree some sort of permissions scheme is needed. A note about searching: with Postgres we can just set up the UTF-8 collation on the article text fields, and then we can use LIKE clauses to search for text in the articles and titles, and the characters will be collated correctly, without any extra coding on our part. Another reason I am eager to use Postgres. The search engine will be trivial. Jonathan -- Geek House Productions, Ltd. Providing Unix & Internet Contracting and Consulting, QA Testing, Technical Documentation, Systems Design & Implementation, General Programming, E-commerce, Web & Mail Services since 1998 Phone: 604-435-1205 Email: djw(a)reactor-core.org Webpage: http://reactor-core.org Address: 2459 E 41st Ave, Vancouver, BC V5R2W2

On Tue, Dec 10, 2002 at 03:16:51PM -0800, Brion Vibber wrote: Well, IF we are not going to store article sizes separately, then we need to retrieve the text of all articles linked to when we render an article page. And THAT means I can do this with a single query after all, instead of three. Yes, quite fast. We can rank pages however we want; we could use an ORDER BY clause to sort results by article title, or by timestamp, or anything. How is searching currently done? Jonathan -- Geek House Productions, Ltd. Providing Unix & Internet Contracting and Consulting, QA Testing, Technical Documentation, Systems Design & Implementation, General Programming, E-commerce, Web & Mail Services since 1998 Phone: 604-435-1205 Email: djw(a)reactor-core.org Webpage: http://reactor-core.org Address: 2459 E 41st Ave, Vancouver, BC V5R2W2

On Tue, Dec 10, 2002 at 04:07:04PM -0800, Brion Vibber wrote: In fact, I was assuming the opposite; that doing a second query to find the size and existance of all the links would be much more efficient. I also think we see significant savings (if not now, in the future when there are more pageviews than edits) of CPU by storing the article size, instead of calculating it every time we access it. Thank you for pointing that out, Brion. I did some more research; PostgreSQL has a contributed fulltext searching module which we can enable to get the same functionality. It will definately be preferable to using a LIKE clause. Jonathan -- Geek House Productions, Ltd. Providing Unix & Internet Contracting and Consulting, QA Testing, Technical Documentation, Systems Design & Implementation, General Programming, E-commerce, Web & Mail Services since 1998 Phone: 604-435-1205 Email: djw(a)reactor-core.org Webpage: http://reactor-core.org Address: 2459 E 41st Ave, Vancouver, BC V5R2W2