HUC Braille Tables: FAQ erweitert und zig Updates
Eigentlich war dieses Update so nicht geplant gewesen, da ich jenes erst veröffentlichen wollte, nachdem ich den FAQ-Abschnitt der HUC Braille Tables-Website vollständig ins Deutsche übersetzt gehabt hatte. Da sich allerdings bereits derart viele kleine Änderungen aufgestaut hatten und ich mich in den nächsten Tagen und Wochen ausschließlich um das Schneiden der beiden Audio-Guides zu den HUC-Braille-Tabellen kümmern möchte, habe ich mich nun doch dazu entschlossen bereits jetzt die aktualisierten HTML-Dateien zur Verfügung zu stellen. Zuerst sei der Vollständigkeit halber noch darauf hingewiesen, dass die DropDown-Liste "Gehe zu..." auf der Downloads-Seite der Eintrag "HUC-Braille-Tabellen" auf ""HUC-Braille-T." abgekürzt wurde, damit diese DropDown-Liste wieder etwas schmäler dargestellt werden kann.So, und nun aber zur HUC Braille Tables-Website selber, denn exakt diese Bezeichnung ist, also "HUC Braille Tables", nun auch im Titel aller englischen Seiten anstelle von "Hexadecimal Unicode Characters Braille Tables" ersichtlich, da sich jener in der Zwischenzeit bereits eingebürgert hatte. Auf den beiden deutschen Seiten lautet er nun "HUC-Braille-Tabellen" statt "Hexadezimal-Unicode-Zeichen-Braille-Tabellen". Und weiters wurde auch noch das Wort "Hexadezimalwert" in "Hexadezimal-Wert" im Head sowie im Header jener beiden Seiten abgeändert, da diese Schreibweise auch in der restlichen Dokumentation exakt so eingehalten wird. An der UTF-16-Surrogate-Seite fanden darüber hinaus keine Änderungen mehr statt, dafür aber im dortigen Impressum. Hier wurde im Abschnitt "Inhaber" der Threema-ID-Eintrag oberhalb der Telefonnummer verschoben, wobei dieser wiederum nun "Tel./Signal" statt "Tel." lautet.
Weiter geht's mit der Übersichts-Seite, an der sich ebenfalls etliches getan hat. Die Anmerkungen unterhalb der Tabelle im Abschnitt Documentation overview wurden um zwei Punkte erweitert, weshalb sie jetzt auch als Liste dargestellt sind, und jene sind nun standardmäßig ausgeblendet. die beiden zuvor vorhandenen Sätze in diesem nunmehrigen Unter-Abschnitt wurden übrigens leicht erweitert bzw. umgeschrieben und vor allem mit geschützten Leerzeichen geschmückt. Auch bei der englischen sowie deutschen Dokumentation, zu denen ich später noch ausführlich kommen werde, wurden zig geschützte Leerzeichen hinzugefügt. Kann gut sein, dass ich es damit ab und an etwas übertrieben habe.
Weiter geht's mit dem Links-Abschnitt, wo ich gleich mal einen Link zur iOS-/Android-App Signal dem Unter-Abschnitt "Software" hinzugefügt habe. Im Unter-Abschnitt "References to Unicode" wurde ein Link zu Emojipedia hinzugefügt und im Unter-Abschnitt "References to GitHub" der Link zum NVDA-PR #9044 entfernt, da jener in der Zwischenzeit obsolet geworden ist. Dafür wurden jenem Abschnitt Links zu den NVDA-Issues #6341, #6695, #9973 und #9982 sowie welche zu den NVDA-PRs #9544, #9545 und #9897 hinzugefügt. Und zum Schluss wurde hier nun ein gänzlich neuer Unter-Abschnitt namens "Wayback Machine" hinzugefügt, der Links zu allen mit der Wayback Machine gesicherten Versionen der HUC Braille Tables-Website sowie den dazugehörigen Ankündigungen, wie zum Beispiel diese interne News hier, aufweist.
Der Abschnitt Providing a translation war zwar zuvor bereits vorhanden, allerdings nur als HTML-Kommentar, da er noch nicht final gewesen war. Auch wenn die Offline-Versionen mit diesem heutigen Update bedauerlicherweise immer noch nicht zur Verfügung stehen – zuerst muss alles vollständig übersetzt worden sein –, ist dieser Abschnitt bereits jetzt ersichtlich. Und auch der Abschnitt "Reporting a typo" lautet nun Reporting an error or a typo und dessen erster Punkt wurde leicht erweitert. Aber auch dem Abschnitt Accesskeys and anchors wurde einerseits der Unter-abschnitt "Anchors for the headlines on this page" hinzugefügt, da man nun alle Abschnitte in der Übersichts-Seite auch direkt über einen Anker ansteuern kann, und andererseits wurde der Accesskey für die UTF-16-Surrogate-Seite von Q auf S geändert. Und zu guter Letzt wurde hier bei den einst beiden zuvor vorhandenen Unter-Abschnitten das Wort "Set" am Anfang deren Bezeichnungen entfernt, da es irgendwie deplatziert wirkte.
So, und wer sich die Anker für die Überschriften in den Dokumentationen im zuvor erwähnten Abschnitt durchgelesen hat, dem wird aufgefallen sein, dass "NVDA 2019.1" auf "NVDA 2019.2.1" geändert wurde. Der Grund hierfür ist recht einfach: NVDA 2019.2.1 ist die letzte NVDA-Version, die als Code-Basis noch auf Python 2.7 setzt und die noch kein UTF-32 unterstützt. NVDA 2019.3, welches voraussichtlich Ende 2019 noch veröffentlicht werden wird, unterstützt einerseits nun UTF-32 und andererseits verwendet es Python 3.7. Daher habe ich gleich mal vorsorglich die Installations-Anleitungen für NVDA 2019.3 online gestellt. Und an dieser Stelle sei ebenfalls gleich mal angekündigt, dass ich vorhabe im nächsten Jahr eine erweitere Version der HUC-Braille-Tabellen zu veröffentlichen, die vor allem der Darstellung von UTF-16-Surrogaten zu Gute kommen wird, da ich bedauerlicherweise erst am Freitag, dem 16. August 2019, die Kenntnis erlangte, dass man mit dem Always-Opcode mehrere Unicode-Zeichen einem einzigen Braille-Äquivalent zuweisen kann. Wenn ich mir die Liblouis-Anleitung sowie bereits bestehende Braille-Tabellen genauer angeschaut hätte, hätte ich das auch selber herausfinden können. Naja, selbst schuld. Zumindest bedeutet dies klarerweise nun, das 32 weitere Braille-Tabellen erstellt werden müssen, wobei hiervon dann sowohl bei UTF-16, als auch bei UTF-32 lediglich die ersten beiden Braille-Tabellen eingebunden sein werden, um die Ladezeiten bei NVDA auf ein Minimum zu reduzieren.
Trotzdem waren für Liblouis die jetzigen HUC-Braille-Tabellen mit einer Gesamtgröße von 76,1 MB dann doch zu viel des Guten, weshalb Liblouis-PR #730 u.a. auch deswegen am Mittwoch, dem 14. August 2019, geschlossen wurde. Wie dann eine bessere Lösung, die hoffentlich dann weitaus weniger Speicherplatz beanspruchen wird, ausschauen könnte, habe ich hier niedergeschrieben. Allerdings bin ich kein Programmierer, weshalb ich dies nicht selber machen kann. Und da die geplante, erweiterte HUC-Braille-Tabellen-Version noch mehr freien Speicherplatz erfordern wird, ist stark davon auszugehen, dass jene höchstwahrscheinlich nicht in Liblouis in dieser Form aufgenommen werden wird, weshalb ich auch keinen weiteren PR hierfür auf GitHub eröffnen werde. Infolgedessen wurden auch die Hinweistexte unterhalb der Download-Links der jetzigen HUC-Braille-Tabellen wie folgt geändert:
Note: This version is prepared to be included into Liblouis. It isn't already part of it.
» Note: This version was once prepared to be included into Liblouis. It isn't part of it.
Hinweis: Diese Version ist für die Aufnahme in Liblouis vorbereitet. Sie ist noch nicht Teil davon.
» Hinweis: Diese Version war einst für die Aufnahme in Liblouis vorbereitet. Sie ist nicht Teil davon.
Nun aber wieder zurück zu den beiden HUC-Braille-Tabellen-Dokumentationen und den darin vorgenommenen Änderungen. Im Abschnitt Definition für 8- und 6-Punkt in einfacher Sprache wurde ein neuer Unter-Abschnitt namens "Kurze Erklärung von Braille" mit fünf Sätzen hinzugefügt. Infolgedessen wurde der erste Satz im Unter-Abschnitt "Einführung zu den Braille-Tabellen" leicht überarbeitet. Und da es sich hierbei um einen Text in einfacher Sprache handelt, wurde im neuen Unter-Abschnitt das englische Adjektiv "raised" nicht mit "erhaben" sondern bewusst mit "erhöht" übersetzt. So, und nun sollte wohl offensichtlich geworden sein, dass ich nicht einfach eine DeepL-Übersetzung hernehme und jene dann lediglich 1:1 übernehme. Nein, auch beim Übersetzen mache ich mir viele Gedanken und übersetze manchmal auch mehrfach hin und her, um so die ideale Resultate sowohl für Englisch als auch für Deutsch zu erhalten. LEO und Duden kommen hier ebenfalls zum Einsatz. Und vor allem letzteres Online-Wörterbuch war hinsichtlich der korrekten Grammatik beim folgenden, einst missverständlich formulierten, nun aber korrigierten Satz in den Abschnitten Definition für 8-Punkt und Definition für 6-Punkt erforderlich – denn man lernt ja nie aus:
And from this point three braille characters are needed to define a Unicode code point correctly.
» And from this point four braille characters (including the prefix braille character) are needed to define a Unicode code point correctly.
Und ab hier werden drei Braille-Zeichen benötigt, um einen Unicode-Code-Punkt korrekt zu definieren.
» Und ab hier werden vier Braille-Zeichen (einschließlich des Präfix-Braille-Zeichens) benötigt, um einen Unicode-Code-Punkt korrekt zu definieren.
And from this point four braille characters are needed to define a Unicode code point correctly.
» And from this point five braille characters (including the prefix braille character) are needed to define a Unicode code point correctly.
Und ab hier werden vier Braille-Zeichen benötigt, um einen Unicode-Code-Punkt korrekt zu definieren.
» Und ab hier werden fünf Braille-Zeichen (einschließlich des Präfix-Braille-Zeichens) benötigt, um einen Unicode-Code-Punkt korrekt zu definieren.
Aber nicht nur bei den Definitionen wurden diese kleinen, aber doch wesentlichen Änderungen vorgenommen, sondern auch bei den Beispielen für 8- und 6-Punkt wurden jeweils zwei weitere Unicode-Zeichen der Tabelle hinzugefügt. Hierbei handelt es sich einerseits um das DVD-Emoji (U+1F4C0) und andererseits um das vereinheitlichte CJK-Ideogramm 672C 本. All jenen unter euch, die Japanisch können, dürfte bereits aufgefallen sein, dass es sich hierbei um das Kanji-Zeichen für Buch handelt. Ursprünglich hatte ich ja das Kanji-Zeichen für Baum bzw. Holz, also 木, geplant gehabt, fragte aufgrund meiner nicht vorhandenen Japanisch-Kenntnisse meinen alten Bekannten Eric Ebelt um seine Einschätzung sowie um einen Alternativ-Vorschlag zu 木. Tja, und dann kam halt von ihm das Kanji-Zeichen 本, was laut ihm dem 木 visuell recht ähnlich ist. Gut, und das es bei den HUC-Braille-Tabellen ja primär ums Lesen, und nicht um Bäume oder gar Holz geht, passte das Kanji-Zeichen 本 ja wie die Faust aufs Auge. An dieser Stelle daher einen großen Dank an Eric Ebelt für diesen wunderbaren vorschlag.
So, und da ich zuvor bereits die beiden neuen Installations-anleitungen für NVDA 2019.3 erwähnt gehabt hatte, sei noch kurz festgehalten, dass ich auch die einleitenden Hinweistexte für die beiden Installations-Anleitungen für NVDA 2019.2.1 und für die Deinstallations-Anleitung für NVDA 2019.2.1/2019.3 ergänzte. Ja, auch dessen Überschrift wurde leicht abgeändert, um Verwirrungen zu vermeiden. Übrigens testete ich am Montag, dem 28. Oktober 2019, tatsächlich noch die HUC-Braille-Tabellen unter Windows XP SP3 mit NVDA 2013.2, was auf einem über 15,5 Jahre alten Notebook mit einer rotierenden HDD nicht gerade amüsant gewesen war. Zumindest brauchte NVDA 2013.2 auf dieser lahmen Kiste trotzdem nur rund 2 Sekunden zum Laden der HUC-Braille-Tabellen.
Kommen wir nun zum größten Brocken – den FAQ. Hier wurden nun 13 weitere Fragen hinzugefügt, und zwar beginnend ab Frage-Nr. ⡇. Die Fragen mit den Nummern ⡾, ⣾, ⣞, ⡺ und ⠺ wurden nach ganz unten und jene mit der Nummer ⢺ unmittelbar unterhalb von Frage-Nr. ⡣ verschoben, da diese thematisch dort unten besser reinpassen. In Summe umfasst der FAQ-Abschnitt aktuell satte 47 Fragen, wobei mit diesem heutigen Update 15 davon ins Deutsche übersetzt sind. Und am Ende dieser internen News hier möchte ich insbesondere auf Frage-Nr. ⣇ aufmerksam machen, dessen Ursprung in den NVDA-Issues #9973 und #9982 zu finden ist. Kurzum: Die mit NVDA 2018.3 eingeführte automatische Erkennung der angeschlossenen Braillezeile führt beim Laden großer Liblouis-Braille-Tabellen – darunter zählt auch die mit Liblouis mitausgelieferte "zh-tw.ctb" mit 1,25 MB – zu teils erheblichen Problemen. solange man die Braillezeile manuell in NVDA auswählt, tritt dieser Fehler nicht auf, was ich übrigens hier nach etlichen Tests niedergeschrieben habe. Die Grenze für die Dateigröße der Liblouis-Braille-Tabellen war bei NVDA 2019.1 etwas höher, als dies bei NVDA 2019.2 der Fall war, weshalb mir dieses Problem im März 2019 noch nicht aufgefallen war.
So, und damit endet nun dieses doch recht umfangreiche Update. Aber das nächste ist bereits im Anflug. Also seid gespannt.