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