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

[Thien-Thi Nguyen]

   From: Daniel Skarda <address@hidden>
   Date: 02 Aug 2001 12:29:06 +0000

   This is another solution - to mix %read-line and read calls. But
   unfortunately this approach extracts only "top-level" comments and
   misses "nested ones".

true.  that is surely a deficiency.

   GNU xgettext for example extracts comments - it helps translators to
   understand the message - for example gettext-0.10.38/lib/getopt.c:797
   [...]

   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.

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

check out ttn-pers-scheme module `(ttn gap-buffer)' and `(ttn edit)'.
there might be an intermediate approach where you can use `read' from
w/in an editable buffer.

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

i'm glad to hear this!

   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.

that would be time well spent, since it's a guaranteed FAQ.

   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.

   ps: for more issues see me response to Neil.

time to read further along this thread....  (btw, feel free to send me a
"simplified" patch privately -- i am curious in any case.)

thi