Sprache, Harmonie und Auspacken – Ein Jahr im Leben eines Such-Nerds

Ausschnitt aus Da Vincis Codex Atlanticus, der eine Explosionsdarstellung einer Winde zeigt. Angepasst von einem gemeinfreien Bild auf Wikimedia Commons.

Hallo! Ich bin Trey und arbeite als Computerlinguist* im Team der Wikimedia-Suchplattform. Ich sage gerne, dass meine Aufgabe im Suchteam darin besteht, die Sprachverarbeitung fĂŒr die Suche zu verbessern – vor allem fĂŒr andere Sprachen als Englisch. Das ist nicht das Einzige, was ich tue, aber es ist mit Sicherheit meine Lieblingsaufgabe. Ich möchte dir von dem Projekt „Entpacken von Sprachanalysatoren“ erzĂ€hlen, an dem ich in den letzten Jahren gearbeitet habe, um die Suche in einigen Dutzend Sprachen zu verbessern und die Suche in allen von uns unterstĂŒtzten Sprachen zu harmonisieren. Dabei habe ich einige interessante Fakten ĂŒber die verschiedenen Sprachen herausgefunden und einige lĂ€stige Fehler in den Analyseprogrammen aufgedeckt. Komm und verschaffe dir einen Überblick ĂŒber das Projekt und nutze die Gelegenheit, die Sprache in ihrer fast unendlichen Vielfalt zu schĂ€tzen!

PrĂ€ludium – Sprachanalyse

Die Sprachanalyse ist eine Reihe von Schritten, um Texte – wie Wikipedia-Artikel – fĂŒr die Indizierung durch eine Suchmaschine vorzubereiten. Sie kann eine allgemeine Textverarbeitung oder eine sprachspezifische Verarbeitung umfassen, und beides kann ziemlich einfach oder ziemlich komplex sein. Anfragen von Suchenden werden auf Ă€hnliche Weise verarbeitet, so dass der Text einer Anfrage mit dem Text im Suchindex verglichen werden kann.

Die Suche im Wiki fĂŒr Wikipedia, Wiktionary‡ und die anderen sprachspezifischen Projekte wird von CirrusSearch bereitgestellt. CirrusSearch ist eine MediaWiki-Erweiterung, die derzeit auf der Suchmaschine Elasticsearch aufbaut, die wiederum auf der Suchbibliothek Apache Lucene basiert.

Lucene bietet Komponenten fĂŒr die Sprachanalyse in etwa drei Dutzend Sprachen.§ Die meisten Sprachanalysatoren haben ein paar Standardkomponenten:‖

Tokenisierung — der Text wird in der Regel in Wörter zerlegt, mehr oder weniger

Kleinschreibung von Wörtern — so dass die Suche nach einem der Wörter gehen, GEHEN und Gehen auch die anderen findet

Filterung von Stoppwörtern — so dass Wörter wie das, von, ist, und, und andere ignoriert oder ausgeklammert werden

Stemmer — die sich dem Wortstamm annĂ€hert, so dass die Suche nach einem der Wörter hoffen, hofft, hoffte und hoffend auch die anderen findet

Grundlegende Schritte der Sprachanalyse auf Englisch

Viele Sprachanalysatoren verfĂŒgen ĂŒber zusĂ€tzliche spezialisierte Formen der Normalisierung, die in der Regel darin besteht, bestimmte Zeichen in verwandte Zeichen umzuwandeln, die standardmĂ€ĂŸiger sind oder mit denen man leichter arbeiten kann; die Kleinschreibung ist eine Art der Normalisierung. Mehrere Sprachen haben eine Elisionsverarbeitung, so dass z. B. im Französischen l’Ă©lision mit Ă©lision ĂŒbereinstimmt. TĂŒrkisch hat eine andere spezielle Art der Apostrophbehandlung, ĂŒber die wir spĂ€ter noch sprechen werden. Wenn du mehr – viel mehr – ĂŒber Tokenisierung, Normalisierung, Stemming und Stoppwörter wissen willst, lies meine Blogserie ĂŒber Die Anatomie der Suche.

Um die Implementierung und Konfiguration zu erleichtern, werden die Standard-Analysekomponenten fĂŒr jede Sprache von Elasticsearch als vorkonfigurierter Analyzer gebĂŒndelt. Anstatt alles, was du brauchst, selbst zu konfigurieren, kannst du eine ziemlich gute Sprachanalyse fĂŒr Armenisch, Baskisch, Tschechisch, NiederlĂ€ndisch, Estnisch, Finnisch, Griechisch, Ungarisch, Indonesisch usw. erhalten, indem du einfach den Namen des gewĂŒnschten Sprachanalysators angibst. Kinderleicht!

Normalisierung – Ich sehe dich, Unicode

Die RealitĂ€t ist jedoch nicht ganz so einfach.¶ Große Wiki-Projekte haben Texte in vielen verschiedenen Sprachen – die mehrere Dutzend Schriftsysteme# verwenden – sowie technische Symbole, ungewöhnliche Zeichenvarianten und alle Arten von „interessanter“ Formatierung und Typografie. Wir wollen, dass diese Dinge fĂŒr die Suchenden so transparent wie möglich sind.

Wenn jemand zum Beispiel sucht nach-

  • 
 chu Quoc ngu, dann wollen wir, dass sie mit chữ Quốc ngữ ĂŒbereinstimmen – vor allem auf Wikis, wo man nicht erwarten wĂŒrde, dass Suchende vietnamesische Tastaturen benutzen.
  • 
 ÎČαρÎČÎčτÎčστησ – weil sie keine griechischen Akzente schreiben können, die Endung σ/ς im Griechischen vergessen haben und keine Ahnung von der französischen Angewohnheit haben, ϐ fĂŒr ÎČ in der Mitte eines Wortes zu verwenden – wollen wir, dass sie ÎČÎŹÏÏÎčτÎčÏƒÏ„ÎźÏ‚ entsprechen
  • 
 Hawai'i, wollen wir, dass sie dem korrekteren Hawai’i, Hawai‘i, HawaiÊŒi und HawaiÊčiΔ
  • 
 , mit Zeichen in voller Breite wollen wir, dass sie mit Wikipedia ĂŒbereinstimmen, und wenn sie nach ïœłïœšïœ·ïŸïŸŸïŸƒïŸžïœšïœ± in halber Breite suchen, wollen wir, dass sie mit ォィキペディケ ĂŒbereinstimmen
  • 
 so ziemlich allem, wollen wir, dass sie Wörter mit unerwarteten unsichtbaren Zeichen abgleichen, wie z. B. Bidirektionalzeichen von links nach rechts und von rechts nach links, weiche Bindestriche, Variationsselektoren und verschiedene „Joiner“- und „Non-Joiner“-Zeichen

GlĂŒcklicherweise stellt das Open-Source-Projekt International Components for Unicode (ICU) Bibliotheken zur VerfĂŒgung, die diese Art von Unicode-Normalisierung unterstĂŒtzen und in Elasticsearch-Plugins verpackt wurden. Zwei davon sind fĂŒr uns besonders nĂŒtzlich: ICU Normalization und ICU Folding.

