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

[Daniel Owens]

This is a good issue to discuss. I think both Chris and Peter's ideas 
have merit.

- It would be nice to have more than one alternative, tied  either to 
the current locale or to some configuration option (it is up to the 
front-end developer, if you ask me, how they use this information)
- The default should not necessarily be English. This is what Chris is 
suggesting. The default display ought to be in the language that the 
module developer decides (usually the language of that module, except in 
the case of ancient texts, in which case probably English should be the 
default).
- An English equivalent should be there for the sake of developers at 
the very least, and then there should be the ability to add third, 
fourth, fifth, etc., options for those items to be accessed by 
front-ends in some way (according to their choosing).
- I think Chris is right that we should keep the language of Description 
and About and add Abbr (not Name, though BriefTitle or AbbrTitle would 
also make sense to me). The module developer should decide in what 
language those should be written. Whether we use Abbr_en or enAbbr is 
something for front-end developers to decide.

One further item I would like to propose is an Author field. This is not 
so important for Bibles (and maybe for most dictionaries), but for most 
books the author is a major factor in whether one uses it or not (way 
more important than title). It could be argued that the author ought to 
be in the Description or About, but if front-ends in the future want to 
enable users to sort the books in their library by author, title, 
subject, etc., then there needs to be a field for that. It also 
facilitates bibliographic citation for students and scholars. The more 
books are added, the more important this becomes. And it also ought to 
be localizable (I'm thinking especially of Chinese authors). A Publisher 
field could be useful too, but that usually is given in the About field, 
so I wouldn't push for it as long as the full bibliographic information 
is there somewhere.

Daniel

Chris Little wrote:
> 
> 
> Peter von Kaehne wrote:
>> Chris Little wrote:
>>> 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.
>>
>> My feeling is that this is still too constraining.
>>
>> My suggestion is following (look at /usr/share/applications - example
>> attached below):
>>
>> ModuleID=[]  # the current Name
>> Name=        # The English name, might be identical to ModuleID
>> Name_de=
>> Name_fr=
>> Description=
>> Description_de=
>> Description_fr=
>>
>> Localisable for Name, Description, About and Copyright.
>>
>> This would allow as many and as few names as one wishes, always give a
>> sane fallback (the English name) and allow particularly for the original
>> texts a multitude of names etc. I think I can tell you a dozen or more
>> modules off hand where 3 or 4 names are useful and another handful were
>> as many as 100s of names will eventually be useful.
> 
> I know that there are circumstances where it would be advantageous to 
> provide another language besides English as a fallback. For example, in 
> a large swath of Africa, Kiswahili would be a better fallback. In much 
> of the Muslim world, Arabic would be a better fallback. And in much of 
> the former Soviet Union, Russian would be a better fallback. But 
> "fallback" implies the non-existence of the favored solution (the 
> localized name), and these modules would all have localized names if 
> they would have anything other than an English form.
> 
> And while I can appreciate an abstract desire to have this sort of 
> information, I cannot envision, from the perspective of implementation, 
> how it would be used. There's no obvious order of fallback precedence.
> 
> I have a feeling that the multiplication of .conf file entries is going 
> to have the result that they'll basically get ignored by frontend 
> developers--other than those explicitly exposed by new SWConfig methods 
> like I described or otherwise default (i.e. what's in Description/About).
> 
> Could you describe how you think all of these values would be used 
> practically?
> 
> It's a minor issue, but I also couldn't support adding an attribute 
> named "Name" simply because the Description field holds the title 
> currently--which is too semantically similar to name. That's why I 
> suggested "Abbr".
> 
> --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
>