"Il vaut mieux ne pas lire du tout que ça."Lisez-vous souvent la littérature technique? C'est de la littérature, et non des manuels sur le hub ou des rapports de bugs sur le github? Et quand vous lisez, dans quelle langue préférez-vous faire cela (si vous le pouvez, bien sûr)? Quelle version préférez-vous, originale en russe ou en anglais?
Dans certains cercles, il y a une opinion que snob et élitiste que la lecture (regarder un film, jouer à des jeux) est uniquement dans la langue de Shakespeare et rien d'autre. Pour beaucoup d'autres, il est assez difficile de vérifier la première sur le sujet pour savoir s'ils sont simplement arrogants ou s'il y a de sérieux problèmes avec la littérature technique traduite. Trite en raison de faibles compétences linguistiques dans l'original.
Une autre complication est ajoutée par le domaine de connaissance autour duquel tout cela se produit. Il n'est souvent pas facile de reconnaître la frontière où un malentendu sur des structures de données complexes ou de nouvelles méthodologies de développement elles-mêmes va dans un malentendu du texte que le traducteur a composé. Voici, par exemple, une citation d'un livre assez récent:
Au lycée, il a commencé à créer des sites Web dynamiques alors qu'Internet était encore relativement jeune. Il a ensuite développé un logiciel pour l'industrie des soins de santé et des télécommunications dans une entreprise locale, étudiant l'informatique à l'Université de Ljubljana, en Slovénie. Au final, il a ensuite travaillé chez Red Hat, développant initialement l'implémentation open source de l'API Google App Engine, qui utilisait des produits Red Hat JBoss de milieu de gamme. Il a également travaillé ou participé à des projets tels que CDI / Weld, Infinispan / Jboss DataGrid, etc.
Depuis la fin de 2014, il fait partie de l'équipe Red Hat Cloud Enablement, où ses responsabilités comprennent la mise à jour des nouveaux développements dans Kubernetes et les technologies connexes et la maximisation du potentiel de Kubernetes et d'OpenShift dans les logiciels de niveau intermédiaire.
Si vous n'êtes pas tombé malade du passage "développer initialement une implémentation open source de l'API Google App Engine", alors vous avez probablement des questions sur le type de "société de niveau intermédiaire" qui est soudainement apparu. Ou ce qui, par exemple, signifie «mettre à jour de nouveaux développements». Revenez au texte d'origine:
Depuis la fin de 2014, il fait partie de l'équipe Cloud Enablement de Red Hat, où ses responsabilités incluent de rester à jour sur les nouveaux développements de Kubernetes et des technologies connexes et de s'assurer que le logiciel middleware de l'entreprise utilise les fonctionnalités de Kubernetes et d'OpenShift à leur plein potentiel. .
Il s'avère, en fait, que ce n'est pas une entreprise de niveau intermédiaire. Et nous parlons du middleware de l'entreprise. Et personne ne l'a forcé à «mettre à jour les nouveaux développements» - en fait, il doit être constamment informé de tous les nouveaux développements.
Ou un autre exemple, d'un autre livre:
En 2007, j'ai contacté des dirigeants de Yahoo au sujet d'un poste lié à «un peu de développement» et «un peu d'exploitation». Il s'agissait de la vacance d'un ingénieur de service senior responsable de la création et de la maintenance d'un entrepôt de données clé / valeur à locataires multiples, hébergé, distribué et répliqué géographiquement appelé Sherpa.
«Un entrepôt de données à locataires multiples, hébergé, distribué et géographiquement répliqué» - vous pouvez immédiatement comprendre ce qu'est exactement ce gâchis, ou vous devrez d'abord le traduire en anglais pour comprendre quels termes familiers étaient si glamourement localisés aux grands et aux puissants?
Est-ce que cela aide à un apprentissage simple? Honnêtement, pas vraiment. Voulez-vous dépenser beaucoup d'argent, en général, dans une jungle linguistique dense, au fond de laquelle se trouve une cabane avec des tablettes d'argile précieuses? Je ne veux pas. J'aimerais un autre: avoir accès à un ensemble de textes simples et compréhensibles, dont la partie la plus difficile serait les idées présentées par l'auteur, et non des constructions linguistiques étranges construites par le traducteur.
Essayer de comprendre pourquoi c'est arrivé
Comment est-ce arrivé? Ça a toujours été comme ça? Pouvons-nous en quelque sorte éviter de tels incidents à l'avenir? Je suggérerais de laisser les questions d'un faible niveau de compétence linguistique en dehors du cadre de cette discussion, car nous ne pouvons pas directement l'influencer directement. Il n'y a que de bons traducteurs, mais pas très bons. Comme les programmeurs. Et les dentistes. Et en général, n'importe qui.
Mais quelles difficultés supplémentaires les bilingues, même très avertis, rencontrent-ils dans les deux langues lorsqu'ils décident de commencer à traduire de la littérature informatique? La technologie de l'information au cours des 10 à 15 dernières années s'est considérablement développée, tant horizontalement que verticalement. Un grand nombre de nouvelles professions, chacune avec sa propre spécialisation. En raison de l'inertie linguistique de la perception humaine, de nombreuses professions apparentées utilisent les mêmes termes, qui ont cependant des significations différentes. Et pour comprendre comment utiliser et traduire correctement un terme particulier, vous avez besoin non seulement d'une bonne maîtrise de la langue, mais également d'une bonne compréhension d'un domaine spécifique et de sous-sections de l'industrie de l'information.
Grosso modo, en même temps que la forme universelle du «programmeur» (pour élever le serveur et écrire le script, et le conder de la carte mère à ressouder) a cessé d'exister, le «traducteur technique» universel a cessé d'exister. Par conséquent, maintenant, il ne suffit plus d’être «juste un traducteur». Ce serait bien d'être, tout d'abord, un spécialiste technique qui, en plus, parle couramment les langues. Et comme vous le savez, c'est une histoire complètement différente. Tous les bons spécialistes techniques n'ont pas des compétences linguistiques suffisantes. Et s'ils le font, il est loin d'être toujours intéressant pour eux de s'engager dans ce type de travail - ils sont plus attirés par les réalisations techniques qu'humanitaires.
"Et avant, avant, comme c'était bon!" (c)
La méthodologie de «traduction» de nouveaux mots est maintenant largement répandue en remplaçant simplement l'anglais existant. Par exemple, commit (la «fixation» de traduction plus ou moins normale est déjà presque partout évincée), build, deploy - la liste peut être maintenue à l'infini. Très probablement, cette situation s'est développée en raison de l'accélération du rythme de l'émergence de nouvelles technologies. La traduction, comme tout autre système réactif, ne peut tout simplement pas suivre le rythme donné. Et au moment où un texte est parvenu à la traduction par des professionnels, les techniciens avaient déjà formé un jargon profondément enraciné - et la traduction du terme «commettre» avec le mot «fixation» blesserait l'œil du lecteur.
Mais cela ne signifie pas du tout qu'il faille supporter une situation similaire! Il existe d'excellents exemples de traduction de haute qualité et bien pensée. À partir des exemples, nous pouvons prendre «fil» - «fil». La traduction littérale - «thread» - suggère que, très probablement, à l'aube de la formation de la terminologie anglaise, il s'agissait d'une association avec un métier à tisser avec un tas de fils étirés en parallèle. Dans la langue russe, «l'exécution multi-thread» semble très incompréhensible, mais «l'exécution multi-thread» est une question complètement différente. Ici, la sémantique est préservée, car le flux est un mouvement constant (calcul), que le thread n'a pas. Et cela semble assez familier («les voitures se déplacent dans plusieurs cours d'eau le long de l'autoroute»).
Un autre exemple de terme bien localisé est «pipeline» = «pipeline». "Pipeline" est un pipeline, l'essence du terme (pipeline de rendu, pipeline CI / CD) est le processus de traitement, où une action a lieu sur chaque nœud: selon les conditions, les "vannes" peuvent être fermées et ouvertes et le traitement se poursuit par un autre " le tuyau. " Tout au long du pipeline, une sorte de «capteurs» peut être placé pour surveiller le processus. Le mot a été très bien choisi, mais la traduction directe, "pipeline de rendu" ne semble pas assez concise. «Convoyeur» dans ce cas est un mot parfaitement assorti, sauf avec une nuance différente (transporter - transporter, mais «coule par lui-même» à travers les tuyaux), mais sans perdre le sens principal.
Comment vivre plus loin?
Que proposons-nous de notre côté? Nous offrons la fusion unique de compétences techniques avec des compétences linguistiques de qualité. Nous sommes prêts à consacrer du temps à nos spécialistes techniques pour mettre en parfait état le contenu sémantique des textes traduits.
Dans le processus de travail sur les traductions, nous devons consacrer beaucoup de temps aux discussions sur le thème de la localisation de certains termes. À cet égard, il serait bon de commencer à compiler un glossaire commun de la nouvelle terminologie, pour une utilisation ultérieure dans nos propres traductions et les traductions de nos collègues. Ce glossaire ne doit pas être simplement une collection de mots; Tout d'abord, il est appelé à expliquer pourquoi un tel terme a été choisi, pourquoi il est meilleur que des termes similaires, comment il s'inscrit dans le contexte linguistique - enfin, et notre tradition technique. Sans traçage aveugle et irréfléchi de terminologie étrangère.
Voici le glossaire que nous prévoyons de faire. Pour commencer, ce sera apparemment une série d'articles avec un aperçu des collections de termes, l'histoire de leur apparition et de leur développement, ainsi que les objets derrière eux. Par la suite, chaque livre de
notre maison d'édition aura une section distincte décrivant comment nous avons travaillé sur la terminologie utilisée dans ce livre. Au fur et à mesure que le matériel est recruté, une publication distincte devrait être publiée sur les problèmes de la langue russe dans la traduction moderne des technologies de l'information. En attendant, vous pouvez
précommander notre premier livre, «Designing Event-Oriented Systems», de Ben Stopford.
Et que pensez-vous de la situation dans la littérature technique traduite? Y a-t-il des termes qui sont particulièrement chers au cœur et qui, à votre avis, ont été parfaitement traduits en russe? Ou peut-être qu'il y en a surtout des détestés? :)