From: Tom Tromey <tromey@redhat.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFA: start of i18n
Date: Fri, 21 Jun 2002 13:13:00 -0000 [thread overview]
Message-ID: <87d6uktm2y.fsf@fleche.redhat.com> (raw)
In-Reply-To: <3D137942.4070807@cygnus.com>
Andrew> I suspect GDB is going to have some fun with ui-out. Some
Andrew> messages are not contigious strings but rather a concatenation
Andrew> of several strings.
Yeah, that could hurt.
Andrew> Should the primary catalogue even be kept in CVS (at least on
Andrew> the trunk)?
It depends. It is in bfd (etc) because, back in the day, I put
gettext into maintainer-tools (a Cygnus internal thing for those who
don't know), and the policy was that you didn't need maintainer-tools
to do an ordinary build. That decision lives on in the rest of the
src tree. Doing it that way is definitely easiest. It doesn't seem
notably difficult.
Andrew> Hmm, how do things handle a situtation where the primary
Andrew> catalogue gets changed but not the translated catalogs?
You just ignore it. When you upload a new primary catalog to the
translation site, the translation teams get email. Then they use
their tools (which are also part of gettext) to merge the new
translations. I think these tools also help you find out which
translations changed just a little (e.g. if a typo is fixed in English
it requires a minor change in the translated version) or were removed.
gettext always falls back to whatever is in the source (English) if it
can't find a given translation. So shipping an incomplete .po file is
not fatal; this happens all the time in fact.
This is why Gnome has a string freeze before release. It lets the
active translation teams ensure 100% coverage, by having some time for
the upload/translate/download cycle of translation. Whether gdb will
need this is hard to say in advance.
Andrew> Given that GDB is interactive it is likely going to see more
Andrew> string changes then say BINUTILS or GCC.
gcc error messages seem to churn constantly :-).
But, yeah, I'd expect even more in gdb land.
Anyway, back to the patch: it is pretty short and I think
uncontroversial. It seems unlikely to break the build, given that
very similar code is already littered throughout the src tree.
Could someone approve it in its entirety?
Tom
next prev parent reply other threads:[~2002-06-21 20:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-21 10:10 Tom Tromey
2002-06-21 10:22 ` Andrew Cagney
2002-06-21 10:49 ` Tom Tromey
2002-06-21 12:06 ` Andrew Cagney
2002-06-21 13:13 ` Tom Tromey [this message]
2002-06-22 2:47 ` Eli Zaretskii
2002-06-22 8:51 ` Andrew Cagney
2002-06-22 10:25 ` Eli Zaretskii
2002-06-26 20:15 ` Andrew Cagney
2002-06-21 10:46 ` Elena Zannoni
2002-06-21 10:50 ` Tom Tromey
2002-06-21 15:13 ` Andrew Cagney
2002-06-21 15:57 ` Tom Tromey
2002-06-21 16:13 ` Andrew Cagney
2002-06-21 16:45 ` Tom Tromey
2002-06-22 15:24 ` [patch] Update selftest.exp; Was: " Andrew Cagney
2002-06-22 18:13 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d6uktm2y.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=ac131313@cygnus.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox