In progress, see ​http://grass.osgeo.org/wiki/Development_Specs

Message Standardization

How should Errors/Warnings/Messages be formatted

• Only user derived variables should be bracketed, not GRASS derived variables, for example:

   Yes: Creating raster map <%s>.  Pass 1 of 7 ...
   No:  Creating <raster> map <%s>.  Pass [1] of [7] ...
  

• strings < > - raster, vector maps, group names, etc., e.g.
  • Raster map <%s> not found
• strings ' ' - paths, SQL queries, etc., e.g.
  • File '%s' not found
  • Unable to create table: '%s'

Discussion

• The [bracketed] parenthetical disrupts the flow of the phrase and doesn't help enhance clarity of meaning. IMHO, this reads better without [] brackets: "Line %d deleted." [] Brackets should be used when value is outside of the phrase: "Unknown line [%d]". --HB

Statistics

symbol	number of code lines (2007-04-11)	2008-02-14 (6.3svn)	2009-08-02 (7.0svn)
<%s>	637	1406	1935
[%s]	690	427	222
'%s'	354	370	537
<%d>	12	7	11
[%d]	207	13	137
'%d'	3	1	1

TYPES="<%s> \[%s\] '%s' <%d> \[%d\] '%d'"

for TYPE in $TYPES ; do
  NUM_HITS=`grep -rI "$TYPE" * | grep -v '/.svn/\|^dist.i686-\|locale/po/' | wc -l`
  echo "$TYPE  $NUM_HITS"
done

Macros to be defined for C library

• MSG_RASTER_NOT_FOUND_IN_MAPSET - "Raster map <%s> not found in <%s>"
• MSG_CANNOT_OPEN_RASTER - "Unable to open raster map <%s>"
• MSG_CANNOT_OPEN_FILE - Unable to open file <%s>

Note: Problem with xgettext package. How to use macros to work with xgettext?

Standard messages sandbox

• First letter should be capitalized
• Use the present tense (cannot instead of could not; better: unable to; even better: avoid the issue altogether by rewording like "File not found.")
• Avoid contractions (cannot instead of can't)
• Good sentence construction ("Cannot find input map <%s>" instead of "It could not be find input map <%s>"; possibly better: "Input map <%s> not found.")
• Be consistent with periods. Either end all phrases with a period or none. Without periods the translators save also some time Complete sentences or all parts of a message with multiple sentences should end with periods. Short phrases should not. Punctuated events, such as errors, deserve a period. e.g. "Operation complete." Phrases which imply ongoing action look odd if missing an ellipse or any other form of punctuation. Phrase != Sentence. --HB
• Either all module descriptions should end with periods or not. As some are multi-sentence, and thus should end in a period for consistency within the message, so probably they all should end in one. Currently by my count 237 end with '.', 139 do not. In the multi-sentence case it may be posible to put the simple description in the module->label field and additional explanitory text into the ->description field.
• option and flag descriptions generally should not end in a period (more likely to be phrases than sentences). But they can suffer the same multi-sentence period problem as module descriptions. In this case splitting out additional text into a ->label, ->description split may help.
• Suspension points used to indicate some process is being done should be placed next to last word, without space. e.g. "Reading map..." instead of "Reading map ..." --HB: FWIW & my 2c, 1) to me keeping the space before the ellipse looks better, is this a purely cosmetic choice or is there some style logic? [wikipedia article on the ellipse was cited on grass-dev, I would argue that refers to printed typeset text not monospace terminal text, strangely suggests punctuation+3 dots (....), is just one other guy's opinion, and I'm still not swayed] 2) these messages may be good candidates for G_verbose_message(). -- HB 2c more: (i.landsat.rgb example) Processing <$i>...

Processing <$i> ... The version with the space just looks better. The version without just looks wrong. But when the line ends with a word, no-space doesn't look that bad: (v.in.ascii) Importing points...

Importing points ...

• Module descriptions should use all the same verbal tense. Currently some of them can be found in infinitive and others in present.