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 "translations"
of these into English. When presented to a user it can be translated, but
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 field ModuleName
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 defined pattern.
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:-)
* Category
* Language
* GlossaryFrom
* GlossaryTo
* MinimumVersion
The rest are visible only to software and have no need of it.
* DataPath (if you want to call a path a pattern)
* ModDrv
* SourceType
* BlockType
* CompressType
* Direction
* Encoding
* BlockCount
* InstallSize
* OSISqToTick
* CipherKey
c) Some fields can be repeated but the values are among a fixed list/defined pattern.
These are presented to the user and should be I18N/L10N.
* GlobalOptionsFilter
* Feature
d) Other fields have values that are not fixed but are specific.
* Font
* CipherKey3) There are fields that are not used by software but are presented to the user:
a) Fields whose values are fixed list of values or fixed patterns:
* SwordVersionDate
* Version
* DistributionLicense
b) Some fields can be repeated but the values are among a fixed list/defined pattern.
* 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 I18N/L10N.
* Description
* About
* ShortPromo
* ShortCopyright
* DistributionNotes
* DistributionSource
* Copyright
* CopyrightDate
* CopyrightHolder
* CopyrightContactName
* CopyrightContactAddress
* CopyrightContactEmail
* CopyrightNotes
* TextSource
Daniel Glassey wrote:
Hi,
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).
Regards, Daniel _______________________________________________ sword-devel mailing list sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel
_______________________________________________ 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
