Brion Vibber schrieb:

Magnus Manske wrote:

...

I suggest the implementation of a new magic template: {{DISPLAYTITLE|HTML-encoded title}} which will change the display of the title. I am aware that it would be a potential target for vandals, but hey, what on wikipedia isn't?

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.

Similar to "Redirected from", there could be a message "Link to this page as [[PKB value]]" on all pages that have DISPLAYTITLE.

Note that this will only be applicable to a small number of articles, compared to the million we have. But for those, it will make a huge improvement in appearance.

Magnus

Steve Bennett schrieb:

On 4/11/06, Magnus Manske magnus.manske@web.de wrote:

...

I suggest the implementation of a new magic template: {{DISPLAYTITLE|HTML-encoded title}} which will change the display of the title. I am aware that it would be a potential target for vandals, but hey, what on wikipedia isn't?

I'd be willing to implement it if there's no major objection.

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?

We agreed on standards for articles in these matters. We can do that for the relatively low number of article titles this would affect.

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.

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:

On 4/11/06, Magnus Manske magnus.manske@web.de wrote:

...

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 just suspect that if the possibilities are there, it will become quite fraught (unless the policies are very clear). Someone will be going "but company FOOBar" *always* writes the Bar in italics, and Foo in bold. But I don't think that Wikipedia should respect that.

But you're right, we should leave that one to the community to manage.

...

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 :-)

True. :) But the parser could be as simple as replace(replace(s, "<", "&lt;"), "&lt;sup&gt;", "<sup>") etc.

...

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.

I have an example. [[Prima facie]] (and other latin expressions), [[ménage à trois]] etc. Would we have any call to allow a title to be *partially* in italics? If not, perhaps you could make a variety of flagtags like:

{{TITLEFIRSTLETTERCAPS}} {{TITLEITALICS}}

...and then somehow deal with superscript/subscript :)

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.

PS if you're hacking on stuff like this, can I request a flag to limit the depth of a contents section? Sometimes having 3rd and 4th level subheadings show up in the contents is just ugly and not helpful...

How about {{LIMITTOC|3}} ?

Magnus

On 4/11/06, Locke Cole locke.cole.wiki@gmail.com 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

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

Brion Vibber schrieb:

1. It breaks template inclusions.

This *should* include a template: {{My template|value}}

but instead it sets the display title to "value".

My bad, fixed.

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.

I'll work on that.

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.

I've limited it to "$action == 'view'". That leaves some special pages. I'll write a workaround.

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.

We have sooo many goodies nowadays, I keep forgetting... ;-) Anyway, fixed.

Magnus

Tels wrote:

How do you determine whether the parser currently runs for action=view or action=preview etc?

You don't. :)

The parser does not (or should not!) know anything about the outside environment.

I would like to generate different output depending on whether my extension code is triggered for a preview, or for a save.

Please don't. Among other things, this defeats the purpose of a preview.

-- brion vibber (brion @ pobox.com)

On 13/04/06, Phil Boswell phil.boswell@gmail.com wrote:

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 :-).

It would also be nice if the categories next to the rest of the page, above the edit box. With however I set my prefs, I get this:

page text

edit box

categories

Steve

Moin,

On Wednesday 12 April 2006 20:33, Brion Vibber wrote:

Tels wrote:

...

How do you determine whether the parser currently runs for action=view or action=preview etc?

You don't. :)

The parser does not (or should not!) know anything about the outside environment.

So please tell my how my extension can know about preview or not preview. For reasons why this is actually desirable, see my other email. :)

If the Parser should not know, then something else must know and be able to pass the knowledge on. If it can't, then extensions producing files are forever leaking files and thus clobbering disks up :(

Best wishes,

Tels

Brion Vibber wrote:

Magnus Manske wrote:

...

...

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.

I've limited it to "$action == 'view'". That leaves some special pages. I'll write a workaround.

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.

I will remove this hack once I make it return data through the parseroutput object.

Magnus

Tim Starling schrieb:

Magnus Manske wrote:

...

I just saw the de.wikipedia article about the pKB value, which:

• looks like "PKB"
• should look like "pK_B"

This looks pityful, and the note that it can't be shown otherwise for technical reasons doesn't really help the matter.

I suggest the implementation of a new magic template: {{DISPLAYTITLE|HTML-encoded title}} which will change the display of the title. I am aware that it would be a potential target for vandals, but hey, what on wikipedia isn't?

I'd be willing to implement it if there's no major objection.

The Chinese Wikipedia actually has this already. The syntax is -{T|Title goes here}- . The intended application is to change the display title depending on the selected language variant. For example, the Chinese Wikipedia main page has this:

-{T|zh-cn:首页;zh-tw:首頁;zh-hk:首頁;zh-sg:首页}-

Is this an extension, or in the main code already? Could it be tweaked to work without "en:"? Does it allow for HTML to be rendered in the title?

More importantly, could it be changed to use the more "wiki standards" (if there is such a thing) {{T|Title}} style?

Magnus

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:

Tim Starling schrieb:

...

Magnus Manske wrote:

...

I just saw the de.wikipedia article about the pKB value, which:

• looks like "PKB"
• should look like "pK_B"

This looks pityful, and the note that it can't be shown otherwise for technical reasons doesn't really help the matter.

I suggest the implementation of a new magic template: {{DISPLAYTITLE|HTML-encoded title}} which will change the display of the title. I am aware that it would be a potential target for vandals, but hey, what on wikipedia isn't?

I'd be willing to implement it if there's no major objection.

The Chinese Wikipedia actually has this already. The syntax is -{T|Title goes here}- . The intended application is to change the display title depending on the selected language variant. For example, the Chinese Wikipedia main page has this:

-{T|zh-cn:首页;zh-tw:首頁;zh-hk:首頁;zh-sg:首页}-

Is this an extension, or in the main code already?

It's in LanguageConverter.php.

Could it be tweaked to work without "en:"?

It works without the language code already.

Does it allow for HTML to be rendered in the title?

Hopefully not, that would be unsafe.

More importantly, could it be changed to use the more "wiki standards" (if there is such a thing) {{T|Title}} style?

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

On 4/11/06, Magnus Manske magnus.manske@web.de wrote:

Tim Starling wrote:

...

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?

My hack does that (header). The JavaScript from User:Datrio doesn't, but probably could be expanded.

If I understand correctly, that's simple - just copy the content of h1.firstHeading to div#contentSub, before substituting it for the correct title.

There probably are a few flaws in my idea, as I wrote it in the simpliest way possible, but they shouldn't be too hard to fix. The only one I found so far, is that during editing you'll get the normal title, not the correct one. That'll be harder ro change, but - still possible.

My JavaScript is good in the way of accessibility - it just substitutes the h1 element, without changing the URL, or anything else. It's good for browsing Wikipedia - if someone would want to enter the URL of it into the browser, his browser would (probably) not support it.

Still, it's not that much our problem. I think the most we can do is substitute h1 with the correct title from the {{Title Restrictions}} template, or similiar.

-- Pozdrawiam, Dariusz Siedlecki