[gnome-devel-docs] Fix a few typos and awkward phrasings

[Michael Catanzaro <mcatanzaro src gnome org>]

commit c29a2821e3656a55f73a8e673bae454b2b7164a2
Author: Michael Catanzaro <mcatanzaro gnome org>
Date:   Sun Aug 24 17:34:09 2014 -0500

    Fix a few typos and awkward phrasings

 hig3/C/compatibility.page     |    2 +-
 hig3/C/design-principles.page |    6 +++---
 hig3/C/dialogs.page           |    8 ++++----
 hig3/C/header-bar-menus.page  |    2 +-
 hig3/C/header-bars.page       |    2 +-
 hig3/C/icons-and-artwork.page |    2 +-
 hig3/C/index.page             |    2 +-
 hig3/C/lists.page             |    2 +-
 hig3/C/primary-windows.page   |    2 +-
 hig3/C/search.page            |    2 +-
 10 files changed, 15 insertions(+), 15 deletions(-)
---
diff --git a/hig3/C/compatibility.page b/hig3/C/compatibility.page
index 104b66e..8dc7a7d 100644
--- a/hig3/C/compatibility.page
+++ b/hig3/C/compatibility.page
@@ -39,7 +39,7 @@
 
 <p>Incorporating these elements of the guidelines can enhance your application without requiring a major 
redesign, and all GTK+ and GNOME applications can benefit from them.</p>
 
-<p>At the same time, following some of the design patterns in these guidelines may imply larger-scale design 
changes for GNOME 2 style applications, particularly if those applications are complex. In particular, 
replacing window title bars and <link xref="menu-bars">menu bars</link> with a <link 
xref="header-bars">header bar</link> could be a big change for your application</p>
+<p>At the same time, following some of the design patterns in these guidelines may imply larger-scale design 
changes for GNOME 2 style applications, particularly if those applications are complex. In particular, 
replacing window title bars and <link xref="menu-bars">menu bars</link> with a <link 
xref="header-bars">header bar</link> could be a big change for your application.</p>
 
 <p>These Human Interface Guidelines have been designed to assist you in determining the best design for your 
application, rather than proposing a single template to be used in all applications. As such, while they 
recommend <link xref="header-bars">header bars</link> over <link xref="menu-bars">menu bars</link>, they 
provide guidance on both approaches.</p>
 
diff --git a/hig3/C/design-principles.page b/hig3/C/design-principles.page
index 7dcc444..30bc33c 100644
--- a/hig3/C/design-principles.page
+++ b/hig3/C/design-principles.page
@@ -72,7 +72,7 @@
 <section id="errors">
 <title>Anticipate errors</title>
 
-<p>People make mistakes. Anticipating these mistakes will prevent damaging consequences, and will make your 
application more pleasurable and satisfying to use. The first line of defence here is to design your 
application so that mistakes cannot be made. Secondly, if it is possible to make a mistake, make it easy to 
recover.</p>
+<p>People make mistakes. Anticipating these mistakes will prevent damaging consequences, and will make your 
application more pleasurable and satisfying to use. The first line of defense here is to design your 
application so that mistakes cannot be made. Secondly, if it is possible to make a mistake, make it easy to 
recover.</p>
 
 <p>Automatically correct potentially invalid input, and always make it possible to undo destructive 
operations.</p>
 
@@ -81,7 +81,7 @@
 <section id="interruptions">
 <title>Avoid interruptions</title>
 
-<p>Interruptions cause frustration, annoyance and prevent people from focusing on what they are interested 
in. Design your application so that it stays out of the way when it is not in use, and does not surprise when 
it is in use.</p>
+<p>Interruptions cause frustration and annoyance, and prevent people from focusing on what they are 
interested in. Design your application so that it stays out of the way when it is not in use, and does not 
surprise when it is in use.</p>
 
 <p>Use <link xref="notifications">notifications</link> with restraint, always avoid spontaneously popping up 
dialogs without user intent, and avoid disruptive feedback mechanisms like message dialogs.</p>
 
@@ -113,7 +113,7 @@
 <section id="emotion">
 <title>Use emotion and humor (sparingly)</title>
 
