13.11.09

Talking about SRX in LT during LTC

Jarek Lipski and me had a talk on using the SRX segmentation standard for LanguageTool during LTC 2009. We were asked a couple of times where the file is available, so I'm putting the link to our free SRX file here - it's a current version from our CVS, and at the time of writing it supports Polish, English, Dutch, Romanian, Russian, Icelandic, Slovak and Slovenian. It's on LGPL, so you can freely reuse it. There are also some SRX segmentation hints on our LanguageTool wiki. Especially important is the fact that there is a free (as speech) editor, Ratel, which helps to write the rules (and testing them).

The draft version of the paper is available online here. In case you want to cite it, here is the complete record:

Marcin Miłkowski, Jarosław Lipski, 2009. Using SRX standard for sentence segmentation in LanguageTool, in: Human Language Technologies as a Challenge for Computer Science and Linguistics, ed. by Zygmunt Vetulani, Poznań: Wydawnictwo Poznańskie, Fundacja Uniwersytetu im. A. Mickiewicza, p. 556-560.

1.11.09

LanguageTool 1.0.0

Dziś ukazała się najnowsza wersja korektora LanguageTool z okrągłym numerem 1.0.0!

Podstawowe zmiany:

  • obsługa języka duńskiego, katalońskiego i galisyjskiego;
  • nowe reguły i poprawki w słownikach dla języka duńskiego, francuskiego, włoskiego, polskiego, hiszpańskiego, szwedzkiego i rosyjskiego;
  • język polski ma ponad 1000 reguł;
  • poprawione różnego rodzaju usterki.

Uwaga. Ta wersja działa wyłącznie w OpenOffice.org w wersji 3.0.1 lub nowszej! Przed instalacją programu OpenOffice.org 3.0.1 należy usunąć wszystkie wcześniejsze wersje LanguageTool zainstalowane w OpenOffice.org.

Instalacja:

W programie OpenOffice.org 3.0.1 lub nowszym
  • Metoda prosta
    Dwukrotnie kliknij pobrany plik LanguageTool-1.0.0.oxt. Jeśli w systemie jest zarejestrowane rozszerzenie .oxt (robią to aktualne wersje OpenOffice.org), nastąpi uruchomienie instalatora.
  • Metoda tradycyjna
Kliknij polecenie Narzędzia > Menedżer rozszerzeń > Dodaj, a następnie wybierz plik LanguageTool-1.0.0.oxt. Zamknij pakiet (łącznie z modułem szybkiego uruchamiania).

Po ponownym otwarciu OpenOffice.org będzie możliwe automatyczne sprawdzanie tekstu. Jako test wpisz zdanie: „To zdanie zdanie jest z błędem”.

Bez programu OpenOffice.org
  • Rozpakuj archiwum LanguageTool-1.0.0.oxt (jest to plik w formacie .zip) i uruchom plik LanguageToolGui.jar, klikając go dwukrotnie. Jeśli na danym komputerze nie skonfigurowano skojarzenia dla plików *.jar, uruchom program z wiersza poleceń za pomocą polecenia java -jar LanguageToolGUI.jar. Plik LanguageTool.jar jest natomiast korektorem działającym z poziomu wiersza poleceń.
  • Rozpakuj znajdujący się w archiwum plik standalone-libs.zip do tego samego katalogu, do którego rozpakowano pliki z archiwum.

W razie problemów

  1. Należy upewnić się, czy w systemie zainstalowana jest Java w wersji co najmniej 1.5. Środowisko GIJ ma błędy uniemożliwiające użytkowanie LT; należy korzystać z Javy w wersji IcedTea lub firmy Sun. Zalecana jest Java 1.6.
  2. Ta wersja środowiska Java musi być widoczna dla OpenOffice.org (Narzędzia > Opcje > Java).
  3. Nazwa użytkownika w systemie Windows nie może zawierać polskich liter, jeśli pakiet OpenOffice.org jest starszy niż 3.1.
  4. W systemie Ubuntu konieczna jest instalacja pakietu openoffice.org-java-common, gdyż OpenOffice jest domyślnie instalowany bez bibliotek obsługujących Javę.

23.9.09

morfologik-stemming 1.2.2

Ponieważ poprzednia licencja była wersją BSD z klauzulą na temat patentów, która nie miała prawnego sensu, wróciliśmy do czystej licencji BSD. Większych poza tym zmian nie ma.

Pliki – jak zwykle – na stronie projektu.

11.8.09

LanguageTool w Firefoksie

Od niedawna mamy dwie możliwości uruchomienia LanguageTool do sprawdzania tekstu bezpośrednio w naszej ulubionej przeglądarce.

Sposób pierwszy

