-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
MediaWiki 1.4beta4 is an experimental release, to help flush out remaining major problems in the code prior to a final public 1.4.0 release. It is not recommended to use this beta on a public site unless you're familiar with MediaWiki innards and are willing and able to help diagnose and fix problems that come up.
Users of the earlier beta releases should upgrade to keep up with bug fixes. Anyone running a version _earlier_ than beta 3 should upgrade immediately if uploads are enabled due to potential security vulnerabilities on some Apache configurations.
=== Beta 4 fixes ===
* (bug 1090) Fix sitesupport links in CB/classic skins * Gracefully ignore non-legal titles in a <gallery> * Fix message page caching behavior when $wgCapitalLinks is turned off after installation and the wiki is subsequently upgraded * Database error messages include the database server name/address * Paging support for large categories * Fix image page scaling when thumbnail generation is disabled * Select the content language in prefs when bogus interface language is set * Fix interwiki links in edit comments * Fix crash on banned user visit * Avoid PHP warning messages when thumbnail not generated * (bug 1157) List unblocks correctly in Special:Log * Fix fatal errors in LanguageLi.php * Undo overly bright, difficult to read colors in Cologne Blue * (bug 1162) fix five-tilde date inserter * Add raw signatures option for those who simply must have cute sigs * (bug 1164) Let wikitext be used in Loginprompt and Loginend messages * Add the dreaded <span> to the HTML whitelist * (bug 1170) Fix Russian linktrail * (bug 1168) Missing text on the bureaucrat log * (bug 1180) Fix Makesysop on shared-user-table sites * (bug 1178) Fix previous diff link when using 'oldid=0' * (bug 1173) Stop blocked accounts from reverting/deleting images * Keep generated stylesheets cache-separated for each user * (bug 1175) Fix "preview on first edit" mode * Fix revert bug caused by bug 1175 fix * Fix CSS classes on minor, new, unpatrolled markers in enhanced RC * Set MySQL 4 boolean search back to 'and' mode by default * (bug 1193) Fix move-only page protection mode * Fix zhtable Makefile to include the traditional manual table * Add memcache timeout for the zh conversion tables * Allow user customization of the zh conversion tables through Mediawiki:zhconversiontable * Add zh-min-man (back) to language names list * Ported $wgCopyrightIcon setting from REL1_3A * (bug 1218) Show the original image on image pages if the thumbnail would be bigger than the original image * (bug 1213) i18n of Special:Log labels * (bug 1013) Fix jbo, minnan in language names list * Added magic word MAG_NOTITLECONVERT to indicate that the title of the page do not need to be converted. Useful in zh: * (bug 1224) Use proper date messages for date reformatter * (bug 1241) Don't show 'cont.' for first entry of the category list * (bug 1240) Special:Preferences was broken in Slovenian locale when $wgUseDynamicDates is enabled * Added magic word MAG_NOCONTENTCONVERT to supress the conversion of the content of an article. Useful in zh: * write-lock for updating the zh conversion tables in memcache * recursively parse subpages of MediaWiki:Zhconversiontable * (bug 1144) Fix export for fy language * make removal of an entry from zhconversiontable work * (bug 752) Don't insert newline in link title for url with %0a * Fix missing search box contents in MonoBook skin * Add option to forward search directly to an external URL (eg google) * Correctly highlight the fallback language variant when the selected variant is disabled. Used in zh: only for now.
Release notes: http://sourceforge.net/project/shownotes.php?release_id=295298
Download: http://prdownloads.sf.net/wikipedia/mediawiki-1.4beta4.tar.gz?download
Wiki admin help mailing list: http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
Low-traffic release announcements mailing list: http://mail.wikipedia.org/mailman/listinfo/mediawiki-announce
Bug report system: http://bugzilla.wikipedia.org/
Play "stump the developers" live on IRC: #mediawiki on irc.freenode.net
- -- brion vibber (brion @ pobox.com)
Is there a syntax for external links, that will cause them to open in a new browser window?
James
On Saturday 08 January 2005 06:27, =James Birkholz= wrote:
Is there a syntax for external links, that will cause them to open in a new browser window?
do not do that, it is bad design.
On Sat, Jan 08, 2005 at 04:07:03PM +0200, NSK wrote: # On Saturday 08 January 2005 06:27, =James Birkholz= wrote: # > Is there a syntax for external links, that will cause them to open in a new # > browser window? # # do not do that, it is bad design.
Amen to that! Let your users decide if they want new windows.
I agree generally, that it can be a nuisance when webplaces open pages in new windows. But then everything can be abused.
If you want to build a community, it is valuable to be able to differentiate between what is going on, on the inside of the site, inside the community and what is external from the site. Targeting external links to new windows helps create that feeling, overriding user settings.
I want my portal to be friendly also to users, who may not be so familiar with the internet, and the more so with the wiki concept. Yet I still want to use interwikilinks and such for key concepts that are best explained elsewhere. I therefore want my users to familiarize themselves with my site as a safe, local place, and keep them there, being sent into the abyss of wikimania in wikipedia, without losing track of crewscut.com.
Is there anyone who has made a hack or extension for the purpose of targeting interwikilinks and external links to new windows?
Morten :-)
Sam Rowe wrote:
On Sat, Jan 08, 2005 at 04:07:03PM +0200, NSK wrote: # On Saturday 08 January 2005 06:27, =James Birkholz= wrote: # > Is there a syntax for external links, that will cause them to open in a new # > browser window? # # do not do that, it is bad design.
Amen to that! Let your users decide if they want new windows. _______________________________________________ MediaWiki-l mailing list MediaWiki-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
-- Crews Cut Community http://www.crewscut.com
Morten Blaabjerg Dronningensgade 4B, DK-5000 Odense C. Tlf. +45 65 90 60 88
On Sun, Jan 09, 2005 at 01:17:47PM +0100, Morten Blaabjerg wrote: # I agree generally, that it can be a nuisance when webplaces open pages in new # windows. But then everything can be abused. # # If you want to build a community, it is valuable to be able to differentiate # between what is going on, on the inside of the site, inside the community and what # is external from the site. Targeting external links to new windows helps create # that feeling, overriding user settings.
I realize that this thread is quickly leaving the topicality of the list, so I'll be brief.
This is a common argument used by people who like to target new windows. From my perspective, it seems like an argument that could only be made by someone with total disdain for their users. If your users can't tell the difference between your site and a site you link to, A) they're not going to notice that they're now in a new window and B) even if they did notice the new window, they won't understand *why* they're in a new window.
Let your users manage their windows.
-Sam
I'm in agreement with Morten here. General ideals are fine and I like to control my windows as much as the next guy, but since my site and WikiPedia use the same software and most users will likely be using the default skins, if I have a link to a WikiPedia article (which is likely an article that isn't the subject that would bring users to my site), I don't want to confuse them. They should know that they've transferred and diverged to a different Wiki, and it should be made easy for them to return to their original thread of research without having to "back" xx times. (My audience is heavily weighted towards permanently novice users ie. "elderly"). The only way I know to do this is to use the new window option. It's a courtesy that I appreciate in similar situations on other sites.
Since no one has yet answered my specific question ("How do you...?") but have only had some say "You shouldn't...", then I guess the answer is "You can't". Given that assumption, then my next thought is to wait until I have time to learn how to make skins and replace all the skins and reset the default config so that the window appearance is radically different from WikiPedia's. Another thought would be to pop up a "You've left MySite.com" window, but that gets too annoying for frequent use.
I was just hoping there was a simple syntax option in place.
James
At 01:17 PM 1/9/05, you wrote:
I agree generally, that it can be a nuisance when webplaces open pages in new windows. But then everything can be abused.
If you want to build a community, it is valuable to be able to differentiate between what is going on, on the inside of the site, inside the community and what is external from the site. Targeting external links to new windows helps create that feeling, overriding user settings.
I want my portal to be friendly also to users, who may not be so familiar with the internet, and the more so with the wiki concept. Yet I still want to use interwikilinks and such for key concepts that are best explained elsewhere. I therefore want my users to familiarize themselves with my site as a safe, local place, and keep them there, being sent into the abyss of wikimania in wikipedia, without losing track of crewscut.com.
Is there anyone who has made a hack or extension for the purpose of targeting interwikilinks and external links to new windows?
Morten :-)
Sam Rowe wrote:
On Sat, Jan 08, 2005 at 04:07:03PM +0200, NSK wrote: # On Saturday 08 January 2005 06:27, =James Birkholz= wrote: # > Is there a syntax for external links, that will cause them to open
in a new
# > browser window? # # do not do that, it is bad design.
Amen to that! Let your users decide if they want new windows. _______________________________________________ MediaWiki-l mailing list MediaWiki-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
-- Crews Cut Community http://www.crewscut.com
Morten Blaabjerg Dronningensgade 4B, DK-5000 Odense C. Tlf. +45 65 90 60 88
MediaWiki-l mailing list MediaWiki-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
James Birkholz admin, Posen-L mailing list and website http://www.Posen-L.com
On Sunday 09 January 2005 18:47, =James Birkholz= wrote:
I was just hoping there was a simple syntax option in place.
It is possible to enable raw html or php in mediawiki. this way you can have new windows.
What are the best (and lowest cost) options for spell checking when editing wiki?
Obviously I can copy and paste into either (in my personal situation) my e-mail or word processor (Eudora and Word97). Was wondering if anyone had better ideas?
Also, is there a way to keyword search the archives for this mailing list? I only find browsing functions at http://mail.wikipedia.org/pipermail/mediawiki-l/ where I hope to spend some time catchin up soon, since the volume isn't too huge.
James Birkholz admin, Posen-L mailing list and website http://www.Posen-L.com
On Sunday 09 January 2005 19:21, =James Birkholz= wrote:
What are the best (and lowest cost) options for spell checking when editing wiki?
Use the Konqueror web browser available at http://www.konqueror.org
It spell checks all text boxes in any web page. It's awesome.
On Jan 9, 2005, at 9:21 AM, =James Birkholz= wrote:
What are the best (and lowest cost) options for spell checking when editing wiki?
Browsers with built-in spell checking are handy. Apple's Safari, for instance.
Also, is there a way to keyword search the archives for this mailing list?
Google; include site:mail.wikipedia.org in your query.
-- brion vibber (brion @ pobox.com)
Browsers with built-in spell checking are handy. Apple's Safari, for instance.
Firefox also have such a plugin, installed by default on the Lindows Linux distribution.v
Well, it might be a bad design, but I really need a link to a special keybord to be opened in new window when editing the Wikipedia article. The link is so far incorporated in the text of the Copyrightwarning message, so html targeting is simply not working.
Plamen
----- Original Message ----- From: "NSK" nsk2@wikinerds.org To: "MediaWiki announcements and site admin list" mediawiki-l@Wikimedia.org Sent: Saturday, January 08, 2005 4:07 PM Subject: Re: [Mediawiki-l] External links in new window?
On Saturday 08 January 2005 06:27, =James Birkholz= wrote:
Is there a syntax for external links, that will cause them to open in a
new
browser window?
do not do that, it is bad design.
-- NSK The Wikinerds Community Federation of Science Wikis Owner of the Wikinerds Portal http://portal.wikinerds.org Owner of the NerdyPC IT Wiki http://www.nerdypc.org _______________________________________________ MediaWiki-l mailing list MediaWiki-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
On Saturday 08 January 2005 17:09, Plamen Gradinarov wrote:
html targeting is simply not working.
html targetting is not included in recent W3C XHTML recommendations, use ECMAscript instead.
mediawiki-l@lists.wikimedia.org