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" <[EMAIL PROTECTED]> 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 _______________________________________________ grass-dev mailing list [email protected] http://grass.itc.it/mailman/listinfo/grass-dev
