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
