Lttoolbox-java (français)
Contents
Qu'est ce que lttoolbox-java
lttoolbox-java est un portage Java de la totalité du système d'exécution Apertium, incluant à la fois lttoolbox et apertium.
Fonctions lttoolbox
lttoolbox peut faire les choses suivantes
- Compiler : fabriquer des fichiers binaires à partir des fichiers .dix (lt-comp),
- Traiter : analyser ou générer du texte (lt-proc) et
- Étendre : développer un fichier dictionnaire .dix (lt-expand).
Le portage Java de lttoolbox est aussi capable de
- Composants (expérimental)
- Flag diacritics (très expérimental)
- Valider des fichiers .dix
Fonctions d'exécution apertium
Le portage Java implémente les fonctions typiques utilisées par Apertium pendant l'exécution.
- Lire les fichiers .mode et exécuter les étapes qu'ils contiennent
- Exécuter le tagger
- Exécuter les étapes de transfert (toutes les trois)
Le portage Java a besoin des binaires C++ pour préparer/développer une paire de langue, par exemple pour compiler les fichiers de transfert et entraîner le tagger.
Le portage Java de lttoolbox est aussi capable de
- Générer le bytecode for transfer et l'exécuter. Le bytecode s'exécute typiquement 10 fois plus vite que la version C++.
Pourquoi
Un "portage Java" d'Apertium permet l'utilisation sur
- Windows,
- J2ME/téléphones Android,
- pages web (applets),
- application de bureau,
- applications serveur Java.
Les deux derniers points sont capitaux comme, par exemple un plugin OpenOffice.org devrait être indépendant de la plate-forme pour être maintenable.
On n'a vu personne implanter Apertium sur une application de bureau. Actuellement Apertium est utilisable dans un sous répertoire local mais l'installation n'est pas triviale pour l'utilisateur final.
Avoir une version empaquetée facile à utiliser d'Apertium prête pour supporter les machines de traduction dans un programme plus large serait très sympa. Idéalement ça pourrait être un fichier JAR contenant Apertium, dépendant seulement de JRE et un fichier JAR additionnel par paire de langue.
Une autre approche d'"implantation" est d'utiliser un client stub(?) pour l'un de nos services Apertium, mais il peut y avoir des raisons qui font préférer d'avoir les choses installées localement (on n'a pas besoin de les répéter ici).
Caractéristiques
- Compatibilité binaire avec lttoolbox. lttoolbox-java est capable de lire et d'écrire les fichiers binaires lttoolbox et génère exactement la même sortie
- Il y une suite de tests compréhensible qui teste à la fois lttoolbox (C++) et lttoolbox-java.
Installation
Pré-requis :
- java-runtime
- apache-ant (pour compilation)
Sous Arch Linux, vous pouvez installer les pré-requis avec
pacman -S openjdk6 apache-ant
Sous Debian/Ubuntu:
sudo apt-get install ant ant-optional # quoi d'autre ??
Téléchargement, compilation, installation
Téléchargez la version la plus récente ou récupérez-la depuis SVN :
svn co https://apertium.svn.sourceforge.net/svnroot/apertium/trunk/lttoolbox-java
Utilisez Netbeans ou Unix, ou n'importe quoi qui vous va le mieux :
sh autogen.sh make sudo make install
Vous pouvez aussi construire et installer en utilisant Maven 2 (http://maven.apache.org), en tapant :
mvn install -DskipTests
Voir aussi le fichier README
Utilisation
$ java -jar dist/lttoolbox.jar lttoolbox: est une boite à outils pour le traitement lexical, l'analyse morphologique et la génération de mots UTILISATION : java -jar dist/lttoolbox.jar [tache] Exemples: java -jar dist/lttoolbox.jar lt-expand dictionnaire.dix étend un dictionnaire java -jar dist/lttoolbox.jar lt-comp lr dic.dix dic.bin compile un dictionnaire java -jar dist/lttoolbox.jar lt-proc dic.bin analyse morphologique
ou, en utilisant des scripts shell :
$ lt-comp-j v3.2j: construit un transducteur de lettres depuis un dictionnaire UTILISATION : LTComp lr | rl fichier_dictionnaire fichier_de_sortie [fichier_acx] Modes: lr: compilation de gauche à droite rl: compilation de droite à gauche
$ lt-proc-j LTProc: traite un flux avec un transducteur de lettres UTILISATION : LTProc [-c] [-a|-g|-n|-d|-b|-p|-s|-t] fichier_fst [fichier_d'entrée [fichier_de_sortie]] Options: -a: analyse morphologique (comportement par défaut) -c: utiliser le cas littéral des caractères entrant -e: analyse morphologique, avec analyse des composants sur les mots inconnus -f: trouve les drapeaux (expérimental) -g: génération morphologique -n: génération morphologique sans marquage des mots inconnus -d: génération morphologique avec tous les trucs -t: génération morphologique, mais en gardant les parties de discours -p: post-génération -s: annotation SAO système de traitement de l'entrée -t: appliquer le dictionnaire de translittération -z: vider les sorties sur le caractère nul -v: version -D: déboguage; envoyer les diagnostics sur stderr -h: montrer cette aide
$ lt-expand-j v3.2j: étend le contenu d'un fichier dictionnaire UTILISATION : LTExpand fichier_dictionnaire [fichier_de_sortie]
$ lt-validate-j v3.2j: valide un fichier XML par rapport à un schéma UTILISATION : LTValidate -dix dictionnaire.xml LTValidate -acx dictionnaire.acx
Exemples
Utilisation de la nouvelle fonctionnalité de composition :
echo "lambakjöti" | java -jar dist/lttoolbox.jar lt-proc -e /home/j/esperanto/apertium/apertium-is-en/is.bin
^lambakjöti/lamb<n><nt><pl><gen><ind>+kjöt<n><nt><sg><dat><ind>$
Problèmes d'encodage
Essayez -Dfile.encoding=UTF-8, comme
echo "lambakjöti" | java -Dfile.encoding=UTF-8 -jar dist/lttoolbox.jar lt-proc -e /home/j/esperanto/apertium/apertium-is-en/is.bin
^lambakjöti/lamb<n><nt><pl><gen><ind>+kjöt<n><nt><sg><dat><ind>$
Utilisateurs de Mac
Vous avez besoin du JDK1.6. Essayez
/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Commands/java -jar dist/lttoolbox.jar
Utilisation Windows
Par défaut, la console Windows utilise l'UTF-16, tandis que les données apertium sont encodées avec UTF-8. Cette commande commute la boite dos sur UTF-8:
chcp 65001
Note : vous avez aussi besoin d'utiliser une fonte capable de supporter Unicode pour la console Windows, comme Lucida Console (Properties -> Font).
Également, n'oubliez pas de positionner les drapeaux d'exécution : -Xms64m -Xmx800 -Dfile.encoding=UTF-8
Raisons du portage Java
- Il existe plusieurs périphériques (téléphones mobiles, par exemple) qui peuvent exécuter des programmes assez compliqués, mais seulement s'ils sont écrits en Java. lttoolbox est la première étape pour avoir Apertium qui s'exécute sur ces périphériques.
- portage Windows. Ce ne sera pas aussi puissant que les systèmes basés Unix, mais ça existera
- Apertium sera la premier système de traduction automatique *du monde* qui pourra être montré à partir d'applets Java
- Le transfert en bytecode promet un gain de vitesse d'un facteur 4 - comparé à ce qu'on utilise maintenant (XML interprété). Et l'utilisation de l'unité centrale pour le transfert est dominante lorsqu'on traite de grandes quantités de texte
Performance du portage Java
Compatibilité et performance peuvent être testées en appelant test_java_and_c.sh dans testdata/regression.
Processeur simple-corps (Jimmy O'Regan)
java version "1.6.0_18" OpenJDK Runtime Environment (IcedTea6 1.8) (6b18~pre4-1ubuntu1) OpenJDK Client VM (build 16.0-b13, mixed mode, sharing) C analysis is... 0.59sec OK Java analysis is... 1.15sec OK C generator -g is ... 0.54sec OK Java generator -g is ... 1.13sec OK C generator -d is ... 0.56sec OK Java generator -d is ... 1.12sec OK C generator -n is ... 0.52sec OK Java generator -n is ... 1.12sec OK C postgenerator -p is ... 0.07sec OK Java postgenerator -p is ... 0.33sec OK All tests passed
Processeur double-corps (Jacob)
Java HotSpot(TM) Client VM (build 1.6.0-beta2-b86, mixed mode, sharing) C analysis is... 0.39sec OK Java analysis is... 0.66sec OK C generator -g is ... 0.32sec OK Java generator -g is ... 0.62sec OK C generator -d is ... 0.33sec OK Java generator -d is ... 0.58sec OK C generator -n is ... 0.32sec OK Java generator -n is ... 0.64sec OK C postgenerator -p is ... 0.03sec OK Java postgenerator -p is ... 0.20sec OK All tests passed
Comme vous pouvez voir, la version est actuellement (avril 2010) plus lente d'un facteur 2 que la version C. Il y a des manières d'y remédier (en utilisant des collection de classes de type simples), mais cela n'a pas été implémenté, et personne ne l'a demandé.
Ça donne déjà de bonnes performances, toutefois, et Apertium exécuté en Java est très rapide, comparé aux autres systèmes de traduction automatiques. La surcharge en utilisant la version Java au lieu de la version C est négligeable, puisque le transfert est de toutes façon gros consommateur de ressources.
Les tests ci-dessus comparent les fonctions de base lttoolbox. Comme le transfert Java est plus rapide, le résultat du test de performance en pur Java et pur C++ sont comparables (et principalement en faveur de Java). On peut faire un hybride qui bat les performances des deux systèmes.
Défauts connus
Il y a actuellement (janvier 2010) des problèmes pour compiler quelques constructions très rares et étranges (?) (testdata/strange.dix). Vous pouvez utiliser la version C pour les compiler, et les fichiers binaires fonctionneront bien en utilisant lttoolbox-java.
Remerciements
- Nic Cottrell a contribué à la version initiale du portage Java de lttoolbox.
- Pendant le Google Summer of Code de 2009 Raphaël et Sergio ont travaillé dessus, mais le traitement n'a toujours pas marché (la compilation et l'expansion ont marché)
- En novembre 2009 Jacob Nordfalk a fini le travail et optimisé certaines parties
- Durant le Google Summer of Code de 2010 Jacob a supervisé un port complet de l'exécution en Java d'Apertium (c'est à dire pas seulement lttoolbox) réalisé par Stephen Tigner.