Hopefully, if the new DISPLAYTITLE functionality goes into effect, the effect of this can be done. X! On Dec 29, 2008, at 9:59 PM [Dec 29, 2008 ], K. Peachey wrote:

On Mon, Dec 29, 2008 at 8:31 PM, Soxred93 <soxred93(a)gmail.com> wrote: What new DISPLAYTITLE functionality? Is this separate from https://bugzilla.wikimedia.org/show_bug.cgi?id=12998 ? -- Remember the dot http://en.wikipedia.org/wiki/User:Remember_the_dot

Aryeh Gregor wrote: What about providing " » " as a image with alt="/" ?

On 30 Dec 2008, at 22:13, Aryeh Gregor wrote: What about programming the software to replace " » " in links with "/" before submitting to the database or previewing the page.

Aryeh Gregor wrote: If not a PST, it would pretty much have to be done in title normalization. For one thing, we'd need it for link existence checks. But I have a simpler suggestion: why not display the title just like we do now, but use CSS to add some padding around the slashes and to render everything up to the last slash in smaller font on a separate line? Should be easy enough to do with just a couple of simple <span> tags, and be perfectly cut-and-pasteable. Granted, it means sticking with "/" as the delimiter instead of "»", but I wouldn't think that'd be a blocking issue. -- Ilmari Karonen

On Tue, Dec 30, 2008 at 10:03 PM, Ilmari Karonen &lt;nospam(a)vyznev.net&gt; wrote: Yes, title normalization would be the right place if we did this. That's a good idea. If you put it on a separate line (say with display: block; for the last part), will browsers insert a line break when you copy-paste? Firefox seems to in a quick test, although I wasn't very exact (maybe it special-cases <p> or checks margins or something). I would expect it to generate the newline, as a user. I don't think the last part is necessarily what we want to emphasize, anyway. If you have a title like "Principia Mathematica/Part 1", you want to emphasize the first part of the title more, surely. Having the name of the work in small print and the section in large print seems backwards to me. It should be pointed out that we could do whatever we want with the <title> attribute of articles, since there's no copy-pasting problem there.

On Sun, Jan 4, 2009 at 11:02 AM, Michael J. Walsh &lt;michaelj.walsh(a)oceanfree.net&gt; wrote: The nature of books is such that you almost inevitably see the cover of the book (which contains the title) before you ever look at the inside, so you don't necessarily need reminders of the title. On the other hand, web pages can expect many if not most visitors to reach any given page by direct links, skipping any material that might have given them an earlier clue to the title. So I'm not sure print is a good analogy for what we should do here.

On Sun, Jan 4, 2009 at 5:19 PM, Michael J. Walsh &lt;michaelj.walsh(a)oceanfree.net&gt; wrote: Filenames conventionally encode information in a way that section numbers don't. In MediaWiki itself, Brion reverted a change a while ago which changed SpecialFoo.php to specials/Foo.php. He changed it to specials/SpecialFoo.php, putting info in the filename that's redundant to the path. This is because applications expect the filename to have meaning on its own, even if you strip the path. Text editors commonly put the filename on the tab, but not the path. But in this case, "Italy" logically implies "Europe" and "Regional". The latter two pieces of info are in fact entirely redundant. "Part 1" does not logically imply "Principia Mathematica" at all: in fact, if you don't already know you're reading Principia Mathematica, "Part 1" is completely useless as an identifier. It would be like having the <title> for an old version of a page in MediaWiki be "Revision as of 2008-01-04" instead of "Articlename". "Articlename - revision as of 2008-01-04" might be better still, but if you're going to emphasize one piece of information, it should be which article it is, not which part of the article. Similarly, we put the site name at the end of the title, not at the beginning, so if you have many tabs open from the same site, you can easily tell them apart. I think it's clear that analogies exist in both directions here. If this is going to move forward (which looks vaguely unlikely), the format needs to be considered on its own merits, not by analogy.