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
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<title>Règles de codage de Scribus</title>
</head>
<body>
<h2>Règles de codage de Scribus</h2>
<p>
Document initial : Paul F. Johnson, 26 fév. 2004, version : 0.04<br/>
Révisé par Craig Ringer le 16 août 2005, version : 0.05 (encodage du texte, exceptions, à qui envoyer les mises à jour)<br />
Révisé par Peter Linnell le 06 sept. 2005, version : 0.06 (éléments d'encodage de texte ajoutés pour tenir compte des des entretiens récents)</p>
<p>Ce document se veut un guide pour tous les développeurs et contributeurs du projet Scribus. Il s'agit d'un outil convivial qui aide à préserver la simplicité du code source et à en assurer la maintenance.</p>
<h3>Documentation du code</h3>
<p>Tout le code doit être documenté clairement.</p>
<p>Avant d'utiliser une méthode en particulier, les éléments suivants doivent être présents :</p>
<blockquote><table width="100%" border="1" bgcolor="#eeeeee"><tr><td border="0">
<pre>
/*!
\fn functionName::functionName()
\author Nom des auteurs
\date
\brief Constructeur pour la classe
\param Aucun
\retval Aucun
*/
</pre>
</td></tr></table></blockquote>
<p>Vous devez mettre en place quelque chose de semblable avant d'établir les définitions de classe.</p>
<p>De préférence, tous les détails devraient rédigés être en anglais. Cela inclut les commentaires.</p>
<p>À moins qu'un commentaire n'occupe une seule ligne, vous devez utiliser <code>//</code> de préférence à <code>/* */</code>.</p>
<h3>Code</h3>
<h4>Convention de noms de variable</h4>
<p>Tous les noms de variable doivent commencer en lettres minuscules. Si le nom comporte plusieurs parties,
la deuxième partie doit commencer par une lettre majuscule. Par exemple : <code>int foo</code> et <code>int fooBar</code>. Sous aucune circonstance, vous ne devez utiliser le caractère de soulignement (_).</p>
<p>Les variables doivent être nommées clairement. La seule exception réside dans une boucle for. De préférence, les variables doivent être libellées
en anglais. Nous avons entrepris de convertir et de modifier les variables existantes en fonction de ce modèle.</p>
<p>Les variables temporaires (comme celles utilisées dans une boucle <code>for</code> ou celles qui dépendent d'un contexte)doivent être déclarées uniquement lorsqu'elles sont nécessaires et si elles ne sont pas utilisées dans un contexte global. S'il y a une condition
au début d'une méthode, toutes les variables nécessaires doivent être déclarées, mais rien d'autre. Par exemple :</p>
<blockquote><table width="100%" border="1" bgcolor="#eeeeee"><tr><td border="0">
<pre>
void foo::bar(f *b)
{
int j;
string g = b->passed_in;
double fg, m, c;
which_string(g, &j);
if (j == true)
return;
// rest of the code
}
</pre>
</td></tr></table></blockquote>
<p>ne doit pas avoir de déclaration de variables doubles. On peut se demander si g doit être déclarée, mais dans cet exemple, cela n'a pas d'importance.</p>
<p>Si une variable n'a pas d'utilité, ne la créez pas. Dans l'exemple ci-dessus, rien n'exige l'utilisation de g. </p>
<h4>Convention de tabulation</h4>
<ol>
<li>
<p>Définitions à l'intérieur d'une classe</p>
<p>À l'exception des déclarations d'accès, vous devez placer une tabulation avant chaque définition de méthode et de variable. Il ne doit pas y avoir de tabulation avant les déclaration d'accès. Il y a une tabulation avant <code>Q_Object</code>.</p>
</li>
<li>
<p>Dans le code principal :</p>
<p>Il doit y avoir une tabulation au début de chaque ligne. Sur toutes les lignes conditionnelles, il doit y avoir une accolade ouvrante seule. Sur les lignes suivantes, il doit y avoir une autre tabulation avant le code. L'accolade fermante doit être alignée sous l'accolade ouvrante.</p>
</li>
</ol>
<h4>Conditions</h4>
<p>Construisez toujours des conditions logiques. Cela peut paraître simpliste, mais observez l'exemple qui suit :</p>
<blockquote><table width="100%" border="1" bgcolor="#eeeeee"><tr><td border="0">
<pre>
int foobar(bool m)
{
if (m == true)
{
somethingA(1);
somethingB(1);
somethingC(1);
}
else
{
somethingA(0);
somethingB(0);
somethingC(0);
}
}
</pre>
</td></tr></table></blockquote>
<p>Voici comment on peut rendre les choses plus claires :</p>
<blockquote><table width="100%" border="1" bgcolor="#eeeeee"><tr><td border="0">
<pre>
int foobar(bool m)
{
int c = m == true ? 1 : 0;
somethingA(c);
somethingB(c);
somethingC(c);
}
</pre>
</td></tr></table></blockquote>
<p>Cette présentation est beaucoup plus lisible et sera généralement plus facile à optimiser. </p>
<p>Utilisez des conditions ternaires (?) au lieu de <code>if</code> / <code>else</code>. Elles sont beaucoup plus rapides à exécuter une fois que le code est compilé.</p>
<p>Selon la tâche à accomplir, il vaut mieux éviter les énoncés switch. Il existe souvent une manière plus simple de procéder. Par exemple :</p>
<blockquote><table width="100%" border="1" bgcolor="#eeeeee"><tr><td border="0">
<pre>
int b;
string s;
switch (f)
{
case 1 :
b = 4;
s = "four";
break;
case 2 :
b = 8;
s = "eight";
break;
case 3 :
b = 12;
s = "twelve";
}
</pre>
</td></tr></table></blockquote>
<p>peut être ré-écrit comme ceci : </p>
<blockquote><table width="100%" border="1" bgcolor="#eeeeee"><tr><td border="0">
<pre>
int b = f * 4;
char *number[] = {"four", "eight", "twelve"};
size_t no = sizeof(number) / sizeof(*number);
s = number(f);
</pre>
</td></tr></table></blockquote>
<p>Le switch a disparu et le code généré tourne beaucoup plus vite; comme les conditions n'ont pas besoin d'être créées, il sera mieux optimisé. Note : avec la fonction <code>QObject::tr()</code> , il se peut que char* ne fonctionne pas toujours correctement. Une solution de rechange consiste à utiliser <code>QString number[] = {"four", "eight", "twelve"};</code> etc.
<p>Évidemment, vous ne pouvez utiliser le code ci-dessus pour des conditions switch plus complexes.</p>
<h4>Formatage des conditions </h4>
<p>Le formatage devrait ressembler à ceci :</p>
<blockquote><table width="100%" border="1" bgcolor="#eeeeee"><tr><td border="0">
<pre>
if (fred == 5)
{
// something
// something
}
</pre>
</td></tr></table></blockquote>
<p>Le formatage du switch doit ressembler à ceci :</p>
<blockquote><table width="100%" border="1" bgcolor="#eeeeee"><tr><td border="0">
<pre>
switch (f)
{
case 0:
if (fred == 1)
{
// something
// more
// ok
}
else
{
if (jimmy == 0)
{
// hi
// code
}
// something here
}
break;
}
</pre>
</td></tr></table></blockquote>
<p>Le code est facile à lire et on peut déterminer aisément où la condition prend fin.</p>
<p>N'écrivez jamais, sous AUCUNE considération, une ligne telle que celle-ci : </p>
<blockquote><table width="100%" border="1" bgcolor="#eeeeee"><tr><td border="0">
<pre>
if (foo == bar) { somethingA(0); }
</pre>
</td></tr></table></blockquote>
<p>Employez plutôt cette présentation : </p>
<blockquote><table width="100%" border="1" bgcolor="#eeeeee"><tr><td border="0">
<pre>
if (foo == bar)
somethingA(0);
</pre>
</td></tr></table></blockquote>
<p>Si les accolades ne sont pas requises, ne les utilisez pas. Par exemple, les accolades ne seraient pas requises ici</p>
<blockquote><table width="100%" border="1" bgcolor="#eeeeee"><tr><td border="0">
<pre>
for (int j = 0; j < 10; ++j)
cout << j << "\n"?;
</pre>
</td></tr></table></blockquote>
<h4>Préincrémentation et postimcrémentation</h4>
<p>Dans les boucles, vous devez choisir la préincrémentation (++a plutôt que a++). Avec les processeurs ARM et x64 (vérifier à pour ia64) ++a requiert la moitié moins de cycles d'horloge que le style postfix. Dans certaines circonstances, ++a est beaucoup plus efficace sous ia32. Cela est vrai même avec des itérateurs. La postincrémentation doit être utilisée dans le genre de code ci-dessous :</p>
<blockquote><table width="100%" border="1" bgcolor="#eeeeee"><tr><td border="0">
<pre>
if (b == true)
{
m->wibble(c);
m->wobble(c++);
}
</pre>
</td></tr></table></blockquote>
<h4>Espacements</h4>
<p>Il doit y avoir un espace :</p>
<ul>
<li>Après toutes les virgules et tous les points-virgules (dans une condition for)</li>
<li>Entre chaque conditionnel (<code>if (a == true)</code> - il y a un espace de chaque côté du conditionnel <code>==</code>)</li>
<li><p>Avant une parenthèse ouverte ou après une parenthèse fermée :</p>
<ul>
<li>Il est interdit de placer un espace tout de suite après une parenthèse ou à la fin d'un énoncé entre parenthèses.</li>
<li>N'insérez jamais d'espace en début de ligne. Utilisez plutôt une tabulation. Une tabulation correspond à un nombre précis d'espaces, qui peut
varier si vous les introduisez à la main.</li>
</ul>
</li>
</ul>
<h4>Utilisation de modèles</h4>
<p>Il convient d'utiliser les modèles pour les types et les classes. Les responsables du projet recommandent d'utiliser g++ 3.x, qui supporte parfaitement les modèles et les classes modèles. N'oubliez pas la charge de calcul supplémentaire due à l'utilisation des modèles!</p>
<p>Lorsque vous utilisez des modèles, rappelez-vous ce qui suit :</p>
<ul>
<li>Le binaire final sera plus volumineux.</li>
<li>Utilisez les modèles correctement. On peut se laisser séduire par l'idée de "faire un modèle" quand, en fait, il conviendrait de créer (par exemple) un modèle générique qui hérite des classes de base Qt en question.</li>
<li>Dans certains cas de figure, un modèle ne sera pas aussi efficace qu'un appel autonome.</li>
</ul>
<h4>Optimisation</h4>
<p>À moins de savoir exactement ce que vous faites et, surtout, ce que le code fait, n'essayez pas d'optimiser le code. À beaucoup d'égards, l'optimisation est davantage un art qu'une science. </p>
<p>Du code comme <code>a = b = c = 0;</code> est plus efficace (lorsqu'il est traité par le compilateur) que <code>a=0; b=0; c=0;</code></p>
<p>Il vaut mieux se concentrer sur la manière dont le code fonctionnne plutôt que d'essayer une des "astuces" du métier.</p>
<p>Tout changement à grande échelle doit être approuvé au préalable. Parfois, un changement minime peut avoir des répercussions très importantes.</p>
<p>Des lignes séparées contenant des appels aux méthodes Qt sont beaucoup moins efficaces que des appels regroupés dans une boucle for.</p>
<h4>Initialisation</h4>
<p><code>QString fred = QString("bob")</code> n'est pas la même chose que <code>QString fred("bob")</code>. Le premier crée un élément temporaire qui est ensuite abandonné. Cette technique est lente et doit être évitée.</p>
<p>Dans les constructeurs, il est préférable d'utiliser ce qui suit : </p>
<blockquote><table width="100%" border="1" bgcolor="#eeeeee"><tr><td border="0">
Fred::Fred() : ParentClass(),
argument1("initialValue"),
argument2(INITIAL_VALUE)
{
}
</td></tr></table></blockquote>
<p>que</p>
<blockquote><table width="100%" border="1" bgcolor="#eeeeee"><tr><td border="0">
Fred::Fred() : ParentClass()
{
argument1 = "initialvalue";
argument2 = INITIAL_VALUE;
}
</td></tr></table></blockquote>
<p>pour les raisons expliquées plus haut. Il vaut mieux initialiser les membres dans l'ordre où ils sont listés dans la déclaration de la classe.</p>
<h4>Vérification de la mémoire</h4>
<p>Comme les exceptions ne sont pas disponibles (voir ci-dessous), nous utilisons <code>Q_CHECK_PTR</code> pour vérifier les allocations. Cela signifie que vous obtenez un abandon avec un message explicatif plutôt qu'un segfault sans aucun détail.<p>
<blockquote><table width="100%" border="1" bgcolor="#eeeeee"><tr><td border="0">
int *m = new int[2048];
Q_CHECK_PTR(m);
</td></tr></table></blockquote>
<h5>Exceptions</h5>
<p>Idéalement, tous les appels à <code>new</code> doivent être capturés. Cette fonctionnalité n'existe pas dans les versions courantes. La méthode souhaitable serait :</p>
<blockquote><table width="100%" border="1" bgcolor="#eeeeee"><tr><td border="0">
<pre>
#include <new>
try
{
m = new int[2048];
}
catch(bad_exception)
{
cout << "memory allocation to m failed - <method name<" << endl;
exit(EXIT_FAILURE);
}
</pre>
</td></tr></table></blockquote>
<p>Comme il y a plusieurs appels à new dans Scribus, ceux-ci devront être encapsulés.</p>
<p>Les utilisateurs de Qt qui compilent eux-mêmes le programme doivent inclure dans leur code le script <code>./configure</code>, qui doit lever une exception C++. Sinon, les catch n'intercepteraient rien et Scribus ne s'exécuterait pas.</p>
<p>En ce moment (pour v3.2 - v3.4), KDE recommande que Qt soit compilé sans exceptions. La suggestion est mauvaise, puisqu'elle signifie que les exceptions pour allocation de mémoire erronée ne seront pas interceptées à l'aide de la méthode choisie. Comme la plupart des distributions suivent cette recommandation, cela signifie que nous (de Scribus) devrions nous priver des exceptions.</p>
<h4>Encodage du texte</h4>
<p>L'encodage du texte doit être traité avec soin. Si vous traitez du texte UTF-8 comme du latin-1, par exemple, vous risquez d'obtenir des incohérences et des erreurs. Ces problèmes sont souvent difficiles à repérer, d'où la nécessité d'écrire le code avec vigilance. Les détails de l'encodage du texte ne sont pas abordés ici, mais vous trouverez quelques précisions ailleurs dans la documentation. La partie qui suit consiste en une version antérieure du texte; vos commentaires sont bienvenus.</p>
<p>La première chose que vous devez comprendre est que les <code>QString</code> de Qt, et la plupart des autres classes de Qt, connaissent leur propre encodage et prennent soin des questions de l'encodage du texte pour vous, pour qu'ils puissent être traités comme "seulement du texte" lorsque passés dans Scribus ou à d'autres classes Qt. C'est uniquement à l'interface entre le code orienté octet et le code orienté "texte" qu'un soin particulier est requis. Ces interfaces peuvent ne pas être évidentes à trouver (la conversion implicite d'un <code>QString</code> à un <code>QCString</code> ou <code>char*</code>, par exemple, est facilement manquée) donc il faut lire avec attention et précaution la documentation de l'API.</p>
<p>Bien qu'il n'y ait pas de réel substitut à la <i>compréhension</i> des encodages de texte, voici quelques règles importantes à suivre:</p>
<p>Construisez toujours un <code>QString</code> à partir d'un octet en utilisant une des méthodes <code>QString::fromblah(...)</code> . Vous ne devriez jamais utiliser <code>QString(char*)</code> ou <code>QString(QCString)</code>. Vous devez déterminer dans quel encodage est la chaîne d'octets avec laquelle vous travaillez et utiliser l'appel correct, en examinant la documentation du système/librairie que vous appelez. Il n'y a généralement aucun moyen de dire quel est l'encodage de la chaîne en l'examinant - au mieux il s'agit de deviner. N'assumez <b>pas</b> qu'une chaîne est en utf-8 ou latin-1, parce que même si ça fonctionne pour vous, avec certains langages ce ne sera pas le cas. Pour lire des données à partir du système d'exploitation ou de librairies C, vous utiliserez en général <code>QString::fromLocal8Bit(...)</code>. En cas de doute, demandez à quelqu'un.</p>
<p>De manière similaire, vous devriez toujours utiliser les méthodes de conversion<code>QString</code> appropriées pour convertir des <code>QString</code> en chaînes d'octets (par exemple <code>QCString</code>, <code>QByteArray</code>, ou <code>char*</code>). Notez que de telles conversions peuvent survenir automatiquement, donc surveillez les conversions implicites. Pour envoyer des données aux appels systèmes ou librairies C, vous utiliserez en général <code>QString::local8Bit()</code> mais vous devez vérifier et confirmer que c'est adapté à l'appel spécifique que vous effectuez. Certains appels win32, par exemple, attendent des données UCS-2 (wchar), et certaines librairies C attendent des chaînes UTF-8 comme arguments à certaines méthodes.</p>
<p>Vous ne devez absolument jamais écrire ceci :</p>
<blockquote><table width="100%" border="1" bgcolor="#eeeeee"><tr><td border="0">
QString blah = anotherQString.utf8();
</td></tr></table></blockquote>
<p>Le code ci-dessus:</p>
<ul>
<li>Convertit anotherQString de son encodage interne UCS-2 à une chaîne d'octets UTF-8 conservée dans un <code>QCString</code>; alors</li>
<li>il la passe au constructeur <code>QString(QCString)</code> de blah;</li>
<li><code>QString(QCString)</code> décode le <code>QCString</code> passé <i>conformément au paramètre de langage par défaut de qt</i> qui est habituellement latin-1 (ne vous y fiez; cela peut avec le langage à un certain point.).</li>
</ul>
<p>Donc, vous finissez par effectuer beaucoup de travail inutile d'encodage et de décodage de la chaîne, et de plus il y aura probablement corruption en décodant une chaîne utf-8 comme latin-1. Habituellement, vous ne le noterez pas, parce que vous envoyez probablement uniquement des données ASCII, et ainsi le bug sera découvert beaucoup plus tard lorsque des personnes dans d'autres langages utilisent d'autres encodage de texte. Ces questions tendent à être difficiles à dépister.</p>
<p>Pour des raisons similaires, lorsque vous lisez ou écrivez un <code>QTextStream</code>, rappelez-vous d'appeler <code>QTextStream::setEncoding(...)</code> avant de lire/écrire toute donnée. Utilisez <code>l'opérateur<<</code> avec les<code>QString</code>, mais <code>WriteRawBytes(...)</code> pour écrire des chaîne d'octets qui sont déjà dans l'encodage correct. Les chaînes d'octets dans d'autes encodages doivent être converties à <code>QString</code> ou transcodées en utilisant <code>QTextCodec</code>. N'assumez <b>pas</b> que le <code>QTextStream</code> écrira en UTF-8. L'encodage correct dépend de l'endroit où les données vont et d'où elles viennent. Par exemple, un fichier texte seul que l'utilisateur édite devrait être dans l'encodage qui convient à sa langue. Si vous n'êtes pas sûr, demandez à quelqu'un.</p>
<p>Ne convertissez pas un QString en une chaîne d'octets lorsque vous écrivez dans un QTextStream - le QTextStream le fait pour vous avez l'opérateur<<. Par exemple:</p>
<blockquote><table width="100%" border="1" bgcolor="#eeeeee"><tr><td border="0">
QTextStream ts(&file);
// Dans ce cas, nous voulons écrire de UTF8 dans ce fichier, pas écrire dans l'encodage local une chaîne d'octets 8 bits.
ts.setEncoding(QTextStream::UnicodeUTF8);
ts << someQString.utf8();
</td></tr></table></blockquote>
<p>Il s'agit de la même erreur que dans l'exemple précédent, mais écrit d'une manière différente. À la place, vous devriez omettre le <code>.utf8()</code>.</p>
<p>La meilleure manière de gérer les encodages de texte est de les convertir en chaînes d'octets 8 bits en <code>QString</code> ou une autre classe "sécuritaire" aussitôt que possible à l'entrée, et de convertir en chaînes d'octets 8 bits le plus tard possible à la sortie. Par-dessus tout, ne le faites qu'une seule fois et surveillez les conversions implicites. Vous devez penser aux encodages en passant du texte à travers toute interface qui demande des chaînes orientées octets plutôt que des <code>QString</code>s. Rappelez-vous de <b>lire la documentation</b> des API que vous utilisez pour déterminer comment elles se comportent face à l'encodage du texte, et si vous n'êtes pas sûr, <i>demandez à quelqu'un</i>.</p>
<p>Il est fortement recommandé de lire <a href="http://doc.trolltech.com/3.3/i18n.html">http://doc.trolltech.com/3.3/i18n.html</a> pour de plus amples informations sur cette question, en particulier la section "Support for Encodings". Vous devriez également lire<a href="http://doc.trolltech.com/qq/qq05-achtung.html">Achtung! Binary and Character data</a>.</p>
<h4>Indices pour la traduction - Questions d'encodages</h4>
<p>Veuillez utiliser:</p>
<pre> "<qt>" + tr("text for translation") + "</qt>"</pre>
<p>et non pas ceci:</p>
<pre> tr("<qt>text for translation</qt>")</pre>
<p>qui est réellement ennuyeux pour les traducteurs.</p>
<p>Si vous écrivez une classe qui n'hérite pas de QObject ou d'une classe Qt, vous ne pouvez pas utiliser la méthode héritée tr(). Si vous utilisez quelque chose comme suit:</p>
<pre> QObject::tr("text for translation")</pre>
<p>remplacez-le par:</p>
<pre>QObject::tr("text for translation", "describe what is it related")</pre>
<p>Un exemple du scripteur:</p>
<pre>QObject::tr("Item is not text frame", "scripter error")</pre>
<p>Cela aide les traducteurs à situer le contexte et leur indique également ce qu'ils traduisent, même si dans certains cas les chaînes sont génériques de nature.</p>
<p>Il y a un autre point concernant les traductions, même s'il concerne plus l'encodage correct, etc.: veuillez ne pas utiliser:</p>
<pre>tr( QString("blah %1").arg(something) )</pre>
ou sinon utilisez un QString à l'intérieur d'un tr(...) . Le faire causerait une conversion implicite en
'const char*', que le QString convertirait en une chaîne d'octets latin-1. Si des caractères ne peuvent pas être représentés en latin-1, ils sont remplacés par '?'. L'usage correct est:
<pre>tr("blah %1","context").arg("something")</pre>
<p>... en exploitant le fait que tr(...) retourne un QString et que vous pouvez enchaîner les appels à QString::arg. Cela évite toute conversion implicite et évitera toute une série de bug d'encodages bizarres.</p>
<p>Si vous devez réellement traduire du texte qui ne peut pas être représenté en latin-1, vous devez utiliser <strong>QObject::trUtf8(...).</strong> Si vous voulez traduire une chaîne avec "?" (delta majuscule) à l'intérieur, par exemple, vous pourriez essayer:</p>
<p> tr("? is %1", "context")</p>
<p>ce qui est faux, non portable, peut ne pas compilé, ou pire peut donner des résultats différents sur des systèmes différents. <strong>Il faut utiliser des chaînes de caractères échappés au lieu d'inclure un caractère Unicode ou latin-1 étendu directement dans la source. </strong>La séquence d'octets UTF-8 pour ce caractère est \xce\x94, donc il faut essayer:</p>
<pre>tr("\xce\x94 is %1", "context")</pre>
<p>mais c'est également faux, parce que la séquence d'octets Unicode sera interprétée comme du latin-1 et vous obtiendrez un résultat corrompu. À la place, vous devez utiliser:</p>
<pre> trUtf8("\xce\x94 is %1", "context")</pre>
<p>De même, si vous voulez inclure le symbole © (copyright), qui existe aussi en latin-1, vous pouvez utiliser au choix:</p>
<pre>tr("something \xa9 someone", "context")</pre>
<p>ou</p>
<pre>trUtf8("something \xc2\xa9 someone", "context")</pre>
<h4>Portabilité</h4>
<p>Ne convertissez pas un pointeur en entier (int), cela cause des problèmes de portabilité où sizeof(int) != sizeof(void*). Vous devriez chercher une
autre méthode pour atteindre le résultat souhaité.</p>
<h4>Soumettre les mises à jour</h4>
<p>Les mises à jour du code doivent être envoyées à Franz, Craig Bradney, ou Paul. Les mises à jour de la documentation doivent être envoyées à Peter et Craig Bradney. Cela est sujet à changement. Les questions de scripting doivent être adressées à Petr et Craig Ringer.</p>
<p>Les mises à jour doivent être en texte seul. <code>diff -u old_file.cpp new_file.cpp >difference.diff</code> est la meilleure manière de les envoyer. Veuillez ne pas envoyer pas de mises à jour à la liste principale. Rappelez-vous d'utiliser <code>-u</code> (diff unifié) parce que les autres types de diff sont difficiles à utiliser.</p>
<p>Veuillez vous assurer lorsque vous avez changé quelque chose de mettre un commentaire juste avant le changement. Assurez-vous de mettre la date, l'auteur du changement et la raison de ce changement. Vérifiez que les commentaires incluent la ligne de code originale. Avec le temps, elles seront supprimées, mais il est utile de voir ce qui a été altéré.</p>
<p>Envoyez un seul diff pour chaque fichier modifié. Cela rend la soumission des changements beaucoup plus simple pour nous!</p>
<h4>Écrire des extensions</h4>
<p>Veuillez utiliser les fonctions actuelles et vous référer à <a href="plugin_howto.html">Plugin howto</a> pour plus d'information.</p>
<p>Tout code appelé à partir de l'application Scribus principale doit être entourée avec un <code>extern "C" { ... };</code> pour permettre à l'extension de fonctionner.
Assurez-vous que tout le code est documenté et suit les directives spécifiées plus haut.</p>
</body>
</html>m
|
