Merge pull request #3549 from vespa-engine/kkraune/typos

proofreading

en/content/idealstate.html

@@ -124,7 +124,7 @@ <h2 id="a-simple-example-modulo">A simple example: Modulo</h2>
 <h2 id="weighted-random-election">Weighted random election</h2>
 <p>
   This is the algorithm that is currently used for distribution in the content layer,
-  as it fits our usecase well.
+  as it fits our use case well.
 </p><p>
   To avoid a total redistribution on state change,
   the mapping can not be heavily dependent on the number of nodes in the cluster.

en/document-api-guide.html

@@ -342,7 +342,7 @@ <h3 id="asyncsession">AsyncSession</h3>
     or update that needs to be handled.</li>
 <li>Note that the client must process the response queue or your JVM will run into garbage collection issues,
   as the underlying session keeps track of all responses
-  and unless they are consumed they will be kept alive and not be gc'ed.</li>
+  and unless they are consumed they will be kept alive and not be garbage collected.</li>
 </ol>
 <p>Example:</p>
 <pre>

en/embedding.html

@@ -563,7 +563,7 @@ <h3 id="adding-a-fixed-string-to-a-query-text">Adding a fixed string to a query
 <pre>{% highlight json %}
 {
     "yql": "select * from doc where userQuery() or ({targetHits: 100}nearestNeighbor(embedding, e))",
-    "input.query(e)": "embed(mxai, @text)",
+    "input.query(e)": "embed(mxbai, @text)",
     "user_query": "space contains many suns"
 }
 {% endhighlight %}</pre>

en/federation.html

@@ -27,7 +27,7 @@
     articles.</li>
 <li>provide more comprehensive results by finding data from
     alternative sources in the cases where the application has none,
-    like backfilling web results.</li>
+    like back-filling web results.</li>
 <li>create applications whose main purpose is not to provide access
     to some data set but to provide users or frontend applications a
     single starting point to access many kinds of data from various

en/getting-started.html

@@ -91,7 +91,7 @@
 
   <strong>Embedding Model Inference</strong>
   <p>
-   Vespa supports integrating <a href="embedding.html">embedding</a> models, this avoids transfering large amounts of embedding vector data 
+   Vespa supports integrating <a href="embedding.html">embedding</a> models, this avoids transferring large amounts of embedding vector data
    over the network and allows for efficient serving of embedding models.
   <ul>
     <li><a href="embedding.html#huggingface-embedder">Huggingface Embedder</a> Use single-vector embedding models from Hugging face</li>

en/grouping.html

@@ -448,7 +448,7 @@ <h2 id="ordering-and-limiting-groups">Ordering and Limiting Groups</h2>
   Example: To find the 2 globally best groups, make an educated guess on how
   many samples are needed to fetch from each node in order to get the right groups.
   This is the <code>precision</code>.
-  An initial factor of 3 has proven to be quite good in most usecases.
+  An initial factor of 3 has proven to be quite good in most use cases.
   If however the data for customer 'Jones' was spread on 3 different content nodes,
   'Jones' might be among the 2 best on only one node.
   But based on the distribution of the data,
@@ -1899,7 +1899,7 @@ <h3 id="impression-forecasting">Impression forecasting</h3>
 </p><p>
 So if the rank score is 0.420 for a specific user/ad/bid combination,
 then <code>interpolatedlookup(impressions,relevance())</code> would return 5.0.
-If the bid is increased so the rankscore gets to 0.490,
+If the bid is increased so the rank score gets to 0.490,
 it would get 5.5 as the return value instead.
 </p><p>
 In this context a count of 5.5 isn't meaningful for the past of a single user,

en/jdisc/index.html

@@ -15,7 +15,7 @@
   <li><a href="injecting-components.html">Dependency injection based on Guice</a>
     (Felix), but extended for configs and component collections.</li>
   <li>A component model based on <a href="../components/bundles.html">OSGi</a> which allows
-  component to be (re)deployed to running servers, and to control which API's they expose to others.</li>
+  component to be (re)deployed to running servers, and to control which APIs they expose to others.</li>
   <li>The features above combine to allow application package changes (changes to components, configuration or data)
     to be applied by Vespa without disrupting request serving nor requiring restarts.</li>
   <li>Standard component types exists for

