O esplendor e a pobreza da literatura traduzida



"É melhor não ler nada do que isso."

Você costuma ler literatura técnica? É literatura e não manuais no hub ou relatórios de bugs no github? E quando você lê, em qual idioma você prefere fazer isso (se você pode escolher, é claro)? Qual versão você prefere, original em russo ou em inglês?

Em alguns círculos, há uma opinião esnobe e elitista de que ler (assistir a um filme, jogar jogos) é apenas na linguagem de Shakespeare e nada mais. Para muitos outros, é bastante difícil verificar o primeiro sobre se são simplesmente arrogantes ou se há algum problema sério com a literatura técnica traduzida. Banal por causa das habilidades de idioma pobres no original.


Outra complicação é adicionada pela área de conhecimento em torno da qual tudo isso acontece. Muitas vezes, não é fácil reconhecer a fronteira em que um mal-entendido de estruturas de dados complexas ou novas metodologias de desenvolvimento entra em um mal-entendido do texto que o tradutor compôs. Aqui, por exemplo, está uma citação de um livro bastante recente:

No ensino médio, ele começou a criar sites dinâmicos quando a Internet ainda era relativamente jovem. Ele então desenvolveu um software para o setor de saúde e telecomunicações em uma empresa local, estudando ciência da computação na Universidade de Ljubljana, na Eslovênia. No final, ele passou a trabalhar na Red Hat, desenvolvendo inicialmente a implementação de código aberto da API do Google App Engine, que usava produtos JBoss Red Hat de nível intermediário. Ele também trabalhou ou participou de projetos como CDI / Weld, Infinispan / Jboss DataGrid, etc.
Desde o final de 2014, ele faz parte da equipe de Red Hat Cloud Enablement, onde suas responsabilidades incluem atualizar novos desenvolvimentos no Kubernetes e tecnologias relacionadas e maximizar o potencial do Kubernetes e do OpenShift em software de nível intermediário.

Se você não ficou doente com a passagem "desenvolvendo inicialmente uma implementação de código aberto da API do Google App Engine", provavelmente terá dúvidas sobre que tipo de "empresa de nível intermediário" surgiu subitamente. Ou o que, por exemplo, significa "atualizar novos desenvolvimentos". Vá para o texto original:

Desde o final de 2014, ele faz parte da equipe de habilitação em nuvem da Red Hat, onde suas responsabilidades incluem manter-se atualizado sobre novos desenvolvimentos no Kubernetes e tecnologias relacionadas e garantir que o software de middleware da empresa utilize os recursos do Kubernetes e do OpenShift em todo o seu potencial. .

Acontece que, de fato, essa não é uma empresa de nível médio. E estamos falando do middleware da empresa. E ninguém o forçou a "atualizar novos desenvolvimentos" - na verdade, ele precisa estar constantemente a par de todos os novos desenvolvimentos.

Ou outro exemplo, de outro livro:
Em 2007, entrei em contato com os executivos do Yahoo sobre uma posição relacionada a "um pouco de desenvolvimento" e "um pouco de exploração". Tratava-se da vaga de um engenheiro de serviço sênior responsável pela criação e manutenção de um data warehouse de dados / chave com múltiplos arrendatários, hospedado, distribuído e geograficamente replicado chamado Sherpa.

“Um data warehouse com múltiplos inquilinos, hospedado, distribuído e replicado geograficamente” - você pode entender imediatamente o que exatamente é essa bagunça ou precisará traduzi-la novamente para o inglês primeiro para perceber quais termos específicos foram tão fascinantemente localizados para os grandes e poderosos?

Isso ajuda a um aprendizado simples? Honestamente, não de verdade. Deseja gastar um dinheiro considerável, em geral, em uma densa selva lingüística, nas profundezas das quais há uma cabana com preciosas tábuas de barro? Eu não quero Gostaria de outro: ter acesso a um conjunto de textos simples e compreensíveis, dos quais a parte mais difícil seriam as idéias apresentadas pelo autor, e não as estranhas construções de linguagem construídas pelo tradutor.

Tentando descobrir por que aconteceu


Como isso aconteceu? Sempre foi assim? De alguma forma, podemos evitar esses incidentes no futuro? Eu sugeriria deixar questões de baixo nível de competência linguística fora do escopo desta discussão, porque não podemos influenciá-lo diretamente. Existem apenas bons tradutores, mas não muito bons. Como programadores. E os dentistas. E, em geral, qualquer um.

Mas que dificuldades adicionais os bilíngues, mesmo seriamente entendidos nos dois idiomas, encontram quando decidem começar a traduzir literatura de TI? Nos últimos 10 a 15 anos, a tecnologia da informação cresceu tremendamente, tanto na horizontal quanto na vertical. Um grande número de novas profissões, cada uma com sua própria especialização. Devido à inércia linguística da percepção humana, muitas profissões relacionadas usam os mesmos termos, os quais, no entanto, têm significados diferentes. E, para entender como usar e traduzir adequadamente um termo específico, você precisa não apenas de um bom domínio do idioma, mas também de um bom entendimento de uma área e subseções específicas do setor de informação.

