On Sat, Mar 1, 2008 at 11:51 PM, DanTMan <dan_the_man(a)telus.net> wrote:
Which is more sane?
* Editing a large amount of code to make small changes. And then ending
up finding out that further improvements can't be made without hacks and
needing to edit a large amount of code again.
* One group editing a large amount of code to make small changes, at the
same time that another group decides to do something similar yet
incompatible with the other than extends the functionality in another way.
* Or one group editing a large amount of code to make small changes at
the same time as opening up the ability to improve that further without
the use of hacks.
The third, which is why I never said the mechanism shouldn't be
perfectly extensible. It should be.
On Sun, Mar 2, 2008 at 12:40 AM, DanTMan <dan_the_man(a)telus.net> wrote:
And I'm not saying that adding the extension
functionality is something
for you to do in addition. I'm saying that this could be best done as
multiple people working on different parts at the same time, and making
sure that the different parts are compatible with each other and work
cleanly instead of someone making a big hack later (Isn't changing a
small bit of functionality at one point and a hack needing to be created
later the whole reason we got into this whole big DISPLAYTITLE mess in
the first place? Repeating the past isn't good).
I'm even fine with being the one to do the extension stuff, while
working with you to make sure both our changes work together rather than
breaking each other, or locking the others features out and limiting
people to pick between.
I think you're assuming I'm actually going to do this. I doubt I am,
for the foreseeable future. I don't have the time to do much serious
hacking. I was just expressing a fond wish.
Next, I'm not saying that both things coincide.
In fact, we've been
talking in the notion that there are two types of titles, while ignoring
what's really there. There are three types of titles.
* Title key - keeps the complete normalized form. Used for uniqueness
checking, finding things, and such.
* Real title - keeps information on what the real padding, case, and
characters are actually inside of the title. Used in clean display of
the title and this is what is normalized to create the title key.
* Display title - this is what we actually display to the user, rather
than a bunch of technical limitations, the point is to make the display
suit the reader's eyes and deliver a name in a understandable means.
This may or may not be completely unique, and if it doesn't normalize to
the title key like the real title does, then some notification should be
added to make sure that bad links aren't created. In fact, rather than
just "Link with: Foo", we could output something like "Link with:
[[Foo|'''F'''oo]]" which considers limited parts of the
displaytitle
(only italic and bold should be considered if markup is allowed) as well
as the real title to create proper links that can actually be used in
the best manor.
The second and third titles you name may or may not be required to
coincide. Permitting them not to (i.e., allowing the display title
not to normalize to the title key, and/or permitting odd things like
HTML in the display title) raises its own set of difficulties that
will require a lot more thought than the initial proposal, and go a
lot further. And I don't think they should be in core.
But I think this discussion has gotten to the point where it may as
well stop, unless someone says they're willing to write the code.
Further argument over implementation details is probably not very
productive without anyone seriously considering an implementation.