[gnome-devel-docs] minor fixes based on feedback from Michael Catanzaro

[Allan Day <allanday src gnome org>]

commit 3124547b08fb78fd97095a4c211cb292c689262d
Author: Allan Day <allanpday gmail com>
Date:   Tue Aug 26 09:50:20 2014 +0100

    minor fixes based on feedback from Michael Catanzaro

 hig3/C/application-basics.page      |    6 +++---
 hig3/C/buttons.page                 |    2 +-
 hig3/C/check-boxes.page             |    2 +-
 hig3/C/design-principles.page       |    4 ++--
 hig3/C/dialogs.page                 |    2 +-
 hig3/C/drop-down-lists.page         |    2 +-
 hig3/C/header-bar-menus.page        |    6 +++---
 hig3/C/icons-and-artwork.page       |   10 +++++-----
 hig3/C/index.page                   |    5 +++--
 hig3/C/keyboard-input.page          |   10 +++++-----
 hig3/C/menu-bars.page               |   30 +++++++++++++++---------------
 hig3/C/menus.page                   |    2 +-
 hig3/C/notifications.page           |    6 +++---
 hig3/C/pointer-and-touch-input.page |    2 +-
 hig3/C/popovers.page                |    2 +-
 hig3/C/primary-windows.page         |    2 +-
 hig3/C/progress-bars.page           |    4 ++--
 hig3/C/search.page                  |    4 ++--
 hig3/C/sidebar-lists.page           |    2 +-
 hig3/C/sliders.page                 |    2 +-
 hig3/C/spin-boxes.page              |    4 ++--
 hig3/C/tabs.page                    |    6 +++---
 hig3/C/toolbars.page                |    4 ++--
 hig3/C/writing-style.page           |    4 ++--
 24 files changed, 62 insertions(+), 61 deletions(-)
---
diff --git a/hig3/C/application-basics.page b/hig3/C/application-basics.page
index 3217d48..636656f 100644
--- a/hig3/C/application-basics.page
+++ b/hig3/C/application-basics.page
@@ -20,7 +20,7 @@
 <section id="application-definition">
 <title>Defining an application</title>
 
-<quote><p>An application is a distinct and independent piece of software that incorporates useful 
functionality, and which can be installed on a user's system.</p></quote>
+<quote><p>An application is a distinct and independent piece of software that incorporates useful 
functionality, and which can be installed on a user’s system.</p></quote>
 
 <p>This definition can be broken down into a set of characteristics, which describe an application in more 
detail. Applications:</p>
 
@@ -48,7 +48,7 @@ Applications are launched and switched to via their launchers...
 <section id="application-names">
 <title>Naming your application</title>
 
-<p>An application's name is vital. It is what users will be first exposed to, and will help them decide 
whether they want to use an application or not. It is a major part of your application's public face.</p>
+<p>An application’s name is vital. It is what users will be first exposed to, and will help them decide 
whether they want to use an application or not. It is a major part of your application’s public face.</p>
 
 <p>An application name plays a number of functions:</p>
 
@@ -60,7 +60,7 @@ Applications are launched and switched to via their launchers...
 
 <p>Ensure that your application name is short - fewer than 15 characters. This will ensure that it is always 
displayed in full within a GNOME 3 environment.</p>
 
-<p>Additionally, choose an application name that is easy to understand and communicates your application's 
functionality. Avoid references which will not be understood or be familiar to potential users, such as 
obscure cultural references, inside jokes and acronyms. Instead, pick a name that references what your 
application does, or the domain in which it operates.</p>
+<p>Additionally, choose an application name that is easy to understand and communicates your application’s 
functionality. Avoid references which will not be understood or be familiar to potential users, such as 
obscure cultural references, inside jokes and acronyms. Instead, pick a name that references what your 
application does, or the domain in which it operates.</p>
 
 </section>
 
diff --git a/hig3/C/buttons.page b/hig3/C/buttons.page
index 11d771f..3c2bd5c 100644
--- a/hig3/C/buttons.page
+++ b/hig3/C/buttons.page
@@ -55,7 +55,7 @@
 <section id="toggle-buttons">
 <title>Toggle buttons</title>
 
-<p>Toggle buttons look the same as regular buttons, but are used to show or change a state rather than 
initiate an action. A toggle button's two states, set and unset, are shown by its appearing "pushed in" or 
"popped out" respectively.</p>
+<p>Toggle buttons look the same as regular buttons, but are used to show or change a state rather than 
initiate an action. A toggle button’s two states, set and unset, are shown by its appearing “pushed in” or 
“popped out” respectively.</p>
 
 </section>
 
diff --git a/hig3/C/check-boxes.page b/hig3/C/check-boxes.page
index 9d6baf2..bfcf661 100644
--- a/hig3/C/check-boxes.page
+++ b/hig3/C/check-boxes.page
@@ -41,7 +41,7 @@
 <list>
 <item><p>Clicking the box once should check the box, applying that setting (when confirmed) to all the 
selected objects.</p></item>
 <item><p>Clicking the box a second time should uncheck the box, removing that setting (when confirmed) to 
all the selected objects.</p></item>
-<item><p>Clicking the box a third time should return the box to its mixed state, restoring each selected 
object's original value for that setting (when confirmed).</p></item>
+<item><p>Clicking the box a third time should return the box to its mixed state, restoring each selected 
object’s original value for that setting (when confirmed).</p></item>
 </list></item>
 <item><p>Label a group of check boxes with a descriptive heading above or to the left of the 
group.</p></item>
 <item><p>Do not place more than about eight check boxes under the same group heading. If you need more than 
