[sword-devel] Adding abbreviated names to the module conf file (was Re: isalnum(3) for i18n)
chrislit at crosswire.org
Tue Dec 16 17:47:32 MST 2008
Jonathan Morgan wrote:
> On Thu, Aug 14, 2008 at 4:50 AM, Ben Morgan <benpmorgan at 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
>> 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
I'd like to propose 4 new .conf file entries, along with a couple
fallback orders. Presently module naming is identified in .confs via
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,
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
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
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.
More information about the sword-devel