[sword-devel] Adding abbreviated names to the module conf file (was Re: isalnum(3) for i18n)
dmsmith555 at yahoo.com
Wed Dec 17 07:22:00 MST 2008
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
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.)
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 <benpmorgan at gmail.com>
>>> 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
>>> 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_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
>> as all frontends could display the localised text (e.g. AraSVD goes
>> 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
> 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?
> sword-devel mailing list: sword-devel at crosswire.org
> Instructions to unsubscribe/change your settings at above page
More information about the sword-devel