eight, try to use blank space or heading labels to divide them into smaller groups. Otherwise, consider using 
a check box list instead— but you probably also need to think about how to simplify your user 
interface.</p></item>
diff --git a/hig3/C/design-principles.page b/hig3/C/design-principles.page
index 30bc33c..1aa8566 100644
--- a/hig3/C/design-principles.page
+++ b/hig3/C/design-principles.page
@@ -54,7 +54,7 @@
 <section id="hierarchy">
 <title>Create a clear hierarchy</title>
 
-<p>People tend to ‘read’ an interface from left to right and top to bottom. Items that are encountered first 
are seen to be dominant over those that come later. Use this implied hierarchy to communicate which parts of 
your application are most important.</p>
+<p>People tend to “read” an interface from left to right and top to bottom. Items that are encountered first 
are seen to be dominant over those that come later. Use this implied hierarchy to communicate which parts of 
your application are most important.</p>
 
 <p>Position the most important controls towards the top-left of your windows, and place dominant controls 
prior to other controls they affect. See the <link xref="visual-layout">visual layout</link> guidelines for 
more details.</p>
 
@@ -65,7 +65,7 @@
 
 <p>Applications typically present content, whether it is images, text, messages or more complex data. It is 
this content that your users will be interested in, and too many controls or user interface elements will 
distract from the focus of their attention.</p>
 
-<p>Give content as much space as possible in your user interface, by reducing the number of controls. Don't 
crowd out the primary object of interest with secondary information.</p>
+<p>Give content as much space as possible in your user interface, by reducing the number of controls. Don’t 
crowd out the primary object of interest with secondary information.</p>
 
 </section>
 
diff --git a/hig3/C/dialogs.page b/hig3/C/dialogs.page
index 839ce0b..68e9fdc 100644
--- a/hig3/C/dialogs.page
+++ b/hig3/C/dialogs.page
@@ -131,7 +131,7 @@
 
 <p>Choose the default button to be the most likely action, such as a confirmation action or an action that 
applies changes. Do not make a button the default if its action is irreversible, destructive or otherwise 
inconvenient to the user. If there is no appropriate button in your window, to designate as the default 
button, do not set one.</p>
 
-<p>In particular, it is currently not recommended to make the <gui>Close</gui> button the default in an 
instant apply window, as this can lead to users closing the window accidentally before they have finished 
using it.</p>
+<p>In particular, it is not recommended to make the <gui>Close</gui> button the default in an instant apply 
window, as this can lead to users closing the window accidentally before they have finished using it.</p>
 
 </section>
 
diff --git a/hig3/C/drop-down-lists.page b/hig3/C/drop-down-lists.page
index 9323ef1..565a6b3 100644
--- a/hig3/C/drop-down-lists.page
+++ b/hig3/C/drop-down-lists.page
@@ -22,7 +22,7 @@
 <item><p>The number of options is large.</p></item>
 <item><p>There is little available space.</p></item>
 <item><p>The list of options may change over time.</p></item>
-<item><p>The contents of the hidden part of the menu are obvious from its label and the one selected item. 
For example, if you have an option menu labelled "Month:" with the item "January" selected, the user might 
reasonably infer that the menu contains the 12 months of the year without having to look.</p></item>
+<item><p>The contents of the hidden part of the menu are obvious from its label and the one selected item. 
For example, if you have an option menu labelled “Month:” with the item “January” selected, the user might 
reasonably infer that the menu contains the 12 months of the year without having to look.</p></item>
 </list>
 
 <section id="general-guidelines">
diff --git a/hig3/C/header-bar-menus.page b/hig3/C/header-bar-menus.page
index 6dc55d7..44b25ff 100644
--- a/hig3/C/header-bar-menus.page
+++ b/hig3/C/header-bar-menus.page
@@ -18,7 +18,7 @@
 
 <p><link xref="header-bars">Header bars</link> can include a menu which contains actions and options for the 
current view. These menus are located at the far right side of the header bar.</p>
 
-<p>While the most frequently used actions for a view should be placed directly in the header bar, a header 
bar menu provides access to lesser-used actions. This ensures that the header bar isn't overwhelmed with less 
interesting or useful controls.</p>
+<p>While the most frequently used actions for a view should be placed directly in the header bar, a header 
bar menu provides access to lesser-used actions. This ensures that the header bar isn’t overwhelmed with less 
interesting or useful controls.</p>
 
 <p>In this way, the header bar menus help to create focused views that guide the user towards the most 
interesting and useful functionality.</p>
 
@@ -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, 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>
+<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>
 
@@ -38,7 +38,7 @@
 <item><p>Header bar menus should only contain actions for the current view or window - this differentiates 
their content from application menus.</p></item>
 <item><p>Follow the <link xref="menus">standard guidelines for menus</link>.</p></item>
 <item><p>A header bar menu is contained within a <link xref="popovers">popover</link>. As such, a header bar 
menu can include a variety of controls, such as groups of buttons.</p></item>
-<item><p>Header bar menus shouldn't include a close menu item, since this action is already provided by the 
header bar. It can also be ambiguous as to what a close menu item refers to.</p></item>
+<item><p>Header bar menus shouldn’t include a close menu item, since this action is already provided by the 
header bar. It can also be ambiguous as to what a close menu item refers to.</p></item>
 </list>
 
 </section>
diff --git a/hig3/C/icons-and-artwork.page b/hig3/C/icons-and-artwork.page
index 5430f15..2b547fc 100644
--- a/hig3/C/icons-and-artwork.page
+++ b/hig3/C/icons-and-artwork.page
@@ -29,7 +29,7 @@
 <item><p>Convention establishes which icons will be recognized. If you are in doubt, stick to icons which 
are frequently used in other applications.</p></item>
 <item><p>Consider which icons will be meaningful in the specific context of your application - users of 
specialist tools will often be familiar with domain-specific symbols.</p></item>
 </list></item>
