[gnome-devel-docs] minor fixes

[Allan Day <allanday src gnome org>]

commit 09d85c7421f29be7ce08cd67762cf98867b28514
Author: Allan Day <allanpday gmail com>
Date:   Thu Aug 21 10:32:39 2014 +0100

    minor fixes

 hig3/C/icons-and-artwork.page |    2 +-
 hig3/C/keyboard-input.page    |    2 +-
 hig3/C/notifications.page     |    2 +-
 hig3/C/primary-windows.page   |    2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)
---
diff --git a/hig3/C/icons-and-artwork.page b/hig3/C/icons-and-artwork.page
index f0a21a9..7e49efa 100644
--- a/hig3/C/icons-and-artwork.page
+++ b/hig3/C/icons-and-artwork.page
@@ -94,7 +94,7 @@
 <p>Symbolic icons have a simple form and are drawn within a 16x16 pixel grid. They are then programatically 
scaled and colored within the user interface itself.</p>
 
 <list>
-<item><p>Identify a single property when looking for an appropriate metaphor for an icon, and focus on what 
distinguishes the idea you want to communicate. For example, when describing an action to be performed on an 
image, it isn't necessary to repeat the idea of an image in every icon. Instead, focus on what is distinct 
about each action (eg. rotate, tag, align).</p></item>
+<item><p>Identify a single property when looking for an appropriate metaphor for an icon, and focus on what 
distinguishes the idea you want to communicate. For example, when describing an action to be performed on an 
image, it isn't necessary to repeat the idea of an image in every icon. Instead, focus on what is distinct 
about each action (for example: rotate, tag, align).</p></item>
 <item><p>Avoid using any perspective in symbolic icons, stick to a simple orthogonal view.</p></item>
 <item><p>Filled shapes are generally faster to process by the human visual system than wireframe 
outlines.</p></item>
 <item><p>Symbolic icons are recolored at runtime to match the context, very much like a piece of text. While 
there are ways to "shade" parts of an icon by using opacity or creating duotone/pattern dithering, try 
avoiding these as much as possible.</p></item>
diff --git a/hig3/C/keyboard-input.page b/hig3/C/keyboard-input.page
index 4e29d86..9309ad1 100644
--- a/hig3/C/keyboard-input.page
+++ b/hig3/C/keyboard-input.page
@@ -50,7 +50,7 @@
 <item><p>Choose access keys so that they are easy to remember. Normally this means using the first letter of 
the label. However, in complex windows, the choice can become more difficult. Here are some simple rules:</p>
 <list>
 <item><p>Assign access keys to the most frequently-used controls first. If it's not clear which controls 
will be the most frequently used, assign access keys from left to right, top to bottom (for Western 
locales).</p></item>
-<item><p>Use the first letter of the label, or of one of its other words if it has more than one. If another 
letter provides a better association (e.g. "x" in Extra Large) however, consider using that letter 
instead.</p></item>
+<item><p>Use the first letter of the label, or of one of its other words if it has more than one. If another 
letter provides a better association (for example: "x" in Extra Large) however, consider using that letter 
instead.</p></item>
 <item><p>If the first letter is not available, choose an easy to remember consonant from the label, for 
example, "p" in Replace.</p></item>
 <item><p>If no such consonants are available, choose any available vowel from the label.</p></item>
 </list></item>
diff --git a/hig3/C/notifications.page b/hig3/C/notifications.page
index 2008cf8..f42531b 100644
--- a/hig3/C/notifications.page
+++ b/hig3/C/notifications.page
@@ -43,7 +43,7 @@
 <td><p>Title</p></td><td><p>The heading for the notification.</p></td>
 </tr>
 <tr>
-<td><p>Body</p></td><td><p>An optional block of text which gives extra detail about the notification. The 
notification body can include multiple paragraphs. e.g. A snippet from the beginning of an email.</p></td>
+<td><p>Body</p></td><td><p>An optional block of text which gives extra detail about the notification. The 
notification body can include multiple paragraphs. For example: a snippet from the beginning of an 
email.</p></td>
 </tr>
 <tr>
 <td><p>Default Action</p></td><td><p>This is the action that is triggered when the notification is 
activated.</p></td>
diff --git a/hig3/C/primary-windows.page b/hig3/C/primary-windows.page
index 9828bec..579a8c8 100644
--- a/hig3/C/primary-windows.page
+++ b/hig3/C/primary-windows.page
@@ -58,7 +58,7 @@
 <list>
 <item><p>If your application isn't running and its launcher is activated, a single primary window should be 
displayed. Do not show multiple windows when your application is initially launched.</p></item>
 <item><p>If your application launcher is selected while your application is running, all its primary windows 
should be displayed.</p></item>
-<item><p>Primary windows should host the main functionality of your application. Do not rely on dialog or 
secondary windows in order to present basic functionality.</p></item>
+<item><p>Primary windows should host the main functionality of your application. Do not rely on dialogs or 
secondary windows in order to present basic functionality.</p></item>
 <item><p>Primary windows should be independent - closing one primary window should not result in other 
primary windows being closed.</p></item>
 <item><p>Dialog windows should always be dependent on a primary window. See the <link xref="dialogs">dialogs 
page</link> guidelines.</p></item>
 <item><p>Your application should cease to run when all its primary windows have been closed.</p></item>