nano-devel
[Top][All Lists]
Advanced

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

Re: [Nano-devel] [patch] making some messages more alarming


From: Chris Allegretta
Subject: Re: [Nano-devel] [patch] making some messages more alarming
Date: Wed, 20 Aug 2008 01:43:10 -0400

On Tue, Aug 19, 2008 at 6:08 PM, Mike Frysinger <address@hidden> wrote:
On Tuesday 19 August 2008, Benno Schulenberg wrote:
> Mike Frysinger wrote:
> > On Tuesday 12 August 2008, Benno Schulenberg wrote:
> > > -        statusbar(_("Couldnt match current undo line"));
> > > +        statusbar(_("*Internal error*: cannot match current
> > > undo line"));
> >
> > maybe better to introduce an internal error macro ?  that way
> > translators only need to update "*internal error*" once rather
> > than every message, and so the output format stays consistent.
>
> In some human languages things may need to be worded differently
> depending on whether it is an alarmist message, a neutral note, a
> pointing out of user error, ...  Therefore it's better to
> gettextize complete messages and not parts of them.

i dont see how that relates to message prefixes.  internal errors will all
have the same translated prefix.  how you translate the rest of the message
is unchanged.

I think what he is trying to say, and Ive heard other translators tell me this as
well, that its harder to translate the proper sentence as effectively if you just
see a '%s' instead of the wording which completes the thought you are trying
to convey.
 

> Repetitive components are not a problem for translators.  And the
> messages to which "*Internal error*" is added are all new, so not
> many translators have translated them yet.  Not much is lost when
> changing them now.

having all the messages read the same now doesnt really matter.  it's a very
trivial source for bitrot.
-mike

This is true.  However once we this code is tested out and we get into the next
stable series my plan is to just remove the strings altogether, since in theory
you should not be able to trigger them: they can be replaced with an assert if
we're concerned that we might get there.  I dont want people to lose work unnecessarily
in the meantime or I'd take them out now.

I'll revamp the messages per the discussion and make a 2.1.5pre1 release tonight
or tomorrow.

On an unrelated note, 2.0.8 will hopefully be released this weekend after I get my
RPM making infrastructure back up and functional.

reply via email to

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