We probably need to discuss what we need.
----- Forwarded message from Candid Hosting Support <support(a)candidhosting.com> -----
From: "Candid Hosting Support" <support(a)candidhosting.com>
Date: Mon, 29 Nov 2004 11:40:21 -0500 (EST)
To: mmemmer(a)neutelligent.com, JWales(a)BOMIS.com
Subject: [candidhosting.com #115227] Install & Setup Gig Link for
Fiber has been ordered and I expect delivery this week, however I think
I may have made an error. I assumed that it would be SC to SC fiber.
Please let me know the connector type you will have on your switch so I
may get the approperate cable and a spare.
----- End forwarded message -----
--
"La nèfle est un fruit." - first words of 50,000th article on fr.wikipedia.org
Hi all!
It seems to me that handling of non-ASCII characters in interwiki
links (or in URLs in general) is a bit problematic. As an example,
take [[en:Václav Havel]]. Since en: does not use UTF-8, the URL is
".../V%E1clav_Havel". If you try to use the interwiki link to cs:
(specified in the source as [[cs:Václav Havel]]), it leads to
http://cs.wikipedia.org/wiki/V%E1clav_Havel, which is _wrong_, because
the cs: Wikipedia uses UTF-8 and the proper link should be
".../V%C3%A1clav_Havel". And, vice versa, the Czech article contains
an interwiki link (specified again as [[en:Václav Havel]]) leads to
http://en.wikipedia.org/wiki/V%C3%A1clav_Havel, which is, again,
wrong.
I believe that a correct solution (apart from the long-term solution
of using UTF-8 everywhere) could be:
* Accept UTF-8 in URLs on en: (but how could they be recognized??)
* Interwiki linking should use UTF-8 even on en: (or, does another
Wikipedia except en: use latin-1?)
Best regards,
[[cs:User:Mormegil | Petr Kadlec]]
Over at the wikien list a small flame war between PHP and perl,
resulted in a bunch of people all saying that they would love to
contribute to mediawiki development, however do not have the technical
know-how to do so. And thus was born the idea of a group PHP tutorial
with the aim of bringing people who dont know PHP up to a level where
they can do menial coding, simple bug fixes etc. for mediawiki,
freeing up time that the more skilled developers could use on
something else, and hopefully (after the internship of doing easy
stuff) become full blooded developers. So what they are looking for is
someone who has a good knowledge of PHP to act as thier guide. <uncle
sam voice> IS THAT PERSON YOU!?!?!?!?! </uncle sam voice>
hopefully,
[[w:User:The bellman]]
rjs
--
hit me: robin.shannon.id.au
jab me: saudade(a)jabber.zim.net.au
This work is licensed under the Creative Commons
Recombo Plus License. To view a copy of this license, visit
http://creativecommons.org/licenses/sampling+/1.0/
-----Original Message-----
> Why did we write our own database abstraction layer when there's one already in PEAR?
PEAR DB abstraction layer handles separate API functions.
MediaWiki DB abstraction layer handles separate API functions AND separate flavours, query syntax and methods.
Maybe it would be a great idea to separate our db api and run as separate PEAR/SF/whatever project ;-) *giggle*
Domas
Hi,
After a couple of false starts, I've posted a short patch for Bug 144 (related
changes for Categories). I can also close Bug 923, which I posted (poor use
of strings in recentchangeslinked). So:
1) [[m:Development policy]] seems to say I should ask for CVS access. I don't
really want CVS access, but if it was set up for me, I'd check in patches for
144 and 923. Alternately, somebody with access could check them in. I
really want 144 closed by 1.4; I got a bunch of excited mail from people
following that bug.
2) The patch for 923 subtly changes the meaning of the string 'rclsub'. Will
translators know that the string changed? Is there a policy on allowing
changes to strings close to release?
3) [[m:Development tasks]] seems unloved. The KDE project has a "junior jobs"
concept where easy problems are prefixed with JJ: in bugzilla. I would be
interested in a similar project for Mediawiki. I don't have time to do major
things like database redesign or delta-compression, but if I could take a
couple hours each week checking off simple bugs and free up time for core
developers to work on the big issues I'd be willing to do that.
Peace,
Dan Keshet (English Wikipedia)
A bunch of compressed old entries on es.wiktionary.org are corrupted.
For example, history entries on the Portada are corrupt from June 16
through August 11 and September 24 through October 25.
A spot-check of corrupt entries shows a byte pattern very reminiscent
of a text conversion from Latin-1 to UTF-8. I need to know when this
wiki was converted, and exactly what was done; are there prior backups?
Is the conversion reversible? Might we have the same problem on other
wikis?
-- brion vibber (brion @ pobox.com)
Brion wrote
> E-mail functions are not always available on a given server (or may be
> available but non-functional), and in general open e-mail can be
> abused. Being able to disable all e-mail functions on the wiki prevents
>false presentation of unusable features, and disabling of user-to-user
> e-mail could cut down on abuse (for instance as a spam relay).
To summarise:
As written on the IRC, we have now ( Brion_and_Tom together ) the
following variables in DefaultSettings.php
(1) $wgEnableMail
(2) $wgEnableEmailUser
(3) $wgEmailnotificationForUserTalkPages
(4) $wgEmailnotificationForAllPages
(5) $wgEmailnotificationForMinorChanges
The switches 1 to 2 are general switches, the switches 3 to 5 are used
to determine the behaviour for the Email Notification for Page Changes,
this patch scheduled for publication on 30.11.2004
See http://bugzilla.wikipedia.org/show_bug.cgi?id=454 and
http://meta.wikipedia.org/Enotif
Any ideas about this message:
Fatal error: Call to a member function on a non-object in
c:\apache\htdocs\mediawiki\includes\Parser.php on line 1532
I get it right away when I try to go to the main wiki page.
Roy.
Dear friends,
I am using Mozilla Firefox and need to used Unicode characters. I have installed lots of fonts (some supporting Unicode).
Please look first at http://en.wikipedia.org/wiki/User:Gangleri/tests/Unicode_ISO_8859-1/Table_o… then edit the section and make a preview. The spaces between the characters are different in the preview and what is saved.
The page contains more anchors and sections
a.. #char458
b.. #char502
c.. #char544
d.. #char622
e.. #char675
4.1 Note on character 458
4.2 Note on character 502
4.3 Note on character 544
6.1 Note on character 622
6.2 Note on character 675
You may experience the same behaviour there. It maight be that it is a random problem of the browser. Is there a way to avoid this?
Regards Reinhardt