[gnome-devel-docs] HIG: Use unicode

[David King <davidk src gnome org>]

commit 0cd23f10b76c0c53e47895e9edba54bf850fd23a
Author: Rafael Fontenelle <rffontenelle gmail com>
Date:   Tue Sep 25 10:18:35 2018 +0000

    HIG: Use unicode

 hig/C/application-basics.page      |  2 +-
 hig/C/button-menus.page            |  4 ++--
 hig/C/buttons.page                 |  2 +-
 hig/C/design-principles.page       |  4 ++--
 hig/C/dialogs.page                 |  4 ++--
 hig/C/full-screen.page             |  2 +-
 hig/C/header-bars.page             | 12 ++++++------
 hig/C/icons-and-artwork.page       |  4 ++--
 hig/C/menu-bars.page               |  4 ++--
 hig/C/menus.page                   |  6 +++---
 hig/C/notifications.page           |  2 +-
 hig/C/overlaid-controls.page       |  4 ++--
 hig/C/pointer-and-touch-input.page |  4 ++--
 hig/C/primary-windows.page         |  2 +-
 hig/C/progress-spinners.page       |  2 +-
 hig/C/search.page                  |  4 ++--
 hig/C/tabs.page                    |  2 +-
 hig/C/text-fields.page             |  2 +-
 hig/C/typography.page              |  2 +-
 hig/C/visual-layout.page           |  6 +++---
 hig/C/writing-style.page           |  2 +-
 21 files changed, 38 insertions(+), 38 deletions(-)
---
diff --git a/hig/C/application-basics.page b/hig/C/application-basics.page
index 0b7839f5..55528eac 100644
--- a/hig/C/application-basics.page
+++ b/hig/C/application-basics.page
@@ -52,7 +52,7 @@
 <item><p>It needs to identify your application in the systems where it is installed and run.</p></item>
 </list>
 
-<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>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>
 
diff --git a/hig/C/button-menus.page b/hig/C/button-menus.page
index b27fdea2..cd324bfa 100644
--- a/hig/C/button-menus.page
+++ b/hig/C/button-menus.page
@@ -34,7 +34,7 @@
 <p>Menus provide a clear and consistent way to present diverse sets of actions and settings. At the same 
time, a popover with embedded controls, like buttons, sliders, spin buttons, lists and text entries, can 
provide a more effective interface for many tasks.</p>
 
 <list>
-<item><p>Evaluate each function within a button menu, in order to decide whether it would be better served 
by a different <link xref="ui-elements">user interface element</link>. While simple actions or settings can 
be effectively represented by menu items, others cannot. In particular, sliders, spin buttons, switches and 
text entries provide functionality that cannot be easily reproduced with a menu. Likewise, some entries might 
be better represented as icons rather than text - in which case, buttons could be more appropriate than a 
menu.</p></item>
+<item><p>Evaluate each function within a button menu, in order to decide whether it would be better served 
by a different <link xref="ui-elements">user interface element</link>. While simple actions or settings can 
be effectively represented by menu items, others cannot. In particular, sliders, spin buttons, switches and 
text entries provide functionality that cannot be easily reproduced with a menu. Likewise, some entries might 
be better represented as icons rather than text — in which case, buttons could be more appropriate than a 
menu.</p></item>
 <item><p>If a menu button contains a small number of items that can be more effectively represented as a 
group of controls, a popover containing different interface elements can be a more interesting and efficient 
user interface. However, this approach can easily become over-complex for larger and more diverse button 
menus.</p></item>
 <item><p>A menu button can be combined with a small number of other interface elements, such as buttons, 
sliders and switches (see example below). This can enable some menu items to be presented in a more 
space-efficient manner, or to provide interactions that are not possible with a standard menu. However, be 
careful not to mix too many types of control or make the menu too complex in the process.</p></item>
 </list>
@@ -47,7 +47,7 @@
 <title>General guidelines</title>
 
 <list>
-<item><p>Each context - whether it is a view or delineated area of your interface - should only include one 
generic button menu.</p></item>
+<item><p>Each context — whether it is a view or delineated area of your interface — should only include one 
generic button menu.</p></item>
 <item><p>Ensure that single purpose button menus are effectively labelled. While an icon is more compact, 
