From: Daniel Jacobowitz <drow@false.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: ibr@ata.cs.hun.edu.tr, gdb-patches@sources.redhat.com
Subject: Re: an i18n sample
Date: Tue, 26 Oct 2004 20:02:00 -0000 [thread overview]
Message-ID: <20041026200155.GA29170@nevyn.them.org> (raw)
In-Reply-To: <01c4bb16$Blat.v2.2.2$57f587c0@zahav.net.il>
On Tue, Oct 26, 2004 at 06:42:28AM +0200, Eli Zaretskii wrote:
> > Date: Mon, 25 Oct 2004 16:20:52 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: ibr@ata.cs.hun.edu.tr, gdb-patches@sources.redhat.com
> >
> > Sorry, my wording was not clear; I understood your suggestion. I still
> > disagree with it. I think that a type whose name is "<unnamed>" or
> > _("<unnamed>") should recieve the same output as a type whose TYPE_NAME
> > is NULL.
>
> I don't understand what you mean by "should receive the same output".
> Can you explain?
I mean that I believe the string that GDB displays to the user for
these two cases, i.e. an unnamed type or a type whose name is set to
<unnamed>, should always be the same. I don't see much point in
moving maintenance of that ideal to the translators, but you know more
about this than I do :-)
> > A format string is a different sort of problem than a partial sentence.
> > It's a complete grammatical construct, but we have to take what steps
> > we can to make sure that the parts that get substituted in make sense
> > in any language.
>
> Given a string "<unnamed>", how would a translator know that it is
> supposed to be a substitution for %s in the format string? The only
> way to know that is to read the source, which a translator normally
> does not do. Without knowing the context of "<unnamed>", the
> translator is unlikely to find a good translation for it.
That's true. But it expresses a concept - an object without a name.
Would "<unnamed type>" be better?
I think I understand what your objection was, now. I had
completely failed to get your point; so my kibitzing is withdrawn.
I thought you were calling the format string a partial sentence.
--
Daniel Jacobowitz
next prev parent reply other threads:[~2004-10-26 20:02 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-24 10:45 Baurjan Ismagulov
2004-10-24 19:28 ` Eli Zaretskii
2004-10-24 19:57 ` Baurjan Ismagulov
2004-10-24 20:18 ` Daniel Jacobowitz
2004-10-25 20:10 ` Eli Zaretskii
2004-10-25 20:20 ` Daniel Jacobowitz
2004-10-26 4:47 ` Eli Zaretskii
2004-10-26 20:02 ` Daniel Jacobowitz [this message]
2004-10-27 5:03 ` Eli Zaretskii
2004-10-25 21:59 ` Andrew Cagney
2004-10-26 5:02 ` Eli Zaretskii
2004-10-26 7:54 ` Baurjan Ismagulov
2004-10-26 19:56 ` Eli Zaretskii
2004-10-27 17:28 ` Andrew Cagney
2004-11-27 20:54 ` Baurjan Ismagulov
2004-11-27 22:18 ` Eli Zaretskii
2004-11-27 22:54 ` Baurjan Ismagulov
2004-12-04 19:55 ` Baurjan Ismagulov
2004-12-04 22:31 ` Baurjan Ismagulov
2004-12-12 17:12 ` Andrew Cagney
2004-12-12 18:42 ` Daniel Jacobowitz
2004-12-12 21:07 ` Andrew Cagney
2004-12-13 3:37 ` Eli Zaretskii
2004-12-04 23:04 ` Eli Zaretskii
2004-12-05 23:46 ` Baurjan Ismagulov
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=20041026200155.GA29170@nevyn.them.org \
--to=drow@false.org \
--cc=eliz@gnu.org \
--cc=gdb-patches@sources.redhat.com \
--cc=ibr@ata.cs.hun.edu.tr \
/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