Magnus Manske wrote: Keeping titles and link names the same is a key part of the wiki system. As noted years ago on the bug report, I'd recommend only allowing swapping the case of the first letter with such a method. -- brion vibber (brion @ pobox.com)

On 4/11/06, Magnus Manske <magnus.manske(a)web.de> wrote: I love the idea. I agree that notes like "The correct title of this article is eBay. It's shown incorrectly due to technical restrictions" are, um, suboptimal". What kind of restrictions could you put in to ensure that oldlimitations(HTML-encoded title) = actual title? In other words, you don't want to allow someone to make "PKb" display as "Jerry's huge cock", or even worse, "Abortion" or something. Actually, a more likely problem is people using it as a loophole around page-move-protection ("what? you won't let me move it? I'll just rename it!") That problem is probably not too hard, right? Rip out all formatting and punctuation, and case-insensitive compare against actual title? Although it occurs to me that you don't really want to allow HTML coded titles (colors, images, blinking, underlines...), either. You really only want treat the major specific technical limitations: * punctuation * lower case first letter * superscript/subscript Otherwise there will be a whole new grey area of what should and shouldn't be kept in the page title. Should Google appear in different colours? Can a company title have certain letters in bold? Are different font sizes acceptable? So it might be better to define a special markup (possibly resembling real HTML markup), and simply ignore the entire template tag if it fails any requirement. Just brainstorming... Steve

Steve Bennett schrieb: We agreed on standards for articles in these matters. We can do that for the relatively low number of article titles this would affect. I'd just use our usual WikiMarkup plus HTML and have it limited through the manual of style. Inventing a whole new markup (and the appropriate new parser) for a few titles which people will have to learn in addition to the existing one doesn't seem prudent, somehow :-) Your list (punctuation, case, sub/sup) seems good, although I'd allow italics as well (I don't have an example, though). With only the manual of style limiting markup, we can expand it where necessary. Magnus

Steve Bennett schrieb: I have commited an initial attempt at {{DISPLAYTITLE|Anything goes}}, turned off by default in case of unforseen side effects ($wgAllowDisplayTitle=true turns it on). We can still restrict this, but at least the infrastructure is there now. How about {{LIMITTOC|3}} ? Magnus

On 4/11/06, Magnus Manske <magnus.manske(a)web.de> wrote: Something like this, IMO, seems better done as a per-user preference. /me can already imagine edit wars over how many subheadings to display in the TOC =) -L

On 4/11/06, Locke Cole <locke.cole.wiki(a)gmail.com> wrote: Hmm, I disagree. There are articles where the 4th level of subheadings are actual paragraphs which could decently show up in the table of contents. Other times they're barely stubs, single lines. Perhaps those subheadings could be rewritten in another format. In either case, a user setting wouldn't be able to distinguish the two sorts of articles. And honestly, we have to stop worrying about whether edit wars will break out every time we propose a new feature :) PS Magnus, {{LIMITTOC|3}} would be fine - for a minute there I thought you were telling me about an existing feature and I got all excited :) Steve

I just wrote up a simple JavaScript code for the Polish (update, after 30 minutes of writing this email) and English Wikipedia. It changes the title (h1.firstHeading) to the name of the page which is the {{Restrictions}} (or similiar) template. Just check my JavaScript: http://en.wikipedia.org/wiki/User:Datrio/monobook.js And here's an example (after moving the JS to your own monobook.js): http://en.wikipedia.org/wiki/ITunes_Music_Store If anyone wants to copy it, feel free to do it. -- Pozdrawiam, Dariusz Siedlecki

Magnus Manske wrote: It's in LanguageConverter.php. It works without the language code already. Hopefully not, that would be unsafe. The language converter has its own syntax, because there was a need for compact representation of characters in different scripts, the simplest of which is literal escaping, e.g. "沒想到8天-{後}-". I don't think changing it would be the right way to go, rather we could add a more verbose synonym to support this quite different application. That is to say, assuming we support it at all. Like Brion, I'd rather maintain the ability to create links by copying and pasting from the H1 element. The only alternative appears to be to copy the URL and fix the underscores, which is tedious. Even more tedious when the title contains non-ASCII characters and you haven't got a browser which decodes URL escaping for you. We could conceivably allow freeform titles, but offer the canonical title as a subtitle or footer element. Would that be an acceptable balance between usability for editors and presentation quality? -- Tim Starling

Tim Starling wrote: Not if it runs though the parser, which my hack does. My hack does that (header). The JavaScript from User:Datrio doesn't, but probably could be expanded. Magnus

