diff --git a/content/designs/application-bundle-metadata.md b/content/designs/application-bundle-metadata.md
index 88cb9d043919ed2e7584be280877714faf7dcfa3..b4809e277a563469adfd78023256e10dc6673c59 100644
--- a/content/designs/application-bundle-metadata.md
+++ b/content/designs/application-bundle-metadata.md
@@ -485,13 +485,13 @@ The name (and several other metadata fields) can be translated via the
 `xml:lang` attribute. For example, GNOME Videos (Totem) has many
 language-specific names, starting with:
 
----
+```
   <name>Videos</name>
   <name xml:lang="af">Video's</name>
   <name xml:lang="ar">فيديو</name>
   <name xml:lang="as">ভিডিঅ'সমূহ</name>
   <name xml:lang="be">Відэа</name>
----
+```
 
 AppStream upstream XML does not include an icon, although the derived
 [AppStream collection XML] format published by redistributors does. We recommend
diff --git a/content/designs/application-entry-points.md b/content/designs/application-entry-points.md
index e69e626994608366c80a8eb08996925a467f9c07..d84ce41da49964dba3dad4060dfdb851d5d6a702 100644
--- a/content/designs/application-entry-points.md
+++ b/content/designs/application-entry-points.md
@@ -387,7 +387,7 @@ app bundles) or `/var/lib/apertis_extensions/applications`
 `{/usr,}/Applications/${bundle_id}/share/applications`, with content
 similar to this.
 
----
+```
 # /usr/share/applications/org.apertis.Rhayader.desktop
 [Desktop Entry]
 Type=Application
@@ -401,7 +401,7 @@ X-Apertis-InternetPriority=normal
 Categories=Network;WebBrowser;
 MimeType=text/html;x-scheme-handler/http;x-scheme-handler/https;
 Icon=applications-internet
----
+```
 
 ### Services
 
@@ -445,7 +445,7 @@ to ensure that only one activation occurs. The `Activate`, `Open` or
 
 The result would look something like this:
 
----
+```
 # org.apertis.Frampton.desktop
 [Desktop Entry]
 Type=Application
@@ -460,9 +460,9 @@ MimeType=audio/mpeg;
 NoDisplay=true;
 Icon=music
 X-Apertis-ServiceExec=/usr/Applications/org.apertis.Frampton/bin/frampton --gapplication-service
----
+```
 
----
+```
 # org.apertis.Frampton.Artists.desktop
 [Desktop Entry]
 Type=Application
@@ -474,9 +474,9 @@ X-Apertis-Type=application
 Categories=Audio;Player;Music;
 Icon=music-artist
 X-Apertis-ParentEntry=org.apertis.Frampton
----
+```
 
----
+```
 # org.apertis.Frampton.Albums.desktop
 [Desktop Entry]
 Type=Application
@@ -488,9 +488,9 @@ X-Apertis-Type=application
 Categories=Audio;Player;Music;
 Icon=music-album
 X-Apertis-ParentEntry=org.apertis.Frampton
----
+```
 
----
+```
 # org.apertis.Frampton.Songs.desktop
 [Desktop Entry]
 Type=Application
@@ -502,7 +502,7 @@ X-Apertis-Type=application
 Categories=Audio;Player;Music;
 Icon=music-track
 X-Apertis-ParentEntry=org.apertis.Frampton
----
+```
 
 ## Appendix: GSettingsSchema-based entry point registration prior to October 2015
 
@@ -639,7 +639,7 @@ In this model, each entry point (application or service) is a `.desktop`
 file. Frampton would install `org.apertis.Frampton.desktop`, with contents
 something like this:
 
----
+```
 # org.apertis.Frampton.desktop
 [Desktop Entry]
 Type=Application
@@ -680,7 +680,7 @@ X-Apertis-ShowInMenu=true
 Name=Shuffle All
 Icon=music-shuffle
 Exec=/usr/Applications/org.apertis.Frampton/bin/frampton-control --shuffle-all
----
+```
 
 The Desktop Entry Specification specifies that application launchers should
 present [desktop actions][Desktop Entry actions] to the user within
@@ -703,7 +703,7 @@ This model is similar to the one with desktop actions, but it acknowledges
 that desktop actions were not really designed to work that way, and uses
 Apertis-specific syntax inspired by desktop actions instead:
 
----
+```
 # org.apertis.Frampton.desktop
 [Desktop Entry]
 Type=Application
@@ -742,7 +742,7 @@ Exec=/usr/Applications/org.apertis.Frampton/bin/frampton --songs
 Name=Shuffle All
 Icon=music-shuffle
 Exec=/usr/Applications/org.apertis.Frampton/bin/frampton-control --shuffle-all
----
+```
 
 <!-- Other documents -->
 
diff --git a/content/designs/application-framework.md b/content/designs/application-framework.md
index 92c01b9954aea1fed6880be06d8ba4d84475fb0d..2fdceebd8383d0f81852c1e7611e8be936edbf73 100644
--- a/content/designs/application-framework.md
+++ b/content/designs/application-framework.md
@@ -512,12 +512,12 @@ here is an example with Goodvides, an internet radio player
 application:
 ```shell
 flatpak install flathub io.gitlab.Goodvibes
----
+```
 
 The application can then be run by clicking on the desktop icon or simply with:
 ```shell
 flatpak run io.gitlab.Goodvibes
----
+```
 
 Each application can be defined using a [standard manifest][Manifest] that
 describes all the dependencies, their source and how to build them. If a
@@ -536,14 +536,14 @@ previously mentioned:
 
 ```shell
 flatpak run --command=cat io.gitlab.Goodvibes /app/manifest.json > io.gitlab.Goodvibes.json
----
+```
 
  2) Build the flatpak locally, allowing to install the dependencies from flathub
  if required
 
 ```shell
 flatpak-builder --install-deps-from=flathub build-dir io.gitlab.Goodvibes.yaml
----
+```
 
 That's it, the flatpak is now built
 
@@ -551,7 +551,7 @@ That's it, the flatpak is now built
 
 ```shell
 flatpak-builder --run build-dir io.gitlab.Goodvibes.yaml goodvibes
----
+```
 
 # Legacy Apertis application framework
 
diff --git a/content/designs/application-layout.md b/content/designs/application-layout.md
index 06a6fe1a159e06de89cff794c9b48d4a4d46765b..c3e182f03a1d6e56439122a98b6146d48d617476 100644
--- a/content/designs/application-layout.md
+++ b/content/designs/application-layout.md
@@ -635,7 +635,7 @@ The application-visible directories in `/var/Applications` and `/Applications`
 are only mount points. Applications' real storage is situated on the general
 storage volume, in the following layout:
 
----
+```
 <general storage volume>
 ├─app-bundles/
 │ ├─com.example.MyApp/                  (store app-bundle)
@@ -659,7 +659,7 @@ storage volume, in the following layout:
 │   └─version-2.5.1-1/
 │     └─variable/                       (subvolume)
 … <other directories subvolumes unrelated to application bundles>
----
+```
 
 The `static` and `variable` directories are `btrfs` subvolumes so that they
 can be copied using snapshots, while the other directories shown may be
@@ -678,11 +678,11 @@ operations to implement "transactions".
 
 During normal operation, the subvolumes would be mounted as follows:
 
----
+```
 com.example.MyApp/current/static      → /Applications/com.example.MyApp
 com.example.MyApp/current/variable    → /var/Applications/com.example.MyApp
 org.apertis.Frampton/current/variable → /var/Applications/org.apertis.Frampton
----
+```
 
 so that the expected paths such as
 `/var/Applications/com.example.MyApp/users/1001/config/` are made available.
@@ -1079,7 +1079,7 @@ not currently public. `xyz` is used here to represent the common prefix
 for an Apertis variant. The layout of the store application bundle looks
 like this:
 
----
+```
 /appstore/
     store.json
     store.sig
@@ -1100,7 +1100,7 @@ like this:
             background.png
             icon_sudoku.png
             (more graphics)
----
+```
 
 The manifest indicates that `/xyz-sudoku.tar` is expected to
 be unpacked into `/Applications`, leading to filenames like
@@ -1109,7 +1109,7 @@ be unpacked into `/Applications`, leading to filenames like
 [Frampton] is an example of a built-in application bundle shipped in
 15.09. Its layout is as follows:
 
----
+```
 /usr/
     Applications/
         frampton/
@@ -1141,7 +1141,7 @@ be unpacked into `/Applications`, leading to filenames like
     frampton/
         app-data/
             (empty)
----
+```
 
 Issues with the application filesystem layout in these examples:
 
diff --git a/content/designs/applications.md b/content/designs/applications.md
index 09fc2bd44189f790c0f10760fa3af188cf4102c9..e0c830b04939e8c22adb8c283032654520e43682 100644
--- a/content/designs/applications.md
+++ b/content/designs/applications.md
@@ -927,7 +927,7 @@ be made.
 
 For more invasive system extensions, the application manager can decide
 based on the extension type in the application bundle metadata whether the
----
+```
 functionality requires that the system be restarted. The user should be
 informed during installation that new features will only be present next
 time they start their vehicle.
@@ -1194,7 +1194,7 @@ appropriate for Apertis to provide API to assist in performing the task
 accurately.
 
 A minimal C language API for state saving could be developed consisting
----
+```
 
   - A way to register a callback for a D-Bus signal that requests a save
     of state information.
diff --git a/content/designs/canterbury-legacy-application-framework.md b/content/designs/canterbury-legacy-application-framework.md
index fc533b7914a5cd8892ec9f259133d257a9ac7bcf..90e7f359f775216f186ba62695c18758fef1d617 100644
--- a/content/designs/canterbury-legacy-application-framework.md
+++ b/content/designs/canterbury-legacy-application-framework.md
@@ -112,13 +112,13 @@ necessary.
 
 Desktop file should be updated to use Flatpak instead of Canterbury to launch
 the application, e.g. replacing
