I would like to suggest that we *consider* the *design* of Java's mechanism for Internationalization and Localization, called ResourceBundles. (The implementation details are not important)
Here is a simplification:
A resource bundle consists of (key,value) pairs in files of a predefined extension.
The name of the resource bundle is of the form name.ext, name_lang.ext or name_lang_locale.ext.
Name.ext is regarded as the default resource bundle. All others are variants.
Given a user's language and locale a key is looked up in the following fashion:
Look first for name_lang_locale.ext for the key's value.
Failing that look in name_lang.ext for the key's value.
Failing that look in name.ext for the key's value.
Failing that report an error.
(In practice, a user's lang/locale determines the possible set of files and these are merged in core into a single representation)
I don't know if we need to go to the level of localization, but we should define the mechanism. Perhaps, Australian English and American English are different enough to warrant separate files. (In one job I did, this was the case!)
The practical implications of this is that a translation is only done on the keys that are needed. These are held in separate files. (We could also use directories rather than suffixes to hold the lang and locale info.) This means that the values that software needs to do its job are held in the default file. If software wants to use the other info it can, but it won't need to even look at it otherwise.
The nice thing about the proposal above, is that it does not require that one language (e.g. English) and locale (e.g. UK) be the default.
Since the majority of the translatable info is related to copyright, we may need to consider what language is used as the default. It may be possible that the publisher provides specific text and it differs from the vernacular of the text.
(By the way, it is no advantage to JSword if this mechanism is used. The conf's are significantly different from Java's property files that we will have to write our own lookup routines)
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
