7. Was ist konkret zu tun?

Arboreal

Tippfehler und Programmfehler bei u/v-Regeln korrigieren. (Wer macht das?)

XML-Texte

Benedetti:

• entferne <reg> für ę
• <num value="1585" style="sc">mdlxxxv</num>
• class="sc" zu style="sc"

Workflow

Textkorrektur: Akut statt Tonos

interaktives Skript für den scholarly workflow:

• ersetze <reg faithful="{πρ}ός">πρός</reg> durch πρός
• ersetze <reg norm="exem" type="context">exẽ</reg> <lb/>plo durch <reg norm="exem- plo" type="context">exẽ-<lb/>plo</reg> (soft hyphen!)

DESpecs

• chinesische DESpecs: bei Varianten eine IDS-Sequenz angeben lassen
• uͤ versus ü markieren lassen?

Schema

<reg> mit type="unverified" (spätestens wenn die automatisierte Textverbesserung beginnt)

Frontend

Checkbox "faithful" als Unterpunkt von Original.

Der Benutzer muss gewarnt werden, dass er für Original (auch ohne faithful) eventuell bestimmte Fonts installieren muss, zum Beispiel einen MUFI-Font wie Andron, Junicode oder Palemonas.

Der Benutzer soll für einen Text die Normalisierungen von verschiedenen Sprachschichten einstellen können. Also in den extended-Optionen für jede Sprache die Wahl zwischen allen vorhandenen Normalisierungen. Wenn das Backend die Information liefert, ob ein Text <place> enthält, könnte man vielleicht auch herausfinden, welche Sprachen er laut den xml:lang-Attributen im Text enthält, und in den Optionen nur diese Sprachen auflisten?

Backend

Modulare Architektur:

• Zwei Lex-Dateien pro Sprache, eine für die Textanzeige und eine für die Wörterbuch-Normalisierung. In manchen Sprachen weitere Aufteilung in Sprachschichten. Falls gewünscht, schreibe ich die Lex-Dateien zumindest für die Textanzeige.
• Regeln sollten leicht änderbar sein, indem man eine Lex-Datei ändert, ohne in den Java-Code eingreifen zu müssen; sowohl bei einfachen Ersetzungsregeln als auch bei algorithmischen Regeln wie u/v.
• Änderungen sollten im System sofort sichtbar sein. Wenn die Lex-Dateien in Java umgewandelt werden müssen, sollte das idealerweise per Knopfdruck möglich sein.
• Die Architektur muss mit offenen Klassen wie der chinesischen Zeichenliste umgehen können, wo gelegentlich Zeichen von studentischen Hilfskräften nachgetragen werden.
• Trennung von sprachimmanenter Normalisierung (Beispiel "Gravis wird zu Akut") und technisch bedingter Normalisierung (Beispiel "Unicode wird zu Betacode"). Die technisch bedingte Normalisierung ist der sprachimmanenten Normalisierung nachgeschaltet.
  • Intern verwenden wir reines Unicode. Ein wichtiges Ziel ist, auch die Wörterbücher auf Unicode umzustellen. Falls das nicht möglich ist und zum Beispiel bei Griechisch weiterhin Betacode verwendet werden muss, brauchen wir eine modulare Architektur mit einer Unicode-Schnittstelle und kleinen Konvertierungsmodulen für die Wörterbücher, die leicht angepasst werden können.
  • Die Umwandlung von Käse in Kaese für ein bestimmtes Wörterbuch ist ein Beispiel eine technisch bedingte Normalisierung, die schon für das nächste Wörterbuch in der gleichen Sprache nicht zutrifft.
  • Aus Performance-Gründen könnte man dann die Normalisierungen eventuell automatisiert zusammenfassen. Dieser Vorgang müsste bei jeder Änderung an den Original-Modulen wiederholt werden.

Zentrales repository ("authority file") für die {}-Sequenzen aus dem faithful-Attribut: {πρ}, {q3-it-a}, {⿴口或} etc., mit Angaben, wie diese Sequenzen dargestellt werden. Eventuell auch für escape sequences wie &x1F70D;. (Wenn es zu einer Sequenz keine Angabe oder Dateinamen gibt, wird sie unverändert angezeigt.)

Die Informationen im faithful-Attribut sollen sinnvoll suchbar sein. (Für die entsprechende XQuery sollte es wohl eine Checkbox in den Suchoptionen geben: "Suche in faithful".)

Langfristig sollen zumindest die IDS- und IVS-Sequenzen als jeweils ein einziges Zeichen anzeigbar sein, siehe Ticket ​#40.

<num> wie <var> vor der morphologischen Analyse verstecken

Archimedes-Texte: Beispiel <expan abbr="cõprehenſione">comprehenſione</expan>:

• Original: cõprehenſione (neu)
• Regularized: comprehenſione (wie bisher)
• Normalized: comprehensione (wie bisher)

sprachspezifische Normalisierungen

alle Sprachen:

• ſ wird zu s
• Umgang mit Zeilenumbrüchen (siehe auch Tickets ​#62 und ​#82)

Latein:

• ß zu ss
• æ und ę zu ae
• œ wird zu oe
• ij wird zu ii
• u/v-Regeln
• nur Anzeige:
  • ò ô ö werden zu o, entsprechend für alle Vokale
• nur Wörterbuch, sprachimmanent:
  • ò wird zu o; entsprechend für alle Vokale
  • ô wird zu o; Wortform-Disambiguierung; entsprechend für alle Vokale
  • ö wird zu o; entsprechend für alle Vokale

Italienisch:

• u/v-Regeln

Englisch:

• nichts?

Französisch:

• nichts?

Deutsch (modern):

• nur Wörterbuch, technisch bedingt (Celex):
  • Umlaute

Chinesisch:

• Wortliste mit Einträgen der Form "Standard: Variante1 Variante2 etc." Beispiel: "歷: 歴"
• entferne ZWS

Griechisch:

• nur Wörterbuch, sprachimmanent:
  • Gravis wird zu Akut
• Sigma: siehe ​#64
  • korrektes Sigma im XML-Text verwenden
  • keine Normalisierung in der Textanzeige
  • keine sprachimmanente Wörterbuch-Normalisierung
  • Falls nötig, technisch bedingte Normalisierung. Überschneidet sich eventuell mit der Umwandlung in Betacode, wo beide Sigma gleich dargestellt werden.