<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
DM Smith wrote:
<blockquote cite="mid:A5AA07FF-B3D8-4287-A785-61CDB47689AD@yahoo.com"
 type="cite">
  <pre wrap="">On Aug 12, 2008, at 8:22 PM, Jonathan Morgan wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">On Wed, Aug 13, 2008 at 2:48 AM, Eeli Kaikkonen
<a class="moz-txt-link-rfc2396E" href="mailto:eekaikko@mail.student.oulu.fi">&lt;eekaikko@mail.student.oulu.fi&gt;</a> wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">On Mon, 11 Aug 2008, Chris Little wrote:
      </pre>
      <blockquote type="cite">
        <pre wrap="">2) The module name is intended for use by developers, not  
necessarily
for display to users. That's why the constraint is iscsym--to
facilitate use within code. If you want to suggest the addition of a
short abbreviation .conf tag, that's a different matter.
        </pre>
      </blockquote>
      <pre wrap="">People seem to get used to those short abbreviations but still they  
are
not very user friendly. Actually I would like to have two extra  
tags: a
short abbreviation in the language of the module and a description in
the language of the module. In internationalized and localized
environments it's important to have both English and native language
information available. As a user and as a developer I want to see
information which I can understand even if I can't read the module.
Therefore English short description is important. But I would like to
have also a short Finnish abbreviation in Finnish modules. It's quite
stupid to for example copy a quote which have "FinPR" attached while
no-one uses that in Finnish - it's usually "KR 38" or something like
that.
      </pre>
    </blockquote>
    <pre wrap="">A lot of what we do happens for the convenience of developers rather
than users.  This should probably change, but it's not an easy thing
to change.  I think you are right that localised book names and
abbreviations are appropriate.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I think two fields make sense. One as an alternate for [name] and one  
for Description=
It might be better to use Description for a localized name. If you  
can't read it, you probably cannot read the module:)

  </pre>
</blockquote>
This is a very good (and important) discussion. I agree that the
Description field should be used for a localized name, and perhaps a
recommended character length should be added to the module creation
wiki to give module developers a better idea of how long that field
should be. <br>
<br>
However, not all UTF8 Description fields are readable in all
front-ends, though off the top of my head this only really affects
BibleCS. It would be fantastic if all front-ends supported UTF8
Descriptions AND used the Description field for the selection of
modules by the user. BPBible is a hybrid of the abbreviation and the
Description. In any case, the display of a module for selection ought
to be in a form that the end-user can recognize immediately.<br>
<blockquote cite="mid:A5AA07FF-B3D8-4287-A785-61CDB47689AD@yahoo.com"
 type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <pre wrap="">
    </pre>
    <blockquote type="cite">
      <pre wrap="">It has occurred to my mind that a frontend could offer a UI for  
giving
the abbreviation. User could give whatever string he wanted and it  
could
be used in module lists and in other places. It would of course be
stored separately, not in the module conf.
      </pre>
    </blockquote>
    <pre wrap="">I don't necessarily mind that as an extra, but the problems with it  
are:
1. Most users won't want to do it.  As much as possible it should be a
thing that just works, which means a good, localised name and
abbreviation should come with the module.
2. It is unlikely to be supported by other applications, meaning you
have to do it on a per application basis or not bother.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
IMHO, It would be good for the engine to give write capabilities to a  
conf, with critical fields being write protected (at least with a  
warning.)

Then it would be straight forward for all front-ends to provide the  
ability.

In Him,
        DM


  </pre>
</blockquote>
<blockquote cite="mid:A5AA07FF-B3D8-4287-A785-61CDB47689AD@yahoo.com"
 type="cite">
  <pre wrap="">
_______________________________________________
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>
Daniel<br>
<pre class="moz-signature" cols="72">-- 
PMBX license 1502 
</pre>
</body>
</html>