[sword-devel] Adding abbreviated names to the module conf file (was Re: isalnum(3) for i18n)

[Chris Little]

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
>> 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