Add glossary

.github/workflows/build.reusable.yaml

@@ -38,6 +38,9 @@ jobs:
       - name: Build plugins
         run: |
           yarn build:plugins
+      - name: Build theme
+        run: |
+          yarn build:theme
       # Submodules cached per environment to save time
       - name: Cache submodules
         uses: actions/cache@v3

.gitpod.yml

@@ -3,6 +3,7 @@ tasks:
     init: |
       corepack enable
       yarn
+      yarn build:theme && yarn build:plugins
       yarn build:all
     command: yarn serve
 github:

README.md

@@ -69,7 +69,7 @@ To preview the Wiki locally, use the following steps. For more preview and build
 
 1. Clone the repository by running `git clone https://github.com/iota-wiki/iota-wiki.git` and go to the directory with `cd iota-wiki`.
 2. Install dependencies with `yarn`.
-3. Build plugins once with `yarn build:plugins`
+3. Build the theme and all plugins once with `yarn build:theme && yarn build:plugins`
 4. Preview a specific environment with `yarn start:<environment>` where environment can be `iota`, `shimmer` or `next`.
 
 You should always prefer previewing only a specific environment of the Wiki, but if you need a complete Wiki build you can replace step 3 with `yarn start:all`.

common/docusaurus.config.js

@@ -68,6 +68,7 @@ module.exports = {
   themes: [
     'docusaurus-theme-openapi-docs',
     '@saucelabs/theme-github-codeblock',
+    '@iota-wiki/theme',
   ],
   staticDirectories: [path.resolve(__dirname, '../static')],
 };

iota/docs/zebra-iota-edge-sdk/tutorials/zebra-iota-edge-sdk/zebra-iota-edge-sdk-101-tutorial.md

@@ -59,7 +59,7 @@ There are several applications of decentralized identities in different domains:
 
 - **Decentralized Identity (DID) for Organizations**: The main application is the “DID for organizations in global trade” use case. For instance, a trader from Kenya creates its decentralized digital identity (DID) and receives a number of Credentials from Kenyan authorities after the requested verification processes. Some of these Credentials are also accepted by the EU authorities. Once starting to trade in Argentina, the same trader does not require new credentials as the existing ones are already matching those required by the Argentinian authorities, who can verify their authenticity in a decentralized way, without the need to integrate with any of the Kenya or EU Identity Issuers. You can watch this video which shows how we are applying it to the [TLIP Project](https://www.youtube.com/watch?v=bnAfclXTaeI) jointly developed by TradeMark East Africa and IOTA.
 
-- **Decentralized Device Identity**. Any device, such as a printer, scanner or RFID reader used in supply chains, may be issued a decentralized identity and associated credentials by the organization owning it. As a result all interactions made with that device can be recorded and audited, increasing the level of traceability, accountability, security and trust in the daily operations of an organization. For instance, a Zebra scanner in a warehouse can be assigned a decentralized identity, including certain verifiable credentials. When the device generates supply chain events, for instance scanning trade items (pallets, cases, etc.), a new record, signed with the keys bound to the identity of such a device, can be recorded and anchored to a distributed ledger such as IOTA. As a result, any associated business operation could be traceable all the way from an origin device to the corresponding business transaction. The Zebra-IOTA SDK already includes a reference application (_[DeviceID Application](zebra-iota-edge-sdk-104-tutorial.md)_) structured around a wizard that allows onboarding devices owned by an organization (see below).
+- **Decentralized Device Identity**. Any device, such as a printer, scanner or RFID reader used in supply chains, may be issued a decentralized identity and associated credentials by the organization owning it. As a result all interactions made with that device can be recorded and audited, increasing the level of traceability, accountability, security and trust in the daily operations of an organization. For instance, a Zebra scanner in a warehouse can be assigned a decentralized identity, including certain verifiable credentials. When the device generates supply chain events, for instance scanning trade items (pallets, cases, etc.), a new record, signed with the keys bound to the identity of such a device, can be recorded and anchored to a distributed ledger such as IOTA. As a result, any associated business operation could be traceable all the way from an origin device to the corresponding business transaction. The Zebra-IOTA SDK already includes a reference application ([DeviceID Application](zebra-iota-edge-sdk-104-tutorial.md)) structured around a wizard that allows onboarding devices owned by an organization (see below).
 
 - **Supply Chain Credentials**. Currently there are many supply chain processes that are actually conducted without the proper level of security or with no digitisation at all. We can imagine a truck driver arriving into a warehouse requesting to load / unload some pallets and showing just a document on paper with the transportation order. These kind of processes involve identity, trust and change of custody records between multiple parties each one holding their own decentralized identity: the warehouse manager, the truck driver, the logistics service provider, the supplier company and the customer company, for instance:
 

iota/docs/zebra-iota-edge-sdk/tutorials/zebra-iota-edge-sdk/zebra-iota-edge-sdk-102-tutorial.md

@@ -10,7 +10,7 @@ Before reading this tutorial we recommend that you read the [first part](../zebr
 
 All the scaffolding needed to create a solution for managing credentials on Android devices is packaged under the so-called _Holder Application_. This application also allows sharing credentials with interested parties by way of a scannable data matrix.
 
-The application guides the user to set up an Identity (a DID document) before associating Verifiable Credentials to this Identity. As this is just a reference application, the app self-signs the Verifiable Credentials, but ordinarily they would be signed by a third party such as a government in the case of personal details. An interested party can scan and verify the credential when presented in the form of a data matrix (see _[103 Tutorial](../zebra-iota-edge-sdk/zebra-iota-edge-sdk-103-tutorial.md)_).
+The application guides the user to set up an Identity (a DID document) before associating Verifiable Credentials to this Identity. As this is just a reference application, the app self-signs the Verifiable Credentials, but ordinarily they would be signed by a third party such as a government in the case of personal details. An interested party can scan and verify the credential when presented in the form of a data matrix (see [103 Tutorial](../zebra-iota-edge-sdk/zebra-iota-edge-sdk-103-tutorial.md)).
 
 Note: The _Holder Application_ also includes partial functionality as an issuer of credentials (see [104 Tutorial](../zebra-iota-edge-sdk/zebra-iota-edge-sdk-104-tutorial.md)).
 

iota/docusaurus.config.js

@@ -3,8 +3,10 @@ const contentConfigs = require('./contentPlugins');
 const { create_doc_plugin, globStatic } = require('../src/utils/config');
 
 module.exports = async () => {
-  const contentPlugins = (await contentConfigs()).map((contentConfig) =>
-    create_doc_plugin(contentConfig),
+  const contentPlugins = await Promise.all(
+    (
+      await contentConfigs()
+    ).map(async (contentConfig) => await create_doc_plugin(contentConfig)),
   );
 
   const staticDirs = await globStatic('/docs/**/static/', __dirname);