only use them when they will be commonly understood by your users. The <link xref="icons-and-artwork">icon 
usage guidelines</link> provide more advice on this.</p></item>
 <item><p>Single purpose buttons should be clearly and consistently defined. Their menu items should have an 
obvious relationship with the overall purpose of the menu.</p></item>
 <item><p>While multiple button menus can be used simultaneously, be careful about introducing too many 
disclosure points into your user interface. The more of these that you introduce, the harder it will be for 
users to find the controls they need, and human error will be increased.</p></item>
diff --git a/hig/C/buttons.page b/hig/C/buttons.page
index 493488ea..ad4c5453 100644
--- a/hig/C/buttons.page
+++ b/hig/C/buttons.page
@@ -37,7 +37,7 @@
 <title>General Guidelines</title>
 
 <list>
-<item><p>A button can contain an icon, button, or - more unusually - an image. Follow the icons and artwork 
guidelines when deciding which to use.</p></item>
+<item><p>A button can contain an icon, button, or — more unusually — an image. Follow the icons and artwork 
guidelines when deciding which to use.</p></item>
 <item><p>After pressing a button, the user should expect to see the result of their action within 1 
second.</p></item>
 <item><p>Do not use more than one or two different widths of button in the same window, and make all of them 
the same height. This will help give a pleasing uniform visual appearance to your window that makes it easier 
to use.</p></item>
 <item><p>Do not assign actions to double-clicking or right-clicking a button. Users are unlikely to discover 
these actions, and if they do, it will distort their expectations of other buttons on the desktop.</p></item>
diff --git a/hig/C/design-principles.page b/hig/C/design-principles.page
index 1aa8566a..21cad5ff 100644
--- a/hig/C/design-principles.page
+++ b/hig/C/design-principles.page
@@ -27,7 +27,7 @@
 <section id="complexity">
 <title>Keep user interface complexity to a minimum</title>
 
-<p>Every control or piece of information that you add to your application creates additional work for users, 
and increases the complexity of your application - potentially making it more difficult and less pleasurable 
to use. Therefore, only include essential controls and information in your application interface.</p>
+<p>Every control or piece of information that you add to your application creates additional work for users, 
and increases the complexity of your application — potentially making it more difficult and less pleasurable 
to use. Therefore, only include essential controls and information in your application interface.</p>
 
 <p>When adding a new control or piece of information, always take a moment to question whether it is 
necessary.</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/hig/C/dialogs.page b/hig/C/dialogs.page
index 61f64fbe..609beab7 100644
--- a/hig/C/dialogs.page
+++ b/hig/C/dialogs.page
@@ -59,7 +59,7 @@
 <section id="message-dialog-examples">
 <title>Examples</title>
 
-<p>Confirmation dialogs use a message dialog to check - or confirm - that the user wants to carry out an 
action. They have two buttons: one to confirm that the action should be carried out and one to cancel the 
action.</p>
+<p>Confirmation dialogs use a message dialog to check — or confirm — that the user wants to carry out an 
action. They have two buttons: one to confirm that the action should be carried out and one to cancel the 
action.</p>
 
 <note style="tip"><p>Confirmation dialogs will often be accidentally or automatically acknowledged, and will 
not always prevent mistakes from happening. It is often better to provide undo functionality 
instead.</p></note>
 
@@ -75,7 +75,7 @@
 
 <media type="image" mime="image/svg" src="figures/patterns/action-dialog.svg"/>
 
-<p>Action dialogs present options and information about a specific action before it is carried out. They 
have a heading (which typically describes the action) and two primary buttons - one which allows the action 
to be carried out and one which cancels it.</p>
+<p>Action dialogs present options and information about a specific action before it is carried out. They 
have a heading (which typically describes the action) and two primary buttons — one which allows the action 
to be carried out and one which cancels it.</p>
 
 <p>Sometimes, the user may be required to choose options before an action can be carried out. In these 
cases, the affirmative dialog button should be insensitive until the required options have been selected.</p>
 
diff --git a/hig/C/full-screen.page b/hig/C/full-screen.page
index 1eb622ec..61746f5c 100644
--- a/hig/C/full-screen.page
+++ b/hig/C/full-screen.page
@@ -31,7 +31,7 @@
 <title>Guidelines</title>
 
 <list>
