diff --git a/content/de/boox-note-scientific-workflow.md b/content/de/boox-note-scientific-workflow.md
new file mode 100644
index 0000000..9123672
--- /dev/null
+++ b/content/de/boox-note-scientific-workflow.md
@@ -0,0 +1,93 @@
+Title: Wissenschaftlicher Workflow mit dem BOOX Note Air 3 C
+Slug: boox-note-scientific-workflow
+Category: work
+Tags: wissenschaftlicher workflow, kollaboration, literaturverwaltung
+Date: 2024-01-26
+Lang: de
+Status: published
+
+Vor Kurzem habe ich mir einen [ONYX BOOX Note Air 3 C](https://onyxboox.com/boox_noteair3c) zugelegt, um meinen wissenschaftlichen Workflow zu unterstützen. Ende letzten Jahres wurde mir klar, warum ich in meiner wissenschaftlichen Laufbahn nicht so recht vorankam. Ehrlich gesagt war mir ein Hauptgrund durchaus bewusst: mir fehlte die Selbstdisziplin, die für meine Forschung nötigen Quellen zu lesen. Den eigentlichen Grund dafür kannte ich aber erst seit letztem Jahr. Es stellte sich heraus, dass die meisten Quellen in digitaler Form vorlagen und ich mich einfach nicht dazu durchringen konnte, sie am Computerbildschirm zu lesen. Ein Tablet oder Smartphone waren ebenfalls keine echte Alternative, da mich die Displays einfach zu schnell ermüden.
+
+Ein E-Book-Reader war eine mögliche Lösung. Ein Kollege arbeitet schon seit einiger Zeit mit einem Remarkable 2, was ich ebenfalls sehr interessant fand. Das Leseerlebnis mit diesem Gerät war allerdings nicht gut. Nach einiger Recherche habe ich mich für einen Boox Note Air 3 C entschieden, der mir sowohl bei der Lese- als auch bei der Notizfunktion am vielversprechendsten erschien. Dennoch war ich mir nicht sicher, ob ich mit dem Gerät einen sinnvollen Workflow für wissenschaftliches Arbeiten in meinem Arbeitsalltag etablieren könnte.
+
+Nach ein paar Wochen Nutzung kann ich sagen: Der Note Air 3 C erfüllt meine Erwartungen voll und ganz. Meine Hauptanwendungsfälle bisher waren das Lesen von Lehrbüchern inklusive direkter Annotation im PDF sowie allgemeine Notizen. In den ersten Tagen habe ich natürlich versucht, mich mit den Bordmitteln des Geräts vertraut zu machen. Ich habe probiert, mit Hilfe der BOOX-Cloud und der BOOXDrop-Funktion einen brauchbaren Workflow aufzubauen. Das erwies sich jedoch als ziemlich unübersichtlich – vor allem, weil mein primäres Betriebssystem Linux ist und die Synchronisationstools nur für Windows und macOS verfügbar sind. Ich musste daher jeden Synchronisationsvorgang über den Webbrowser abwickeln.
+
+Und obwohl es Tools wie Marcin Juszkiewiczs [onyx-send2boox](https://github.com/hrw/onyx-send2boox) gibt, wollte ich von vornherein nicht alle meine Daten durch die Cloud des Herstellers schicken. Cloud und Backup dorthin habe ich zwar noch aktiviert, mein täglicher Workflow nutzt sie aber nicht mehr.
+
+Stattdessen habe ich mittlerweile einen Workflow etabliert, der größtenteils auf selbstgehosteten Diensten und Open-Source-Anwendungen beruht.
+
+# Websurfen
+
+Ich nutze seit jeher Firefox als Webbrowser auf all meinen Rechnern, und auch auf meinem Android-Smartphone war Firefox stets der Standardbrowser. Vor Kurzem bin ich auf ein iPhone umgestiegen, aber auch dafür gibt es ein mobiles Firefox für iOS (leider ohne Add-on-Unterstützung).
+
+Es lag also nahe, Firefox auch auf dem Note Air 3 C zu installieren – vor allem, um Add-ons nutzen zu können, allen voran uBlock Origin, um unnötige und im schlimmsten Fall animierte Werbung (die bei einem E-Ink-Gerät besonders auf den Akku geht) zu blockieren. Da ich Firefox auf allen Geräten einsetze, kann ich [Tabs beliebig zwischen den Geräten verschieben](https://support.mozilla.org/de/kb/tabs-von-anderen-geraten-senden), solange die Installation mit meinem Mozilla-Konto verknüpft ist. Natürlich nutze ich auch hier einen Cloud-Dienst, aber die seit Jahren ausgereifte Mozilla-Cloud erscheint mir deutlich vertrauenswürdiger als die eines chinesischen Hardwareherstellers. Und der zusätzliche Komfort, nicht nur Tabs, sondern auch Lesezeichen und Verlauf zu synchronisieren, ist einfach zu praktisch, um darauf zu verzichten.
+
+# Lesezeichen (Read-it-later)
+
+Lesezeichen im klassischen Sinne, also die Bookmarks im Webbrowser, habe ich immer nur für häufig besuchte Websites genutzt. Kurzfristige Merkzettel habe ich nie über Browser-Lesezeichen verwaltet – dafür waren für mich schon immer Read-it-later-Apps und -Dienste zuständig.
+
+Auch wenn mit Pocket seit einiger Zeit ein Read-it-later-Dienst in Firefox integriert ist, habe ich diesen nie genutzt. Stattdessen betreibe ich schon länger eine eigene [Wallabag](https://www.wallabag.it/)-Instanz. Dazu gibt es nicht viel zu sagen – es funktioniert einfach.
+
+Die [Wallabag-App](https://play.google.com/store/apps/details?id=fr.gaulupeau.apps.InThePoche) läuft auf dem Note Air 3 C reibungslos und erlaubt mir, jederzeit auf meine Read-it-later-Lesezeichen auf diesem Gerät zuzugreifen. Einträge werden über die Android-Freigabefunktion hinzugefügt, sodass sich Lesezeichen auch direkt aus dem Webbrowser heraus anlegen lassen.
+
+
+*wallabag app auf dem BOOX Note Air 3 C*
+
+# Literaturverwaltung
+
+Da ich sowohl persönlich als auch in unserer Arbeitsgruppe eine gemeinsame Bibliothek über Zotero betreibe, lag es nahe, dieses auch auf dem Note Air 3 C einzusetzen. Im Play Store gibt es leider keine auf dem Gerät funktionierende Zotero-App – zumindest nicht die ganze Geschichte.
+
+Zum einen gibt es inzwischen eine offizielle [Zotero-App](https://play.google.com/store/apps/details?id=org.zotero.android) im Beta-Stadium, die auf dem Gerät funktioniert, zum anderen läuft auch die aktuell deutlich bessere App [Zoo for Zotero](https://play.google.com/store/apps/details?id=com.mickstarify.zooforzotero). Mit der Einschränkung, dass Letztere nicht über den Play Store installiert werden kann. Eine direkte Installation per APK (die man aus einschlägigen Quellen beziehen kann) funktioniert bei mir aber bislang problemlos. Zu bedenken ist außerdem, dass das letzte Update der App aus August 2021 stammt – das Fehlen automatischer Updates über den Play Store ist also ein eher geringes Risiko. Trotzdem sollte man die Entwicklung bei direkten APK-Installationen im Auge behalten und bei Bedarf manuell aktualisieren.
+
+
+*Zoo for Zotero App auf dem BOOX Note Air 3 C*
+
+Die Zotero-Bibliotheken (sowohl meine persönliche als auch die Gruppenbibliothek) enthalten nicht nur wissenschaftliche Publikationen zur jeweiligen Forschung, sondern auch sonstige Fachliteratur wie Lehrbücher sowie Links zu relevanten Websites und Blogbeiträgen.
+
+Damit ist Zotero für mich mittlerweile die Standardmethode zur Synchronisation von E-Books geworden. Ich lege für ein neues E-Book einfach einen Eintrag in Zotero anhand der ISBN an und hänge die Datei an den Eintrag an. Auf dem Note Air 3 C kann ich das E-Book (oder auch jedes wissenschaftliche Paper) direkt über die Zoo for Zotero App synchronisieren. PDFs und auch EPUBs werden direkt in der BOOX-Neo-Reader-App geöffnet, sodass Annotationen von Haus aus möglich sind.
+
+Der einzige Nachteil: Die annotierten Dateien werden natürlich nicht direkt zurück nach Zotero synchronisiert. Bei der Gruppenbibliothek ist das andererseits vielleicht auch gar nicht so schlecht – schließlich möchten nicht alle Kolleg:innen meine Annotationen in ihrer Bibliothek haben.
+
+# Zwischenablage teilen
+
+Gelegentlich brauche ich auch eine schnelle Möglichkeit, die Zwischenablage vom Rechner auf den Note Air 3 C zu übertragen oder umgekehrt. Da ich, wie oben erwähnt, auf allen Rechnern Linux-Desktopsysteme einsetze, ist [KDE Connect](https://apps.kde.org/de/kdeconnect/) meiner Meinung nach die beste Option. Es bietet nicht nur das Teilen der Zwischenablage, sondern auch Funktionen wie das Teilen von Benachrichtigungen oder Remote-Eingaben.
+
+Auch wenn es KDE Connect heißt, ist es dank der [GSConnect-Erweiterung](https://extensions.gnome.org/extension/1319/gsconnect/) ebenso mit GNOME-Desktops kompatibel.
+
+# KI-Unterstützung
+
+Auch wenn es auf dem E-Ink-Display wegen der stark animierten Live-Ausgabe nicht besonders gut aussieht, lässt sich die [offizielle ChatGPT-App](https://play.google.com/store/apps/details?id=com.openai.chatgpt) nutzen. Ich greife allerdings nur darauf zurück, wenn ich wirklich kein anderes Gerät zur Hand habe – was praktisch nie vorkommt, da ich immer mindestens ein Smartphone in der Nähe habe. Und trotz des kleineren Displays ist die Usability dort deutlich besser.
+
+
+*ChatGPT App auf dem BOOX Note Air 3 C*
+
+# Kollaboration
+
+Da wir in unserer Arbeitsgruppe Jira und Confluence als Kollaborationstools einsetzen, nutze ich auch hier die offiziellen Apps für [Jira Data Center](https://play.google.com/store/apps/details?id=com.atlassian.jira.server) und [Confluence Data Center](https://play.google.com/store/apps/details?id=com.atlassian.confluence.server). Auch hier gilt: Ich nutze die Apps nur, wenn kein anderes Gerät zur Hand ist. Ich kann daher lediglich sagen, dass sie funktionieren und einfach zu bedienen sind, eine tiefergehende Nutzungsanalyse habe ich aber nicht durchgeführt.
+
+# E-Mail
+
+Wie in den vorangegangenen Absätzen vielleicht schon deutlich wurde, nutze ich den Note Air 3 C nicht wirklich als Tablet im klassischen Sinne. Trotzdem muss ich gelegentlich eine E-Mail auf dem Tablet öffnen. Ich denke, dass grundsätzlich jeder Standard-Mail-Client auf dem Gerät funktionieren sollte, der Vollständigkeit halber sei aber erwähnt, dass Marcel Bokhorsts großartiger Open-Source-Mail-Client [FairEmail](https://play.google.com/store/apps/details?id=eu.faircode.email) auf dem Gerät hervorragend läuft.
+
+# Kalender (und Kontakte)
+
+Kalenderzugriff (und -synchronisation) ist eine weitere Funktion, die ich nicht ständig brauche. Aber es ist hin und wieder nützlich, meinen Kalender auch auf dem Note Air 3 C einsehen zu können. Da ich meinen Kalender (auch auf anderen Geräten) über CalDAV synchronisiere (und meine Kontakte über CardDAV), nutze ich dafür einfach [DAVx⁵](https://play.google.com/store/apps/details?id=at.bitfire.davdroid) auf dem Gerät.
+
+Da das Gerät standardmäßig keine Kalender- oder Kontakte-App mitbringt, müssen diese nachträglich installiert werden. Ich bin seit Jahren großer Fan der Apps [Simple Calendar](https://play.google.com/store/apps/details?id=com.simplemobiletools.calendar) und [Simple Contacts](https://play.google.com/store/apps/details?id=com.simplemobiletools.contacts). Der Vollständigkeit halber sei erwähnt, dass ich immer die Pro-Versionen nutze – es kann also sein, dass der kostenlosen Version Funktionen fehlen oder sie andere Nachteile hat.
+
+# Onleihe
+
+Auch die Onleihe-App habe ich auf dem BOOX Note Air 3 C ausprobiert. Auf dem E-Ink-Display wirkt sie durch die vielen Farbelemente recht unruhig; selbst mit dem dunklen Farbschema bleiben etwa die grünen Flächen (siehe Screenshot) uneinheitlich, da das dabei verwendete Schwarz keine gleichmäßige Fläche ergibt. Zum gemütlichen Stöbern lädt das nicht gerade ein, für die schnelle Ausleihe eines E-Books oder E-Magazins reicht es aber allemal.
+
+
+*Onleihe auf dem BOOX Note Air 3 C*
+
+Auch das Lesen digitaler Tageszeitungen über die Onleihe-App funktioniert recht gut, wobei man wegen der Spaltenzahl entsprechend stark zoomen muss.
+
+
+*Zeitungslektüre über die Onleihe App auf dem BOOX Note Air 3 C*
+
+# Alternativer App-Store
+
+[F-Droid](https://f-droid.org) lässt sich auf dem Note Air 3 C installieren – nicht nur als Alternative zum Play Store, sondern auch um Open-Source-Apps installieren zu können, die möglicherweise nicht für das Gerät im Play Store freigegeben sind. Das ermöglicht zudem die Installation kostenloser Builds mancher Apps, die den vollen Funktionsumfang bieten, der sonst nur per Pro-Upgrade verfügbar wäre.
+
diff --git a/content/de/howto-fhir-date-parameter.md b/content/de/howto-fhir-date-parameter.md
new file mode 100644
index 0000000..29d0b78
--- /dev/null
+++ b/content/de/howto-fhir-date-parameter.md
@@ -0,0 +1,302 @@
+Title: HowTo: Der FHIR `date`-Suchparameter – Präfixe, Intervalle und Kombinationen richtig verstehen
+Slug: howto-fhir-date-parameter
+Category: work
+Tags: FHIR, howto
+Date: 2026-08-12
+Lang: de
+Status: published
+
+Wer FHIR-Server baut oder abfragt, stolpert früher oder später über den
+`date`-Suchparameter. Auf den ersten Blick sieht er simpel aus:
+`?date=2023-06-15`. Aber sobald Präfixe wie `ge`, `sa` oder `ap` ins Spiel
+kommen und mehrere `date`-Parameter kombiniert werden, wird es schnell
+unübersichtlich. Dieser Artikel bringt Ordnung rein: Schritt für Schritt, mit
+Zeitleisten-Grafiken zu jedem Fall, und als Kurzreferenz zum schnellen
+Nachschlagen.
+
+## Inhaltsverzeichnis
+
+[TOC]
+
+---
+
+## Kurzreferenz: Alle Präfixe auf einen Blick
+
+Für den schnellen Blick zwischendurch. Details und Grafiken zu jeder Zeile
+folgen in den Abschnitten unten.
+
+| Präfix | Name | Kurzregel | Beispiel |
+|---|---|---|---|
+| *(keins)* | implizit `eq` | Precision des Werts bestimmt das Intervall | `date=2023-06-15` |
+| `eq` | gleich | Resource-Intervall vollständig im Such-Intervall | `date=eq2023-06-15` |
+| `ne` | ungleich | Komplement von `eq` | `date=ne2023-06-15` |
+| `gt` | größer als | Ragt über das Ende hinaus (Overlap genügt) | `date=gt2023-06-15` |
+| `lt` | kleiner als | Beginnt vor dem Anfang (Overlap genügt) | `date=lt2023-06-15` |
+| `ge` | größer/gleich | `gt` oder vollständig enthalten (`eq`) | `date=ge2023-06-15` |
+| `le` | kleiner/gleich | `lt` oder vollständig enthalten (`eq`) | `date=le2023-06-15` |
+| `sa` | starts after | Vollständig danach, **keine** Überlappung | `date=sa2023-06-15` |
+| `eb` | ends before | Vollständig davor, **keine** Überlappung | `date=eb2023-06-15` |
+| `ap` | approximately | Überlappung + ähnliche Größenordnung | `date=ap2023-06-15` |
+
+**Fehlender `start`/`end` bei `Period`:** fehlender `start` bedeutet `-∞`,
+fehlendes `end` bedeutet `+∞`. Deshalb kann `sa` bei fehlendem `start` nie
+matchen, und `eb` kann bei fehlendem `end` nie matchen (Details in
+[Abschnitt 4](#4-offene-unvollständige-periods)).
+
+---
+
+## Das Grundprinzip: FHIR vergleicht Intervalle, keine Zeitpunkte
+
+Der wichtigste gedankliche Reset zuerst: FHIR behandelt Datumswerte nie als
+exakten Zeitpunkt, sondern immer als **Intervall**. Wie breit dieses Intervall
+ist, hängt von der Precision des angegebenen Werts ab:
+
+- `2023` → das ganze Jahr 2023
+- `2023-06` → der ganze Juni 2023
+- `2023-06-15` → der ganze 15. Juni 2023 (00:00–24:00 Uhr)
+- `2023-06-15T10:00:00` → (fast) ein exakter Zeitpunkt
+
+Jeder Vergleichsoperator vergleicht anschließend **zwei Intervalle**
+miteinander: das Such-Intervall aus deinem Query-Parameter und das
+Resource-Intervall aus dem Feld der Ressource (z. B. `Patient.birthDate` oder
+`Encounter.period`).
+
+### Ohne Präfix = `eq`, aber die Precision entscheidet mit
+
+Gibst du kein Präfix an, nimmt der Server `eq` an. Das Resource-Datum muss
+dann **vollständig** innerhalb deines Such-Intervalls liegen. Je gröber die
+Precision, desto breiter das Intervall, und desto mehr Resource-Werte passen
+hinein:
+
+
+*FHIR date-Suchparameter OHNE Präfix*
+
+`date=2023-06-15` matched nur diesen einen Tag. `date=2023-06` matched dagegen
+jeden Tag im Juni, auch den 15. Das ist der häufigste Stolperstein für
+Einsteiger: eine „ungenaue" Suchanfrage ist nicht strenger, sondern lockerer.
+
+---
+
+## Die neun Präfixe im Überblick
+
+FHIR definiert insgesamt neun Präfixe für `date`. Jeder davon beschreibt eine
+andere Beziehung zwischen Such-Intervall (rot gestrichelt in der Grafik) und
+Treffer-Bereich (grün/farbig schattiert):
+
+
+*Alle Präfixe im Überblick*
+
+| Präfix | Name | Bedeutung |
+|---|---|---|
+| `eq` | gleich | Resource-Intervall liegt vollständig im Such-Intervall |
+| `ne` | ungleich | Komplement von `eq` |
+| `gt` | größer als | Resource-Intervall **ragt über** das Ende des Such-Intervalls hinaus |
+| `lt` | kleiner als | Resource-Intervall **beginnt vor** dem Anfang des Such-Intervalls |
+| `ge` | größer/gleich | `gt` **oder** vollständig im Such-Intervall enthalten (`eq`) |
+| `le` | kleiner/gleich | `lt` **oder** vollständig im Such-Intervall enthalten (`eq`) |
+| `sa` | starts after | Beginnt vollständig **nach** dem Ende des Such-Intervalls, keine Überlappung |
+| `eb` | ends before | Endet vollständig **vor** dem Beginn des Such-Intervalls, keine Überlappung |
+| `ap` | approximately | Überlappung, plus ähnliche Größenordnung der Intervalle |
+
+**Wichtig, Containment vs. Overlap:** Nur `eq` (und implizit `sa`/`eb`)
+verlangen, dass das Resource-Intervall **vollständig** innerhalb bzw.
+**vollständig getrennt** vom Such-Intervall liegt. Bei `gt`, `lt`, `ge`
+und `le` reicht dagegen eine **Überlappung**: das Resource-Intervall muss
+nicht komplett außerhalb des Suchbereichs liegen, es genügt, dass es über
+die jeweilige Grenze hinausragt. Details dazu im nächsten Abschnitt.
+
+---
+
+## Matching gegen `Period` und `Range`
+
+Die Grafiken oben zeigen das Resource-Datum als schmalen roten Marker. Das
+passt für einfache `date`/`dateTime`-Felder wie `Patient.birthDate`. Sobald
+das Zielfeld selbst ein **Intervall** ist (`Period`, z. B.
+`Encounter.period`, `Condition.onsetPeriod`, oder `Range`), wird die
+Unterscheidung zwischen **Containment** (vollständiges Enthaltensein) und
+**Overlap** (bloße Überlappung) entscheidend:
+
+- **`eq`** verlangt Containment: das gesamte Resource-Intervall muss im
+ Such-Intervall liegen.
+- **`gt` / `lt` / `ge` / `le`** verlangen nur Overlap: es reicht, wenn das
+ Resource-Intervall über die jeweilige Grenze hinausragt, auch wenn ein
+ Teil davon auf der "falschen" Seite liegt.
+- **`sa` / `eb`** verlangen das Gegenteil von Overlap: das Resource-Intervall
+ muss vollständig und ohne jede Überlappung auf der jeweiligen Seite liegen.
+
+Bei einem einfachen Zeitpunkt-Feld (kein `Period`) fällt dieser Unterschied
+praktisch nicht auf, da Resource-Start und -Ende (fast) identisch sind. Dort
+verhalten sich `gt` und `sa` de facto gleich. Der Unterschied wird erst bei
+echten Zeitspannen relevant. Das ist auch der Grund, warum `sa`/`eb`
+laut Spezifikation in erster Linie für `Period`/`Range`-Werte gedacht sind.
+
+**Beispiel:** Ein Encounter läuft vom 10. bis 20. Juni. Die Suche
+`date=gt2023-06-15` soll ihn finden, obwohl der Encounter *vor* dem 15.
+begonnen hat. Entscheidend ist nur, dass er über den 15. hinausreicht
+(Overlap mit dem Bereich "nach dem 15."). Bei `date=sa2023-06-15` würde
+derselbe Encounter dagegen **nicht** matchen, weil er nicht vollständig nach
+dem 15. liegt. Genau das ist der praktische Unterschied zwischen `gt` und
+`sa`.
+
+Die folgende Grafik macht das für alle vier "einseitigen" Präfixe (`gt`,
+`sa`, `lt`, `eb`) an denselben drei Beispiel-Periods sichtbar: einer
+Period komplett davor, einer, die die Suchgrenze überlappt, und einer
+komplett danach:
+
+
+*Matching gegen Period/Range (Containment vs. Overlap)*
+
+Man sieht deutlich: `gt` und `lt` (blau schattierter Bereich, durchgezogene
+Grenzlinie) lassen die überlappende Period B als Treffer durch, während `sa`
+und `eb` (gestrichelte Grenzlinie) sie ablehnen. Nur eine Period, die
+komplett auf der richtigen Seite liegt, zählt dort.
+
+| Encounter-Zeitraum | `date=gt2023-06-15` | `date=sa2023-06-15` |
+|---|---|---|
+| 10.–20. Juni (überlappt die Grenze) | ✅ Treffer (Overlap) | ❌ kein Treffer (nicht vollständig danach) |
+| 16.–20. Juni (komplett danach) | ✅ Treffer | ✅ Treffer |
+| 01.–10. Juni (komplett davor) | ❌ kein Treffer | ❌ kein Treffer |
+
+---
+
+## Offene (unvollständige) Periods
+
+In der Praxis sind Periods oft **nicht abgeschlossen**, zum Beispiel ein
+laufender Encounter ohne `end`, oder ein importierter Datensatz mit
+unbekanntem `start`. Der FHIR-Standard regelt das eindeutig:
+
+> Ein fehlender unterer Rand (`start`) gilt implizit als **kleiner als jedes
+> reale Datum** (also `-∞`). Ein fehlender oberer Rand (`end`) gilt implizit
+> als **größer als jedes reale Datum** (also `+∞`).
+
+Das hat spürbare Konsequenzen, gerade für `sa` und `eb`:
+
+- Ein laufender Encounter (`start` gesetzt, `end` fehlt, also `end = +∞`)
+ kann **niemals** `eb` (ends before) matchen. Sein Ende liegt ja nie vor
+ irgendeinem endlichen Datum. Er matcht aber sehr wohl `gt`, weil sein
+ (unendliches) Ende immer über jede Suchgrenze hinausragt.
+- Ein Encounter mit unbekanntem Start (`start` fehlt, also `start = -∞`)
+ kann **niemals** `sa` (starts after) matchen. Sein Beginn liegt ja nie
+ nach irgendeinem endlichen Datum. Er matcht aber `lt`, weil sein
+ (unendlicher) Anfang immer vor jede Suchgrenze hineinreicht.
+- Eine Period ganz ohne `start` und `end` überlappt praktisch **jeden**
+ overlap-basierten Filter (`gt`, `lt`, `ge`, `le`). Sie „reicht" ja per
+ Definition über jede Grenze hinaus.
+
+Dieselben vier Präfixe wie in [Abschnitt 3](#3-matching-gegen-period-und-range),
+jetzt mit offenen statt geschlossenen Periods:
+
+
+*Matching gegen offene (unvollständige) Period/Range*
+
+**Praktische Konsequenz:** Wenn du „laufende" Ressourcen (z. B. aktive
+Encounter, offene Verordnungen) gezielt aus einer Zeitraumsuche ausschließen
+willst, reicht `eb`/`sa` allein nicht. Du musst zusätzlich nach dem Status
+oder explizit nach `end:missing=true`/`start:missing=true` filtern, je
+nachdem, was dein Server unterstützt.
+
+---
+
+## Mehrere `date`-Parameter kombinieren
+
+In der Praxis reicht ein einzelner Präfix selten, meist willst du einen
+**Bereich** definieren. FHIR-Server verknüpfen mehrere `date`-Parameter in
+derselben Query immer per **UND**. Vier typische Muster:
+
+
+*Kombination mehrerer Parameter (UND-Verknüpfung)*
+
+| Kombination | Beispiel | Charakter |
+|---|---|---|
+| `ge` + `le` | `ge2023-01-01&le2023-12-31` | Geschlossenes Intervall (beide Grenzen inklusive) |
+| `gt` + `lt` | `gt2023-01-01<2023-12-31` | Offenes Intervall (beide Grenzen exklusive) |
+| `sa` + `eb` | `sa2023-01-01&eb2023-12-31` | Strikt getrennter Bereich, primär für Period-Werte |
+| `ge` + `lt` | `ge2023-06-01<2023-07-01` | Halboffenes Intervall `[start, ende)`, Standardmuster für „genau ein Monat" |
+
+Wenn du in Timestamp-lastigen ETL-Pipelines mit `[start, ende)` arbeitest,
+kommt dir `ge` + `lt` bekannt vor: es ist exakt dasselbe Muster wie bei
+klassischen Zeitfenster-Queries in SQL.
+
+---
+
+## Die vollständige 3×3-Matrix aller Bereichs-Kombinationen
+
+Die vier Muster oben sind nur die gebräuchlichsten. Tatsächlich lässt sich
+**jede** Untergrenze mit **jeder** Obergrenze kombinieren:
+
+- Untergrenzen: `ge`, `gt`, `sa`
+- Obergrenzen: `le`, `lt`, `eb`
+
+Das ergibt 3 × 3 = **9 mögliche Kombinationen**, alle spec-konform:
+
+
+*3x3-Matrix der Bereichs-Kombinationen (Untergrenze x Obergrenze)*
+
+Sie unterscheiden sich nur darin, ob die jeweilige Grenze inklusiv
+(durchgezogene Linie) oder exklusiv (gestrichelte Linie) ist, und ob es sich
+um einen einfachen Werte-Vergleich (`ge`/`gt`/`le`/`lt`) oder einen strengen
+Period-Vergleich (`sa`/`eb`) handelt. Es gibt **keine explizite
+Ausschluss-Regel** im FHIR-Standard. Jede Zelle dieser Matrix ist eine
+gültige, funktionierende Query.
+
+---
+
+## Sonderfälle: Wenn Kombinationen redundant oder widersprüchlich werden
+
+Nicht jede syntaktisch gültige Kombination ist auch praktisch sinnvoll. Drei
+Kategorien solltest du kennen, bevor du sie versehentlich in einer
+generierten Query landen lässt:
+
+
+*Sonderfälle bei Parameter-Kombinationen*
+
+### Redundante Kombinationen
+Ändern nichts am Ergebnis, sind aber technisch kein Fehler:
+- `eq` + eine Grenze, die vom `eq`-Intervall ohnehin erfüllt wird
+ (`eq2023-06-15&ge2020-01-01`): die Zusatzbedingung ist überflüssig.
+- Zwei Bedingungen desselben Richtungstyps
+ (`ge2020-01-01&ge2023-01-01`): nur die strengere (spätere) Untergrenze
+ wirkt effektiv.
+
+### Kombinationen mit garantiert leerem Ergebnis
+Strukturell unmöglich zu erfüllen:
+- `eq` + `ne` auf denselben Wert (`eq2023-06-15&ne2023-06-15`): sich
+ gegenseitig ausschließende Bedingungen.
+- Untergrenze liegt zeitlich nach der Obergrenze
+ (`ge2023-06-01&le2023-01-01`): kein Datum erfüllt beides gleichzeitig.
+
+Der Server wird solche Queries **syntaktisch akzeptieren** und einfach eine
+leere Ergebnismenge zurückgeben. Kein Fehler, aber auch keine hilfreiche
+Rückmeldung. Es lohnt sich, so etwas clientseitig vorab zu validieren.
+
+### Ungewöhnliche, aber gültige Sonderfälle
+- **Drei oder mehr `date`-Parameter**, z. B. ein Jahresbereich mit
+ ausgeschlossenem Einzeltag: `ge2023-01-01&le2023-12-31&ne2023-06-15`.
+- **`ap` kombiniert mit einer Grenze**, z. B.
+ `ap2023-06-15&ge2023-01-01`: selten genutzt, da `ap` selbst schon
+ unscharf ist und die Toleranzberechnung serverabhängig bleibt.
+
+---
+
+## Praxis-Empfehlungen zum Schluss
+
+- Für einfache Bereichsfilter ist **`ge` + `lt`** (halboffenes Intervall) meist
+ das robusteste Muster: es vermeidet Rundungsprobleme an der
+ Precision-Grenze (kein Off-by-one bei „bis einschließlich 31.12.").
+- **`sa`/`eb`** bewusst einsetzen, wenn du bei `Period`/`Range`-Feldern eine
+ *vollständige* Trennung brauchst (siehe [Abschnitt 3](#3-matching-gegen-period-und-range)),
+ z. B. „Encounter vollständig nach Entlassung X". Für einen simplen
+ „ab Datum X"-Filter ist meist `ge`/`gt` gemeint, nicht `sa`.
+- Bei `Period`-Feldern mit möglichen offenen Enden (siehe
+ [Abschnitt 4](#4-offene-unvollständige-periods)) nicht vergessen: `sa`/`eb`
+ greifen dort strukturell nie. Ggf. zusätzlich `:missing` oder Status
+ filtern.
+- Vor dem Absetzen einer Multi-Parameter-Query lohnt sich ein kurzer Check auf
+ logische Konsistenz zwischen Unter- und Obergrenze, um leere Ergebnisse
+ durch Konfigurationsfehler in der eigenen Pipeline zu vermeiden.
+
+Mit der Kurzreferenz oben und den sechs Grafiken im Hinterkopf, ohne Präfix,
+alle neun Präfixe einzeln, Containment vs. Overlap bei Period/Range (offen
+wie geschlossen), typische Kombinationen, die volle 3×3-Matrix und die
+Sonderfälle, sollte die nächste `date`-Query im FHIR-Suchparameter kein
+Rätsel mehr sein.
diff --git a/content/boox-note-scientific-workflow.md b/content/en/boox-note-scientific-workflow.md
similarity index 95%
rename from content/boox-note-scientific-workflow.md
rename to content/en/boox-note-scientific-workflow.md
index af4a079..0317252 100644
--- a/content/boox-note-scientific-workflow.md
+++ b/content/en/boox-note-scientific-workflow.md
@@ -1,7 +1,9 @@
Title: Scientific workflow with BOOX Note Air 3 C
+Slug: boox-note-scientific-workflow
Category: work
Tags: scientific workflow, collaboration, literature management
Date: 2024-01-26
+Lang: en
Status: published
Recently I bought an [ONYX BOOX Note Air 3 C](https://onyxboox.com/boox_noteair3c) to support my scientific workflow. In the end of last year I realized why I wasn't moving forward in my scientifc career. To be honest I was very well aware of one main reason, which was that I hadn't enough self-discipline to read the sources needed for my research, but I didn't know the reason for it until last year. It turned out that the main reason was that most of the sources were in digital form and I couldn't bring myself to read them on the computer monitor. A tablet or smartphone weren't viable alternatives either, as the displays simply tire me out too quickly.
@@ -30,7 +32,7 @@ Even though a read-it-later service has been integrated into Firefox for some ti
The [wallbag app](https://play.google.com/store/apps/details?id=fr.gaulupeau.apps.InThePoche) runs smoothly on the Note Air 3 C and allows me to call up my read-it-later bookmarks on this device at any time. Adding entries to the app is done via the Android sharing function and therefore also allows bookmarks to be added directly from the web browser.
-
+
*wallabag app on BOOX Note Air 3 C*
# Literature management
@@ -39,7 +41,7 @@ Since I personally and we in our scientific working group operate a shared libra
On the one hand, there is now an official [Zotero app](https://play.google.com/store/apps/details?id=org.zotero.android) in the beta phase that works on the device and, on the other hand, the currently much better app [Zoo for Zotero](https://play.google.com/store/apps/details?id=com.mickstarify.zooforzotero) also works. With the caveat that the latter cannot be installed from the Play Store. But a direct installation via APK (which can be obtained from relevant sources) is possible and has run without any problems for me so far. In addition, the last update of the app is from August 2021, so the lack of an automatic update by the Play Store is also a minor risk. Nevertheless, you should of course keep an eye on the development of direct APK installations and carry out a manual update if necessary.
-
+
*Zoo for Zotero app on BOOX Note Air 3 C*
The Zotero libraries (both my personal and the group library) contain not only scientific publications relevant to the respective research, but also other specialized literature such as textbooks and links to relevant websites and blog posts.
@@ -58,7 +60,7 @@ Even though it is called KDE Connect, it is also compatible with GNOME desktops
Even if it doesn't look particularly good on the e-ink display due to the heavily animated live output, the [official ChatGPT app](https://play.google.com/store/apps/details?id=com.openai.chatgpt) can be used. But I only use it when I really don't have any other device to hand, which is never the case as I always have at least one smartphone nearby. And despite the smaller display, the usability is far better here.
-
+
*ChatGPT app on BOOX Note Air 3 C*
# Collaboration
@@ -79,14 +81,15 @@ As the device does not come with a calendar or contacts app as standard, these h
As I live in Germany, I was particularly interested in whether and how well the [Onleihe app](https://play.google.com/store/apps/details?id=de.etecture.ekz.onleihe) for german public libraries works on the BOOX Note Air 3 C. What can I say? What can I say, it works, but the app looks very restless on the E-Ink display due to the many color representations. Although you can also change the color scheme to a dark standard theme, the green areas (visible in the screenshot below) still look very uneven, as the black used then does not form a uniform color area. Therefore, it doesn't really invite you to browse, but it's enough to quickly borrow an e-book or an e-magazine.
-
+
*Onleihe on BOOX Note Air 3 C*
Also reading electronic newspaper via the Onleihe App works quite well. Of course, you need to zoom quite a lot to compensate for the number of columns in a daily newspaper.
-
+
*Reading newspaper via Onleihe app on BOOX Note Air 3 C*
# Alternative app store
[F-Droid](https://f-droid.org) can be installed on the Note Air 3 C not only to have an alternative to the Play Store, but also to be able to install open source apps that may not have been released for the device in the Play Store. This also allows the installation of free builds for some apps, which offer the full range of functions that would otherwise only be available via a Pro upgrade.
+
diff --git a/content/en/howto-fhir-date-parameter.md b/content/en/howto-fhir-date-parameter.md
new file mode 100644
index 0000000..a4b21c9
--- /dev/null
+++ b/content/en/howto-fhir-date-parameter.md
@@ -0,0 +1,300 @@
+Title: HowTo: The FHIR `date` Search Parameter – Understanding Prefixes, Intervals, and Combinations
+Slug: howto-fhir-date-parameter
+Category: work
+Tags: FHIR, howto
+Date: 2026-08-12
+Lang: en
+Status: published
+
+Anyone building or querying a FHIR server sooner or later runs into the
+`date` search parameter. At first glance it looks simple:
+`?date=2023-06-15`. But as soon as prefixes like `ge`, `sa`, or `ap` come
+into play, and multiple `date` parameters get combined, things get
+confusing fast. This article brings order to the chaos: step by step, with
+timeline graphics for every case, and a quick-reference table for fast
+lookups.
+
+## Table of Contents
+
+[TOC]
+
+---
+
+## Quick Reference: All Prefixes at a Glance
+
+For a fast glance in between. Details and graphics for every row follow in
+the sections below.
+
+| Prefix | Name | Short rule | Example |
+|---|---|---|---|
+| *(none)* | implicit `eq` | Precision of the value determines the interval | `date=2023-06-15` |
+| `eq` | equal to | Resource interval fully within the search interval | `date=eq2023-06-15` |
+| `ne` | not equal to | Complement of `eq` | `date=ne2023-06-15` |
+| `gt` | greater than | Extends beyond the end (overlap is sufficient) | `date=gt2023-06-15` |
+| `lt` | less than | Begins before the start (overlap is sufficient) | `date=lt2023-06-15` |
+| `ge` | greater or equal | `gt` or fully contained (`eq`) | `date=ge2023-06-15` |
+| `le` | less or equal | `lt` or fully contained (`eq`) | `date=le2023-06-15` |
+| `sa` | starts after | Entirely after, **no** overlap | `date=sa2023-06-15` |
+| `eb` | ends before | Entirely before, **no** overlap | `date=eb2023-06-15` |
+| `ap` | approximately | Overlap + similar order of magnitude | `date=ap2023-06-15` |
+
+**Missing `start`/`end` on a `Period`:** a missing `start` means `-∞`, a
+missing `end` means `+∞`. That's why `sa` can never match when `start` is
+missing, and `eb` can never match when `end` is missing (details in
+[Section 4](#4-open-incomplete-periods)).
+
+---
+
+## The Core Principle: FHIR Compares Intervals, Not Points in Time
+
+The most important mental reset first: FHIR never treats date values as an
+exact point in time. It always treats them as an **interval**. How wide
+that interval is depends on the precision of the given value:
+
+- `2023` → the entire year 2023
+- `2023-06` → all of June 2023
+- `2023-06-15` → all of June 15, 2023 (00:00–24:00)
+- `2023-06-15T10:00:00` → (almost) an exact point in time
+
+Every comparison operator then compares **two intervals** with each other:
+the search interval from your query parameter, and the resource interval
+from the resource's field (e.g. `Patient.birthDate` or
+`Encounter.period`).
+
+### No prefix means `eq`, but precision still matters
+
+If you don't specify a prefix, the server assumes `eq`. The resource date
+must then lie **fully** within your search interval. The coarser the
+precision, the wider the interval, and the more resource values fit
+inside it:
+
+
+*FHIR date search parameter WITHOUT a prefix*
+
+`date=2023-06-15` only matches this single day. `date=2023-06`, on the
+other hand, matches every day in June, including the 15th. That's the
+most common trap for beginners: a "less precise" search query isn't
+stricter, it's looser.
+
+---
+
+## The Nine Prefixes at a Glance
+
+FHIR defines nine prefixes for `date` in total. Each describes a different
+relationship between the search interval (red dashed in the graphic) and
+the matching range (colored/shaded):
+
+
+*All prefixes at a glance*
+
+| Prefix | Name | Meaning |
+|---|---|---|
+| `eq` | equal to | Resource interval lies fully within the search interval |
+| `ne` | not equal to | Complement of `eq` |
+| `gt` | greater than | Resource interval **extends beyond** the end of the search interval |
+| `lt` | less than | Resource interval **begins before** the start of the search interval |
+| `ge` | greater or equal | `gt` **or** fully contained within the search interval (`eq`) |
+| `le` | less or equal | `lt` **or** fully contained within the search interval (`eq`) |
+| `sa` | starts after | Begins entirely **after** the end of the search interval, no overlap |
+| `eb` | ends before | Ends entirely **before** the start of the search interval, no overlap |
+| `ap` | approximately | Overlap, plus a similar order of magnitude between the intervals |
+
+**Important, containment vs. overlap:** Only `eq` (and, implicitly,
+`sa`/`eb`) require the resource interval to lie **fully** within, or
+**fully separated** from, the search interval. For `gt`, `lt`, `ge`, and
+`le`, an **overlap** is enough: the resource interval doesn't have to lie
+completely outside the search range, it just needs to extend past the
+respective boundary. More on that in the next section.
+
+---
+
+## Matching Against `Period` and `Range`
+
+The graphics above show the resource date as a thin red marker. That
+works for simple `date`/`dateTime` fields like `Patient.birthDate`. As
+soon as the target field is itself an **interval** (a `Period`, e.g.
+`Encounter.period`, `Condition.onsetPeriod`, or a `Range`), the
+distinction between **containment** (fully contained) and **overlap**
+(mere overlap) becomes crucial:
+
+- **`eq`** requires containment: the entire resource interval must lie
+ within the search interval.
+- **`gt` / `lt` / `ge` / `le`** only require overlap: it's enough for the
+ resource interval to extend past the respective boundary, even if part
+ of it lies on the "wrong" side.
+- **`sa` / `eb`** require the opposite of overlap: the resource interval
+ must lie fully, and without any overlap, on the respective side.
+
+For a simple point-in-time field (no `Period`), this distinction barely
+shows, since the resource's start and end are (almost) identical. There,
+`gt` and `sa` behave de facto the same. The difference only becomes
+relevant for actual time spans. That's also why `sa`/`eb` are, per the
+specification, primarily intended for `Period`/`Range` values.
+
+**Example:** An encounter runs from June 10 to June 20. The search
+`date=gt2023-06-15` should find it, even though the encounter *started*
+before the 15th. What matters is only that it extends past the 15th
+(overlap with the range "after the 15th"). With `date=sa2023-06-15`, the
+same encounter would **not** match, because it doesn't lie entirely after
+the 15th. That's exactly the practical difference between `gt` and `sa`.
+
+The following graphic makes this visible for all four "one-sided" prefixes
+(`gt`, `sa`, `lt`, `eb`) using the same three example periods: one
+entirely before, one overlapping the boundary, and one entirely after:
+
+
+*Matching against Period/Range (containment vs. overlap)*
+
+You can clearly see: `gt` and `lt` (blue shaded area, solid boundary line)
+let the overlapping Period B through as a match, while `sa` and `eb`
+(dashed boundary line) reject it. Only a period lying entirely on the
+correct side counts there.
+
+| Encounter timeframe | `date=gt2023-06-15` | `date=sa2023-06-15` |
+|---|---|---|
+| June 10–20 (overlaps the boundary) | ✅ Match (overlap) | ❌ No match (not entirely after) |
+| June 16–20 (entirely after) | ✅ Match | ✅ Match |
+| June 1–10 (entirely before) | ❌ No match | ❌ No match |
+
+---
+
+## Open (Incomplete) Periods
+
+In practice, periods are often **not closed**, for example an ongoing
+encounter without an `end`, or an imported record with an unknown
+`start`. The FHIR standard handles this clearly:
+
+> A missing lower bound (`start`) is implicitly treated as **less than any
+> real date** (i.e. `-∞`). A missing upper bound (`end`) is implicitly
+> treated as **greater than any real date** (i.e. `+∞`).
+
+This has noticeable consequences, especially for `sa` and `eb`:
+
+- An ongoing encounter (`start` set, `end` missing, so `end = +∞`) can
+ **never** match `eb` (ends before). Its end never lies before any
+ finite date. It will, however, match `gt`, because its (infinite) end
+ always extends beyond any search boundary.
+- An encounter with an unknown start (`start` missing, so `start = -∞`)
+ can **never** match `sa` (starts after). Its beginning never lies after
+ any finite date. It will, however, match `lt`, because its (infinite)
+ beginning always reaches before any search boundary.
+- A period with neither `start` nor `end` overlaps practically **every**
+ overlap-based filter (`gt`, `lt`, `ge`, `le`). By definition, it
+ "extends" past every boundary.
+
+The same four prefixes as in [Section 3](#3-matching-against-period-and-range),
+now with open instead of closed periods:
+
+
+*Matching against open (incomplete) Period/Range*
+
+**Practical consequence:** If you want to specifically exclude "ongoing"
+resources (e.g. active encounters, open orders) from a date-range search,
+`eb`/`sa` alone won't do it. You'll additionally need to filter by status,
+or explicitly by `end:missing=true`/`start:missing=true`, depending on
+what your server supports.
+
+---
+
+## Combining Multiple `date` Parameters
+
+In practice, a single prefix is rarely enough. Usually you want to define
+a **range**. FHIR servers always combine multiple `date` parameters in the
+same query with **AND**. Four typical patterns:
+
+
+*Combining multiple parameters (AND logic)*
+
+| Combination | Example | Character |
+|---|---|---|
+| `ge` + `le` | `ge2023-01-01&le2023-12-31` | Closed interval (both bounds inclusive) |
+| `gt` + `lt` | `gt2023-01-01<2023-12-31` | Open interval (both bounds exclusive) |
+| `sa` + `eb` | `sa2023-01-01&eb2023-12-31` | Strictly separated range, primarily for Period values |
+| `ge` + `lt` | `ge2023-06-01<2023-07-01` | Half-open interval `[start, end)`, the standard pattern for "exactly one month" |
+
+If you work with `[start, end)` in timestamp-heavy ETL pipelines, `ge` +
+`lt` will look familiar: it's exactly the same pattern used for classic
+time-window queries in SQL.
+
+---
+
+## The Full 3×3 Matrix of Range Combinations
+
+The four patterns above are only the most common ones. In fact, **any**
+lower bound can be combined with **any** upper bound:
+
+- Lower bounds: `ge`, `gt`, `sa`
+- Upper bounds: `le`, `lt`, `eb`
+
+That gives 3 × 3 = **9 possible combinations**, all spec-compliant:
+
+
+*3x3 matrix of range combinations (lower bound × upper bound)*
+
+They differ only in whether the respective boundary is inclusive (solid
+line) or exclusive (dashed line), and whether it's a simple value
+comparison (`ge`/`gt`/`le`/`lt`) or a strict Period comparison
+(`sa`/`eb`). There is **no explicit exclusion rule** in the FHIR
+standard. Every cell in this matrix is a valid, functioning query.
+
+---
+
+## Edge Cases: When Combinations Become Redundant or Contradictory
+
+Not every syntactically valid combination is practically meaningful. There
+are three categories you should know about before one of them ends up in a
+generated query by accident:
+
+
+*Edge cases in parameter combinations*
+
+### Redundant combinations
+Don't change the result, but aren't technically an error either:
+- `eq` plus a boundary that's already satisfied by the `eq` interval
+ (`eq2023-06-15&ge2020-01-01`): the extra condition is superfluous.
+- Two conditions of the same directional type
+ (`ge2020-01-01&ge2023-01-01`): only the stricter (later) lower bound
+ actually takes effect.
+
+### Combinations with a guaranteed empty result
+Structurally impossible to satisfy:
+- `eq` + `ne` on the same value (`eq2023-06-15&ne2023-06-15`): mutually
+ exclusive conditions.
+- The lower bound lies after the upper bound in time
+ (`ge2023-06-01&le2023-01-01`): no date can satisfy both at once.
+
+The server will **syntactically accept** such queries and simply return an
+empty result set. Not an error, but not a helpful response either. It's
+worth validating this client-side before sending the request.
+
+### Unusual but valid edge cases
+- **Three or more `date` parameters**, e.g. a year range with a single day
+ excluded: `ge2023-01-01&le2023-12-31&ne2023-06-15`.
+- **`ap` combined with a boundary**, e.g.
+ `ap2023-06-15&ge2023-01-01`: rarely used, since `ap` is already fuzzy
+ by nature, and the tolerance calculation remains server-dependent.
+
+---
+
+## Practical Recommendations
+
+- For simple range filters, **`ge` + `lt`** (half-open interval) is
+ usually the most robust pattern. It avoids rounding issues at precision
+ boundaries (no off-by-one when you mean "through December 31st
+ inclusive").
+- Use **`sa`/`eb`** deliberately when you need *complete* separation on
+ `Period`/`Range` fields (see [Section 3](#3-matching-against-period-and-range)),
+ e.g. "encounter entirely after discharge X". For a simple "from date X
+ onward" filter, you usually mean `ge`/`gt`, not `sa`.
+- For `Period` fields with possible open ends (see
+ [Section 4](#4-open-incomplete-periods)), don't forget: `sa`/`eb`
+ structurally never match there. Additionally filter by `:missing` or
+ status if needed.
+- Before sending a multi-parameter query, it's worth a quick sanity check
+ on the logical consistency between the lower and upper bound, to avoid
+ empty results caused by configuration mistakes in your own pipeline.
+
+With the quick reference above and the six graphics in mind, no prefix,
+all nine prefixes individually, containment vs. overlap for Period/Range
+(both open and closed), typical combinations, the full 3×3 matrix, and the
+edge cases, your next `date` query in FHIR should no longer be a mystery.
diff --git a/content/theme-test.md b/content/en/theme-test.md
similarity index 99%
rename from content/theme-test.md
rename to content/en/theme-test.md
index c0009fd..af183e7 100644
--- a/content/theme-test.md
+++ b/content/en/theme-test.md
@@ -102,7 +102,7 @@ At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergr
# Images
-
+
*Image of a Capybara*
# Links
diff --git a/content/images/fhir-date-all-prefixes_de.svg b/content/images/fhir-date-all-prefixes_de.svg
new file mode 100644
index 0000000..c8cc537
--- /dev/null
+++ b/content/images/fhir-date-all-prefixes_de.svg
@@ -0,0 +1,124 @@
+
\ No newline at end of file
diff --git a/content/images/fhir-date-all-prefixes_en.svg b/content/images/fhir-date-all-prefixes_en.svg
new file mode 100644
index 0000000..11dec72
--- /dev/null
+++ b/content/images/fhir-date-all-prefixes_en.svg
@@ -0,0 +1,124 @@
+
\ No newline at end of file
diff --git a/content/images/fhir-date-combinations_de.svg b/content/images/fhir-date-combinations_de.svg
new file mode 100644
index 0000000..4e6bcda
--- /dev/null
+++ b/content/images/fhir-date-combinations_de.svg
@@ -0,0 +1,56 @@
+
\ No newline at end of file
diff --git a/content/images/fhir-date-combinations_en.svg b/content/images/fhir-date-combinations_en.svg
new file mode 100644
index 0000000..fd863eb
--- /dev/null
+++ b/content/images/fhir-date-combinations_en.svg
@@ -0,0 +1,56 @@
+
\ No newline at end of file
diff --git a/content/images/fhir-date-edge-cases_de.svg b/content/images/fhir-date-edge-cases_de.svg
new file mode 100644
index 0000000..bfe86bc
--- /dev/null
+++ b/content/images/fhir-date-edge-cases_de.svg
@@ -0,0 +1,71 @@
+
\ No newline at end of file
diff --git a/content/images/fhir-date-edge-cases_en.svg b/content/images/fhir-date-edge-cases_en.svg
new file mode 100644
index 0000000..6ee4d1a
--- /dev/null
+++ b/content/images/fhir-date-edge-cases_en.svg
@@ -0,0 +1,71 @@
+
\ No newline at end of file
diff --git a/content/images/fhir-date-matrix-3x3_de.svg b/content/images/fhir-date-matrix-3x3_de.svg
new file mode 100644
index 0000000..c93b674
--- /dev/null
+++ b/content/images/fhir-date-matrix-3x3_de.svg
@@ -0,0 +1,92 @@
+
\ No newline at end of file
diff --git a/content/images/fhir-date-matrix-3x3_en.svg b/content/images/fhir-date-matrix-3x3_en.svg
new file mode 100644
index 0000000..02c66cb
--- /dev/null
+++ b/content/images/fhir-date-matrix-3x3_en.svg
@@ -0,0 +1,92 @@
+
\ No newline at end of file
diff --git a/content/images/fhir-date-no-prefix_de.svg b/content/images/fhir-date-no-prefix_de.svg
new file mode 100644
index 0000000..d82ffcb
--- /dev/null
+++ b/content/images/fhir-date-no-prefix_de.svg
@@ -0,0 +1,40 @@
+
\ No newline at end of file
diff --git a/content/images/fhir-date-no-prefix_en.svg b/content/images/fhir-date-no-prefix_en.svg
new file mode 100644
index 0000000..1d1907c
--- /dev/null
+++ b/content/images/fhir-date-no-prefix_en.svg
@@ -0,0 +1,40 @@
+
\ No newline at end of file
diff --git a/content/images/fhir-date-open-periods_de.svg b/content/images/fhir-date-open-periods_de.svg
new file mode 100644
index 0000000..d53ea44
--- /dev/null
+++ b/content/images/fhir-date-open-periods_de.svg
@@ -0,0 +1,111 @@
+
\ No newline at end of file
diff --git a/content/images/fhir-date-open-periods_en.svg b/content/images/fhir-date-open-periods_en.svg
new file mode 100644
index 0000000..4ae6d8d
--- /dev/null
+++ b/content/images/fhir-date-open-periods_en.svg
@@ -0,0 +1,111 @@
+
\ No newline at end of file
diff --git a/content/images/fhir-date-period-range-matching_de.svg b/content/images/fhir-date-period-range-matching_de.svg
new file mode 100644
index 0000000..d502eeb
--- /dev/null
+++ b/content/images/fhir-date-period-range-matching_de.svg
@@ -0,0 +1,84 @@
+
\ No newline at end of file
diff --git a/content/images/fhir-date-period-range-matching_en.svg b/content/images/fhir-date-period-range-matching_en.svg
new file mode 100644
index 0000000..fc1ca2d
--- /dev/null
+++ b/content/images/fhir-date-period-range-matching_en.svg
@@ -0,0 +1,84 @@
+
\ No newline at end of file
diff --git a/content/pages/about.md b/content/pages/about.md
deleted file mode 100644
index 65b9516..0000000
--- a/content/pages/about.md
+++ /dev/null
@@ -1,18 +0,0 @@
-Title: About me
-Tags: about
-Date: 2023-03-30
-
-As a computer scientist specializing in medical data science, my skills cover a broad range of technical areas. With a master's degree in medical informatics and a background in systems administration, I am proficient in both software development and system management.
-
-My development skills encompass Python, Bash, PowerShell andsome prior experience with Java, JavaScript, C and C++. This enables me to deliver software solutions that address the unique needs of medical data science teams, including data exchange, interoperability, and automation.
-
-On the system management side, I possess expertise in Linux and FreeBSD administration, enabling me to manage and secure Unix-based systems. I am well-versed in automation tools like Ansible, which I leverage to scale infrastructure and automate tasks. Additionally, I have experience in DevOps techniques and software test automation.
-
-In terms of project management, I am skilled in using collaboration tools such as GitLab, Atlassian JIRA and Confluence to streamline team workflows and maximize productivity. My experience in these areas allows me to effectively communicate with stakeholders, facilitate project workflows, and track progress.
-
-In addition to my technical skills, I am familiar with healthcare data exchange standards such as HL7 FHIR and HL7v2, as well as REST APIs. This knowledge is critical to my ability to work on medical data science projects that involve data exchange and interoperability.
-
-Currently, I'm expanding into data architecture technologies, delving into advanced concepts in data modeling, database design, and optimizing data storage.
-
-Overall, I am a versatile and experienced computer scientist with a passion for medical data science. My proficiencies in software development, system management, and project management equip me to tackle any technical challenge in the field of medical data science.
-
diff --git a/content/pages/de/about-me.md b/content/pages/de/about-me.md
new file mode 100644
index 0000000..1089a83
--- /dev/null
+++ b/content/pages/de/about-me.md
@@ -0,0 +1,11 @@
+Title: Über mich
+Slug: about-me
+Lang: de
+Tags: about
+Date: 2023-03-30
+
+Angefangen hat alles aus Spaß am Gerät, lange bevor daraus ein Beruf wurde. Über die Jahre bin ich vom IT-Administrator zur medizinischen Informatik gewandert. Linux und Unix sind dabei die Konstante geblieben, auf der so ziemlich alles andere aufbaut. Heute leite ich den Arbeitsbereich Infrastruktur am [Datenintegrationszentrum des Universitätsklinikums Jena](https://www.uniklinikum-jena.de/gbit/Datenintegrationszentrum.html), im Rahmen der [Medizininformatik-Initiative](https://www.medizininformatik-initiative.de/) und des [Netzwerks Universitätsmedizin](https://www.netzwerk-universitaetsmedizin.de/). Dazwischen lag ein Master in Medizinischer Informatik, weshalb ich mich meist an der Schnittstelle zwischen Systemadministration, Softwareentwicklung und klinischen Datenstandards bewege. Im Alltag arbeite ich viel mit FHIR und HL7v2, meist in Python, mit Kafka und PostgreSQL im Hintergrund.
+
+Privat betreibe ich zuhause ein kleines Homelab: ein paar Proxmox-Nodes, Ceph-Storage, eigene PKI. Falls mal was fehlt, helfen ein 3D-Drucker und ein bisschen Elektronik weiter. Und wenn gerade kein Server brennt, bin ich auch mal im Garten zu finden.
+
+Diese Seite ist eine Mischung aus beidem: technische HowTos und Notizen aus Arbeit und Homelab.
diff --git a/content/pages/en/about-me.md b/content/pages/en/about-me.md
new file mode 100644
index 0000000..766e290
--- /dev/null
+++ b/content/pages/en/about-me.md
@@ -0,0 +1,11 @@
+Title: About me
+Slug: about-me
+Lang: en
+Tags: about
+Date: 2023-03-30
+
+It all started for the hack value of it, long before it became a job. Over the years I moved from IT administrator to medical informatics. Linux and Unix have stayed the constant that pretty much everything else is built on. Today I lead the Infrastructure work area at the [Data Integration Center of the Jena University Hospital](https://www.uniklinikum-jena.de/gbit/en/IT+Department/Data+Integration+Center.html), as part of the [Medical Informatics Initiative](https://www.medizininformatik-initiative.de/en) and the [Network of University Medicine](https://www.netzwerk-universitaetsmedizin.de/en). In between came a master's degree in Medical Informatics, which is why I usually sit at the intersection of systems administration, software development, and clinical data standards. Day to day I work a lot with FHIR and HL7v2, mostly in Python, with Kafka and PostgreSQL in the background.
+
+At home I run a small homelab: a few Proxmox nodes, Ceph storage, my own PKI. If something's missing, a 3D printer and a bit of electronics usually help out. And when no server is on fire, you might also find me in the garden.
+
+This site is a mix of both: technical how-tos and notes from work and homelab.
diff --git a/pelicanconf.py b/pelicanconf.py
index accd0c9..d87eefc 100644
--- a/pelicanconf.py
+++ b/pelicanconf.py
@@ -6,14 +6,27 @@ AUTHOR = 'haemka'
SITENAME = 'haemka'
SITEURL = ''
-PATH = './content/'
-
TIMEZONE = 'Europe/Berlin'
DEFAULT_LANG = 'en'
+LOCALE = 'en_US.UTF-8'
THEME = './themes/latex/'
+PLUGINS = ['i18n_subsites']
+I18N_SUBSITES = {
+ 'de': {
+ 'SITENAME': 'haemka',
+ 'LOCALE': 'de_DE.UTF-8',
+ },
+}
+
+PATH = './content/'
+PAGE_PATHS = ['pages']
+ARTICLE_PATHS = ['en', 'de']
+
+
+
# Feed generation is usually not desired when developing
FEED_ALL_ATOM = None
CATEGORY_FEED_ATOM = None
@@ -27,11 +40,22 @@ LINKS = (('Pelican', 'http://getpelican.com/'),
('Jinja2', 'http://jinja.pocoo.org/'),
('You can modify those links in your config file', '#'),)
-# Social widget
-SOCIAL = (('You can add links in your config file', '#'),
- ('Another social link', '#'),)
-
DEFAULT_PAGINATION = False
-# Uncomment following line if you want document-relative URLs when developing
RELATIVE_URLS = True
+
+DISPLAY_RECENT_ARTICLES_ON_MENU = True
+RECENT_ARTICLES_COUNT = 10
+
+MARKDOWN = {
+ 'extension_configs': {
+ 'markdown.extensions.extra': {},
+ 'markdown.extensions.codehilite': {'css_class': 'highlight'},
+ 'markdown.extensions.meta': {},
+ 'markdown.extensions.toc': {
+ 'permalink': True,
+ 'toc_depth': '2-4',
+ },
+ },
+ 'output_format': 'html5',
+}
diff --git a/themes/latex b/themes/latex
index 29d24c0..add49ba 160000
--- a/themes/latex
+++ b/themes/latex
@@ -1 +1 @@
-Subproject commit 29d24c0b7d0cf9f23651e9fd9c3200a12d37a1a8
+Subproject commit add49ba73c7c9724eb9bc289bde966d2285c2774
diff --git a/update.sh b/update.sh
index d25ea68..112448e 100755
--- a/update.sh
+++ b/update.sh
@@ -3,7 +3,7 @@
WEBSERVER='aquaria'
build() {
- [[ ! ${VIRTUAL_ENV} ]] && NO_VENV=1 && source ./venv/bin/activate
+ [[ ! ${VIRTUAL_ENV} ]] && NO_VENV=1 && source ./.venv/bin/activate
pelican
retval=$?
[[ ${NO_VENV} ]] && deactivate
@@ -11,7 +11,7 @@ build() {
}
upload() {
- rsync -avz --delete output/* ${WEBSERVER}:~/web/
+ rsync -avz --delete output/* ${WEBSERVER}:~/web/haemka.de/
}
build