ICU Normalization macht viele nĂŒtzliche Dinge:

  • einige weniger verbreitete Schriften und seltene Zeichen richtig klein zu schreiben (siehe Beispiele unten)
  • Konvertierung von manchmal visuell nicht unterscheidbaren Zeichen (je nach Schriftart), wie ” → ÎŒ, ïŻŒ → ی, ㄱ → ᄀ, und ̀ → ̀
  • die Umwandlung zahlreicher Zeichen in „normalere“ Formen, wie Ćż → s, ϐ → ÎČ, ς → σ, ïč– â†’ ? und ïž” → (
  • Streichen der oben genannten unsichtbaren Zeichen
Kleinschreibung von weniger verbreiteten und seltenen Schriftzeichen
[Hinweis: Da die Kleinbuchstaben der Cherokee-Schrift nur selten verwendet werden, werden sie in Großbuchstaben umgewandelt.]

Die vollstÀndige Liste scheint nirgendwo dokumentiert zu sein, also habe ich sie im Jahr 2020 mit roher Gewalt herausgefunden. Ich fand heraus, dass die ICU-Normalisierung nicht perfekt ist, aber eine Menge Gutes bewirkt!

ICU Folding hingegen ist viel aggressiver und scheint jedes Zeichen auf seine einfachste Form reduzieren zu wollen – Diakritik hin oder her! Es wandelt zum Beispiel jedes Ă , ĂĄ, Ăą, ĂŁ, ā, ă, ȧ, Ă€, áșŁ, Ă„, ǎ, ȁ, ȃ, ą, áșĄ, ខ, áșš, áș§, áș„, áș«, áș©, áș±, áșŻ, áș”, áșł, ÇĄ, ǟ, Ç», áș­, áș·, ⱄ, ɑ, ɐ, oder ɒ in ein einfaches a um. Als Englischsprachiger ist das genial, denn ich weiß kaum noch, wie man BiĂ ncĂĄitiān oder epĂ€jĂ€rjestelmĂ€llistyttĂ€mĂ€ttömyydellĂ€nsĂ€kÀÀnköhĂ€nkÀÀn buchstabiert, geschweige denn, wie man all diese akzentuierten Zeichen schreibt. In einem finnischsprachigen Wiki wollen wir jedoch in der Lage sein, a/Ă€ & o/ö zu unterscheiden – und auch a/Ă„. Schwedisch stimmt mit dieser Liste ĂŒberein, wĂ€hrend DĂ€nisch und Norwegisch jeweils ihre eigene Liste von Buchstaben haben, mit denen man nicht herumspielen sollte. Baskisch, Galicisch und Spanisch wollen nur, dass n/ñ nicht vermischt wird. ThailĂ€ndisch und Japanisch haben ebenfalls Listen, ebenso wie viele – vielleicht sogar die meisten – anderen Sprachen. Wir mĂŒssen also die ICU-Faltung fĂŒr viele Sprachen sprachspezifisch anpassen, aber das ist es wert, denn es macht die Suche nach fremdsprachigem Text einfacher – wo es fremdsprachig ist, hĂ€ngt natĂŒrlich vom Kontext des Wikis ab, in dem du dich befindest.

Neben den Verbesserungen, die die ICU-Komponenten bieten, haben wir auch andere Elasticsearch-Komponenten konfiguriert – oder in einigen FĂ€llen unsere eigenen geschrieben -, um uns um andere „interessante“ UmstĂ€nde zu kĂŒmmern, auf die wir im Laufe der Jahre gestoßen sind.

Wenn also jemand sucht nach –

  • 
 ac bo wri mo, sollten sie mit AcBoWriMo ĂŒbereinstimmen
  • 
 Wikimedia Phabricator, sollten mit phabricator.wikimedia.org ĂŒbereinstimmen
  • 
 screaming snake case, sollten mit SCREAMING_SNAKE_CASE ĂŒbereinstimmen
  • 
 chocolate, sollten sie mit chocĐŸlate ĂŒbereinstimmen – wobei der fette Buchstabe in der Mitte des Wortes eigentlich ein kyrillisches Zeichen ist; solche Zeichen, die fast identisch aussehen, nennt man Homoglyphen, und sie sind meine persönliche Nemesis, wenn es um die Suche geht!

Monolithische technische Schulden – Entpacken

Leider können die von Elasticsearch bereitgestellten Standardkonfigurationen des Analyzers nicht mit ICU-Komponenten oder Komponenten, die wir selbst konfiguriert oder geschrieben haben, angepasst werden. Sie werden alle in einem StĂŒck geliefert, daher die Bezeichnung monolithisch. GlĂŒcklicherweise gibt Elasticsearch die Komponenten jedes monolithischen Analyzers an und wir können sie als „benutzerdefinierte“ Analyzer wiederherstellen, die dann weiter modifiziert und aktualisiert werden können, um Probleme wie die oben genannten zu lösen.

In der Theorie ist das großartig und gibt uns jede Menge FlexibilitĂ€t! In der Praxis hat sich dies jedoch als Hindernis erwiesen, wenn es darum geht, Verbesserungen vorzunehmen oder Fehler zu beheben, denn der erste Schritt zu einer ansonsten schnellen und einfachen Korrektur◊ ist oft das „Auspacken“ eines monolithischen Analysators.

Beim Auspacken ĂŒberprĂŒfen wir zunĂ€chst, ob der ausgepackte Analyzer die gleiche Leistung bringt wie der monolithische Analyzer, was ziemlich einfach ist. Wenn wir damit aufhören, mĂŒssen wir jedoch eine kleine Reihe von Standardverbesserungen deaktivieren, die wir fĂŒr nicht-monolithische Analyzer haben, z. B. die Verwendung von ICU-Normalisierung anstelle von einfacher Kleinschreibung, die Aktivierung der Behandlung von Homoglyphen und ein paar Korrekturen fĂŒr kleine Fehler, die wir in verschiedenen Analysekomponenten gefunden haben. NatĂŒrlich wollen wir all diese Upgrades aktivieren, aber sie erfordern ein paar Tests. Und wenn wir schon dabei sind, wĂ€re es nicht toll, wenn wir die (entsprechend angepasste) ICU-Faltung aktivieren könnten? NatĂŒrlich wĂ€re es das!

Der Spanish Analyzer, in verschiedenen Stadien des Auspackens und AufrĂŒstens. Der monolithische und der ausgepackte Analyzer sind funktional gleichwertig, aber der ausgepackte Analyzer kann verĂ€ndert, angepasst und aufgerĂŒstet werden – und so war es auch.

Nachdem wir ĂŒber unser Ad-hoc-Auspacken einiger Analyzer nachgedacht hatten, wurde uns klar, dass monolithische Analyzer fĂŒr uns eine technische Schuld darstellen – sie erschweren es, spezifische Verbesserungen fĂŒr bestimmte Sprachen vorzunehmen, und sie hindern uns daran, allgemeine Verbesserungen ĂŒberall auf einmal vorzunehmen.↓

Jetzt hast du hoffentlich eine bessere Vorstellung davon, was „Entpacken von Sprachanalysatoren“ bedeutet! Das unmittelbare Ziel war es, alle vorhandenen Sprachanalysatoren auszupacken, unsere Standard-Upgrades zu aktivieren und ICU Folding fĂŒr jeden einzelnen zu aktivieren und anzupassen, und daran habe ich in den letzten zwei Jahren einen Großteil der Zeit gearbeitet.

Es war eine lange, seltsame Reise.

Testen, testen – ist das Ding an?

Im Laufe der Jahre, in denen ich mit Sprachen gearbeitet habe – beim Testen von Analyzer-Änderungen, bei der allgemeinen Analyse des Analyzer-Verhaltens und bei der Analyse großer Wikipedia- und Wiktionary-Beispiele – und bei dem Versuch herauszufinden, wie ich potenzielle Probleme am besten hervorheben kann,☞ habe ich einige Skripte entwickelt, die ich ĂŒberflĂŒssigerweise rekursiv wiederholend reduplikativ als meine „Analyse-Analyse“-Tools bezeichne.

Ich habe unter anderem gelernt, wie ich vorgehen und worauf ich achten muss:

  • Gruppen von Wörtern, die denselben Wortstamm haben, aber keine gemeinsamen Anfangs- oder Endbuchstaben aufweisen. Manchmal ist das sogar ziemlich cool: Der englische Stemmer schreibt NiederlĂ€ndisch (engl. dutch) und Niederlande (engl. Netherlands) gleich, und Filipino und Philippinen gleich. Manchmal ist es aber auch ein Zeichen dafĂŒr, dass etwas schief gelaufen ist.
  • Wirklich große Gruppen von Wörtern, die zusammen geschrieben werden. Manchmal handelt es sich um ein gemeinsames Wort mit vielen Formen. Manchmal handelt es sich um zwei oder mehr Wörter, deren Formen sich ĂŒberschneiden. Manchmal ist das ein Zeichen dafĂŒr, dass etwas schief gelaufen ist.
  • Sehr lange Wörter. Manchmal ist es nur eine etwas ĂŒbertriebene deutsche Verbindung oder eine sehr große Zahl oder eine URL oder ein Satz in einer Sprache, die keine Leerzeichen verwendet, wie zum Beispiel Thai. Manchmal ist es aber auch ein Zeichen dafĂŒr, dass etwas schiefgelaufen ist.
  • Unsichtbare Zeichen hervorheben. Wenn ein Wort mit einem weichen Bindestrich oder einer Links-nach-Rechts-Markierung versehen ist, wird es niemand jemals so schreiben, also ist es im Grunde unauffindbar!
  • Farbcodierung von Token mit gemischter Schrift, damit man leichter erkennen kann, was los ist. Wenn ein Wort wie chocĐŸlate einen nicht erkennbaren kyrillischen Buchstaben enthĂ€lt, wird es niemand jemals so schreiben, also ist es im Grunde unauffindbar!
Farbcodierte und gekennzeichnete gemischte (nicht-thailĂ€ndische) Token in einem Beispiel aus der thailĂ€ndischen Wikipedia. Alle außer ƞьmkent sind mit ziemlicher Sicherheit Homoglyphenfehler – das kyrillische weiche Zeichen (ь) wird in der historischen slawischen Sprachwissenschaft und in anderen ZusammenhĂ€ngen manchmal mit lateinischen Buchstaben verwendet.

Ich schÀtze, es ist klar, dass ich ein bisschen besessen bin von Dingen, die im Grunde unauffindbar sind, und von anderen FÀllen, in denen etwas seltsam schief gelaufen ist!

NatĂŒrlich ist es auch wichtig, alle Änderungen an einer Analysekette zu testen. Meine Analysewerkzeuge heben hervor, wo Wörter, die frĂŒher unterschiedlich waren, jetzt als dasselbe analysiert werden oder umgekehrt, ebenso wie Tokens, die frĂŒher existierten, jetzt aber nicht mehr, oder umgekehrt.

Einige nicht-thailĂ€ndische Änderungen aus den thailĂ€ndischen Wikipedia-Daten (siehe mehr ĂŒber thailĂ€ndische Änderungen unten). Tƍkyƍ (mit Makrons) wird jetzt mit Tokyo (ohne) indiziert. Tom’s (mit geschweiftem Apostroph) wird mit Tom’s (mit geradem Apostroph) indiziert. Tomas wird mit zwei Versionen mit akutem und schwerem Akzent indiziert. Der Anstieg der Anzahl der Instanzen von Tokio und Toll/toll ist auf Änderungen bei der Tokenisierung zurĂŒckzufĂŒhren.

Ein weiterer Aspekt des Testens und der Analyse, den ich fĂŒr dieses Projekt aufgegriffen habe, ist die ÜberprĂŒfung der Änderungen in den Ergebnissen einer Stichprobe von Abfragen, nachdem Aktualisierungen vorgenommen wurden. Wenn ich mir die Änderungen in den Wikipedia- und Wiktionary-Beispielen ansehe, die ich vor dem Einsatz teste, gibt es genug Anhaltspunkte, um sicher zu sein, dass die Änderungen des Analysators korrekt sind. Der zusĂ€tzliche Schritt, die Abfragen nach der Bereitstellung zu prĂŒfen, hilft dabei, den Einfluss der Änderungen zu beurteilen.

In der Regel kann der Abbau technischer Schulden zu keinen sichtbaren VerĂ€nderungen im Verhalten der Software fĂŒhren – sauberer Code lĂ€uft vielleicht etwas schneller und ist definitiv einfacher zu handhaben, was sich bei der zukĂŒnftigen Entwicklung auszahlt. In diesem Fall jedoch bewirken ICU Normalization und ICU Folding oft eine kleine, aber deutliche Verbesserung** bei der Anzahl der Abfragen, die keine Ergebnisse liefern, und haben einen Ă€hnlichen Einfluss auf die Anzahl der zurĂŒckgegebenen Ergebnisse im Allgemeinen. Ein Beispiel: Ohne ICU Folding wird die Suche nach Biancaitian keine BiĂ ncĂĄitiān finden. Es hĂ€ngt von vielen Faktoren ab, ob ein Wort ohne seine bevorzugten diakritischen Zeichen in einem Wiki vorkommt, aber im Allgemeinen erhöht die Möglichkeit, ohne fremde diakritische Zeichen zu suchen (und ohne herausfinden zu mĂŒssen, wie man sie eintippt), die Zahl der nĂŒtzlichen Ergebnisse.

Dieser zusÀtzliche Abfragetest hat den gesamten Entwicklungsprozess des Entpackens ein wenig verlangsamt, aber es ist schön, einen Eindruck davon zu bekommen, welchen Einfluss die Verbesserungen auf dem Weg dorthin haben.

Du sagst Anecdota, ich sage Anecdata

Wie oben und unten schon erwĂ€hnt, – wo wir von unten sprechen, du liest doch die Fußnoten, oder? Diese Fußnoten haben es in sich! Jedenfalls, wie oben und unten erwĂ€hnt, sind die Dinge oft nicht so einfach, wie man hoffen wĂŒrde.

Bei meinen Tests und Analysen habe ich einige interessante Fakten ĂŒber verschiedene Sprachen entdeckt und einige lĂ€stige Fehler in ihren Analyseprogrammen aufgedeckt. Lasst uns die Gelegenheit nutzen, die Sprache in ihrer fast unendlichen Vielfalt zu schĂ€tzen!

❊ TĂŒrkisch – die Angst vor nicht-muttersprachlichen Apostrophen

Apostrophe werden im TĂŒrkischen verwendet, um Eigennamen von angehĂ€ngten Suffixen zu trennen – z. B. TĂŒrkiye’den („aus der TĂŒrkei“) – vermutlich, weil ohne Apostroph die Grenze zwischen einem unbekannten Namen und den Suffixen unklar sein könnte. Das Englische macht etwas Ähnliches mit a’s, i’s und u’s – den Pluralen von a, i und u – um sie von den Wörtern as, is und us zu unterscheiden.

Elasticsearch/Lucene behandelt Apostrophe speziell fĂŒr das TĂŒrkische und entfernt den ersten Apostroph, den es in einem Wort findet, sowie alles, was nach dem Apostroph kommt. Das ist vernĂŒnftig fĂŒr tĂŒrkischen Text, aber es ist katastrophal fĂŒr nicht-tĂŒrkische Wörter und Namen wie D’Artagnan, d’Ivoire und d’Urbervilles – die alle zu d reduziert werden – oder O’Connell, O’Keefe und O’Sullivan – die alle zu o reduziert werden, was ein Stoppwort ist!

Die grĂ¶ĂŸte Analysegruppe in meiner tĂŒrkischen Wikipedia-Stichprobe – alle diese Wörter werden als „d“ analysiert. Du musst kein TĂŒrkisch sprechen, um zu erkennen, dass hier etwas faul ist – aber ein bisschen Französisch oder Italienisch zu können, kann nicht schaden. Beachte, dass einige dieser Wörter sowohl einen eigenen Apostroph als auch einen tĂŒrkischen Eigennamenapostroph haben, wie z.B. D’Amato’nun („D’Amato’s“) in der ersten Reihe.

Da es viele Quellen und Online-Materialien in französischer Sprache gibt, taucht in der tĂŒrkischen Wikipedia (und in vielen anderen Wikipedias) viel Französisches auf, und die Apostroph-Behandlung macht mit vielem davon gaaaanz schlimme Sachen. Noch schlimmer ist, dass der Apostroph nicht berĂŒcksichtigt, wenn es sich um nicht-lateinischen Text handelt, so dass einige sehr-nicht-tĂŒrkische Wörter wie Δπ’ΔυÎșαÎčÏÎŻÎ±, ĐżŃ€Đ”ĐŒ’єр und Ś’’ŚŚœŚ” ebenfalls mit einem Apostroph versehen sind.

Der tĂŒrkische Apostroph wird auch fĂŒr einzelne Buchstaben verwendet, egal ob es sich um den Buchstaben selbst oder um etwas handelt, das mit dem Buchstaben bezeichnet wird (z.B. „Gruppe B“), daher gibt es Formen wie B’dekilere („zu denen in B“). In meinen Daten ist d’ jedoch ĂŒberwiegend ein Indikator dafĂŒr, dass etwas auf Französisch ist. Diese beiden Trends kollidieren in meinem Lieblingsbeispiel fĂŒr tĂŒrkische Apostrophe, d’nin. Sowohl d’ als auch ‘nin bedeuten „von“ – es ist also entweder französisch fĂŒr „von nin“ oder tĂŒrkisch fĂŒr „von d“. Im Kontext eines tĂŒrkischen Wikis scheint die Annahme, dass es sich um „von d“ handelt, die sicherere Variante zu sein.

Um nicht-tĂŒrkische Wörter mit Apostrophen besser verarbeiten zu können – und tĂŒrkische Wörter mit Nicht-Apostrophen, Ă€hnlich wie in den Beispielen auf Hawai’i – habe ich einen Umweg ĂŒber das Auspacken gemacht und einen neuen, besseren Apostroph-Handler entwickelt, der etwas selbstgefĂ€llig „better_apostrophe“ heißt.

Alle FĂ€lle, Ausnahmen und Ausnahmen von Ausnahmen, die ich berĂŒcksichtigen musste, sind in der better_apostrophe ReadMe ausfĂŒhrlich beschrieben.

❊ RumĂ€nisch – Cedillas & Kommas, verwirrt & verwechselt

Als ich mich ĂŒber das rumĂ€nische Alphabet informierte – um zu erfahren, welche rumĂ€nischen Buchstaben von der ICU-Faltung ausgenommen werden mĂŒssen – erfuhr ich, dass es eine hĂ€ufige Verwechslung zwischen ß und ĆŁ (mit Zedille, nicht offiziell rumĂ€nische Buchstaben) und ș und ț (mit Komma, die richtigen rumĂ€nischen Buchstaben) gibt. Auf der rumĂ€nischen Wikipedia gibt es viele Beispiele fĂŒr beide Formen, obwohl die korrekte Kommaform im Allgemeinen viel hĂ€ufiger vorkommt.

Wie in dem oben verlinkten Wikipedia-Artikel erwĂ€hnt, gab es bis Mitte/Ende der 2000er Jahre einen großen Mangel an UnterstĂŒtzung fĂŒr die richtigen rumĂ€nischen Buchstaben. Als ich daran arbeitete, ß/ș und ĆŁ/ț fĂŒr die Suche zusammenzufĂŒhren, stellte ich fest, dass die rumĂ€nische Stoppwortliste und der rumĂ€nische Stemmer nur die Ă€lteren, falschen Cedilla-Formen der Wörter verwendeten! Diese Komponenten stammen aus der schlechten alten Zeit†† (typografisch gesehen) und wurden seitdem nicht mehr aktualisiert.

Als ich die Kommaformen zur Stoppwortliste hinzufĂŒgte, wurden 1,4 % der Wörter aus meiner Wiktionary-Stichprobe und 3,4 % der Wörter aus meiner Wikipedia-Stichprobe ausgeschlossen – in beiden FĂ€llen war die große Mehrheit der einzelnen Wörter și (was „und“ bedeutet). Wenn du și zu einem Stoppwort machst, verbessert sich sowohl die Anzahl der Ergebnisse (es ist nicht mehr erforderlich, um einen Treffer zu erhalten) als auch die Rangfolge dieser Ergebnisse (es wird nicht mehr berĂŒcksichtigt, wenn es einen Treffer gibt). Wenn du zum Beispiel nach Bosnien și Herțegovina suchst, werden (und sollten) Treffer mit Bosnien und Herțegovina viel stĂ€rker gewichtet werden als Treffer mit și.

Es gibt auch einige rumĂ€nische Beugungen, die ș und ț verwenden. Etwa 0,9 % der Wörter in meiner Wiktionary-Stichprobe und 1,8 % der Wörter in meiner Wikipedia-Stichprobe wurden nicht korrekt gestammt, werden es aber jetzt.

Unsere Probleme mit den rumĂ€nischen Kommas und Cedillen sind gelöst, aber ich habe auch Tickets dafĂŒr geöffnet, dass die Stoppwortliste in Lucene und der Snowball Stemmer das Richtige tun – nĂ€mlich sowohl ß/ș als auch ĆŁ/ț einbeziehen, da sie alle noch in Gebrauch sind und man leicht ĂŒbersieht, wenn man das falsche Wort hat.

❊ Bengali/Bangla – Unreine Normalisierung, geschĂŒttelt und gerĂŒttelt

Als ich die Liste der Sprachanalysatoren erstellte, die ausgepackt werden mussten, stellte ich fest, dass unsere damals neue Version von Elasticsearch zwei zusĂ€tzliche Analysatoren hatte, die wir nicht aktiviert hatten: Bengalisch und Estnisch. Da sie ausgepackt werden mussten, als sie aktiviert wurden, fĂŒgte ich sie meiner Liste der zu bearbeitenden Analyzer hinzu. Die Aktivierung eines neuen Analyzers – vor allem mit einem guten Stemmer, siehe Fußnote ** (in den Fußnoten steht wirklich viel Gutes!) – ist der beste Weg, um einen großen Einfluss auf die Suche nach einer bestimmten Sprache zu haben, also war das eine spannende Aussicht!

Viele der Analyseprogramme, die fĂŒr die On-Wiki-Suche eingesetzt werden, sind schon lange im Einsatz, schon vor meiner Zeit bei der Foundation, und wurden daher meines Wissens noch nicht explizit getestet oder analysiert. Deshalb werde ich (gerne, wenn auch unerwartet) abgelenkt, wenn ich etwas finde, das nicht stimmt, wie bei TĂŒrkisch und RumĂ€nisch oben. Deshalb prĂŒfe ich neue Analysatoren gerne kurz, um sicherzustellen, dass sie nichts tun, was sie offensichtlich nicht tun sollten. Im Laufe der Jahre habe ich schon einige seltsame Dinge gefunden.‡‡

Ich habe eine ganze Reihe von bengalischen Wortgruppen gefunden, die denselben Wortstamm haben, aber keine gemeinsamen Anfangs- oder Endbuchstaben aufweisen – ein Grund fĂŒr besondere Aufmerksamkeit, aber nicht unbedingt ein Fehler. Die hĂ€ufigste Variante waren die Anfangsbuchstaben àŠ¶, àŠ·, àŠž (shĂŽ, áčŁĂŽ, sĂŽ). Mit Hilfe von Wiktionary und Google Translate sahen die Dinge ziemlich verdĂ€chtig aus, aber keines von beiden ist 100% zuverlĂ€ssig (vor allem in einem Schriftsystem, das ich nicht kenne). Nachdem ich mich mit einigen Bangla-Sprechern beraten und mir einige eindeutig schlechte Beispiele angeschaut hatte – wie àŠŹàŠżàŠ¶ (die Zahl „20“); àŠŹàŠżàŠ· („Gift“); àŠŹàŠżàŠž („LotusstĂ€ngel“), die ĂŒberhaupt nichts miteinander zu tun zu haben scheinen – beschloss ich, die Quelle der Verwechslung im Bengali-Analysator aufzuspĂŒren.

Der Standard-Bengali-Analysator von Elasticsearch verfĂŒgt ĂŒber einige zusĂ€tzliche Komponenten, die ĂŒber den ĂŒblichen Tokenizer, die Kleinschreibung, den Stoppwortfilter und den Stemmer hinausgehen. Es gibt drei Komponenten, die eine zusĂ€tzliche Normalisierung vornehmen:

  • decimal_digit, das viele nicht-westliche arabische Ziffern (siehe Beispiele unten) in westliche arabische Ziffern (0-9) umwandelt; es wird in Analyzern fĂŒr sechs verschiedene Sprachen verwendet und scheint eine numerenspezifische Teilmenge von ICU Folding zu sein
  • indic_normalization, das „die Unicode-Darstellung von Text in indischen Sprachen normalisiert“ und auch im Hindi-Analyzer verwendet wird
  • bengali_normalizer, die spezifisch fĂŒr Bengali ist, und „den Bengali-spezifischen Algorithmus implementiert, der in: Eine doppelte Metaphon-Kodierung fĂŒr Bangla und ihre Anwendung in der RechtschreibprĂŒfung spezifiziert ist“
Eine Sammlung von Vieren aus verschiedenen Schriften, die alle mit decimal_digit in die Zahl 4 umgewandelt werden.

Der Titel der Arbeit ließ bei mir sofort die Alarmglocken lĂ€uten, denn Metaphone und Double Metaphone sind bekannte phonetische Algorithmen. Phonetische Algorithmen dienen dazu, ein Wort auf der Grundlage seiner Aussprache zu kodieren.§§ Ich habe den Algorithmus in der Veröffentlichung mit der Datenanalystin unseres Teams, Aisha Khatun, die zufĂ€llig auch Bangla spricht, besprochen. Sie sagte, dass keine der Regeln auf alle Wörter oder sogar die meisten Wörter (fĂŒr die Suchindexierung) angewendet werden sollte, weil sie auf dem Klang der Buchstaben basieren. Das klingt wie ein hervorragender Algorithmus, um VorschlĂ€ge fĂŒr die RechtschreibprĂŒfung zu machen – und in der Tat lautet der erste Satz des Abstracts: „Wir stellen eine Double Metaphone Codierung fĂŒr Bangla vor, die von RechtschreibprĂŒfprogrammen verwendet werden kann, um die QualitĂ€t der VorschlĂ€ge fĂŒr falsch geschriebene Wörter zu verbessern“ – aber das ist kein guter Algorithmus, um Suchbegriffe zu finden.

Ich habe den bengali_normalizer als Teil des Entpackens deaktiviert.

Der Effekt der EinfĂŒhrung eines neuen Analysators – vor allem des Stemmers – war enorm! Die bengalische Wikipedia hatte eine sehr hohe Null-Ergebnis-Rate (49,0 %), und der neue Analyzer lieferte Ergebnisse fĂŒr etwa ⅐ der Null-Ergebnisse, was die Null-Ergebnis-Rate auf 42,3 % senkte – was immer noch ziemlich hoch ist, aber definitiv besser. Die Gesamtzahl der Abfragen ohne Null-Ergebnisse, die direkt nach der EinfĂŒhrung des Analysators mehr Ergebnisse lieferten, lag bei 33,0 % – ⅓ der Abfragen lieferten also auch mehr Ergebnisse!

❊ Arabisch, Arabisch, & Arabisch – Ressourcen nutzen, Erfolg teilen

Als ich den Arabisch-Analysator auspackte, bat ich Mike Raish vom WMF Design Research Team, mir dabei zu helfen, sicherzustellen, dass alle arabischen Zeichen, die von ICU Folding verÀndert wurden, in einem arabischsprachigen Kontext angemessen sind. Es war tatsÀchlich alles in Ordnung!

Als ich daran arbeitete, die Änderungen fĂŒr Arabisch (Sprachcode ar) auszupacken, bemerkte ich einige Wikis mit den Sprachcodes ary und arz – die sich als die Codes fĂŒr marokkanisches Arabisch und Ă€gyptisches Arabisch herausstellten. Ich habe ein wenig recherchiert und herausgefunden, dass es zumindest plausibel ist, dass der Analysator fĂŒr Standardarabisch – oder zumindest einige seiner Komponenten – auch fĂŒr die anderen arabischen Varianten funktionieren könnte.‖‖

Mike half mir dabei, die Stoppwort- und Stemmer-Komponenten fĂŒr den Einsatz in diesen beiden Wikis zu ĂŒberarbeiten, und sie funktionierten gut. Wir haben die Stoppwortliste stark erweitert und zusĂ€tzliche orthografische Varianten und Wörter mit PrĂ€fixen aufgenommen.

Als die Änderungen eingefĂŒhrt wurden, gab es enorme Verbesserungen bei der Null-Ergebnis-Rate! Etwa 1 von 5 Abfragen auf der marokkanisch-arabischen Wikipedia (von 55,3 % auf 44,8 %) fĂŒhrt jetzt zu Ergebnissen, und mehr als 1 von 3 Abfragen auf der Ă€gyptisch-arabischen Wikipedia (von 54,5 % auf 34,2 %) fĂŒhrt jetzt zu Ergebnissen! Ein Ă€hnlicher Anteil aller Suchanfragen liefert ebenfalls mehr Ergebnisse – 1 von 5 fĂŒr die marokkanisch-arabische Wikipedia und 1 von 3 fĂŒr die Ă€gyptisch-arabische Wikipedia.

❊ Falti McFalterson und Freunde

Wie bereits erwĂ€hnt, hĂ€tte das Entpacken von Analysatoren, damit sie jeweils der entsprechenden Standardkonfiguration des gebĂŒndelten Analysators entsprechen, keine Auswirkungen auf die Ausgabe des Analysators – es sind dieselben Prozesse, die nur explizit statt implizit angegeben werden. Unsere Standard-Upgrades – ICU-Normalisierung, ICU-Faltung und Homoglyphenbehandlung – können jedoch zu Verbesserungen bei der Null-Ergebnisrate und der Anzahl der zurĂŒckgegebenen Ergebnisse fĂŒhren.¶¶

Den grĂ¶ĂŸten Einfluss hat die ICU-Faltung in der Regel durch das Ignorieren fremder diakritischer Zeichen. Zum Beispiel wĂŒrde die Suche nach Muju Dogyo in der englischen Wikipedia ohne ICU Folding null Ergebnisse liefern. Mit ICU Folding findet sie MujĆ« Dƍgyƍ und erhĂ€lt (derzeit) zwei Ergebnisse. Das Eintippen von Ć« und ƍ ist auf den meisten europĂ€ischsprachigen Tastaturen schwierig, weil die Buchstaben außerhalb des romanisierten Japanisch oder einer technischen Anwendung nicht hĂ€ufig verwendet werden. GebrĂ€uchlichere japanische Wörter und Begriffe wie rƍmaji und nattƍ kommen hĂ€ufiger vor, vor allem in relevanteren Artikeln – und die stets hilfreichen WikiGnomes haben Weiterleitungen von den diakritiklosen Versionen an die richtige Stelle erstellt;## so dass ICU Folding in diesen FĂ€llen nicht viel hilft, obwohl es auch nicht schadet.

In manchen FĂ€llen stellt sich jedoch heraus, dass diakritische Zeichen, die in der offiziellen Schreibweise einer Sprache verwendet werden, in der Umgangssprache nicht so gebrĂ€uchlich sind – vor allem, wenn die Buchstaben mit diakritischen Zeichen nicht als eigenstĂ€ndige Buchstaben betrachtet werden. Im Schwedischen zum Beispiel ist Ă„ ein anderer Buchstabe als a. Vermutlich sind sie aber offensichtlich verwandt – aber warte noch ein paar tausend Jahre: Die meisten Menschen scheinen vergessen zu haben, dass G ursprĂŒnglich eine Variante von C war. Vergleiche das Spanische, wo ĂĄ ein a mit einem Akzent ist, aber immer noch ein a.

Wiki-Inhalte sind in der Regel förmlicher verfasst, aber die Abfragen können ganz schön durcheinander sein. Es scheint besonders hÀufig vorzukommen, dass Leute diakritische Zeichen weglassen, die technisch von ihrer Rechtschreibung verlangt werden, die aber in der Praxis in bestimmten Wörtern oder allgemeinen Mustern vorkommen, die so gebrÀuchlich sind, dass niemand durch das Fehlen der diakritischen Zeichen verwirrt wird. Einige Beispiele:

  • Akut gesetzte Akzente im Spanischen deuten oft auf eine unvorhersehbare Betonung hin, aber selbst als mittelmĂ€ĂŸiger Spanisch-Sprecher habe ich nie in Frage gestellt, wo die Betonung in Jose Gomez de Peru (vielleicht formeller bekannt als JosĂ© GĂłmez de PerĂș) liegt; spanische Suchende schreiben sie nicht immer
  • Irische Suchende sind sich einig, dass einige Namen, wie Seamus Padraig O Suilleabhain, keine Akzente brauchen, um klar zu sein, obwohl die WikiStickler ihn fast immer formeller als SĂ©amus PĂĄdraig Ó SĂșilleabhĂĄin schreiben
  • Portugiesische Suchende machen sich nicht immer die MĂŒhe, Tilden zu schreiben, besonders bei sĂŁo (oft „Heiliger“, hĂ€ufig in Ortsnamen wie SĂŁo Paulo verwendet).
  • Katalanische Suchende mögen es nicht, den Akzent in -‍ciĂł (das mit dem spanischen -‍ciĂłn und dem englischen -‍tion verwandt ist) zu schreiben; auch galicische Suchende schreiben hĂ€ufig -‍cion fĂŒr -‍ciĂłn
    • Technisch gesehen braucht es den Akzent, um die Betonungsregeln zu befolgen, aber es ist eine so gebrĂ€uchliche Endung, dass niemand sie mit etwas anderem verwechseln wird, wenn sie nicht akzentfrei ist, genauso wie ein englischer Sprecher -‍tion nie als „ti-on“ aussprechen wird.
  • Es ĂŒberrascht nicht, dass baskische Suchende ziemlich hĂ€ufig nach spanischen Wörtern suchen, aber es ĂŒberrascht auch nicht, dass sie nicht immer die Akzente tippen

❊ Hindi – Translitierte Texte & Tastaturspielereien

Leider hatten weder ICU Folding noch die anderen allgemeinen Verbesserungen einen großen Einfluss auf die Hindi-Wikipedia-Abfragen. In einigen anderen Sprachen war der Einfluss Ă€hnlich gering. Das kommt vor.

Was bei den Hindi-Daten auffiel, war die unglaublich hohe Null-Ergebnis-Rate, mit oder ohne ICU Folding. Die typische Null-Ergebnis-Rate fĂŒr eine große Wikipedia liegt bei 25 % bis 35 %.◊◊ In Hindi waren es ĂŒber 60 %! Da ich eine vernĂŒnftige Stichprobe von Abfragen vor mir hatte, beschloss ich, nachzuschauen, ob ich einen offensichtlichen Grund dafĂŒr finden konnte, dass etwas seltsam schief gelaufen sein könnte.

Fast 85 % der Null-Ergebnisse bei der Hindi-Wikipedia sind in lateinischer Schrift, und fast 70 % davon sehen offensichtlich wie Hindi aus, wenn sie aus Devanagari transliteriert werden, und etwa 40 % davon liefern Ergebnisse, wenn sie zurĂŒck transliteriert werden (ich habe Google Translate benutzt, um das zu testen). Grob geschĂ€tzt könnten also fast ÂŒ der Abfragen in der Hindi-Wikipedia, die keine Null-Ergebnisse liefern, mit einer vernĂŒnftigen Latein-Devanagari-Transkription wiederhergestellt werden! (Das steht auf der Liste unserer zukĂŒnftigen Projekte.)

❩ Über Thai und Tokenisierung

Die thailĂ€ndische Sprache wird in der Regel ohne Leerzeichen zwischen den Wörtern geschrieben, so dass die Tokenisierung – das Zerlegen in Wörter – eine Herausforderung ist. Von den standardmĂ€ĂŸig in Elasticsearch enthaltenen Analyseprogrammen ist Thai das einzige, das nicht den Standard-Tokenizer verwendet,☞☞ sondern einen eigenen Thai-Tokenizer. Der thailĂ€ndische Tokenizer verwendet vermutlich ein Wörterbuch und einige Heuristiken, um Wortgrenzen im thailĂ€ndischen Text zu finden.

Bei meiner Analyse habe ich festgestellt, dass der Thai-Tokenizer einige nicht-thailĂ€ndische Dinge anders macht als der Standard-Tokenizer. Er lĂ€sst Token mit doppelten AnfĂŒhrungszeichen zu (z. B. den Tippfehler let”s); außerdem erlaubt er Bindestriche,***  en-Bindestriche, em-Bindestriche, horizontale Balken, Bindestrich-Minus in voller Breite, Prozentzeichen und Ampersands. Der Standard-Tokenizer trennt Wörter an all diesen Zeichen.

Noch wichtiger ist jedoch, dass der thailĂ€ndische Tokenizer durch Leerzeichen mit Null-Breite verwirrt werden kann, die in thailĂ€ndischen Texten relativ hĂ€ufig vorkommen (zumindest in unseren Wikis). Der Tokenizer scheint in einen Zustand zu geraten, in dem er nicht mehr parst, bis er auf ein Leerzeichen oder ein anderes Zeichen stĂ¶ĂŸt, das eindeutig eine Wortgrenze darstellt. Das Ergebnis können sehr lange Token sein. Das lĂ€ngste war ĂŒber 200 Zeichen lang! (Ohne die Leerzeichen wurden 49 Wörter geparst, von denen 20 als Stoppwörter gelöscht wurden).

Die drei lĂ€ngsten Token in meinem thailĂ€ndischen Wikipedia-Beispiel. Die beiden lĂ€ngsten sind ĂŒber 200 Zeichen lang! Nullbreite Leerzeichen, die normalerweise unsichtbar sind, werden als hellblaue untere eckige Klammern (⎔) angezeigt, um auf das gemeinsame Element aller drei falsch langen Token hinzuweisen.

Es gibt zwei veraltete Thai-Zeichen, àžƒ und àž…, die im Allgemeinen durch die Ă€hnlich aussehenden und Ă€hnlich klingenden àž‚ und àž„ ersetzt wurden. Diese veralteten Zeichen verwirren auch den thailĂ€ndischen Tokenizer und fĂŒhren dazu, dass er sehr lange Token erzeugt.

Die thailĂ€ndische Schrift ist von der alten Khmer-Schrift abgeleitet und hat deshalb auch einige der Probleme, die das moderne Khmer bei der Anordnung der Zeichen und der Glyphenbildung hat – zum GlĂŒck in viel geringerem Umfang! (Einen Moment lang habe ich mir wirklich Sorgen gemacht, denn ich habe viel Zeit damit verbracht, die hĂ€ufigsten Probleme mit der Sortierung in Khmer zu lösen).

Hier sind zum Beispiel vier Zeichenfolgen, die gleich aussehen können, und wie oft sie zum Zeitpunkt meiner Untersuchung in der thailÀndischen Wikipedia auftauchten:

  • àžàž„àčˆàžł = àž + àž„ + àčˆ + àžł (8900 Vorkommen)
  • àžàž„àčàčˆàžČ = àž + àž„ + àč + àčˆ + àžČ (80 Vorkommen)
  • àžàž„àčˆàčàžČ = àž + àž„ + àčˆ + àč + àžČ (6 Vorkommen)
  • àžàž„àžłàčˆ = àž + àž„ + àžł + àčˆ (2 Vorkommen)

Da die Darstellung von Glyphen je nach Schriftart, Betriebssystem und Browser sehr unterschiedlich ausfallen kann, findest du unten einen Screenshot der gleichen Zeichen wie oben, dargestellt auf einem MacBook in den Schriftarten Helvetica, Microsoft Sans Serif und Sathu (und in Everson Mono auf der linken Seite fĂŒr die AufschlĂŒsselung nach Zeichen).

Die zwei hĂ€ufigsten Versionen des Wortes werden in mehr als einem Dutzend Schriftarten, die ich getestet habe, gleich dargestellt. Die dritte Variante wird oft gleich wiedergegeben, wie in Sathu, aber manchmal auch anders, wie in Microsoft Sans Serif (beachte, dass die Diakritika vertauscht sind), und manchmal gebrochen, wie in Helvetica. Die vierte wird selten gleich wiedergegeben wie die anderen, aber in Sathu schon. Oft wird sie anders wiedergegeben, wie in Microsoft Sans Serif, und manchmal gebrochen, wie in Helvetica. (Beachte, dass die gebrochene Darstellung in Helvetica wohl die korrekteste ist, weil die diakritischen Zeichen nicht in der „richtigen“ Reihenfolge gemĂ€ĂŸ dem Unicode-Standard verwendet werden).

All diese Variationen – wie bei Khmer (wo noch viel mehr los ist!) – sind schlecht fĂŒr die Suche, weil Wörter, die gleich aussehen, in Wirklichkeit anders geschrieben werden. Im Englischen ist das so, als ob c+l+a+y, c+a+l+y und c+l+y+a im Druck alle wie clay aussehen. Und natĂŒrlich können diese nicht kanonisch geordneten Zeichen den thailĂ€ndischen Tokenizer verwirren – weil nicht jede Variante in seinem Wörterbuch steht – und dazu fĂŒhren, dass er mehr dieser wirklich langen Token erzeugt.

Es wĂ€re nicht so schlimm, wenn der thailĂ€ndische Tokenisierer veraltete Zeichen oder falsch angeordnete diakritische Zeichen ĂŒberspringen könnte – schließlich sind sie im Grunde genommen Tippfehler – und auf der anderen Seite mit dem Heraussuchen von Wörtern beginnen wĂŒrde; die Tatsache, dass er einfach aufgibt und alles in der NĂ€he als ein einziges langes Token behandelt, ist so schlimm.

Auftritt des ICU Tokenizers! Die ICU Unicode-Komponenten umfassen nicht nur die ICU-Normalisierung und die ICU-Faltung – es gibt auch einen ICU-Tokenizer. Er verfĂŒgt ĂŒber WörterbĂŒcher und/oder Heuristiken fĂŒr eine ganze Reihe von Leerzeichen-losen ostasiatischen Sprachen, darunter Thai, Chinesisch, Japanisch, Koreanisch, Khmer, Laotisch und andere, so dass er diese Sprachen in einem einzigen Paket parsen kann.

Beim Vergleich der beiden Tokenizer habe ich ein paar neue Dinge entdeckt:

  1. Der thailĂ€ndische Tokenizer behandelt einige Symbole und Emojis sowie Ahom (𑜒𑜑đ‘œȘ𑜹) und Grantha (đ‘Œ—đ‘đ‘Œ°đ‘Œšđ‘đ‘Œ„) im Wesentlichen wie Satzzeichen und ignoriert sie vollstĂ€ndig; außerdem ignoriert er inkonsistent einige New Tai Lue (᩟áŠČᧅ኷኎áŠșᩑ᩟áŠčᧉ) Token.
  2. Der Thai-Tokenizer zerlegt wirklich lange Textzeilen in 1024-Zeichen-StĂŒcke, selbst wenn dabei ein Wort in zwei HĂ€lften geteilt wird!
  3. Der ICU-Tokenizer trennt keine thailĂ€ndischen oder arabischen Zahlen von benachbarten thailĂ€ndischen Wörtern. Das ist in Sprachen sinnvoll, in denen die Wörter Leerzeichen haben und die Zahlen wahrscheinlich absichtlich an die Wörter angehĂ€ngt werden – so ist 3a wirklich 3a und nicht 3 + a -, aber in Thai ist es weniger sinnvoll.

Der ICU-Tokenizer scheint tatsĂ€chlich besser fĂŒr Thai-Text geeignet zu sein als der Thai-Tokenizer, und seine vergleichbaren MĂ€ngel (z.B. #3 oben) können mit ein paar ErgĂ€nzungen zum ungepackten Thai-Analyzer behoben werden, um strategisch Leerzeichen an den richtigen Stellen hinzuzufĂŒgen.

Der ICU-Tokenizer hat jedoch einige weitere bekannte Probleme. Das Ă€rgerlichste fĂŒr mich – da Homoglyphen meine persönliche Nemesis sind – ist, dass er Token mit gemischter Schrift auflöst, so dass unser Freind chocĐŸlate – bei dem das fette Zeichen in der Mitte kyrillisch ist – in drei Token aufgeteilt wird: choc, ĐŸ, late. Auf diese Weise aufgespalten, können sie von unseren Upgrades zur Behandlung von Homoglyphen nicht mehr repariert werden. (Außerdem werden nicht-homoglyphische, gemischte Zeichen wie KoĐŻn in Ko + ĐŻ + n zerlegt).

Noch falscher ist wohl, dass der ICU-Tokenizer in bestimmten Kontexten auch einige seltsame Dinge mit Token macht, die mit Zahlen beginnen. So wird zum Beispiel x 3a als x + 3a geparst (weil x und a beides lateinische Zeichen sind), wĂ€hrend àžŁ 3a als àžŁ + 3 + a geparst wird (weil àžŁ und a nicht im selben Zeichensatz sind – ja, das ist seltsam).

Nachdem ich den ICU-Tokenizer aktiviert und einige zusĂ€tzliche Schritte hinzugefĂŒgt hatte, um Leerzeichen zu entfernen, veraltete Zeichen zu ersetzen und diakritische Zeichen neu zu ordnen, hatte meine thailĂ€ndische Wiktionary-Probe 21 % mehr Token und meine thailĂ€ndische Wikipedia-Probe 4 % mehr Token. Auch die Zahl der eindeutigen Token ist drastisch gesunken – um etwa 60 %. Auch die durchschnittliche LĂ€nge der unterscheidbaren thailĂ€ndischen Wörter sank: von 7,6 auf 5,1 in der Wikipedia-Stichprobe. All dies deutet darauf hin, dass lĂ€ngere Phrasen in einzelne Wörter zerlegt werden, von denen die meisten an anderer Stelle im Text vorkommen. Im Englischen wĂ€re myThaiWiktionarysample ein einziges, lĂ€ngeres Token, wĂ€hrend my + Thai + Wiktionary + sample vier kĂŒrzere Token ergibt, die alle an anderer Stelle vorkommen.

Einige weitere Änderungs-Highlights aus den Thai-Wikipedia-Daten, diesmal mit Schwerpunkt auf Thai-Wörtern. Zeichen, die normalerweise unsichtbar sind, werden hier als andere Zeichen in hellblau dargestellt. ↄ in der ersten Reihe ist ein bidirektionales „Pop“-Zeichen, » in der zweiten Reihe ist eine Links-nach-Rechts-Markierung und – in der letzten Reihe ist ein weicher Bindestrich. Diese Verschmelzungen sind alle auf das ICU Folding zurĂŒckzufĂŒhren. Die dritte Reihe zeigt, dass Token, die sich durch das veraltete àžƒ und dessen Ersatz àž‚ (sehr subtil!) unterscheiden, zusammen indiziert werden. Die vierte Zeile zeigt, dass diakritische Varianten (93 Instanzen von àžȘ + àžł und eine Instanz von àžȘ + àč + àžČ) zusammen indiziert werden – obwohl der Unterschied hier nicht direkt zu sehen ist. Wörter, die in der Stichprobe 1000 Mal oder öfter vorkommen, sind fett und dunkelblau markiert.

Als ich mir die Auswirkungen des ICU-Tokenizers nach dem Einsatz ansah, entdeckte ich, dass der Thai-Tokenizer nicht nur lĂ€cherlich lange Token erzeugt, sondern manchmal auch lĂ€cherlich kurze Token, die den Text in einzelne Thai-Zeichen zerlegen. Das kann zu vielen falsch positiven Übereinstimmungen fĂŒhren. Zum Vergleich: Das Wort Thai findet man nur in einem kleinen Teil der Artikel in der englischen Wikipedia, aber wenn wir einzelne Buchstaben indizieren wĂŒrden, dann wĂŒrde die Suche nach t, h, a und i fast jeden Artikel im Wiki finden!

Zum ersten (und bisher einzigen) Mal stieg also die Null-Ergebnis-Rate nach dem Auspacken, Aktualisieren und Modifizieren eines Analyzers um 1,5 % an, was auf die Auswirkungen des ICU-Tokenizers zurĂŒckzufĂŒhren ist. Bei etwa 0,5 % der Abfragen wurden aus null Ergebnissen einige Ergebnisse – vor allem, weil wirklich lange Token aufgelöst wurden – und bei etwa 2 % der Abfragen wurden aus einigen Ergebnissen null Ergebnisse – vor allem, weil die Wörter nicht mehr in einzelne Buchstaben aufgelöst wurden.

❊ Irisch – Gepunktete Punkte & Überpunkte

Ältere Formen der irischen Rechtschreibung verwenden einen Überpunkt (ឃ, ċ, ᾋ, etc.), um eine VerlĂ€ngerung anzuzeigen, die jetzt normalerweise mit einem folgenden h (bh, ch, dh, etc.) angezeigt wird.††† Es war einfach genug, die Zuordnung (ឃ → bh, etc.) zum ungepackten irischen Analysator hinzuzufĂŒgen. Da diese Zeichen nicht so hĂ€ufig vorkommen, gab es nicht viele Änderungen, aber eine Handvoll neuer guter Übereinstimmungen.

Eine weitere Besonderheit der gÀlischen Schrift ist, dass das klein geschriebene i ohne Punkt ist (ı). Da es im Irischen jedoch keinen Unterschied zwischen i und ı gibt, wird i in der Regel im Druck und in elektronischen Texten verwendet. ICU Folding wandelt ı bereits in i um.

Das irische Wort amhrĂĄin („Lieder“) kam in meinem Beispielkorpus sowohl in seiner modernen Form als auch in seiner Ă€lteren Form, aáčråın (mit punktiertem áč und punktlosem ı), vor. Durch das HinzufĂŒgen des Overdot-Mappings plus und der ICU-Faltung können diese beiden Formen ĂŒbereinstimmen!

Die Ă€ltere irische Rechtschreibung auf der linken Seite, mit gepunktetem m (áč) und punktlosem i (ı), ist der modernen Schreibweise auf der rechten Seite, mit mh und gepunktetem i, gewichen. In den irischen Wikis werden sie nun zusammen angezeigt.

Die Zukunft – Leben in Harmonie

Das Auspacken aller monolithischen Sprachanalysatoren ist lediglich ein Schritt – aber bei weitem der grĂ¶ĂŸte Schritt – in einem grĂ¶ĂŸeren Plan, die Sprachanalyse in allen Sprachen und Wikis zu harmonisieren. Das bedeutet natĂŒrlich nicht, dass sie alle identisch sein sollen.¶¶¶ Es wird immer eine sprachspezifische Verarbeitung in einigen Wikis geben – wir lieben die sprachspezifische Verarbeitung, ich wĂŒnschte, wir könnten sie fĂŒr mehr Wikis machen!### Und natĂŒrlich ist es sinnvoll, sich auf die Seite der „Muttersprache“ eines Wikis zu schlagen und den Text so zu verarbeiten, wie es fĂŒr diese Sprache am besten funktioniert.

Was keinen Sinn macht, ist, dass Mr. Rogers, Mr_Rogers und MrRogers in verschiedenen Wikis unterschiedlich behandelt werden, bevor eine sprachspezifische Verarbeitung stattfindet, und dass sie an verschiedenen Stellen mit Mr. Rogers ĂŒbereinstimmen können oder auch nicht. Oder dass D’Artagnan in einigen Wikis mit D’Artagnan ĂŒbereinstimmt, in anderen aber nicht. Oder dass chocĐŸlate – bei dem das verdammte fette Zeichen in der Mitte immer noch kyrillisch ist – in einem Wiki mit normaler chocolate (deutsch: Schokolade) ĂŒbereinstimmt, in einem anderen aber mit lateĐŸchocΔΔΔ in gemischter Schreibweise.

Alle nicht sprachspezifischen Verarbeitungen in den verschiedenen Wikis sollten so weit wie möglich ĂŒbereinstimmen, wobei Abweichungen durch sprachspezifische Belange begrĂŒndet sein sollten und nicht durch historische ZufĂ€lle bei der Entwicklung und dem Einsatz der Analysatoren. Und wenn die Sprachanalysatoren erst einmal so harmonisch wie möglich sind, wird es einfacher◊◊◊ sein, Verbesserungen in allen Sprachen vorzunehmen.↓↓↓

Coda – Anmerkungen und Fußnoten

Wenn du nach diesem lÀcherlich langen Blog-Beitrag noch nicht genug hast, solltest du dir professionelle Hilfe suchen kannst du dir jederzeit meine Notizen-Seiten auf MediaWiki ansehen. Ich habe eine noch lÀcherlich lÀngere Seite mit all meinen Auspacknotizen, die weniger Hintergrund, aber mehr technische Details enthÀlt. Ich dokumentiere die meisten meiner sprach- und suchbezogenen Projekte auf MediaWiki, mit Links auf meine Hauptnotizen-Seite.

Bevor ich gehe, hoffe ich, dass dir das Lesen der Fußnoten nur halb so viel Spaß gemacht hat wie mir das Schreiben. Du hast doch die Fußnoten gelesen, oder?☞☞☞


* Was ist ein/e Computerlinguist/in, fragst du? Die Details variieren von Computerlinguist/in zu Computerlinguist/in,† aber in meinem Fall lautet die kurze Antwort: „eine Spezialisierung des/der Softwareingenieur/in“. Aufmerksamen Leser/innen meiner frĂŒheren Blogs wird aufgefallen sein, dass in meinen frĂŒheren BeitrĂ€gen „Software-Ingenieur/in“ und nicht „Computerlinguist/in“ stand. Beides ist richtig, aber „Computerlinguist/in“ ist spezifischer.

† Das, was passiert, wenn du ein Wort immer wieder hörst oder siehst und es seine Bedeutung verliert, nennt man semantische SĂ€ttigung. Computerlinguist, Computerlinguist, Computerlinguist.

‡ Wahrscheinlich darf ich keinen Favoriten haben – aber eines der am schlechtesten gehĂŒteten Geheimnisse der Welt ist, dass Wiktionary mein Favorit ist. Sag es nicht den anderen Projekten.

§ Die genaue Anzahl kann sich immer wieder Ă€ndern, weil immer wieder neue Analysatoren hinzukommen, aber es ist auch einfach schwer, die vorhandenen „Sprachen“ zu zĂ€hlen. Es gibt Analyzer fĂŒr Portugiesisch und „Brasilianisch“ (auch bekannt als Portugiesisch), die sich nicht so sehr unterscheiden – zwei Analyzer, eine Sprache. Und es gibt den CJK Analyzer, der Chinesisch, Japanisch und Koreanisch unterstĂŒtzt – drei Sprachen, ein Analyzer – obwohl wir ihn im Moment nur fĂŒr Japanisch verwenden.

‖ Die meisten Sprachen verwenden einen Standard-Tokenizer, um Wörter zu finden, aber Thai hat seinen eigenen Tokenizer. Der CJK-Analysator versucht gar nicht erst, chinesische, japanische oder koreanische Wörter zu finden; er zerlegt CJK-Text einfach in sich ĂŒberschneidende Bigramme. Sprachen mit Schriftsystemen ohne Groß- und Kleinschreibung wie Arabisch, Bengalisch oder Chinesisch haben immer noch einen Schritt zur Kleinschreibung, um mit Fremdwörtern umzugehen, denn Englisch ist wie ein bad penny – es taucht ĂŒberall auf. Eine Handvoll Analysatoren – Persisch, ThailĂ€ndisch und CJK – enthalten keine Stemmer.

¶ Und wahrscheinlich ist es auch nicht so einfach. Nichts ist das jemals.

# Eine lustige Herausforderung fĂŒr Wort-Nerds: Kannst du ein Dutzend Schriftsysteme nennen? Zwei Dutzend? Vier Dutzend? Oder sogar 50! (Tipp: Allein mit den brahmischen Schriften schaffst du ⅔ davon, und hier ist ein Spickzettel, mit dem du auf ĂŒber 100 kommst).

Δ Es wĂ€re auch toll, wenn Hawai’i und HawaiÊ»i mit Hawaiâ€Či, HawaiÂŽi, HawaiáżŸi, Hawai‛i und Hawai`i ĂŒbereinstimmen wĂŒrden, die alle in der englischen Wikipedia vorkommen, aber so weit sind wir noch nicht. Hawai*i, Hawai,i und Hawai«i kommen auch in der englischen Wikipedia vor, aber ich habe kein schlechtes Gewissen, dass ich sie nicht gefunden habe. Falls du neugierig bist: Die apostrophĂ€hnlichen Zeichen sind in der Reihenfolge ihres Auftretens: Apostroph (‘), HawaiÊ»ian okina, auch bekannt als „Komma als Modifizierungsbuchstabe“ (Ê»), rechtes geschweiftes AnfĂŒhrungszeichen (’), linkes geschweiftes AnfĂŒhrungszeichen (‘), Apostroph als Modifizierungsbuchstabe (ÊŒ), Primzahl als Modifizierungsbuchstabe (Êč), Primzahl (â€Č), Akutakzent (ÂŽ), griechische Dasia (áżŸ), AnfĂŒhrungszeichen als umgekehrtes Komma (‛) und Gravisakzent (`). In der Rubrik „Was zum
?“ gibt es außerdem Sternchen (*), Komma (,) und linkes Gillemet («).

◊ Eine kleine Softwareentwickler-Weisheit: Es gibt keine garantierte „schnelle, einfache Lösung“. Viele einfache Lösungen sind in der Tat schnell, aber es gibt immer irgendeinen Blödsinn, der passieren könnte. Es gibt einen Grund, warum es die 90-90-Regel gibt!

↓ Ausnahmsweise kamen die großen Weltsprachen zu kurz und nicht die kleineren, meist weniger gut unterstĂŒtzten Sprachen. Unsere Standardverbesserungen, wie die Behandlung von Homoglyphen und die ICU-Normalisierung (aber nicht die aggressivere ICU-Faltung), sind standardmĂ€ĂŸig fĂŒr alle Sprachen/Wikis aktiviert, die keinen monolithischen Sprachanalysator haben.

☞ „Erfahrung ist das, was du bekommst, wenn du es brauchst.“ Jedes Mal, wenn ich etwas Seltsames oder Unerwartetes bei einer Sprache oder einem Analyzer entdecke, aktualisiere ich meine Skripte, um dieses potenzielle Problem in Zukunft hervorzuheben, damit ich mich nicht noch einmal mit genau demselben Problem herumschlagen muss.

** Bei der Suche ist eine Verbesserung von 1 % bei jeder Standardmessung – Abruf, Genauigkeit, Null-Ergebnis-Rate usw. – eine ziemlich große Sache. Die Suche ist in der Regel sehr gut, und normalerweise arbeiten wir nur an den RĂ€ndern, um sie zu verbessern. Die Ausnahme von dieser Regel ist im Bereich der Sprachanalyse das HinzufĂŒgen eines Stemmer, wo es vorher keinen gab. Im Englischen gibt es im Allgemeinen nicht viel grammatikalische Flexion – dog/dogs und hope/hopes/hoped/hoping sind so ziemlich alles! Das Beste/Schlechteste, was das Englische zu bieten hat, ist wahrscheinlich das höchst unregelmĂ€ĂŸige be, mit gerade mal acht Formen: be, being, been, am, is, are, was, were. In den romanischen Sprachen kann jedes Verb etwa 50 Konjugationen haben (z. B. französisch: manger, 48; italienisch: mangiĂ re, 58; spanisch: comer, 68), und im Finnischen mit seinem umfangreichen Kasussystem können Substantive Tausende von Formen haben, auch wenn die meisten nur selten verwendet werden. Wenn du all diese Formen mit einem Stemmer zusammenfĂŒhrst, kannst du die Anzahl der Ergebnisse fĂŒr viele Suchanfragen erheblich verbessern.

†† Regelbasierte Stemmer sind relativ leicht und billig und es gibt sie schon ewig. Sie enthalten zwar keine umfangreichen Ausnahmelisten (wie z.B. NiederlĂ€ndisch/Holland oder be/been/being/am/is/are/was/were), aber sie können fĂŒr viele Sprachen eine große Hilfe sein.

‡‡ Ein paar Beispiele: Ein Analysator hat alle Satzzeichen in Kommas umgewandelt und sie indiziert. (Satzzeichen werden normalerweise bei der Indizierung verworfen.) Das Ergebnis war, dass alle Satzzeichen in einer Abfrage mit allen Satzzeichen im gesamten Wiki ĂŒbereinstimmten. Ein anderer Stemmer ĂŒbersetzte kyrillisch in lateinisch, da die Sprache beides verwendete, aber aufgrund der Art und Weise, wie der Code geschrieben war, verwarf er versehentlich jeden Text, der nicht lateinisch oder kyrillisch war, anstatt ihn unverĂ€ndert durchzulassen. Ein anderer statistischer Stemmer hatte ein Problem mit Fremdwörtern und Zahlen und verwechselte am Ende Hunderte von zufĂ€lligen Wörtern und Namen miteinander. All diese Probleme konnten mit verschiedenen Patches am Code oder an der Konfiguration grĂ¶ĂŸtenteils oder vollstĂ€ndig behoben werden.

§§ Phonetische Algorithmen werden in der RechtschreibprĂŒfung eingesetzt – zum Beispiel, um Menschen dabei zu helfen, Genealogie richtig zu schreiben – und in der Genealogie, um Ă€hnlich klingende Namen zusammenzufassen – zum Beispiel, um die vielen Schreibweisen von Caitlin zu finden
 obwohl nur wenige eine Chance haben, KVIIIlyn zu finden – aber ich schweife ab.

‖‖ Anhand der Namen von Sprachen kann man nie sagen, wie eng sie miteinander verwandt sind. Es gibt einen alten Witz, der besagt, dass „eine Sprache ein Dialekt mit einer Armee und einer Marine ist“ – die Unterscheidung zwischen eng verwandten „Sprachen“ ist oft sozial oder politisch. Die so genannten „Dialekte“ des Chinesischen sind ungefĂ€hr so unterschiedlich wie die romanischen Sprachen, wĂ€hrend Bosnisch, Kroatisch und Serbisch ungefĂ€hr so unterschiedlich sind wie einige Dialekte des Englischen und im Allgemeinen gegenseitig verstĂ€ndlich sind.

¶¶ Sie können sich auch auf das Ranking auswirken und darauf, welcher spezifische Text fĂŒr ein bestimmtes Snippet ausgewĂ€hlt wird, das mit den Ergebnissen auf der Seite Spezial:Suche angezeigt wird. Ich schaue mir in der Regel die Änderungen im obersten Ergebnis an, obwohl das bei weniger hĂ€ufigen Wörtern und/oder kleineren Wikis aufgrund der Art und Weise, wie die Wortstatistiken berechnet werden, etwas unscharf sein kann. So haben die verschiedenen Suchabschnitte in unserem Suchcluster leicht unterschiedliche Wortstatistiken, je nachdem, welche Dokumente in den einzelnen Abschnitten gespeichert sind. In einigen seltenen FĂ€llen liegen die Ergebnisse der besten Dokumente so nah beieinander, dass winzige Unterschiede in den Wortstatistiken zwischen den Servern, die normalerweise einen Rundungsfehler in der Trefferliste darstellen wĂŒrden, ausreichen, um die endgĂŒltige Reihenfolge der Ergebnisse zu beeinflussen. Wenn du die Seite neu aufrufst, erhĂ€ltst du möglicherweise Ergebnisse von einem anderen Suchserver, wo diese winzigen Unterschiede dazu fĂŒhren, dass einige Top-5-Ergebnisse die PlĂ€tze tauschen. Das passiert am ehesten bei einem sehr seltenen Suchbegriff, der nur ein- oder zweimal in jedem von nur einem Dutzend oder weniger Dokumenten vorkommt, und zwar nicht im Titel eines dieser Dokumente. Ich schaue mir normalerweise keine anderen Ranking- oder Snippet-Änderungen an, es sei denn, es gibt einen Grund zu der Annahme, dass etwas seltsam schief gelaufen ist.

## Die WikiGnome sind großartig, und wir sollten sie alle mehr schĂ€tzen. Wenn ich in einem Blogbeitrag, einem Phabricator-Ticket oder einer E-Mail-Liste ein Beispiel fĂŒr etwas gebe, das im Wiki nicht richtig funktioniert, wird es oft von einem freundlichen WikiGnome korrigiert, was ich sehr schĂ€tze. Eines meiner Lieblingsbeispiele war vor Jahren bei einem völlig anderen Projekt: Wir haben auf Phabricator darĂŒber diskutiert (und geklagt), dass es in der englischen Wikipedia kein offensichtlich gutes Ergebnis fĂŒr die Suchanfrage „Marineflaggen“ gab, und
 um es kurz zu machenΔΔ
 Thryduulf hat eine gute BegriffsklĂ€rungsseite fĂŒr „Marineflagge“ erstellt, mit einem Redirect vom Plural und einem Link zu einer neuen Seite „Listen der Marineflaggen“. Jetzt gibt es ein offensichtlich gutes Ergebnis fĂŒr die Abfrage Marineflaggen!

ΔΔ Was natĂŒrlich gegen meine Natur ist.

◊◊ In meiner Anfangszeit bei der Stiftung habe ich mir Sorgen gemacht, dass diese Zahl ziemlich hoch ist – wie viele andere auch. 2015 untersuchte ich die Null-Ergebnis-Abfragen in vielen Wikipedias, um zu sehen, ob es offensichtliche Verbesserungsmöglichkeiten gibt (oder auch nur kleine – siehe Fußnote **). Ich habe einen Fehler in der Wikipedia Mobile App entdeckt, der behoben wurde, aber ich habe auch eine Menge MĂŒll gefunden, der wirklich keine Ergebnisse verdient. Es gibt Bots und Apps, die eine Menge automatisierter Abfragen durchfĂŒhren. Manchmal sind die Bots mehr als nur ein bisschen willkĂŒrlich – böser Programmierer! böse! – aber wir versuchen, uns nicht darum zu kĂŒmmern, solange es nicht missbrĂ€uchlich wird. Manche Apps scheinen nach etwas NĂŒtzlichem zu fischen, das sie ihren Nutzern zeigen können, aber es ist in Ordnung, wenn sie nichts finden. (Und im Allgemeinen ist es immer großartig, dass Menschen auf der kostenlosen Wissensplattform, die wir anbieten, aufbauen!) Programmierer machen einige Fehler, wie z. B. die buchstĂ€bliche Suche nach {searchTerms} anstelle der eigentlichen Suchbegriffe oder die wiederholte ÜbersĂ€uberung von Daten, so dass “search” (mit geraden AnfĂŒhrungszeichen) am Ende als quot search quot abgefragt wird (wahrscheinlich mit einer Zwischenform wie "search"). Und natĂŒrlich machen menschliche Suchende Fehler, indem sie das Falsche in die richtige Suchmaschine einfĂŒgen oder vielleicht das Richtige in die falsche Suchmaschine – wir bekommen viele Suchanfragen nach Kauderwelsch oder riesigen TextauszĂŒgen (d.h. 1.000-Wort-Anfragen, bevor wir eine LĂ€ngenbeschrĂ€nkung eingefĂŒhrt haben) oder sehr unenzyklopĂ€dische Anfragen, die eher fĂŒr eine allgemeine Web-Suchmaschine geeignet sind (wie Dating-RatschlĂ€ge, Pornografie usw.).↓↓

↓↓ Trotzdem gibt es immer noch Leute, die hĂ€ufig wiederholte Null-Suchanfragen fĂŒr potenzielle neue Artikel nutzen wollen. Das ist eine gute Idee – das dachte ich auch, als ich sie hatte. Aber in der Praxis gibt es, zumindest in der englischen Wikipedia, nicht wirklich viel davon. Ich habe mir das 2016 angeschaut und eine Menge Pornografie gefunden. Sehr viel Pornografie. Ich glaube, dass die WikiGnome in grĂ¶ĂŸeren Wikis schneller arbeiten, als jemand Null-Ergebnisse-Abfragen ĂŒberprĂŒfen kann, vor allem, wenn neue Weiterleitungen erstellt werden. Außerdem fĂŒhren viele Suchanfragen, die nicht zum richtigen Ort fĂŒhren, nicht wirklich zu null Ergebnissen – bei Millionen von Artikeln ist es schwer, nicht etwas zu finden.

☞☞ Der CJK-Analysator erzeugt Bigramme fĂŒr CJK-Text, was sich deutlich von der Standard-Tokenisierung unterscheidet, aber er verwendet in einem ersten Schritt den Standard-Tokenizer, der eine Menge Nicht-CJK-Text verarbeitet. Ein spĂ€terer cjk_bigram-Schritt parst Sequenzen von CJK-Token in ĂŒberlappende CJK-Bigramme um.

*** Ich habe auch gelernt, dass der ĂŒbliche Bindestrich, der auch als Minuszeichen fungiert (- U+002D „HYPHEN-MINUS“) und den ich fĂŒr den Bindestrich hielt, nicht der einzige Bindestrich ist
 es gibt auch ‐ (U+2010 „HYPHEN“). Da ich das typische „Bindestrich-Minus“ in meinen Berichten als „Bindestrich“ bezeichnet hatte, brauchte ich eine Weile, um zu erkennen, dass das Zeichen, das nur „Bindestrich“ genannt wird, etwas anderes ist. Lustige Zeiten!

††† Das grenzt an eine orthografische Verschwörungstheorie, aber die Umwandlung von Overdots in –h im Irischen hat mich dazu gebracht, darĂŒber nachzudenken, wie h in mehreren europĂ€ischen Sprachen verwendet wird, um anzuzeigen, dass etwas ein verwandter Laut ist, den man nicht anders schreiben kann. Im Englischen ist das hĂ€ufig der Fall, mit ch, sh, th und zh und manchmal auch mit kh – und vielleicht wh, je nach Akzent – und ph, auch wenn wir einfach nur ein f da stehen haben.‡‡‡ Das Französische verwendet ch und das Deutsche verwendet sch fĂŒr den Laut, den wir im Englischen als sh schreiben. Polnisch und Ungarisch verwenden auch z als Markierung fĂŒr „Àhnliche Laute“. Andere Digraphen§§§ sind ein bisschen kombinatorischer, zum Beispiel wenn dz mehr oder weniger wie d + z klingt.

‡‡‡ Es gibt etymologische GrĂŒnde – vor allem griechische – fĂŒr viele FĂ€lle von ph statt f, aber die englische Rechtschreibung ist so schrecklich, dass ich mir nicht sicher bin, ob es das wert war.

§§§ Es macht Spaß – und zwar nach der Definition eines Wort-Nerds von SpaßDigraphen, Trigraphen, Tetragraphen, Pentagraphen und Hexagraphen auf Wikipedia nachzuschlagen. Beachte, dass die meisten Beispiele fĂŒr Pentagraphen und alle Beispiele fĂŒr Hexagraphen irisch sind. Die irische Rechtschreibung ist eine der wenigen, die der englischen Rechtschreibung in puncto Furchtbarkeit orthografischer Tiefe in nichts nachsteht.‖‖‖

‖‖‖ [Die Tangente wird wild!] Ein interessanter Fall von asymmetrischer mehrsprachiger orthografischer Tiefe ist die Sprache Santa Cruz, die auch NatĂŒgu genannt wird, was auch Natqgu geschrieben wird. Ihre Rechtschreibung ist sehr „flach“, mit einem fest verankerten „ein Buchstabe, ein Laut“-Prinzip. In den 1990er Jahren beschloss man jedoch, die diakritischen Buchstaben, die vor Ort nur schwer zu tippen, zu veröffentlichen oder zu fotokopieren waren, abzuschaffen und durch einfachere Buchstaben zu ersetzen – nĂ€mlich die, die auf einer amerikanischen englischen Schreibmaschine geschrieben werden und fĂŒr nichts anderes verwendet wurden. Deshalb sind c, q, r, x und z in Natqgu Vokale – die Rechtschreibung ist also zwar flach, aber fĂŒr die meisten anderen Benutzer des lateinischen Alphabets ziemlich undurchsichtig. Siehe „Wenn c, q, r, x und z Vokale sind: Ein informeller Bericht ĂŒber die Natqgu-Rechtschreibung“ (~400K PDF) fĂŒr mehr!

¶¶¶ Es wĂ€re so schnell und einfach gewesen, nur einen Analysator fĂŒr alles zu haben – aber er wĂ€re in allem miserabel gewesen.

### Und ich bin immer auf der Suche nach Möglichkeiten, noch mehr zu tun. Im Laufe der Jahre haben wir Chinesisch, Esperanto, HebrĂ€isch, Khmer, Koreanisch, Mirandesisch, Nias, Polnisch, Serbisch und Kroatisch, Slowakisch und Ukrainisch erweitert und verbessert. Einige davon wurden durch die VerfĂŒgbarkeit von Open-Source-Software ermöglicht, andere durch Phabricator-Tickets, die Probleme meldeten, und wieder andere durch motivierte Freiwillige, die die Sprache sprechen. Wenn du eine gute Open-Source-Sprachverarbeitungssoftware kennst – vor allem Stemmer -, die in unseren Tech-Stack integriert werden könnte (ich bin ziemlich geschickt mit dem Hammer!), oder wenn du ein kleines Problem oder eine Aufgabe gefunden hast – die kleiner ist als Stemmer -, die wir möglicherweise lösen könnten, öffne ein Phab-Ticket und schreibe mir ein @. (Der Geist jedes Produktmanagers, mit dem ich je zusammengearbeitet habe, erinnert mich daran, dass ich nicht versprechen kann, dass wir dein Ticket noch im selben Halbjahrzehnt bearbeiten, in dem du es eröffnet hast, aber ich werde versuchen, was ich kann).

ΔΔΔ Wegen des ICU-Tokenizer-Fehlers werden sowohl chocĐŸlate als auch lateĐŸchoc in drei Token zerlegt: choc + ĐŸ + late. Die Tatsache, dass sie nicht in der richtigen Reihenfolge stehen, ist fĂŒr das Matching normalerweise weniger wichtig als die Tatsache, dass sie sehr nah beieinander liegen. Die Tatsache, dass zwischen ihnen keine Leerzeichen stehen, spielt keine Rolle.

◊◊◊ Das ist ein großer Schritt nach vorn! Vor dem Auspacken war es gar nicht möglich, Verbesserungen in allen Sprachen zusammen vorzunehmen.

↓↓↓ Ein weiteres meiner persönlichen Problem-Auas ist die Tatsache, dass ich bei der Suche nach NASA nicht N.A.S.A. finde, und umgekehrt. Und ich möchte wirklich, dass alle (vernĂŒnftigen – siehe Fußnote Î”) Varianten von HawaiÊ»i miteinander ĂŒbereinstimmen. Ich wĂŒnschte, ich könnte everything, everywhere, all at once in Ordnung bringen!

☞☞☞ Gefallen dir meine Fußnoten-Symbole? Hasst du sie? Hey, ich versuche nur, die Klassiker wieder aufleben zu lassen!

No comments

Comments are closed automatically after 21 days.