Re: internationalization

> |This seems pretty right. I will do that soon. I believe that
> |get_message('See section %section_name in %book', { 'section_name'
> | => "5.6.19", 'book' => "A Guide to Everything")
> |will be even more practical, as only % has to be escaped.
> 
> Except that you've now excluded constructs such as %{section_name}word.
> %section_nameword would specify a new variable to the parser.

That's right.
 
> Regardless, % doesn't really need to be escaped, and neither does `{' or
> `}'.  Even if these appear together or with words in the middle, they
> will only be substituted by the above code if they mention one of the
> hash keys passed in.  i.e. %{}, %{{{{{{}, %{something_undefined}, and so
> on would all be treated as literals by the code above.  The only
> constructs a user could not get at would be ones where the variable was
> defined (the user could not pass through a literal `%{section_name}' and
> we would have to allow an escape for that case in either situation.

I think that nevertheless it would be simpler if %% escaped a percent
sign. Thus to pass a litteral %{section_name}, %%{section_name}
should be passed. And to pass %%{section_name} -> %the_name, %%%{section_name}
would work. Still {} don't need to be handled especially, you are right, as
it would only make sens after a % and would only be replaced if the key 
is found.

> I was thinking about something along these lines too.  I hadn't decided
> yet that it was reasonable to exclude variables (i.e. require only
> quoted strings there) from the first argument to get_message, but it
> sounds right.

If we accept variables, it will be quite impossibe to find out the strings 
anyway.

> The last figure I heard for a count of spoken languages in the world was
> over 9000, but I don't recall where I heard it.  I think the number of
> written languages is smaller.
> <http://www.unicode.org/onlinedat/languages.html> lists c. 162 languages
> with ISO codes and another 16 that have windows or macintosh codes and
> no ISO code.

That doesn't make too much for now.

> |Maybe we could keep on merging everything in the script until there are
> |too much languages used, but I don't think this will happen soon.
> 
> 
> This is true.  It does require a translator, but I was thinking that
> installed as I mentioned, a user could override the translations or
> provide new ones simply by adding or replacing files in
> TEXI2HTML_LIB/i18n/* or `dirname $0`/i18n/*.  Perhaps a combination of
> the methods would be in order?  If a file can be found in the above
> dirs, source it and allow its contents to override the internal variables?

I agree that it is indeed a good idea, but not to override translations.
To override translations, it would be easier for a user to use the existing 
mechanisms, that is put his new hash in /etc/texi2htmlrc or ~/.texi2htmlrc.

However I agree that it makes sense to source files conditionnaly on a 
language. In that case, if a user wants to do different formatting based
on the languages he will be able to do so. I think that Karl Heinz Marbraise 
proposed something along that in his IDEAS file. In fact I think that the user
should put in this file everything that is not translated strings because
translated strings are allready taken into account. Of course your point about
efficiency still holds, that is the user could put relevant translations in 
the i18n files only to avoid having a too big  /etc/texi2htmlrc or 
~/.texi2htmlrc with all the translations.

The conclusion is that I agree with you, we should source users files (in the 
same way we find init files).

Pat