Update of main branch after release

.github/workflows/antora-worflow.yml

@@ -0,0 +1,53 @@
+name: Build
+on:
+  push:
+    branches: [ master, main, develop ]
+env:
+  SITE_DIR: 'site'
+jobs:
+  build_site:
+    name: "Build site with Antora"
+    runs-on: [ ubuntu-latest ]
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+      - name: "Install Node 16"
+        uses: actions/setup-node@v3
+        with:
+          node-version: 16
+      - name: "Install Antora"
+        run: make install-antora
+      - name: "Generate site using antora site action"
+        run: make build-site
+      - name: "Upload generated site"
+        uses: actions/upload-artifact@v4
+        with:
+          name: site
+          path: "${{ github.workspace }}/build/${{ env.SITE_DIR }}"
+
+  deploy_site:
+    runs-on: [ ubuntu-latest ]
+    needs: [ build_site ]
+    name: "Deploy GitHub Pages"
+    env:
+      ACTIONS_ALLOW_UNSECURE_COMMANDS: 'true'
+    steps:
+      - name: "Install Node 16"
+        uses: actions/setup-node@v3
+        with:
+          node-version: 16
+      - name: Checkout
+        uses: actions/checkout@v4
+      - name: Download generated site
+        uses: actions/download-artifact@v4
+        with:
+          name: site
+          path: "${{ github.workspace }}/${{ env.SITE_DIR }}"
+      - name: Deploy to GitHub Pages
+        uses: JamesIves/github-pages-deploy-action@v4.4.0
+        with:
+          # ACCESS_TOKEN: # optional
+          GITHUB_TOKEN: "${{ github.token}}"
+          FOLDER: "${{ env.SITE_DIR }}"
+          BRANCH: 'gh-pages'
+          COMMIT_MESSAGE: "[CI] Publish Documentation for ${{ github.sha }}"

.gitignore