-<item><p>If an application uses different views, it is only necessary to enable fullscreen for those views 
where it is useful - primarily those that display content items.</p></item>
+<item><p>If an application uses different views, it is only necessary to enable fullscreen for those views 
where it is useful — primarily those that display content items.</p></item>
 <item><p>Fullscreen can be triggered automatically when a content item is opened, or can be offered as a 
mode that can be activated by the user.</p></item>
 <item><p>If fullscreen is being offered as a mode that users activate, judge how prominent to make the 
control to enter fullscreen according to how often it will be used. Typically, a fullscreen button should be 
placed in the <link xref="header-bars">header bar</link> or <link xref="header-bar-menus">header bar 
menu</link>.</p></item>
 <item><p>When fullscreen is active:</p>
diff --git a/hig/C/header-bars.page b/hig/C/header-bars.page
index c5aece0a..b20db00b 100644
--- a/hig/C/header-bars.page
+++ b/hig/C/header-bars.page
@@ -20,9 +20,9 @@
 <p>Header bars are a common horizontal element which are placed at the top of windows. They play a number of 
roles:</p>
 
 <list>
-<item><p>Window controls - header bars allow windows to be moved by dragging, include window control buttons 
(typically a single close button), and provide access to a window controls menu.</p></item>
-<item><p>Headings - a key role of a header bar is to provide context for the content of the window, either 
through a heading or view switcher.</p></item>
-<item><p>Controls - header bars provide a place for key controls, typically in the form of 
buttons.</p></item>
+<item><p>Window controls — header bars allow windows to be moved by dragging, include window control buttons 
(typically a single close button), and provide access to a window controls menu.</p></item>
+<item><p>Headings — a key role of a header bar is to provide context for the content of the window, either 
through a heading or view switcher.</p></item>
+<item><p>Controls — header bars provide a place for key controls, typically in the form of 
buttons.</p></item>
 </list>
 
 <section id="when-to-use">
@@ -39,7 +39,7 @@
 
 <p>Header bars can contain key controls for the window, which can be placed on the left and right-hand side 
of the header bar. Examples of these controls include buttons for navigating back and forward, search, and 
selecting content.</p>
 
-<p>Ensure that your header bar only contains a small number of key controls - this will help users to 
understand the primary functionality provided by the window, and will ensure that the window can be resized 
to narrow widths.</p>
+<p>Ensure that your header bar only contains a small number of key controls — this will help users to 
understand the primary functionality provided by the window, and will ensure that the window can be resized 
to narrow widths.</p>
 
 <p>If a window requires more controls than can be comfortably accommodated within the header bar, additional 
functionality can be included within a header bar menu.</p>
 
@@ -48,7 +48,7 @@
 <section id="dynamic">
 <title>Header bars are dynamic</title>
 
-<p>A header bar can - and should - update along with view or mode changes. This ensures that header bar 
controls are always relevant to the current context.</p>
+<p>A header bar can — and should — update along with view or mode changes. This ensures that header bar 
controls are always relevant to the current context.</p>
 
 <p>If the window includes multiple views (accessed through a <link xref="view-switchers">view 
switcher</link>), the header bar can include different controls for each view.</p>
 
@@ -61,7 +61,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, center 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/hig/C/icons-and-artwork.page b/hig/C/icons-and-artwork.page
index e0401678..7ff6391d 100644
--- a/hig/C/icons-and-artwork.page
+++ b/hig/C/icons-and-artwork.page
@@ -23,7 +23,7 @@
 
 <p>Two styles of icon are used in GNOME 3: full-color and symbolic icons.</p>
 
-<p>Full-color icons are colorful and detailed, and are optimized for larger sizes. They are defined as 
128x128px SVGs, and are sharpest when scaled up in multiples of 128 (such as 256✕256 and 512✕512).The design 
of full-color icons also allows them to be rendered sharp at 64x64px and 32x32px, but is not advised to make 
them any smaller.</p>
+<p>Full-color icons are colorful and detailed, and are optimized for larger sizes. They are defined as 
128×128px SVGs, and are sharpest when scaled up in multiples of 128 (such as 256✕256 and 512✕512).The design 
of full-color icons also allows them to be rendered sharp at 64×64px and 32×32px, but is not advised to make 
them any smaller.</p>
 
 <media type="image" mime="image/png" src="figures/icons/fullcolor-v-symbolic.svg"/>
 