Od dawna można uruchomić program bezpośrednio (mechanizm Java Web Start, proszę nie przejmować się komunikatem, że przeterminował się klucz szyfrujący, po prostu nie mam czasu na poklikanie na stronie Thawte). Potem chowamy LanguageTool do paska zadań (Plik > Schowaj do paska zadań) i z powrotem przeglądarce możemy redagować tekst. Kopiujemy napisany tekst do schowka i klikamy ikonę LanguageTool. Pojawi się powiększone okienko, od razu ze sprawdzonym tekstem. Niestety, poprawek nie można bezpośrednio wprowadzić.

Ale za to można zmienić konfigurację reguł.

Sposób drugi

A jeśli chcemy bezpośrednio stosować poprawki proponowane przez korektor? Jest na to sposób. Najpierw trzeba zainstalować Ubiquity, swoiste rozszerzenie do Firefoksa. Umożliwia ono obsługę przeglądarki z klawiatury: wystarczy kliknąć [Ctrl]+[Spacja], a pojawi się specjalne okno poleceń. Domyślnie są różne zapytania do wyszukiwarek itd. Siłą Ubiquity jest możliwość dodawania własnych poleceń.
Żeby mieć LanguageTool, wchodzimy na stronę LangBota, który w Ubiquity pozwala zainstalować magiczne polecenie gramatyka. Po zainstalowaniu tego wszystkiego procedura jest banalna: zaznaczamy tekst, [Ctrl]+[Spacja], „gramatyka”. LangBot automatycznie wykrywa język tekstu i sprawdza tekst z domyślnymi ustawieniami LanguageToola (nie można zmienić tych ustawień indywidualnie). W okienku pokażą się podkreślone na zielono błędy, które można poprawiać myszką (kliknięcie otwiera dodatkowe okienko). Niestety, z powodu pewnych niedociągnięć w Ubiquity nie działa jeszcze bezpośrednie redagowanie zaznaczonego tekstu. Ale za to poprawki są bezpośrednio wstawiane do tekstu (uwaga: gubi się formatowanie).

8.8.09

morfologik-stemming 1.2.1

Wczoraj wydaliśmy nową wersję biblioteki morfologik-stemming (1.2). W nowej wersji zupełnie zmieniony został interfejs obsługi słowników fsa, oczywiście na wygodniejszy, a przy tym szybkość działania jest parokrotnie wyższa. Wszystkie zmiany opisuje oczywiście JavaDoc.

Pliki biblioteki do pobrania na stronie projektu. Biblioteka w tej wersji zostanie włączona do przygotowywanej wersji 1.0 korektora LanguageTool.

POPRAWKA. Ponieważ zapomnieliśmy o drobiazgu, co uniemożliwiało użycie prostego narzędzia do analizy składniowej z wiersza poleceń, szybko wydaliśmy poprawkę. Narzędzia można używać tak:


#java -jar morfologik-stemming-1.2.1.jar plstem [opcje]


Po wywołaniu bez opcji samo powie, jak się je obsługuje.

2.8.09

Słownik poprawnej polszczyzny w sieci

Zupełnie znienacka i cichaczem Wydawnictwo Szkolne PWN wprowadziło do jednego ze swych serwisów („Prawo dla szkół”) dostęp do słownika poprawnej polszczyzny, słownika nazw własnych i słownika ortograficznego. Dla uważnych czytelników jest jasne, że są to publikacje WSzPWN, które kiedyś przejęło publikacje słownikowe wydawnictwa Park. Nie są to więc wielkie słowniki Wydawnictwa Naukowego PWN, ale i tak to jedyne tego rodzaju źródła w Internecie (oczywiście, nie mówię o słowniku ortograficznym, bo takich w sieci jest na pęczki, choć bodaj wszystkie są prostymi przedrukami wersji papierowych bez sensownego algorytmu generowania podpowiedzi – z wyjątkiem mojego słownika ortograficznego).

Nie jest dla mnie jasne, czy słowniki – w tym ten poprawnej polszczyzny – pozostaną w sieci na dłużej, czy też dostęp do niego zostanie zamknięty tak jak do całego serwisu „Prawo dla szkół”, 30 września. Na razie jednak można go używać.

14.7.09

Evaluating Grammar Checkers

As a developer of LanguageTool, I would love to see clear guidelines for evaluating grammar checkers. Some discussions of flaws in grammar checkers - such as the influential analysis by Daniel Kies - rely on quite controversial principles and make assumptions that seem unwarranted at times.

