Re: internationalization

> I don't think that I have any objection to moving i18n strings to the
> config namespace, though perhaps the user and site config could be moved
> into ~/.texi2html/conf and /etc/texi2html/conf and handling added for
> ~/.texi2html/i18n and /etc/texi2html/i18n directories for the
> translation overrides?  That should answer the efficiency and clutter
> issues.  Most of the code that sources the installed i18n/* files should
> be reusable in config then as well.
> 
> ~/.texi2htmlrc and /etc/texi2htmlrc could be continued to be sourced for
> a few releases with deprecation warnings.

Hum. This seems like to me another discussion. You propose using 
~/.texi2html/conf instead of ~/.texi2htmlrc and /etc/texi2html/conf 
instead of /etc/texi2htmlrc.

This could make sense regardlee of i18n, as init files are searched
in ~/.texi2html/ and /etc/texi2html/. Is it what you mean ?

Whatever we choose for that, I think that it is worth having i18n directory
with file sourced according to the language.

> I'm not sure about this, as long as the file isn't installed.  The
> script does not need to source the `en' file to determine english
> strings and thus I think no `en' file should be installed by default.

Hum. In its actual form the code uses the english strings. That's
because a warning is emitted when a string is marked as a candidate
for internationalization, but no entry exists in the en strings. This
acts as a remainder to rerun manage_i18n.pl to regenerate the strings 
and update the other languages files.

> The `i18n/template' in the source distribution would hopefully jump out
> at contributors as a starting point for translations.  If we were to

In the current code things don't really happen like that. If somebody
wants to add a language, say 'ln', he adds it to the list (@known_languages) 
at the beginning of manage_i18n.pl, and run manage_i18n with
./manage_i18n.pl update ln
This will create the i18n/ln file with all the entries found in template.
(./manage_i18n.pl update will do it too, and so will ./manage_i18n.pl all
but it will do more).

> install a file for english "translations", i.e. one that allowed an
> installer to change the english text, then that should definately be
> called `en', however.

This is allready like that, the user can override the english strings.
And if there are "translations" in english in the default they are specified 
in the $template_strings hash in manage_i18n.pl (along with strings which
should be translated but don't appear in the code, currently the month names).

My conclusion is that with the current code we should call it 'en' instead 
of 'template', as it may be used for translations and needs to be included. 
However if the current code isn't satisfactory, we could call it template.

Pat