Re: internationalization

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

Dumas Patrice wrote:

|Hi,
|
|I changed a bit the handling of internationalization.

|3 changes which (I believe) are not very questionnable:
|
|* a function is used instead of a hash. Allows for encapsulation.


Cool!

|* the keys are strings (like 'About this page') and not identifiers (like
|'About_title'). This is how gettext does and I think it helps translaters.


I agree.  Great!

|* I am starting using sprintf with %d and %s instead of string
concatenations
|such that it is easier to exchange the order of the words.


Awesome, but are you talking about something like gettext's %1, %2, %3?
Simply having a translator enter %s in their string won't allow for
changing the order of substitutions and a quick search/replace is
trivial in Perl.

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 have also added code which, in my opinion would help the maintainers in
|maintaining the translations up to date, and would help translators by
|hiding underlying code. But you might find these changes bad, thus I ask
|here before finishing the transition.
|
|In the new scheme, there is a hash in the main translations file
(T2h_i18n.pm),
|each entry corresponding with an english string. This hash should be
updated
|whenever there are new strings to be translated. I call this hash the
|reference hash.


Is the reference has necessary for purposes other than documentation?
IIRC, gettext simply uses the english "key" string if no translation is
available.  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.

| There is also one file per language, in the i18n directory,
|and each of these files only contains one (or 2) hash, which keys are the
|english strings, and values are the corresponding translated strings.


Perfect.  I think one file per language is the way to go.

|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.

|The idea behind that is that translators should only have to look at
the file
|for their language and just write down the translations. And the
|maintainers/coders should only have to update the reference hash, then
|rerun
|$./texi2html -i18n update
|
|When the translators have done their jobs,
|$./texi2html -i18n merge
|merge the files in a file, translations.pl, which is included by
|./configure into the texi2html script.


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.  If you were planning on allowing for overrides, why not allow an
installed TEXI2HTML_LIB/i18n/* file to override rather than a single
translations.pl?  I think the translations.pl file overly complicates
matters.

Derek

- --
~                *8^)

Email: [email protected]

Get CVS support at <http://ximbiot.com>!
- --
When the only tool you own is a hammer, every problem begins to resemble
a nail.

    - Abraham Maslow
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE/XKq9LD1OTBfyMaQRAhXZAKC/fR1GYpDwqabzSQ8NhvjInIrRKwCg3ZZP
q27Z2Y8Vp//mGUdsAv7tIOU=
=qs3b
-----END PGP SIGNATURE-----