@@ -64,7 +64,7 @@
 <p>Other things to consider when using icons:</p>
 
 <list>
-<item><p>Think about 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>
+<item><p>Think about 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>
 <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>
 
diff --git a/hig/C/menu-bars.page b/hig/C/menu-bars.page
index d2481c2d..a826fd09 100644
--- a/hig/C/menu-bars.page
+++ b/hig/C/menu-bars.page
@@ -93,8 +93,8 @@
 <title>General guidelines</title>
 
 <list>
-<item><p>The menubar is normally visible at all times and is always accessible from the keyboard, so make 
all the commands available in your application available on the menubar. (This guideline is unique to menu 
bars - other menus should not seek to reproduce functionality that is made available by other 
controls).</p></item>
-<item><p>Treat <link xref="application-menus">application menus</link> as part of the menu bar - it is not 
necessary to reproduce items from the application menu in other menus.</p></item>
+<item><p>The menubar is normally visible at all times and is always accessible from the keyboard, so make 
all the commands available in your application available on the menubar. (This guideline is unique to menu 
bars — other menus should not seek to reproduce functionality that is made available by other 
controls).</p></item>
+<item><p>Treat <link xref="application-menus">application menus</link> as part of the menu bar — it is not 
necessary to reproduce items from the application menu in other menus.</p></item>
 <item><p>Do not disable menu titles. Allow the user to explore the menu, even though there might be no 
available items on it at that time.</p></item>
 <item><p>Menu titles on a menubar are single words with their first letter capitalized. Do not use spaces in 
menu titles, as this makes them easily-mistaken for two separate menu titles. Do not use compound words (such 
as <gui>WindowOptions</gui>) or hyphens (such as <gui>Window-Options</gui>) to circumvent this 
guideline.</p></item>
 <item><p>Do not provide a mechanism for hiding the menubar, as this may be activated accidentally. Some 
users will not be able to figure out how to get the menu bar back in this case.</p></item>
diff --git a/hig/C/menus.page b/hig/C/menus.page
index f482bcd9..3da13d49 100644
--- a/hig/C/menus.page
+++ b/hig/C/menus.page
@@ -47,12 +47,12 @@
 
 <p>Submenus should contain between three and six items, and should never contain other submenus.</p>
 
-<p>Organize similar menu items into groups using dividers - this will make them easier to understand and 
quicker to use. When creating groups:</p>
+<p>Organize similar menu items into groups using dividers — this will make them easier to understand and 
quicker to use. When creating groups:</p>
 
 <list>
 <item><p>Order groups and group items logically, either by importance, task order, or expected frequency of 
use. Items at the top and bottom of the menu are more noticeable and easily targeted, so reserve these 
locations for particularly important or interesting functionality.</p></item>
 <item><p>Place single-item groups at the top or bottom of the menu, or group them together with other single 
items.</p></item>
-<item><p>Do not mix different types of menu item within each group - actions, check box and radio button 
items should be kept separate.</p></item>
+<item><p>Do not mix different types of menu item within each group — actions, check box and radio button 
items should be kept separate.</p></item>
 </list>
 
 </section>
@@ -64,7 +64,7 @@
 <item><p>Provide an <link xref="keyboard-input#access-keys">access key</link> for every menu item. You may 
use the same access key on different menus in your application, but avoid duplicating access keys on the same 
menu. Note that unlike other controls, once a menu is displayed, its access keys may be used by just typing 
the letter; it is not necessary to press the Alt key at the same time.</p></item>
 <item><p>Label menu items with verbs for commands and adjectives for settings, using <link 
xref="writing-style#capitalization">header capitalization</link>.</p></item>
 <item><p>Use <link xref="writing-style#ellipses">ellipses</link> when a menu item requires further input 
from the user to complete an action.</p></item>
-<item><p>Two linked actions can be combined into a single menu item, by changing the label when the item is 
selected. For example, a <gui>Play</gui> item may change to <gui>Pause</gui>. However, only use this type of 
item when actions are logical opposites which are obvious to users. Likewise, do not use this technique for 
settings - use check boxes or radio buttons instead.</p></item>
+<item><p>Two linked actions can be combined into a single menu item, by changing the label when the item is 
selected. For example, a <gui>Play</gui> item may change to <gui>Pause</gui>. However, only use this type of 
item when actions are logical opposites which are obvious to users. Likewise, do not use this technique for 
settings — use check boxes or radio buttons instead.</p></item>
 </list>
 
 </section>