----
+```
 Exec=@bindir@/eye app-name @app_id@ play-mode stop url NULL
----
+```
 by
----
+```
 Exec=flatpak run app-name @app_id@ play-mode stop url NULL
----
+```
 
 ## Application metadata
 
diff --git a/content/designs/coding_conventions.md b/content/designs/coding_conventions.md
index 4fa39a4f4c8638ac8194265209b85e476457e0bb..63ea1a6350d46acf1a3b9bb075085603cb2fbd99 100644
--- a/content/designs/coding_conventions.md
+++ b/content/designs/coding_conventions.md
@@ -64,9 +64,9 @@ style consistent as the files evolve. The following modeline should be put as
 the very first line of the file, immediately before the
 [copyright comment](license-applying.md#licensing-of-code):
 
----
+```
 /* vim:set et sw=2 cin cino=t0,f0,(0,{s,>2s,n-s,^-s,e2s: */
----
+```
 
 For more information about the copyright comment, see
 [Applying Licensing](https://designs.apertis.org/latest/license-applying.html).
@@ -77,27 +77,27 @@ If a file or module does not conform to the code formatting style and needs to
 be reindented, the following command will do most of the work — but it can go
 wrong, and the file **must** be checked manually afterwards:
 
----
+```
 indent -gnu -hnl -nbbo -bbb -sob -bad -nut /path/to/file
----
+```
 
 To apply this to all C and H files in a module:
 
----
+```
 git ls-files '*.[ch]' | \
 xargs indent -gnu -hnl -nbbo -bbb -sob -bad -nut
----
+```
 
 Alternatively, if you have a recent enough version of Clang (>3.5):
 
----
+```
 git ls-files '*.[ch]' | \
 xargs clang-format -i -style=file
----
+```
 
 Using a `.clang-format` file (added to git) in the same directory, containing:
 
----
+```
 # See https://designs.apertis.org/latest/coding_conventions.html#code-formatting
 BasedOnStyle: GNU
 AlwaysBreakAfterDefinitionReturnType: All
@@ -109,7 +109,7 @@ SpaceAfterCStyleCast: true
 # developer will line wrap appropriately. clang-format will still check
 # existing hanging indents.
 ColumnLimit: 0
----
+```
 
 ## Memory management
 
@@ -243,7 +243,7 @@ such as `(nullable)`.
 
 Pre- and post-condition assertions are implemented using
 [`g_return_if_fail()`](https://developer.gnome.org/glib/stable/glib-Warnings-and-Assertions.html#g-return-if-fail)
----
+```
 [`g_return_val_if_fail()`](https://developer.gnome.org/glib/stable/glib-Warnings-and-Assertions.html#g-return-val-if-fail).
 
 The pre-conditions should check each parameter at the start of the function,
@@ -319,32 +319,32 @@ or
 is almost certainly wrong. For example, iteration over a GList should be
 implemented using the linking pointers, rather than a incrementing index:
 
----
+```
 GList *some_list, *l;
 
 for (l = some_list; l != NULL; l = l->next)
----
+```
     gpointer element_data = l->data;
 
     /* Do something with @element_data. */
----
----
+```
+```
 
 Using an incrementing index instead results in an exponential decrease in
 performance (O(2×N^2) rather than O(N)):
 
----
+```
 GList *some_list;
 guint i;
 
 /* This code is inefficient and should not be used in production. */
 for (i = 0; i < g_list_length (some_list); i++)
----
+```
     gpointer element_data = g_list_nth_data (some_list, i);
 
     /* Do something with @element_data. */
----
----
+```
+```
 
 The performance penalty comes from `g_list_length()` and `g_list_nth_data()`
 which both traverse the list (O(N)) to perform their operations.
@@ -353,17 +353,17 @@ Implementing the above with a GPtrArray has the same complexity as the first
 (correct) GList implementation, but better cache locality and lower memory
 consumption, so will perform better for large numbers of elements:
 
----
+```
 GPtrArray *some_array;
 guint i;
 
 for (i = 0; i < some_array->len; i++)
----
+```
     gpointer element_data = some_array->pdata[i];
 
     /* Do something with @element_data. */
----
----
+```
+```
 
 ## Magic values
 
@@ -458,11 +458,11 @@ are a key feature of GLib-based object orientation. Properties should be used to
 expose state variables of the object. A guiding principle for the design of
 properties is that (in pseudo-code):
 
----
+```
 var temp = my_object.some_property
 my_object.some_property = "new value"
 my_object.some_property = temp
----
+```
 
 should leave `my_object` in exactly the same state as it was originally.
 Specifically, properties should **not** act as parameterless methods, triggering
diff --git a/content/designs/connectivity-documentation.md b/content/designs/connectivity-documentation.md
index 653f525e52a2fdaebcf80b139a889307e6f9b877..0d85cf64bc1c466717616e256b27b4acf8192617 100644
--- a/content/designs/connectivity-documentation.md
+++ b/content/designs/connectivity-documentation.md
@@ -57,11 +57,11 @@ The file STORAGEDIR/settings, where STORAGEDIR by default points to
 /var/lib/connman, shall be edited, or even created, to have the
 following content:
 
----
+```
 [WiFi]
 
 Enable=true
----
+```
 
 This configuration will tell ConnMan at start up to enable the WiFi
 radio.
@@ -262,7 +262,7 @@ infrastructure that a Connection Manager needs to manage the Protocol.
 In the Class Factory it is possible to see which methods are defined
 by this Class by looking at the *TpBaseProtocolClass base\_class* var:
 
----
+```
 base_class->get_parameters = get_parameters;
 base_class->new_connection = new_connection;
 base_class->normalize_contact = normalize_contact;
@@ -270,7 +270,7 @@ base_class->identify_account = identify_account;
 base_class->get_interfaces = get_interfaces;
 base_class->get_connection_details = get_connection_details;
 base_class->dup_authentication_types = dup_authentication_types;
----
+```
 
 Documentation on each method of this class can be found in the
 Telepathy-GLib documentation for
@@ -288,15 +288,15 @@ at the *RakiaConnectionClass* and *RakiaBaseConnectionClass*
 initializations. They are defined at *src/sip-connection.c* for the
 *RakiaBaseConnecionClass:*
 
----
+```
 sip_class->create_handle = rakia_connection_create_nua_handle;
 sip_class->add_auth_handler =
 rakia_connection_add_auth_handler;
----
+```
 
 and for the *TpBaseConnectionClass*:
 
----
+```
 base_class->create_handle_repos = rakia_create_handle_repos;
 base_class->get_unique_connection_name = rakia_connection_unique_name;
 base_class->create_channel_managers = rakia_connection_create_channel_managers;
@@ -306,7 +306,7 @@ base_class->start_connecting = rakia_connection_start_connecting;
 base_class->shut_down = rakia_connection_shut_down;
 base_class->interfaces_always_present =
 interfaces_always_present;
----
+```
 
 During the *TpBaseConnection* object construction the
 `create_channel_managers` method is called. A *Channel* is an
@@ -335,12 +335,12 @@ The callback then handles the message it receives through the
 *Connection* using the sofia-sip library. At the end of the function
 the following code can be found:
 
----
+```
 channel = rakia_text_manager_lookup_channel (fac, handle);
 if (!channel)
 	channel = rakia_text_manager_new_channel (fac, handle, handle, NULL);
 rakia_text_channel_receive (channel, sip, handle, text, len);
----
+```
 
 The RakiaTextManager tries to figure if an existing *Channel* for this
 message already exists, or if a new one needs to be created. Once the
@@ -360,7 +360,7 @@ through the exposed D-Bus interface. The request comes from the
 *TpChannelManager* object and is created by
 *rakia\_media\_manager\_requestotron()* in the end of its call chain:
 
----
+```
 static void
 channel_manager_iface_init (gpointer g_iface, gpointer iface_data)
 {
@@ -371,7 +371,7 @@ channel_manager_iface_init (gpointer g_iface, gpointer iface_data)
 	iface->create_channel = rakia_media_manager_create_channel;
 	iface->ensure_channel = rakia_media_manager_ensure_channel;
 }
----
+```
 
 Here in *channel\_manager\_iface\_init()*, telepathy-rakia sets which
 method it wants to be called when the [D-Bus methods][telepathy-glib-dbus]
diff --git a/content/designs/contribution-process.md b/content/designs/contribution-process.md
index 71babb90d9c4801ca687358c868eaca86fb77922..5cfa237e8058f164701f98fe6e746f33e3692348 100644
--- a/content/designs/contribution-process.md
+++ b/content/designs/contribution-process.md
@@ -66,8 +66,8 @@ intention to implement larger features before starting. Such a conversation
 might be started by sending an email to the projects devel
 [mailing list](https://lists.apertis.org/) saying:
 
----
----
+```
+```
 
 I'm attempting to use <project> to <task> for my project.
 
@@ -78,7 +78,7 @@ I'm open to suggestions should there be a better way to solve this.
 Thanks,
 
 <developer>
----
+```
 
 This enables other experienced developers the chance to suggest approaches that
 may prove to be the most efficient, saving effort in implementation and later
@@ -243,9 +243,9 @@ specific guidelines) and an account with commit rights on GitLab (see
 Propose changes by pushing a git branch to GitLab.
 
 * Check out the git repository:
----
+```
 git clone https://gitlab.apertis.org/[group name]/[repository name].git
----
+```
 * Create a local branch and make code changes in there. The branch should have
   the following naming convention: `wip/$username/$feature` or
   `wip/$username/$taskid`. This branch should be pushed into the destination
@@ -257,9 +257,9 @@ git clone https://gitlab.apertis.org/[group name]/[repository name].git
   [guidelines for making commits](https://wiki.apertis.org/Guidelines/Version_control#Guidelines_for_making_commits)
   ), test them and check you are allowed to submit them under the project’s
   license, following the [sign-offs](#signoffs) documentation
----
+```
 git commit -i -s
----
+```
 * Every commit must have an appropriate [`Signed-off-by:` tag](#signoffs) in
   the commit message.
 * Add a `Fixes: APERTIS-<task_id>` tag for each task in the proposed commit
@@ -361,10 +361,10 @@ indicates that they have agreed to the
 be multiple `Signed-off-by` lines for a commit, for example, by the developer
 who wrote the commit and by the maintainer who reviewed and pushed it:
 
----
+```
 Signed-off-by: Random J Developer <random@developer.example.org>
 Signed-off-by: Lucky K Maintainer <lucky@maintainer.example.org>
----
+```
 
 Apertis closely follows the Linux kernel process for sign-offs, which is
 described in section 11 of the
diff --git a/content/designs/debug-and-logging.md b/content/designs/debug-and-logging.md
index 6ead09fc498ce007f665a32e0a008b0520e7833e..d53e08d5a79d9b28ed86cb3b566a299a0cbfafde 100644
--- a/content/designs/debug-and-logging.md
+++ b/content/designs/debug-and-logging.md
@@ -598,9 +598,9 @@ are stored before being dropped. The systemd journal must have a disk
 space or age limit applied; this can be done by editing
 /etc/systemd/journald.conf and adding the following, for example:
 
----
+```
 SystemMaxUse=100M
----
+```
 
 To limit the priority level of messages which are stored to disk, the
 following configuration option can be used; it is highly recommended to
@@ -609,9 +609,9 @@ systems.
 
 > The full range of options is documented in `man 5 journald.conf`
 
----
+```
 MaxLevelStore=error
----
+```
 
 Logging must not have a large runtime overhead — each call from a
 process to the logging API must be fast. Furthermore, rate limiting must
@@ -620,10 +620,10 @@ system logs. This can be achieved using the following configuration
 options for the systemd journal; the following values limit each process
 to at most 1000 messages in a given 30 seconds:
 
----
+```
 RateLimitInterval=30s
 RateLimitBurst=1000
----
+```
 
 As discussed in the Robustness design, the journal should
 additionally be configured to leave an amount of free space smaller than
@@ -631,9 +631,9 @@ the reserved blocks of the file system containing the log files, so that
 log messages can continue to be written in low disk space conditions,
 allowing easier diagnosis of the problem:
 
----
+```
 SystemKeepFree=5%
----
+```
 
 ### Profiling tools
 
diff --git a/content/designs/encrypted-updates.md b/content/designs/encrypted-updates.md
index 7d1d3e9a8b6ae8f71e095ad80bce61f5b441dc27..e078d3c8cafd1f73b7a91fd53f17a4e6dcc21664 100644
--- a/content/designs/encrypted-updates.md
+++ b/content/designs/encrypted-updates.md
@@ -91,9 +91,9 @@ This can allow a bundle to be read using a main key or fallback key(s), and/or b
 On the device itself, Apertis Update Manager is in charge of decrypting the bundle and it will try as many keys as needed to unlock the bundle, there's no limitation on the number of keys which can be stored.
 
 Random keys for bundle encryption can be generated using:
----
+```
 head -c128 /dev/random | base64 --wrap=0
----
+```
 
 ### How keys can be stored on devices
   - Keys can be stored in separated files, located in read-only part of the filesystem: `/usr/share/apertis-update-manager/`
diff --git a/content/designs/geolocation-and-navigation.md b/content/designs/geolocation-and-navigation.md
index e4468dedfc7bc08a71e21a883d32c8012dca3137..acc7e73bda9698fc452725db89f89ce52275c4d0 100644
--- a/content/designs/geolocation-and-navigation.md
+++ b/content/designs/geolocation-and-navigation.md
@@ -1459,7 +1459,7 @@ the standard org.freedesktop.DBus.Properties signals. We recommend the
 following API, exposed at the well-known name
 org.apertis.Navigation1:
 
----
+```
 /* This object should implement the org.freedesktop.DBus.ObjectManager standard
    API to expose all existing routes to clients.
 */
@@ -1480,7 +1480,7 @@ object /org/apertis/Navigation1/Routes/$ID {
   read-only a{ss} property Title; /* mapping from language name to a human-readable title of the route in this language. Language names are using the POSIX locale format with locale identifiers defined by ISO 15897, like fr_BE for example. */
   read-only a{ua{ss}} property GeometryDescriptions; /* array of pairs of index and description, which attach a description, in various languages, to points in the geometry property. Language names use the same format as in the Title property. */
 }
----
+```
 
 > Syntax is a pseudo-IDL and types are as defined in the D-Bus
 > specification, <http://dbus.freedesktop.org/doc/dbus-specification.html#type-system>
@@ -1517,12 +1517,12 @@ following API, exposed at the well-known name
 `org.apertis.NavigationGuidance1.Progress` on the object
 `/org/apertis/NavigationGuidance1/Progress`:
 
----
+```
 interface org.apertis.NavigationGuidance1.Progress {
   read-only t property StartTime; /* UNIX timestamp, to be interpreted in the local timezone */
   read-only t property EstimatedEndTime; /* UNIX timestamp, to be interpreted in the local timezone */
 }
----
+```
 
 Additional properties may be added in future.
 
@@ -1547,7 +1547,7 @@ We recommend the following API, exposed at the well-known name
 `org.apertis.NavigationGuidance1.TurnByTurn` on the object
 `/org/apertis/NavigationGuidance1/TurnByTurn`:
 
----
+```
 interface org.apertis.NavigationGuidance1.TurnByTurn {
   /* See https://people.gnome.org/~mccann/docs/notification-spec/notification-spec-latest.html#command-notify */
   method Notify (in u replaces_id,
@@ -1562,7 +1562,7 @@ interface org.apertis.NavigationGuidance1.TurnByTurn {
 
   method CloseNotification (in u id)
 }
----
+```
 
 > Syntax is a pseudo-IDL and types are as defined in the D-Bus
 > specification, <http://dbus.freedesktop.org/doc/dbus-specification.html\type-system>
@@ -1794,7 +1794,7 @@ The geofencing service must be available as the well-known name
 org.freedesktop.GeoClue2.Geofencing on D-Bus. It must export the
 following object:
 
----
+```
 /org/freedesktop/GeoClue2/Geofencing/Manager {
   /* Adds a geofence as a latitude, longitude and radius (in metres), and
    * returns the ID of that geofence. The dwell\_time (in seconds) gives
@@ -1819,7 +1819,7 @@ following object:
    * dwelling inside. */
   signal GeofenceActivity(out au entered, out au dwelling, out au exited)
 }
----
+```
 
 IDs are global and opaque — applications cannot find the area referenced
 by a particular geofence ID. A geofence may only be removed by the
diff --git a/content/designs/image-build-infrastructure.md b/content/designs/image-build-infrastructure.md
index 5b86b51c599c6aee5193f319d553825e9910ddb6..e8547628100e3bf88d58953cc19b8eb2554f2dce 100644
--- a/content/designs/image-build-infrastructure.md
+++ b/content/designs/image-build-infrastructure.md
@@ -35,7 +35,7 @@ environment.
 For each Apertis release there are two relevant Jenkins jobs to build images;
 The first job builds a Docker image which defines the build environment and
 uploads the resulting image to the Apertis Docker registry. This is defined in
----
+```
 [apertis-docker-images git repository](https://gitlab.apertis.org/infrastructure/apertis-docker-images).
 The second job defines the build steps for the various ospacks, hardware packs and
 images which are run in the Docker image build by the previous job; it also
@@ -66,9 +66,9 @@ satisfied on slave machines:
 For the last requirement on Debian systems this can be achieved by dropping a
 file called /etc/udev/rules.d/99-kvm-perms.rules in place with the following
 content.
----
+```
 SUBSYSTEM=="misc", KERNEL=="kvm", GROUP="kvm", MODE="0666"
----
+```
 
 Documentation for installing Docker on Debian can be found as  part of the
 [Docker documentation](https://docs.docker.com/install/linux/docker-ce/debian/).
@@ -288,8 +288,8 @@ Jenkins master:
 To retrieve the list, access the [script console](https://jenkins.apertis.org/script)
 and enter the following Groovy script:
 
----
+```
 Jenkins.instance.pluginManager.plugins.toList()
   .sort{plugin -> plugin.getShortName()}
   .each{plugin -> println ("* ${plugin.getShortName()}")}
----
+```
diff --git a/content/designs/infrastructure-maintenance-automation.md b/content/designs/infrastructure-maintenance-automation.md
index 402e6705d7032047dba8dbabc66e79a851de03c0..694db3ef139c93c1847ffc331cb27a09f9953d74 100644
--- a/content/designs/infrastructure-maintenance-automation.md
+++ b/content/designs/infrastructure-maintenance-automation.md
@@ -237,7 +237,7 @@ projects:
           suite: infrastructure-v2019
           components:
             - buster
----
+```
 
 ### Per-repository branching operations
 
diff --git a/content/designs/inter-domain-communication.md b/content/designs/inter-domain-communication.md
index 9a452ed0a86e15a0f8c1668830237a9e63c15513..11df736e07ccd88333160c6d3881f3b13285fa88 100644
--- a/content/designs/inter-domain-communication.md
+++ b/content/designs/inter-domain-communication.md
@@ -298,26 +298,26 @@ The following diagrams depict the data and control flow when the Bluetooth
 device is attached to the AD.
 
 Sending audio stream from BT to AD
----
+```
   BT device                  AD                      CE
       |  ---   attach   ---> |                        |
       |  ---------      encoded audio      ---------> |
       |                      | <--- decoded audio --- |
                 (mixing decoded audio in AD) 
----
+```
 
 Sending audio stream from AD to BT
----
+```
   BT device                  AD                      CE
       |  ---   attach   ---> |                        |
       |                      | ---- LPCM audio ---->  |
       |  <--------      encoded audio      ---------  |
----
+```
 
 The following diagram depicts the data and control flow when the Bluetooth
 device is directly attached to the CE instead.
 
----
+```
 BT device                           CE                       AD
     | --------- attach -----------> |                         |
     | <-------- control ----------  |                         |
@@ -326,12 +326,12 @@ BT device                           CE                       AD
     |                               | ------- LPCM audio ---> |
     |                               | <------ LPCM audio ---- |
     | <-------- encoded audio ----- |
----
+```
 
 The following diagram depicts the data and control flow when the Bluetooth
 device is directly attached to the CD.
 
----
+```
 BT device                      CD                CE          AD
     | ---- attach -----------> |                  |           |
     | <--- control ----------  |                  |           |
@@ -343,7 +343,7 @@ BT device                      CD                CE          AD
     |                          | --------- LPCM audio ------> |
     |                          | <-------- LPCM audio ------- |
     | <--- encoded audio ----- |
----
+```
 Multiple variations are possible on this model.
 
 ### Audio transfer
@@ -2285,7 +2285,7 @@ normative: real implementations can diverge from the interfaces described
 here and the actual API to be used by SDK services must be documented in a
 separate specification.
 
----
+```
 /* The interface exported by the adapter/gateway to SDK services to initiate channel creation. */
 interface org.apertis.InterDomain.DataConnection1 {
   /* @id: the app-specific unique token used to to identify and authorize the channel
@@ -2377,7 +2377,7 @@ interface org.apertis.InterDomain.DataConnectionInternal1 {
                       in s sender,
                       in s destination)
 }
----
+```
 
 #### Data channel API flow example for a media player streaming audio
 
@@ -2385,7 +2385,7 @@ A possible use-case of the API is a Media Player frontend hosted on the AD with
 The frontend requests the backend to decode a specific stream using an application specific API
 and passing a token with the request.
 
----
+```
                  AD                          |                       CE
 media player              gateway            |         adapter                media player
  frontend                                    |                                  backend
@@ -2401,7 +2401,7 @@ media player              gateway            |         adapter                me
     o <-- ChannelCreated() ---- o            |            o -- CreateChannel() --> o
                                              |                     reply
     o <------------------------------- data channel ------------------------------ o
----
+```
 
 The Media Player frontend initially calls
 the application-specific `Play()` method on its backend,
@@ -2446,7 +2446,7 @@ shares them with the update manager in the AD which has access to the devices
 to be updated.
 
 
----
+```
                  AD                          |                       CD
 update manager               gateway         |         adapter                 OTA agent
     o ----> GetUpdate()  -------o------------|------------o----------------------> o
@@ -2466,7 +2466,7 @@ update manager               gateway         |         adapter                 O
     o <-- ChannelCreated() ---- o            |            o -- CommitChannel() --> o
                                              |                     reply
 
----
+```
 
 The update manager calls the `GetUpdate()` method of the agent, with a token
 identifying the request. The OTA agent retrieves the metadata of the file to
@@ -2654,7 +2654,7 @@ domains must trigger the
 [`NameOwnerChanged signal`](https://dbus.freedesktop.org/doc/dbus-specification.html#bus-messages-name-owner-changed)
 in response to the
 [`org.freedesktop.DBus.ReleaseName()`](https://dbus.freedesktop.org/doc/dbus-specification.html#bus-messages-release-name)
----
+```
 [`org.freedesktop.DBus.RequestName()`](https://dbus.freedesktop.org/doc/dbus-specification.html#bus-messages-request-name)
 calls. No specific ordering is required and thus the service may be
 temporarily unavailable or the two domains may export the same service
@@ -2973,7 +2973,7 @@ protocol library ([][Protocol library and inter-domain services]). In the CE dom
 as a D-Bus interface on the private bus which is part of the adapter
 layer. This limits its access to developers who have access to that bus.
 
----
+```
 Interface org.apertis.InterDomainConnection.Debug1 {
   /* Mapping from IKEv1 initiator cookie to encryption key. */
   readonly property a{ss} Ike1Keys;
@@ -2984,7 +2984,7 @@ Interface org.apertis.InterDomainConnection.Debug1 {
    * hexadecimal strings to allow for varying key lengths. */
   readonly property a((ss)(ssssussu)) Ike2Keys;
 }
----
+```
 
 A [new Lua plugin][ws-decrypt-plugin] in Wireshark could connect to this interface and
 listen for signals of updates to the connection’s keys, and use those to
@@ -3532,13 +3532,13 @@ standard, supported by the GStreamer `funnel` element.
 
 The following diagram shows how a RFC 5761 pipeline can be set up in GStreamer:
 
----
+```
 /--------\     /---------\     /--------\         /---------------\          /----------\
 | audio  | === | audio   | === | rtpbin | = rtp = | rtp payloader |  = rtp = |          |     /----------\
 | source |     | convert |     |        |         \---------------/          |  funnel  | === | udp sink |
 \--------/     \---------/     |        | =========================== rtcp = |          |     \----------/
                                \--------/                                    \----------/
----
+```
 
 ## Appendix: Audio and video decoding
 
diff --git a/content/designs/internationalization.md b/content/designs/internationalization.md
index a47a26b7cd004e35366db7e23dabc374d76730f7..72785d89e804d44259d777e4c9a779acbda815eb 100644
--- a/content/designs/internationalization.md
+++ b/content/designs/internationalization.md
@@ -113,7 +113,7 @@ detail.
 This is an example of all the metadata that a translated string can have
 attached:
 
----
+```
 #. Make sure you use the IEC equivalent for your language
 ## Have never seen KiB used in our language, so we'll use KB
 #: ../glib/gfileutils.c:2007
@@ -122,7 +122,7 @@ attached:
 msgctxt "File properties dialog"
 msgid "%.1f KiB"
 msgstr "%.1f KB"
----
+```
 
 For strings embedded inside [ClutterScript] files, ClutterScript supports a
 `translatable` property to mark the string as translatable. So to mark the text
@@ -135,7 +135,7 @@ of a `ClutterText` as translatable, the following ClutterScript should be used:
         "string" : "Label Text"
     }
 }
----
+```
 
 Note that `clutter_script_set_translation_domain()` or
 [`textdomain()`][textdomain] needs to be called before translatable strings can
@@ -214,17 +214,17 @@ font descriptions.
 Here is an example of such a metadata file, note the font styles `NORMAL`,
 `TITLE` and `APPLICATION_LIST`:
 
----
+```
 PARK_ASSIST_1 NORMAL 120px
 PARK_ASSIST_2 NORMAL 210px
 SETTINGS_1 TITLE 445px
 BROWSER APPLICATION_LIST 120px
----
+```
 
 And here is the PO file that would result after merging the metadata in,
 ready to be uploaded to Transifex:
 
----
+```
 #. NORMAL,120px
 #: ../preferences.c:102
 msgid "PARK_ASSIST_1"
@@ -233,7 +233,7 @@ msgstr "Park assist"
 #: ../preferences.c:104
 msgid "PARK_ASSIST_2"
 msgstr "Park assist"
----
+```
 
 If for some reason some source code is reused that uses English for its
 translation IDs and the rest of the application or library uses
diff --git a/content/designs/jenkins-docker.md b/content/designs/jenkins-docker.md
index 641ce382e395c1fd4cb5f9e18325578ead0d6fde..a1b00687cf53a2f584dda4f42b2351bc6c0ae8a2 100644
--- a/content/designs/jenkins-docker.md
+++ b/content/designs/jenkins-docker.md
@@ -91,11 +91,11 @@ access to the KVM device.
 Developers can retrieve and launch the same environment used by Jenkins with a
 single command:
 
----
+```
 $ docker run \
   -t docker-registry.apertis.org/apertis/apertis-18.09-image-builder \
   /bin/bash
----
+```
 
 ### Documentation
 
diff --git a/content/designs/lava-external-devices.md b/content/designs/lava-external-devices.md
index 22ca3bbd204c3d46decbc63cb9587f8d65ee8055..6f2ebf3017d508a000f6755f373a1ccd793beb21 100644
--- a/content/designs/lava-external-devices.md
+++ b/content/designs/lava-external-devices.md
@@ -130,7 +130,7 @@ the device which starts the secondary connection guests or at any later point
 
 ### Job File Example
 
----
+```
 job_name: LXC and Secondary connection with a Device
 
 timeouts:
@@ -389,7 +389,7 @@ actions:
       from: git
       path: lava-test-shell/single-node/singlenode03.yaml
       name: singlenode-advanced
----
+```
 
 # QA Report
 
diff --git a/content/designs/license-applying.md b/content/designs/license-applying.md
index 4d4d4c3c8886877e6dd664b2686e75298d308058..e03eb46cda92c0a8e6ea0db8328642e3a99b32b1 100644
--- a/content/designs/license-applying.md
+++ b/content/designs/license-applying.md
@@ -59,16 +59,16 @@ Licensing all parts of your project appropriately is not complicated and we
 highly recommend that you do so. Your typical directory structure should look
 something like:
 
----
+```
 <project>
 ↳COPYING
 ↳COPYING.MPL
----
+```
 
 The `COPYING` file should contain information about all parts of the project.
 For example, it could look like:
 
----
+```
 <project> is an Apertis project and follows the licensing guidelines as
 specified at https://wiki.apertis.org/Licensing.
 
@@ -88,7 +88,7 @@ Documentation
 All documentation in this project is licensed under CC BY-SA 4.0 International.
 For information about the license, see
 https://creativecommons.org/licenses/by-sa/4.0/
----
+```
 
 Your `COPYING.MPL` should contain the full license text for the Mozilla Public
 License Version 2.0. You may also need to have other license-specific `COPYING`
@@ -121,7 +121,7 @@ mistakes as the code is publicly available and archived.
 
 This is what a typical MPL license header looks like:
 
----
+```
 /*
  * Copyright © 2015, 2016 Anita Developer <a.developer@example.com>
  *
@@ -129,8 +129,8 @@ This is what a typical MPL license header looks like:
  * This Source Code Form is subject to the terms of the Mozilla Public
  * License, v. 2.0. If a copy of the MPL was not distributed with this
  * file, You can obtain one at http://mozilla.org/MPL/2.0/.
----
----
+```
+```
 
 For additional guidance on how license headers work, please read the
 [GNU license guidance](https://www.gnu.org/licenses/gpl-howto.html). The
@@ -153,9 +153,9 @@ For example,
 
 Your copyright notice should normally look something like:
 
----
+```
 Copyright © 2016 Anita Developer <a.developer@example.com>
----
+```
 
 For documentation written in Mallard, you should use the `<credit>`, `<name>`,
 `<email>` and `<years>` tags which will generate the correct copyright notice
@@ -200,7 +200,7 @@ For example, if your copyright notice was
 `Copyright © 2016 Andrew Contributor <a.contributor@example.com>` then the
 resulting copyright header would look like:
 
----
+```
 /*
  * Copyright © 2015, 2016 Anita Developer <a.developer@example.com>
  * Copyright © 2016 Andrew Contributor <a.contributor@example.com>
@@ -209,8 +209,8 @@ resulting copyright header would look like:
  * This Source Code Form is subject to the terms of the Mozilla Public
  * License, v. 2.0. If a copy of the MPL was not distributed with this
  * file, You can obtain one at http://mozilla.org/MPL/2.0/.
----
----
+```
+```
 
 ## License for images
 
@@ -231,20 +231,20 @@ its website.
 For example, if your copyright notice is
 `© 2016 Alice Artist <a.artist@example.com>` then this command will add it to
 the `Exif.Image.Copyright` key:
----
+```
 exiv2 -v -M"set Exif.Image.Copyright Copyright © 2016 Alice Artist <a.artist@example.com>. This work is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA." <path to your image>
----
+```
 
 Replace the copyright notice with your own and replace `<path to your image>`
 with the path to the image which you want to update.
 
 You can now check the copyright notice with:
----
+```
 exiv2 <path to your image>
----
+```
 
 Which will output something that looks like:
----
+```
 File name       : apertis-icon.png
 File size       : 1228 Bytes
 MIME type       : image/png
@@ -256,6 +256,6 @@ l License. To view a copy of this license, visit <nowiki>http://creativecommons.
 nses/by-sa/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View
 , CA 94042, USA.
 Exif comment    :
----
+```
 There may be some other tags present in the output.
 
diff --git a/content/designs/license-validation.md b/content/designs/license-validation.md
index df1c0ed99146d3a950e26bb1ccf2e2cf74406cbb..60dc09ea3264f52a8daaa2f21929a64ee04c4848 100644
--- a/content/designs/license-validation.md
+++ b/content/designs/license-validation.md
@@ -167,10 +167,10 @@ Ninka. It also detects copyright statements. It output results in plain text
 Perl.
 
 Auto generating a `debian/copyright` can be easily accomplished by:
----
+```
 licensecheck --copyright -r `find * -type f` | \
   /usr/lib/cdbs/licensecheck2dep5 > debian/copyright.auto
----
+```
 
 #### debmake
 [debmake](https://anonscm.debian.org/cgit/collab-maint/debmake.git) is a program
@@ -179,14 +179,14 @@ copyright+license (-c) and compare `debian/copyright against current sources and
 exit (-k). Written in Python.
 
 Auto generating a `debian/copyright` can be easily accomplished by:
----
+```
 debmake -cc > debian/copyright
 
----
+```
 Compare new sources against upstream new sources:
----
+```
 debmake -k
----
+```
 It focus on license types and file matching, and is able to detect ineffective
 blocks in the copyright file.
 
@@ -213,9 +213,9 @@ to licensing changes that must be acknowledged.
 #### cme
 [cme](https://metacpan.org/release/App-Cme) option is based on a config parsing
 library.
----
+```
 cme update dpkg-copyright
----
+```
 This will create or update `debian/copyright`. The cme tool seem to handle UTF-8
 names better than debmake. Written in Perl, using licensecheck.
 
diff --git a/content/designs/list.md b/content/designs/list.md
index 9b30f54acdcd3ce3fa66f5d5882988b6c8be1970..3df1e64ca7bb0034c71b169d72e30eefce419a08 100644
--- a/content/designs/list.md
+++ b/content/designs/list.md
@@ -630,7 +630,7 @@ clutter_actor_set_x_align (third_actor, CLUTTER_ACTOR_ALIGN_FILL);
 
 /* this actor will be centered inside the allocation. */
 clutter_actor_set_x_align (fourth_actor, CLUTTER_ACTOR_ALIGN_CENTER);
----
+```
 
 More details can be found in the [`ClutterActor`] documentation.
 
diff --git a/content/designs/multiuser.md b/content/designs/multiuser.md
index 4216cf3c8f82f625dd5e3acdae4f1dfa7a685163..5d31b37bed99c400b6774d705b4644aae840c48f 100644
--- a/content/designs/multiuser.md
+++ b/content/designs/multiuser.md
@@ -697,7 +697,7 @@ made based on concrete requirements.
 One valuable general design principle is that, when a user carries out
 an action, it should be easy to predict the outcome. In the context of a
 multi-user system, this implies various more concrete principles, such
----
+```
 
   - sharing should not occur when a user would not expect it to; this
     “over-sharing” is likely to lead to users distrusting the system
diff --git a/content/designs/preferences-and-persistence.md b/content/designs/preferences-and-persistence.md
index 48a965691b2895bdd8b82fb9f83deabcc830cfce..649c48ebadd85d78fa298c2ef7fb19ae47f7b5f2 100644
--- a/content/designs/preferences-and-persistence.md
+++ b/content/designs/preferences-and-persistence.md
@@ -867,11 +867,11 @@ layer:
 This would be implemented as the dconf
 profile:
 
----
+```
 user-db:user
 file-db:/Applications/net.example.MyApplication/username/config/dconf/app
 system-db:local
----
+```
 
 All accesses to dconf would go through GSettings, and then through the
 proxy service which applies AppArmor rules to restrict access to
@@ -901,9 +901,9 @@ GSettings.
 
 The existing Apertis system puts
 
----
+```
 #include <abstractions/gsettings>
----
+```
 
 in several of the AppArmor profiles, which gives unrestricted access to
 the user dconf database. This must change with the new system, only
@@ -1635,7 +1635,7 @@ they are written. This is what dconf uses for storage.
 All updates to a GVDB file are atomic, as it uses the same
 atomic-overwrite technique as [][GKeyFile]. Transactions are
 supported similarly — by writing out the updated database or discarding
----
+```
 
 The amount of I/O for reads from a GVDB file is small, as it memory-maps
 the database, so only pages in the data it actually reads (plus some
diff --git a/content/designs/robustness.md b/content/designs/robustness.md
index 27e131775be00e9c5fbc236de015b4a4bac58697..83ceda3c0fa2bb10f9023939a85872b443567403 100644
--- a/content/designs/robustness.md
+++ b/content/designs/robustness.md
@@ -241,7 +241,7 @@ hardware features available with the storage media.
 The System Updates and Rollback Design describes the partition layout
 for Apertis. Not all the partitions have the same requirements, so both
 the FAT32 and BTRFS filesystems are used. The partitions are configured
----
+```
 
   - **Factory Recovery** – This partition is never mounted read-write
     and must be readable by the boot loader. Currently the boot loader
diff --git a/content/designs/secure-boot.md b/content/designs/secure-boot.md
index fa9b44747f66765b6c7f73ea39afe4a28fa42f25..0a920d17a0f9ff9192018f3850838b919e635782 100644
--- a/content/designs/secure-boot.md
+++ b/content/designs/secure-boot.md
@@ -256,13 +256,13 @@ hash only once!
 To fuse the [Apertis SRK hash](https://gitlab.apertis.org/infrastructure/apertis-imx-srk/-/blob/master/SRK_1_2_3_4_fuse.bin)
 we have to have the hexadecimal dump of the hash of the key. Command below will produce the
 output with commands for Apertis SRK hash fusing:
----
+```
 $ hexdump -e '/4 "0x"' -e '/4 "%X""\n"' SRK_1_2_3_4_fuse.bin | for i in `seq 0 7`; do read h; echo fuse prog -y 3 $i $h; done
----
+```
 
 This command generates the list of commands to be executed in a U-Boot CLI.
 For Apertis SRK hash fusing they are:
----
+```
 fuse prog -y 3 0 0xFD415383
 fuse prog -y 3 1 0x519690F5
 fuse prog -y 3 2 0xE844EB48
@@ -271,7 +271,7 @@ fuse prog -y 3 4 0xEC0F8D7C
 fuse prog -y 3 5 0x2F209598
 fuse prog -y 3 6 0x9A98BE3
 fuse prog -y 3 7 0xAAD9B3D6
----
+```
 
 After execution of commands above only [Apertis development keys](https://gitlab.apertis.org/infrastructure/apertis-imx-srk/)
 can be used for signing the U-Boot binary.
@@ -291,20 +291,20 @@ different. The i.MX6 device may work in 2 modes:
 
 To check if your device is booted with correctly signed bootloader, and
 SRK key is fused, just type this in the U-Boot CLI:
----
+```
 => hab_status 
 
 Secure boot enabled
 
 HAB Configuration: 0xcc, HAB State: 0x99
 No HAB Events Found!
----
+```
 The output shows if the device is in "closed" mode (secure boot enabled) and 
 booted without any security errors.
 
 In case of errors in "open" mode the same command will show the
 list of HAB events similar to:
----
+```
 --------- HAB Event 5 -----------------
 event data:
     0xdb 0x00 0x14 0x41 0x33 0x21 0xc0 0x00
@@ -315,14 +315,14 @@ STS = HAB_FAILURE (0x33)
 RSN = HAB_INV_CERTIFICATE (0x21)
 CTX = HAB_CTX_COMMAND (0xC0)
 ENG = HAB_ENG_ANY (0x00)
----
+```
 
 During Linux kernel verification it is possible to emulate the "closed" mode
 with `fuse override` command and proceed with the boot:
----
+```
 => fuse override 0 6 0x2
 => run bootcmd
----
+```
 _Note_: the only issue with closed mode emulation -- the device will
 accept kernel signed with any key, but HAB events will be
 generated and shown in that case.
@@ -331,9 +331,9 @@ To close a device you need to fuse the same values used for overriding.
 
 **_Caution_**: the board can only use bootloaders signed with the Apertis development key after the
 step below! This is irreversible operation:
----
+```
 => fuse prog 0 6 0x2
----
+```
 
 ## Secure boot in the U-Boot package for Sabrelite
 
@@ -364,7 +364,7 @@ as a template for your U-Boot binary.
 U-Boot for SabreLite board doesn't use SPL, hence the whole `u-boot.imx` binary
 must be signed. With enabled `CONFIG_SECURE_BOOT` option the build log
 will contain following output (and file `u-boot.imx.log` as well):
----
+```
 Image Type:   Freescale IMX Boot Image
 Image Ver:    2 (i.MX53/6/7 compatible)
 Mode:         DCD
@@ -373,25 +373,25 @@ Load Address: 177ff420
 Entry Point:  17800000
 HAB Blocks:   0x177ff400 0x00000000 0x00091c00
 DCD Blocks:   0x00910000 0x0000002c 0x00000310
----
+```
 we need values from the string started with "HAB Blocks:".
 Those values must be used in "[Authenticate Data]" section of
 [template](https://gitlab.apertis.org/infrastructure/apertis-imx-srk/-/blob/master/csf/csf_uboot.txt):
----
+```
 [Authenticate Data]
     Verification index = 2
     Blocks = 0x177ff400 0x00000000 0x00091C00 "u-boot.imx"
----
+```
 
 To sign the U-Boot with `cst` tool simply call:
----
+```
 cst -i csf_uboot.txt -o csf_uboot.bin
----
+```
 File `csf_uboot.bin` will contain signatures which should be
 appended to original `u-boot.imx` binary:
----
+```
 cat u-boot.imx csf_uboot.bin > u-boot.imx.signed
----
+```
 
 ### Sign U-Boot bootloader for loading via USB serial downloader
 
@@ -407,23 +407,23 @@ document.
 The template [csf_uboot.txt](https://gitlab.apertis.org/infrastructure/apertis-imx-srk/-/blob/master/csf/csf_uboot.txt)
 for signing U-Boot to be loaded over serial downloader protocol should contain
 additional block in "[Authenticate Data]" section:
----
+```
 [Authenticate Data]
     Verification index = 2
     Blocks = 0x177ff400 0x00000000 0x00091C00 "u-boot.imx", \
              0x00910000 0x0000002c 0x00000310 "u-boot.imx"
----
+```
 
 With the help of [mod_4_mfgtool.sh](https://storage.googleapis.com/boundarydevices.com/mod_4_mfgtool.sh)
 script we need to store and restore DCD address from original `u-boot.imx`
 in addition to signing:
 
----
+```
 sh mod_4_mfgtool.sh clear_dcd_addr u-boot.imx
 cst -i csf_uboot.txt -o csf_uboot.bin
 sh mod_4_mfgtool.sh set_dcd_addr u-boot.imx
 cat u-boot.imx csf_uboot.bin > u-boot.imx.signed_usb
----
+```
 
 ## Sign kernel images for U-Boot to load
 
@@ -460,7 +460,7 @@ be copied to configured memory regions after successful verification.
 To create the FIT image you need to have `mkimage` command from the
 package `u-boot-tools` compiled with FIT support. With FIT source file
 prepared just run `mkimage` and generate the FIT binary:
----
+```
 $ mkimage -f vmlinuz.its vmlinuz.itb
 FIT description: Apertis armhf kernel with dtb and initramfs
 Created:         Fri Mar 13 02:23:33 2020
@@ -506,7 +506,7 @@ Created:         Fri Mar 13 02:23:33 2020
   Hash algo:    sha1
   Hash value:   unavailable
 CSF Processed successfully and signed data available in vmlinuz.itb
----
+```
 
 ### Signing the FIT image
 
@@ -518,14 +518,14 @@ since it is prepared automatically during the build of the bootloader.
 The IVT is needed for the HAB ROM and must be the part of the binary, it should
 be aligned to `0x1000` boundary.
 For instance, if the produced binary is:
----
+```
 $ stat -c "%s" vmlinuz.itb
 25555173
----
+```
 we need to pad the file to nearest aligned value, which is `25559040`:
----
+```
 $ objcopy -I binary -O binary --pad-to=25559040 --gap-fill=0x00 vmlinuz.itb vmlinuz-pad.itb
----
+```
 
 The next step is IVT generation for the FIT image and the easiest method is to
 use the [`genIVT` script](https://storage.googleapis.com/boundarydevices.com/genIVT)
@@ -538,13 +538,13 @@ provided by Boundary Devices with adaptation for padded FIT image:
   Pointer to signature data, which we will add after IVT
 
 So, the IVT generation is pretty simple:
----
+```
 $ perl genIVT
----
+```
 it will generate the binary named `ivt.bin` to be added to the image:
----
+```
 $ cat vmlinuz-pad.itb ivt.bin > vmlinuz-pad-ivt.itb
----
+```
 
 We need to prepare the config file for signing the padded FIT image with IVT.
 This step is absolutely the same as for [U-Boot signing](#sign-uboot-bootloader-such-that-the-rom-can-verify).
@@ -553,18 +553,18 @@ Configuration file for FIT image is created from
 template [csf_uboot.txt](https://gitlab.apertis.org/infrastructure/apertis-imx-srk/-/blob/master/csf/csf_uboot.txt),
 and values in `[Authenticate Data]` section must be the same as used
 for IVT calculation -- Jump Location and the size of generated file:
----
+```
 [Authenticate Data]
     Verification index = 2
     # Authenticate Start Address, Offset, Length and file
     Blocks = 0x12000000 0x00000000 0x1860020 "vmlinuz-pad-ivt.itb"
----
+```
 
 At last we are able to sign the prepared FIT image:
----
+```
 $ cst -i vmlinuz-pad-ivt.csf -o vmlinuz-pad-ivt.bin
 CSF Processed successfully and signed data available in vmlinuz-pad-ivt.bin
----
+```
 
 ## Signing bootloader and kernel from the image build pipeline
 
@@ -599,7 +599,7 @@ with the same names as used in [CSF template](https://gitlab.apertis.org/infrast
 and remove them after the usage.
 
 For instance the simple secrets copying for Jenkins:
----
+```
 withCredentials([ file(credentialsId: csf_csf_key, variable:  'CSF_CSFKEY'),
   file(credentialsId: csf_img_key, variable:  'CSF_IMGKEY'),
   file(credentialsId: csf_key_pass, variable: 'CSF_PASSWD')]) {
@@ -611,7 +611,7 @@ withCredentials([ file(credentialsId: csf_csf_key, variable:  'CSF_CSFKEY'),
       cp -af $CSF_IMGKEY ./
       cp -af $CSF_PASSWD ./""")
 }
----
+```
 
 ### U-Boot signing
 
@@ -622,11 +622,11 @@ and call the `cst` tool to sign the U-Boot binary.
 
 The script is called by the [Debos recipe for the SabreLite U-Boot installer
 image](https://gitlab.apertis.org/infrastructure/apertis-image-recipes/-/blob/apertis/v2021dev1/mx6qsabrelite-uboot-installer.yaml):
----
+```
   - action: run
     description: Sign U-Boot
     script: scripts/sign-u-boot.sh "${ROOTDIR}/deb-binaries/usr/lib/u-boot/{{ $target }}/u-boot.imx"
----
+```
 
 ### FIT image creation and signing
 
@@ -641,11 +641,11 @@ The FIT image is more complex. So for Apertis we use 2 scripts:
 
 The integration with the build pipeline happens **after** the kernel is installed
 by the [OSTree commit recipe](https://gitlab.apertis.org/infrastructure/apertis-image-recipes/-/blob/apertis/v2021dev1/apertis-ostree-commit.yaml) by adding the step below:
----
+```
   - action: run
     description: Generate FIT image
     script: scripts/generate_fit_image.sh
----
+```
 
 **NB**: this action must be done prior to ostree commit action
 to add the signed FIT kernel into OSTree repository for OTA upgrades.
diff --git a/content/designs/security.md b/content/designs/security.md
index a3cfd019ba256406e7becda0300240b76849d7a1..30abc937709eab7da4681d644ad6ca348b918c4a 100644
--- a/content/designs/security.md
+++ b/content/designs/security.md
@@ -402,7 +402,7 @@ IPC mechanism. Android uses two very simple strategies to forcibly stop
 an application: 1) it kills applications when the device is out of
 memory; 2) it notifies the user of [unresponsive applications][Android-responsiveness] and allows
 them to force the application to close, similar to how GNOME does
----
+```
 
 An application is deemed to not be responding after about 5 seconds of
 not being able to handle user input. This feature is implemented by the
@@ -646,7 +646,7 @@ ping: icmp open socket: Operation not permitted
 # ping2 debian.org
 ping: icmp open socket: Operation not permitted
 #
----
+```
 
 > AppArmor restriction applying to file system links
 
@@ -903,7 +903,7 @@ policy file:
 
 ```shell
 $ cat /etc/apparmor.d/bin.ping
----
+```
 /bin/ping {
   #include <abstractions/base>
   #include <abstractions/consoles>
@@ -918,7 +918,7 @@ $ cat /etc/apparmor.d/bin.ping
   #include \<local/bin.ping\>
 }
 $
----
+```
 
 > AppArmor policy shipped for ping in Ubuntu
 
@@ -948,7 +948,7 @@ $ ls -l /etc/apparmor.d/disable/
 total 0
 lrwxrwxrwx 1 root root 24 Feb 20 19:38 bin.ping ->
 /etc/apparmor.d/bin.ping
----
+```
 
 > A symbolic link to disable the ping AppArmor policy
 
@@ -1114,7 +1114,7 @@ $ cat /etc/apparmor.d/usr.bin.dconf
   @{HOME}/.config/dconf/user r,
   /usr/bin/dconf mr,
 }
----
+```
 
 > Sample profiles for implementing white-listing
 
@@ -1125,13 +1125,13 @@ executed from this shell will be able to look at or interfere with
 dconf's files, and that dconf itself is able to function when used.
 Here's the result:
 
----
+```
 % cat .config/dconf/user
 cat: .config/dconf/user: Permission denied
 % dconf read /apps/empathy/ui/show-offline
 true
 %
----
+```
 
 > Effects of white-list approach profiles
 
diff --git a/content/designs/sensors-and-actuators.md b/content/designs/sensors-and-actuators.md
index c07108e8f499ddd168727aba5f0e6f90adb12aa0..506e30f0d6949995bc42ad9929e8986ec73bce28 100644
--- a/content/designs/sensors-and-actuators.md
+++ b/content/designs/sensors-and-actuators.md
@@ -1048,7 +1048,7 @@ interface to let client discover and get notified about the registered vehicles.
 Vehicles are mapped under `/org/apertis/Rhosydd1/${vehicle_id}` and implement
 the `org.apertis.Rhosydd1.Vehicle` interface:
 
----
+```
 interface org.apertis.Rhosydd1.Vehicle {
   readonly property s VehicleId;
   readonly property as Zones;
@@ -1086,7 +1086,7 @@ interface org.apertis.Rhosydd1.Vehicle {
     x current_time,
     a(ss(uu)) changed_attributes_metadata)
 }
----
+```
 
 Backends register themselves on the bus with well-known names under the
 `org.apertis.Rhosydd1.Backends.` prefix and implement the same interfaces and
@@ -1538,7 +1538,7 @@ vehicle.mirror.mirrorPan property (an actuator) would therefore have the
 following polkit rule generated in
 /etc/polkit-1/rules.d/20-org.example.AccelerateMyMirror.rules:
 
----
+```
 polkit.addRule (function (action, subject) {
   if (subject.credentials != 'org.example.AccelerateMyMirror') {
   /* This rule only applies to this bundle.
@@ -1567,8 +1567,8 @@ if (action.id == 'org.apertis.vehicle_device_daemon.WriteProperty' &&
   
 /* Deny all other accesses. */
 return polkit.Result.NO;
----
----
+```
+```
 
 In the rules, the subject is always the program in the bundle which is
 requesting access to the device.
@@ -2087,7 +2087,7 @@ Business Group Report 24 November 2014, and does not include the [Vehicle
 Data specification][w3-vehicle-data] for brevity. The API is described as
 [WebIDL], and partial interfaces have been merged.
 
----
+```
 partial interface Navigator {
   readonly attribute Vehicle *vehicle*;
 };
@@ -2168,7 +2168,7 @@ enum Availability {
   "not_supported_business_policy",
   "not_supported_other"
 };
----
+```
 
 [Rhosydd]: https://docs.apertis.org/rhosydd/index.html
 
diff --git a/content/designs/supported-api.md b/content/designs/supported-api.md
index 7aa8044f62ac9cf9235d0eaaf2f434adc17c2e92..0d1afbdc6f1bfe2dd554a638f6a26279369e09e7 100644
--- a/content/designs/supported-api.md
+++ b/content/designs/supported-api.md
@@ -187,7 +187,7 @@ the best way to guarantee stability, but that will only delay the impact
 of the changes. Building a set of APIs that abstract some of the
 platform can also be sensible: applications using high level widgets can
 be shielded from changes done at the lower levels – Clutter, Mx, and so
----
+```
 
 To conclude: taking advantage of open source code takes away some of the
 control over the platform's future. While Google and Apple are able to
@@ -453,7 +453,7 @@ but work may be done on a case-by-case basis to provide a smooth
 migration path, with old versions coexisting with newer ones when
 possible. Most existing open source APIs related to core functionality
 fall in this support level: Mx, clutter, clutter-gst, GStreamer, and so
----
+```
 
 As discussed in section 3.5.1, [][The GTK upgrade and a Clutter API break],
 there are ways to deal with ABI/API breakage in these libraries. Keeping
diff --git a/content/designs/system-updates-and-rollback.md b/content/designs/system-updates-and-rollback.md
index 01f71b239594c1d2b8a25ca4e5988468f1be6bd5..5d0282e043bd958affbd15ed5f900faafe79ab15 100644
--- a/content/designs/system-updates-and-rollback.md
+++ b/content/designs/system-updates-and-rollback.md
@@ -523,21 +523,21 @@ Ostree expect what secret key consists of 64 bytes (32b seed + 32b public) encod
 with base64 format. The ed25519 secret and public parts could be generated by 
 numerous utilities including `openssl`, for instance:
 
----
+```
 openssl genpkey -algorithm ed25519 -outform PEM -out ed25519.pem
----
+```
 
 Since ostree is not capable to use PEM format directly, it is needed to [extract the
 secret and public keys](http://openssl.6102.n7.nabble.com/ed25519-key-generation-td73907.html)
 from pem file, for example:
----
+```
 PUBLIC="$(openssl pkey -outform DER -pubout -in ${PEMFILE} | tail -c 32 | base64)"
 SEED="$(openssl pkey -outform DER -in ${PEMFILE} | tail -c 32 | base64)"
----
+```
 As mentioned above, the secret key is concatenation of SEED and PUBLIC parts:
----
+```
 SECRET="$(echo ${SEED}${PUBLIC} | base64 -d | base64 -w 0)"
----
+```
 
 On the client, ed25519 is also used to ensure that the commit comes from a trusted
 provider since updates could be acquired through different methods like OTA over
@@ -545,9 +545,9 @@ a network connection, offline updates on plug-in mass storage devices,
 or even mesh-based distribution mechanism.
 To enable the signature check, repository on the client must be configured by
 adding option `sign-verify=true` into the `core` or per-remote section, for instance:
----
+```
 ostree config set 'remote "origin".sign-verify' "true"
----
+```
 
 OSTree searches for files with valid public signatures in directories
 `/usr/share/ostree/trusted.ed25519.d` and `/etc/ostree/trusted.ed25519.d`.
@@ -571,10 +571,10 @@ authority.
 TLS can be configured in the `remote` configuration on the client using
 the following entries:
 
----
+```
 tls-ca-path
     Path to file containing trusted anchors instead of the system CA database.
----
+```
 
 Once a key is pinned, OSTree is ensured that any download is coming from a
 host which key is present in the image.
@@ -588,14 +588,14 @@ TLS also permit the OSTree client to authenticate itself to the server before
 being allowed to download a commit.
 This can also be configured in the `remote` configuration on the client using
 the following entries:
----
+```
 tls-client-cert-path
     Path to file for client-side certificate, to present when making requests to
     this repository.
 tls-client-key-path
     Path to file containing client-side certificate key, to present when making
     requests to this repository.
----
+```
 
 Access to remote repositories can also be controlled via HTTP cookies. The
 `ostree remote add-cookie` and `ostree remote delete-cookie` commands will
@@ -824,11 +824,11 @@ to maintain a whitelist and synchronize it with the bootloader.
 A command line tool is provided to query the status using
 [the `org.apertis.ApertisUpdateManager` D-Bus API](https://gitlab.apertis.org/appfw/apertis-update-manager/blob/master/data/apertis-update-manager-dbus.xml):
 
----
+```
 $ updatectl
 ** Message: Network connected: No
 ** Message: Upgrade status: Deploying
----
+```
 
 The current API exposes information about whether the updater is idle, an
 update is being checked, retrieved or deployed, or whether a reboot is pending
@@ -836,9 +836,9 @@ to switch to the updated system.
 
 It can also be used to mark the boot as successful:
 
----
+```
 $ updatectl --mark-update-successful
----
+```
 
 ### Update validation
 
diff --git a/content/designs/test-data-storage.md b/content/designs/test-data-storage.md
index 62f6e47de01a98e7bb6b552f2e97bec53ec2309f..8a3637fcbc091a7886b38973d5fcf84cc59bc396 100644
--- a/content/designs/test-data-storage.md
+++ b/content/designs/test-data-storage.md
@@ -409,7 +409,7 @@ file formats. Here are some examples of the different types of file formats:
 
 1) Tests file: it contains the test results in `PASS/FAIL` format.
 
----
+```
 {
   "test1": "pass",
   "test2": "pass",
@@ -418,24 +418,24 @@ file formats. Here are some examples of the different types of file formats:
   "testsuite2/subgroup1/testA": "pass",
   "testsuite2/subgroup2/testA": "pass",
 }
----
+```
 
 2) Metrics file: it contains the test results in metrics format.
 
----
+```
 {
   "test1": 1,
   "test2": 2.5,
   "metric1/test1": [1.2, 2.1, 3.03],
   "metric2/test2": [200, 109, 13],
 }
----
+```
 
 3) Metadata file: it contains metadata for the tests. It recognises some
 special values and also accept new fields to extend the test data with any
 relevant information.
 
----
+```
 {
   "build_url": "https://<url_build_origin>",
   "job_id": "902",
@@ -445,7 +445,7 @@ relevant information.
   "metadata2": "metadata_value2",
   ....
 }
----
+```
 
 4) Attachment files: these are any arbitrary files that can be submitted to
 SQUAD as part of the test results. Multiple attachments can be submitted to
@@ -510,9 +510,9 @@ SQUAD works around teams and projects to group the test data, so these are
 central concepts reflected in its HTTP API. For example, the API path contains
 the team and project names in the following form:
 
----
+```
 /api/submit/:team/:project/:build/:environment
----
+```
 
 Tools can make use of this API either using programming modules or invoking
 command line tools like `curl` to trigger the request.
@@ -522,13 +522,13 @@ test file `common-tests.json` for the image release 18.06 with version
 20180527.0 and including its metadata from the file `environment.json` would
 look like this:
 
----
+```
 $ curl \
     --header "Auth-Token: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
     --form tests=@common-tests.json \
     --form metadata=@environment.json \
     https://squad.apertis.org/api/submit/apertis/18.06/20180527.0/amd64
----
+```
 
 ### Fetching Test Results
 
@@ -540,17 +540,17 @@ through its HTTP API. For example, to fetch the tests results contained in the
 tests file (previously submitted), a GET request call to the test file path can
 be triggered like this:
 
----
+```
 $ curl https://squad.apertis.org/api/testruns/5399/tests_file/
----
+```
 
 This retrieves the test results contained in the tests file of the test run ID
 5399. In the same say, the metadata file for this test run can be fetched
 with a call to the metadata file path like this:
 
----
+```
 $ curl https://squad.apertis.org/api/testruns/5399/metadata_file/
----
+```
 
 The test run ID is generated by SQUAD to identify a specific test, and it can be
 obtained by triggering some query calls using the HTTP API.
@@ -597,7 +597,7 @@ as an indicator of format that will be used.
 An example of the automated test case file for the `librest` test. This test
 case file will be executed by LAVA automatically:
 
----
+```
 metadata:
   format: "Lava-Test-Shell Test Definition 1.0"
   name: librest
@@ -626,14 +626,14 @@ parse:
 
 expected:
   - "PASSED or FAILED"
----
+```
 
 An example of the manual test case file for the `webkit2gtk-aligned-scroll`
 test. This test case can be manually read and executed by the tester, but
 ideally a new application should be developed to read this file and guide the
 tester through each step of the test case:
 
----
+```
 metadata:
   format: "Manual Test Definition 1.0"
   name: webkit2gtk-aligned-scroll
@@ -676,14 +676,14 @@ example:
 notes:
   - "Both mouse and touchscreen need to PASS for this test case to be considered a PASS.
      If either does not pass, then the test case has failed."
----
+```
 
 ### Mandatory Data Fields
 
 A test case file should at least contain the following data fields for both the
 automated and manual tests:
 
----
+```
 format: This is used to identify the format version.
 name: Name of test case.
 type: This could be used to define a series of test case types (functional, sanity,
@@ -695,7 +695,7 @@ description: Brief description of the test case.
 priority: low, medium, high, critical.
 run: Steps to execute the test.
 expected: The expected result after running the test.
----
+```
 
 The test case file format is very extensible and new fields can be added as
 necessary.
diff --git a/content/designs/text-to-speech.md b/content/designs/text-to-speech.md
index ffa76d10f23c74ac3fcac916d5a22c2c918b4113..761ca93a4c96161470ae82304a534c99a96448ae 100644
--- a/content/designs/text-to-speech.md
+++ b/content/designs/text-to-speech.md
@@ -1033,7 +1033,7 @@ As discussed in the above sections, we recommend:
 
 The code listing is given in pseudo-code.
 
----
+```
 /* TTS context to contain relevant state and loaded resources and
  * settings. */
 class TtsContext {
@@ -1107,7 +1107,7 @@ enum TtsPitch
   NORMAL,
   HIGH,
 }
----
+```
 
 [Android-tts]: http://developer.android.com/reference/android/speech/tts/package-summary.html
 
diff --git a/content/designs/ui-customisation.md b/content/designs/ui-customisation.md
index dca39bd5f0b58f5651d3a2b053925dc77dfa9ce2..fd05d5a7492446028c7374561493878b30c8948d 100644
--- a/content/designs/ui-customisation.md
+++ b/content/designs/ui-customisation.md
@@ -634,7 +634,7 @@ ClutterScript is a method for creating user interfaces from JSON files.
 An example is shown below which describes variant A application chooser
 user interface:
 
----
+```
 [{
   "id": "model-categories",
   "type": "LightwoodAppCategoryModel"
@@ -665,9 +665,9 @@ user interface:
         { "name": "activated", "handler": "app_activated_cb" }
       ]
     }
----
+```
 }]
----
+```
 
 The first two objects created (`model-categories` and `model-apps`) are
 models for the application categories available on the system, and the
@@ -694,7 +694,7 @@ roller with applications is updated (set by the `app-list` property).
 Another example to compare is given below with the B-variant application
 chooser user interface:
 
----
+```
 [{
   "id": "model-apps",
   "type": "LightwoodAppModel"
@@ -712,9 +712,9 @@ chooser user interface:
         { "name": "activated", "handler": "app_activated_cb" }
       ]
     }
----
+```
 }]
----
+```
 
 The differences of the B-variant application chooser in comparison to
 the A-variant application chooser are:
@@ -767,7 +767,7 @@ implement):
 
 An `app-switcher.json` file contains the following objects defined:
 
----
+```
 [{
   "id": "view-header",
   "type": "LightwoodHeader",
@@ -787,7 +787,7 @@ An `app-switcher.json` file contains the following objects defined:
   "color": "#ff0000",
   "children": [ "view-header", … , "view-footer" ]
 }]
----
+```
 
 Header and footer objects are defined (`view-header` and `view-footer`) each
 with `height` properties (100 and 80 respectively). An `app-switcher` object
@@ -802,7 +802,7 @@ colour of the main app switcher, without copy & pasting a lot of text to
 redefine all these objects, objects can simply extend on previous
 definitions. For example, in a `my-app-switcher.json`:
 
----
+```
 [{
   "external-uri": "file:///path/to/app-switcher.json",
   "id": "view-header",
@@ -814,7 +814,7 @@ definitions. For example, in a `my-app-switcher.json`:
   "id": "app-switcher",
   "color": "#ffff00"
 }]
----
+```
 
 Referencing objects defined in other files can be achieved by specifying
 the `external-uri` property pointing to the other file, and the `id`
@@ -830,10 +830,10 @@ changes. Each external object must be referred to separately as they are
 not automatically brought into scope after the first `external-uri`
 reference. For example:
 
----
+```
 {
   "id": "example-with-children",
----
+```
   "children": [
     "first-child",
     {
@@ -844,9 +844,9 @@ reference. For example:
       "external-uri": "file:///path/to/another.json",
       "id": "third-child"
     }
----
+```
 }
----
+```
 
 In this example, this object has three children:
 
@@ -928,7 +928,7 @@ gint item_id)
     /* change animation */
   } else {
     /* reset animation */
----
+```
 
   /* chain up */
   return roller_class->activate (roller, item_id);
@@ -941,13 +941,13 @@ my_roller_class_init (MyRollerClass *klass)
 
   roller_class->activate = my_roller_activate;
 }
----
+```
 
 Another example is if the system integrator wants to change another part
 of the roller when scrolling starts, the appropriate signal can be
 connected to:
 
----
+```
 G_DEFINE_TYPE (MyRoller, my_roller, LIGHTWOOD_TYPE_ROLLER)
 
 static void
@@ -971,7 +971,7 @@ my_roller_class_init (MyRollerClass *klass)
   GObjectClass *object_class = G_OBJECT_CLASS (klass);
   object_class->constructed = my_roller_constructed;
 }
----
+```
 
 In the template, this variant would stop referring to `LightwoodRoller`
 and instead would use `MyRoller`, or update the widget factory entry (see
@@ -1206,7 +1206,7 @@ GtkBuilder is a method for creating user interfaces from XML files. An
 example is shown below which describes the A-variant application chooser
 user interface:
 
----
+```
 <interface>
   <object class="LightwoodAppCategoryModel" id="model_categories" />
   <object class="LightwoodAppModel" id="model_apps" />
@@ -1232,7 +1232,7 @@ user interface:
     </child>
   </object>
 </interface>
----
+```
 
 The first two objects created (`model_categories` and `model_apps`) are
 models for the application categories available on the system, and the
@@ -1259,7 +1259,7 @@ roller with applications is updated (set by the `app-list` property).
 Another example to compare is given below with the B-variant application
 chooser user interface:
 
----
+```
 <interface>
   <object class="LightwoodAppModel" id="model_apps" />
   <object class="LightwoodWindow" id="window">
@@ -1271,7 +1271,7 @@ chooser user interface:
     </child>
   </object>
 </interface>
----
+```
 
 The differences of the B-variant application chooser in comparison to
 the A-variant application chooser are: