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

[Peter von Kaehne]

Chris Little wrote:
> 
> 
> DM Smith wrote:
>> 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.
> 
> Okay. While I find the arguments in favor of localizing all string
> fields in .confs entirely unconvincing, it doesn't drastically harm
> anything to permit module makers to add more data to their .conf files.

Good. I do not expect anyone to make use of the ability to localise
_all_ strings, but the big 4 - Abbr, About, Description and one of the
copyright related ones will make a difference.

> 
> In the absence of a localized form, the un-suffixed version will always
> be default. In general, the title-like attributes will be according to
> the actual title of the book, generally in the language of the text.
> Names of people/organizations will generally be language-neutral. The
> rest will generally be language-neutral or in English.

That is my understanding

> That said, nothing will *work* unless someone writes the code to take
> advantage of it.
> 

I think the agreement was the harder and more important part. Now we can
add localised strings and eventually someone will step up to the plate
and provide the code.

>> 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.)
> 
> So, for reference, the width of 16 characters would be:
> xxxxxxxxxxxxxxxx
> Six would be:
> xxxxxx
> 
> I suspected there would be disagreement with my suggested number, but I
> had assumed that it would seem too low. So... some of my reasoning:
> 
> Many Bibles will include a year, which eats up 4 characters in itself.
> Bibles with standard abbreviations aren't a big issue (WEB, NIV, NASB,
> NRSV, etc.) but many others incorporate a translator/place/organization
> name--which can be longish (Elberfelder, Webster, Grünewald, Rotherham,
> Delitzsch, Tischendorf, Cornilescu, etc.)
> 
> So, we could make the limit lower, but I worry that we would limit the
> meaningfulness of these strings. Maybe we could cut it down to 12?:
> xxxxxxxxxxxx

I would argue against this. If we restrict Abbr in this severe fashion
then we only recreate the situation around the current [Name]. If a
frontend is really incapable for space reasons to do anything with
decent sized titles then  they can always revert to the Name/ModuleID.
At least frontends which are capable of displaying a complete title will
not be limited. Why have two limited size names?

Elberfelder1905 - 15 letters. I am sure there are longer ones about.
Russian is probably a good candidate for long titles.

Peter









> I18n isn't much of a concern here. Western European languages have the
> highest sign to phoneme ratio that I can think of. And non-alphabetic
> scripts will generally be far more economical in terms of
> codepoints--though this will often be lost due to physically wider
> characters.
> 
> --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