Thinking about the "Standard" skin naming issue brought to mind my
least favourite piece of text in the whole MediaWiki interface:
"Recommended for modern browsers".
It's not a note attached to an option somewhere, it is the entire text
of one of the options for "Rendering math" (maybe one day I'll be able
to customize that to "maths"...).
What exactly is a "modern browser"? How "modern" is "modern"? Does
that include modern text-based browsers, such as ELinks? I doubt it!
What happens in a few years time, when "modern" browsers become able
to do far fancier tricks (and what's now "modern" will be "older")?
And who is recommending this, and why? And if you're about to answer
that question, hold on to it for a bit; if we have to give an
explanation beyond the text that appears, we might as well just call
it "use this one".
Looking at the options, some of the others aren't too great either -
and they're a right mish-mash. Currently, we have:
(0) "Always render PNG"
(1) "HTML if very simple or else PNG"
(2) "HTML if possible or else PNG"
(3) "Leave it as TeX (for text browsers)"
(4) "Recommended for modern browsers"
(5) "MathML if possible (experimental)"
This order seems somewhat bizarre, for a start, but that's alright -
we can just redefine the values the constants are defined with in
Language.php (correct me if I'm wrong). For clarity, I'll use the
numbers in brackets (their current position/value) in my proposal
below.
Basically, what we want to communicate here is: a)roughly what
behaviour the option activates; b)what circumstances/browsers/etc that
will be useful for. So why not standardise the descriptions, e.g.:
(3) "Leave it as TeX (useful for text-based browsers, screen reader software)"
(0) "Always produce a PNG image (*)"
(1) "Produce HTML if very simple, otherwise a PNG (*)"
(4) "HTML for many cases, but PNG for the most complex (*)"
(2) "HTML wherever possible, otherwise PNG (may not display well in
existing browsers|*)"
(5) "MathML wherever possible, otherwise PNG [EXPERIMENTAL]"
Now, all we need to do is what to replace those *s with - some
scenarios or example browsers for each case. Now, as I say, I don't
know what "modern browser" means, but maybe "e.g. IE >=5.0, Netscape
>=4.0, Mozilla" for option (4), and the corresponding less-thans for
option (1)? And can anyone think of a specific situation for option
(0) - just "if other options do not display well" perhaps? As for (2)
and (5), we can add example browsers in when/if they come into
existence...
(Of course, all these will then have to be translated too!)
What does anyone think?
--
Rowan Collins BSc
[IMSoP]
Somebody recently posted on the English Wikipedia's "Help Desk" with
what at first sight appeared to be a technical problem with skins:
they could not see "the most modern 'standard'" while logged in.
[ http://en.wikipedia.org/wiki/Wikipedia:Help_desk#Display_irk ]
I think, however, that they are just being confused by a rather
unhelpful choice of name - if you select "Standard" as your skin, you
get not the current default (which is called "MonoBook"), but the
previous one. It's now become a name for something that was previously
essentially nameless.
As I went on to say in my response, it's probably not a very good idea
having something called "standard" that's not standard any more -
perhaps we should try and come up with a "proper" name for it.
"Classic" would be a possibility, but not a very good one, since we
already have a "nostalgia"; "phase3" would be a bit dull (and
meaningless for most users)...
So here's my challenge to you all (developers and users alike, I hope
I don't annoy too many people by cross-posting this): come up with a
name, in retrospect, for the skin which didn't need a name until
MediaWiki 1.3, because it was just "standard".
--
Rowan Collins BSc
[IMSoP]
Hi,
I the last days there is a recurring problem in Hebrew Wikipedia. Links to existing articles are colored in red. Sometimes it could be fixed by edit the source article. I suspect that this hints that our links table is not updated with all the changes.
Ideas? Is this related to the problem with Greek Wikipedia?
Meir :->
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Some compatibility fixes for PHP 4.1.2 and 4.2.x; installer checks for
missing MySQL support; and many various things fixed. Anyone running a
public server on 1.3.0beta is strongly recommended to upgrade to this
release, as a potential JavaScript injection attack in earlier betas has
been fixed. (1.2.x is not vulnerable.)
Release notes:
https://sourceforge.net/project/shownotes.php?release_id=248913
Download:
http://prdownloads.sourceforge.net/wikipedia/mediawiki-1.3.0beta4.tar.gz?do…
Report bugs at:
https://sourceforge.net/tracker/?group_id=34373&atid=411192
Play "Stump the Developers" live on IRC:
#mediawiki on irc.freenode.net
Help mailing list:
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
(CVS note: this is tagged as REL1_3_0beta4a. We tagged a REL1_3_0beta4
last week but didn't release quite it.)
Changes from beta3 include but are not limited to:
* Install checks for missing PHP MySQL support
* Fixed broken PHP 4.1.2 compatibility functions
* PHP 4.2 vs MonoBook skin title encoding
* Offsets
* Mysterious install fixes
* Fix for with html-tidy
* (optional) experimental load balancer
* Fixes for some broken queries from last beta
* Improved error reporting in command line scripts and elsewhere
* Account creation per IP throttle (requires memcached)
* Copyright info on uploads (optional)
* Hook for custom spam check filter function
* Improved HTML escaping of user names in some places
* Removed < and > from legal title chars (shouldn't have been added)
* Recentchanges reports move-over-redirect more clearly
* Search index updates no longer use REPLACE DELAYED, as it causes more
problems than it solves
* Copyright notice was missing on old revisions, fixed
* More bad title checks in skin
* Unused skins no longer loaded (reduces memory usage)
* "newbies" mode on Special:Contributions
* Bureaucrat flag put back into Special:Makesysop
* Special:Undelete fix for titles with apostrophes
* Upload warning on existing filename
* $wgWhitelistRead fix
* Titles with "./" are allowed again as long as it's not at the
beginning or following a "/"
* Language file upades for Hungarian, Japanese, Korean, Portuguese
* Spelling corrections in languge names
* rebuildtextindex.php updated
* SQL fix to blobs table
* TeX suppress dvips output from logs
* Style fixes
- -- brion vibber (brion @ pobox.com)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFA3hSCwRnhpk1wk44RAozfAKC+DUHqNn6fHib/z4x5KERA/iU0+gCghKs5
MH0NL5ooqwYMbd6pw8C6/JA=
=peLW
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
I just noticed something strange on fr.wiktionary.org.
[[Catégorie:Langue française]] has 13 subcategories, including
[[Catégorie:Pronom français]] and [[Catégorie:Prépositions françaises]].
~ "Prépositions" was listed after "Pronom", which is incorrect. So I
edited [[Catégorie:Prépositions françaises]] and added
"[[Catégorie:Langue française|Prepositions francaises]]" to fix this
error. But now, there are 2 "P" sections in [[Catégorie:Langue française]]:
~ P * Pronoms français
~ V * Verbes français
~ P * Prépositions françaises
Is this a bug or did I do something wrong ?
Thanks !
MagicTom
[[w:fr:Utilisateur:MagicTom]]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFA2Yqe8qG/0bshvCcRAvm/AJ4gf8fVE31hOgVUDsd/SdM4OACOGwCZAWVg
T94UEnNdEmipnALcGqt2SJs=
=wsTm
-----END PGP SIGNATURE-----
We had some problems enabling search because inserts into a table with a
full-text index is quite slow. Switching PACK_KEYS off seemed to help a
bit, although that may have been illusory. Despite having PACK_KEYS off,
during last peak period the edit rate on the wiki again exceeded the
maximum insert rate on suda, just as it had done in the previous two
days. This causes editing on the wiki in question to apparently cease, a
runaway increase in open mysql connections, and eventually complete loss
of service if search updates are not switched off.
A more efficient alternative was obviously necessary, so I wrote a
script to perform the day's search updates during the off-peak periods.
It scans the recentchanges table for pages to update, starting from a
timestamp saved to disk by the previous run. It obtains a write lock on
searchindex and a read lock on cur, and then updates the table for some
specified period of time (currently 20 seconds). It then releases its
locks and allows any queued edits from the wiki to complete, before
locking again and continuing.
Locking tables like this improves the performance of bulk inserts,
according to the MySQL manual. The read lock on cur is required because
an unlocked table cannot be accessed while another table is locked.
The script is in CVS at maintenance/updateSearchIndex.php, and should
work on non-Wikimedia installations without modification.
-- Tim Starling
Wikipedia has a decisive Plone (www.plone.org) feel to it. Yet,
I cannot find Plone anywhere on the about pages. Is it
a coincidence, or did Wikipedia base some of its logics and or
design on Plone?
Thanks,
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: krafft.bogus(a)ailab.ch madduck.bogus(a)madduck.net
opment of a culture.
Names.php currently specifies "zh-cfr" for the Minnan pedia even though
the subdomain is "minnan". Can this be fixed so people will be spared
the need to guess when linking over to Minnan? Thanks.
Is there a ceiling on the size to which an image may be upscaled?
One wrinkle a vandal figured out today was altering the image markup on
[[en:User:Hephaestos]] to produce a massive image. Done prolifically, I
figure there's some potential both to DOS the server that does the
scaling, and to similarly slow visitors' browsers.
I can't see much reason to allow scaling of images to beyond a few
thousand pixels.
FIn
--
----------------------------------------------------------------------
W.Finlay McWalter [[User:Finlay McWalter]] http://www.mcwalter.org
"With the thoughts you'd be thinkin', You could be another Lincoln..."
I see that when I categorise a page "Foo" with, say [[Category:Test]] it
will create a category page Categories:Test with an entry T Test.
If I do it like [[Category:Test|Bar]] I'll get an entry like B Test.
That's irritating.
Couldn't it be done that it shows the modified search. Like B Bar.
That example might not be a very good one but it is more clear when we use
Albert_Einstein like on meta.
A page Albert_Einstein gets categorised as
[[Category:Albert_Einstein|Einstein, Albert]] and shows up as E
Albert_Einstein where it shoud be E Einstein, Albert.
That's weird.
Cheers
Manfred