[sword-devel] isalnum(3) for i18n

Daniel Blake danblake at tcdr.com
Wed Aug 13 16:57:46 MST 2008

Thanks Daniel the "About" field was what I was missing :-)

Your thought about "Title" and "Author" fields seem good to me.

Instead of separate fields for each language, I think just localizing 
"Description" or maybe a different field would be a more elegant 
sustainable solution.

Daniel Blake

Daniel Owens wrote:
> I may be missing something too :), but in my experience the "About" 
> field is the more verbose field which helps people choose modules they 
> want to use (from the wiki: "A lengthier description and may include 
> copyright, source, etc. information, possibly duplicating information 
> in other elements."). The "About" functions much more like back cover 
> or flap copy that you read to find out more.
> It does seem that the two terms are easily confused and overlapping in 
> meaning. Perhaps instead of "Description" it should be called "Title" 
> or "ModuleTitle" or something like that. After all, the wiki defines 
> the "Description" as "a short (1 line) title of the module." Why not 
> have the "Title" field and then an "Author" field. I mean, if you have 
> more than just Bibles then authors become an important piece of 
> information. Just a thought.
> Daniel
> Daniel Blake wrote:
>> 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
>> _______________________________________________
>> 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
> -- 
> PMBX license 1502 
> ------------------------------------------------------------------------
> _______________________________________________
> 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

More information about the sword-devel mailing list