<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">This assumes uni-directional use of an abbreviation. Once it is used for input, that is bi-directional, given by a user by typing or otherwise, it has a problem.<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 1, 2015, at 9:45 PM, Kahunapule Michael Johnson <<a href="mailto:kahunapule@eBible.org" class="">kahunapule@eBible.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<div class="moz-cite-prefix">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.<br class="">
<br class="">
Module ID -> abbreviation is OK.<br class="">
abbreviation -> Module ID is not OK.<br class="">
language ID + abbreviation -> Module ID is OK.<br class="">
<br class="">
But the "not OK" case is in active use, now. Sigh.<br class="">
<br class="">
Possible solutions:<br class="">
<ul class="">
<li class="">Stop doing that, and always require a full module ID
whenever you want to find a module. (Requires some software
rewriting and distribution.)<br class="">
</li>
<li class="">Require that all module abbreviations are globally unique
across well over 1,000 translations. (This precludes using
locally meaningful and traditional abbreviations in many
cases, and results in longer abbreviations.)</li>
<li class="">Let the user assign abbreviations and disallow assignment of
a duplicate. (You could suggest a default.)<br class="">
</li>
</ul>
Personally, I don't like the idea of burdening the user with
managing unique abbreviations, unless you have working defaults so
that this level of customization is not required.<br class="">
<br class="">
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 <a class="moz-txt-link-freetext" href="http://ebible.org/study/">http://eBible.org/study/</a> or <a class="moz-txt-link-freetext" href="http://inscript.org/">http://inScript.org</a> -- 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. <span class="moz-smiley-s3"> ;-) </span><br class="">
<br class="">
On 09/01/2015 12:42 PM, Peter von Kaehne wrote:<br class="">
</div>
<blockquote cite="mid:1441147334.9589.138.camel@gmx.net" type="cite" class="">
<pre wrap="" class="">On Tue, 2015-09-01 at 18:19 -0400, Karl Kleinpaste wrote:
</pre>
<blockquote type="cite" class="">
<pre wrap="" class="">On 09/01/2015 09:29 AM, DM Smith wrote:
</pre>
<blockquote type="cite" class="">
<pre wrap="" class="">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.
</pre>
</blockquote>
<pre wrap="" class="">I'm glad I didn't misunderstand this aspect.
</pre>
</blockquote>
<pre wrap="" class="">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: <a class="moz-txt-link-abbreviated" href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/sword-devel">http://www.crosswire.org/mailman/listinfo/sword-devel</a>
Instructions to unsubscribe/change your settings at above page
</pre>
</blockquote>
<br class="">
<br class="">
<div class="moz-signature">-- <br class="">
<meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8" class=""><p class=""><font class="">Aloha,<br class="">
<i class="">Kahunapule Michael Johnson</i></font></p>
<table cellpadding="7" cellspacing="0" class="">
<tbody class="">
<tr class="">
<td style="background: rgb(255, 255, 0)" class=""><font class=""><b class="">MICHAEL JOHNSON<br class="">
PO BOX 881143<br class="">
PUKALANI HI 96788-1143</b><br class="">
USA</font></td>
<td style="background: rgb(0, 255, 255)" class=""><font class="">
<a href="http://ebible.org/" class="">eBible.org</a><br class="">
<a href="http://mljohnson.org/" class="">MLJohnson.org</a><br class="">
Mobile: +1 <b class="">808-333-6921</b><br class="">
Skype: kahunapule</font></td>
</tr>
</tbody>
</table>
</div>
</div>
_______________________________________________<br class="">sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" class="">sword-devel@crosswire.org</a><br class=""><a href="http://www.crosswire.org/mailman/listinfo/sword-devel" class="">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br class="">Instructions to unsubscribe/change your settings at above page</div></blockquote></div><br class=""></div></body></html>