en/linguistics.html

@@ -76,7 +76,7 @@ <h3 id="default-languages">Default languages</h3>
     <li>Irish (ga)</li>
     <li>Italian (it)</li>
     <li>Norwegian (nb)</li>
-    <li>Portugese (pt)</li>
+    <li>Portuguese (pt)</li>
     <li>Romanian (ro)</li>
     <li>Russian (ru)</li>
     <li>Spanish (es)</li>

en/operations-selfhosted/docker-containers.html

@@ -176,7 +176,7 @@ <h2 id="graceful-stop">Graceful stop</h2>
   (i.e. data structures are flushed).
   If the container is shutdown forcefully,
   the content nodes might need to restore the state from the transaction log which might be time-consuming.
-  There is no chance of data loss or data corruption as the data is always written and sync'ed to persistent storage.
+  There is no chance of data loss or data corruption as the data is always written and synced to persistent storage.
 </p>
 <p>
   The default timeout for the Docker daemon to wait for the shutdown

en/operations-selfhosted/vespa-cmdline-tools.html

@@ -384,7 +384,7 @@ <h2 id="vespa-fbench-filter-file">vespa-fbench-filter-file</h2>
 <pre>
 usage: vespa-fbench-filter-file [-a] [-h] [-m maxLineSize]
 
-Read concatenated fastserver logs from stdin and write
+Read concatenated logs from stdin and write
 extracted query urls to stdout.
 
  -a       : all parameters to the original query urls are preserved.

en/operations/tools.html

@@ -153,7 +153,7 @@ <h2 id="vespa-fbench">vespa-fbench</h2>
   <tr>
     <th>-x</th>
     <td>
-      write benchmarkdata-reporting to output file:
+      write benchmark data reporting to output file:
       <table class="table">
         <thead></thead><tbody>
       <tr>

en/partial-updates.html

@@ -164,7 +164,7 @@ <h2 id="write-pipeline">Write pipeline</h2>
     Attribute data is periodically flushed, see <a href="proton.html#attribute-flush">attribute-flush</a>.
     Note that operations are persisted to the Transaction Log Service (TLS),
     in the rare case of a power failure or unclean shutdown,
-    the operations are synched from the TLS.
+    the operations are synced from the TLS.
     </p>
     <p>
 

en/performance/sizing-feeding.html

@@ -59,7 +59,7 @@ <h2 id="stateful-content-cluster">Stateful content cluster</h2>
 </p>
 <p>
   The write pattern is append and sequential (not random) IO. Note that Vespa cannot sustain a higher write rate than 
-  the underlaying storage can handle.  Feeding might be impacted severely if the content nodes are using network attached storage
+  the underlying storage can handle.  Feeding might be impacted severely if the content nodes are using network attached storage
   where the sync operation (for durability) has a much higher cost than on local attached storage (e.g. SSD).
   See <a href="../reference/services-content.html#sync-transactionlog">sync-transactionlog</a>.
 </p>

en/performance/valgrind.html

@@ -27,7 +27,7 @@ <h2 id="valgrind-with-callgrind">Valgrind with callgrind</h2>
 <pre>
 $ valgrind 'application'
 </pre>
-<p>Show callgraph:</p>
+<p>Show call graph:</p>
 <pre>
 $ valgrind --tool=callgrind 'application'
 </pre>

en/proton.html

@@ -207,9 +207,9 @@ <h2 id="transaction-log">Transaction log</h2>
 Having a transaction log simplifies proton's in-memory index structures
 and enables steady-state high performance, read more below.
 </p><p>
-All operations are written and synched to the <a href="proton.html#transaction-log">transaction log</a>.
+All operations are written and synced to the <a href="proton.html#transaction-log">transaction log</a>.
 This is sequential (not random) IO but might impact overall feed performance if running on NAS attached storage
-where the synch operation has a much higher cost than on local attached storage (e.g. SSD).
+where the sync operation has a much higher cost than on local attached storage (e.g. SSD).
 See <a href="reference/services-content.html#sync-transactionlog">sync-transactionlog</a>.
 </p>
 <p>
