[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Neil Jerram
Subject: Re: [patch] i18n, l10n, gettext and something more
Date: 02 Aug 2001 19:54:19 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

>>>>> "Daniel" == Daniel Skarda <address@hidden> writes:

    Daniel> 1) it does not record exact position of strings
    >>  Out of interest, what does source-properties record?  Is it
    >> just the beginning of each parenthesized expression?

    Daniel>   It seems so (unfortunately it can happen that string
    Daniel> does not start on the same line as "parent" expression)

Perhaps in future it will be nice to implement source properties using
`make-object-property', then anything that is distinguishable by `eq?'
can have source properties.  (This includes all strings, but
unfortunately excludes multiple occurrences of the same numbers,
symbols, #t and #f ...)

    Daniel> 2) it always interprets escape sequences (even thought
    Daniel> when you do not want to)
    >>  When do you not want it to?

    Daniel>   I my opinion extracted strings should look same in .po
    Daniel> files and .scm files.  When there is \t inside string in
    Daniel> .scm, there should be \t in .po file and not " " (and vice
    Daniel> versa) unless user turns on --escape (escape every
    Daniel> `suspicious' character :)
I see - good point.  But I wonder if I better way of achieving this
would be a print option to say whether or not to escape control
characters in the output (possibly on a per-character basis)?

This approach would never be able to preserve the difference between
an implicit and explicit newline in, say,


but do you need to preserve even this difference?

    Daniel> 3) it discards comments (surprising, is not it? :-)
    >>  Why do you need to translate strings in comments?

    Daniel>   I do not need to translate strings from comments - I
    Daniel> want to extract comments (or xgettext options) to help
    Daniel> translators in their work.

Thanks again for explaining.  Since a comment should, by definition,
never be returned from `read', perhaps we could make comment text
available through a `comment-text-hook' in the reader?

    Daniel> It was very entertaining to extend guile in this way. I
    Daniel> have to admit that in one moment I had to say "stop" (I
    Daniel> caught myself playing with idea about writing parser for C
    Daniel> or Perl like language... it is a shame I have not enough
    Daniel> spare time (or sponsor :))
    >>  Perhaps not; we already have ctax to embarass us.  And Thomas
    >> Bushnell is already working on Python.

    Daniel>   I like it just because of fun of coding (and maybe I
    Daniel> would like to work on some other language when
    Daniel> infrastructure for adding new parsers to guile settles
    Daniel> down).

Yes; sorry for being negative.  I hope that Thomas's work will help us
to make the translator framework more concrete.

    Daniel>   BTW - what's the ctax status (I have not seen stable
    Daniel> release for months) - who maintains the package?

No idea, I'm afraid; I'm not sure that it is maintained at all.

    Daniel> call (array [c = getc ()], c, port)
    >>  I think it would.  The biggest current Guile performance
    >> problem is startup time on older machines, and this would be
    >> right there in the inner loop!
    Daniel> [snip]
    >> In my non-maintainerly opinion... Scheme code maybe, but C
    >> changes definitely not; the performance impact of your proposed
    >> reader changes is just too great (or at least too uncertain at
    >> this point).

    Daniel>   As soon as guile gets VM and the ability to load/compile
    Daniel> bytecode, 'read' performance is not going to affect
    Daniel> startup time anymore. That's from longterm point of view.

    Daniel>   And what about performance of 1.6 reader? I have not
    Daniel> implemented all improvements I suggested and it would be
    Daniel> surprising for me if enhanced read function would be
    Daniel> noticeably slower. (array [int] != SCM_BOOL_F) lookup is
    Daniel> done only once per "starting character" of reader's "atom"
    Daniel> so this should not degrade reader performance ("starting
    Daniel> character" means #\" #\; for strings (or comments) etc...)

    Daniel>   Though one should run some serious tests to be sure...

Yes, perhaps I'm excessively worried about this.  Testing is, as you
say, the only way to be sure.

    Daniel> ps: Language parsers are also related to new module
    Daniel> system. Does it still have "waiting for Goddot" status or
    Daniel> somebody is working on it? I remember Jost Boekemeier was
    Daniel> working on it, I noticed "libguile/environment.[ch]" but I
    Daniel> could not find any code that uses it (maybe I am wrong).

I would say that it is evolving gradually from what we have already.
E.g. a recent enhancement now supports renaming of variables upon
import, and we've clarified the difference between export and

You're right about environments.[ch]; I don't know what the plan is
for making use of this.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]