Interne News

HUC Braille Tables: HUCv2 wurde veröffentlicht

Exakt neun Monate nach der Veröffentlichung der HUC Braille Tables-Website stehen die HUC-Braille-Tabellen nun in Version 2 zum kostenlosen Download zur Verfügung.

Bevor ich nun darauf näher eingehe, sei auf die interne News vom Freitag, dem 1. März 2019, sowie auf jene vom Mittwoch, dem 1. Mai 2019, verwiesen, bei denen sich alles um die Entstehung der HUC8- sowie der HUC6-Braille-Tabellen dreht. Und in der internen News vom Freitag, dem 22. November 2019, hatte ich meinen NVDACon 2019-Vortrag bereits angesprochen gehabt. Tja, und genau nach diesem Vortrag, den ich am Samstag, dem 16. November 2019, von 20:09 bis 20:42 Uhr (jeweils UTF+1) hielt, kontaktierte mich am Dienstag, dem 19. November 2019, um 12:10 Uhr André-Abush Clause, der Haupt-Entwickler des NVDA-Add-ons namens BrailleExtender, via Telegram. Ja, auch hierüber bin ich erreichbar, auch wenn das nicht mein primär verwendeter Messenger ist.

Gut, was wollte er nun von mir? Tja, er fragte mich – auf Englisch –, ob er die HUC-Braille-Tabellen in BrailleExtender einbauen dürfe, was ich noch am selben Tag um 13:18 Uhr selbstverständlich bejahte, da jede andere Lösung besser als die hart-kodierten HUC-Braille-Tabellen ist, zumal die hart-kodierten HUC-Braille-Tabellen zurzeit noch ein paar Nebenwirkungen haben, worauf ich im FAQ-Abschnitt in der Dokumentation mit zig Fragen bereits ausführlich eingegangen bin. Falls sich jetzt jemand fragen sollte, ob ich Französisch könne: Ja, ich hatte es zu meiner HAK 2/Abend-HAK-Zeit von 2002 bis 2010. Und wenn man jene Sprache gute zehn Jahre lang nicht benötigt… Den Rest könnt ihr euch selber denken. Es wird schon seinen Grund haben, warum ich die HUC-Braille-Tabellen-Dokumentation nicht auch noch ins Französische übersetzt habe.

Aber gut, um den BrailleExtender geht's hier jetzt auch wieder nicht, da er vorher ja noch einen eigenen HUC-Braille-Converter außerhalb des BrailleExtenders in Python geschrieben hatte. Etwas, was ich aufgrund meines nicht vorhandenen Wissens in Pythons nicht konnte bzw. kann. Und nicht mal zwei Tage später hatte er bereits jenes Python-Skript zur Generierung der HUC8-Braille-Punktmuster fertig gehabt. Und nach zwei weiteren Tagen, also am Samstag, dem 23. November 2019, spuckte sein Skript ebenfalls HUC6-Braille-Punktmuster aus. Tja, und ein Python-Skript zum Generieren von Liblouis-kompatiblen Braille-tabellen war dann nur mehr eine Frage von Stunden, denn am Sonntag, dem 24. November 2019, um 01:10 Uhr erhielt ich von ihm via E-Mail die erste TBI-Datei mit den schönen Dateinamen "huc8-u+0000-u+ffff.tbi".

Okay, diese allererste Version hatte jetzt allerdings noch ein paar Kinderkrankheiten, denn er fügte jeder Definition als Kommentar noch das Unicode-Zeichen selber, dessen HUC8-Pendant und dessen englischen Unicode-Namen hinzu. Das war zwar nett gemeint, ließ diese TBI-Datei aber einerseits unnötig auf satte 4,11 MB auf und andererseits führte die direkte Darstellung einiger Unicode-Zeichen bzw. Code-Punkten zu äußerst unerwünschten Nebeneffekten, weil halt etliche Unicode-code-Punkte eben als Steuerzeichen fungieren. Deshalb bat ich ihm den Kommentar-Bereich komplett wegzulassen und mir eine neue TBI-Datei zukommen zu lassen, dem er noch am selben Tag nachkam, allerdings gleich mit allen 34 binnen 119 Sekunden generierten TBI-Dateien der HUC-Braille-Tabellen in einem schönen 7z-Archiv.

