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