
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

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

[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!

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!

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.

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!

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â

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).

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:
- 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.
- Der Thai-Tokenizer zerlegt wirklich lange Textzeilen in 1024-Zeichen-StĂŒcke, selbst wenn dabei ein Wort in zwei HĂ€lften geteilt wird!
- 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.

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 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!