First I'm sorry of your misunderstanding of what I meant. It's surely
because of English is not my native language, nor C++ :-)
On Wed, 19 Jan 2000, Gilles Detillieux wrote:
> According to Jerome ALET:
> > this should be done with a special class (I suppose it's the correct term)
> > and with one instance of this particular class for each country (maybe we
>
> Wouldn't that mean changing the C++ code whenever you want to add support
> for another country? In my opinion, that would definitely not be an
> improvement.
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.
> > can fill each with text configuration files at runtime ala locale) and
>
> Well, if you can give us some pointers as to how we'd get this information
> from the locale,
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).
- or create country specific files (or directories) in the same
way as the locale database is constructed, but let them in the htdig home.
> 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.
> 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.
> In other words, this approach is consistent with what we've done so
> far. We already have a large number of config attributes, so one more
> doesn't hurt. If you want to have all the language specific attributes
> in separate configuration files, you can do that now, and just include
> the one you want in the main file. E.g.: "include: francais.conf"
I'm sorry, I didn't know it existed.
> If we can get all this stuff reliably into locales, then that may be
> a good approach, but given all the problems users have had with broken
> locales on various systems, I'm not convinced this is the way to go.
this should be the way to go, but only with improved locale.
> 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.
bye,
Jerome
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED]
You will receive a message to confirm this.
