Merge pull request #392 from JohnTitor/fix-typos-qa-when-lang-neg

Fix some typos on questions/qa-when-lang-neg

questions/qa-when-lang-neg.en.html

@@ -54,7 +54,7 @@ <h1>When to use language negotiation</h1>
     <div id="updateInfo"></div><script>document.getElementById('updateInfo').innerHTML = g.updated</script>
     </div>
 
- <section id="question">
+<section id="question">
 <h2>Question</h2>
     <p class="question">When is it appropriate, or not, to use language negotiation?</p>
 
@@ -76,7 +76,7 @@ <h2>Answer</h2>
   <p>The short answer is: <em>always</em>.</p>
   <p>A slightly longer answer is: <em>almost</em> always, <em>but not alone</em>.</p>
   <p>Language negotiation <a href="#shortcomings">does not always work as intended</a>; there are techniques to <a href="#overrides">make up
-    for the shortcomings</a>; one should also provide for <a href="#stickyness">stickyness in navigation</a>.</p>
+    for the shortcomings</a>; one should also provide for <a href="#stickyness">stickiness in navigation</a>.</p>
 
   <section id="shortcomings">
 <h3>Shortcomings of language negotiation</h3>
@@ -97,7 +97,7 @@ <h3>Shortcomings of language negotiation</h3>
     <p id="equivalence">Additionally, language negotiation is not even <em>relevant</em> when pages are not
       equivalent, i.e. do not have essentially the same content in different languages. The article <a class="print" href="/International/questions/qa-mono-multilingual"><cite>Monolingual vs. multilingual
       Web sites</cite></a> sheds some light on this, see in particular the "<em>Multilingual, same content</em>" and "<em>Multilingual, changed content</em>"
-      sub-sections. Note however than some measure of cultural adaptation (e.g. changing the currency) does not necessarily make pages non-equivalent; the
+      sub-sections. Note however that some measure of cultural adaptation (e.g. changing the currency) does not necessarily make pages non-equivalent; the
       non-equivalence limitation to language negotiation really exists when a <em>site</em> is adapted so that pages in different languages do not
       correspond to one another any more.</p>
   </section>
@@ -127,8 +127,8 @@ <h3>Navigation</h3>
     <p>Suppose Sylvia visits www.example.be and gets Flemish (situation 2 or 3). She then clicks on the German control and reads on, no real
       trouble. But she then clicks on a link to get to an interesting page within the site. Oops, Flemish again! Fortunately, the German control is still
       there, but after a couple of such detours she's getting understandably frustrated. Can't www.example.be just remember that she can't read Flemish?
-      What is needed here is some <em>stickyness</em> of the explicit language selection.</p>
-    <p>There are a couple of ways that www.example.be can provide this stickyness. Which one to choose will depend on the underlying
+      What is needed here is some <em>stickiness</em> of the explicit language selection.</p>
+    <p>There are a couple of ways that www.example.be can provide this stickiness. Which one to choose will depend on the underlying
       technology available on the server and on the level of effort that can be expended.</p>
     <p>If the site implements a <em>session</em> mechanism (for instance using <a class="print" href="https://www.rfc-editor.org/info/rfc6265">cookies</a>), then it is a fairly simple matter to arrange for language to be part of the
       session state. Once Sylvia clicks on the German control, this gets stored (either in the cookie itself or in the server, to be matched by a <em>session number</em> in the cookie) and from then on she gets German when navigating the site. The cookie can even be made persistent (although
@@ -142,7 +142,7 @@ <h3>Navigation</h3>
         a couple of downsides, however. One is that all internal links become translatable material, increasing the cost of translation as well as the
         potential for errors. Another is that if Jaap sends a link to Pierre, the URL (picked up from the browser's address bar) will be language-specific;
         Pierre will then get the Flemish page. Neither of these downsides is horrible, however, so using language-specific links is probably the way to go
-        if stickyness cannot be provided through a session state or profile mechanism.</p>
+        if stickiness cannot be provided through a session state or profile mechanism.</p>
       <aside class="sideinfonote"><p class="footnote">Note that the particular forms of language-specific and language-generic URLs shown here
         (company/about<b>.de</b>.html vs company/about.html) depend on the technology used on the server side to implement language negotiation. Using <a class="print" href="/International/questions/qa-apache-lang-neg">Apache MultiViews</a>, one would rather see company/about.html<b>.de</b> and company/about.html or, forgoing the
         .html extension entirely, company/about<b>.de</b> and company/about.</p></aside>