diff --git a/hig/C/notifications.page b/hig/C/notifications.page
index 3b970031..489220f5 100644
--- a/hig/C/notifications.page
+++ b/hig/C/notifications.page
@@ -78,7 +78,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 should 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 should 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/hig/C/overlaid-controls.page b/hig/C/overlaid-controls.page
index 78e4707d..4caba728 100644
--- a/hig/C/overlaid-controls.page
+++ b/hig/C/overlaid-controls.page
@@ -21,7 +21,7 @@
 <section id="when-to-use">
 <title>When to use</title>
 
-<p>Since overlaid controls hide when they are not in use, they help to provide an uncluttered viewing 
experience. They are appropriate when it is desirable to present a clean and distraction-free view on a 
content item - this is particularly (although not exclusively) appropriate for images and video.</p>
+<p>Since overlaid controls hide when they are not in use, they help to provide an uncluttered viewing 
experience. They are appropriate when it is desirable to present a clean and distraction-free view on a 
content item — this is particularly (although not exclusively) appropriate for images and video.</p>
 
 <p>Overlaid controls may be inappropriate if they obscure relevant parts of the content below. Image editing 
controls may interfere with the ability to see their effects, for example. In these cases, controls should 
not be overlaid.</p>
 
@@ -34,7 +34,7 @@
 <item><p>Follow established conventions for this type of control, such as left/right browse buttons in image 
viewers, and player controls at the bottom for video.</p></item>
 <item><p>Controls should be displayed when the pointer is moved over the content, or when it is tapped (on 
touch devices).</p></item>
 <item><p>Overlaid controls can be attached to the edge of the content/window, or can be free-floating. <link 
xref="action-bars">Action bars</link> can be treated as overlaid controls.</p></item>
-<item><p>Use the standard "OSD" theme style for overlaid controls.</p></item>
+<item><p>Use the standard “OSD” theme style for overlaid controls.</p></item>
 </list>
 
 </section>
diff --git a/hig/C/pointer-and-touch-input.page b/hig/C/pointer-and-touch-input.page
index 5b61e5f3..4b3e4c33 100644
--- a/hig/C/pointer-and-touch-input.page
+++ b/hig/C/pointer-and-touch-input.page
@@ -21,7 +21,7 @@
 <section id="pointer-input">
 <title>Pointer input</title>
 
-<p>A pointing device is any input device that allows the manipulation of a pointer - typically represented 
as an arrow, and often called a cursor - on screen. While mice and touchpads are the most common, there are a 
wide variety of such devices, including graphics tablets, track balls, track points and joysticks.</p>
+<p>A pointing device is any input device that allows the manipulation of a pointer — typically represented 
as an arrow, and often called a cursor — on screen. While mice and touchpads are the most common, there are a 
wide variety of such devices, including graphics tablets, track balls, track points and joysticks.</p>
 
 <section id="primary-and-secondary-buttons">
 <title>Primary and secondary buttons</title>
@@ -127,7 +127,7 @@
 <tr>
 <td><media type="image" mime="image/png" src="figures/touch/tap.svg"/></td>
 <td><p>Tap on an item.</p></td>
-<td><p>Primary action. Item opens - photo is shown full size, application launches, song starts 
playing.</p></td>
+<td><p>Primary action. Item opens — photo is shown full size, application launches, song starts 
playing.</p></td>
 </tr>
 <tr>
 <td colspan="3"><p><em style="strong">Press and hold</em></p></td>
diff --git a/hig/C/primary-windows.page b/hig/C/primary-windows.page
index 85bf1682..11ebd9ff 100644
--- a/hig/C/primary-windows.page
+++ b/hig/C/primary-windows.page
@@ -73,7 +73,7 @@
 <item><p>A single primary window should always be displayed when your application is launched.</p></item>
 <item><p>If your application launcher is activated 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>
+<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>The guidelines on <link xref="display-compatibility">display compatibility</link> are particularly 
relevant for primary windows: be careful to ensure that they follow the advice on minimum display sizes, 
display orientation, and half-screen snap.</p></item>
 <item><p><gui>Quit</gui> should close all primary windows.</p></item>