Diese generierten HUC-Braille-Tabellen schauten schon mal nicht schlecht aus, allerdings nahm ich nicht nur diese zum Vergleichen her, sondern auch jene, die er mir am Folgetag um 11:02 Uhr via E-Mail zukommen ließ. Diese schickte er mir nämlich zu, nachdem ich ihn am Montag, dem 25. November 2019, um 09:15 Uhr meine Pläne für HUCv2 erläutert gehabt hatte. Dieses 7z-Archiv enthielt dann nämlich auch schon die 16 "huc8s-u+*.tbi"- und die 16 "huc6s-u+*.tbi"-Dateien, die für die korrekte Darstellung der HUC8- und der HUC6-Braille-Punktmuster unter UTF16-Endanwendungen nötig sind.

Allerdings muss ich an dieser Stelle gleich mal festhalten, dass ich diese Dateien noch nicht in HUCv2, welches heute ja veröffentlicht wurde, inkludiert habe, da ich einerseits hierfür ein paar Sätze in der Dokumentation korrigieren hätte müssen, und andererseits wollte ich seine generierten TBI-Dateien nicht einfach so 1:1 übernehmen, da ich ja nicht wissen konnte bzw. kann, ob jene fehlerhaft sind. Folglich enthält die zweite Version der HUC-Braille-Tabellen auch nur Dateien, die ich selber allesamt erstellt habe – ausgenommen der neu dazugekommenen Datei "huc-lgpl-2.1.md". Und bei HUCv3, die dann die ergänzenden TBI-Dateien für UTF16-Endanwendungen enthalten wird, wird höchstwahrscheinlich dasselbe zutreffen.

Also wozu waren seine TBI-Dateien nun gut, wenn ich diese nicht einfach hernahm? Ganz einfach: Zum Vergleichen. Da ich einen komplett anderen Ansatz als er wählte, um die TBI-Dateien zu erstellen, sind auch die Fehler, die auf beiden Seiten auftreten hätten können, andere. Und so viel darf ich jetzt schon verraten: Seine 34 TBI-Dateien waren gänzlich fehlerfrei – nicht aber meine. Folglich entschied ich mich am Montag, dem 25. November 2019, um 11:40 Uhr dazu just heute unbedingt diese korrigierten TBI-Dateien online zu stellen, was ich ihm in exakt zu diesem Zeitpunkt versandten E-Mail wissen hab lassen.

An dieser Stelle möchte ich mich schon mal ganz herzlich bei André-Abush Clause für die Erstellung all seiner 66 TBI-Dateien aus dem zuletzt zugesandten 7z-Archiv, dessen Generierung gerade einmal knapp 234,5 Sekunden dauerte, ganz herzlich bedanken, da ich erst hierdurch äußerst einfach die Fehler in meinen TBI-Dateien aufspüren konnte. Eine manuelle Sichtung aller 2.228.224 Definitionen, wenn auch nur aufgrund von Suchen&Ersetzen und Copy&Paste "lediglich" um die 4.688 Zeilen hätten begutachtet werden müssen, wäre mir dies persönlich zu anstrengend gewesen – außer wenn ich diese mühselige Arbeit auf einen längeren Zeitraum ausgedehnt hätte. Dies ist nun dank André-Abush Clause nicht mehr notwendig gewesen, worüber ich sehr froh bin.

Der Vollständigkeit halber sei noch festgehalten, dass ich an jenem Tag mittels WinMerge lediglich zwei meiner TBI-Dateien mit zwei seiner TBI-Dateien vergleichen und jeweils eine Patch-Datei generieren hab lassen, und zwar jeweils die erste TBI-Datei von HUC6 um 11:05:09 Uhr und jene von HUC8 um 11:06:02 Uhr. Die beiden HUC8-Dateien waren bis auf den Header-Abschnitt völlig identisch, nicht so aber bei HUC6, bei dem ich 4 von rund 4.128 Suchen&Ersetzen-Kommandos vermasselte. Ergo waren je TBI-Datei 64 Definitionen inkorrekt, was aufgrund von Copy&Paste sich klarerweise versiebzehnfachte. In Summe also 1.088 inkorrekte Definitionen, was rund 0,049 % aller 2.228.224 Definitionen in den HUC-Braille-Tabellen entspricht.

