[sword-devel] Proposition concerning module names

[DM Smith]

On Dec 1, 2009, at 10:25 PM, Nic Carter wrote:

> 
> Hi there DM, thanks for the reply  :)
> 
> What has been proposed (& accepted, it seems?) sounds excellent.  :)
> Sorry about bring it up again, I saw there was nothing in the API (that I could see) but forgot to check the mailing list archives  :(

It wasn't easy to find. No problem bringing it up again. Part of it is in the wiki on the conf. More could be said to make it clearer.

> 
> One thought about that, tho, is that the _en bits should probably use the 3 letter code?  Given that we now are using those in our module conf files, we should probably be using those as the suffixes as well?

Basic rule of thumb: If there is a 2 letter code use it. Otherwise use the three letter code.

> 
> TBH, though, I think we only need to have the description and about text in the localised native language -- the priority should be to always display the text in that language.  For ourselves, we can always keep additional notes in English/German/whatever as commented out text in the conf file so that we know who maintains the module & where it's from, etc, etc, as is already the case in a fair few of the locale.d conf files...  :)

I really doubt we'll encourage fully localizing even these few fields. Having them in the native tongue and English yes. (We already have English and don't want to delete it.) But the basic thought has been that if you don't speak a particular language or read a particular script, then having the description and about in the native language serves its purpose.

> 
> 
> Thanks again, ybic
> 	nic...  :)
> 
> On 02/12/2009, at 2:06 PM, DM Smith wrote:
> 
>> Nic,
>> 
>> 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.
>> 
>> In Him,
>> 	DM
>> 
>> 
>> 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!  :)
>>> 
>>> 
>>> ybic
>>> 	nic...  :)
>>> 
>>> 
>>> 
>>> <ui-new2.png><Apple-i18n.png>_______________________________________________
>>> sword-devel mailing list: sword-devel at crosswire.org
>>> http://www.crosswire.org/mailman/listinfo/sword-devel
>>> Instructions to unsubscribe/change your settings at above page
>> 
>> 
>> _______________________________________________
>> sword-devel mailing list: sword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
> 
> 
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page