Re: internationalization

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dumas Patrice wrote:

|>Perhaps we could even use %{varname} or the like in the strings to make
|>it easier for translators to read.  Passing a hash of the form <var1> =>
|><val1>, <var2> => <val2>, ... to the translation and then the
|>search/replace function is pretty straightforward in Perl as well.
|
|
|I agree that it would help, but I can't see how to do that practically.
|Imagine there is the following string
|
|"See section %s in %s"
|
|I agree that it would be nicer if it was possible to know that the first %s
|corresponds to 'section_name' and the second %s corresponds to 'book'.
Is it
|what you proposed ?
|
|If yes, do you have an idea on how to do it practically ?


~    #! perl
~    sub
~    get_message {
~        my ($key, %input_hash) = @_;
~        $key =~ s/%\{(\w+)\}/$input_hash{$1} || $&/eg;
~        return $key;
~    }

print get_message("See section %{section_name} in %{book}", section_name
=> "5.6.19", book => "A Guide to Everything");

This get_message function replaces the vars as advertised and ignores
vars between %{} which are not present in the input hash.  If you run
the above as a stand alone script, it outputs:

~    See section 5.6.19 in A Guide to Everything

The texi2html version would need some code which checked the current
language and subbed into a translation from the appropriate translation
file or $key if no translation was found, but the rest should be able to
remain essentially unchanged.

|>Is the reference has necessary for purposes other than documentation?
|>IIRC, gettext simply uses the english "key" string if no translation is
|>available.  
|
|
|This is what is done here, too.
|
|>This way the english strings would only need to be stored in
|>one location.  If you want to be able to generate "templates" for
|>translators and obsolete translations for keys which are no longer in
|>use, I'd think the keys could be stripped from the calls to the
|>translation functions fairly easily.
|
|
|I don't understand that... Do you mean that the strings should be stored
|only in the code, and the templates would be regenerated by parsing the
code
|for strings to be translated ?


Yes.  I'd have to think a bit to come up with the parser - it's possible
something simple would do but if not we might be able to leverage
existing Perl parsers.  As a quick example:

~    perl -e 'while (<>) { if (/\bget_message\s*\(.*\)/) {
s/^.*\bget_message\s*\(\s*([^),]+).*$/$1/; print; } }' texi2html.pl

would print a list of the keys, one per line, if there were no more than
one call to get_message per line, a single call to get_message never
took up more than a single line, the key strings did not contain commas
or spaces, and the declaration of get_message did not contain a prototype.

|In my scheme, there is no such thing. When
|a string is an argument to the translation function and this string isn't
|in the reference hash, a warning is echoed. I think that it is enough
|for detection of new strings. However there is nothing to detect that a
|string in the reference hash is no longer in use.


This might be the simplest way to go, but I think maintaining the keys
in a single location is the most maintainable over the long run if we
can create a usable parser.  It is certainly the most asthetically
pleasing solution.

|>|One
|>|of the hash holds the strings appearing in the reference hash. The other
|>|contains all the obsolete strings which are not in the reference hash
|>anymore.
|>|These hashes are automatically updated with
|>|$./texi2html -i18n update
|>
|>
|>Why is this part of texi2html and not the build tool or even a
|>maintainer-only script?  I don't think any functionality a user won't
|>need access to should be part of the texi2html script.
|
|
|You are right I will make it a separate script. All the real code is in
|T2h_i18n.pm anyway. I was just lazy...


Thanks.

|>Again, why not handle this in the build tool?  It should be as easy, if
|>not easier, to include i18n/* without the intermediate translations.pl
|>step.  
|
|
|I added that file because I wanted to use AC_SUBST_FILE in configure.in.
|Maybe we could use another technic ?


Ah.  Maybe.  I'm wondering if having a copy of all the strings in the
executable file is really optimal anyhow?  Few programs fail to expect
that they have been installed properly.  What if texi2html looked for
the i18n files in TEXI2HTML_LIB/i18n/* or `dirname $0`/i18n/* and
required only the ones it needed to use?

Derek

- --
~                *8^)

Email: [email protected]

Get CVS support at <http://ximbiot.com>!
- --
I am not authorized to fire substitute teachers.
I am not authorized to fire substitute teachers.
I am not authorized to fire substitute teachers...

~          - Bart Simpson on chalkboard, _The Simpsons_
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE/XPCZLD1OTBfyMaQRAvP5AJ9m5rbHNGaO1bDWATHrYPL46neQTwCdE4ZM
Em1/aIdleQ1fef/2btfpJ9k=
=9btN
-----END PGP SIGNATURE-----