Re: [patch] i18n, l10n, gettext and something more

[Daniel Skarda]

> have you looked at scripts/read-scheme-source?  it also handles comments
> and records "source position".  perhaps there is some factoring
> potential here.  (see also ttn-pers-scheme/bin/snarf-docs which uses
> this module.)

 This is another solution - to mix %read-line and read calls. But unfortunately
this approach extracts only "top-level" comments and misses "nested ones". GNU
xgettext for example extracts comments - it helps translators to understand the
message - for example gettext-0.10.38/lib/getopt.c:797

        /* 1003.2 specifies the format of this message.  */
        fprintf (stderr, _("%s: illegal option -- %c\n"),
                 argv[0], c);

 and corresponding .po item:

        #. 1003.2 specifies the format of this message.
        #: lib/getopt.c:831 lib/getopt.c:961
        #, c-format
        msgid "%s: option requires an argument -- %c\n"
        msgstr ""

 Also comments can carry some additional options for gettext 

        /* xgettext: c-format */

 and so on. I tried to mimic this feature - unfortunately read-scheme-sources
would be useless because almost all such comments are not top-level.

>       - Second improvement is stolen (oops! ^H^H^H^H^H^H :) borrowed
>       from TeX - introduce something like catcodes.
> 
> i believe this is akin to emacs "syntax tables", q.v.

 Yep (every day I learn something new about emacs - it seems:) - but emacs uses
it for text buffers and there is no effect on 'read' function. However I would
like to experiment and use it to modify read function (as in TeX)
 
>      * (post 1.6 ?) localize all messages in libguile/*.c and
>        ice-9/*.scm
> 
> i think there is some implicit dependency on regularizing error messages
> (in english) in the first place.  to me this indicates the work should
> go into 1.8.

 L10n of all messages is going to be tedious work...

>      * Even thought I tried really hard to release polished code, it is
>        possible that I left many rough/untested/buggy lines in my code.
>        Please let me know if something does not work for you.
> 
> probably best way to convince yourself (and everyone else) of the
> quality of the code is to write some torturous tests to add to the
> test-suite/tests directory.  

 scripts/xgettext is able to extract translatable strings from itself (and I
tried to verify all arguments etc) but I can not swear there is no hidden beast
waiting somewhere - some obscure combination I have not dream about not even in
my wildest dreams :)

> also, documentation is a good way to
> introduce^Wfind discrepencies...

 All functions from (i18n gettext) module are documented (copied from gettext
manual pages) and all scripts/xgettext options are described in --help call.

 I am not sure about some i18n introduction, but in my opinion for scheme users
GNU gettext documentation is very good place to start - there are only few
differences between C and SCM i18n (you write (_ "translatable string") instead
of _("translatable string") :-)

 But I think I should write one or two paragraphs about how to coordinate/
merge extraction from scheme and C/C++ sources.

> i've looked at the tarball contents and now my gray-haired side says,
> maybe 1.8 is the best place for this.  by then, we will have had time to
> develop proper tests/docs, hammer out parser modularization issues, and
> take care of paperwork (which may already be done, if so, i stand
> corrected).

 I think that (i18n gettext) module (bindings for C functions from GNU gettext
library) can/should go into 1.6 release. It does not/can not break anything and
1.8 is too far away and inclusion of gettext bindings would allow scheme users
to i18n their projects now.

 As for scripts/xgettext - it utilises read extensions, because I think that:

  * extracted strings in .PO file should look like strings in .scm sources - so
    if there is \t in .scm file there should be \t in .po file and not "       
".

  * .po translators should be informed about exact string position

  * it is nice to extract comments and xgettext options from scheme source
    file.

 If changes in 'read' function are unacceptable for other developers, there is
another solution...

  Add simplified xgettext script to 1.6 (and to 1.7 branch fully featured
  version) that uses unmodified 'read' - it would interpret escape sequences and
  would not extract exact position neither comments/options.  Because this
  script is needed only be developers, there can be some notice that for more
  featured/comfortable string extraction they should use xgettext script from
  1.7 branch.

 ... and more 'read' enhancements could be 1.8 business. Also note that xgettext
is independent on other 'read' enhancements I suggested (modularisation,
catcodes) - they were part of (i18n gettext) announcements because there ideas
stroke me during work on xgettext and (i18n gettext) module.

0.

ps: for more issues see me response to Neil.