Quoting Chris Little <chris...@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
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