@@ -225,7 +225,7 @@ <h2 id="document-store">Document store</h2>
   Documents are stored as compressed serialized blobs in the <em>document store</em>.
   Put, update and remove operations are persisted in the <a href="#transaction-log">transaction log</a>
   before updating the document in the document store.
-  The operation is ack'ed to the client and the result of the operation is immediately seen in search results.
+  The operation is acked to the client and the result of the operation is immediately seen in search results.
 </p>
 <p>
   Files in the document store are written sequentially, and occur in pairs - example:

en/reference/query-api-reference.html

@@ -1622,7 +1622,7 @@ <h2 id="tracing">Tracing</h2>
         Default is no information.
         See <a href="#trace.profiledepth">trace.profileDepth</a> for semantics of this parameter.
       </p>
-      <p>Tracing with <code>trace.profiling.secondhaseRanking.depth</code> also requires that <a href="#trace.level">trace.level</a> is positive.</p>
+      <p>Tracing with <code>trace.profiling.secondphaseRanking.depth</code> also requires that <a href="#trace.level">trace.level</a> is positive.</p>
     </td>
   </tr>
 

en/reference/rank-features.html

@@ -16,7 +16,7 @@
 </p>
 <ul>
   <li>
-    Types: All rank feature values are floats. Ints are converted to exact whole value floats.
+    Types: All rank feature values are floats. Integers are converted to exact whole value floats.
     String values are converted to exact whole value floats using a hash function.
     String literals in ranking expressions are converted using the same hash function,
     to enable equality tests on string values.
@@ -1371,7 +1371,7 @@ <h3 id="rank-scores">Rank scores</h3></td></tr>
   <td>6400M</td>
   <td>
     <p id="distance(name)">
-      The euclidian distance from the query position to the given position attribute in millionths of degrees (about 10 cm).
+      The Euclidean distance from the query position to the given position attribute in millionths of degrees (about 10 cm).
       If there are multiple positions in the query, items that actually search in <em>name</em> is preferred.
       Also: if multiple query items search in <em>name</em>, or <em>name</em> is an array of positions, or both,
       the closest distance found is returned.
@@ -1419,7 +1419,7 @@ <h3 id="rank-scores">Rank scores</h3></td></tr>
   <td>6400M</td>
   <td>
     <p id="distanceToPath(name).distance">
-    The euclidian distance from a path through 2d space
+    The Euclidean distance from a path through 2d space
     given in the query to the given position attribute in
     millionths of degrees. This is useful e.g. for finding the
     closest locations to a given road. The query path is set in the

en/reference/ranking-expressions.html

@@ -579,7 +579,7 @@ <h3 id="non-primitive-functions">Non-primitive functions</h3>
     <th>atan2(t1, t2)</th>
     <td>
       <p id="atan2-t1-t2"><code>join(t1, t2, f(x,y)(atan2(x,y)))</code></p>
-      <p>Arctangent of <code>t1</code> and <code>t2</code>/</p>
+      <p>Arc tangent of <code>t1</code> and <code>t2</code>/</p>
     </td>
   </tr>
   <tr>

en/reference/schema-reference.html

