[Po4a-dev]Assainir les encodages ; assainir les options des binaires

[Martin Quinson]

Ok, this message is in french, and that's bad, but Denis and I are both
french, and we exchange pretty much messages about po4a status and future.

I'll use the list for that, despite of the french language, because I feel
that those messages are important and deserve an archive.


Sorry for non french speaking members (if any, speak up).

On Wed, Jan 15, 2003 at 02:36:39PM +0100, Denis Barbier wrote:
> > > > On Wed, Jan 15, 2003 at 11:33:09AM +0100, Martin Quinson wrote:
> > > > > Je ne sais pas si tu as réfléchi à un autre problème, qui est le 
> > > > > codage
> > > > > utilisé en entrée/sortie. Il faut absolument que ce soit spécifié, et
> > > > > éventuellement permettre une conversion à la volée, comme po-debconf.
> > > > > Les puristes voudront que le coeur ne gère que de l'UTF-8, la 
> > > > > conversion
> > > > > vers d'autres codages étant faite dans les entrées/sorties.
> > > > 
> > > > Je suis une bille totale en ca. Je sais meme pas exactement quels sont 
> > > > les
> > > > problemes... 
> > > 
> > > Regarde les fichiers PO : le charset est spécifié, et s'il ne l'est pas,
> > > les outils de gettext ne traitent pas le fichier. Il faut faire la même
> > > chose avec tous les fichiers texte qu'on manipule : si le charset n'est
> > > pas spécifié, le fichier est ignoré.
> > > Pour les manpages, je viens de rajouter cette information, chaque fichier
> > > a un codage spécifié dans le fichier INFOS.
> > > Pour le SGML/XML, le charset est soit spécifié, soit implicite, mais il
> > > est dans tous les cas défini.
> > > Pour les fichiers POD traduits, il n'y a rien, on est dans la même 
> > > situation
> > > que debconf avant po-debconf. Comme Perl a pris un virage UTF-8 à fond, il
> > > est probable qu'on verra bientôt arriver des fichiers POD en UTF-8 (même
> > > en anglais). C'est par exemple le cas de Locale::Language, la prochaine
> > > version sera en UTF-8, car certaines langues ont des lettres accentuées.
> > > 
> > > Il y a 2 étapes distinctes :
> > >   a. Prendre conscience du problème et faire en sorte que le codage de
> > >      chaque fichier soit spécifié, soit à l'intérieur du fichier
> > >      (comme SGML), soit dans un autre fichier (les manpages du CVS),
> > >      soit implicitement (mais avec une règle bien définie et immuable).
> > >   b. Modifier les outils pour qu'ils prennent en compte le codage.
> > > 
> > > Il faut impérativement que le (a) soit réglé avant la release officielle,
> > > sinon on va devoir se trainer des fichiers sans codage spécifié, et ça va
> > > être super galère à gérer (comme pour debconf).
> > > On verra le point (b) ultérieurement.
> > > 
> > Donc, ce qu'il faut que je fasse pour cette premiere étape, c'est:
> > 
> >   - une fonction get_charset_of_file dans chaque module qui lit le fichier 
> >     et cherche à en déduire le charset (et renvoi undef si inconnu)
> 
> Ou récupérer l'information dans un fichier auxiliaire, p.ex. <source>.charset,
> afin de ne pas avoir à modifier l'original.
> Ça peut être nécessaire pour certains formats, p.ex. les pages man, dont
> le codage est actuellement par défaut ISO-8859-1, et passera bientôt en UTF-8.
 
Je n'ai pas envie de traiter des fichiers annexes. C'est pour ca que je
préfere mettre des options aux binaires. Mon idée, c'est que si l'info est
dnas un fichier à part, c'est à l'utilisateur de po4a de se faire chier à le
parser, et à passer cette info en argumetn à po4a.

Si y'a pas de charset spécifié dans le fichier source, et si on passe pas de
charset en argument, alors le charset est undef, et ca plante. C'est pas
bon, ca ?

Pour les nroff, on peut dire que le charset peut être donné en commentaire
dans le source. Un truc comme ca, pas loin du début.:
.\" Charset: UTF-8

Une autre question, c'est comment le programme man va "deviner" le charset ?
Est ce qu'il y a moyen de faire comme lui ? De toute facon, va falloir lui
donner l'info en sortie dans la page traduite, non ?

> >   - une floppée d'options charset pour tous les binaires. il me faut une
> >     option pour chaque fichier (entré ou sortie) pour surcharger le charset.
> 
> Ben, si chaque langue a un certain charset, et que tu en veux un autre,
> je ne vois pas comment se passer de ces options. En pratique, le choix est
> limité à 2 ou 3 codages par langues.
> Pour po-debconf, le codage de sortie est dirigé par le fichier
> debian/po/output

J'aime vraiment pas l'idée d'un fichier à part.

> , les valeurs possibles sont :
>   1. UTF-8
>   2. le charset qui se trouve dans le PO
>   3. le charset qui est déclaré dans le fichier
>           /usr/share/po-debconf/encodings
>      avec possibilité de fournir son propre mapping langue <-> codage

