diff --git a/content/post/2017-02.md b/content/post/2017-02.md
index 32b60bac6..387a838e9 100644
--- a/content/post/2017-02.md
+++ b/content/post/2017-02.md
@@ -175,3 +175,16 @@ dspace=# update metadatavalue set text_value = regexp_replace(text_value, 'http:
- Fix label of CCAFS subjects in Atmire Listings and Reports module
- Help Sisay with SQL commands
- Help Paola from CCAFS with the Atmire Listings and Reports module
+- Testing the `fix-metadata-values.py` script on macOS and it seems like we don't need to use `.encode('utf-8')` anymore when printing strings to the screen
+- It seems this might have only been a temporary problem, as both Python 3.5.2 and 3.6.0 are able to print the problematic string "Entwicklung & Ländlicher Raum" without the `encode()` call, but print it as a bytes when it *is* used:
+
+```
+$ python
+Python 3.6.0 (default, Dec 25 2016, 17:30:53)
+>>> print('Entwicklung & Ländlicher Raum')
+Entwicklung & Ländlicher Raum
+>>> print('Entwicklung & Ländlicher Raum'.encode())
+b'Entwicklung & L\xc3\xa4ndlicher Raum'
+```
+
+- So for now I will remove the encode call from the script (though it was never used on the versions on the Linux hosts), leading me to believe it really *was* a temporary problem, perhaps due to macOS or the Python build I was using.
diff --git a/public/2017-02/index.html b/public/2017-02/index.html
index 308ea99f8..a2931514a 100644
--- a/public/2017-02/index.html
+++ b/public/2017-02/index.html
@@ -92,7 +92,7 @@ Looks like we’ll be using cg.identifier.ccafsprojectpii as the field name
"headline": "February, 2017",
"url": "https://alanorth.github.io/cgspace-notes/2017-02/",
- "wordCount": "1211",
+ "wordCount": "1347",
"datePublished": "2017-02-07T07:04:52-08:00",
@@ -371,6 +371,20 @@ dspace=# update metadatavalue set text_value = 'https://dx.doi.org/10.15446/agro
Fix label of CCAFS subjects in Atmire Listings and Reports module
Help Sisay with SQL commands
Help Paola from CCAFS with the Atmire Listings and Reports module
+Testing the fix-metadata-values.py script on macOS and it seems like we don’t need to use .encode('utf-8') anymore when printing strings to the screen
+It seems this might have only been a temporary problem, as both Python 3.5.2 and 3.6.0 are able to print the problematic string “Entwicklung & Ländlicher Raum” without the encode() call, but print it as a bytes when it is used:
+
+
+$ python
+Python 3.6.0 (default, Dec 25 2016, 17:30:53)
+>>> print('Entwicklung & Ländlicher Raum')
+Entwicklung & Ländlicher Raum
+>>> print('Entwicklung & Ländlicher Raum'.encode())
+b'Entwicklung & L\xc3\xa4ndlicher Raum'
+
+
+
+- So for now I will remove the encode call from the script (though it was never used on the versions on the Linux hosts), leading me to believe it really was a temporary problem, perhaps due to macOS or the Python build I was using.
diff --git a/public/index.xml b/public/index.xml
index 5c63ad9ee..e57659596 100644
--- a/public/index.xml
+++ b/public/index.xml
@@ -219,6 +219,20 @@ dspace=# update metadatavalue set text_value = 'https://dx.doi.org/10.15446/
<li>Fix label of CCAFS subjects in Atmire Listings and Reports module</li>
<li>Help Sisay with SQL commands</li>
<li>Help Paola from CCAFS with the Atmire Listings and Reports module</li>
+<li>Testing the <code>fix-metadata-values.py</code> script on macOS and it seems like we don’t need to use <code>.encode('utf-8')</code> anymore when printing strings to the screen</li>
+<li>It seems this might have only been a temporary problem, as both Python 3.5.2 and 3.6.0 are able to print the problematic string “Entwicklung & Ländlicher Raum” without the <code>encode()</code> call, but print it as a bytes when it <em>is</em> used:</li>
+</ul>
+
+<pre><code>$ python
+Python 3.6.0 (default, Dec 25 2016, 17:30:53)
+>>> print('Entwicklung & Ländlicher Raum')
+Entwicklung & Ländlicher Raum
+>>> print('Entwicklung & Ländlicher Raum'.encode())
+b'Entwicklung & L\xc3\xa4ndlicher Raum'
+</code></pre>
+
+<ul>
+<li>So for now I will remove the encode call from the script (though it was never used on the versions on the Linux hosts), leading me to believe it really <em>was</em> a temporary problem, perhaps due to macOS or the Python build I was using.</li>
</ul>
diff --git a/public/post/index.xml b/public/post/index.xml
index ce867c1d1..0099aedf8 100644
--- a/public/post/index.xml
+++ b/public/post/index.xml
@@ -219,6 +219,20 @@ dspace=# update metadatavalue set text_value = 'https://dx.doi.org/10.15446/
<li>Fix label of CCAFS subjects in Atmire Listings and Reports module</li>
<li>Help Sisay with SQL commands</li>
<li>Help Paola from CCAFS with the Atmire Listings and Reports module</li>
+<li>Testing the <code>fix-metadata-values.py</code> script on macOS and it seems like we don’t need to use <code>.encode('utf-8')</code> anymore when printing strings to the screen</li>
+<li>It seems this might have only been a temporary problem, as both Python 3.5.2 and 3.6.0 are able to print the problematic string “Entwicklung & Ländlicher Raum” without the <code>encode()</code> call, but print it as a bytes when it <em>is</em> used:</li>
+</ul>
+
+<pre><code>$ python
+Python 3.6.0 (default, Dec 25 2016, 17:30:53)
+>>> print('Entwicklung & Ländlicher Raum')
+Entwicklung & Ländlicher Raum
+>>> print('Entwicklung & Ländlicher Raum'.encode())
+b'Entwicklung & L\xc3\xa4ndlicher Raum'
+</code></pre>
+
+<ul>
+<li>So for now I will remove the encode call from the script (though it was never used on the versions on the Linux hosts), leading me to believe it really <em>was</em> a temporary problem, perhaps due to macOS or the Python build I was using.</li>
</ul>
diff --git a/public/tags/notes/index.xml b/public/tags/notes/index.xml
index 8f13101fe..3139de2f2 100644
--- a/public/tags/notes/index.xml
+++ b/public/tags/notes/index.xml
@@ -218,6 +218,20 @@ dspace=# update metadatavalue set text_value = 'https://dx.doi.org/10.15446/
<li>Fix label of CCAFS subjects in Atmire Listings and Reports module</li>
<li>Help Sisay with SQL commands</li>
<li>Help Paola from CCAFS with the Atmire Listings and Reports module</li>
+<li>Testing the <code>fix-metadata-values.py</code> script on macOS and it seems like we don’t need to use <code>.encode('utf-8')</code> anymore when printing strings to the screen</li>
+<li>It seems this might have only been a temporary problem, as both Python 3.5.2 and 3.6.0 are able to print the problematic string “Entwicklung & Ländlicher Raum” without the <code>encode()</code> call, but print it as a bytes when it <em>is</em> used:</li>
+</ul>
+
+<pre><code>$ python
+Python 3.6.0 (default, Dec 25 2016, 17:30:53)
+>>> print('Entwicklung & Ländlicher Raum')
+Entwicklung & Ländlicher Raum
+>>> print('Entwicklung & Ländlicher Raum'.encode())
+b'Entwicklung & L\xc3\xa4ndlicher Raum'
+</code></pre>
+
+<ul>
+<li>So for now I will remove the encode call from the script (though it was never used on the versions on the Linux hosts), leading me to believe it really <em>was</em> a temporary problem, perhaps due to macOS or the Python build I was using.</li>
</ul>