[sword-devel] Adding abbreviated names to the module conf file (was Re: isalnum(3) for i18n)

[Eeli Kaikkonen]

Quoting Chris Little <chrislit at crosswire.org>:

>
> Okay. While I find the arguments in favor of localizing all string
> fields in .confs entirely unconvincing, it doesn't drastically harm
> anything to permit module makers to add more data to their .conf files.

That's true.

>
> So I think we can go with the suggestion of suffixing localized string
> values in .confs with _ plus a locale (which would generally mean a BCP
> 47 value, but we may have to alter that based on the constraints on
> attribute names in .confs). If we add Abbr, Author, Translator, &
> Publisher fields, the complete list of localizable attributes would be:
>
> Abbr, Author, Translator, Publisher,
> About, Description, History_x.x,
> Copyright, CopyrightHolder, CopyrightNotes, CopyrightContactName,
> CopyrightContactNotes, CopyrightContactAddress, ShortPromo,
> ShortCopyright, DistributionNotes

Looks great.

> In the absence of a localized form, the un-suffixed version will always
> be default. In general, the title-like attributes will be according to
> the actual title of the book, generally in the language of the text.
> Names of people/organizations will generally be language-neutral. The
> rest will generally be language-neutral or in English.
>

The next thing is to decide how exactly the localizations are to be
get for the frontend. Is it the same as with key names so that it's
set once and then the keys (or in this case, text fields) come
localized?

Would it be possible to set a secondary language, so that I can see
the Finnish text if it exists, then the English text if it exists and
only after that the "native" language text? I know this sounds a bit
exaggerated, but we should never underestimate the needs of the users.
For example, someone Finnish who also speaks English has friends from
different countries who have another native   language with non-latin
alphabet but who speak English, too. They ask the Finnish one if
there's a X (name in English) Bible translation for their native langue in the
Crosswire repository. The Finnish opens the list and tries to find
out. Then the text must be in English - otherwise the Finnish who can
read only latin alphabet can't find it.

I know this may be a bit far-fetched. But I want to point out, again,  
that there certainly are use cases which are not obvious, and limiting  
the possibilities will make things complicated later.


> That said, nothing will *work* unless someone writes the code to take
> advantage of it.

I'm happy to take advantage of it. But this must be well and  
unambiguously documented for module developers and frontend  
developers. Reading the Sword library source code is not what I mean  
here.

>
> I suspected there would be disagreement with my suggested number, but I
> had assumed that it would seem too low. So... some of my reasoning:
>
> Many Bibles will include a year, which eats up 4 characters in itself.
> Bibles with standard abbreviations aren't a big issue (WEB, NIV, NASB,
> NRSV, etc.) but many others incorporate a translator/place/organization
> name--which can be longish (Elberfelder, Webster, Grünewald, Rotherham,
> Delitzsch, Tischendorf, Cornilescu, etc.)
>
> So, we could make the limit lower, but I worry that we would limit the
> meaningfulness of these strings. Maybe we could cut it down to 12?:
> xxxxxxxxxxxx

I, too, am against strict size limits. There are already modules with  
long names, if not in the main repository, then in the Kleinpaste's  
repository (ftp://ftp.kleinpaste.org/pub/sword/mods.d/), and therefore  
longer than 6 char names don't create any new problem for frontends.  
The screen real estate is of course a problem with all frontends but  
it's not a reason to limit the names to something unusable. 12 may be  
good, 6 is far too short. And it should be a soft limit, not hard, as  
Chris has already pointed out elsewhere.

--Eeli Kaikkonen