> Then I strongly vote for adding an optional Displayname= or something
> like that to the configuration files. I think it is not wise to
> identify internal module identifier and screen display name -- these
> are two distinct concepts.
Yep, that's why we have 'name', 'description', and 'about'.
eg.
[NKJV]
(name)
Description=New King James Version
About=New King James Version NKJV, copyright 1982 \par \
Thomas Nelson, Inc. All rights reserved. Bible text from \par \
the New King James Version is not to be reproduced in \par \
copies or otherwise by any means except as permitted in \par \
writing by Thomas Nelson, Inc.
Description is supposed to be for the user display, but is probably too
long for tabs and other things that we current use to display 'name'.
Maybe we do need something like your DisplayName=NKJV
I must say that this will probably require alot of client code changes.
I know we personally lookup modules by the tab caption in the windows
frontend. We'd have to save the name of the associated module some
place else. Not sure what the other frontends do.
I agree that we want to support display short names with the full range
of unicode characters. We won't really break anything by adding
DisplayName=. Current frontends won't do anything with it, and will
still display 'name', but when they want to get around to supporting it,
they can make the necessary changes.
OK, I'm for it. Anyone else want to chime in?
> (All the old modules don't have to be
> changed (except for those with ~) because we can use the identifier if
> the Displayname is not present.)
good default.
> Especially when you consider that for some modules, people might like
> to use UTF-8 names. I'd prefer to call a German dictionary
> "Wörterbuch", instead of having the APIs force me to use the clumsy
> "Woerterbuch".
Agreed.
-Troy.
> Greetings,
> Christian Renz
>
