OLD | NEW |
| (Empty) |
1 // Copyright (c) 2015, the Dart project authors. Please see the AUTHORS file | |
2 // for details. All rights reserved. Use of this source code is governed by a | |
3 // BSD-style license that can be found in the LICENSE file. | |
4 | |
5 // This file is parsed by JavaScript and must not use fancy Dart constructs. | |
6 // It can contain JSON like constructs and "//" comments (but not "/*" "*/"). | |
7 // It must have one assignment (`final MESSAGES =`). | |
8 // All strings must be raw strings. | |
9 | |
10 // The messages in this file should meet the following guide lines: | |
11 // | |
12 // 1. The message should be a complete sentence starting with an uppercase | |
13 // letter, and ending with a period. | |
14 // | |
15 // 2. Reserved words and embedded identifiers should be in single quotes, so | |
16 // prefer double quotes for the complete message. For example, "The | |
17 // class '#{className}' can't use 'super'." Notice that the word 'class' in the | |
18 // preceding message is not quoted as it refers to the concept 'class', not the | |
19 // reserved word. On the other hand, 'super' refers to the reserved word. Do | |
20 // not quote 'null' and numeric literals. | |
21 // | |
22 // 3. Do not try to compose messages, as it can make translating them hard. | |
23 // | |
24 // 4. Try to keep the error messages short, but informative. | |
25 // | |
26 // 5. Use simple words and terminology, assume the reader of the message | |
27 // doesn't have an advanced degree in math, and that English is not the | |
28 // reader's native language. Do not assume any formal computer science | |
29 // training. For example, do not use Latin abbreviations (prefer "that is" over | |
30 // "i.e.", and "for example" over "e.g."). Also avoid phrases such as "if and | |
31 // only if" and "iff", that level of precision is unnecessary. | |
32 // | |
33 // 6. Prefer contractions when they are in common use, for example, prefer | |
34 // "can't" over "cannot". Using "cannot", "must not", "shall not", etc. is | |
35 // off-putting to people new to programming. | |
36 // | |
37 // 7. Use common terminology, preferably from the Dart Language | |
38 // Specification. This increases the user's chance of finding a good | |
39 // explanation on the web. | |
40 // | |
41 // 8. Do not try to be cute or funny. It is extremely frustrating to work on a | |
42 // product that crashes with a "tongue-in-cheek" message, especially if you did | |
43 // not want to use this product to begin with. | |
44 // | |
45 // 9. Do not lie, that is, do not write error messages containing phrases like | |
46 // "can't happen". If the user ever saw this message, it would be a | |
47 // lie. Prefer messages like: "Internal error: This function should not be | |
48 // called when 'x' is null.". | |
49 // | |
50 // 10. Prefer to not use imperative tone. That is, the message should not sound | |
51 // accusing or like it is ordering the user around. The computer should | |
52 // describe the problem, not criticize for violating the specification. | |
53 // | |
54 // Other things to keep in mind: | |
55 // | |
56 // Generally, we want to provide messages that consists of three sentences: | |
57 // 1. what is wrong, 2. why is it wrong, 3. how do I fix it. However, we | |
58 // combine the first two in [template] and the last in [howToFix]. | |
59 | |
60 final MESSAGES = { | |
61 }; | |
OLD | NEW |