Puh, was für eine lange Vorgeschichte. Jepp, denn die eigentliche Arbeit an den HUC-Braille-Tabellen sowie an dessen Dokumentation und an einigen HTML-Dateien begann erst vor fünf Tagen, also am Mittwoch, dem 27. November 2019. Vorweg sei aber noch darauf hingewiesen, dass ich jetzt nicht alle Zeitspannen, während ich an den HTML-Dateien herumdokterte, protokollarisch festhielt. Bei den 41 Dateien der HUC-Braille-Tabellen selber tat ich dies aus historischen Gründen aber sehr wohl. Fangen wir also gleich mal mit den beiden Ordnern an sich an, deren Erstellungsdatum für "HUC6 Braille Tables" Samstag, 16. Februar 2019, 04:25:25 Uhr und für "HUC8 Braille Tables" Samstag, 16. Februar 2019, 04:25:28 Uhr lautet. Dies ist deshalb von Interesse, da der gesamte Inhalt des Ordners "HUC6 Braille Tables" in den Ordner "HUC8 Braille Tables" verschoben und jener Ordner auf "HUC Braille Tables" umbenannt wurde. Somit werden alle 41 Dateien zu den HUC-Braille-Tabellen ab Version 2 nun in einem einzigen 7z-Archiv ausgeliefert.

Wer nun genau aufgepasst hat, dem wird aufgefallen sein, dass ich von 41 Dateien sprach. Folglich kamen drei neue Markdown-Dokumente hinzu, und zwar "huc-readme.md" am Mittwoch, dem 27. November 2019, 07:43:51 Uhr, "huc-changelog.md" am Mittwoch, dem 27. November 2019, 07:44:16 Uhr und "huc-lgpl-2.1.md" am Mittwoch, dem 27. November 2019, 07:45:04 Uhr. Bei den ersten beiden MD-Dateien handelt es sich hierbei um das Erstellungsdatum und bei der dritten um den Zeitpunkt des Downloads jener Datei von der offiziellen LGPL 2.1-Website. Und da diese Datei nicht geändert werden darf, war die Arbeit an jener bereits mit dem Download und dem Umbenennen des Dateinamens bereits vollständig abgeschlossen gewesen.

Nicht so aber bei den anderen beiden Dateien, da die Readme-Datei ja Teile der Dokumentation enthält und ich jene hinsichtlich HUCv2 abändern bzw. erweitern musste. Einerseits wurden die Überschriften "Definition für 8-Punkt" und Definition für 6-Punkt" auf "Definition für 8-Punkt (HUC8)" und "Definition für 6-Punkt (HUC6)" erweitert, sodass es hier zu keinen Missverständnissen mehr kommen kann, und andererseits wurde bei allen vier Installations-Anleitungen beim jeweils ersten Punkt "HUC8 or the HUC6 Braille Tables" auf "HUC Braille Tables" korrigiert. Zumindest dachte ich das zu jenem Zeitpunkt. Hierzu später mehr. Zumindest saß ich an jenem Tag an der Datei "huc-changelog.md" noch bis 10:51:46 Uhr und an "huc-readme.md" bis 11:46:38 Uhr. Aber finalisiert waren diese beiden Dateien noch lange nicht.

Aber auch an den Dateien "huc8-utf32.tbl" und "huc6-utf32.tbl" werkelte ich an jenem Tag noch ein klein wenig herum, und zwar bis 11:49:30 Uhr bzw. 11:52:24 Uhr. Bei diesen beiden TBL-Dateien galt es nämlich die zu inkludierenden TBI-Dateien von jeweils 17 auf jeweils die ersten beiden zu beschränken, sodass der NVDA-Startvorgang nicht unnötig in die Länge gezogen wird. Am Donnerstag, dem 28. November 2019, war ein reiner Doku-Tag, da ich hier nun bei den Abschnitten Installations-Anleitung für NVDA 2019.3 (installierte Version, UTF-32) und Installations-Anleitung für NVDA 2019.3 (portable Version, UTF-32) jeweils zwei durchaus wortreiche Absätze hinsichtlich HUCv2 beim jeweils vorletzten Punkt hinzufügte, und zwar klarerweise zugleich in der deutschen als auch in der englischen Fassung.

