Chris,
I would like to lobby for a separator between the language code and
the field name. I don't much care whether it is a prefix or suffix.
While I understand that you are suggesting that we don't have a deAbbr
or xxAbbr, I could see that it might be added some time in the future
and with 3-letter codes and with differences in script (e.g.
Traditional/Simplified Chinese), a separator makes it much easier to
code for today.
I like that the default should be in the language of the module. I'm
assuming as well in the encoding of the module (e.g. UTF-8 for UTF-8
modules).
WRT the length of Abbr, I'd like to see it be much shorter than 16 or
that 16 be the upper limit w/ a much smaller number being the
recommended maximum, say 6?, with the knowledge that anything longer
than 6 (or whatever is the recommended max) may be truncated by some
frontends (e.g. MacSword and BibleDesktop have dropdowns for a
parallel view which have a severe limit of 4. I imagine that small
devices, such as phones and PDAs would also have a real estate problem.)
In Him,
DM
On Dec 16, 2008, at 7:47 PM, Chris Little wrote:
Jonathan Morgan wrote:
On Thu, Aug 14, 2008 at 4:50 AM, Ben Morgan <benpmor...@gmail.com>
wrote:
I'd really like to see an abbreviations field - while a
description is
useful, an abbreviation such as KJV, ESV, etc is invaluable when
there is
not much room.
Most bibles have such an abbreviation.
I also agree that we should be targeting most of this at the end
users of
each module - developers don't matter nearly as much :)
So I think:
Description should be in the foreign language (encoded as per
encoding
directive)
There should be a field Abbreviation for a short version (encoded
as per
encoding directive)
And the actual module name (presumably derived from the
abbreviation, but
ascii) can be used by developers.
Maybe a field like Description_en would be a good idea. Then if
you are
using the english locale, you might see that in the frontend.
That way you could also have a Description_fr for french
description,
Description_de for german description, etc.
Just reviving this thread, I think at a minimum we need to add an
optional "Abbreviation" field to the module configuration to contain
an abbreviated form of the module name, to be used where frontends
currently use the module name (due to limited space). For modules
which do not have it, this would fall back to the module name. For
modules like ESV, ISBE, KJV, ... the module name is perfectly
acceptable, but for something like GerLut1545 a better abbreviation
would probably be Luther 1545 or similar (and this is a problem for
almost all foreign language modules, and I don't want them to be
essentially second class citizens).
I'm not going to argue at present about whether this should be
localised or not, but I suspect it would be better if it were, so
long
as all frontends could display the localised text (e.g. AraSVD goes
to
some brief Arabic name).
Re-resurrecting this thread, since Peter is proposing something
quite similar.
I'd like to propose 4 new .conf file entries, along with a couple
fallback orders. Presently module naming is identified in .confs via
three values:
The internal module ID (what's in between the square brackets at the
head of a .conf) is highly constrained ([A-Za-z0-9_]+). The
Description contains the module title. And the About can contain a
bunch of info, or as little as the title (when that's all that's
available).
In addition to these, I recommend adding enDescription, enAbout,
Abbr, and enAbbr.
We traditionally include English and localized title/about data
within Description & About entries. The addition of enDescription
and enAbout would simply divide these, so enDescription will contain
the English title and Description will contain the localized title.
Likewise, enAbout will contain the English about text and About will
contain the localized version.
Abbr will contain a localized abbreviated (short form) title
(possibly an abbreviation or initialism). And enAbbr, by analogy
will contain an English-form abbreviated title. Unlike the module
ID, the (en)Abbr won't have any restrictions with respect to
codepoints (except that LF & CR are prohibited, I suppose). I would
also like to recommend we put a soft limit on spacing codepoints
here. I think 16 spacing codepoints is /probably/ reasonable.
Limiting this will allow frontends to display this short form in
sidebars without taking up too much screen real estate. Keeping it a
soft limit lets module developers use longer abbreviated titles at
the risk of not having them display completely on all frontends.
We should add a few methods to SWConfig for grabbing this data via
the fallback mechanism I'm about to describe, but the data will also
be there via the existing mechanisms for those who desire finer
grained control in their frontends. The methods should give access
to the preferred forms (as described in the fallback order below) as
well as concatenated entries (the localized plus English forms).
Ideally you'll want to display the title from Description, but
enDescription would be there as a fallback. Likewise enAbout would
be the last resort if About is unavailable. And finally, abbreviated
forms should be taken from Abbr, or enAbbr if that's unavailable, or
the module ID as a final fallback.
All data in the new entries should follow the existing encoding
standards for .confs: If the module Encoding=UTF-8, these entries
will be UTF-8. Otherwise, they must be cp1252. (Frankly, I don't see
any need to issue cp1252 modules at all. But I want to be explicit.)
All UTF-8 should be in NFC.
We want new data to take advantage of improvements, but we don't
want to break existing, installed data. I think this achieves that.
Sound good?
--Chris
_______________________________________________
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
_______________________________________________
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
