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

[Chris Little]

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