Remake
A rebuilt edition of eDiAna — same research data, new software. The project itself is described in its original wording under About the Project.
- 3,799
- Articles carried over
- 942
- Corpus texts
- 38,077
- Word tokens
- 5,015
- Bibliographic titles
eDiAna was first built as a PHP application on a MySQL database and went online in that form. This edition is a remake: the research data is unchanged and was carried over in full, while the software around it was written anew. The description of the research project itself is kept in the original wording under About the Project.
Architecture
Every layer was replaced. What the original used stands above, what this edition uses below.
Bootstrap 5, jQuery
Nuxt 4, Vue 3, Tailwind CSS 4, server-side rendered
PHP 7
FastAPI, SQLAlchemy 2 (asynchronous), Python 3.13
MySQL
PostgreSQL 17
Each layer runs in its own container, so the whole application can be rebuilt from source with a single command.
WordPress with the Advanced Custom Fields plugin
Not yet rebuilt. The articles were written in a WordPress installation whose fields were defined with ACF; from there the material was carried into the tables this edition reads. The editorial back office — WP-Converter, Excerpt+, Literature+, Corpus+ — is planned for a second stage.
Authorship
This edition builds entirely on the original project. The research data, the editorial conventions and the wording of every article are the work of the eDiAna team; none of it has been rewritten, and the identifiers of lemmata and bibliographic titles were carried over unchanged, so existing permalinks and citations remain valid. What was rebuilt is the software around that material — data model, migration, backend and interface. That rebuild was carried out by Dr. Markus Frank with Claude Opus 5 at the LMU Center for Digital Humanities.
Search
The original offered five ways into the dictionary: the identifier of a lemma, a prompted headword, a list per language, specific word forms, and full text. All five are kept. What changed is how a query is matched against the holdings and in what order the results come back.
-
Transliteration is normalised
The original matched search terms as substrings. A form had to be typed the way it was recorded, with its diacritics, or it was not found. Queries are now normalised on both sides before they are compared:
Typed Matches Why hattusili ḫattušili diacritics are folded [ta]-ba-ti ta-ba-ti editorial brackets are ignored ḪA₂-tar HA2-tar, not ḪA₃-tar index digits are kept apart Folding the digits along with everything else would have been simpler, but it would have merged signs that are philologically distinct. They are mapped to plain digits instead.
-
Exact matches come first
A substring match has no notion of a better or worse hit: everything that contains the query is returned, in whatever order the database happens to produce. Matches are now graded — literal, then normalised, then approximate — and every result carries its score, colour-banded so that the strong hits are recognisable at a glance. Entering a[- in the corpus now yields the literal form at the top rather than somewhere among the approximate ones.
-
Word stems are not applied
Full-text search uses a text search configuration built for this material. The usual configurations reduce words to English stems, which quietly destroys philological forms; this one does not stem at all. Where a search term is close but not equal, an approximate match takes over instead.
-
Beyond the headword
Every field of a lemma can be searched, not only the headword: translation, word class, grammatical information, language section, certainty, the year of publication and revision. In the corpus, all six annotation levels are searchable individually — lemma, syllabic string, logogram, translation, morphological analysis and part of speech — or all at once.
-
One query across the corpora
The original searched each of the eight corpora separately. One query now covers all of them and returns the hits in keyword-in-context form, with the proportion of the whole text that carries glosses shown for each. That figure matters when judging whether a passage is worth opening.
-
Typing what a keyboard has no key for
Gloss wedges, index digits and the philological special characters can be entered from a virtual keyboard next to every search field, without installing a keyboard layout.
-
Results that can be cited
Search results are rendered on the server and carry their query in the address. A result can therefore be linked to in a footnote, and search engines can index it.
The original interface
The site this edition replaces was itself built twice. Select an image to enlarge it.
2015The beta, built by hand
PHP and MySQL on the server; in the browser, jQuery as the only helper library. Everything else — layout, panels, drag and drop — was written by hand. The idea was not a web page but a working environment for the desktop: panels that could be moved, collapsed and stacked like the windows of a desktop application, so that a query, an article and its index could be arranged side by side as the work required. The landing page took the placement of its elements from the title screens of the computer and video games of the time.
2017The release, on Bootstrap
The hand-built interface had two drawbacks. It was not responsive and coped badly with screen widths other than the one it had been laid out for, and building every element by hand cost too much time. In early 2017 the project therefore moved from hand-written CSS to Bootstrap — the version that stood until this rebuild.