Kies used analysis of a corpus of 3000 college essays in English to evaluate the checkers. Now, the analysis contained top 20 errors, ordered by frequency. Of course, frequency of the error seems to be an important factor but what about the severity of error? Let me explain. I really doubt that "No comma after introductory element" is the top error in college essays if they're written on a computer keyboard. The most common error is to have multiple whitespace or formatting with whitespace. Of course, this is not strictly a grammar error, but punctuation is also quite far from syntactic principles of the language, and multiple whitespace is also a punctuation problem. If they had manually written essays, then they don't have a chance to count whitespace errors as they don't seem to occur in handwriting. So a lot depends on the medium of the corpus: the space of possible errors is biased by the representation of the linguistic content. In a corpus of OCRed books you would expect more errors that are due to incorrect recognition of badly printed characters, for example.

Another problem is that "No comma after introductory element" is actually quite controversial. Modern writers don't seem to care about the comma, so using this rule as a baseline is not a reliable way to evaluate the checkers. For example, I don't want to implement this rule and make it turned on by default exactly for this reason: most people don't think a missing comma after an introductory element is actually a severe problem. If you want to evaluate grammar checkers, you'd better ignore such problems and focus on things which are uncontroversially severe, such as confusing "it's" and "its". Implementing a rule for detecting a phrase at a sentence start that is not a subject of the sentence is not exactly rocket science, but I don't think the rule is really so important. Also, if you see some error really often in a corpus, then it may mean that it's no longer an error but rather an emerging standard usage.

The second error on the list is "vague pronoun reference". This is actually much harder to implement. In computational linguistics, we still don’t have a good solution for anaphora resolution: a failure of anaphora resolution would mean that there is a vague pronoun reference. But as anaphora resolution is actually quite hard (especially for such languages as English, which is much harder than Slavonic or Romance languages with their richer morphology that contains gender information), developers may decide not to focus on it but implement things which are much easier. The question is whether you want your grammar checker to complain at Kant's prose (Kant notoriously used vague pronouns) or you want it to find simpler typos etc. If you think that computer-aided proofreading tools shouldn't deal with the deep structure of language and actually help edit the text, then you will not count this error as a good way to evaluate grammar checkers.

Another problem with the list used for evaluation is that it's based on college essays. College students don't tend to make mistakes typical for people that use English as their second language (I make different mistakes than native speakers, for example). As more people use English as their second language than there are native speakers of English, you would expect the evaluation to be based at least not only on native users' problems. It seems obvious that a Chinese or Polish student needs the computer tools to correct her English much more than a native speaker.

If you use a biased list of errors, you can get biased results. I think it would be interesting to see the evaluation of grammar checkers based on different corpora, as all specialized corpora are biased this way or another. But as long as you try to balance it, you might get better insight, both into the state of the field of grammar checking (or computer-aided proofreading) and into the errors as stable patterns of incorrect usage of language. So a more exhaustive analysis could reuse:

  • Language learners error corpora (especially ESL)
  • Corpora of texts marked by professional proofreaders
  • Automatically generated corpora from Wikipedia
Any ideas what to use as baseline measures for evaluation? What kinds of data would be needed?

It's also worth noting that it's much easier to evaluate grammar checkers in terms of their precision by counting false positives among all alarms raised by them. It is the recall, or the real number of true positives, that remains really hard to evaluate.

14.6.09

LanguageTool i cyzelowanie stylu

Narzędzie korektorskie oczywiście nie napisze poematu trzynastozgłoskowcem, ale może się przydać przy mechanicznym poprawianiu tekstu. Nawet na poziomie stylistycznym. LanguageTool ma kilka takich reguł, ale są one domyślnie wyłączone, bo są nieco nadwrażliwe. W okienku Opcje można je znaleźć w kategorii „Błędy różne”. Do tej pory chodziło głównie o monotonię stylistyczną - czyli o regułę, która wykrywała powtarzanie się tego samego wyrazu w zdaniu. Szkolna stylistyka mówi, że trzeba tego unikać, ale oczywiście jest tutaj wiele wyjątków. Na przykład nikt nie zakaże kilkakrotnie użyć słówka „nie” do wyrażenia negacji. Albo użycia wyrażenia „oko za oko”... Nie wszystko to daje się łatwo mechanicznie ująć wyjątkami, więc czasem LanguageTool zbyt dużo podkreśla. Ale czasem udaje się znaleźć naprawdę dziwaczne powtórzenia podczas pisania tekstu.

Dziś dodałem kolejną taką zaawansowaną regułę: wykrywa ona rymujące się sąsiednie wyrazy (np. w tytule „Problemy organizacji administracji”). Czasem te rymy przeszłyby niezauważone (np. „sześćdziesięciu pięciu”), a czasem brzmią fatalnie („wartości ludzkości”). Kiedy jednak redaguję tekst, coś takiego może się przydać; komiczne niezamierzone rymy często działają na czytelnika niemal podprogowo i utrudniają odbiór tekstu. Dlatego też i ta reguła jest domyślnie wyłączona.