[GRASS-dev] Message standardization

[Michael Barton]

What a mess. But not at all surprising after over 20 years of volunteer
programming by umteem people.

I fully support the standardization of error messages. The suggestions all
look good to me. 

There is considerable back and forth (thoughtful) about periods. For easy
consistency, I'd simply go with: sentence ends with period; phrase does not
end with period. (and as HB says sentence != phrase). Save ellipses for
pending operations (Reading...).

Looking this over didn't take much time and I recommend everyone follow
Hamish's suggestion so we can move ahead with this.

We'll need to do the same thing with the GUI, especially as we add more
error traps and error message boxes. But let's do the main C modules first
and then use these specs as guidance.

Michael


On 6/10/07 11:02 PM, "Hamish" <hamish_nospam at yahoo.com> wrote:

> Carlos Dávila wrote:
>> I'm new in dev list, but I've been working in translations for some
>> time. I would like to standardize some grass messages, according to
>> what is proposed in
>> http://grass.gdf-hannover.de/wiki/Development_Specs (please check
>> last changes) in order to ease the work for translators and get a
>> more consistent program. I don't know if standard messages proposed in
>> wiki can already be used or if discussion is still open. Any feedback
>> is welcome. If no objections are reported, I will start changing
>> messages in the next days, at least the most obvious.
> 
> 
> The ideas on the wiki page are just the opinions of a few of us who
> edited the page AFAICT, not a full consensus reached on the -dev mailing
> list which it needs to be before any mass change. So that it can be
> formalized and the discussion closed, I too would ask everyone to review
> what's listed there, and discuss here. There are several unresolved
> questions there which need to be answered.
> 
> At least I hope with g.message and G_*message() we have all the tools we
> need now? My only gripe with G_message() is that it makes it impossible
> to use whitespace formatting as it drops \n and \t and leading spaces
> and compresses inline multiple spaces. But maybe that is good, as doing
> that will not work well with dynamic-width fonts, ie it makes GUI output
> ugly between lines, and tables should go to fprintf(stdout,..).
> 
> 
> It saves more work later to get this right the first time :) and kills
> motivation on all sides to have to revert changes later :(
> 
> 
> Hamish
> 
> 

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton