[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: script vérificateur



De mon coté, j'ai un truc nomé msgcheck sur le feu. C'est la meme chose que
ce que tu fais, mais c'est en C, et c'est destiné à s'integrer à la famille
gettext un jour. 

Mais j'ai mis en tete de todo list debconf2po et po2debconf il y a peu, et
mon directeur de these m'a mis une serie d'expériementation a faire encore
avant :)

La conclusion, c'est que j'aimerais qu'on colabore, plutot. Cela n'empeche
pas de faire une version en perl pour tester l'idée, et pour avoir l'outil
le plus tot possible, mais il faudrait le faire en C à terme car le
mainteneur de gettext semble un peu allergique au perl.

Mais déjà, si on se met d'accord sur le format des fichiers, c'est une tres
bonne chose : la version perl servira à explorer les besoins, à définir le
format des fichiers de regles et les fonctionnalitées de l'outil (et bien
plus tant que je ne ferais rien pour la version C).

Voici un morceau d'un mail que Bruno Haible (mainteneur gettext) m'a envoyé
à ce sujet :
----------------------------------
I find your approach exciting; it has the potential of becoming good
academic research or really useful in practice (maybe even both :-)).
Especially with web-based cooperative authorship of such rules files.

Maybe in the long term the program can be combined with a spell checker,
like pospell does, i.e. its parameters would be a rule set and a dictionary.

But now about your PCRE question. We won't use PCRE in gettext. The simple
fact is that PCRE is not standardized, whereas POSIX regexps are.
1. Why should people learn four different regexp syntaxes: POSIX basic,
   POSIX extended, Emacs and P*rl?
2. If PCRE evolves in subtly incompatible ways (P*rl already did), who would
   update and verify the rules files?

So my advice is: Stick to POSIX basic regexps. But your rule syntax can
be extended to allow && combined rules, like

  /chaine/ && !/prochaine/

(It is quite customary in rules-based languages to have multiple && combined
conditions on the left side of the rule.)

> [ewa]/regex/
> text to display if this rule match

This syntax mixes condition (LHS) and action (RHS) of the rule. It seems
cleaner to write it as

  /regex/
  [EWA]: text to display if this rule match

Btw, since such rule sets are likely to be the result of collaborative work
and long time maintenance, a possibility to add comments

  # comment

seems necessary.

Oh, and "severity" or "level" is probably a better word for "gravity".
----------------------------------------

A propos des regles posix vis à vis des regles perl, je pense mainenant
qu'il a raison. On a besoin des regles perl uniquement quand on essaye de
faire de cet outil un correcteur orthographique, ce qui me semble etre une
erreur.

On a aussi besoin d'un mécanisme d'override dans le fichier po, du style un
commentaire au format prédéfini indiquant, en substance, "je sais que j'ai
pas mis d'espace avant mes deux points, mais je t'emmerde [car ils font
parti d'une url]"...

Tout ca pour dire que msgcheck me semble bien comme nom pour ton script :)

Voila, voila, Mt.

On Thu, Jan 17, 2002 at 01:22:22AM +0100, Nicolas Bertolissio wrote:
> Bonjour,
> 
> Comme je l'avais annoncé, j'ai repris le script de l'équipe de kde pour
> vérifier la typo. et quelques autres règles. Comme je ne comprenais
> rien à cause du manque de commentaires, j'en ai fait un nouveau que je
> comprends.
> 
> De plus, en un mois il n'avais pas changé, c'est-à-dire qu'il ne fait
> toujours que reporter les erreurs sans donner le moyen de les corriger
> automatiquement, j'en ai déduit qu'il était un peu laissé de côté.
> 
> Mon script n'est pas tout à fait fini, mais j'ai bien avancé hier et
> aujourd'hui. Si j'ai suffisamment de temps pour bosser dessus, j'espère
> le sortir ce week-end. Mais sans documentation pour le moment, sauf si
> j'ai vraiment beaucoup de temps, mais ça m'étonnerait énormément.
> 
> Le format des fichiers de syntaxe est malheureusement différent et
> incompatible avec celui de l'équipe de kde.
> 
> Il me manque un nom, donc si quelqu'un a une idée, je suis preneur.
> 
> Voila donc pour les nouvelles.
> 
> 
> Nicolas
> -- 
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-l10n-french-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> 

-- 
Dans le passé, il y avait plus de futur que maintenant.
   -- Le Chat



Reply to: