[sword-devel] isalnum(3) for i18n

[Daniel Blake]

I may be missing something here, but the "Description" field was 
included so an actual description of a module could be added.  
Descriptions are very important for people to choose which modules they 
want to use/look at.  Many times the name of a module just isn't enough 
to tell people what the module is about.  Similar to the front and back 
cover of books for review before purchasing them.

Wouldn't it be better to add a field for the localized name and use the 
description field for it's intended purpose?

Daniel Blake

Daniel Owens wrote:
> DM Smith wrote:
>> On Aug 12, 2008, at 8:22 PM, Jonathan Morgan wrote:
>>
>>   
>>> On Wed, Aug 13, 2008 at 2:48 AM, Eeli Kaikkonen
>>> <eekaikko at mail.student.oulu.fi> wrote:
>>>     
>>>> On Mon, 11 Aug 2008, Chris Little wrote:
>>>>       
>>>>> 2) The module name is intended for use by developers, not  
>>>>> necessarily
>>>>> for display to users. That's why the constraint is iscsym--to
>>>>> facilitate use within code. If you want to suggest the addition of a
>>>>> short abbreviation .conf tag, that's a different matter.
>>>>>         
>>>> People seem to get used to those short abbreviations but still they  
>>>> are
>>>> not very user friendly. Actually I would like to have two extra  
>>>> tags: a
>>>> short abbreviation in the language of the module and a description in
>>>> the language of the module. In internationalized and localized
>>>> environments it's important to have both English and native language
>>>> information available. As a user and as a developer I want to see
>>>> information which I can understand even if I can't read the module.
>>>> Therefore English short description is important. But I would like to
>>>> have also a short Finnish abbreviation in Finnish modules. It's quite
>>>> stupid to for example copy a quote which have "FinPR" attached while
>>>> no-one uses that in Finnish - it's usually "KR 38" or something like
>>>> that.
>>>>       
>>> A lot of what we do happens for the convenience of developers rather
>>> than users.  This should probably change, but it's not an easy thing
>>> to change.  I think you are right that localised book names and
>>> abbreviations are appropriate.
>>>     
>>
>> I think two fields make sense. One as an alternate for [name] and one  
>> for Description=
>> It might be better to use Description for a localized name. If you  
>> can't read it, you probably cannot read the module:)
>>
>>   
> This is a very good (and important) discussion. I agree that the 
> Description field should be used for a localized name, and perhaps a 
> recommended character length should be added to the module creation 
> wiki to give module developers a better idea of how long that field 
> should be.
>
> However, not all UTF8 Description fields are readable in all 
> front-ends, though off the top of my head this only really affects 
> BibleCS. It would be fantastic if all front-ends supported UTF8 
> Descriptions AND used the Description field for the selection of 
> modules by the user. BPBible is a hybrid of the abbreviation and the 
> Description. In any case, the display of a module for selection ought 
> to be in a form that the end-user can recognize immediately.
>>>     
>>>> It has occurred to my mind that a frontend could offer a UI for  
>>>> giving
>>>> the abbreviation. User could give whatever string he wanted and it  
>>>> could
>>>> be used in module lists and in other places. It would of course be
>>>> stored separately, not in the module conf.
>>>>       
>>> I don't necessarily mind that as an extra, but the problems with it  
>>> are:
>>> 1. Most users won't want to do it.  As much as possible it should be a
>>> thing that just works, which means a good, localised name and
>>> abbreviation should come with the module.
>>> 2. It is unlikely to be supported by other applications, meaning you
>>> have to do it on a per application basis or not bother.
>>>     
>>
>> IMHO, It would be good for the engine to give write capabilities to a  
>> conf, with critical fields being write protected (at least with a  
>> warning.)
>>
>> Then it would be straight forward for all front-ends to provide the  
>> ability.
>>
>> In Him,
>> 	DM
>>