Hi,
I have a question about the configuration of mediawiki. It seems to automatically make the first letter in a user name upper case, and I have a user who does not like this. I managed to manually change the name to lowercase in the database, but it still shows it as uppercase on the profile page, etc. Can someone tell me what it is that converts the first letter to uppercase and how I can change this?
Thanks Alli
On Wednesday 09 February 2005 08:30, Alli Lenters wrote:
I have a question about the configuration of mediawiki. It seems to
There is a congfiguration in LocalSettings.php (actuall DefaultSettings.php) which causes MW to not differentiate between uppercase and lowercase titles in wikipages.
If you change this setting then all articles and all wikipages will be case-sensitive completely.
My convention for sites I do is to make links that go off-site open a new window. Is there a simple way to do this? If not a simple way, where should I begin?
I tried hacking around in include/Skin.php but was unable to add 'target="offsite"' to any of the code that builds '<a>' tags in a way that would reliably appear in generated pages.
Specifically, I thought that adding the 'target' attribute would work inside getExternalLinkAttributes(), but refreshing a page with external links does not show the new target attribute. Likewise, putting it inside the 'if($nt->isExternal()' in makeLinkObj() didn't seem to work.
I suspect there's some caching going on that was masking what I was doing. Or is there a simpler way, perhaps in the skin CSS file?
:::: In the current US political climate, accurate bad news is punished and false good news rewarded. -- DarkSyde, aka John Springer :::: Jan Steinman http://www.Bytesmiths.com/Van
Quoting Jan Steinman, from the post of Tue, 08 Feb:
My convention for sites I do is to make links that go off-site open a new window. Is there a simple way to do this? If not a simple way, where should I begin?
AFAIR Brion is against dictating that to the users (though some very good poits were raised in favor in a past discussion on this very subject). my view is that it's not too bad to leave this decision to the user (or rather his browser). for instance I use FireFox on both Linux and Windows and I always set links to a different site to open in a new background tab, because that's the way (aha aha) I like it. I would not want to force this on my users if they don't.
Jan Steinman wrote:
My convention for sites I do is to make links that go off-site open a new window.
I think that's a bad idea, personally. ;) Users really, really hate it when you force them to open links in a new window without expecting it.
I tried hacking around in include/Skin.php but was unable to add 'target="offsite"' to any of the code that builds '<a>' tags in a way that would reliably appear in generated pages.
Make sure you're not looking at previously cached HTML. (A simple way to be _really sure_ is to do the testing in an edit preview. The preview will _always_ be rendered fresh.)
Some browsers do not re-fetch data on the 'refresh' or 'reload' command if the server returns a 304 response. You may need to push additional buttons to force this (try control or shift). Additionally, if the parser cache is enabled (the default in 1.4) you may need to flush that; use action=purge, edit the page, or clear the objectcache table (if using the default cache backend rather than selecting memcached or turck mmcache data cache functions).
Specifically, I thought that adding the 'target' attribute would work inside getExternalLinkAttributes(), but refreshing a page with external links does not show the new target attribute.
Making this change does work in my testing, so check the caching issues above.
-- brion vibber (brion @ pobox.com)
On 9 Feb 2005, at 00:49, Brion Vibber wrote:
Jan Steinman wrote:
My convention for sites I do is to make links that go off-site open a new window.
I think that's a bad idea, personally. ;) Users really, really hate it when you force them to open links in a new window without expecting it.
(Chuckle!) Hoisted by your own petard!
When you edit a page on the wikimedia site and press "Edit help" you get: TA DA! A NEW WINDOW!
Sorry, couldn't resist. I think the one thing that can be said about this is that there are exceptions to every rule.
:::: You can't have your SUV and eat it, too! :::: (It takes TEN calories of fossil-fuel energy to produce EACH calorie of food.) :::: Jan Steinman http://www.Bytesmiths.com/Van
Jan Steinman wrote:
(Chuckle!) Hoisted by your own petard!
When you edit a page on the wikimedia site and press "Edit help" you get: TA DA! A NEW WINDOW!
Yeah, and I hate it.
The reason for that particular, one sole link is that some version of Internet Explorer has a bug where if you follow a link from the edit page, then hit the back button, you lose all your work.
More sensible browsers don't consider that to be "loading" the page and will keep your edits when you hit back instead of reloading it.
-- brion vibber (brion @ pobox.com)
On Friday 11 February 2005 22:28, Brion Vibber wrote:
More sensible browsers don't consider that to be "loading" the page and will keep your edits when you hit back instead of reloading it.
I have seen that many php programs use this technique: Whenever a new page is loaded (or refreshed) and there are data in the session, they create a text field filling it with the data and saying "here's what you wrote before, copy paste if you like".
Brion Vibber brion@pobox.com wrote:
Jan Steinman wrote:
(Chuckle!) Hoisted by your own petard!
When you edit a page on the wikimedia site and press "Edit help" you get: TA DA! A NEW WINDOW!
Yeah, and I hate it.
The reason for that particular, one sole link is that some version of Internet Explorer has a bug where if you follow a link from the edit page, then hit the back button, you lose all your work.
More sensible browsers don't consider that to be "loading" the page and will keep your edits when you hit back instead of reloading it.
Opera has been doing similarly lately. It doesn't delete the contents of the text box directly, but whenever I hit the "back" button, it immediately reloads the page from the server, and thus overwriting whatever was originally on it. I've had to get into the habit of having it "stop" whenever I use "back", just to save wasted time and occasionally data (and occasionally getting there late).
I've only noticed this on MediaWiki sites, both when I'm editing and when I'm not. I thought it might be a browser problem, but I've just noticed that Wikipedia for example serves pages with the header "Cache-control: private, s-maxage=0, max-age=0, must-revalidate" -- my own wiki is serving the same, sans s-maxage --- am I right in reading that this denies the browser the right to go back to the cached page after zero seconds?
*Muke!
On Wednesday 09 February 2005 09:56, Jan Steinman wrote:
My convention for sites I do is to make links that go off-site open a new window. Is there a simple way to do this? If not a simple way,
Have you ever asked what the users think about such sites?
My convention for sites I do is to make links that go off-site open a new window. Is there a simple way to do this? If not a simple way,
Have you ever asked what the users think about such sites?
The system should give flexibility to the designer as much as the user. He probably knows more about his site's req's than you do. OTOH if the designer chooses to make an art-piece and ignore the users, he should be able to. For example this guy might be doing a bank intranet site where he needs to make really clear what is an external resource.
The implication here is that mediawiki makes it difficult for a designer to pre-determine link functionality.
/dc
-- NSK http://portal.wikinerds.org/slashdotting2005feb4 _______________________________________________ MediaWiki-l mailing list MediaWiki-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
On Wed, 2005-02-09 at 18:36 +0900, D_C wrote:
Have you ever asked what the users think about such sites?
The system should give flexibility to the designer as much as the user.
No, it shouldn't. In matters of user interface policy, the system should tie the designer's hands as much as possible, so that users have some chance of predicting, and controlling, what happens next on their computers.
He probably knows more about his site's req's than you do.
The web is filled with poor user interfaces by designers who thought they knew better than their users. Unless there is a really, really good reason to do otherwise, common user interface actions like "clicking on a hyperlink" ought to offer to me, an end-user, the usual range of choices and behaviours. That way, *I* get to decide to open it in the same window, another window, a tab, save it to a file, my scrapbook, or whatever.
Unless this choice by me fundamentally interferes with the purpose of the web site, it is arrogant presumption by the web designer to deny it to me.
if the designer chooses to make an art-piece and ignore the users, he should be able to.
What would an 'art-piece wiki' even mean? Something that encourages user input and participation while simultaneously ignoring it? Eh?
For example this guy might be doing a bank intranet site where he needs to make really clear what is an external resource.
He might be, but the question he asked suggests that it's just a personal preference being embedded into a design:
My convention for sites I do is to make links that go off-site open a new window. Is there a simple way to do this? If not a simple way,
Apparently, one designer has decided that how he likes to do things is how everyone must do them; this is poor web design, and I would be disappointed if mediawiki encouraged it.
The implication here is that mediawiki makes it difficult for a designer to pre-determine link functionality.
Mediawiki ought to make it hard to shove user interface policy changes down users' throats; this is A Good Thing, especially if it forces web designers to think more about how their decisions can frustrate and confuse their users.
Ah, didn't know I opened a can of worms here!
I'm dealing with a bunch of artists who barely know how to turn a computer on. While on the Wiki, they need "management." They get REALLY CONFUSED when they click on one word, and are still within the site, then click on the next word, and are warped off to who-knows-where. I get phone calls from people reporting problem with OTHER sites -- when I try to explain, they say, "But I clicked this thing on our site!"
The simplest solution is to draw a bright line between what is "here" and what is elsewhere. I make all my offsite links go 'target="offsite"' and there's no confusion at all.
Sophisticated users on sophisticated browsers can easily defeat that, at least with Safari (MacOS X). The status bar reads "in another window" when you point at such a link, and holding down Command forces it to open in a tab instead of a window.
The challenge is not to say, "The user is God, thou shalt not even risk annoying Him," but rather to figure out what works for your audience, and trust sophisticated users to be, well, sophisticated about it.
Thanks, Brion for the caching advice. That was it. I simply went to another computer, and it was working as expected.
:::: Our scientific power has outrun our spiritual power. We have guided missiles and misguided man. Martin Luther King Jr. :::: Jan Steinman http://www.Bytesmiths.com/Item/02CJDBGF
On Wednesday 09 February 2005 18:59, Jan Steinman wrote:
CONFUSED when they click on one word, and are still within the site,
You can just avoid linking to external sites. Why do you need external links?
People who get confused so easily need training.
On 9 Feb 2005, at 13:57, NSK wrote:
On Wednesday 09 February 2005 18:59, Jan Steinman wrote:
CONFUSED when they click on one word, and are still within the site,
You can just avoid linking to external sites. Why do you need external links?
Because they include useful information that people appreciate. Because I can't control what users (not the really unsophisticated ones, who don't edit) put on their pages. Because the wiki concept is free and open.
The problem is that SOME PEOPLE don't know how to get back to where they were.
Before you snort derisively about not knowing how to use a "back" button, think of someone you know that can barely use a VCR -- a parent or grandparent, perhaps. Shouldn't we try to make the Internet as easy as possible for them?
People who get confused so easily need training.
This is true, but often not practical. Plus, they're 500km away from me.
:::: I'm the commander - see, I don't need to explain - I do not need to explain why I say things. That's the interesting thing about being the president. Maybe somebody needs to explain to me why they say something, but I don't feel like I owe anybody an explanation. -- George W. Bush :::: Jan Steinman http://www.Bytesmiths.com
on 2005/02/9 23:11, mediawiki-l-bounces@Wikimedia.org wrote:
On 9 Feb 2005, at 13:57, NSK wrote:
On Wednesday 09 February 2005 18:59, Jan Steinman wrote:
CONFUSED when they click on one word, and are still within the site,
You can just avoid linking to external sites. Why do you need external links?
Because they include useful information that people appreciate. Because I can't control what users (not the really unsophisticated ones, who don't edit) put on their pages. Because the wiki concept is free and open.
You could put a list of these links in a section at the end of the page. Properly label the section and provide some helpful blurb. This should make it clear that they're on an exit. Encourage other writers to follow the same conventions. The wiki concept is indeed free and open, but without some conventions and self-discipline it will quickly deteriorate into a mess that will soon be left alone. <play sounds of doom here>
Before you snort derisively about not knowing how to use a "back" button, think of someone you know that can barely use a VCR -- a parent or grandparent, perhaps. Shouldn't we try to make the Internet as easy as possible for them?
Yes, we should, but a Back button is pretty standard, and many sites and browser rely on it. Once your granny learns about the back button, she will be able to re-use it everywhere (and damn those sites that break the back button). If we all start inventing our own 'go back' implementations, your granny will become even more confused --- she will not be able to re-use what she has learned before, and she will become afraid of pushing anything at all.
People who get confused so easily need training.
This is true, but often not practical. Plus, they're 500km away from me.
Are you the only one that can tell those people how to use a browser?
Cheers, Peter.
On Wed, 9 Feb 2005 14:11:18 -0800, Jan Steinman Jan@bytesmiths.com wrote:
Before you snort derisively about not knowing how to use a "back" button, think of someone you know that can barely use a VCR -- a parent or grandparent, perhaps. Shouldn't we try to make the Internet as easy as possible for them?
The assumption you are making here, which maybe you realise, but you haven't mentionned explicitly, is that closing the window to reveal another "underneath" is easier ("more intuitive" as the jargon goes) than clicking a button labelled "back" to reveal the page you've just left.
I'm not sure this is a safe assumption, as people tend to browse with their windows maximised, and novice users aren't generally very aware of the taskbar (assuming they're using Windows) as a clue to what is still open. Consequently, they may not be aware that a new window has openned, and that closing it will only take them "down" a layer, rather than being what you do when you've finished everything.
What's more, I've watched people get confused because their back button [which they *have* learnt to use] ceases to work - indeed, I do it myself - because a new window openned without them realising [a behaviour they have rightly *not* learned to rely on].
The best you can do to distinguish between internal and external links is to go really over-the-top on the [CSS] styling you apply to them. You could even, I believe, have your MediaWiki:monobook.css add the words "[External Link]" in small red letters after every single one of them. If people failed to notice that, they really would be beyond your help.
mediawiki-l@lists.wikimedia.org