[sword-devel] language of module descriptions
dmsmith555 at yahoo.com
Sun Mar 20 06:03:12 MST 2005
Previously I have done a lengthy study of the confs of our public modules.
Based upon that I would like to make some observations:
Please correct me where I am wrong, especially wrt the Sword program.
I am very familiar with the JSword software.
1) The keys for each field need to be fixed and not I10N/L10N.
If you look at the modules page, you will see that there are
of these into English. When presented to a user it can be
the translations should be external to the conf files. This applies
to all other
fixed/patterned fields in the conf.
2) There are fields whose values are used by software.
These are not candidates for I18N/L10N.
a) The first line of a conf is [modulename].
When moved to lowercase, this is the name of the module's conf.
Since this name is used by files, often in the same directory
(e.g. mods.d) it has to be unique.
I don't think that there would be a problem with having a new
which is presented to the user, but is not otherwise used.
b) Some fields are single value among a fixed list of values or by
Some of these are presented to the user and should be I18N/L10N.
However, since the list is fixed or patterned, this does not
need to be done in the conf.
For example, JSword takes the Language field and does a lookup
to translate it into
the user's language, if we have such a translation present (so
far we have no translations:-)
The rest are visible only to software and have no need of it.
* DataPath (if you want to call a path a pattern)
c) Some fields can be repeated but the values are among a fixed
These are presented to the user and should be I18N/L10N.
d) Other fields have values that are not fixed but are specific.
3) There are fields that are not used by software but are presented to
a) Fields whose values are fixed list of values or fixed patterns:
b) Some fields can be repeated but the values are among a fixed
* Obsoletes (module names of prior versions)
If we add an I18N/L10N ModuleName, do we need a
corresponding field for this?
c) The rest of the fields are informational and are candidates for
Daniel Glassey wrote:
> Being an English speaker it wasn't obvious, but all the works (also
> known as modules) descriptions are in English. Surely the descriptions
> should be in the language of the people who will use the works?
> Here's what I suggest. For any new modules or modules that are
> changed, or modules that people want to change this for:
> make a new Description in the language of the module
> rename the old conf field to Description_en
> make sure both descriptions mean the same thing ;)
> This mechanism allows descriptions to be made in other languages if
> people really want e.g. Description_de
> The Description_en is probably necessary as I guess not all frontends
> would be able to handle unicode descriptions.
> It is not a priority to change old modules but I think it would be a
> good policy for new modules.
> Another thing that would be useful is an About_en (at least from my
> point of view trying to understand the copyright details of modules).
> sword-devel mailing list
> sword-devel at crosswire.org
More information about the sword-devel