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

[Peter von Kaehne]

Chris Little wrote:
> Since new module .confs would have module name information in the
> module's own locale (provided it is available), I don't believe there's
> really a case where the system/user locale would ever be used.

I can see many cases - where someone wants to keep a different
language's module around for reference and use, but would prefer his own
language's name.

> 
> Take, as a random example, the Western Highland Chatino NT we have. It's
> title is "Cha' Su'we Nu Nchkwi' Cha' 'In Jesucristo Nu Nka X'naan". That
> would go in Description. We would put something like "Western Highland
> Chatino NT" in the enDescription field, basically as a convenience to
> ourselves. 

And a Mexican pastor would like to have a Spanish text here for his/her
convenience.


I can't forsee a circumstance where the German, French, or
> Russian translations of "Western Highland Chatino NT" are useful. If you
> can only read English, German, French or Russian, then the text isn't
> going to be very useful to you.

For most modules there might be only 2 or 3 names, so that the
discussion we have is largely irrelevant. But for a fair number
(minority languages, neighbouring languages, classic modules of varying
kind (not just ancient original texts) a name in one's own
language/locale is useful.

> I don't see the utility in other cases either....

Thing is your first language is English, so your "convenience names" are
a convenience indeed. for many they are not. A name in their own locale
would be.

>> So if my locale is set to German in GS I want the Vulgate appearing as
>> Vulgata, while whatever name a Russian would give the Vulgate would
>> appear for him.
> 
> The proper titles of most original language texts are in Latin. We have
> a couple "Vulgate" modules, but those are historical artifacts. More
> recent work calls this Vulgate (cf. Vulgata Clementina). See also,
> Biblia Hebraica Stuttgartensia, Textus Receptus, Septuaginta, Aleppo
> Codex, Westminster Leningrad Codex. Regardless of what we may have (or
> have had), almost all of these should properly be in Latin or be
> relatively language-neutral.

For an Arab/Assyrian Christian who wants to keep the Peshitta around,
who will maybe struggle to read it fluently, but enough to get
enjoyment/enlightenment from it, will not know English or Latin, but
enough Assyrian to make sense of it, a Latin text name is not useful.

A Persian minister wants to have Assyrian and Armenian al,ong with Arab,
Krdish and a few more for his congregation, but will not by necessity be
able to understand any of these module descriptioins in either English
or original language

For a modern Jewish Israeli Christian who will understand old Hebrew
enough, again Latin names are an irrelevancy. A Hebrew name is much more
appropriate.

And then my proposal was not just for the names, where you are arguably
more right then wrong. The module descriptions etc are along my model
fully localisable and that is of huge value with all classical texts. I
want a good German explanation for any particular original text, and teh
Mexican minister will appreciate a Spanish one for the West Highland
Chapotec

> So in general, in the "Description" field we want the REAL title of the
> text--what you would expect to find on the title page of the printed
> edition.  "enDescription" would have an English translation of the
> title, an English description, or (with the Japanese Bibles, for
> example) a Latin-script transliteration.

As I said, we limit use here without need. A Russian wants to have a
cyrillic transliteration and who are we to state that this is
inappropriate? Particularly as many of the Central Asian (e.g) Christian
literature will be of Russian origin and authorship.

I think an argument could be had for following scheme combining both
proposals into following:

[Config_entry]_original

[Config_entry] [locale] and ubiquitous installation of a English locale
which in turn would be returned by the machine if a locale is set but
does not deliver.

This would require some changes to frontends as there is a suddenly a
choice between original name (module locale) and localised name
(programe/system locale) but I presume this would be a reasonable simple
change "Show module original names" yes/No and then definition of a
custom ISO639-like code standing for original name/description/whatever
- at which point the frontend again will not have to consider the matter
anymore further.

The point being that we do not need to _provide_ the locale in each and
every case, but once a module finds a larger readership we will get the
locale settings in a variety modules where this is interesting.

Peter