summaryrefslogtreecommitdiff
path: root/info/latex2e-help-texinfo-fr/README
blob: 9d67506375c3a91233d5698c7bfe515b6d87e16b (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
$Id: README-fr 585 2017-08-08 21:52:24Z vincentb1 $
README for latex2e-fr.texi, aka the latex2e-help-texinfo-fr package.
Public domain.  This file originally written 2016, Vincent Belaïche,
based on the English version by Karl Berry.

About this project (French translation of this section follows)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This project is an attempt to write a reference manual for core LaTeX.
It is unofficial and the LaTeX Project members have not reviewed it.

https://puszcza.gnu.org.ua/software/latexrefman/ (the project home page)
has more information, including links to the current output in various
formats, sources, mailing lists, and other infrastructure.

Help is most definitely wanted.  (Search for "xx" in the source for just
a few of the known deficiencies.)  Please email any bug reports, new
material, general discussion, whatever, to latexrefman@tug.org (see
http://lists.tug.org/latexrefman for archives and subscription via the web).


À propos de ce projet
~~~~~~~~~~~~~~~~~~~~~

Ce projet est une tentative d'écrire un manuel de référence pour le
cœur de LaTeX.  Il est officieux en ceci que les membres du projet
LaTeX n'en ont pas fait la revue.

https://puszcza.gnu.org.ua/software/latexrefman/ (la page d'accueil du
projet) contient plus ample information, dont les liens vers la
version courante du manuel généré dans divers format, les codes
source, les listes de discussion, et d'autres infrastructures.

Toute aide est la bien venue. (Cherchez "xx" dans le source pour un
aperçu de quelques-unes des carences connues). Envoyez SVP par mél
tout rapport d'anomalie, nouveau matériel, ou point de discussion
générale à latexrefman@tug.org, voir aussi
http://lists.tug.org/latexrefman pour les archives et l'abonnement.

À propos de la traduction en français
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

J'(Vincent Belaïche) ai initié la traduction en français du manuel en
octobre 2015, la première traduction complète a été publiée en avril
2016.

Contrairement à ce qui avait été fait pour la traduction en espagnol,
je n'ai pas traduit les références internes, c-à-d. les noms de nœuds
(@node) et les ancres (@anchor), de sorte que tout lien vers la
version anglaise puisse facilement être converti en un lien vers la
version française. De plus, j'anticipe que le langage Texinfo offrira
un jour ou l'autre la possibilité de spécifier un alias localisé des
références internes.

En ce qui concerne le vocabulaire typographique et « LaTeXien », je me
suis appuyé notamment sur les ressources suivantes :

    http://david.carella.free.fr/fr/typographie/glossaire-typographique.html
    http://www.cavi.univ-paris3.fr/phalese/desslate/index.htm
    http://cahiers.gutenberg.eu.org/cg-bin/article/CG_2007___49_19_0.pdf

ainsi que sur les tableaux Unicodes pour les noms de symboles :

	http://hapax.qc.ca/pdf/Tableaux-5.0/Uxxxx.pdf en français
	http://www.unicode.org/charts/PDF/Uxxxx.pdf en anglais

où xxxx est à remplacer par le code de début de plage en hexadécimal.

Je me suis cependant départi de plusieurs des termes usuels, ce que
j'assume pleinement comme je l'explique ci-après :

Traduction de « section/sectionning »
------------------------------------
J'ai préféré « rubrique » à « section », et le néologisme
« rubricage » à « sectionnement ». Le problème, ÀMHA, avec
« section/sectionnement » est double :

- d'une part, et le même problème existe en anglais, le terme reprend
  la dénomination de l'un des niveaux de rubricage, celui créé par la
  commande \section, donc c'est ambigu

- d'autre part, le terme « sectionnement » me fait trop penser à une
  coupure violente, à la fois irrémédiable et regrettable, comme le
  sectionnement d'une artère, alors que le but des rubriques n'est pas
  de couper (ou sectionner) le texte, mais de le structurer et de le
  rythmer. Le mot « rubrique » vient de la couleur rouge qui était
  utilisée pour colorer les titres de rubriques, et j'aime à penser que
  le choix de cette couleur est inspiré par celle du soleil levant,
  comme si chaque rubrique était ainsi annoncée par l'Aurore aux
  doigts de rose.

Traduction de « package »
-------------------------
J'ai préféré utiliser « paquetage » à « extension » qui est le terme
traditionnel, lorsque il s'agit d'une extension de LaTeX chargée avec
la commande \usepackage. Par contre, dans le nœud (info
"(LaTeX2e-fr) Overview") j'ai traduit « macro package » par « paquet
de macros ».

En effet, dans le premier cas le mot anglais « package » est le même
que celui utilisé dans le langage Java. C'est pratiquement un synonyme
de ce que l'on appelle « bibliothèque » pour d'autres langages, comme
par exemple le C ou le C++, à ceci près que « package » insiste plus
sur l'existence d'un mécanisme dédié de chargement du code ---
celui-ci est en quelque sorte emballé de façon à être rendu disponible
à moindre effort --- alors que « bibliothèque » insiste plus sur le
regroupement dans un même module de fonctions en relation avec un même
objectif, un peu comme dans une bibliothèque les livres peuvent être
classés par rayon. Le terme paquetage m'a ainsi paru mieux traduire
« package » étant donné le mécanisme offert pas la commande
\usepackage, le passage d'option globale depuis \documentclass, ainsi
que les commandes \RequirePackage, \PassOptionsToPackage,
etc. offertes aux développeurs de paquetages.

Dans le second cas, à savoir « macro package », j'ai préféré le mot
« paquet », parce qu'il m'a semblé qu'ici on signifiait que ces macros
sont distribuées et installables ensemble.


Traduction de « moving argument »
--------------------------------
La traduction traditionnelle de « moving argument » est « argument
mobile », et c'est la traduction que j'ai utilisée dans un premier
temps. Toutefois, j'ai préféré la changer en « argument mouvant ». Et
d'ailleurs je ne suis pas le seul à préférer cette traduction (voir
https://www.latex-project.org/help/books/lc2fr-apb.pdf).

Un argument mouvant est un argument qui est développé en deux étapes,
la première, hors contexte final, pour être écrit dans un fichier
auxiliaire, la seconde à partir du fichier auxiliaire dans le contexte
final pour être éxecuté et composé. Lorsque lors de la première étape
le développement trop poussé d'une macro en l'absence du contexte
final induirait un code TeX non valide on dit que la macro en question
est « fragile », et il convient de se protéger contre cette
éventualité, par ex. en utilisant à la place une macro ne posant pas
le même problème, et à ce titre dite « robuste ». De la vient la
problématique des arguments mouvants.

Les arguments mouvants ne sont donc pas vraiment mouvants : ils sont
exécutés et composés en général à des endroits bien définis du texte,
contrairement aux flottants. C'est certainement cette raison qui a
fait préferer « mobile » à « mouvant » dans les traductions
traditionnelles. Toutefois « mobile » tout en conservant cette idée de
mobilité que l'on trouve dans le terme original « moving argument »,
n'est pas à mon avis beaucoup plus clair, et lors d'une discussion sur
fr.comp.text.tex beaucoup de termes alternatifs qui auraient peut-être
été plus clairs on été proposés : argument clonés, rebouclés,
repliqués etc... Le choix de « mobile » fait donc les choses à moitié,
on perd à la fois le côté poétique de « mouvant » dont l'étrangeté est
en soi une incitation à lire une explication détaillée du concept,
sans vraiment former un terme beaucoup plus clair.

D'autre part la nuance entre « mobile » et « mouvant » (« moving » )
est la même en anglais et en français : dans le premier cas on parle
de la possibilité d'un mouvement, souvant une possibilité offerte et
désirable (par ex. « téléphone mobile »), alors que dans le second cas
on parle de la survenue d'un mouvement, le plus souvant indésirable
(par ex. « sables mouvants »). En français, il faut toutefois noter
que le terme « mouvant » et beaucoup moins fréquent que « moving » en
anglais, et que son utilisation dans un manuel technique est donc
encore plus improbable.

Le terme « moving argument » est utilisé pour la première fois par
Leslie Lamport, le créateur de LaTeX. En ce qui concerne la fragilité
de certaines commandes, Lamport n'explique pas les détails de ce qui
se passe « sous le capot ». Après tout son intention en créant LaTeX
était de permettre à l'utilisateur lambda d'écrire des documents sans
avoir à connaître toutes les subtilités du langage TeX. Il se contente
donc d'alterter le lecteur sur la nécessité d'utiliser des commandes
robustes, ou de les rendre robustes par un préfixe \protect, et dans
ce texte introductif il le fait de façon très imagée :

   When carried from where it appears in the input file to the other
   places it is used, the argument of a sectioning command is shaken
   up quite a bit. Some LaTeX commands are fragile and can break when
   they appear in an argument that is shaken in this way.

Le terme « moving argument » résulte donc de ce procédé poétique
visant à capter l'attention du lecteur, et non de la recherche d'un
terme technique exact.

C'est par respect pour ce choix, que je garde et assume la traduction
« argument mouvant », il me semble finalement mieux convenir aux
utilisateurs novices de LaTeX, quitte provoquer un « moving argument »
(une dispute émouvante) parmi les TeXniciens confirmés.

# Local Variables:
# coding: utf-8
# ispell-dictionary: "francais"
# mode: text
# End: