[sword-devel] Adding abbreviated names to the module conf file (was Re: isalnum(3) for i18n)
chrislit at crosswire.org
Tue Dec 16 18:54:41 MST 2008
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
> 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
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
More information about the sword-devel