Mmm. C'est dur de convertir ? J'aimerais forcer l'utilisateur à me donner le
charset en entrée, et lui permettre de donner n'importe quoi en sortie (avec
par défaut le charset du fichier po)

> >   - faire qu'on refuse de traiter des fichiers dont l'encodage est inconnu
> >     (ie, get_charset a échoué, et l'option n'a pas été passée en argument)
> 
> Oui, il faut forcer le traducteur à fournir cette information.
> Pour po-debconf, j'ai dû courir après un roumain pour savoir ce qu'il avait
> utilisé, c'est galère.
> 
> >   - la possibilité de mettre le charset dans les po générés
> >   - Il faut que je trouve comment mettre le charset dans les fichiers
> >     de documentation générés. La duale de get_charset_of_file().
> 
> Oui, ça serait bien de l'avoir en 1e ligne, sous forme de commentaire.

Ah, on est d'accord. Mais ceci dit, il faut fournir cette information au
format généré. Je veux dire, si on écrit du XML, il faut pas mettre ceci en
commentaire, mais à la place prévue pour ca, afin que les outils qui vont
mouliner ce XML apres nous sachent l'encodage.

> > Ai je raison? Ai je vraiment besoin de tétrachiées d'options, ou puis-je en
> > faire une seule qui sera utilisée en entrée et en sortie (ca va imposer de
> > faire des convertions hors de po4a dans certains cas étranges) ? 
> 
> Il faut différencier po4a-gettextize du reste. Dans cette phase, il vaut
> mieux utiliser un fichier auxiliaire, comme je l'ai fait dans po-debconf
> avec le fichier encodings.
> Une fois que po4a-gettextize est passé, on a des fichiers PO, dont le
> charset est bien identifié, le document original (=entrée) et les
> traductions (=sortie).
> Ici encore, je pense que l'approche utilisée dans po-debconf est bonne,
> en limitant le codage de sortie à 3 possibilités : UTF-8, ke charset du
> PO ou utiliser un fichier contenant la correspondance langue <-> encoding.
> Pour le codage d'entrée, si on a autre chose que de l'ASCII, gettext
> va râler. Dans ce cas, il faut de toute façon convertir les lettres
> accentuées (p.ex. en entités SGML), donc ce problème doit être réglé
> indépendamment de ces considérations de codage.
> Pour po-debconf, je ne me suis pas préoccupé du codage d'entrée, il me
> semble que Joey Hess a décidé de n'autoriser que de l'ASCII.


Pourquoi ? TransTractor est déjà une belle usine à gaz sans qu'on rajoute le
besoin d'un Nieme fichier. Pourquoi ne pas le passer en argument ?

po4a-gettextize --master-charset=ascii --trans-charset=iso8859-1 man.1 man.fr.1

Je pense nettoyer les options des binaires, et virer les --input et --output
qui changent de sens avec le programme pour mettre les memes optiosn
partout. Par exemple:

 -m,--master : document original
 -M,--master-charset
 -t,--trans : document traduit [si t'as un meilleur nom, je suis preneur]
 -T,--trans-charset
 -p,--po : po (utilisé en entrée et en sortie)
 -a,--addendum:
 -A,--addendum-charset
 
 -f,--format : module po4a (anciennement -t)
 -F,--help-format : donne la liste des formats dispo
 
 -o,--option : y'a des fois ou je vais avoir besoin de passer des arguments
               au module. Je vais limiter au maximum, mais bon.
               
 -d,--debug
 -v,--verbose
 -V,--version

 [spécifique à translate]
 -k,--keep: pourcentage minimum de traduction pour garder le fichier généré

 [uniquement pour gettexize et normalize, c'est clair dans les autres cas]
 -P,--po-charset 

Ca me permet d'utiliser les memes options pour tous les binaires, et ca
m'évite de devoir gérer encore un fichier de plus à coté.

Ce que ca ne permet pas de faire, c'est joindre des pages man originales
encodées UTF8 et d'autres encodées ASCII dans le meme appel à po4a-updatepo.
Est ce grave ?

> > Autre chose, ca va semer la zone dans mes expressions régulières dans le
> > source, ou il faudrait principalement faire un use UFT8; et eviter deux
> > trois constructions ?
> 
> A priori, tu n'utilises pas 'use locale', donc les expressions régulières
> ne concernent que l'ASCII et ne sont pas impactées.

Donc, si je cole use UTF8; ca marche meme pour les caractères multibytes ?


Une autre chose que j'aimerais voir avant de faire une release 1.0, c'est
permettre de coller les addendums dans les fichiers po, sous forme de
commentaires ayant un entete particulier (pour packer tous les éléments
d'une langue donnée dans un seul fichier, et éviter que le mainteneur puisse
oublier un addendum lors de la génération).

Mais est ce que l'encodage des commentaires est déterminé ?

Bye, Mt.

-- 
Dans un pays d'extrême droite, tu dis pas non a tout bout de champ, ou alors
au bout du champ de tir.
   -- Frères misère