I have translated the latest additions of the CVS into Dutch. The new
languageNl.php is attached to this message, with the request for someone
to upload it.
Why is it that even when I translate it, it sometimes does not get on the
Dutch site? This happened recently with the semi-automatic addition of
text upon deletion. Is there something else that has to be set, and if so,\
what and where?
Andre Engels
Hi,
not wanting to sound impatient, but I still haven't received an answer
to my questions.
a) What about my patch (the one about the pentuple-apostrophe bug)? Is
it going to be committed? If not, why not? What do I need to change
to make it committable?
b) Will I ever get CVS write access or not? If not, am I supposed to
submit patches to this mailing list? Nobody else seems to do that.
Timwi
I have tried to post this to the newsgroup twice, but it never showed up
in it, so I'm attempting to send it through the mailing list. Apologies
if someone receives this several times. Does anyone know why I can't
post this to the newsgroup? (Replying to other postings in the newsgroup
appears to work fine.)
Hi,
not wanting to sound impatient, but I haven't yet received an answer to
my two questions:
a) What about my patch (the one about the pentuple-apostrophe bug)? Is
it going to be committed? If not, why not? What do I need to change
to make it committable?
b) Will I ever get CVS write access or not? If not, am I supposed to
submit patches to this mailing list? Nobody else seems to do that.
P.S. I've seen the Wiki page on development policy, but it doesn't
answer these specific questions.
Thanks,
Timwi
I thought I had posted this here yesterday, but it's not appearing in
the newsgroup for me. Has it been swallowed? Anyway, I'll post it again.
Hi,
not wanting to sound impatient, but I haven't yet received an answer to
my two questions:
a) What about my patch (the one about the pentuple-apostrophe bug)? Is
it going to be committed? If not, why not? What do I need to change
to make it committable?
b) Will I ever get CVS write access or not? If not, am I supposed to
submit patches to this mailing list? Nobody else seems to do that.
P.S. I've seen the Wiki page on development policy, but it doesn't
answer these specific questions.
Thanks,
Timwi
OK, I have some notes:
The pipe trick would work well in this case,
with [[#Y|]] being treated as [[#Y|Y]] --
because that's almost always what you want to do --
and perhaps [[X#Y|]] being treated as [[X#Y|Y]].
Currently, both of these remain unparsed.
I found it rather annoying to continually type in [[#Y|Y]].
In a preview, an internal [[#Y]] link
links to a URL with <&action=submit> and everything.
We know that some browsers interact badly
with the back and forward buttons in article previews
(neither Netscape nor IE uses these buttons correctly),
which is why we had to introduce all that page cache stuff.
This could exacerbate things, with people hopping all over a previewed page.
Instead, these links might link to the ordinary URL,
the same as a link of the form [[X]] [[X#Y]] (even on the page [[X]]) does.
(I'm less sure about this one.)
-- Toby
In CVS:
After some indirect prompting from Erik, I wrote some link table update code
which hopefully will speed up edits to pages with lots of links. Basic
features:
* fairly well enabled/disabled with $wgUseBetterLinksUpdate
* Article::showArticle() loads the link table with LinkCache::preFill(),
then calls LinkCache::clear(), which clears the cache but leaves a copy of
it hidden away. It then refills the cache with the new link table.
* LinksUpdate::doUpdate() calls LinkCache::incrementalSetup(), which works
out what needs to be added and deleted, and applies a simple formula to
decide whether the old way or the new way should be quicker.
* The new way deletes links row by row, and then adds the new ones using a
single insert. Blanking large articles would be slow, hence that would be
done the old way.
This has not been tested for speed yet. I think constructing a realistic
test would be difficult -- it's probably easier just to put it on the live
server and see what happens.
-- Tim Starling.
http://test.wikipedia.org is not responding and the email I
just sent to wikidown(a)wikipedia.org was just returned to
me.
--Karl
--- MAILER-DAEMON(a)yahoo.com wrote:
> Date: 4 Jul 2003 15:38:08 -0000
> From: MAILER-DAEMON(a)yahoo.com
> To: Karl Wick
> Subject: failure delivery
>
> Message from yahoo.com.
> Unable to deliver message to the following address(es).
>
> <wikidown(a)wikipedia.org>:
> 130.94.122.197 does not like recipient.
> Remote host said: 550 5.1.1 <wikidown(a)wikipedia.org>...
> User unknown
> Giving up on 130.94.122.197.
>
> --- Original message follows.
>
> Return-Path: Karl Wick
> Message-ID:
> <20030704153807.87929.qmail(a)web13802.mail.yahoo.com>
> Received: from [156.63.242.29] by web13802.mail.yahoo.com
> via HTTP; Fri, 04 Jul 2003 08:38:07 PDT
> Date: Fri, 4 Jul 2003 08:38:07 -0700 (PDT)
> From: Karl Wick <mrkarlofthewickfamily(a)somhiddendomain.com>
> Subject: its the test.wikipedia.org subdomain at least
> ... wont open up
> To: wikidown(a)wikipedia.org
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
>
>
>
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
Moved to wikitech-l as we've gone to the minutiae of implementation rather
than policy. :)
On Wed, 2 Jul 2003, Erik Moeller wrote:
> Tables are predictable and dependable. CSS often isn't. ;-) But it's
> probably safe to use it by now.
If we don't encourage users to use browsers that support CSS, they'll have
no incentive to not drive us fricking crazy with their stupid broken
browsers. :)
A nice named div will allow skins to be flexible with the TOC placement.
In a sidebar, perhaps, whatever...
> > <a name="Culture/Blecchistan">...
> > <a name="Language/Blecchistan">...
[snip]
> But not if the hierarchy is changed, and we would still have to retain the
> numbering feature for H2 dupes. Also, these anchor names could get very
> long, especially for H4 anchors.
Yes, all these are reasons why I don't like generating anchor names from
header text. :) Whatever you do, they remain fragile. Nice explicit
anchors would be better, though of course your fiendish table of contents
needs automatic ones anyway, so oh well. :)
> > and by default are faded
> > (so seemingly partially transparent on the solid background) until a
> > mouseover darkens them up to full visibility?
>
> Hm, can you demonstrate that?
Off the cuff, something like:
<div class="sectionedit">[<a href="blahblah">Edit</a>]</div>
.sectionedit {
float: right;
color: #ccc; /* light gray text */
font-size: 0.8em;
}
.sectionedit a:link {
color: #ccf; /* light blue link text */
}
.sectionedit a:hover {
color: #00f; /* darker, brighter blue */
}
-- brion vibber (brion @ pobox.com)
There had been some typos in the historywarning messages, I fixed.
Brion, can you put the new LanguageDE.php from CVS to Live-wiki? Thanks in
advance.
--
Smurf
smurf(a)AdamAnt.mud.de
------------------------- Anthill inside! ---------------------------
Brion Vibber wrote:
> If anything is more broken than usual ;) give out a shout.
Thanks again for the update.
But it seems that TeX support is broken:
http://de.wikipedia.org/wiki/Wikipedia:TeX
Kurt