• [^] # Re: un couple en peril ...

    Posté par . En réponse au journal un couple en peril .... Évalué à 4.

    Hum, moi je suis partisan de la suite de logiciel suivants :

    Canna + Kinput2

    Canna étant un serveur (dictionnaire), et kinput2 permettant de faire la liaison entre XIM (X Input Method) et le dictionnaire (canna en l'occurrence). Le but étant de taper en romaji, ce qui est retranscrit en kana (à la frappe), puis il permet de choisir les kanji appropriés correspondant au kana tapés. La méthode est simple et relativement efficace. À noter que je n'ai jamais essayé les claviers qui permettent de taper directement les kana... ça doit etre rudement pratique ça.

    Pour installer tout ça, il suffit d'installer les paquets, et normalement canna sera lancé automatiquement comme démon au démarrage de la machine. Une fois X lancé, il suffit de charger kinput2, et X est nihongo-aware ^^

    Néanmoins il faut préciser à l'application utilisée qu'il faut utiliser le japonais ! C'est-à-dire qu'il faut utiliser un wrapper de le style de celui donné ci-dessous, ou bien avoir un environnement utilisateur utilisant une locale et un charset Japonais. Il faut néanmoins avoir certaines variables d'environnements exportées, et surtout : XMODIFIERS.

    --- CUT HERE ---
    #! /bin/sh
    # ~/bin/nihongo.sh

    LANG=fr
    LANGUAGE=fr
    LC_ALL=ja_JP.UTF-8
    #LC_ALL=ja_JP.eucJP
    #LC_ALL=ja_JP.SJIS
    XMODIFIERS="@im=kinput2"
    #GTK_IM_MODULE=cedilla
    GTK_IM_MODULE=XIM

    export LANG LANGUAGE LC_ALL XMODIFIERS GTK_IM_MODULE

    exec $*
    --- CUT HERE ---

    Nota: ce script peut certainement être amélioré. Le charset SJIS est le charset made in microsoft, utilisé majoritairement donc. eucJP est le charset généralement utilisé par les stations Unix. UTF-8 est ZE Charset que je recommande.

    En ce qui concerne GTK_IM_MODULE, c'est pour définir la mathode d'entrée (IM) qui sera sélectionnée dans l'application GTK+2 correspondante. "cedilla" désigne le français, tandis que "XIM" sera pour la méthode d'entrée X, donc dans notre cas : le japonais. À noter que toute cette méthode est aussi valable pour le Corréen et le Chinois, il suffit de changer de serveur/dictionnaire (canna=japonais). Je ne saurais par contre vous dire ce qu'il faut utiliser.

    Nota: exporter GTK_IM_MODULE me permet de lancer Galeon, Gedit, etc. et de les utiliser par défaut en français. Ensuite un clic-droit dans une zone de texte me permet de choisir l'IM que je veux, et si je veux taper du japonais : je choisis Méthode de saisie X (XIM). Pour les plus aventureux, vous pouvez retirer les méthodes que vous ne voulez pas dans /etc/gtk-2.0/gtk.immodules ce qui permet de ne garder que "cedilla" & "XIM" par exemple.

    ATTENTION ! Je ne conseille pas d'ajouter XMODIFIERS dans n'importe quel script type ~/.bash_profile ou ~/.profile ! Car ceci impactera tous le compte utilisateur (et encore si c'est lancé dans /etc/profile). Le problème étant que cette bête commande empêchera l'utilisation des touches mortes dans les applications GTK+1 (au moins) ! J'ai mis longtemps avant de comprendre le pourquoi du comment de ce bug. Alors pour éviter les problèmes et si vous voulez mixer du japonais et du français, gardez la solution du XMODIFIERS dans le wrapper, c'est beaucoup moins problématique.

    Pour l'utilisation : <ctrl+espace> pour activer l'écriture en japonais. pour convertir les kana en kanji, et <re-espace> pour en choisir d'autres, au bout de 3 normalement un petit menu s'affiche avec toutes les possibilités. À noter que le programme est intelligent et si vous sélectionner une solution une fois, lsa fois suivante il vous propose directement cette solution en premier choix. Simple & pratique, non ? ^^

    Notes diverses :

    * sous GTK+2 il faut avoir vérifié que la méthode d'entrée sélectionné est bien « Méthode de saisie X ».
    * une bonne faço de vérifier que le système marche bien est d'essayer kterm (kanji-term), et de voir s'il supporte l'activation ou non du mode japonais (ctrl+espace). Si ça marche, alors il n'y a pas de raison pour qu'aucune autre application ne marche pas (ou alors elle est mal codée et pas nihongo aware). Normalement toute application récente, ou basée sur un widget graphique récent (GTK+2, QT, etc.) est nihongo aware.

    ---
    À noter que je n'utilise tout ça que sous Debian/Sarge (et j'ai déjà essayé sous Woody & Sid). Je n'ai jamais essayé sur d'autres distributions ou systèmes. Néanmoins cette méthode devrait marcher pour tout système X. Les paquets debian correspondant étant :

    * canna
    * kinput2-canna

    Il existe aussi des alternatives à canna, tel que wnn, mais je ne saurais trop parler de celui-ci. Pour ce qui est de im-ja il est très très bien, c'est vrai, mais uniquement comme module IM pour GTK+2. Là où kinput2 est (virtuellement) disponible pour toute application supportant la méthode XIM.

    À noter qu'une autre solution, multiplateforme, multilangue, etc. est en cours de réalisation : IIIMF (Internet Intranet Input Method Framework). Le travail est prometteur, mais je ne suis pour le moment arrivé à rien. L'une des possibilités intéressantes de IIIMF étant de pouvoir passer d'une langue et d'une méthode à l'autre sans se soucier de rien. Mais pour l'instant c'est une vision à long terme.


    頑張ってくれ!

    M'étant fondu d'un joli petit HOWTO là, je sens que je vais l'ajouter à mon site ça... Si des gens veulent l'améliorer, ça sera dispo dans une licence libre. C'est quoi la licence libre la plus appropriée ? LDP ?

    Néanmoins, je pense qu'avec ça, ton couple est sauvé ^^