guile-devel
[Top][All Lists]
Advanced

[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,

"hello\nbig
world"

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

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

        Neil




reply via email to

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