I've gotten three separate complaints, automated, but which may cause
us some trouble. Apparently our proxy blocker is doing something
which some sites perceive to be an attempt to probe for security
problems (which, of course, is true).
I think we should be doing this, but until I confirm with our colo
that we won't be getting grief for this, I think we should stop.
This is not an emergency, but is something that should be done soon.
Possibly there is a way we can limit the use of the anon proxy probe
to cases that are highly suspicious or something?
--Jimbo
Hello all.
I'm putting the finishing touches on a script that exports the
wikipedia in a format that can be directly imported to Yahoo!'s (and
other's) search engine. It's nothing pretty (in fact, it's my first
PHP), but I'd be grateful if 2 things would happen:
* Someone would look at it (I attached it) and say "this sucks
because..."
* Someone would give me cvs write access, so I could add the file to
the repository.
Eventually, this should be on a cron, updating periodically so that
the search engines which use these results stay up-to-date. I saved a
copy of the spec here:
http://www.bomis.com/idif/spec.pdf
I didn't come up with any good way of getting keywords for a given
page. Using the linked page titles was a suggestion. Other ideas?
Thanks.
--
"Jason C. Richey" <jasonr(a)bomis.com>
Shaihulud's been running the Mersenne Twister calculation as a CPU
stress test on geoffrin. Related or not, things seem to have gone
south; it comes up with "I/O error" in response to most commands, I
can't even tell it to shutdown or reboot.
Log fragment:
Apr 4 19:05:02 geoffrin kernel: EXT3-fs error (device sd(8,7)) in
ext3_reserve_inode_write: IO failure
Apr 4 19:05:02 geoffrin kernel: SCSI disk error : host 0 channel 0 id
0 lun 0 return code = 25040001
Apr 4 19:05:02 geoffrin kernel: I/O error: dev 08:07, sector 0
Apr 4 19:05:02 geoffrin kernel: SCSI disk error : host 0 channel 0 id
0 lun 0 return code = 25040001
Apr 4 19:05:02 geoffrin kernel: I/O error: dev 08:07, sector 60715128
Apr 4 19:05:02 geoffrin kernel: SCSI disk error : host 0 channel 0 id
0 lun 0 return code = 25040001
Apr 4 19:05:02 geoffrin kernel: I/O error: dev 08:07, sector 60715008
-- brion vibber (brion @ pobox.com)
In response to reports of people posting misleading links to
Special:Blockme, or otherwise tricking users' browsers into requesting
the relevant URL, I've implemented a basic keyed hash authentication
algorithm.
Still to do: initialising the key from a higher quality random number
source in the installer program. Currently it just draws 124 bits from a
Mersenne Twister, which is probably seeded from the system time. In the
short term, users may wish to replace $wgProxyKey with their own random
string. Wikipedia is using a 160 bit key drawn from /dev/random.
-- Tim Starling
Any objection to removing SkinSmarty.php and the templates therefore?
That's my half-finished experimental implementations of Tarquin's
Montparnasse and Paddington layouts.
I've never had the chance to get them cleanly working, meanwhile
Gwicke's PHPTal-based skins are at a much more advanced state... it
seems kind of silly to maintain two parallel template systems. If
someone would like to rebuild Paddington and Montparnasse for PHPTal,
that would be great, but at present they don't really work and I don't
think it's worth the effort to clean up the Smarty code.
-- brion vibber (brion @ pobox.com)
Hi there,
although Timwi and some other people already requested to code the
deletion for single revisions and I posted a modification some weeks ago
nothing happend yet. Unfortunately the last weeks brought some major
code changes, as far as I noticed.
However I attached my proposal for the deletion of single revisions as
diffs against the current cvs. I have no idea if it still works, but I
think it should.
The deletion of the complete article when a copyright violation occured
is not feasable and I hope that my few lines of code help a little bit.
Regards
Thomas aka Urbanus
On Apr 4, 2004, at 14:58, Evan Prodromou wrote:
> If these features are turned on (with global flags), a metadata link
> tag is
> provided to the appropriate action ('dublincore' or
> 'creativecommons'). When
> the wiki script receives these actions, it creates RDF files on the
> fly.
Neat! Don't forget to check in Metadata.php...
-- brion vibber (brion @ pobox.com)
On Apr 3, 2004, at 17:45, Gabriel Wicke wrote:
> * invalid anchor names- attention! this might break links! Replacing
> [^a-z0-9] -> '_' now
That's going to be pretty bad for languages that don't write in Latin
script, isn't it?
-- brion vibber (brion @ pobox.com)
I'm replying as requested to wikitech-l, but I haven't received the original
message through this list yet, so you might need to resend it.
--- David Friedland <david(a)nohat.net> wrote:
> My recommended solution is:
> * Implement some kind of wiki markup for indicating IPA text in the wiki
> source, ideally as part of the WikiTeX system.
> * Mark up all IPA symbols on Wikipedia using the markup!
> * Logged-in users can set their preference to Unicode IPA, WikiTeX TIPA
> images, and/or (X-)SAMPA.
> * This system would put <span style="font-family:..."> tags around
> Unicode IPA in the HTML output so Windows IE users who have set their
> preference to Unicode will be able to see the symbols regardless of
> their browser's font setting.
This sounds like a nice solution (as long as their are user preferences as you
suggest).
> * What do do for anonymous users: should we do a browser detect and
> serve a page with unicode IPA or WikiTeX-ed image of the IPA, depending
> on the browser, or just send WikiTeX images to all anonymous users? It
> is hard to guarantee via a browser detect that the user has the proper
> unicode fonts, although certainly for all Safari users, the Unicode will
> render correctly, because Mac OS X has fonts with unicode characters
> installed by default. We need to do a browser/platform survey to
> determine what combinations are likely to support Unicode IPA.
Well, the simplest would be to deliver X-SAMPA by default as this would require
no guessing/scanning on our parts.
> * Inline TeX renderings won't be in the same font and may not be
> properly aligned with the surrounding text, and so may not be attractive.
This is particularly relevant to wikipedia (rather than, say, wiktionary) as
most pronunciation guides will appear not only inline, but in the very first
sentence. That's not the place we want to be messing up the formatting/line
height. Also, TeX outputs as a png, right? We should consider those who surf
with images switched off. Since linguists have gone to the bother of
translating the IPA into ascii X-SAMPA, we should consider this as a default
for anons as it has maximum cross-browser compatability.
I'm comfortable with using the IPA, but many people do find all the symbols
off-putting. In fact, very few dictionaries use it, presumably for that
reason. Perhaps SAMPA is a bit friendlier?
If we're going to be encouraging the use of pronunciation guides, perhaps it
would be best to create seperate guides to the IPA, SAMPA etc, which are
designed to be linked from articles and help the reader decode the guide as
quickly as possible. We might also need to do the same for editors, to help
them write in SAMPA/the IPA in order to produce these guides in the first
place. And I've been wondering if the string of symbols itself should be the
link: (/[[SAMPA chart for English|"hE.l@U w3:ld]]/) for the sake of tidiness?
Fabi.
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
Things aren't 100% clean yet, but some tweaks are starting to go in to
make output pass as XHTML.
If you'd like to test it, set these in your LocalSettings.php:
$wgMimeType = "text/xml";
$wgDocType = "-//W3C//DTD XHTML 1.0 Transitional//EN";
$wgDTD = "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";
Mozilla will let you know immediately when it finds output that's not
well-formed XML by freaking out and refusing to show the page. :)
UI markup cleanup is tedious but easy. The parser still may need some
tweaking here and there, and particularly clean-up for user-written
HTML in wiki pages is an area that needs to be carefully checked.
Someday it might be neat to conform to XHTML 1.0 Strict, but that's a
freakier land where things like 'width' and 'height' attributes are
forbidden.
-- brion vibber (brion @ pobox.com)