1 Jul 2003 02:09
1 Jul 2003 09:54
Re: Really copy logo in update.php?
Hi, folks! Brion Vibber wrote: > a) You can set the wiki to use a different file for the logo. > b) You can put your custom logo in your work source tree. > c) You don't need to use update.php at all. I don't; I use a script that > copies individual files into all running wikis' live script directories. There are surely some workarounds but I doubt that they make any sense. I mean, if we provide an update script, it should do exactly this: update the wiki software. It should not update any content. Neither should it have to be replaced (?) by a custom update script (a good proof that our script is useless). I think the only usable workaround is item a) but it still is a workaround. Why should I copy an image that is not used at all to the installation path? This issue is probably more philosophical than technical, though, but it's still an issue. Before I write my own update script I want to check if other ppl have the same problems. If they do (and it seems so) we should update the update script to make it more useful. Bye! Matthias
1 Jul 2003 10:09
Re: Dynamic dates
>Eclecticology wrote: > >The ISO format is based on numerical dates. Thus for the example it would >be 2003-06-24. It includes hyphens and has leading zeros for days and >months. To the extent that I have been applying them I would enter such a >date as [[2003]]-[[06-24]]. The first hyphen is outside of the link, and I >have written redirects for the numerical dates on an as required basis. I didn't bother putting that one in because there didn't seem to be much support for it on the voting page. I can put it in if you want. It will be infinitesimally slower than the rest due to the need for month name->number conversion. >tarquin- > > It seems a little bats that at a time when our databse is struggling, > > we're adding more load to the system for something so trivial. > >This should not add substantial load if properly coded, since it's just a >search/replace operation with a fairly specific match (only triggers on >linked dates). That's my thinking too, although I haven't tested it. There's no extra DB access, which by far forms the lion's share of the time required to display a page. CPU load is about 5-6 lightweight preg_replace calls. They all match a limited number of characters, and start with "[[". I thought long and hard about various possible implementations: say, a single more complex regex plus some PHP code to distinguish between the various cases, but I decided that would take longer. Ditto for somehow incorporating it into replaceInternalLinks(). The only faster thing way I can think of is writing it in C. Setting up the regular expressions from the month name array is(Continue reading)
1 Jul 2003 14:49
New feature and new string in LanguageXX.php
Hi, folks! I implemented the feature that allows users (and the admins) to define a default set of namespaces for searches. Doing so, I had to add a new string to LanguageXX.php: defaultns. The string is already defined in Language.php and LanguageDe.php. Since my skills in other foreign languages are not that good I'd want to encourage the maintainers of the respective files to include that string soon. The changes have already been committed to the CVS repository. Bye! Matthias
1 Jul 2003 17:22
Anchors (Was: "Edit this section", TOC implemented)
Erik Moeller wrote: >Toby Bartels: >>I also have another technical question for Erik: >>How does [[Special:Whatlinkshere]] interact with this? >It simply shows the links to the page, without the anchor. But the anchors >don't break Special:Whatlinkshere. I'm afraid that I don't understand the response. '_` I'll ask a more precise question: If [[Z]] links to [[X#Y]] but not to just plain [[X]], then will [[Special:Whatlinkshere&target=X]] list [[Z]]? -- Toby
1 Jul 2003 18:41
Re: New feature and new string in LanguageXX.php
Hi,
I want to suggest some improvements:
* Page-titles: more details for bookmarks+browserhistory
** Language-Code (en, de ...)
** Pagetype, like "Search", "Special", "WhatLinksHere", "PageHistory"...
("Editing" already gets into the page-title)
E.g. instead of "Sport - Wikipedia" and "Sport"
it should be "Sport - Wikipedia-DE" and "Whatlinkshere: Sport"
* Tweaks on the links for Next/Prev page:
** Recent changes: The current output is:
Show last 50 | 100 | 250 | 500 changes in last 1 | 3 | 7 | 14 | 30 days.
Show new changes starting from HH:MM 1 Jul 2003
It would be nice to also have a link "Show changes older then...",
because "100" re-displays the first 50 entries.
** Page history:
the prev/next links look like this:
"View (previous 50) (next 50) (20 | 50 | 100 | 250 | 500)."
This is misleading on the last page of the list, e.g.
"(next 50)" is not deactivated as on the first page.
* Upload-page: after a successful upload, show some
cut&paste examples how to use the file, like:
[[Image:YourPicture.jpg]]
or:
(Continue reading)
1 Jul 2003 19:24
1 Jul 2003 22:15
fr: is almost death, de: is very slow also
Hi there, Since about one hour fr: is slower and slower. Now it's almost death. de: is very slow also, but en: seems to be more or less OK. Is there a problem? -- -- Luc Van Oostenryck aka Looxix
2 Jul 2003 08:48
Enhanced special page links (in testing)
It's been oft complained that it's difficult to link to various special functions -- backlinks, contribs, and the like -- which might be nice. I made a quick hack to allow tacking a parameter onto a special page in a wikilink, like so: [[Special:Contributions/User name]] [[Special:Whatlinkshere/Page title]] [[Special:Recentchangeslinked/Page title]] etc See some examples and try it out at on the test wiki at http://test.wikipedia.org/ The slash (/) doesn't have to be the separator character; if people find it offensive I'm sure we could change it to something else. :) A(nother) colon may or may not be preferable. An advantage that a variant on this scheme has over the experimental interwiki prefixes Erik put in a bit ago ([[BackLinks:foo]] etc) is that it will require no additional per-wiki maintenance, and can be used across existing interwiki links (once set up on the live wikis), eg: [[DeWikipedia:Spezial:Contributions/Eloquence]] would work from English Wikipedia, or even from other unrelated wikis so long as they support the DeWikipedia prefix.* A disadvantage (so far) is that since history & editing don't go through special pages, they'll need a little more work to set up on a similar(Continue reading)
2 Jul 2003 10:24
Re: Dynamic dates
Hi, folks! Erik Moeller wrote: > our pages while not giving up some editorial liberty. I therefore fully > support the implementation of this feature, unless the code is completely > nutsActually, I looked at the code to make some changes to my private language file and didn't understand it. I know somehow what the code does but not how, because I didn't want to spend that much time decoding all those regexps that make the code pretty cryptic and hard to maintain - with the added bonus of not having /any/ documentation. Why not rearrange the code into two segments: Segment one would parse the linked date like present in the article into three numerical values: day, month, year. The second segment then would only have to concat those values (maybe with a converted month name) into the final form. This form could be given in the usual "$1 $2 $3 $4" syntax (with e.g. $4 being the month name). That also would take some load off the server that now has to interpret lots of regexp patterns, which isn't too cheap because these patterns normally first get converted into some form of a finite automaton that is eventually given the input string for processing. (At least the code by Tatu Ylonen proceeds in this way.) Bye! Matthias
RSS Feed