Grosso modo, ao mesmo tempo em que a forma universal do "programador" (que eleva o servidor e escreve o script e o conector na placa-mãe para re-soldar) deixou de existir, o "tradutor técnico" universal também deixou de existir. Portanto, agora não basta ser "apenas um tradutor". Seria bom ser, antes de tudo, um especialista técnico que, além disso, é fluente em idiomas. E isso, como você sabe, é uma história completamente diferente. Nem todos os bons especialistas técnicos possuem habilidades linguísticas suficientes. E se o fizerem, está longe de ser sempre interessante para eles se engajarem nesse tipo de trabalho - eles são mais atraídos por realizações técnicas do que humanitárias.

"E antes, antes, como era bom!" c)


A metodologia de "traduzir" novas palavras agora é difundida simplesmente substituindo o inglês existente. Por exemplo, confirmar (a "fixação" da tradução mais ou menos normal já está quase em toda parte), construir, implantar - a lista pode ser mantida infinitamente. Muito provavelmente, essa situação se desenvolveu devido ao ritmo acelerado do surgimento de novas tecnologias. A tradução, como qualquer outro sistema reativo, simplesmente não consegue acompanhar o ritmo determinado. E quando qualquer texto chegasse à tradução pelos profissionais, os técnicos já haviam formado um jargão profundamente arraigado - e a tradução do termo "confirmar" com a palavra "fixação" faria mal aos olhos do leitor.

Mas isso não significa que seja necessário suportar uma situação semelhante! Existem excelentes exemplos de tradução de alta qualidade e bem pensada. Nos exemplos, podemos pegar "thread" - "thread". A tradução literal - "thread" - sugere que, muito provavelmente, no início da formação da terminologia inglesa, havia uma associação com um tear com um monte de threads esticados em paralelo. No idioma russo, a "execução multi-thread" parece muito incompreensível, mas a "execução multi-thread" é ​​uma questão completamente diferente. Aqui a semântica é preservada, porque o fluxo é um movimento constante (cálculo), que o encadeamento não possui. E isso soa bastante familiar ("os carros se movem em várias correntes ao longo da rodovia").

Outro exemplo de um termo bem localizado é "pipeline" = "pipeline". "Pipeline" é um pipeline, a essência do termo (pipeline de renderização, pipeline de CI / CD) é o processo de processamento, onde algumas ações ocorrem em cada nó: dependendo das condições, os "portões" podem ser fechados e abertos e o processamento passa por outro " o cachimbo ". Em todo o pipeline, pode ser colocado algum tipo de "sensor" que monitora o processo. A palavra foi escolhida muito bem, mas a tradução direta, "pipeline de renderização" não parece concisa o suficiente. “Transportador”, neste caso, é uma palavra perfeitamente compatível, exceto com uma tonalidade diferente (transmitir - transmitir, mas “flui por si mesma” através de tubos), mas sem perder o significado principal.

Como viver mais?


O que oferecemos da nossa parte? Oferecemos a fusão única de competências técnicas com habilidades linguísticas de qualidade. Estamos prontos para dedicar tempo aos nossos especialistas técnicos para trazer o conteúdo semântico dos textos traduzidos para perfeitas condições.

No processo de trabalhar com traduções, temos que gastar muito tempo em discussões sobre o tópico de como localizar determinados termos. Nesse sentido, seria bom começar a compilar um glossário comum de nova terminologia, para uso subsequente em nossas próprias traduções e traduções de nossos colegas. Este glossário não deve ser apenas uma coleção de palavras; Antes de tudo, é necessário explicar por que esse termo foi escolhido, por que é melhor que um termo semelhante, como ele se encaixa no contexto da linguagem - bem, e em nossa tradição técnica. Sem traços cegos e impensados ​​da terminologia estrangeira.

Este é o glossário que planejamos fazer. Para iniciantes, aparentemente, esta será uma série de artigos com uma visão geral das coleções de termos, a história de sua aparência e desenvolvimento, bem como os objetos por trás deles. Posteriormente, cada livro de nossa editora terá uma seção separada descrevendo como trabalhamos na terminologia usada neste livro. À medida que o material é recrutado, é provável que seja publicada uma publicação separada sobre os problemas do idioma russo na tradução moderna da tecnologia da informação. Enquanto isso, você pode encomendar nosso primeiro livro, "Designing Event-Oriented Systems", de Ben Stopford.

E que pensamentos você tem sobre a situação na literatura técnica traduzida? Existem termos especialmente importantes para o coração que, na sua opinião, foram perfeitamente traduzidos para o russo? Ou talvez haja pessoas especialmente odiadas? :)

Source: https://habr.com/ru/post/pt458758/


All Articles