[gnome-devel-docs/wip/swilmet/prog-guidelines: 2/3] programming-guidelines: typography fixes

[Sébastien Wilmet <swilmet src gnome org>]

commit 102896043c196f8a11a2d7fc5b8c4909d5271a6e
Author: Sébastien Wilmet <swilmet gnome org>
Date:   Wed Nov 11 10:56:19 2015 +0100

    programming-guidelines: typography fixes
    
    https://bugzilla.gnome.org/show_bug.cgi?id=757736

 programming-guidelines/C/api-stability.page     |    4 ++--
 programming-guidelines/C/c-coding-style.page    |    2 +-
 programming-guidelines/C/documentation.page     |    2 +-
 programming-guidelines/C/version-control.page   |    2 +-
 programming-guidelines/C/writing-good-code.page |    2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)
---
diff --git a/programming-guidelines/C/api-stability.page b/programming-guidelines/C/api-stability.page
index f89d54e..9ecbb37 100644
--- a/programming-guidelines/C/api-stability.page
+++ b/programming-guidelines/C/api-stability.page
@@ -46,14 +46,14 @@
       means the C headers of a library form its API, and compiled library
       symbols its ABI. The difference between an API and ABI is given by
       compilation of the code: there are certain things in a C header, such as
-      <code>#define</code>s, which can cause a library's API to change without
+      <code>#define</code>s, which can cause a library’s API to change without
       changing its ABI. But these differences are mostly academic, and for all
       practical purposes, API and ABI can be treated interchangeably.
     </p>
 
     <p>
       Examples of API-incompatible changes to a C function would be to add a
-      new parameter, change the function's return type, or remove a parameter.
+      new parameter, change the function’s return type, or remove a parameter.
     </p>
 
     <p>
diff --git a/programming-guidelines/C/c-coding-style.page b/programming-guidelines/C/c-coding-style.page
index 226a4c1..aa69707 100644
--- a/programming-guidelines/C/c-coding-style.page
+++ b/programming-guidelines/C/c-coding-style.page
@@ -418,7 +418,7 @@ if (!found)
       To make the code clearer, you should write code that highlights the
       specific way 0 is used.  So when reading a comparison, it is possible to
       know the variable type.  For boolean variables, an implicit comparison is
-      appropriate because it's already a logical expression.  Other variable
+      appropriate because it’s already a logical expression.  Other variable
       types are not logical expressions by themselves, so an explicit
       comparison is better:
     </p>
diff --git a/programming-guidelines/C/documentation.page b/programming-guidelines/C/documentation.page
index 805c810..57c45d9 100644
--- a/programming-guidelines/C/documentation.page
+++ b/programming-guidelines/C/documentation.page
@@ -215,7 +215,7 @@ gtk_get_flow (GtkWidget *widget)
     <p>
       Keep in mind that in order to include a function, macro,
       function type, or struct type, it needs to be listed in your
-      documentation's modulename-sections.txt file.
+      documentation’s modulename-sections.txt file.
     </p>
 
     <p>
diff --git a/programming-guidelines/C/version-control.page b/programming-guidelines/C/version-control.page
index 1a5c86c..6f8b0a0 100644
--- a/programming-guidelines/C/version-control.page
+++ b/programming-guidelines/C/version-control.page
@@ -60,7 +60,7 @@
     <list>
       <item><p>
         No forced pushes. Except for branches with the <code>wip/</code> prefix
-        (work-in-progress), the commits' history must not be modified, as
+        (work-in-progress), the commits’ history must not be modified, as
         contributors rely on it.
       </p></item>
       <item><p>
diff --git a/programming-guidelines/C/writing-good-code.page b/programming-guidelines/C/writing-good-code.page
index b6c02a1..6cb9327 100644
--- a/programming-guidelines/C/writing-good-code.page
+++ b/programming-guidelines/C/writing-good-code.page
@@ -35,7 +35,7 @@
     full-time or part-time for here, volunteers still make up a large
     percentage of our contributors.  Programmers may come and go at
     any time and they will be able to dedicate different amounts of
-    time to the GNOME project.  People's "real world" responsibilities
+    time to the GNOME project.  People’s “real world” responsibilities
     may change, and this will be reflected in the amount of time that
     they can devote to GNOME.
   </p>