-<p>Used effectively, emotion and humor can lift the experience provided by your application, and help to 
develop a positive relationship with your users. Be careful not to over-use these techniques though - it is 
far more effective to pick a small number of moments to use emotion, rather than spraying them throughout 
your user interface.</p>
+<p>Used effectively, emotion and humor can lift the experience provided by your application, and help to 
develop a positive relationship with your users. Be careful not to over-use these techniques, though - it is 
far more effective to pick a small number of moments to use emotion, rather than spraying them throughout 
your user interface.</p>
 
 <p>Be welcoming when your application is used for the first time. Using humor when things go wrong is 
another effective technique.</p>
 
diff --git a/hig3/C/dialogs.page b/hig3/C/dialogs.page
index 9b1568e..839ce0b 100644
--- a/hig3/C/dialogs.page
+++ b/hig3/C/dialogs.page
@@ -24,11 +24,11 @@
 
 <title>Dialogs</title>
 
-<p>Dialogs are secondary windows that appear over a primary, parent window. They are used to present 
additional information or controls, including preferences, properties, or to present messages or 
questions.</p>
+<p>Dialogs are secondary windows that appear over a primary, parent window. They are used to present 
additional information or controls, including preferences and properties, or to present messages or 
questions.</p>
 
 <p>GTK+ provides a number of stock dialogs that can be used, such as for printing or color selection.</p>
 
-<p>There are three basic types of dialog design.</p>
+<p>There are three basic types of dialogs.</p>
 
 <section id="when-to-use">
 <title>When to use</title>
@@ -37,10 +37,10 @@
 
 <p>While dialogs can be an effective way to disclose additional controls or information, they can also be a 
source of interruption for the user. For this reason, always question whether a dialog is necessary, and work 
to avoid the situations in which they are required.</p>
 
-<p>There are many ways to avoid using dialogs. Examples include:</p>
+<p>There are many ways to avoid using dialogs:</p>
 
 <list>
-<item><p>Inline composition for new messages, records or contacts.</p></item>
+<item><p>Use inline composition for new messages, records or contacts.</p></item>
 <item><p>In-application notifications are an alternative to message dialogs.</p></item>
 <item><p><link xref="popovers">Popovers</link> can be a way to display additional controls or options in a 
less disruptive manner.</p></item>
 </list>
diff --git a/hig3/C/header-bar-menus.page b/hig3/C/header-bar-menus.page
index 9b0e27e..6dc55d7 100644
--- a/hig3/C/header-bar-menus.page
+++ b/hig3/C/header-bar-menus.page
@@ -27,7 +27,7 @@
 
 <p>Use a header bar menu to present additional actions or options for the current view. They are best used 
when those actions or options are not used the majority of the time - if there is a set of actions which 
deserve more prominence in the view, an <link xref="action-bars">action bar</link> might be a better 
choice.</p>
 
-<p>Header bar menus are not a good choice for performing actions on selected content: when content hasn't 
been selected, the menu will contain unhelpful insensitive menu items, when it has been selected, possible 
actions will not be advertised. <link xref="selection-mode">Selection mode</link> or <link 
xref="popovers">popovers</link> are a better choice for this situation.</p>
+<p>Header bar menus are not a good choice for performing actions on selected content: when content hasn't 
been selected, the menu will contain unhelpful insensitive menu items, and when content has been selected, 
possible actions will not be advertised. <link xref="selection-mode">Selection mode</link> or <link 
xref="popovers">popovers</link> are a better choice for this situation.</p>
 
 </section>
 
diff --git a/hig3/C/header-bars.page b/hig3/C/header-bars.page
index 516764c..0ebdf54 100644
--- a/hig3/C/header-bars.page
+++ b/hig3/C/header-bars.page
@@ -60,7 +60,7 @@
 
 <list>
 <item><p>A header bar should always provide context for the window it belongs to. This aids window 
identification, and clarifies what is displayed in the window itself. This can either be done by placing a 
heading in the center of the header bar, or by including a <link xref="view-switchers">view 
switcher</link>.</p></item>
-<item><p>Arrange controls within the header bar according to the three alignment points described in the 
<link xref="visual-layout">visual layout guidelines</link> - left, centre and right.</p></item>
+<item><p>Arrange controls within the header bar according to the three alignment points described in the 
<link xref="visual-layout">visual layout guidelines</link> - left, center and right.</p></item>
 <item><p><gui>New</gui> and back buttons should be placed on the left side of the header bar.</p></item>
 <item><p>Always ensure that there is room for a header bar to be dragged. This is necessary to enable 
