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

[DM Smith]

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 <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
>
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page