[gnome-devel-docs] HIG: Fix a number of typos.

[Allan Day <allanday src gnome org>]

commit 67b86304b4906102b376386e94523ce0ce26e688
Author: Sebastian Rasmussen <sebras gmail com>
Date:   Wed Jan 4 21:18:59 2017 +0100

    HIG: Fix a number of typos.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=776510

 hig/C/icons-and-artwork.page          | 2 +-
 hig/C/info-bars.page                  | 2 +-
 hig/C/initial-state-placeholders.page | 2 +-
 hig/C/progress-spinners.page          | 2 +-
 hig/C/writing-style.page              | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)
---
diff --git a/hig/C/icons-and-artwork.page b/hig/C/icons-and-artwork.page
index c4924f59..353afc1e 100644
--- a/hig/C/icons-and-artwork.page
+++ b/hig/C/icons-and-artwork.page
@@ -46,7 +46,7 @@
 <section id="color-vs-symbolic">
 <title>Color vs. symbolic icons</title>
 
-<p>GNOME 3 provides two types of icon: full-color and monochrome symbolic icons. The guidelines in this HIG 
indicate when to use which type of icon. The following is a a general guide.</p>
+<p>GNOME 3 provides two types of icons: full-color and monochrome symbolic icons. The guidelines in this 
document indicate when to use which type of icon. The following is a general guide.</p>
 
 <p>Full-color icons should be used for:</p>
 
diff --git a/hig/C/info-bars.page b/hig/C/info-bars.page
index 623b5ff2..8c0795a1 100644
--- a/hig/C/info-bars.page
+++ b/hig/C/info-bars.page
@@ -35,7 +35,7 @@
 
 <list>
 <item><p>Beware of info bar overuse: they should be an exceptional presence in your interface.</p></item>
-<item><p>Only one info bar should be visable at any one time.</p></item>
+<item><p>Only one info bar should be visible at any one time.</p></item>
 <item><p>Only include a longer explanation if it is really needed: a simple heading can often be 
sufficient.</p></item>
 <item><p>Generally speaking, info bars do not require an icon.</p></item>
 </list>
diff --git a/hig/C/initial-state-placeholders.page b/hig/C/initial-state-placeholders.page
index c03d05fc..21e994ba 100644
--- a/hig/C/initial-state-placeholders.page
+++ b/hig/C/initial-state-placeholders.page
@@ -33,7 +33,7 @@
 
 <list>
 <item><p>Follow the standard layout for the size and placement of the image and labels, so that your 
application is consistent with other GNOME 3 applications.</p></item>
-<item><p>The imagry used should be rich and colorful.</p></item>
+<item><p>The imagery used should be rich and colorful.</p></item>
 <item><p>The text that accompanies the image should be positive and upbeat. This is a moment where you can 
sell your application and establish a positive identity for it. It can also be an opportunity to strike up a 
relationship with the user by addressing them directly.</p></item>
 <item><p>If there are controls that allow items to be added, it can be appropriate to highlight them using a 
<link xref="buttons#suggested-and-destructive">suggested style</link> while the list/grid is empty.</p></item>
 <item><p>While an application is initially empty, some controls don't serve a purpose (such as those for 
browsing content, changing view, or searching). Making these controls insensitive will help to avoid the user 
being disappointed, or trying features that won't work.</p></item>
diff --git a/hig/C/progress-spinners.page b/hig/C/progress-spinners.page
index a1a4acf9..b2cf5f4e 100644
--- a/hig/C/progress-spinners.page
+++ b/hig/C/progress-spinners.page
@@ -42,7 +42,7 @@
 <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>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, or 
progress through sub-components of the task (eg. modules downloaded, or pages exported).</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>
 
 </section>
diff --git a/hig/C/writing-style.page b/hig/C/writing-style.page
index bb4c9f02..e36cc423 100644
--- a/hig/C/writing-style.page
+++ b/hig/C/writing-style.page
@@ -51,7 +51,7 @@
 <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>
-<item><p>Latin abbreviations such as “ie” or “eg” should be avoided, since they can't always be easily 
translated and can be unintelligable when read by screen readers. Instead, use full words like “for 
example”.</p></item>
+<item><p>Latin abbreviations such as “ie” or “eg” should be avoided, since they can't always be easily 
translated and can be unintelligible when read by screen readers. Instead, use full words like “for 
example”.</p></item>
 </list>
 
 </section>