[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,
"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
- Re: [patch] i18n, l10n, gettext and something more, Thien-Thi Nguyen, 2001/08/01
- Re: [patch] i18n, l10n, gettext and something more, Daniel Skarda, 2001/08/01
- Re: [patch] i18n, l10n, gettext and something more, Marius Vollmer, 2001/08/01
- Re: [patch] i18n, l10n, gettext and something more, Daniel Skarda, 2001/08/02
- Re: [patch] i18n, l10n, gettext and something more, Neil Jerram, 2001/08/01
- Re: [patch] i18n, l10n, gettext and something more, Daniel Skarda, 2001/08/02
- Re: [patch] i18n, l10n, gettext and something more,
Neil Jerram <=
- Re: [patch] i18n, l10n, gettext and something more, Marius Vollmer, 2001/08/02
- Re: [patch] i18n, l10n, gettext and something more, Daniel Skarda, 2001/08/04
- Re: [patch] i18n, l10n, gettext and something more, Marius Vollmer, 2001/08/01