commit eb455abbff011dc4cc8a42abd29a6df1900f4edf parent f35203265df635ceaa220a04a4d26fa36ebd869a Author: Florian Dold <florian@dold.me> Date: Wed, 18 Feb 2026 01:43:59 +0100 more doc fixes Diffstat:
22 files changed, 40 insertions(+), 44 deletions(-)
diff --git a/checklists/qa-1.0.rst b/checklists/qa-1.0.rst @@ -53,7 +53,7 @@ These deployments should work for the release: Check UX Flows ^^^^^^^^^^^^^^ -See the :doc:`demo upgrade checklist <checklists/checklist-demo-upgrade>`. +See the :doc:`demo upgrade checklist <checklist-demo-upgrade>`. Regio Deployment diff --git a/core/merchant/get-management-instances-INSTANCE-statistics-report-NAME.rst b/core/merchant/get-management-instances-INSTANCE-statistics-report-NAME.rst @@ -53,7 +53,7 @@ interface MerchantStatisticsReportResponse { // Name of the business for which the report is generated. - business_name: String; + business_name: string; // Starting date for the report. start_date: Timestamp; @@ -74,11 +74,11 @@ interface MerchantReportChart { // Name of the chart. - chart_name: String; + chart_name: string; // Label to use for the y-axis of the chart. // (x-axis is always time). - y_label: String; + y_label: string; // Statistical values for the respective time windows, // one entry per ``bucket_period`` in between ``start_date`` diff --git a/core/merchant/get-orders-ORDER_ID.rst b/core/merchant/get-orders-ORDER_ID.rst @@ -48,18 +48,18 @@ order (as this one has been taken) or may trigger repurchase detection. Note that **if** the contract lacks a ``public_reorder_url`` - the backend will instead return a `403 Forbidden` response. + the backend will instead return a ``403 Forbidden`` response. :http:statuscode:`302 Found`: The client should go to the indicated location (via HTTP "Location:" header). Returned only for unauthenticated (no nonce, no contract hash) requests and only if the order was claimed already. Only returned if the content type requested was HTML - if HTML was not requested a `302 Accepted` will be returned instead. + if HTML was not requested a ``302 Accepted`` will be returned instead. The target site may allow the client to setup a fresh order (as this one has been taken) or may trigger repurchase detection. Note that **if** the contract lacks a ``public_reorder_url`` - the backend will instead return a `403 Forbidden` response. + the backend will instead return a ``403 Forbidden`` response. :http:statuscode:`402 Payment required`: The response is a `StatusUnpaidResponse`. :http:statuscode:`403 Forbidden`: diff --git a/core/merchant/get-sessions-SESSION_ID.rst b/core/merchant/get-sessions-SESSION_ID.rst @@ -39,7 +39,7 @@ interface GetSessionStatusPaidResponse { // Order ID of the paid order. - order_id: String; + order_id: string; } @@ -48,6 +48,6 @@ interface GetSessionStatusUnpaidResponse { // Order ID of the unpaid order. - order_id: String; + order_id: string; } diff --git a/deployments/index.rst b/deployments/index.rst @@ -11,3 +11,4 @@ documentation about our deployments. tops-stage-devtesting.rst tops.rst tops-troubleshooting.rst + sandcastle-demo.rst diff --git a/design-documents/046-mumimo-contracts.rst b/design-documents/046-mumimo-contracts.rst @@ -157,8 +157,8 @@ The contract terms v1 will have the following structure: // messages. fulfillment_message_i18n?: { [lang_tag: string]: string }; - // List of products that are part of the purchase (see `Product`). - products: Product[]; + // List of products that are part of the purchase (see `ProductSold`). + products: ProductSold[]; // After this deadline has passed, no refunds will be accepted. refund_deadline: Timestamp; diff --git a/design-documents/063-libeufin-conversion-rate-classes.rst b/design-documents/063-libeufin-conversion-rate-classes.rst @@ -174,13 +174,13 @@ PATCH ``/conversion-rate-classes/$CLASS-ID`` DELETE ``/conversion-rate-classes/$CLASS-ID`` -Added an admin-only ``conversion_rate_class_id`` field of type `Integer`. It is optional field to POST ``/accounts`` requests (creating an account) and PATCH ``/accounts/$USERNAME`` requests (updating an account). +Added an admin-only ``conversion_rate_class_id`` field of type ``Integer``. It is optional field to POST ``/accounts`` requests (creating an account) and PATCH ``/accounts/$USERNAME`` requests (updating an account). Added query filter to GET ``/accounts`` (listing accounts) -Added ``conversion_rate_class`` field of type `AccountConversionRateClass` of GET ``/accounts/$USERNAME`` request with all the information about the convertion rate. ``conversion_rate_class_id`` points to the class assigned to the user but the values of the fields could be from the default class if the assigned class is not completed. +Added ``conversion_rate_class`` field of type ``AccountConversionRateClass`` of GET ``/accounts/$USERNAME`` request with all the information about the convertion rate. ``conversion_rate_class_id`` points to the class assigned to the user but the values of the fields could be from the default class if the assigned class is not completed. diff --git a/design-documents/070-alias-directory-mailbox.rst b/design-documents/070-alias-directory-mailbox.rst @@ -177,7 +177,8 @@ Alice selects the Alias type (e.g. GitHub or Email) and inputs a contacts Alias. If no results were found, Alice cannot import this contact. If found, Alice will be able to import this contact into the contact list. -Alternatively, the contact can also be imported using an ``add-contact`` Taler URI, see :ref:`Alias Management <dd-70 -us-alias-mgmt>`. +Alternatively, the contact can also be imported using an ``add-contact`` Taler +URI, see :ref:`Alias Management <dd-70-us-alias-mgmt>`. **Technical Note**: The wallet periodically performs lookups for contacts where their Taldir registrations have expired and refresh accordingly. diff --git a/design-documents/071-auto-refresh.rst b/design-documents/071-auto-refresh.rst @@ -90,9 +90,10 @@ Proposed Solution the respective currency if the remaining deposit period for any coin drops below 90 days. Distinguish in the warning key causes: - 1) "We are offline and cannot expand the validity period." - 2) "The payment service provider does not offer longer - validity periods." + + 1) "We are offline and cannot expand the validity period." + 2) "The payment service provider does not offer longer + validity periods." ..note:: diff --git a/design-documents/073-extended-merchant-template.rst b/design-documents/073-extended-merchant-template.rst @@ -4,7 +4,7 @@ DD 73: Extended Merchant Template Summary ======= -`#0010234 <https://bugs.gnunet.org/view.php?id=10234>`_ targets a wallet-first shopping cart experience by extending the merchant +`#0010234 <https://bugs.gnunet.org/view.php?id=10234>`__ targets a wallet-first shopping cart experience by extending the merchant template feature set with a dedicated inventory-driven template type. The new design keeps legacy fixed-order templates intact while enabling merchants to publish a single ``taler://pay-template`` QR code that lets the customer pick one @@ -14,7 +14,7 @@ Motivation ========== The existing template API (see :ref:`Section 1.4.15 <merchant-template-api>` of -the merchant manual and `LSD 0006 <https://lsd.gnunet.org/lsd0006/>`_) +the merchant manual and `LSD 0006 <https://lsd.gnunet.org/lsd0006/>`__) lets merchants pre-define mostly static contracts. Wallets can prompt the user for an amount or order summary, then instantiate an order without the merchant needing online infrastructure. This is valuable for: diff --git a/developer/taler-developer-manual.rst b/developer/taler-developer-manual.rst @@ -513,7 +513,7 @@ Demo Upgrade Procedure Upgrading the ``demo`` environment should be done with care, and ideally be coordinated on the mailing list before. It is our goal for ``demo`` to always run a "working version" that is compatible with various published wallets. -Please use the :doc:`demo upgrade checklist <checklists/checklist-demo-upgrade>` to make +Please use the :doc:`demo upgrade checklist <../checklists/checklist-demo-upgrade>` to make sure everything is working. Nginx is already configured to reach the services as exported by the user unit. @@ -1031,10 +1031,11 @@ At the tab *Version control* ( *https://weblate.taler.net/create/component/vcs/* At the tab *Commit messages* you can leave the defaults: * **Commit message when translating** has the most important message: -Translated using Weblate ({{ language_name }}) -Currently translated at {{ stats.translated_percent }}% ({{ stats.translated }} of {{ stats.all }} strings) -Translation: {{ project_name }}/{{ component_name }} -Translate-URL: {{ url }} + + Translated using Weblate ({{ language_name }}) + Currently translated at {{ stats.translated_percent }}% ({{ stats.translated }} of {{ stats.all }} strings) + Translation: {{ project_name }}/{{ component_name }} + Translate-URL: {{ url }} At the tab *Files* diff --git a/frags/nexus-ebics-setup.rst b/frags/nexus-ebics-setup.rst @@ -9,8 +9,6 @@ name of the *fiat* currency. The following snippet shows the mandatory configuration values: -.. _core-config: - .. code-block:: ini [nexus-ebics] diff --git a/libeufin/bank-manual.rst b/libeufin/bank-manual.rst @@ -273,7 +273,7 @@ Integration with the Taler Exchange .. note:: - This step is fully automated if you use the :doc:`automated setup manual<regional-automated-manual>`. + This step is fully automated if you use the :doc:`automated setup manual<../regional/regional-automated-manual>`. You must have an exchange account with username ``exchange`` for conversion to work. Assuming that the configuration file exists at ``$CONFIG_FILE``, the following @@ -299,7 +299,7 @@ Withdrawing e-cash to a Taler wallet .. note:: - This step is fully automated if you use the :doc:`automated setup manual<regional-automated-manual>`. + This step is fully automated if you use the :doc:`automated setup manual<../regional/regional-automated-manual>`. Users can withdraw digital cash from their bank account starting from their online banking as implemented by the libeufin-bank. However, in this scenario, diff --git a/libeufin/ebisync-manual.rst b/libeufin/ebisync-manual.rst @@ -143,7 +143,7 @@ with various credentials. Those must be provided in the The following snippet shows the mandatory configuration values: -.. _core-config: +.. _ebisync-core-config: .. code-block:: ini :caption: /etc/libeufin-ebisync/libeufin-ebisync.conf @@ -270,7 +270,7 @@ Fetching files ============== The responsible subcommand for fetching and uploading files is -``fetch``, and its configuration is a **superset** of core-config_. On +``fetch``, and its configuration is a **superset** of ebisync-core-config_. On top of that, it expects the database connection string, the destination config and *optionally* a frequency and a checkpoint time of day. diff --git a/libeufin/nexus-manual.rst b/libeufin/nexus-manual.rst @@ -124,7 +124,7 @@ submitted to the database, so this section only discusses how such queued payments will be executed. The responsible subcommand for sending payments is ``ebics-submit``, and its -configuration is a **superset** of core-config_. On top of that, it expects +configuration is a **superset** of :ref:`nexus-core-config`. On top of that, it expects the database connection string and *optionally* a frequency at which it will check for submittable payments in the database. @@ -211,7 +211,7 @@ subscriber accepted the bank keys. Furthermore, the database has to be set up. The responsible subcommand for fetching and registering payments is -``ebics-fetch``, and its configuration is a **superset** of core-config_. On +``ebics-fetch``, and its configuration is a **superset** of nexus-core-config_. On top of that, it expects the database connection string and *optionally* a frequency and a checkpoint time of day. diff --git a/oim-roadsigns/GNU Taler ‘with OIM Inside’.md b/orphaned/GNU Taler ‘with OIM Inside’.md diff --git a/regional/regional-automated-manual.rst b/regional/regional-automated-manual.rst @@ -166,7 +166,7 @@ with various credentials. Those must be provided in the The following snippet shows the mandatory configuration values: -.. _regio-nexus-core-config: +.. _nexus-core-config: .. code-block:: ini diff --git a/system-administration/uptime-kuma.rst b/system-administration/uptime-kuma.rst @@ -115,14 +115,14 @@ used using the following query written in https://jsonata.org/: We setup a separate monitor to check that wire fees are working (sure, they can be combined, but this way we can get a more precise alert): -.. code-block:: test +.. code-block:: none $max(wire_fees[*].[*].end_date.t_s) > $millis()/1000 To separate-out global fees monitoring (which is not present on all systems), we also use (except on GLS, which doesn't support P2P): -.. code-block:: test +.. code-block:: none $max(global_fees[*].end_date.t_s) > $millis()/1000 diff --git a/taler-exchange-manual.rst b/taler-exchange-manual.rst @@ -1473,7 +1473,7 @@ the an outgoing transfer: After enough time has passed, the money should arrive at the specified IBAN. For more information on the taler-wallet-cli tool, see -:doc:`taler-wallet`. +:doc:`manpages/taler-wallet-cli.1`. taler-exchange-config --------------------- diff --git a/taler-kyc-manual.rst b/taler-kyc-manual.rst @@ -499,7 +499,7 @@ pairs where the key is the form field name and the value depends on the key. The different keys are defined in the ``gnu-taler-form-attributes`` GANA registry. The respective AML program can then evaluate the data from the form -submission from `attributes`. +submission from ``attributes``. The LINK Type diff --git a/taler-merchant-pos-terminal.rst b/taler-merchant-pos-terminal.rst @@ -83,7 +83,7 @@ The GNU Taler merchant POS configuration is a single JSON file with the followin // The available product categories categories: MerchantCategory[]; - // Products offered by the merchant (similar to `Product`). + // Products offered by the merchant (similar to `ProductSold`). products: MerchantProduct[]; // Map from labels to locations diff --git a/tutorials.rst b/tutorials.rst @@ -1,6 +0,0 @@ -Tutorials -========= - -You can access the tutorials at: - -`https://tutorials.taler.net/ <https://tutorials.taler.net/>`_