@@ -2121,13 +2121,13 @@ <h2 id="secondphase-rank">second-phase</h2>
 <tr><td><a href="#expression">expression</a></td>
 <td><p>Specify the ranking expression to be used for second phase of ranking. (for a description,
   see the <a href="../reference/ranking-expressions.html">ranking expression</a> documentation.</p>
-  <p id="secondphase-rescoring">Hits not reranked might be rescored using a linear function to avoid a greater rank score than the worst reranked hit. This linear function will normally attempt to map the first phase rank score range of reranked hits to the reranked rank score range</p>
+  <p id="secondphase-rescoring">Hits not reranked might be re-scored using a linear function to avoid a greater rank score than the worst reranked hit. This linear function will normally attempt to map the first phase rank score range of reranked hits to the reranked rank score range</p>
 </td>
 </tr>
 <tr><td style="white-space: nowrap">rank-score-drop-limit</td>
   <td>
     <p id="secondphase-rank-score-drop-limit">
-      When set, drop all hits with a second phase rank score (possibly a <a href="#secondphase-rescoring">rescored</a> rank score) less than or equal to this floating point number.
+      When set, drop all hits with a second phase rank score (possibly a <a href="#secondphase-rescoring">re-scored</a> rank score) less than or equal to this floating point number.
       Use this to implement a second phase rank cutoff.
       By default, this value is not set. This can also be <a href="query-api-reference.html#ranking.secondphase.rankscoredroplimit">set in the query</a>.
     </p>
@@ -2139,7 +2139,7 @@ <h2 id="secondphase-rank">second-phase</h2>
     Optional argument. Specifies the number of hits to be re-ranked in the second phase.
     Default value is 100. This can also be <a href="query-api-reference.html#ranking.rerankcount">set in the query</a>.
     Note that this value is local to each node involved in a query.
-    Hits not reranked might be <a href="#secondphase-rescoring">rescored</a>.
+    Hits not reranked might be <a href="#secondphase-rescoring">re-scored</a>.
   </p>
 </td>
 </tbody>
@@ -3051,7 +3051,7 @@ <h3 id="angular">angular</h3>
   </pre>
   If possible, it's slightly better for performance to normalize both query and document vectors to the same
   L2 norm and use the <code>prenormalized-angular</code> metric instead; but note that returned
-  distance and closeness will be differerent.
+  distance and closeness will be different.
 
 <h3 id="dotproduct">dotproduct</h3>
 <p>

en/reference/services-search.html

@@ -341,7 +341,7 @@ <h2 id="significance">significance</h2>
 &lt;/significance&gt;
 </pre>
 <p>
-The models are either provided by <em>Vespa</em> or generated with <a href="../operations-selfhosted/vespa-cmdline-tools.html#vespa-significance">vespa-signficance tool</a>.
+The models are either provided by <em>Vespa</em> or generated with <a href="../operations-selfhosted/vespa-cmdline-tools.html#vespa-significance">vespa-significance tool</a>.
 The order determines model precedence - with the last element having the highest priority.
 To use these models, schema needs to <a href="schema-reference.html#significance">enable significance models in the rank-profile</a>.
 </p>
@@ -365,7 +365,7 @@ <h2 id="model">model</h2>
 </pre>
 <p>
 A model specified with <code>url</code> and <code>path</code> are JSON files, which can be also compressed with <a href="https://facebook.github.io/zstd/">zstandard</a>.
-Model files can be generated using <a href="../operations-selfhosted/vespa-cmdline-tools.html#vespa-significance">vespa-signficance tool</a>.
+Model files can be generated using <a href="../operations-selfhosted/vespa-cmdline-tools.html#vespa-significance">vespa-significance tool</a>.
 Example with <code>url</code>:
 </p>
 <pre>

en/reference/validation-overrides.html

@@ -98,7 +98,7 @@ <h2 id="list">List of validation overrides</h2>
   <tr>
     <td><code>field-type-change</code></td>
     <td>Field type changes.</td>
-    <td>Requires refeeding data.</td>
+    <td>Requires re-feeding data.</td>
   </tr>
   <tr>
     <td><code>tensor-type-change</code></td>
@@ -123,7 +123,7 @@ <h2 id="list">List of validation overrides</h2>
   <tr>
     <td><code>deployment-removal</code></td>
     <td>Removal of production zones from deployment.xml.</td>
-    <td>Causes removal of all clustersand data in the zones.</td>
+    <td>Causes removal of all clusters and data in the zones.</td>
   </tr>
   <tr>
     <td><code>global-document-change</code></td>
@@ -153,7 +153,7 @@ <h2 id="list">List of validation overrides</h2>
   <tr>
     <td><code>certificate-removal</code></td>
     <td>Removing data plane certificates, typically when moving to new certificates.</td>
-    <td>Unable to accesss endpoint with removed certificates.</td>
+    <td>Unable to access endpoint with removed certificates.</td>
   </tr>
   </tbody>
 </table>

en/streaming-search.html

@@ -231,7 +231,7 @@ <h2 id="query-tuning-in-streaming-search">Query tuning in streaming search</h2>
 <p>On <a href="https://cloud.vespa.ai/">Vespa Cloud</a>,
 this number is set automatically to match the number of VCPUs set in
 <a href="https://cloud.vespa.ai/en/reference/services#resources">resources</a>.
-If you cannot get lower latency by increasing vcpus, it means your streaming searches have become
+If you cannot get lower latency by increasing VCPUs, it means your streaming searches have become
 IO bound.</p>
 
 

en/testing.html

@@ -136,7 +136,7 @@ <h2 id="staging-tests">Staging tests</h2>
 <p>
   As opposed to system tests, staging tests are not self-contained, as the state change during upgrade is
   precisely what is tested. Instead, execution order of any staging tests that modify state, particularly
-  after upgrade, must be controlled. Indeed, some changes will require refeeding data, and this should then be
+  after upgrade, must be controlled. Indeed, some changes will require re-feeding data, and this should then be
   part of the <em>staging test</em> code. Finally, it is also good to verify the expected state prior to upgrade.
 </p>
 <p>

en/vespa-cli.html

@@ -141,7 +141,7 @@ <h3 id="documents">Documents</h3>
 $ cat docs.json | vespa feed -
 
 # Feed to Vespa Cloud
-$ vespa feed --application mytenant.mayapp -target https://b123e1db.b68a1234.z.vespa-app.cloud feedfile.json
+$ vespa feed --application mytenant.myapp -target https://b123e1db.b68a1234.z.vespa-app.cloud feedfile.json
 
 # Print successful and failed operations:
 $ vespa feed --verbose docs.json

en/vespa7-release-notes.html

@@ -18,7 +18,7 @@
   means that applications <i>which use functionality that has earlier been deprecated</i> need to change to keep working.</p>
 
 <p>Most deprecated functionality causes warning during compilation (Java API deprecations) or deployment
-  (application package deprecations), however with web service API's there is no way to emit deprecation warnings,
+  (application package deprecations), however with web service APIs there is no way to emit deprecation warnings,
   and we have to rely on marking these as deprecated in the documentation.</p>
 
 <p>Given this, application owners need to do 3 tasks to be compatible with Vespa 7:</p>
@@ -27,7 +27,7 @@
     <li>Review whether <a href="#changed-defaults">changes to defaults</a> requires additional settings in the application
       (<b>note that this is likely</b> on changing from 6 to 7 due to the changes to tokenization and stemming).
     <li>Make sure there are no deprecation warnings on compilation and deployment on Vespa 6.
-    <li>Review the list of removed web service API's and API parameters and make sure these are not used by clients of
+    <li>Review the list of removed web service APIs and API parameters and make sure these are not used by clients of
       the application.
   </ul>
 
@@ -111,10 +111,10 @@ <h3 id="jdk-version">JDK version</h3>
 correct set of imported packages for your OSGi bundles.</p>
 
 
-<h3 id="removed-java-apis">Removed Java API's</h3>
+<h3 id="removed-java-apis">Removed Java APIs</h3>
 
 <p>Classes and methods that were marked as deprecated in Vespa 6 are removed.
-If you get deprecation warnings for Vespa API's when building your
+If you get deprecation warnings for Vespa APIs when building your
  application, they must be fixed before migrating to Vespa 7.</p>
 
 
@@ -135,7 +135,7 @@ <h3 id="container-runtime">Container Runtime Environment</h3>
 </p>
 
 
-<h3 id="removed-http-apis">Removed HTTP API's</h3>
+<h3 id="removed-http-apis">Removed HTTP APIs</h3>
 
 <p>The following HTTP APIs are removed:</p>
 

en/visiting.html

@@ -104,7 +104,7 @@ <h3 id="performance-note-feeding-data-exported-via-visiting">Performance note: f
 means that the stream of documents is no longer uniformly distributed across buckets and/or
 content nodes. Prior to Vespa 8.349 this is likely to greatly reduce feeding performance due
 to increased contention around backend bucket-level write locks and indexing threads. Vespa
-8.349 and beyond contains optimizations that bring refeeding performance much closer to
+8.349 and beyond contains optimizations that bring re-feeding performance much closer to
 that of initial feeding.
 </p>
 <p>