@@ -0,0 +1,165 @@
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[cod]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+pip-wheel-metadata/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# PyInstaller
+#  Usually these files are written by a python script from a template
+#  before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py,cover
+.hypothesis/
+.pytest_cache/
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+db.sqlite3
+db.sqlite3-journal
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+.python-version
+
+# pipenv
+#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
+#   However, in case of collaboration, if having platform-specific dependencies or dependencies
+#   having no cross-platform support, pipenv may install dependencies that don't work, or not
+#   install all needed dependencies.
+#Pipfile.lock
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+# Pyre type checker
+.pyre/
+
+# IDEs
+.idea
+.vscode/
+
+# misc
+.DS_Store
+.~*
+*.xpr
+extensions.json
+
+# project-specific
+.saxon/
+.rmlmapper/
+/mappings/*/data/
+
+jena/
+jena.zip
+dist/
+tmp/
+owlcli
+owl-cli.jar
+owl-cli-snapshot.jar
+mappings-1*
+ref/
+
+analysis_scripts/
+*.mk
+requirements.txt
+test_queries/
+test_scripts/
+src/scripts
+src/README.md
+covered_xpaths.txt
+uncovered_xpaths.txt
+xpaths_to_cover.txt

CODE_OF_CONDUCT.md

@@ -0,0 +1,51 @@
+# Code of Conduct 
+
+## Introduction
+
+This code of conduct applies to all spaces the TED unit of the Publications Office (OP) manages, including IRC, public and private mailing lists, issue trackers, wikis, blogs, Twitter, LinkedIn, and any other communication channels our communities use.
+
+We expect everyone who participates in the community formally or informally, or claims any affiliation with the OP, in any OP-related activities and especially when representing the OP in any role to honor this code of conduct.
+
+This code is not exhaustive or complete. It distills our common understanding of a collaborative, shared environment and goals. We expect all members of the community to follow it in spirit as much as in the letter, so that it can enrich all of us, and the technical communities in which we participate.
+
+## Specific guidelines
+
+We strive to:
+
+**Be open.** We invite anyone to participate in our community. We prefer to use public methods of communication for project-related messages, unless discussing something sensitive. This applies to messages for help or project-related support, too; not only is a public support request much more likely to result in an answer to a question, it also makes sure that any the community notices and corrects any inadvertent mistakes people answering the query may make.
+
+**Be empathetic**, welcoming, friendly, and patient. We work together to resolve conflicts, assume good intentions, and do our best to act in an empathetic fashion. We may all experience some frustration from time to time, but we do not allow frustration to result in a personal attack. A community where people feel uncomfortable or threatened is not a productive one. We should be respectful when dealing with other community members as well as with people outside our community.
+
+**Be collaborative.** Other people will use our work, and we in turn depend on the work of others. When we make something for the benefit of the project, we are willing to explain to others how it works, so they can build on the work to make it even better. Any decision we make will affect users and colleagues, and we take those consequences seriously when making decisions.
+
+**Be inquisitive.** Nobody knows everything! Asking questions early avoids many problems later, so we encourage questions, although we may redirect them to the appropriate forum. Those who receive a question should be responsive and helpful, within the context of our shared goal of improving OP projects and initiatives.
+
+**Be careful in the words that we choose.** Whether we are participating as professionals or volunteers, we value professionalism in all interactions, and take responsibility for our own speech. Be kind to others. Do not insult or put down other participants. Harassment and other exclusionary behaviour are not acceptable. This includes, but is not limited to:
+
+* Violent threats or language directed against another person.
+* Sexist, racist, or otherwise discriminatory jokes and language.
+* Posting sexually explicit or violent material.
+* Posting (or threatening to post) other people's personally identifying information ("doxing").
+* Sharing private content, such as emails sent privately or non-publicly, or from unlogged forums such as IRC channel history.
+* Personal insults, especially those using racist or sexist terms.
+* Unwelcome sexual attention.
+* Excessive or unnecessary profanity.
+* Repeated harassment of others. In general, if someone asks you to stop, then stop.
+* Advocating for, or encouraging, any of the above behaviour.
+
+**Be concise.** Keep in mind that, over time, hundreds or thousands of people will read what you write. Writing a short email means people can understand the conversation as efficiently as possible. Short emails should always strive to be empathetic, welcoming, friendly and patient. When a long explanation is necessary, consider adding a summary at the top of the message.
+
+Try to bring new ideas to a conversation so that each email adds something unique to the thread, keeping in mind that the rest of the thread still contains the other messages with arguments that have already been made.
+
+Try to stay on topic, especially in discussions that are already fairly long.
+
+**Step down considerately.** Members of every project come and go. When somebody leaves or disengages from the project they should tell people they are leaving and take the proper steps to ensure that others can pick up where they left off. In doing so, they should remain respectful of those who continue to participate in the project and should not misrepresent the project's goals or achievements. Likewise, community members should respect any individual's choice to leave the project.
+
+
+## Notes
+This Code defines **empathy** as "_a vicarious participation in the emotions, ideas, or opinions of others; the ability to imagine oneself in the condition or predicament of another._" **Empathetic** is the adjectival form of empathy.
+
+This statement draws on the following for content and inspiration:
+
+* [Apache Foundation Code of Counduct](https://www.apache.org/foundation/policies/conduct.html)
+* [Django Code of Conduct](https://www.djangoproject.com/conduct/)

CONTRIBUTING.md

@@ -0,0 +1,41 @@
+# Contributing Guidelines
+
+As a newcomer on a project, it's easy to experience frustration. Here's some advice to make your work on this project more useful and rewarding.
+
+**Pick a subject area that you care about, that you are familiar with, or that you want to learn about**
+
+You don't already have to be an expert on the area you want to work on; you become an expert through your ongoing contributions to the code.
+
+**Analyze tickets' context and history**
+
+Trac isn't an absolute; the context is just as important as the words. When reading Trac, you need to take into account who says things, and when they were said. Support for an idea two years ago doesn't necessarily mean that the idea will still have support. You also need to pay attention to who hasn't spoken – for example, if an experienced contributor hasn't been recently involved in a discussion, then a ticket may not have the support required to get into this project.
+
+**Start small**
+
+It's easier to get feedback on a little issue than on a big one. See the easy pickings.
+
+**If you're going to engage in a big task, make sure that your idea has support first**
+
+This means getting someone else to confirm that a bug is real before you fix the issue, and ensuring that there's consensus on a proposed feature before you go implementing it.
+
+**Be bold! Leave feedback!**
+
+Sometimes it can be scary to put your opinion out to the world and say “this ticket is correct” or “this patch needs work”, but it's the only way the project moves forward. The contributions of the broad community ultimately have a much greater impact than that of any one person. We can't do it without you!
+
+**Err on the side of caution when marking things Ready For Check-in**
+
+If you're really not certain if a ticket is ready, don't mark it as such. Leave a comment instead, letting others know your thoughts. If you're mostly certain, but not completely certain, you might also try asking on IRC to see if someone else can confirm your suspicions.
+
+**Wait for feedback, and respond to feedback that you receive**
+
+Focus on one or two tickets, see them through from start to finish, and repeat. The shotgun approach of taking on lots of tickets and letting some fall by the wayside ends up doing more harm than good.
+
+**Be patient**
+
+It's not always easy for your ticket or your patch to be reviewed quickly. This isn't personal. There may be a lot of tickets and pull requests to get through.
+
+## Notes
+This statement draws on the following for content and inspiration:
+
+* [Django Contributing Guidelines](https://docs.djangoproject.com/en/dev/internals/contributing/new-contributors/#guidelines)
+