--Danarmk 9 septembre 2007 à 14:38 (CEST):
Je ne voyais pas comment m'en sortir entre "Foreword" et "Preface". J'ai donc décidé de mettre "Préface" pour "Foreword" et "Introduction" pour "Preface" ( vous suivez ? ).
--Penguin 10 septembre 2007 à 10:45 (CEST):
Autre possibilité pour foreword : avant-propos. Mais il est clair que foreword et preface, c'est quasiment équivalent en anglais.
--Danarmk 10 septembre 2007 à 12:23 (CEST):
Avant-propos ? Pourquoi pas, je n'y avait pas pensé. Mais il reste que pour respecter le même modèle des Framabook ( ce livre est destiné à devenir un Framabook, je rappelle ), il n'y a pas d'avant-propos.
A bad Frequently Asked Questions (FAQ) sheet is one that is composed not of the questions people actually asked, but of the questions the FAQ's author wished people had asked. Perhaps you've seen the type before:
Q: How can I use Glorbosoft XYZ to maximize team productivity?
A: Many of our customers want to know how they can maximize productivity through our patented office groupware innovations. The answer is simple: first, click on the “File” menu, scroll down to “Increase Productivity”, then…
Une mauvaise FAQ n'est pas composée des questions que les personnes posent, mais de celles que l'auteur de la FAQ voudrait que les personnes posent. Peut-être avez-vous vu ce type de FAQ :
Q: Comment peut-on utiliser Glorbosoft XYZ pour maximiser la productivité en équipe ?
R: Beaucoup de nos clients veulent savoir comment maximiser la productivité avec notre nouvelle suite office brevetée. La réponse est simple : cliquez sur le menu "Fichier", ensuite, trouvez "Améliorer la productivité" plus bas, ensuite...
The problem with such FAQs is that they are not, in a literal sense, FAQs at all. No one ever called the tech support line and asked, “How can we maximize productivity?”. Rather, people asked highly specific questions, like, “How can we change the calendaring system to send reminders two days in advance instead of one?” and so on. But it's a lot easier to make up imaginary Frequently Asked Questions than it is to discover the real ones. Compiling a true FAQ sheet requires a sustained, organized effort: over the lifetime of the software, incoming questions must be tracked, responses monitored, and all gathered into a coherent, searchable whole that reflects the collective experience of users in the wild. It calls for the patient, observant attitude of a field naturalist. No grand hypothesizing, no visionary pronouncements here—open eyes and accurate note-taking are what's needed most.
Le problème avec de telles FAQs, c'est qu'elles ne sont pas du tout, au sens propre, des FAQs. Personne n'a appelé le support technique et demandé "Comment pouvons-nous améliorer la productivité ?". Au lieu de ça, les personnes posent des question très précises, telles que "Comment pouvons-nous configurer le système de calendrier pour envoyer les rappels deux jours en avance au lieu de 24 heures ?", etc.. Hélas, il est tellement plus facile d'imaginer des questions que de trouver celles qui sont vraiment fréquemment posées. Rédiger une vraie FAQ requiert un effort continu et une bonne organisation : tout le long de la vie du logiciel, les questions posées ainsi que leur réponses doivent être suivies, puis rassemblées et organisées de façon claire et cohérente dans un tout qui doit refléter l'expérience des utilisateurs. Cela nécessite d'être patient et observateur, tel un naturaliste. Ici, pas de grandes théories ni de visionaires, ce qu'il faut avant tout, c'est ouvrir les yeux et prendre des notes.
What I love about this book is that it grew out of just such a process, and shows it on every page. It is the direct result of the authors' encounters with users. It began with Ben Collins-Sussman's observation that people were asking the same basic questions over and over on the Subversion mailing lists: What are the standard workflows to use with Subversion? Do branches and tags work the same way as in other version control systems? How can I find out who made a particular change?
Ce que j'aime à propos de ce livre, c'est qu'il a bien suivi ce procédé, et le montre sur chacune de ses pages. C'est le résultat direct de la rencontre des auteurs et des utilisateurs. Cela commença avec ce que Ben Collins-Sussman avait vu : les personnes reposaient constamment les mêmes questions de base sur la mailing list de Subversion : Quelles sont les procédures pour travailler avec Subversion ? Est-ce que les branches et les tags fonctionnent comme dans les autres systèmes de gestion de version ? Comment est-ce que je peux trouver qui a fait telle ou telle modification ?
Frustrated at seeing the same questions day after day, Ben worked intensely over a month in the summer of 2002 to write The Subversion Handbook, a sixty page manual that covered all the basics of using Subversion. The manual made no pretense of being complete, but it was distributed with Subversion and got users over that initial hump in the learning curve. When O'Reilly and Associates decided to publish a full-length Subversion book, the path of least resistance was obvious: just expand the Subversion handbook.
Frustré de voir revenir les mêmes questions jour après jour, Ben travailla d'arrache pied pendant un mois de l'été 2002 pour ecrire The Subversion Handbook, un manuel de soixante pages couvrant toutes les bases de Subversion. Le manuel ainsi écrit n'avait pas la prétention d'être complet, mais il fut distribué avec Subversion pour aider les utilisateurs à faire les premiers pas dans l'apprentissage de Subversion. Quand O'Reilly and Associates décidèrent de publier livre complet sur Subversion, la voie la plus facile était la plus évidente : simplement améliorer The Subversion Handbook.
The three co-authors of the new book were thus presented with an unusual opportunity. Officially, their task was to write a book top-down, starting from a table of contents and an initial draft. But they also had access to a steady stream—indeed, an uncontrollable geyser—of bottom-up source material. Subversion was already in the hands of thousands of early adopters, and those users were giving tons of feedback, not only about Subversion, but about its existing documentation.
--Danarmk 17 septembre 2007 à 13:18 (CEST):
Je ne suis pas sûr de la traduction de "top-down". Est-ce que ça veut dire "de haut en bas" ? Quelqu'un saurait-il ici ?
Il semble qu'ici on fasse allusion au concept de « développement descendant » qui consiste à commencer par développer les modules de niveau élevé pour ensuite aller vers les modules de bas niveau. La conception "bottom-up" est l'inverse ( Conception ascendante ) et consiste à concevoir son système en concevant d'abord les fonctions élémentaires et ensuite les fonctions de plus en plus spécifiques.
J'avoue que ça ne m'aide pas à suggérer une traduction mais ça explique le sens général ....
Une opportunité inhabituelle se présenta aux trois co-auteurs de ce nouveau livre. Officiellement, leur tâche était de d'écrire un livre "académique" en partant d'une table des matières et d'une ébauche de plan. Mais ils avaient aussi accès à l'immense flux des retours sur le terrain. Subversion était déjà dans les mains des premiers milliers d'utilisateurs, et ces derniers renvoyaient des tonnes de commentaires, pas seulement sur Subversion, mais aussi sur sa documentation.
During the entire time they wrote this book, Ben, Mike, and Brian haunted the Subversion mailing lists and chat rooms incessantly, carefully noting the problems users were having in real-life situations. Monitoring such feedback was part of their job descriptions at CollabNet anyway, and it gave them a huge advantage when they set out to document Subversion. The book they produced is grounded firmly in the bedrock of experience, not in the shifting sands of wishful thinking; it combines the best aspects of user manual and FAQ sheet. This duality might not be noticeable on a first reading. Taken in order, front to back, the book is simply a straightforward description of a piece of software. There's the overview, the obligatory guided tour, the chapter on administrative configuration, some advanced topics, and of course a command reference and troubleshooting guide. Only when you come back to it later, seeking the solution to some specific problem, does its authenticity shine out: the telling details that can only result from encounters with the unexpected, the examples honed from genuine use cases, and most of all the sensitivity to the user's needs and the user's point of view.
--Danarmk 21 septembre 2007 à 14:11 (CEST):
Houla, je m'en sors mieux avec les truc plus techniques (on fait alors du franglais :D ). Là, les "bedrock of experience" et les "sands of wishful thinking", ainsi que "honed", où je ne suis pas sur de ce que j'ai traduit...
Pour le "bedrock" je mettrais plutôt « Socle » le "bedrock" c'est la roche mère, le socle rocheux en place.
J'aime bien les « les sables mouvants des souhaits »
Pour "honed" il y à un sens de « récolté » ou « butiné » si ça peut aider ...
Pendant que Ben, Mike et Brian écrivaient ce livre, ils suivirent la mailing list de Subversion et les salons de "chat" constamment, notant consciencieusement les problèmes que rencontraient les utilisateurs dans la réalité. Traquer ces retours d'expériences était de toutes façons une partie de leur travail à CollabNet, et cela leur donna un énorme avantage quand ils commencèrent à documenter Subversion. Le livre qu'ils ont écrit a été gravé au burin de l'expérience, pas avec le fer blanc des bonnes intentions. Il associe les meilleurs aspects du mode d'emploi et de la FAQ. Cette association ne saute pas immédiatement aux yeux. Pris dans l'ordre, du début jusqu'à la fin, ce livre décrit de manière simple un logiciel. Il y a la vue d'ensemble, l'incontournable visite guidée, le chapitre sur la configuration et l'administration, quelques sujets avancés, et bien évidemment une liste complète des commandes ainsi que la liste des problèmes couramment rencontrés. Mais c'est quand on revient chercher dans ce livre une réponse à un problème spécifique que sa vraie nature se révèle : les détails précisés ne peuvent provenir que de cas concrèts et inattendus, les exemples sont issus de situations réelles, et surtout l'attention est portée aux besoins réels de l'utilisateur et à son point de vue.
Of course, no one can promise that this book will answer every question you have about Subversion. Sometimes, the precision with which it anticipates your questions will seem eerily telepathic; yet occasionally, you will stumble into a hole in the community's knowledge, and come away empty-handed. When this happens, the best thing you can do is email <users (at) subversion (point) tigris (point) org> and present your problem. The authors are still there, still watching, and they include not just the three listed on the cover, but many others who contributed corrections and original material. From the community's point of view, solving your problem is merely a pleasant side effect of a much larger project—namely, slowly adjusting this book, and ultimately Subversion itself, to more closely match the way people actually use it. They are eager to hear from you not merely because they can help you, but because you can help them. With Subversion as with all active free software projects, you are not alone.
Let this book be your first companion.
Bien sûr, personne ne peut affirmer que ce livre répondra à toutes vos questions sur Subversion. De temps en temps, la précision avec laquelle il anticipe vos question vous semblera presque télépathique ; mais d'autres fois, vous serez face à un vide dans la connaissance de la communauté sur Subversion, et vous reviendrez les mains vides. Quand cela arrive, le mieux que vous puissiez faire est d'envoyer un e-mail à <users (at) subversion (point) tigris (point) org> (le mieux est de le rédiger en anglais) et présenter votre problème. Les auteurs sont encore là, regardant, et "les auteurs" n'inclut pas seulement les trois cités plus haut, mais beaucoup d'autres qui ont contribué en corrigeant et enrichissant ce livre. Pour la communauté, résoudre votre problème est un effet secondaire plaisant dans un grand projet, notament pour corriger ce livre, et finalement Subversion lui-même, pour encore mieux coller avec l'utilisation que les personnes en font. Il y a des personnes désireuses de vous entendre, pas seulement parce qu'elles peuvent vous aider, mais aussi parce que vous pouvez les aider. Avec Subversion comme avec tous les les projets de logiciels libres qui sont actifs, vous n'êtes pas seuls.
Laissez ce livre être votre premier guide.
--Danarmk 22 septembre 2007 à 13:52 (CEST):
Je ne pense pas que cette dernière phrase soit la meilleure traduction, mais je n'arrive pas à trouver mieux pour l'instant.
--Hotshot92 20 novembre 2008 à 22:52 (CEST):
Commençons le debut du chemin ensemble ?