diff --git a/hig/C/progress-spinners.page b/hig/C/progress-spinners.page
index b2cf5f4e..a267244b 100644
--- a/hig/C/progress-spinners.page
+++ b/hig/C/progress-spinners.page
@@ -40,7 +40,7 @@
 <list>
 <item><p>If an operation can vary in how long it takes, use a timeout to only show a progress spinner after 
three seconds have elapsed. A progress indication is not needed for lengths of time below this.</p></item>
 <item><p>Place progress spinners close to or within the user interface elements they relate to. If a button 
triggers a long-running operation, the spinner can be placed next to that button, for example. When loading 
content, the spinner should be placed within the area where that content will appear.</p></item>
-<item><p>Generally, only one progress spinner should be displayed at once. Avoid showing a large number of 
spinners simultaneously - this will often be visually overwhelming.</p></item>
+<item><p>Generally, only one progress spinner should be displayed at once. Avoid showing a large number of 
spinners simultaneously — this will often be visually overwhelming.</p></item>
 <item><p>A label can be shown next to a spinner if it is helpful to clarify the task which a spinner relates 
to.</p></item>
 <item><p>If a spinner is displayed for a long time, a label can indicate both the identity of the task and 
progress through it. This can take the form of a percentage, an indication of the time remaining, or progress 
through sub-components of the task (eg. modules downloaded, or pages exported).</p></item>
 </list>
diff --git a/hig/C/search.page b/hig/C/search.page
index e0a10f0c..d6dcda03 100644
--- a/hig/C/search.page
+++ b/hig/C/search.page
@@ -50,9 +50,9 @@ 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>
+<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>
 
 </section>
diff --git a/hig/C/tabs.page b/hig/C/tabs.page
index 895a47b0..7db06fab 100644
--- a/hig/C/tabs.page
+++ b/hig/C/tabs.page
@@ -64,7 +64,7 @@
 <item><p>Tabs often have a constrained width, so ensure that tab labels are short and concise, and that the 
most useful part of the label is displayed first. This ensures that the label continues to be useful even 
when ellipsized.</p></item>
 <item><p>If the content of a tab changes or requires attention, a visual hint can be displayed.</p></item>
 <item><p>Provide a context menu on each tab. This menu should only include actions for manipulating the tab 
itself, such as <gui>Move Left</gui>, <gui>Move Right</gui>, <gui>Move to New Window</gui>, and 
<gui>Close</gui>.</p></item>
-<item><p>If tabs are an important part of the application, a new tab button can be placed in the header bar 
or toolbar. Do not show a new tab button in applications where tabs will not always be used - keyboard 
shortcuts and/or menu items are sufficient in these cases.</p></item>
+<item><p>If tabs are an important part of the application, a new tab button can be placed in the header bar 
or toolbar. Do not show a new tab button in applications where tabs will not always be used — keyboard 
shortcuts and/or menu items are sufficient in these cases.</p></item>
 </list>
 
 <section id="keyboard-shortcuts">
diff --git a/hig/C/text-fields.page b/hig/C/text-fields.page
index b7d059a4..7bb40422 100644
--- a/hig/C/text-fields.page
+++ b/hig/C/text-fields.page
@@ -54,7 +54,7 @@
 <p>Icons or icon buttons can be placed inside a text field to provide status information or additional 
controls.</p>
 
 <list>
-<item><p>An icon at the beginning of the entry can be used to indicate its purpose - replacing the need for 
the entry to be labelled. Search entry fields are the classic example of this, where a search icon is placed 
on the left side of the entry field.</p></item>
+<item><p>An icon at the beginning of the entry can be used to indicate its purpose — replacing the need for 
the entry to be labelled. Search entry fields are the classic example of this, where a search icon is placed 
on the left side of the entry field.</p></item>
 <item><p>If the text to be entered is case sensitive, a warning icon can be shown inside the text field if 
caps lock is on. This is typically shown on the right side of the entry.</p></item>
 <item><p>If it is common for the text field to be cleared, a clear icon button can be placed inside the 
field, at the right side.</p></item>
 <item><p>If you place an icon in a text entry field (either as an indicator or a button), use its symbolic 
variant from the GNOME Symbolic Icon Theme.</p></item>
diff --git a/hig/C/typography.page b/hig/C/typography.page
index 6e4bb40b..3b177119 100644
--- a/hig/C/typography.page
+++ b/hig/C/typography.page
@@ -34,7 +34,7 @@
 <item><p>Use smaller and/or lighter text for less important information, and heavier/darker text to attract 
