[sword-devel] isalnum(3) for i18n
dmsmith555 at yahoo.com
Tue Aug 12 18:05:07 MST 2008
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
>>> 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
>> 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
> 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
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
>> the abbreviation. User could give whatever string he wanted and it
>> 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
> 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
Then it would be straight forward for all front-ends to provide the
More information about the sword-devel