-<item><p>Remember that some icons are only meaningful alongside other icons of the same type. For example, a 
media icon for stop is simply a square, and may not be identified as a stop icon without other media controls 
(like play, pause, or skip) being visible close by. Likewise, the icon to remove an item from a list is a 
subtract symbol (ie. a single line), and will not be recognizable without a corresponding "plus" add 
icon.</p></item>
+<item><p>Remember that some icons are only meaningful alongside other icons of the same type. For example, a 
media icon for stop is simply a square, and may not be identified as a stop icon without other media controls 
(like play, pause, or skip) being visible close by. Likewise, the icon to remove an item from a list is a 
subtract symbol (ie. a single line), and will not be recognizable without a corresponding “plus” add 
icon.</p></item>
 </list>
 
 </section>
@@ -78,7 +78,7 @@
 
 <media type="image" mime="image/png" src="figures/icons/sizes.png"/>
 
-<p>While not as critical, there are still areas where application icons are presented at a small size. To 
keep the icon sharp and well defined, a specific rendering is required to sizes of 48x48px, 32x32px, 24x24px 
and 16x16px. Many GNOME icons also ship a 22x22px size for legacy reasons, but that isn't required.</p>
+<p>While not as critical, there are still areas where application icons are presented at a small size. To 
keep the icon sharp and well defined, a specific rendering is required to sizes of 48x48px, 32x32px, 24x24px 
and 16x16px. Many GNOME icons also ship a 22x22px size for legacy reasons, but that isn’t required.</p>
 
 <media type="image" mime="image/png" src="figures/icons/sizes-small-24.png"/>
 
