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 :(
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?
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... :)
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@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@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@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
