Re: [CSS1] Appel a relecture

Eric Schreiner <Eric.SCHREINER@agriculture.gouv.fr> [2001/07/30 10:19]

Eric,

> Je trouve cette traduction globalement très bien faite.
> J'ai pinaillé un peu et me suis pour l'instant arrêté juste avant le
> 4.2.

Je t'en remercie :-)

> Question :
> - Un "spécialiste" du domaine nous a conseillé de rédiger les mots clefs
> HTML en minuscules pour s'assurer d'une compatibilité ascendante vers la
> suite.
> (Tout comme il conseille de fermer les balises, exemple <BR> peut
> devenir <BR/>, <img...> </img>, etc.)
> Il peut s'agir d'une règle de codage, mais pourriez-vous me confirmer ce
> fait ?

Cette version de la spécification est écrite suivant la recommandation HTML 4.0
transitionnelle (voir le doctype). Suivant celle-ci, il n'est pas requis de
balises fermantes pour les éléments BR et IMG, tout comme pour P et LI. On peut
même omettre la balise HEAD.

Pour un document en XHTML, ces balises fermantes sont obligatoires et leur
construction prend la forme que tu indiques, avec quelques nuances :
il est préférable d'écrire <br /> et <img ....alt="..." /> tout seuls (noter le
blanc qui précède la barre oblique), on pourrait théoriquement utiliser les
formes doubles, telles <br></br> et <img .....></img>, mais au risque de
déplaire à certains vieux navigateurs.


Au sujet de la relecture, je reçois avec grand plaisir le relevé des erreurs ou
ambigüités commises et je les retiens toutes, sous réserve des suivantes :

  [...]
  
> En 4.1.1 le terme "collapsing" est traduit par "fusion" pour le
> comportement des marges
> Je ne trouve pas d'autre terme, mais je ressens "fusion" ambigü du fait
> de la notion de "réunion" qu'il intègre
> Or la résultante n'est pas la réunion des deux (somme) mais la plus
> grande (max).
> J'ai été tenté par "absorbtion", mais idem.
> Je ne suis pas certain que "effondrement" soit approprié.
> Cela est aussi applicable aussi au 4.1.2 §9
> Pour info, voila ce qu'en donne Babylon Translator :
> "effondrement;écroulement;réduction,dissimulation des niveaux
> secondaires ou de sous-répertoire sous le titre ou le répertoire actuels
> (informatique), s'écrouler,s'effondrer"
> Peut être que "réduction" irait.

J'aurais penché pour "effondrement" bien que je lui trouve une connotation
négative. Pour défendre mon "fusion", je trouve que le terme évoque bien plus
l'idée de "ne faire plus qu'un" qui est le résultat final de l'opération. De
plus, il est court. Mais nous pouvons encore en discuter.


> ___
> 2.3 Pseudo-élément 'first-line'
> ...
> §10
> je trouve déroutant/frustrant d'avoir des propriétés traduites et d'autres non
traduites, aussi il me semble préférable
> soit de ne pas traduire et conserver les 'termes' de la version originale :
exemple "color & background (5.3)"
> soit de tout traduire avec les renvois : "de couleur et de fond (5.3)"
> soit, last but not least, de tout traduire et de rappeler avec le renvoi le
terme original : "de couleur et de fond (5.3 color & b&ckground)"

Je ne pense pas qu'il faille traduire à outrance, tous les termes anglais qui se
présentent, et surtout ceux qui ont trait aux propriétés et valeurs, pour
plusieurs raisons :

- pour réaliser une feuille de style, l'auteur est quasi-obligé d'utiliser le
langage de CSS (bien sûr, issu de l'anglais) ; on doit, AMA, considérer les mots
de ce langage comme étant du code, au même titre que les instructions d'autres
langages de programmation.

- pour l'échange entre pairs, c.-à-d. entre auteurs de feuilles de style, ce
langage doit rester universel.

Maintenant, j'admets aller parfois contre ces principes. Par exemple, je propose
"à-règle" pour "at-rule", mais est-ce que c'est aussi parlant pour tous les
francophones, canadiens comme pour belges ou français. Un avis ?

Autrement, comme déjà dit à Claude, on peut toujours créer un lexique des termes
employés qui, AMA, n'a d'utilité que pour une phase de contact iniatiale avec le
langage. Après cette courte période de familiarisation avec ce "code", le
lecteur va rechercher un accès rapide aux définitions. Partant, il vaut mieux
conserver la meilleure lisibilité possible.


En attendant avec impatience la suite de tes remarques,

Merci,

JJS.

P.S.: Je compte mettre en ligne la version corrigée de la traduction après les
retours de chacun d'entre les relecteurs. Dites-moi si vous préférez cette façon
ou celle qui consiste à remettre immédiatement en ligne une version corrigée à
mesure.

--
/* home page <http://www.yoyodesign.org/> */
/* public key id: 9eb99ddb <http://www.keyserver.net/> */

Received on Monday, 30 July 2001 09:53:17 UTC