[sword-devel] Proposition concerning module names
dmsmith at crosswire.org
Tue Dec 1 20:06:13 MST 2009
Regarding names, there are two things that can be called the module's "name".
1) The text between the [initials] on the first line.
2) Description=title -- the actual name of the work.
While there is no current support in SWORD, we have agreed that any field can be suffixed with a language code as in Description_fa.
We have also agreed that a field without a language code should be the localized, native language, otherwise English.
And when it is the localized field then there should be a *_en field.
A few module have this.
In the same thread (December 16, 2008), Chris proposed another new field Abbr that would hold the localized very short name of the module, much like the [name], but it would not have the alphanum restrictions.
We didn't discuss dialects, but it would be represented by the two letter uppercase country code. Not sure whether it would be prefixed by a - or a _ (e.g. en-GB or en_GB).
Again, there is no support in SWORD for anything but the fields that don't have a language code. And no support for Abbr.
On Dec 1, 2009, at 9:23 PM, Nic Carter wrote:
> Hi all. :)
> Given I'm an English speaker & I can only speak and read English, this may seem like a strange proposition, but . . . :)
> As I'm going through the i18n process for PocketSword I'm eliminating everything that is in English, with my priority being traditional chinese (I used to live in HK!). I'm now looking at the module names. I've attached a screenshot to try to explain the problem I've run into:
> There's a button that says KJV on it, telling the user which Bible translation they're currently viewing (and providing a button to press to change the translation), but if I switch to the zh_TW UI, everything switches to chinese, but no matter what I do using the native SWORD API, the module name is the module name & that's in English.
> Do other front-ends translate / localise the module names, so that they display the module names in their native language? It seems rather silly to me that we require the front-end developers to localise their front end to display the correct module names... I realise that a fair few of the developers here can't read chinese and other languages, but for the people who CAN read chinese (and other languages), it makes more sense to display the name of the module in the native language of the module than it does to display the name in English.
> Let me give an example of it done that way: When you switch localisation on the iPhone, Apple have a screen (attached) that shows the different languages. I can figure out what some of them are (traditional vs simplified chinese, for example, I can only figure out cause I used to live in HK) but have no idea for others (it's a long list, scrolling down shows some I'm unfamiliar with). This works great because you only want to switch to languages you can read! :) It makes it more difficult for people like me, when I want to test i18n of PocketSword, but I have to deal with it and ultimately the end user is the one who benefits from that :)
> Anyway, my suggestion is this:
> We keep the module name as it is, in English, ASCII (so it will still work in any front-end, no matter the character encoding restrictions of the platform), but add a new property to the .conf (something like LocalisedName) -- the translation of the module name in the native language of the module. It would keep the name in the shortened version and my second suggestion is that we add a 2nd property (something like LocalisedDescription) which is the module description, but in the native language of the module.
> [oh, hang on, SWORD uses American English, rather than UK/Australian English, so it should be "Localized" to match the spelling we use in the API!]
> This would then be open to discussion as to what to do for the "dead" languages, such as Latin, but what if a German scholar wants to read the Vulgate? Actually, we could probably assume a German scholar who knows Latin would probably know English as well! But, this is where I place this on the table for discussion and see what others have to say about everything I've said. :)
> Thanks for reading this far, if you made it! :)
> nic... :)
> sword-devel mailing list: sword-devel at crosswire.org
> Instructions to unsubscribe/change your settings at above page
More information about the sword-devel