Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(72)

Side by Side Diff: pkg/compiler/lib/src/diagnostics/shared_messages.dart

Issue 1503053004: Move messages out of dart2js. (Closed) Base URL: git@github.com:dart-lang/sdk.git@master
Patch Set: Merge. Created 5 years ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View unified diff | Download patch
OLDNEW
(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 };
OLDNEW

Powered by Google App Engine
This is Rietveld 408576698