bump version

1 files changed, 38 insertions, 38 deletions

diff --git a/texinfo/taler-merchant.texi b/texinfo/taler-merchant.texi
index cf8bb129..4ae98856 100644
--- a/texinfo/taler-merchant.texi
+++ b/texinfo/taler-merchant.texi
@@ -19,7 +19,7 @@
 
 @copying
 @quotation
-GNU Taler 0.9.0, Mar 07, 2024
+GNU Taler 0.9.4, Mar 07, 2024
 
 GNU Taler team
 
@@ -356,7 +356,7 @@ shop a request is intended for.  Each instance has its own base URL in the
 REST API of the merchant backend (@code{/instances/$INSTANCE/}).  Each instance
 can use its own bank accounts and keys for signing contracts. All major
 accounting functionality is separate per instance.  Access to each instance is
-controlled via a bearer token (to be set in the HTTP “Authorization” header).
+controlled via a bearer token (to be set in the HTTP "Authorization" header).
 All instances share the same `database', top-level HTTP(S) address and the
 main Taler configuration (especially the accepted `currency' and `exchanges').
 
@@ -364,12 +364,12 @@ main Taler configuration (especially the accepted `currency' and `exchanges').
 
 @cartouche
 @quotation Note 
-This documentation does not use the term “user” or “username” in
+This documentation does not use the term "user" or "username" in
 conjunction with instances as that might create confusion between
 instances with paying customers using the system.  We also do not use the
-term “account” in conjunction with instances, as that might cause
+term "account" in conjunction with instances, as that might cause
 confusion with bank accounts.  That said, conceptually it is of course
-acceptable to consider instances to be the “users” or “accounts” of a
+acceptable to consider instances to be the "users" or "accounts" of a
 merchant backend and the bearer token is equivalent to a passphrase.
 @end quotation
 @end cartouche
@@ -387,7 +387,7 @@ To receive payments, an instance must have configured one or more bank
 ideally also provide the address and credentials of an HTTP service
 implementing the Taler Bank Revenue HTTP API.  Given such a service, the GNU Taler merchant
 backend can automatically reconcile wire transfers from the exchange to the
-merchant’s bank account with the orders that are being settled.
+merchant's bank account with the orders that are being settled.
 
 This documentation exclusively uses the term `account' for the bank
 accounts of a merchant or shop that may be associated with an instance.
@@ -512,13 +512,13 @@ in cases where the point-of-sale of a merchant is offline (and thus cannot
 setup an order), or even in cases where a simple static QR code is desired to
 accept payments or donations.
 
-When generating a template, the “summary” text of the contract and the
-“amount” to be paid by the customer can be fixed or left for the customer to
+When generating a template, the "summary" text of the contract and the
+"amount" to be paid by the customer can be fixed or left for the customer to
 specify.  If the customer is expected to provide either or both of these
 values, the template link (or QR code) can specify a default value. For
-example, a cafeteria with a fixed price lunch may use a “lunch” template with
-both values fixed to the lunch price and the “lunch” product, a bakery might
-fix the summary to “baked goods” but allow the customer to enter the amount
+example, a cafeteria with a fixed price lunch may use a "lunch" template with
+both values fixed to the lunch price and the "lunch" product, a bakery might
+fix the summary to "baked goods" but allow the customer to enter the amount
 based on the total price of the items being bought, and a charity may allow
 donating an arbitrary amount and summary message while also suggesting default
 values.
@@ -542,7 +542,7 @@ standard is described in RFC 6238@footnote{https://www.rfc-editor.org/rfc/rfc623
 For GNU Taler merchant backends, OTP devices are used as a way to assure a
 merchant without network connectivity that a customer made a digital
 payment. The idea is described in depth in our SUERF Policy Brief@footnote{https://www.suerf.org/suer-policy-brief/69851/practical-offline-payments-using-one-time-passcodes}.
-To use this method, a merchant must configure the OTP device’s shared secret
+To use this method, a merchant must configure the OTP device's shared secret
 in the merchant backend, and then associate the OTP device with a
 @ref{10,,Templates}.  Once the customer has paid, they are given a list of OTP
 codes which must be shown to the merchant who can check that at least one of
@@ -561,7 +561,7 @@ payment.
 The Taler backend can be used to verify that the exchange correctly wired all
 of the funds to the merchant. However, if no Taler Bank Revenue HTTP API was provided for the respective bank account,
 the backend does not have access to the incoming wire transfers of the
-merchant’s bank account. In this case, merchants should manually provide the
+merchant's bank account. In this case, merchants should manually provide the
 backend with wire `transfer' data that specifies the `wire transfer subject'
 and the amount that was received. Given this information, the backend can
 detect and report any irregularities that might arise.
@@ -756,7 +756,7 @@ backend:
 @itemize -
 
 @item 
-“Sphinx RTD Theme” Python package aka @code{python3-sphinx-rtd-theme}
+"Sphinx RTD Theme" Python package aka @code{python3-sphinx-rtd-theme}
 on Debian-based systems (for GNUnet documentation support, can be
 omitted if GNUnet is configured with @code{--disable-documentation})
 
@@ -853,7 +853,7 @@ In any case, if @code{make check} fails, please consider filing a
 bug report with the Taler bug tracker@footnote{https://bugs.taler.net}.
 
 There is no need to actually run a GNUnet peer to use the Taler merchant
-backend – all the merchant needs from GNUnet is a number of headers and
+backend -- all the merchant needs from GNUnet is a number of headers and
 libraries!
 
 After installing GNUnet, unpack the GNU Taler exchange tarball,
@@ -874,7 +874,7 @@ which requires you to run the last step as @code{root}.  You have to specify
 previous step.
 
 There is no need to actually run a Taler exchange to use the Taler merchant
-backend – all the merchant needs from the Taler exchange is a few headers and
+backend -- all the merchant needs from the Taler exchange is a few headers and
 libraries!
 
 Please note that unlike most packages, if you want to run the @code{make check}
@@ -1465,16 +1465,16 @@ This is concern can be addressed using a properly configured
 
 
 In order to setup an instance, you need the merchant backend to already be
-running, and you must either have the credentials for the “default” instance,
+running, and you must either have the credentials for the "default" instance,
 or no instance must be configured at all yet.
 
 To start, point your browser to @code{$PROTO://backend.$DOMAIN_NAME/}, replacing
-“$PROTO” with “https” or (rarely) “http” and “$DOMAIN_NAME” with your
+"$PROTO" with "https" or (rarely) "http" and "$DOMAIN_NAME" with your
 organizations DNS domain or subdomain.
 
 @cartouche
 @quotation Note 
-The label “backend” here is also just a suggestion, your administrator
+The label "backend" here is also just a suggestion, your administrator
 can in principle choose any name.
 @end quotation
 @end cartouche
@@ -1512,7 +1512,7 @@ InstanceConfigurationMessage:
 @end example
 
 The @code{name} field will be shown as the name of your shop. The
-@code{address} field is expected to contain your shop’s physical address. The
+@code{address} field is expected to contain your shop's physical address. The
 various defaults specify defaults for transaction fees your shop is willing to
 cover, how long offers made to the customer are valid, and how long the
 exchange has before it must wire the funds to your bank account. Those
@@ -1569,7 +1569,7 @@ the left of the page.  The following page should be shown:
 
 @image{taler-merchant-figures/no_default_account_yet,,,,png}
 
-Click on the blue “+” sign on the top right of the page to add a new
+Click on the blue "+" sign on the top right of the page to add a new
 bank account. The following page should appear:
 
 @image{taler-merchant-figures/enter_instance_details,,,,png}
@@ -1697,15 +1697,15 @@ SERVE = unix
 UNIXPATH = "/some/path/here.sock"
 @end example
 
-Do not use a UNIX domain socket path in “/tmp”: systemd (or other init
-systems) may give Web servers a private “/tmp” thereby hiding UNIX domain
-sockets created by other users/processes in “/tmp”.
+Do not use a UNIX domain socket path in "/tmp": systemd (or other init
+systems) may give Web servers a private "/tmp" thereby hiding UNIX domain
+sockets created by other users/processes in "/tmp".
 
 If UNIX domain sockets are for some reason not possible, you `may' use a
 host-based firewall to block access to the TCP port of the merchant backend,
 but this is `not recommended'.  If you do need a TCP socket, you should
-instead strongly consider using the “BIND_TO” option to at least bind it only
-to “localhost”.
+instead strongly consider using the "BIND_TO" option to at least bind it only
+to "localhost".
 
 @node Reverse proxy configuration,Access control,Using UNIX domain sockets,Secure setup
 @anchor{taler-merchant-manual id10}@anchor{35}@anchor{taler-merchant-manual reverse-proxy-configuration}@anchor{2a}
@@ -1778,8 +1778,8 @@ users of the default instance, and to @code{$BASE_URL/instances/$ID/private/} to
 the authorized users of the instance @code{$ID}.
 
 By default, the GNU Taler merchant backend simply requires the respective
-HTTP requests to include an “Authorization” header with a “Bearer” token
-set to the respective shared secret which must begin with “secret-token:”
+HTTP requests to include an "Authorization" header with a "Bearer" token
+set to the respective shared secret which must begin with "secret-token:"
 (following RFC 8959).
 
 Note that all of the other endpoints (without @code{/private/})
@@ -1873,7 +1873,7 @@ setup and configure the legal conditions.
 @section Terms of Service
 
 
-The service has an endpoint “/terms” to return the terms of service (in legal
+The service has an endpoint "/terms" to return the terms of service (in legal
 language) of the service operator.  Client software show these terms of
 service to the user when the user is first interacting with the service.
 Terms of service are optional for experimental deployments, if none are
@@ -1887,7 +1887,7 @@ in the configuration file for the service:
 @itemize -
 
 @item 
-@code{TERMS_ETAG}: The current “Etag” to return for the terms of service.
+@code{TERMS_ETAG}: The current "Etag" to return for the terms of service.
 This value must be changed whenever the terms of service are
 updated. A common value to use would be a version number.
 Note that if you change the @code{TERMS_ETAG}, you MUST also provide
@@ -1904,7 +1904,7 @@ process.
 @section Privacy Policy
 
 
-The service has an endpoint “/pp” to return the terms privacy policy (in legal
+The service has an endpoint "/pp" to return the terms privacy policy (in legal
 language) of the service operator.  Clients should show the privacy policy to
 the user when the user explicitly asks for it, but it should not be shown by
 default.  Privacy policies are optional for experimental deployments, if none
@@ -1918,7 +1918,7 @@ in the configuration file for the service:
 @itemize -
 
 @item 
-@code{PRIVACY_ETAG}: The current “Etag” to return for the privacy policy.
+@code{PRIVACY_ETAG}: The current "Etag" to return for the privacy policy.
 This value must be changed whenever the privacy policy is
 updated. A common value to use would be a version number.
 Note that if you change the @code{PRIVACY_ETAG}, you MUST also provide
@@ -1939,7 +1939,7 @@ The @code{TERMS_DIR} and @code{PRIVACY_DIR} directory structures must follow a
 particular layout.  You may use the same directory for both the terms of
 service and the privacy policy, as long as you use different ETAGs.  Inside of
 the directory, there should be sub-directories using two-letter language codes
-like “en”, “de”, or “jp”.  Each of these directories would then hold
+like "en", "de", or "jp".  Each of these directories would then hold
 translations of the current terms of service into the respective language.
 Empty directories are permitted in case translations are not available.
 
@@ -1947,7 +1947,7 @@ Then, inside each language directory, files with the name of the value set as
 the @code{TERMS_ETAG} or @code{PRIVACY_ETAG} must be provided. The extension of each
 of the files should be typical for the respective mime type.  The set of
 supported mime types is currently hard-coded in the service, and includes
-“.epub”, “.html”, “.md”, “.pdf” and “.txt” files. If other files are present,
+".epub", ".html", ".md", ".pdf" and ".txt" files. If other files are present,
 the service may show a warning on startup.
 
 @menu
@@ -1960,7 +1960,7 @@ the service may show a warning on startup.
 @subsection Example
 
 
-A sample file structure for a @code{TERMS_ETAG} of “tos-v0” would be:
+A sample file structure for a @code{TERMS_ETAG} of "tos-v0" would be:
 
 
 @itemize -
@@ -1996,8 +1996,8 @@ TERMS_DIR/de/tos-v0.epub
 TERMS_DIR/de/tos-v0.md
 @end itemize
 
-If the user requests an HTML format with language preferences “fr” followed by
-“en”, the service would return @code{TERMS_DIR/en/tos-v0.html} lacking a version in
+If the user requests an HTML format with language preferences "fr" followed by
+"en", the service would return @code{TERMS_DIR/en/tos-v0.html} lacking a version in
 French.
 
 @node Generating the Legal Terms,Adding translations,Legal policies directory layout,Customization
@@ -2240,7 +2240,7 @@ to increase the @code{ulimit} of the @code{taler-merchant-httpd} process if you
 many static files. Note that Mustach templates do not increase the number of
 open files.
 
-The backend determines the MIME type based on the file’s extension. The list
+The backend determines the MIME type based on the file's extension. The list
 of supported extensions is hard-coded and includes common text and image
 formats.