@@ -94,10 +94,10 @@
 <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 (for example: 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>
+<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>
 <item><p>When a metaphor relies on the negative space, make sure it will work with the colors inverted. For 
example a camera lens spec/highlight will only work if lighter than the lens itself.</p></item>
 </list>
 
@@ -120,7 +120,7 @@
 <section id="perspective">
 <title>Perspective</title>
 
-<p>Most icons can be executed best by using the "on the table" perspective, as if the observer was standing 
in front of the object and looking slightly down on it. Many icons can be rendered with a simple "straight 
on" or "on the shelf" perspective, with the observer looking directly at the object at eye level.</p>
+<p>Most icons can be executed best by using the “on the table” perspective, as if the observer was standing 
in front of the object and looking slightly down on it. Many icons can be rendered with a simple “straight 
on” or “on the shelf” perspective, with the observer looking directly at the object at eye level.</p>
 
 </section>
 
diff --git a/hig3/C/index.page b/hig3/C/index.page
index a622c0e..7076d55 100644
--- a/hig3/C/index.page
+++ b/hig3/C/index.page
@@ -32,10 +32,11 @@
 <list>
 <item><p><link xref="essentials">Essentials</link> - these pages include overarching guidance on thematic 
topics. They include sections on recommended design principles, as well as guidance on themes like writing 
style and artwork.</p></item>
 <item><p><link xref="patterns">Patterns</link> - design patterns make up the core of the HIG. Each pattern 
is a particular arrangement of user interface elements which can be used to construct an application design. 
The patterns allow key design decisions to be abstracted away from the nitty gritty of individual user 
interface elements.</p></item>
-<item><p><link xref="ui-elements">Interface elements</link> - guidance on the various interface elements, 
such as buttons, switches, and sliders, that you can use in your application.
-If you have never read the Human Interface Guidelines before, it is recommended that you start with the 
essentials section, in particular the design principles page, before continuing to learn about the design 
patterns.</p></item>
+<item><p><link xref="ui-elements">Interface elements</link> - guidance on the various interface elements, 
such as buttons, switches, and sliders, that you can use in your application.</p></item>
 </list>
 
+<p>If you have never read the Human Interface Guidelines before, it is recommended that you start with the 
essentials section, in particular the design principles page, before continuing to learn about the design 
patterns.</p>
+
 </section>
 
 <section id="version">
diff --git a/hig3/C/keyboard-input.page b/hig3/C/keyboard-input.page
index 9309ad1..26a3a8e 100644
--- a/hig3/C/keyboard-input.page
+++ b/hig3/C/keyboard-input.page
@@ -49,7 +49,7 @@
 <item><p>Give all labelled components an access key (underlined letter), with the exception of toolbar 
controls which would use up too many access key combinations.</p></item>
 <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>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 (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>
@@ -110,9 +110,9 @@ Do not assign system-level shortcut keys. These use the Super key (sometimes kno
 <td><p>Switches focus to the primary areas of the system: windows, top bar, message tray</p></td>
 </tr>
 <tr>
-<td><p>Log out</p></td>
-<td><p><keyseq><key>Ctrl</key><key>Alt</key><key>Del</key></keyseq></p></td>
-<td><p>Logs the user out of their session. This shortcut is typically disabled by default.</p></td>
+<td><p>Power Off</p></td>
+<td><p><keyseq><key>Ctrl</key><key>Alt</key><key>Delete</key></keyseq></p></td>
+<td><p>Prompts the user to power off the system. This shortcut is typically disabled by default.</p></td>
 </tr>
 <tr>
 <td><p>Window menu</p></td>
@@ -359,7 +359,7 @@ Do not assign system-level shortcut keys. These use the Super key (sometimes kno
 <tr>
 <td><p><gui>Properties</gui></p></td>
 <td><p><keyseq><key>Alt</key><key>Enter</key></keyseq></p></td>
-<td><p>Display the selected object's properties window.</p></td>
+<td><p>Display the selected object’s properties window.</p></td>
 </tr>
 </tbody>
 </table>
diff --git a/hig3/C/menu-bars.page b/hig3/C/menu-bars.page
index d5fcdbe..8af0803 100644
--- a/hig3/C/menu-bars.page
+++ b/hig3/C/menu-bars.page
@@ -33,7 +33,7 @@
 <section id="when-to-use">
 <title>When to use</title>
 
-<p>Menu bars increase the vertical footprint of an application's user interface, introduce a large number of 
disclosure points, and function as a fixed set of inflexible options. For these reasons, <link 
xref="header-bars">header bars</link> and <link xref="header-bar-menus">header bar menus</link> are generally 
recommended over menu bars, along with other design patterns for exposing controls on demand, such as <link 
xref="selection-mode">selection mode</link>, <link xref="action-bars">action bars</link>, and <link 
xref="popovers">popovers</link>.</p>
+<p>Menu bars increase the vertical footprint of an application’s user interface, introduce a large number of 
disclosure points, and function as a fixed set of inflexible options. For these reasons, <link 
xref="header-bars">header bars</link> and <link xref="header-bar-menus">header bar menus</link> are generally 
recommended over menu bars, along with other design patterns for exposing controls on demand, such as <link 
xref="selection-mode">selection mode</link>, <link xref="action-bars">action bars</link>, and <link 
xref="popovers">popovers</link>.</p>
 
 <p>At the same time, menu bars can still be an appropriate choice, particularly for applications that 
already incorporate a header bar. Some platforms also incorporate space for a menu bar in their user 
environment, and a menu model can be desirable for cross-platform integration purposes.</p>
 
@@ -198,7 +198,7 @@
 <tr>
 <td><p><gui>Properties…</gui></p></td>
 <td><p><keyseq><key>Alt</key><key>Return</key></keyseq></p></td>
-<td><p>Opens the document's <gui>Properties</gui> window. This may contain editable information, such as the 
document author's name, or read-only information, such as the number of words in the document, or a 
combination of both. The <keyseq><key>Alt</key><key>Return</key></keyseq> shortcut should not be provided 
where <key>Return</key> is most frequently used to insert a new line.</p></td>
+<td><p>Opens the document’s <gui>Properties</gui> window. This may contain editable information, such as the 
document author’s name, or read-only information, such as the number of words in the document, or a 
combination of both. The <keyseq><key>Alt</key><key>Return</key></keyseq> shortcut should not be provided 
where <key>Return</key> is most frequently used to insert a new line.</p></td>
 </tr>
 </tbody>
 </table>
@@ -244,10 +244,10 @@
 <section id="edit">
 <title>Edit</title>
 
-<p>The <gui>Edit</gui> menu contains items relating to editing both the document (clipboard handling, search 
and replace, and inserting special objects) and the user's preferences. <gui>Preferences</gui> are edited 
here rather than on a <gui>Settings</gui> menu, because:</p>
+<p>The <gui>Edit</gui> menu contains items relating to editing both the document (clipboard handling, search 
and replace, and inserting special objects) and the user’s preferences. <gui>Preferences</gui> are edited 
here rather than on a <gui>Settings</gui> menu, because:</p>
 
 <list>
-<item><p>most applications' preferences windows are accessed via a single menu item, and single-item menus 
offer poor usability</p></item>
+<item><p>most applications’ preferences windows are accessed via a single menu item, and single-item menus 
offer poor usability</p></item>
 <item><p>most applications already contain a suitable Edit menu.</p></item>
 </list>
 
@@ -389,7 +389,7 @@
 <section id="view">
 <title>View</title>
 
-<p>The <gui>View</gui> menu contains only items that affect the user's view of the current document. Do not 
place any items on the <gui>View</gui> menu that affect the content of the current document. (Exception: 
<guiseq><gui>View</gui><gui>Reload</gui></guiseq> may change the current contents if, for example, the 
document is a webpage that has been recently updated on the server).</p>
+<p>The <gui>View</gui> menu contains only items that affect the user’s view of the current document. Do not 
place any items on the <gui>View</gui> menu that affect the content of the current document. (Exception: 
<guiseq><gui>View</gui><gui>Reload</gui></guiseq> may change the current contents if, for example, the 
document is a webpage that has been recently updated on the server).</p>
 
 <table>
 <thead>
@@ -624,17 +624,17 @@
 <tr>
 <td><p><gui>Add Bookmark</gui></p></td>
 <td><p><keyseq><key>Ctrl</key><key>D</key></keyseq></p></td>
-<td><p>Adds a bookmark for the current document to the default bookmark list. Do not pop up a dialog asking 
for a title or location for the bookmark, instead choose sensible defaults (such as the document's title or 
filename as the bookmark name) and allow the user to change them later using the <gui>Edit Bookmarks</gui> 
feature.</p></td>
+<td><p>Adds a bookmark for the current document to the default bookmark list. Do not pop up a dialog asking 
for a title or location for the bookmark, instead choose sensible defaults (such as the document’s title or 
filename as the bookmark name) and allow the user to change them later using the <gui>Edit Bookmarks</gui> 
feature.</p></td>
 </tr>
 <tr>
 <td><p><gui>Edit Bookmarks</gui></p></td>
 <td><p><keyseq><key>Ctrl</key><key>B</key></keyseq></p></td>
-<td><p>Allows the user to edit the application's bookmark list. Open a window in which the user can arrange 
bookmarks into a hierarchy, move, copy, and delete bookmarks, and change their properties.</p></td>
+<td><p>Allows the user to edit the application’s bookmark list. Open a window in which the user can arrange 
bookmarks into a hierarchy, move, copy, and delete bookmarks, and change their properties.</p></td>
 </tr>
 <tr>
 <td><p>Bookmark List</p></td>
 <td><p>None</p></td>
-<td><p>The user's current list of bookmarks for the application.</p></td>
+<td><p>The user’s current list of bookmarks for the application.</p></td>
 </tr>
 </tbody>
 </table>
@@ -663,17 +663,17 @@
 <tr>
 <td><p><gui>Back</gui></p></td>
 <td><p><keyseq><key>Alt</key><key>Left</key></keyseq></p></td>
-<td><p>Navigates to the previous document in the browser's history list.</p></td>
+<td><p>Navigates to the previous document in the browser’s history list.</p></td>
 </tr>
 <tr>
 <td><p><gui>Forward</gui></p></td>
 <td><p><keyseq><key>Alt</key><key>Right</key></keyseq></p></td>
-<td><p>Navigates to the next document in the browser's history list.</p></td>
+<td><p>Navigates to the next document in the browser’s history list.</p></td>
 </tr>
 <tr>
 <td><p><gui>Up</gui></p></td>
 <td><p><keyseq><key>Alt</key><key>Up</key></keyseq></p></td>
-<td><p>Navigates to the current document's (or folder's) parent document (or folder). For a document 
browser, such as an online help viewer, this usually means navigating to the enclosing sub-section, section, 
chapter or contents page.</p></td>
+<td><p>Navigates to the current document’s (or folder’s) parent document (or folder). For a document 
browser, such as an online help viewer, this usually means navigating to the enclosing sub-section, section, 
chapter or contents page.</p></td>
 </tr>
 <tr>
 <td><p><gui>Up</gui></p></td>
@@ -737,13 +737,13 @@
 <section id="windows">
 <title>Windows</title>
 
-<p>The <gui>Windows</gui> menu contains commands that apply to all of the application's open windows. Only 
use a Windows menu in multiple document interface (MDI) applications.</p>
+<p>The <gui>Windows</gui> menu contains commands that apply to all of the application’s open windows. Only 
use a Windows menu in multiple document interface (MDI) applications.</p>
 
 <note><p>Use of MDI is discouraged, as they have a number of inherent usability problems.</p></note>
 
 <p>You may also label this menu <gui>Documents</gui>, <gui>Buffers</gui>, or similar according to the type 
of document handled by your application.</p>
 
-<p>The last items on this menu are a numbered list of the application's primary windows, for example 
<gui>1shoppinglist.abw</gui>. Selecting one of these items raises the corresponding window.</p>
+<p>The last items on this menu are a numbered list of the application’s primary windows, for example 
<gui>1shoppinglist.abw</gui>. Selecting one of these items raises the corresponding window.</p>
 
 <table>
 <thead>
@@ -777,7 +777,7 @@
 <section id="help">
 <title>Help</title>
 
-<p>The <gui>Help</gui> menu provides access to all online documentation for your application. This includes 
both the user guide, and the <gui>About</gui> window which includes a brief description of your application's 
functionality.</p>
+<p>The <gui>Help</gui> menu provides access to all online documentation for your application. This includes 
both the user guide, and the <gui>About</gui> window which includes a brief description of your application’s 
functionality.</p>
 
 <table>
 <thead>
@@ -796,7 +796,7 @@
 <tr>
 <td><p><gui>About</gui></p></td>
 <td><p>None</p></td>
-<td><p>Opens the About dialog for the application. Use the standard dialog provided by the GNOME libraries, 
which contains the name and version number of the application, a short description of the application's 
functionality, author contact details, copyright message and a pointer to the licence under which the 
application is made available.</p></td>
+<td><p>Opens the About dialog for the application. Use the standard dialog provided by the GNOME libraries, 
which contains the name and version number of the application, a short description of the application’s 
functionality, author contact details, copyright message and a pointer to the licence under which the 
application is made available.</p></td>
 </tr>
 </tbody>
 </table>
diff --git a/hig3/C/menus.page b/hig3/C/menus.page
index aa6ae9c..6ec0abd 100644
--- a/hig3/C/menus.page
+++ b/hig3/C/menus.page
@@ -31,7 +31,7 @@
 <section id="when-to-use">
 <title>When to use</title>
 
-<p>Primary actions and options are typically situated in an application's <link xref="header-bars">header 
bar</link>. The main role of menus is to host secondary options or actions, which may not be essential to the 
functioning of the application, or may not be used as frequently.</p>
+<p>Primary actions and options are typically situated in an application’s <link xref="header-bars">header 
bar</link>. The main role of menus is to host secondary options or actions, which may not be essential to the 
functioning of the application, or may not be used as frequently.</p>
 
 <p>Menus can reduce the visual footprint of your application, making it simpler at first glance, and 
highlighting primary functionality. They should be used when it is necessary to include actions and options 
that cannot be comfortably accommodated within other standard design patterns, toolbars in particular.</p>
 
diff --git a/hig3/C/notifications.page b/hig3/C/notifications.page
index f42531b..3265cae 100644
--- a/hig3/C/notifications.page
+++ b/hig3/C/notifications.page
@@ -20,7 +20,7 @@
 
 <p>Use notifications to inform the user about events they will be interested in while they are not using 
your application. This can include new messages in messaging applications, the completion of long-running 
tasks, reminders for calendars, and so on.</p>
 
-<p>Notifications shouldn't be used as a substitute for feedback that is provided by your application 
windows, which should be able to inform the user about events without the need for notifications.</p>
+<p>Notifications shouldn’t be used as a substitute for feedback that is provided by your application 
windows, which should be able to inform the user about events without the need for notifications.</p>
 
 </section>
 
@@ -64,7 +64,7 @@
 <section id="default-actions">
 <title>Default actions</title>
 
-<p>The default action should always dismiss the notification and raise a window belonging to the application 
that sent the notification. If the notification relates to a particular part of your application's user 
interface, the default action should display that part of the UI. The default action for a notification about 
a new email should show the relevant email message when activated, for example.</p>
+<p>The default action should always dismiss the notification and raise a window belonging to the application 
that sent the notification. If the notification relates to a particular part of your application’s user 
interface, the default action should display that part of the UI. The default action for a notification about 
a new email should show the relevant email message when activated, for example.</p>
 
 </section>
 
@@ -76,7 +76,7 @@
 <list>
 <item><p>Notification actions should be related to the content of the notification, and should not provide 
generic actions for your application. This ensures that each notification has a clear focus and 
purpose.</p></item>
 <item><p>Only use notification actions when the functionality that they provide is commonly 
required.</p></item>
-<item><p>Actions shold not replace user interface controls elsewhere - it should be possible to take the 
same actions from your application's windows.</p></item>
+<item><p>Actions shold not replace user interface controls elsewhere - it should be possible to take the 
same actions from your application’s windows.</p></item>
 <item><p>It is not necessary to always use notification actions, and many notifications will not require 
them.</p></item>
 <item><p>Notification actions should not duplicate the default action. For example, a new email notification 
does not need to include an Open button, since the default action should already perform this 
action.</p></item>
 </list>
diff --git a/hig3/C/pointer-and-touch-input.page b/hig3/C/pointer-and-touch-input.page
index 64fa84b..fe9f893 100644
--- a/hig3/C/pointer-and-touch-input.page
+++ b/hig3/C/pointer-and-touch-input.page
@@ -105,7 +105,7 @@
 <section id="touch-input">
 <title>Touch input</title>
 
-<p>Touch screens are also an increasingly common part of modern computer hardware, and applications created 
with GTK+ are likely to be used with hardware that incorporates a touch screen. To make the most of this 
hardware, and to conform to users' expectations, it is therefore important to consider touch input as a part 
of application design.</p>
+<p>Touch screens are also an increasingly common part of modern computer hardware, and applications created 
with GTK+ are likely to be used with hardware that incorporates a touch screen. To make the most of this 
hardware, and to conform to users’ expectations, it is therefore important to consider touch input as a part 
of application design.</p>
 
 <section id="application-touch-conventions">
 <title>Application touch conventions</title>
diff --git a/hig3/C/popovers.page b/hig3/C/popovers.page
index c2b2dec..bb27299 100644
--- a/hig3/C/popovers.page
+++ b/hig3/C/popovers.page
@@ -51,7 +51,7 @@
 
 <list>
 <item><p>A popover can just contain a menu, including submenus.</p></item>
-<item><p>You can combine a menu with other controls, such as buttons, sliders or text fields. However, don't 
mix too many different types of control, and try to group controls of the same type together.</p></item>
+<item><p>You can combine a menu with other controls, such as buttons, sliders or text fields. However, don’t 
mix too many different types of control, and try to group controls of the same type together.</p></item>
 <item><p>Popovers can be given a heading to clarify their purpose.</p></item>
 <item><p><gui>Close</gui> or <gui>Done</gui> buttons are not usually required in a popover.</p></item>
 </list>
diff --git a/hig3/C/primary-windows.page b/hig3/C/primary-windows.page
index ded6de6..5c79236 100644
--- a/hig3/C/primary-windows.page
+++ b/hig3/C/primary-windows.page
@@ -56,7 +56,7 @@
 <title>General guidelines</title>
 
 <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 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 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>
diff --git a/hig3/C/progress-bars.page b/hig3/C/progress-bars.page
index 55a566a..33e2f1c 100644
--- a/hig3/C/progress-bars.page
+++ b/hig3/C/progress-bars.page
@@ -48,9 +48,9 @@
 
 <list>
 <item><p>Accuracy is preferable for progress bars. Where possible, use a time-remaining progress bar, 
followed by typical-time. Try to avoid using indeterminate progress bars.</p></item>
-<item><p>Ensure that time-remaining and typical-time progress bars measure an operation's total time or 
total work, not just that of a single step.</p></item>
+<item><p>Ensure that time-remaining and typical-time progress bars measure an operation’s total time or 
total work, not just that of a single step.</p></item>
 <item><p>Update time-remaining progress bars when changes occur that will cause the operation to finish more 
quickly or more slowly.</p></item>
-<item><p>When using a typical-time progress bar, if your application overestimates the completed amount of 
work, the length of the bar can indicate "almost complete" until the operation is complete. If your 
application underestimates how much work is complete, fill the remaining portion of the bar when the 
operation is complete.</p></item>
+<item><p>When using a typical-time progress bar, if your application overestimates the completed amount of 
work, the length of the bar can indicate “almost complete” until the operation is complete. If your 
application underestimates how much work is complete, fill the remaining portion of the bar when the 
operation is complete.</p></item>
 </list>
 
 </section>
diff --git a/hig3/C/search.page b/hig3/C/search.page
index 61b57c8..d70c747 100644
--- a/hig3/C/search.page
+++ b/hig3/C/search.page
@@ -37,7 +37,7 @@
 In primary windows, the search bar is typically hidden until it is activated by the user. There are three 
common ways to activate search in this context:</p>
 
 <list>
-<item><p>Typing when a text entry field is not focused should activate search, and the entered text should 
be added to the search field. This is called "type to search".</p></item>
+<item><p>Typing when a text entry field is not focused should activate search, and the entered text should 
be added to the search field. This is called “type to search”.</p></item>
 <item><p>The keyboard shortcut for search (<keyseq><key>Ctrl</key><key>F</key></keyseq>).</p></item>
 <item><p>A search button in the header bar should allow the search bar to be displayed (the search button 
should toggle).</p></item>
 </list>
@@ -50,7 +50,7 @@ In primary windows, the search bar is typically hidden until it is activated by
 <title>Search results</title>
 
 <list>
-<item><p>Search should be 'live' wherever possible - the content view should update to display search 
results as they are entered.</p></item>
+<item><p>Search should be “live” wherever possible - the content view should update to display search 
results as they are entered.</p></item>
 <item><p>In order to be effective, it is important that search results are quickly returned.</p></item>
 <item><p>If a search term does not return any results, ensure that feedback is given in the content view. 
Often a simple "No results" label is sufficient.</p></item>
 </list>
diff --git a/hig3/C/sidebar-lists.page b/hig3/C/sidebar-lists.page
index 25dcd36..f9b8491 100644
--- a/hig3/C/sidebar-lists.page
+++ b/hig3/C/sidebar-lists.page
@@ -29,7 +29,7 @@
 <p>Sidebar lists also provide a possible alternative to browser-style navigation. They have a number of 
advantages here:</p>
 
 <list>
-<item><p>When content items have a narrow width, and don't require an immersive experience. A sidebar would 
be inappropriate for browsing videos for this reason, but is well-suited to contacts.</p></item>
+<item><p>When content items have a narrow width, and don’t require an immersive experience. A sidebar would 
be inappropriate for browsing videos for this reason, but is well-suited to contacts.</p></item>
 <item><p>When content items are dynamic. For messaging applications, where new content items appear or old 
ones are updated, a sidebar list provides the ability for someone to view one item while simultaneously being 
aware of updates to the overall message list.</p></item>
 <item><p>When it is possible to filter a collection of content, and there are a large number of 
filters.</p></item>
 </list>
diff --git a/hig3/C/sliders.page b/hig3/C/sliders.page
index aac1fde..3661fa9 100644
--- a/hig3/C/sliders.page
+++ b/hig3/C/sliders.page
@@ -53,7 +53,7 @@
 <item><p>In other cases, label the slider with a text label above it or to its left, using <link 
xref="writing-style#capitalization">sentence capitalization</link>. Provide an <link 
xref="keyboard-input#access-keys">access key</link> in the label that allows the user to give focus directly 
to the slider.</p></item>
 </list></item>
 <item><p>Mark significant values along the length of the slider with text or tick marks. For example the 
left, right and center points on an audio balance control in Figure 6-7.</p></item>
-<item><p>For large ranges of integers (more than about 20), and for ranges of floating point numbers, 
consider providing a <link xref="text-fields">text box</link> or <link xref="spin-boxes">spin box</link> that 
is linked to the slider's value. This allows the user to quickly set or fine-tune the setting more easily 
than they could with the slider control alone.</p></item>
+<item><p>For large ranges of integers (more than about 20), and for ranges of floating point numbers, 
consider providing a <link xref="text-fields">text box</link> or <link xref="spin-boxes">spin box</link> that 
is linked to the slider’s value. This allows the user to quickly set or fine-tune the setting more easily 
than they could with the slider control alone.</p></item>
 </list>
 
 </section>
diff --git a/hig3/C/spin-boxes.page b/hig3/C/spin-boxes.page
index 0d5fe6b..c4de5c2 100644
--- a/hig3/C/spin-boxes.page
+++ b/hig3/C/spin-boxes.page
@@ -45,7 +45,7 @@
 <p>In some cases, it is appropriate to link a spin button with a slider. This combination allows both 
approximate control and the entry of specific values. However, it is only useful if you want to cater to 
people who may know a specific value that they want to use. Use a slider when:</p>
 
 <list>
-<item><p>Immediate feedback for changes in the spin box's value is possible (such as in the case of image 
editing).</p></item>
+<item><p>Immediate feedback for changes in the spin box’s value is possible (such as in the case of image 
editing).</p></item>
 <item><p>It is useful for the user to control the rate of change of the value in real time. For example, to 
monitor the effects of a color change in a live preview window as they drag the RGB sliders.</p></item>
 </list>
 
@@ -56,7 +56,7 @@
 
 <list>
 <item><p>Label the spin box with a text label above it or to its left, using sentence capitalization. 
Provide an access key in the label that allows the user to give focus directly to the spin box.</p></item>
-<item><p>Right-justify the contents of spin boxes, unless the convention in the user's locale demands 
otherwise. This is useful in windows where the user might want to compare two numerical values in the same 
column of controls. In this case, ensure the right edges of the relevant controls are also aligned.</p></item>
+<item><p>Right-justify the contents of spin boxes, unless the convention in the user’s locale demands 
otherwise. This is useful in windows where the user might want to compare two numerical values in the same 
column of controls. In this case, ensure the right edges of the relevant controls are also aligned.</p></item>
 </list>
 
 </section>
diff --git a/hig3/C/tabs.page b/hig3/C/tabs.page
index ec4b1a9..3183a69 100644
--- a/hig3/C/tabs.page
+++ b/hig3/C/tabs.page
@@ -24,7 +24,7 @@
 
 <title>Tabs</title>
 
-<p>Tabs provide a way to break down a window into a series of views. They come in two primary forms: fixed 
and dynamic. Fixed tabs provide an immutable set of defined views that are built into a user interface, 
primarily dialog windows. Dynamic tabs allow a user to view multiple documents or locations within an 
application's primary window.</p>
+<p>Tabs provide a way to break down a window into a series of views. They come in two primary forms: fixed 
and dynamic. Fixed tabs provide an immutable set of defined views that are built into a user interface, 
primarily dialog windows. Dynamic tabs allow a user to view multiple documents or locations within an 
application’s primary window.</p>
 
 <media type="image" mime="image/svg" src="figures/ui-elements/tabs.svg"/>
 
@@ -45,7 +45,7 @@
 <item><p>Label tabs with <link xref="writing-style#capitalization">header capitalization</link>, and use 
nouns rather than verbs, for example <gui>Font</gui> or <gui>Alignment</gui>. Try to give tab labels a 
similar length.</p></item>
 <item><p>Do not design tabs such that changing controls on one page affects the controls on any other page. 
Users are unlikely to discover such dependencies.</p></item>
 <item><p>If a control affects every tab, place it outside the tabs.</p></item>
-<item><p>Use tabs that are proportional to the width of their labels. Don't just set all the tabs to the 
same width, as this makes them harder to scan visually, and limits the number of tabs you can display without 
scrolling.</p></item>
+<item><p>Use tabs that are proportional to the width of their labels. Don’t just set all the tabs to the 
same width, as this makes them harder to scan visually, and limits the number of tabs you can display without 
scrolling.</p></item>
 </list>
 
 </section>
@@ -64,7 +64,7 @@
 
 <p>If tabs are an important part of the application, make the tab bar permanently visible, so that the first 
tab is visible when the application is launched. A new tab button can also be placed in the header bar or 
toolbar.</p>
 
-<p>Dynamic tabs can also be used in cases where tabs will not always be used, or do not form a core part of 
the application's functionality. In these cases, tabs provide an additional extra function for those users 
who want to use them, without introducing superfluous controls for those who only view a single location or 
content item within each window.</p>
+<p>Dynamic tabs can also be used in cases where tabs will not always be used, or do not form a core part of 
the application’s functionality. In these cases, tabs provide an additional extra function for those users 
who want to use them, without introducing superfluous controls for those who only view a single location or 
content item within each window.</p>
 
 <p>In these cases, the tab bar should only be displayed when two or more tabs are open, and a new tab button 
should not be displayed in the header bar or toolbar. Keyboard shortcuts or menu items should be used to 
allow new tabs to be opened.</p>
 
diff --git a/hig3/C/toolbars.page b/hig3/C/toolbars.page
index f766e80..1f6c355 100644
--- a/hig3/C/toolbars.page
+++ b/hig3/C/toolbars.page
@@ -43,9 +43,9 @@
 <list>
 <item><p>Only include controls for the most important functions. Having too many toolbar controls reduces 
their efficiency by making them harder to find, and too many rows of toolbars reduces the amount of screen 
space available to the rest of the application.</p></item>
 <item><p>Utilize conventions for toolbars to increase familiarity. For example, the main toolbar in an 
office application will nearly always have New, Open and Save as its first three toolbar buttons. Similarly, 
the first few buttons in a browser application should always include Back, Forward, Stop and Reload, in that 
order.</p></item>
-<item><p>Place only the most commonly-used application functions on your toolbars. Don't just add buttons 
for every menu item.</p></item>
+<item><p>Place only the most commonly-used application functions on your toolbars. Don’t just add buttons 
for every menu item.</p></item>
 <item><p>If you are using a <link xref="menu-bars">menu bar</link>, ensure that it includes all the 
functions that appear on you toolbar, either directly (i.e. an equivalent menu item) or indirectly (e.g. in 
the <guiseq><gui>Options</gui><gui>Settings</gui></guiseq> dialog).</p></item>
-<item><p>Toolbars shouldn't include buttons for <gui>Help</gui>, <gui>Close</gui> or <gui>Quit</gui>, as 
these are rarely used and the space is better used for more useful controls. Similarly, only provide buttons 
for <gui>Undo</gui>, <gui>Redo</gui> and the standard clipboard functions if there is space on the toolbar to 
do so without sacrificing more useful, application-specific controls.</p></item>
+<item><p>Toolbars shouldn’t include buttons for <gui>Help</gui>, <gui>Close</gui> or <gui>Quit</gui>, as 
these are rarely used and the space is better used for more useful controls. Similarly, only provide buttons 
for <gui>Undo</gui>, <gui>Redo</gui> and the standard clipboard functions if there is space on the toolbar to 
do so without sacrificing more useful, application-specific controls.</p></item>
 <item><p>Toolbar <link xref="buttons">buttons</link> should have a relief, and icon buttons should use <link 
xref="icons-and-artwork#color-vs-symbolic">symbolic icons</link>.</p></item>
 </list>
 
diff --git a/hig3/C/writing-style.page b/hig3/C/writing-style.page
index 1ee6ab6..c23d617 100644
--- a/hig3/C/writing-style.page
+++ b/hig3/C/writing-style.page
@@ -35,7 +35,7 @@
 <list>
 <item><p>Keep text short and to the point. This improves speed of comprehension for the user. It also 
reduces the expansion of text when translated (remember that translated English text can expand up to 30% in 
some languages).</p></item>
 <item><p>Do not shorten your text to the point of losing meaning. A three-word label that provides clear 
information is better than a one-word label that is ambiguous or vague. Try to find the fewest possible words 
to satisfactorily convey the meaning of your label.</p></item>
-<item><p>Use words, phrases, and concepts that are familiar to the people who will be using your 
application, rather than terms from the underlying system. This may mean using terms that are associated with 
the tasks your application supports. For example, in medicine, the paper folder that contains patient 
information is called a "chart." Hence, a medical application might refer to a patient record as a "chart" 
rather than as a "patient database record".</p></item>
+<item><p>Use words, phrases, and concepts that are familiar to the people who will be using your 
application, rather than terms from the underlying system. This may mean using terms that are associated with 
the tasks your application supports. For example, in medicine, the paper folder that contains patient 
information is called a “chart”. Hence, a medical application might refer to a patient record as a “chart” 
rather than as a “patient database record”.</p></item>
 <item><p>Use the standard GNOME terms when referring to parts of the user interface, such as ‘pointer’ and 
‘window’. You can find a full list of these in the GNOME Documentation Style Guide, Recommended 
Terminology.</p></item>
 <item><p>Avoid repetition where possible.</p></item>
 </list>
@@ -60,7 +60,7 @@
 
 <p>(Verbs with three or fewer letters should be capitalized: Be, Are, Is, Put, See, Add.)</p>
 
-<p>For example: "Create a Document", "Find and Replace".</p>
+<p>For example: “Create a Document”, “Find and Replace”.</p>
 
 <p>Header capitalization should be used for any headings, including header bar headings and page, tab and 
menu titles. It should also be used for short control labels that do not normally form proper sentences, such 
as button and switch labels and menu items.</p>