|
The uniqueness of an abbreviation is
not required as long as you never try to look up which module
corresponds to that abbreviation. If all you do is use the
abbreviation as a short way to display which text is selected,
i.e. just looking up the abbreviation given the module name,
collisions are no big deal. If you look at both the language code
and the abbreviation when doing lookups, collisions are avoided.
Module ID -> abbreviation is OK. abbreviation -> Module ID is not OK. language ID + abbreviation -> Module ID is OK. But the "not OK" case is in active use, now. Sigh. Possible solutions:
As an aside, finding and picking the Bible(s) you want to read has gotten a bit more challenging. One long pulldown list isn't a great idea, now. It helps to have a way to search with some sort of hierarchy, like Country->Language->Translation and/or have a filter box to apply. This is something we do in inScript. (See http://eBible.org/study/ or http://inScript.org -- the latter has more Bibles on it.) That is a front end issue I'm not going to touch, right now, other than to point out the elephant in the UI room and go back to making it even more challenging by adding more Bibles. ;-) On 09/01/2015 12:42 PM, Peter von Kaehne wrote: On Tue, 2015-09-01 at 18:19 -0400, Karl Kleinpaste wrote:On 09/01/2015 09:29 AM, DM Smith wrote:Having Abbreviation=KJV for a Thai module is clearly not the intent. To use it within a repo with uniqueness by language is entirely a bad idea.I'm glad I didn't misunderstand this aspect.Michael explains that "KJV" is what is - at least in missionary circles - used for the ThaiKJV. So, yes, this is the intent for Abbreviation as a user friendly option.Certainly I can see that within the Latin script area there may well be clashes for some modules - and we should simply not ever assume that the Abbreviation entry will always be unique across all repos and all modules in existence. It _must_ be unique for a user - and either the computer or the user must be able to resolve clashes. But we should neither assume uniqueness nor rely upon that until a frontend has given for a particular moment the "all clear". Peter _______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page --
Aloha,
|
_______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