Tja, und trotz DeepL und LEO in der Hinterhand tat ich mir mit diesen Sätzen in puncto Übersetzung nun wirklich keinen gefallen. Aber wenn, dann will ich's auch schon ordentlich machen, weshalb ich u.a. daran auch von 10:00 bis 13:15 Uhr gesessen bin. Die Readme-Datei wurde an jenem Tag zuletzt um 13:10:37 Uhr gespeichert. Der Vollständigkeit halber sei noch erwähnt, dass die Markdown-Auszeichnungen allesamt manuell den beiden MD-Dateien hinzugefügt wurden. Hier kam folglich kein HTML-zu-Markdown-Konverter zum Einsatz, weil ich denen nicht ganz vertraue, nicht zuletzt da sie geschützte Leerzeichen oder den Gedankenstrich ("–") gerne unter den Tisch fallen lassen. Und so etwas geht nun wirklich nicht. Selbige Vorgehensweise habe ich übrigens auch für die im nächsten Jahr erscheinenden Offline-Versionen der Dokumentation vor. Mir ist schon klar, dass das viel händische Arbeit ist, aber nur so kann ich sicher sein, dass alles korrekt übernommen und ausgezeichnet ist. Zudem weisen die HTML-Dokumentationen bereits jetzt Eigenschaften auf, die so nicht 1:1 nach Markdown übertragen werden können.

Nun aber wieder zurück zu den HUC-Braille-Tabellen an sich, um genau zu sein zu den 17 TBI-Dateien beginnend mit "huc6-u+". Denn vorgestern, also am Freitag, dem 29. November 2019, zwischen 09:05 und 10:04 Uhr wurden mittels Notepad++ die zuvor erwähnten 1.088 Fehler korrigiert, und zwar zu 75 % erneut mittels Suchen&Ersetzen-Kommandos. Diese Aktionen fanden allerdings in einer neuen, leeren und nicht gespeicherten Textdatei statt, sodass hiervon ausschließlich jeweils 16 Definitionen hiervon betroffen waren. Durch diese Cut-Paste-Replace-Cut-Paste-Methode verringerte ich schon mal eine gewaltige Fehlerquelle – baute aber, wie sich später noch herausstellte, trotzdem einen neuen ein. Diese Vorgehensweise kam bei den Code-Punkt-Bereichen U+*60E0 bis U+*60EF, U+*E130 bis U+*E13F und U+*F040 bis U+*F04F zum Einsatz, wohingegen ich für die Bereiche U+*B240 bis U+*B24F direkt jeweils, also in Summe 272 Mal, die Ziffer 1 bei den Punkt-Muster-Werten hinzufügte, da dies schneller von statten ging.

Bevor ich nun allerdings meine korrigierten TBI-Dateien mit jenem vom Montag 11:02 Uhr vergleichen konnte, fehlte noch eine wesentliche Aktion, und zwar ersetzte ich zwischen 10:20 und 10:26 Uhr alle "sign" durch "noback sign" in allen 34 TBI-Dateien, sodass die HUC8- bzw. HUC6-Definitionen bei der Braille-Eingabe gänzlich ignoriert werden. Auch wenn ich hinsichtlich der Braille-Eingabe dahingehend noch keine Beschwerden erhalten habe – getestet hatte ich jene für HUCv1 ja ebenfalls noch nicht –, entschied ich mich nun trotzdem dafür. Wer's braucht, kann dies aber äußerst leicht selber rückgängig machen, da jene hierfür nötige Vorgehensweise kurz in der Changelog-Datei niedergeschrieben wurde. Auf einem doch schon recht alten Intel Core i7 960, der seit Mittwoch, dem 19. Mai 2010, in meinem Stand-PC werkelt, dauerte die Durchführung dieses einen Suchen&Ersetzen-Kommandos über alle 34 geöffneten TBI-Dateien hinweg knapp 5 Minuten und 42 Sekunden. An den 6 GB RAM lag's übrigens nicht, da Notepad++ lediglich rund ein Viertel GB belegte, sofern ich mich korrekt entsinne.