Magnus Manske wrote: Well I hate to tell you, but it doesn't work. :) 1) It breaks template inclusions. This *should* include a template: {{My template|value}} but instead it sets the display title to "value". 2) Most of the time it won't have any effect. For some reason it's trying to set $wgOut's global title setting from the parser. Most page views come from the parser cache -- the parser *does not run* at the time when the user comes to look at it. It ran on a previous view, or when the page was saved, and any ephemeral changes to $wgOut have long ago vanished. To be useful at all, it would have to save the value into the ParserOutput object, and it would have to be retrieved from that output object (either immediately-rendered or from the cache) at display time. 3) It may have effect in places it shouldn't. Previews, background rendering, display of message chunks inside a special page, etc might run the parser at many times other than a page view. This could lead to inappropriate overwriting of the special page's title information. An immediate example is that the "Editing XYZ" message gets overwritten entirely when previewing. Also I noticed a few weird bits in the code, such as this: $st .= str_replace ( "$1", $t, wfMsg('displaytitle') ); We removed this awkward construct a couple years ago, letting wfMsg() and friends accept parameters for replacements instead. It's generally much cleaner and more legible. -- brion vibber (brion @ pobox.com)

Moin, On Wednesday 12 April 2006 13:04, Magnus Manske wrote: How do you determine whether the parser currently runs for action=view or action=preview etc? I would like to generate different output depending on whether my extension code is triggered for a preview, or for a save. Best wishes, Tels -- Signed on Wed Apr 12 19:49:02 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. This email violates EU patent EP0394160: [ ########## 66% #### ]

Magnus Manske wrote: That's still extremely wrong. You should not attempt to divine anything about or affect the outside environment from the parser. In many cases rendering for future views happens at save time. It might also happen from a command-line maintenance script or other background job. -- brion vibber (brion @ pobox.com)

Brion Vibber wrote: I can certainly see where this might actually be a good thing to do. For example in the case of Aevar's <ref> extension it has been suggested that in cases where a section is being edited which contains <ref> tags but no <references/> tag, the extension might be able to produce a preview of what would appear without the user having to introduce a temporary <references/> (which would run the risk of their forgetting to remove it :-). -- Phil -- View this message in context: http://www.nabble.com/DISPLAYTITLE-t1429950.html#a3899914 Sent from the Wikipedia Developers forum at Nabble.com.

Moin, On Thursday 13 April 2006 15:01, Phil Boswell wrote: I knew you would say this :( With my preview I have a few problems that would be addressed by this: * fontsize change. The user can specify a global percentage of making the font bigger. Unfortunately, this affects #bodyContent (or however it is actually named, I forgot the name). Works fine for the saved article, but _also_ includes the preview/edit area (that arguable a bug, but fixing that needs introducing another div into the output in the mediawiki source code). So when you preview, suddenly all buttons etc, texts are also bigger. This makes editing _very_ hard. Of course, not seeing the real fontsize can be a bit problematic, too, but then, you can't know in what final base fontsize the entire article will be displayed, as every viewer is free to use CTRL+<+> and CTRL+<-> to change it at will. So I'd rather have a workable preview mode, and see the outcome in fontsize after saving. * UI change. My extension makes certain user elements disappear in the saved article for more viewing space (yeah, I can hear you already say "dont do that". However, it is nec. and usefull. When you present text, you dont want the menu. You dont print it, either, right? :-). However, during preview one might actually want the menu box, and the toolbox visible, only to have them disappear at save time. It is of course possible to disable both the fontsize change as well as the disappearing UI elements, as well as the preview-differes from save. So, for users who *want* that functionality, it must be implemented in the extension. I am not sure I understand it, I just know that the feature can be usefull. ;-] Another idea is that for extension producing graphics or other inline elements, a "preview" is (*Gasp! Shock! Horror!* :-) a preview, e.g. it is maybe rendered with a reduced quality, but faster. Only when you save the real final-quality image is produced. Another problem is that when a preview is produced, my graph extension (and any other extension producing files) leaks a file: Hash the contents to render to filename, produce preview, user then edits the contents, saves, a new file is generated. The file from the preview is, unlike files from former editions of an article, no longer accessable. With a dedicated preview action the file could be stored into a different temp folder, which could be cleaned out at any time without any risk of loosing files that are still referenced in real articles. (In fact, this point is the strongest point for determining =preview, because it would stop almost all leaks of files from my extension. The only ones left are from deleting articles and are much harder to get rid of.) So, I'd still like to know how to ask the parser whether it renders for a preview, or for the final save. Best wishes, Tels -- Signed on Thu Apr 13 19:14:38 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. "We're looking at a future where only the very largest companies will be able to implement software, and it will technically be illegal for other people to do so." -- Bruce Perens, 2004-01-23