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.

22.5.09

LanguageTool 0.9.9

Dziś ukazała się nowa wersja korektora LanguageTool 0.9.9. Podstawowe zmiany:

  • usunięto problem z regułami obsługującymi akapity (powodował wyświetlanie okienka z NullPointerException);
  • obsługa języka islandzkiego;
  • więcej reguł angielskich, polskich, niderlandzkich i rumuńskich;
  • poprawki w regułach rosyjskich;
  • więcej fałszywych przyjaciół tłumacza w parze angielski-polski;
  • usunięto błędy w regułach parowania nawiasów i cudzysłowów;
  • wprowadzono segmentację zdaniową z wykorzystaniem formatu segmentacji SRX.

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-0.9.9.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-0.9.9.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-0.9.9.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ę.

26.4.09

LanguageTool 0.9.8

Dziś ukazała się nowa wersja korektora LanguageTool 0.9.8. Podstawowe zmiany:

  • usunięcie denerwującego problemu występującego w komputerach z systemem MacOS;
  • zdecydowanie więcej reguł dla języka rumuńskiego (były 3, jest 160) i syntetyzator morfologiczny dla tegoż języka;
  • więcej reguł dla włoskiego (było 5, jest 77);
  • pierwsze reguły dla słowackiego;
  • poprawki w obsłudze języka angielskiego i polskiego;
  • więcej opcji w wypadku używania LanguageTool z poziomu wiersza poleceń;
  • poprawki wielu drobnych błędów.
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-0.9.8.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-0.9.8.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-0.9.8.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.
  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 (błąd OpenOffice.org od wersji 2.3; będzie poprawiony w wersji 3.1).

22.4.09

Bootstrapping the rules for LanguageTool

This post is related to many languages, so I'm posting in English.

Recently, during PALC 2009, I had a talk on unsupervised generation of rules for LanguageTool. The idea is when you have an error corpus (and you can create one based on Wikipedia revision history, by the way, here's a draft of my paper on creating the error corpus from Wikipedia), you can use transformation-based learning techniques to create rules that may be used to boostrap rule creation for new languages in LanguageTool.

Of course, what I have right now, are only quick hacks and script prototypes, but as you can see in my presentation, I'm planning to make the process a bit easier to use. First of all, the extraction of the error corpus from Wikipedia revision history can be fully ported to Java (I will add filters to remove synonym-for-synonym revisions but some of the most frequent changes are used to adapt the text to some editorial conventions, so they would have to be filtered manually). Currently, I'm using two packages for TBL machine-learning: muTBL and fnTBL (both free but not muTBL is not open-source). muTBL is in Prolog, and it has serious memory limitation - but it allows for iterative, incremental learning of rules on the stack. fnTBL is C++ and can process much larger corpora but crashes a lot, and its newest version (1.2) didn't work for me at all. Fortunately, there is a Java implementation of the TBL toolkit that works in GATE, and it's GPL, so it would allow to adapt it for our needs.

With these tools, it should be fairly easy to add some relevant rules for new languages even for people with limited linguistic competence. Yet, some of the rules require using morphosyntactic lexicons, which aren't so easy to create or find.

Of course, the use of TBL is not limited to bootstrapping new rules for new languages - TBL learning can enhance existing rules quite significantly, as I observed. The process is not very time-consuming even with dirty hacks, so I'm quite optimistic about the practical application.

So if anyone wants to help with porting my scripts to Java, just let me know - this way, we'll have the tool a bit faster :)

8.4.09

Łagodne wprowadzenie do redagowania reguł

W ostatnią niedzielę, 5 kwietnia 2009, na Studenckim Forum Badań nad Językiem prowadziłem warsztaty dotyczące tworzenia reguł dla LanguageToola. Przy okazji parę powiedziałem parę słów o architekturze i przetwarzaniu powierzchniowym, bo LT to de facto nie tylko korektor, ale w ogóle system przetwarzania powierzchniowego języka naturalnego. Mam nadzieję, że moja prezentacja bez komentarza werbalnego też się komuś przyda.

18.3.09

morfologik-stemming 1.1.4

Dziś wydaliśmy nową wersję biblioteki morfologik-stemming. Okazało się, że programu fsa można używać do kodowania słowników w UTF-8, choć autor przewidywał tylko kodowanie 8-bitowe. W bibliotece jednak nie do końca dobrze było to zrealizowane, więc poprawiliśmy parę usterek i jest już gotowe. Dzięki temu w LanguageTool będzie wkrótce bardziej bezpośrednia obsługa słownika języka rumuńskiego.

Oczywiście, użytkownicy LanguageTool nie mają nic do aktualizacji - to jest tylko jedna z bibliotek wykorzystywanych przez program.

5.3.09

LanguageTool 0.9.7

Dziś ukazała się nowa wersja korektora LanguageTool 0.9.7. W tym wydaniu usunęliśmy kilka usterek, m.in. usterkę bardzo denerwującą dla niemieckich użytkowników i błędy w obsłudze menu kontekstowego dla języka francuskiego. Są też kosmetyczne poprawki reguł polskich, rosyjskich i holenderskich oraz obsługa nowego języka (na razie w postaci zalążkowej) – a mianowicie rumuńskiego.


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
    • Metoda prosta
      Dwukrotnie kliknij pobrany plik LanguageTool-0.9.7.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-0.9.7.oxt (bez rozpakowywania). 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-0.9.7.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.
  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 (błąd OpenOffice.org od wersji 2.3; będzie poprawiony dopiero w wersji 3.1).

morfologik-stemming 1.1.3

Ponieważ okazało się, że w bibliotece morfologik-stemming był drobny błąd, który ujawniał się czasem przy użytkowania LanguageTool w OpenOffice.org, trzeba było go naprawić i udostępnić nową wersję biblioteki. Na stronie projektu można pobrać najnowszą dystrybucję.

22.1.09

LanguageTool 0.9.6

Dziś ukazała się nowa wersja korektora LanguageTool 0.9.6. Najważniejsze zmiany:
  • nowe okno dialogowe do sprawdzania błędów - całkowita integracja z OpenOffice.org;
  • bardzo dużo poprawek błędów w regułach polskich, holenderskich i angielskich;
  • polskich reguł jest 900 (w postaci deklaracji w pliku) i kilka specjalnych napisanych w Javie;
  • usunąłem kilkanaście różnego rodzaju usterek i błędów w kodzie;
  • zwiększone możliwości dezambiguatora regułowego;
  • możliwość stosowania unifikacji atrybutów w regułach błędów i dezambiguacji.
Każdy lubi obrazki, a więc... Tak wygląda nowe okno dialogowe:

Jak widać, nie wszystko jeszcze jest do końca dopracowane (tłumaczenia polskie będą niestety dopiero w wersji 3.1), ale za to działa poprawnie.

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
    • Metoda prosta
      Dwukrotnie kliknij pobrany plik LanguageTool-0.9.6.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-0.9.6.oxt (bez rozpakowywania). 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-0.9.6.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.
  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 (błąd OpenOffice.org od wersji 2.3; będzie poprawiony dopiero w wersji 3.2).