[sword-devel] isalnum(3) for i18n

[DM Smith]

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:)

>
>
>> 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