[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