attention to important text.</p></item>
 <item><p>Avoid the use of italic or oblique faces, as these are visually more complex, and can be 
distracting.</p></item>
 <item><p>Never capitalize every letter in a word or sentence. Shouting at your users isn't nice.</p></item>
-<item><p>Do not use graphical backdrops or "watermarks" behind text. These interfere with the contrast 
between the text and its background.</p></item>
+<item><p>Do not use graphical backdrops or “watermarks” behind text. These interfere with the contrast 
between the text and its background.</p></item>
 </list>
 
 </section>
diff --git a/hig/C/visual-layout.page b/hig/C/visual-layout.page
index 35dac2c2..aed5afc3 100644
--- a/hig/C/visual-layout.page
+++ b/hig/C/visual-layout.page
@@ -25,7 +25,7 @@
 
 <title>Visual layout</title>
 
-<p>The visual layout of controls, information and content affects how easy it is to understand your 
application. As part of this, it is important to recognise that visual design has a strong impact on how much 
work is involved in using an application - poor layout results in users having to put in additional effort, 
while good layout requires less effort.</p>
+<p>The visual layout of controls, information and content affects how easy it is to understand your 
application. As part of this, it is important to recognise that visual design has a strong impact on how much 
work is involved in using an application — poor layout results in users having to put in additional effort, 
while good layout requires less effort.</p>
 
 <p>Good visual layout also obviously makes applications more attractive and visually pleasing.</p>
 
@@ -35,7 +35,7 @@
 <title>General guidelines</title>
 
 <list>
-<item><p>An alignment point is an imaginary vertical or horizontal line through your window that touches the 
edge of one or more labels or controls in the window. Minimize the number of these - the fewer there are, the 
cleaner and simpler your layout will appear, and the easier it will be for people to understand.</p></item>
+<item><p>An alignment point is an imaginary vertical or horizontal line through your window that touches the 
edge of one or more labels or controls in the window. Minimize the number of these — the fewer there are, the 
cleaner and simpler your layout will appear, and the easier it will be for people to understand.</p></item>
 <item><p>Align content and controls in your layout exactly. The eye is very sensitive to aligned and 
unaligned objects. If visual elements do not line up, it will be hard for someone to scan them. Elements that 
do not quite line up will be distracting.</p></item>
 <item><p>Be consistent. Use the same amounts of spacing throughout.</p></item>
 <item><p>Organize related controls and information into groups, and use spacing to differentiate them. This 
makes an interface far easier to read and understand.</p>
@@ -46,7 +46,7 @@
 <item><p>A general padding of 18 pixels is recommended between the contents of a dialog window and the 
window borders.</p></item>
 </list></item>
 <item><p>Indent elements by 12 pixels to denote hierarchy and association.</p></item>
-<item><p>Avoid using frames with visible borders to separate groups of controls - use spacing and headers 
instead.</p></item>
+<item><p>Avoid using frames with visible borders to separate groups of controls — use spacing and headers 
instead.</p></item>
 </list>
 
 <p>Incorrect spacing and alignment:</p>
diff --git a/hig/C/writing-style.page b/hig/C/writing-style.page
index e36cc423..74fbe01c 100644
--- a/hig/C/writing-style.page
+++ b/hig/C/writing-style.page
@@ -47,7 +47,7 @@
 <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>Text should adopt a neutral tone and speak from the point of view of the product. Pronouns like 
“you” or "my” should therefore be avoided wherever possible. However, if they are unavoidable “your” is 
preferable to “my”.</p></item>
+<item><p>Text should adopt a neutral tone and speak from the point of view of the product. Pronouns like 
“you” or “my” should therefore be avoided wherever possible. However, if they are unavoidable “your” is 
preferable to “my”.</p></item>
 <item><p>Use the standard GNOME terms when referring to parts of the user interface, such as “pointer” and 
“window”. The HIG can be used as a reference in this regard.</p></item>
 <item><p>Avoid repetition where possible.</p></item>
 <item><p>Sentences should not be constructed from text in several controls, and each label should be treated 
as being self-contained. Sentences that run from one control to another will often not make sense when 
translated into other languages.</p></item>