So, und von 10:43 bis 11:53 Uhr kam dann wieder WinMerge und sogar der 7-Zip File Manager zum Einsatz. Die 34 Patch-Dateien an sich wurden zwar zwischen 11:10:18 und 11:23:48 Uhr erstellt, allerdings musste ich mir hierfür zuvor eine ordentliche Vorgehensweise überlegen, was halt ein bisschen dauerte. Und danach ging's rüber in den 7-Zip File Manager, da mir dort die Dateigröße der 34 Patch-Dateien in Bytes angezeigt wurde. In der Details-Ansicht im Windows Explorer war hingegen bei allen Dateien jeweils "1 KB" ersichtlich, wodurch ich jede Datei öffnen oder umständlich die Statuszeile mit NVDA auslesen hätte müssen. Das Öffnen aller 34 Patch-Dateien konnte ich mir aus dem 7-Zip File Manager heraus allerdings sparen, sofern die Dateigrößen zwischen 262 und 270 und zwischen 468 und 476 Bytes lagen.

Und dies war auch bei allen bis auf die Datei "6u3.txt" der Fall gewesen. Diese Textdatei wies nämlich 576 Bytes auf, da ich Vollposten zuvor lediglich "3f" durch "3e" ersetzen ließ. Was das für "\y3f13f" bedeutete, könnt ihr euch bereits denken. genau, es wurde "\y3e13e" " daraus, wodurch der Code-Punkt U+3E13E nun doppelt definiert war und einer halt nicht mehr. Folglich wurde dieses Missgeschick sogleich korrigiert, sodass danach wieder alle 34 TBI-Dateien korrekt, also bis auf den Header-Abschnitt identisch, mit jenen von André-Abush Clause waren.

Der Vollständigkeit halber sei noch erwähnt, dass klarerweise eine neue Patch-Datei namens "6u3.txt" angefertigt wurde, die dann nur noch die erwartbaren Änderungen in den beiden TBI-Dateien namens "huc6-u+30000-u+3ffff.tbi" aufwies. Die vorhergehende Version dieser Patch-Datei wurde aus historischen Gründen in "old_6u3.txt" umbenannt. Laut meinem protokollarischen Aufzeichnungen tat ich an jenem Tag dann auch noch etwas zwischen 12:03 bis 12:35 Uhr, nur was genau hatte ich leider vergessen gehabt festzuhalten. Tja, und zum Zeitpunkt der Niederschrift dieses Absatzes am Dienstag, dem 28. Jänner 2020, war es mir nun nicht mehr möglich dies zu rekonstruieren. Man möge es mir bei solch einer von Details strotzenden, internen News verzeihen. Die Vorgeschichte in dieser internen News wurde zum allergrößten Teil "bereits" am Donnerstag, dem 12. Dezember 2019, niedergeschrieben, der Rest allerdings erst am 26., 28. 29. und 30. Jänner 2020. Es war für mich undenkbar und auch unmöglich gewesen, solch eine umfassende, interne News mit schönen Sätzen niederzuschreiben und parallel dazu all die Änderungen an den HUC-Braille-Tabellen und dessen Dokumentation durchzuführen. Auch ich habe meine Belastungsgrenzen.

Weiter ging's dann wieder am Samstag, dem 30. November 2019, zwischen 13:05 und 15:45 Uhr, und zwar zuerst Mal um den Header-Abschnitt aller 38 Dateien, da ich jenen nahezu komplett neu geschrieben und zugleich sämtliche Liblouis-Verweise hieraus entfernt habe. Um 14:19 Uhr war der Header-Abschnitt in allen 34 TBI-Dateien finalisiert und um 15:01 Uhr jener in den 4 TBL-Dateien, wobei ich jeweils beim Releasedatum die letzte Ziffer vorerst noch wegließ. Anschließend ging's dann mit der Finalisierung der Changelog-Datei bis 15:44 Uhr weiter. Somit waren nun alle wesentlichen Arbeiten abgeschlossen gewesen – dachte ich zumindest. Aber bevor der heutige Tag anbrach, wurden die aktualisierten HUC-Braille-Tabellen gestern noch von ca. 15:55 bis 16:00 Uhr mit NVDA 2018.1 getestet. Erwartungsgemäß klappte dies erfolgreich, also genauso wie mit den HUCv1-Dateien.

