GNU nano 2.1.3

is released

2008.08.04 - GNY nano 2.1.3 "least stable version ever" is released.  This
		release includes new (and experimental) undo and redo
		functionality for most text operations.  The default 
		key bindings are Meta-U for undo and Meta-E for redo, but
		these can be remapped using the new 2.1 keybinding code.
		Also included are some fixes for configuring using wide 
		curses, crashing when invoking the help menu with 
		certain locales, and not saving the search history when
		compiled with configure options.

Chris A
--

-- 
Chris Allegretta	http://www.asty.org

v4sw7CUPYhw5ln6pr5Pck4ma7u7Lw0m6g/l7DUi5e6t5Ab6THen7g6Ma29s5r3p-4 hackerkey.com

_______________________________________________
Info-nano mailing list
Info-nano <at> gnu.org
http://lists.gnu.org/mailman/listinfo/info-nano

GNU nano 2.1.4

2008.08.09 - GNU nano 2.1.4 "I told you so!" is released.  This release
		includes fixes for several severe issues with the new
		undo/redo code.  Also the behavior of writing
		files when using backup mode has changed as well: if writing
		the backup file fails, nano will not attempt to write the
		current file.  This should help folks who enjoy "extreme
		text editing" i.e. editing files on file systems which
		are likely to run out of space; see Savannah bug 24000.
		Have fun with it!

Chris A
--

-- 
Chris Allegretta	http://www.asty.org

v4sw7CUPYhw5ln6pr5Pck4ma7u7Lw0m6g/l7DUi5e6t5Ab6THen7g6Ma29s5r3p-4 hackerkey.com

_______________________________________________
Info-nano mailing list
Info-nano <at> gnu.org
http://lists.gnu.org/mailman/listinfo/info-nano

[patch] making some messages more alarming

Hi,

Some of the messages in the new undo code are somewhat graphic but 
do not clearly convey that they are serious program errors.  
Attached patch remedies this.  (I'm unsure whether "Couldn't match 
current undo line" is an internal error, though.)

Benno

_______________________________________________
Nano-devel mailing list
Nano-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/nano-devel

Re: Translation updates

Le 2008-08-12 22:27:44 +0200, Benno Schulenberg écrivait :
> 
> Some of the messages in the new undo code are somewhat graphic but 
> do not clearly convey that they are serious program errors.  
> Attached patch remedies this.  (I'm unsure whether "Couldn't match 
> current undo line" is an internal error, though.)

As a side note to the current discussion, could we go back to the way we 
were working previously for translations updates.

There was an agreement to give a one week notice to translators before 
publishing a new version. Thus enabling the new version to be published 
with up-to-date translations. Which in itself is a reward for the 
translator :)

Currently, the published version of nano are never up-to-date regarding 
translation (as the po are updated after the version is published), 
giving the impression that the translator is doing a sloppy job.

Thanks.

Best Regards.

--

-- 
Jean-Philippe Guérard
http://tigreraye.org

Re: Translation updates

On 8/13/08, Jean-Philippe Guérard <jean-philippe.guerard <at> tigreraye.org> wrote:
> As a side note to the current discussion, could we go back to the way we
> were working previously for translations updates.
>
> There was an agreement to give a one week notice to translators before
> publishing a new version. Thus enabling the new version to be published
> with up-to-date translations. Which in itself is a reward for the
> translator :)

Absolutely, unless there is something critical like what we had with
2.1.3 that shouldn't be a problem.  Forgive me, were the specifics of
the agreement: that the maintainer would post to the llist that 'There
will be a release in a week' and not change any strings until the
release, or was a x.y.zpre- release created and uploaded to the test
ftp direcory?

Thanks much!

Re: Translation updates

Le 2008-08-13 16:37:12 -0400, Chris Allegretta écrivait :
> On 8/13/08, Jean-Philippe Guérard <jean-philippe.guerard <at> tigreraye.org> wrote:
> > As a side note to the current discussion, could we go back to the way we
> > were working previously for translations updates.
> >
> > There was an agreement to give a one week notice to translators before
> > publishing a new version. Thus enabling the new version to be published
> > with up-to-date translations. Which in itself is a reward for the
> > translator :)
> 
> Absolutely, unless there is something critical like what we had with
> 2.1.3 that shouldn't be a problem.

OK, perfect.

> Forgive me, were the specifics of the agreement: that the maintainer 
> would post to the llist that 'There will be a release in a week' and 
> not change any strings until the release, or was a x.y.zpre- release 
> created and uploaded to the test ftp direcory?

IIRW, a pre release was made, and the po file posted to the Translation 
Project.

Having a pre-release is useful, as, for bigger updates, the translator 
usually needs to build the new version on his computer to test his 
translation (to check that the messages have the correct length, or 
to check the translation in context).

If the Translation project is too slow publishing the translation (which 
shouldn't happen anymore), posting a link to the pre-release tarball 

Re: Translation updates

Chris Allegretta wrote:
> Forgive me, were the
> specifics of the agreement: that the maintainer would post to the
> llist that 'There will be a release in a week' and not change any
> strings until the release, or was a x.y.zpre- release created and
> uploaded to the test ftp direcory?

A prerelease is preferred.  And then announce it by send its URL to 
<coordinator <at> translationproject.org> with nano.x.y,z.POT in it s 
subject line, as the other coordinators don't follow this list.

Regards,

Benno

Re: [patch] making some messages more alarming

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.
-mike

_______________________________________________
Nano-devel mailing list
Nano-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/nano-devel

Re: [patch] making some messages more alarming

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.

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.

Benno

Re: [patch] making some messages more alarming

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.

> 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