An automated run of parserTests.php showed the following failures:
Running test Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)... FAILED!
Running test Magic Word: {{NUMBEROFFILES}}... FAILED!
Running test BUG 1887, part 2: A <math> with a thumbnail- math enabled... FAILED!
Running test Language converter: output gets cut off unexpectedly (bug 5757)... FAILED!
Running test HTML bullet list, unclosed tags (bug 5497)... FAILED!
Running test HTML ordered list, closed tags (bug 5497)... FAILED!
Running test HTML ordered list, unclosed tags (bug 5497)... FAILED!
Running test HTML nested bullet list, open tags (bug 5497)... FAILED!
Running test HTML nested ordered list, closed tags (bug 5497)... FAILED!
Running test HTML nested ordered list, open tags (bug 5497)... FAILED!
Passed 304 of 314 tests (96.82%) FAILED!
On Mon, May 15, 2006 at 06:27:18PM +0200, Steve Bennett wrote:
> Heh, ok, so people who are looking to follow the link to another
> article click and get the wrong behaviour. People actually looking for
> the image info don't think of clicking. Everyone loses!
>
> Would it be possible, on each and every page, to have a "Image
> credits" link which would provide links to the attribution page of
> every image used on that page, no matter how it was used? Then
> professionals would know to always click on that same "Image credits"
> link placed in the bottom corner, for example.
I've been following this thread with some interest, both as a
photographer (who has actually contributed original work to WP) and as
a usability guy, who understands that icons should behave the way icons
*behave*...
and I like Steve's suggestion here a *lot*; I think it's probably the
best balance between people getting credit for their work, and websites
working as websites are -- these days -- expected to work.
I've unthreaded this, so this proposal doesn't get lost in the noise.
Comments, all?
Cheers,
-- jra
--
Jay R. Ashworth jra(a)baylink.com
Designer Baylink RFC 2100
Ashworth & Associates The Things I Think '87 e24
St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on Usenet and in e-mail?
I've noticed some vandalism on cswiki proxied through
tor (http://tor.eff.org/) routers. Any ideas how to
deal with it some other way than blocking addresses
one-by-one?
Thanks,
Jan Kulveit [[User:Wikimol]]
The issue has been mentioned at http://mail.wikipedia.org/pipermail/wikitech-
l/2006-March/034397.html in wikitecl-l, and also in BugZilla:5790
http://bugzilla.wikimedia.org/show_bug.cgi?id=5790.
Hi all,
As I've mention that pages above, some Wiki sites has the incorrect lang tags
which neither assiciated with ISO-693 nor IANA language tags. So I've examined
this issue, and have a patch sibmitted to BugZilla. However the patch I've
made cannot be accepted as Brian said that this would break up the caching
system.
Is there any workaround/suggestions how to resolve this issue without breaks
the current caching system? (As my limited knowledge in PHP5 classes, so I
need some help who is familar with PHP5 classes).
This patch would solve the issues that the lang tag cannot associated to any
of valid language tags, such as there's no "simple" tag which assiciated
neither ISO-693 nor IANA language tags. And also the patch fixes the incorrect
language tag which depends on the user interface language. There's some sample
patch explaining how the language tag to be determined, such as a Traditional
Chinese user which supposes to using Traditional Chinese fonts (zh-hant/zh-TW)
to see the contexts, rather than using Simplified Chinese fonts (zh/zh-hans/zh-
CN).
regards, :)
Shinjiman
--
http://meta.wikimedia.org/User:Shinjimanhttp://en.wikipedia.org/User:Shinjiman
JanRain, Inc. is pleased to announce the release of a patch to include OpenID
support in MediaWiki 1.5.8. This patch incorporates support using the PHP
OpenID library, release 1.1.0 or later. The PHP OpenID 1.1.0 library supports
the Simple Registration OpenID extension. Users can use Simple Registration
data to update their MediaWiki accounts.
Patches for 1.5.8 using PHP OpenID 1.0 and 1.1.0:
http://www.openidenabled.com/software/mediawiki/mediawiki-openid-patch
Simple Registration:
http://www.openidenabled.com/openid/simple-registration-extension/
Enjoy!
--
Jonathan Daugherty
JanRain, Inc.
I've spent a bit of time trying to figure out how to replace the flawed
"{{fullurl:" with a ParserFunction "{{#fullurl:" that would correctly
encode its parameters, while keeping in mind a more formal wikimarkup
language definition implemented by recursive descent.
In trying to understand the abtruse calling sequence for the
ParserFunctions, one of the definitional difficulties is that the
parameters are expanded (using call_user_func_array). The currently
defined ParserFunctions all have fixed positional parameters.
Unfortunately, fullurl/localurl/whateverurl should have a variable number
of parameters. Future functions might also have a variable number of
parameters, or possibly named parameters with defaults.
The current handling doesn't seem very amenable to formal language
definition or future mixing of a compiled parser with calls to external
PHP functions.
Is my reading of the code correct?
Is is possible to redefine ParserFunctions to pass variable parameters
and let each function process them?
An automated run of parserTests.php showed the following failures:
Running test Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)... FAILED!
Running test Magic Word: {{NUMBEROFFILES}}... FAILED!
Running test BUG 1887, part 2: A <math> with a thumbnail- math enabled... FAILED!
Running test Language converter: output gets cut off unexpectedly (bug 5757)... FAILED!
Running test HTML bullet list, unclosed tags (bug 5497)... FAILED!
Running test HTML ordered list, closed tags (bug 5497)... FAILED!
Running test HTML ordered list, unclosed tags (bug 5497)... FAILED!
Running test HTML nested bullet list, open tags (bug 5497)... FAILED!
Running test HTML nested ordered list, closed tags (bug 5497)... FAILED!
Running test HTML nested ordered list, open tags (bug 5497)... FAILED!
Passed 304 of 314 tests (96.82%) FAILED!
Hi,
This has probably been requested, but would it be possible to allow
images to link to things other than the image file itself. Such a link
is, helpful in featured pictures candidates, or when the image is
being used as a thumbnail illustration in an article, but not helpful
when the image is being used to illustrate a subtopic.
Not sure how best to adapt the syntax, but maybe allowing something like this:
[[Australia|[[Image:Australian flag.svg]]]]
This would leave open the possibility of having an image be part of a
string that is linked.
Steve
An automated run of parserTests.php showed the following failures:
Running test Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)... FAILED!
Running test Magic Word: {{NUMBEROFFILES}}... FAILED!
Running test BUG 1887, part 2: A <math> with a thumbnail- math enabled... FAILED!
Running test Language converter: output gets cut off unexpectedly (bug 5757)... FAILED!
Running test HTML bullet list, unclosed tags (bug 5497)... FAILED!
Running test HTML ordered list, closed tags (bug 5497)... FAILED!
Running test HTML ordered list, unclosed tags (bug 5497)... FAILED!
Running test HTML nested bullet list, open tags (bug 5497)... FAILED!
Running test HTML nested ordered list, closed tags (bug 5497)... FAILED!
Running test HTML nested ordered list, open tags (bug 5497)... FAILED!
Passed 304 of 314 tests (96.82%) FAILED!
Hi all,
I brought this up a little while ago, but have thought some more.
Here's what I'd really like:
* To see a list of articles that have changed since the last time I
"okayed" them.
* To be able to "okay" changes to an article, by marking it on this
list. Such an "okay" would not necessarily be visible to anyone but
me.
* For any change made to an article to by default be considered "okay" for me.
* To show this list sorted by the last time I modified it, most recent first.
BONUS: show a grouped summary of all changes (diffs) made to the
article since the last time we touched it, possibly with grouped edit
summaries
Does this interest anyone else?
Rationale:
I think a lot of people implicitly work on this kind of basis. This is
why we have watchlists after all - we are interested in an article we
have worked on, and want to check changes made to that article, to be
sure they don't compromise it. However, we end up checking and
rechecking the same articles in our watchlists, while missing articles
that have scrolled past. Such a tool would formalise the basic
workflow: Check changes made to our favourite articles, and sign them
off as 'ok' once we've checked them.
Steve