So, und nun war es endlich soweit – Tag der Veröffentlichung. Blöd nur, dass mir eine Sache, nachdem ich aufwachte, einfach keine Ruhe lassen wollte: Wie zum Teufel aktualisiert man die HUC-Braille-Tabellen? Okay, einfach die alten Dateien überschreiben. Ist doch klar, oder? Davon konnte und durfte ich aber nicht ausgehen, sodass ich heute, also am Sonntag, dem 1. Dezember 2019, von 08:00 bis 10:10 Uhr schön brav einen neuen Abschnitt namens Update-Anleitung für NVDA 2019.2.1/2019.3 (installierte/portable Version) sowohl auf Englisch als auch auf Deutsch niederschrieb. Dass jener Abschnitt sogleich noch Teil der Readme-Datei sein musste, versteht sich ja von selber. Folglich checkte ich in jenem Zeitraum auch noch die beiden MD-Dateien, also Readme und Changelog, und dann ging nach einer kurzen Pause endlich die Action los.

Von 10:29 bis 12:19 Uhr fanden nun sämtliche notwendigen Arbeiten statt, wobei hier die meiste Zeit mit den SHA-256-Prüfsummen aller Dateien und dem Anpassen aller Download-Abschnitte und -Seiten draufging. Um 10:50 Uhr wurde bei den beiden zuvor erwähnten MD-Dateien, bei allen 34 TBI- sowie bei allen 4 TBL-Dateien jeweils die Ziffer 1 beim Tag beim Releasedatum hinzugefügt und alles gespeichert, sodass hier schon mal Minuten-genaue Zeitstempel vorhanden waren. Zur Erinnerung: Die Datei "huc-lgpl-2.1.md" – die dritte MD-Datei im 7z-Archiv – darf man nicht abändern. Unmittelbar darauf wurde um 10:51:03 Uhr das 7z-Archiv erstellt und um 10:52:31 Uhr den darin enthaltenen Ordnernamen um die Versionsnummer und das Releasedatum erweitert. Für die exakt selben Vorgangsweise lauten die Uhrzeiten für das ZIP-Archiv 10:51:33 Uhr und 10:52:48 Uhr. Solange ich allerdings keine Anfragen bezüglich dem Bereitstellen jenes ZIP-Archivs erhalte, biete ich nicht zuletzt aufgrund des weitaus effektiveren LZMA2-Algorithmus nur das 7z-Archiv mit einer komprimierten Dateigröße von 4,14 MB an. Beim Deflate-Algorithmus liegt die komprimierte Dateigröße des ZIP-Archivs übrigens bei satten 7,52 MB.

Puh, was für eine anstrengende Arbeit. Aber nun war ich mit allem fertig, oder? Okay, okay, der News-Text selber war zu jenem Zeitpunkt noch überhaupt nicht niedergeschrieben gewesen, sondern nur protokollarische Notizen mit etlichen Zeitangaben. Aber diese Notizen konnte ich in diese Form nun wirklich nicht veröffentlichen, da kaum jemand damit etwas anfangen hätte können. Nein, ich lege halt schon Wert auf einen ordentlichen News-Text. Aber irgendetwas war doch noch, oder? Genau, diese Geschichte in den vier Installations-Anleitungen hinsichtlich dem "HUC8 or the HUC6 Braille Tables" im jeweils ersten Punkt. Nach einer längeren (Essens-)Pause ging's schlussendlich von 15:36 bis 16:20 Uhr in die allerletzte Runde. Da ich aber so viel an den Dokumentationen herumgedoktert hatte, war ich mir zu jenem Zeitpunkt nicht mehr sicher gewesen, ob ich irgendetwas in den FAQ geändert gehabt hatte. Folglich musste nochmals WinMerge ran und um 15:38:03 Uhr wurde eine neue Patch-Datei generiert, wobei ich die aktuelle Datei namens "en.html" mit jener vom Donnerstag, dem 21. November 2019, 07:49:23 Uhr vergleichen ließ.

