Michael Barton wrote: > > Module descriptions are a different sort of beast from error > messages--and from GUI messages and other descriptors. All need > standardization, but I'd recommend doing them one at a time so as not > to overwhelm everyone. > > If we can standardize error messages first it might be the simplest > piece to attack. Then move on to others like module descriptions in > the module code, module doc formatting, GUI, etc.
I would consider module and option/flag descriptions much easier "low- hanging fruit" than error messages. For them the rules are simpler, - module descriptions end with a "." - option/flag descriptions do not. - Multi-sentence descriptions are probably good candidates to break up into a short ->label + a ->description to hold additional info. - Begin with a capital letter. - Don't pad whitespace. For standard error/warning messages (ie the ones that always come right after G_open_file() or whatever) we can pick something nice and specify that on the wiki page to avoid repetitious translations of almost identical messages. For the vast majority of error/warning/regular messages, they are single-use, module dependant, and maybe put there by the programmer on a just-in-case basis, ie they may never be seen by a user. Contrast that with the module description and option descriptions which have high exposure, & thus greater result from a translator's time. library translations have high-reuse value. GUI translations have high-exposure value. 2c, Hamish _______________________________________________ grass-dev mailing list [email protected] http://grass.itc.it/mailman/listinfo/grass-dev
