According to Jerome ALET:
> First I'm sorry of your misunderstanding of what I meant. It's surely
> because of English is not my native language, nor C++ :-)
...
> I wrote another instance of this class for each country, not another
> class. So creating a new instance of this class for each country can be
> done without changing any code, e.g. reading each file in a directory
> which contains all the country specific files and creating a new instance
> for each countryfile read.
Yes, your terminology was correct, and it was I that misunderstood.
Part of the reason for my misunderstanding is that it didn't make sense
to me to have multiple instances of this proposed class, because in a
given run of htsearch, you're only going to output the wrapper template
and search for in a single language, so there's really only one instance
of a class that is configured by a configuration file.
So, we're left with the choices of where this configuration file should
be, and what format it should take. You'd like to see it as part of
the locale support, presumably as in an NLS-style LC_MESSAGES file.
My preference would be as a file of ht://Dig configuration attributes,
for the reasons I've stated earlier.
> I already know the information we want is not present in the locale, so we
> can't use it for now, but I think we should either:
>
> - improve the global locale support (independently of htdig) to
> include what we, and certainely others, want. The benefit would be great
> for everyone whose native language is not English (if it would be used by
> application developpers of course).
That's a worthy goal, but I don't know of anyone on the list who'd be
willing to take up that project. It would also mean that anyone who'd
want to reap the benefits of this work would need to upgrade the locale
support on their system to use the new code. That may happen over time,
if these improvements make there way into popular OS distributions, but
judging by the comments I've seen in the past year on the htdig mailing
lists, many (most) htdig users can't or would rather not have to start
upgrading system libraries.
> - or create country specific files (or directories) in the same
> way as the locale database is constructed, but let them in the htdig home.
Yes, and I think the most painless way to do this is through the existing
config attribute mechanism. There are already many language-related
attributes, and I've proposed a few more in the past few months, including
one to overcome a problem with broken locales on many systems, and one to
configure a general accent fuzzy matching algorithm that's been discussed.
Of course, it would make sense to group all language-specific settings
into a configuration file for that language, and to provide samples of
these files for many languages as part of the ht://Dig distribution.
That's where we'll need contributions from our friends overseas.
> > I'm sure someone would be willing to code it. Whatever
> > solution we pick, though, it MUST be run-time configurable.
>
> Did I wrote I disagree ? I don't think so
> OF COURSE it MUST be run-time configurable and NOT compile-time
> configurable.
No, I simply misunderstood.
> > Apart from that, the
> > only English messages hardcoded in htsearch is a few error message that
> > should only pop up when there are configuration problems.
>
> you're right. IMHO these messages should remain in English to avoid
> problems when understanding what is wrong when helping other people.
The main reason they're not configurable is that they may occur when
there's no valid configuration file to be found, so they must be builtin.
There may be good reason to make some of them configurable, though, for
the cases where the configuration file has already been loaded (e.g. the
database-related errors). However, none of these errors show up in normal
use, on a properly set-up system.
...
> > Indeed, the most frequent problems involving internationalisation
> > in htdig/htsearch have been 1) confusion about how to configure it, 2)
> > broken locale implementations, 3) lack of an accent fuzzy match algorithm,
> > 4) lack of support for 16-bit characters. Locales don't solve any of
> > these problems, and from my experience have aggravated the first two.
>
> maybe they have aggravated problems instead of solving them, nevertheless
> what we want should be included in the locales database, I mean in an
> ideal world.
>
> I hope you better understand what I meant now.
Yes, but unfortunately our world is far from ideal, and proper
internationalisation of ht://Dig is to important to make it wait for
an ideal and widely available implementation of locales. Also, if we
move to the Unicode character set, as has been proposed, to handle all
characters and encodings that the HTML standard allows, then I don't
think we'll be able any longer to tie the parsing of pages to the indexing
system's locale.
We also can't ignore all the grief locales have caused in the past.
Search for "locale" on www.htdig.org if you have any doubts about
this point. For these reasons, I think moving away from locales to
something else, preferably part of ht://Dig itself or at least something
OS-independent, makes a lot of sense.
--
Gilles R. Detillieux E-mail: <[EMAIL PROTECTED]>
Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/~grdetil
Dept. Physiology, U. of Manitoba Phone: (204)789-3766
Winnipeg, MB R3E 3J7 (Canada) Fax: (204)789-3930
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED]
You will receive a message to confirm this.
