On Sat, Mar 1, 2008 at 11:51 PM, DanTMan dan_the_man@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@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.