[sword-devel] language of module descriptions

[DM Smith]

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
          * CipherKey

3) 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 at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
>