windows to be moved or resized.</p></item>
 </list>
diff --git a/hig3/C/icons-and-artwork.page b/hig3/C/icons-and-artwork.page
index 7e49efa..5430f15 100644
--- a/hig3/C/icons-and-artwork.page
+++ b/hig3/C/icons-and-artwork.page
@@ -74,7 +74,7 @@
 
 <p>Every application should have a unique and beautiful application icon. It is the face of the application, 
and the first visual element a user sees when browsing for new applications. The <link 
xref="application-basics">application basics page</link> includes details on what an application is, and when 
to provide an application icon.</p>
 
-<p>Because application icons are presented at larger sizes, legacy Tango styled 48x48px or SVG icons no 
longer suffice (lacking detail). It is essential your application has a 256x256px size. With the advent of 
high-DPI displays, a 512x512px variant is recommended.</p>
+<p>Because application icons are presented at larger sizes, legacy Tango styled 48x48px or SVG icons no 
longer suffice (lacking detail). It is essential your application has a 256x256px icon. With the advent of 
high-DPI displays, a 512x512px variant is recommended.</p>
 
 <media type="image" mime="image/png" src="figures/icons/sizes.png"/>
 
diff --git a/hig3/C/index.page b/hig3/C/index.page
index 1647571..a622c0e 100644
--- a/hig3/C/index.page
+++ b/hig3/C/index.page
@@ -19,7 +19,7 @@
 
 <p>If you are a developer with limited design experience, the HIG is intended to assist you in easily 
creating an effective user interface. For designers, the HIG provides an introduction to the possibilities in 
using GTK+, as well as common design patterns that are used in GNOME applications.</p>
 
-<p>GTK+ is a flexible user interface toolkit. As such, these guidelines do not cover every possible design 
that is possible. Instead, they document recommended practices for creating desktop applications.</p>
+<p>GTK+ is a flexible user interface toolkit. As such, these guidelines do not cover every possible design. 
Instead, they document recommended practices for creating desktop applications.</p>
 
 <p>Similarly, while the HIG does provide guidance on GNOME 3 integration, and can be used to ensure 
consistency with other GNOME 3 applications, it can be used as a resource for those creating cross-platform 
applications, or applications which do not closely follow GNOME 3 application design practices.</p>
 </section>
diff --git a/hig3/C/lists.page b/hig3/C/lists.page
index 9863361..74d01e1 100644
--- a/hig3/C/lists.page
+++ b/hig3/C/lists.page
@@ -29,7 +29,7 @@
 <section id="standard-lists">
 <title>Standard lists</title>
 
-<p>Standard lists are most common list type, and should generally be used in favour of tables.</p>
+<p>Standard lists are most common list type, and should generally be used in favor of tables.</p>
 
 <p>In standard lists, each row is divided by separators, and changing the sort order is acheived by using a 
control outside the list itself.</p>
 
diff --git a/hig3/C/primary-windows.page b/hig3/C/primary-windows.page
index 579a8c8..ded6de6 100644
--- a/hig3/C/primary-windows.page
+++ b/hig3/C/primary-windows.page
@@ -46,7 +46,7 @@
 <list>
 <item><p>Viewing several content items alongside each other.</p></item>
 <item><p>Placing content on different workspaces.</p></item>
-<item><p>Organizing sets of content to be organized into different windows (if using tabs).</p></item>
+<item><p>Organizing sets of content into different windows (if using tabs).</p></item>
 </list>
 
 </section>
diff --git a/hig3/C/search.page b/hig3/C/search.page
index 80b988e..61b57c8 100644
--- a/hig3/C/search.page
+++ b/hig3/C/search.page
@@ -16,7 +16,7 @@
 
 <media type="image" mime="image/svg" src="figures/patterns/search.svg"/>
 
-<p>Search allows a content items to be located by filtering content that is displayed on screen. It is 
distinct from find, which involves moving or highlighting the content that is being searched for, rather than 
filtering.</p>
+<p>Search allows content items to be located by filtering content that is displayed on screen. It is 
distinct from find, which involves moving or highlighting the content that is being searched for, rather than 
filtering.</p>
 
 <section id="when-to-use">
 <title>When to use</title>