| | 48 | |
| | 49 | == Standard messages sandbox == |
| | 50 | |
| | 51 | * First letter should be capitalized |
| | 52 | * Use the present tense |
| | 53 | (cannot instead of could not; '''better: unable to'''; even better: avoid the issue altogether by rewording like "File not found.") |
| | 54 | * Avoid contractions (cannot instead of can't) |
| | 55 | * Good sentence construction |
| | 56 | ("Cannot find input map <%s>" instead of "It could not be find input map <%s>"; possibly better: "Input map <%s> not found.") |
| | 57 | * Be consistent with periods. Either end all phrases with a period or none. Without periods the translators save also some time |
| | 58 | 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 |
| | 59 | * 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. |
| | 60 | * '''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. |
| | 61 | * 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 ..." |
| | 62 | --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(). |
| | 63 | -- HB 2c more: (i.landsat.rgb example) |
| | 64 | Processing <$i>... |
| | 65 | |
| | 66 | Processing <$i> ... |
| | 67 | The version with the space just looks better. The version without just looks wrong. |
| | 68 | But when the line ends with a word, no-space doesn't look that bad: (v.in.ascii) |
| | 69 | Importing points... |
| | 70 | |
| | 71 | Importing points ... |
| | 72 | * Module descriptions should use all the same verbal tense. Currently some of them can be found in infinitive and others in present. |