Diese Patch-Datei sah jetzt soweit korrekt aus – im FAQ-Abschnitt hatte ich nichts geändert gehabt, sondern nur ein paar Teile in den vier Installations-Anleitungen und halt die Erweiterung der Überschriften mit "(HUC8)" bzw. mit "(HUC6)". Aber irgendetwas fehlte mir hier in dieser Patch-Datei. Genau, richtig erraten: Ich hatte in der englischen Dokumentation, also in der HTML-Datei, den ersten Punkt im Abschnitt Installation instructions for NVDA 2019.3 (portable version, UTF-32) vergessen gehabt jene ebenfalls zu korrigieren. So, und nun war mein Puls auf Anschlag. Hatte ich dies auch in der Readme-Datei übersehen gehabt? Wenn dem so gewesen wäre, so hätte ich die beiden Archive und zig SHA-256-Prüfsummen neu berechnen und niederschreiben müssen. Ein Rattenschwanz an zusätzlicher Arbeit, die locker eine weitere Stunde gefressen hätte. Aber Gott sei Dank hatte ich hier nochmals Glück gehabt – die Readme-Datei war korrekt gewesen.

Folglich beendete ich hier nun die Arbeit rund um das HUCv2-Update und lud alles um Punkt 16:00 Uhr auf meinem Webserver hoch und veröffentlichte diese interne News hier. Letztere allerdings, wie zuvor bereits mehrfach erwähnt, noch ohne News-Text. Wobei, so ganz stimmte das auch nicht, denn folgender Einzeiler war als News-Text bis zum Donnerstag, dem 30. Jänner 2020, ersichtlich: "Anmerkung: Der News-Text folgt am Donnerstag." In den ersten zwei oder drei Tagen nach Veröffentlichung stand statt "am Donnerstag" sogar noch "morgen". Nunja, das Wort "morgen" wäre dann aber schon arg strapaziert worden, wenn ich dies nicht recht zeitnah abgeändert gehabt hätte. Die restlichen 20 Minuten nach der Veröffentlichung um 16:00 Uhr gingen mit dem Checken aller Links und dem Überprüfen der SHA-256-Prüfsummen der auf dem Webserver hochgeladenen Dateien drauf. Schon praktisch, wenn dies im News-Text ersichtlich ist, stimmt's?

Dass ich den FAQ-Abschnitt nicht mehr überarbeitet gehabt hatte, erwähnte ich bereits. Hierfür hatte ich einfach keine Zeit mehr gehabt, da auch das Übersetzen ins Deutsche etliches an Zeit und vor allem an Konzentration frisst. Und in puncto Konzentration war am Sonntag-Nachmittag der Zenit bei mir halt schon überschritten gewesen. Das war bzw. ist jetzt aber eh nicht so schlimm, da ich mich darum während der Vervollständigung der deutschen Dokumentation voraussichtlich im Laufe des nächsten Quartals eh noch kümmern werd müssen.

Jepp, und auch im Abschnitt Pending tasks auf der Übersichts-Seite wurden die Zeitangaben sowie Reihenfolge einiger Punkte nach hinten verschoben. Der Grund hierfür liegt in einer E-Mail meines Providers vom Dienstag, dem 26. November 2019, um 10:20 Uhr begründet, denn aufgrund eines php-Upgrades im Februar 2020 werde ich nun bis dorthin ein komplett neues Backend anstelle des phpBB-Forums entwickeln und händisch mit Daten füllen müssen. Aber das ist eine andere Geschichte. Und zum Schluss sei der Vollständigkeit halber noch erwähnt, dass im Unterabschnitt "Software" im Links-Abschnitt auf der Übersichts-Seite noch ein Link zum HUC Braille Converter von André-Abush Clause, bei dem ich mich an dieser Stelle für seine tolle Arbeit noch einmal ganz herzlich bedanken möchte, und zum NVDA-Add-on BrailleExtender sowie einer im Unter-Abschnitt "References to GitHub" einer zum BrailleExtender-Issue #36 hinzugefügt wurden. Darüber hinaus sind die Unter-Abschnitte "References to Unicode" und "References to GitHub" nun standardmäßig eingeklappt, da beide mittlerweile doch recht umfangreich geworden sind.

So, und das war sie nun – die interne News zu HUCv2. War doch jetzt nicht so lang, oder?