Login or register (free and only takes a few minutes) to participate in this question.
You will also have access to many other tools and opportunities designed for those who have language-related jobs (or are passionate about them). Participation is free and the site has a strict confidentiality policy.
Oi, Fábio. Sem stress. A questão aqui não é como traduzir. Eu já disse que você está corretíssimo em traduzir (num contexto de email, como lembrou o Yves), forward para encaminhar. E tampouco concordei ou não com a sugestão do Yves.
Mas, quis alertar que "Elas podem ser traduzidas sem problemas" não é verdade. E, principalmente, "o símbolo poderia ser retirado, retirando assim o atalho" é extremamente danoso, é o que pior que se pode fazer. Um tester provavelmente já testou esse software e atestou que todos os atalhos estão funcionando. Mesmo com um segundo teste para a versão localizada para pt, a estimativa de tempo para esse segundo teste seria bem baixa. Com os atalhos não funcionando, issues seriam criadas e essa estimativa iria pro espaço. Isso se um cliente não encontrasse o erro. Cara, você nem imagina a dor de cabeça que isso iria dar.
E quanto a chegar em lugar nenhum, bem... nesse caso, esse é mesmo o melhor lugar onde devemos chegar: nenhum. Ou seja, este é um caso em que o tradutor só deve traduzir com o acompanhamento do pessoal de TI, que conhece a aplicação e tomará a melhor decisão para manter a usabilidade do sistema.
Tomar cuidado também com Encaminhar! Se o SW é de mail aí sim Forward pode ser traduzido por Encaminhar! Mas pode ser também forward e backward , num scrolling, por exemplo ou num wizzard..
Cara, desse jeito a gente não vai chegar a lugar nenhum.
Se eu estivesse convicto de que traduziria "&Forward" por "Encaminhar", eu teria clicado em "Answer" e sugerido uma resposta. Como achei arriscado, pensei que fosse mais prudente postar uma entrada no painel de discussão. Eu não disse que é a única opção e que é ela que a Lilian deve usar, disse apenas que do jeito que ela colocou foi a primeira coisa que me veio à mente. Seria imprudência minha dizer que a resposta é definitiva, e inocência dela se aceitasse sem desconfiar.
E outra, que palavra vem à sua cabeça se você está num ambiente de email e vê a palavra "forward" que não "encaminhar"? Como está faltando contexto, não me arrisco a sugerir nada mais específico.
E precisa ser realmente uma palavra que COMECE com F? Ela não pode estar no meio da palavra?
Ademais, como você tocou nesse assunto, buscar em 100% dos casos uma palavra em inglês que comece com a mesma letra que sua equivalente em português é certeza de fracasso em 99,9% dos casos. Um profissional de TI DEVE auxiliar o tradutor (senão é o próprio profissional de TI que pagará - e caro - por isso).
Olá, Fábio. Desculpe qualquer coisa, mas, traduzir "Forward" para "Encaminhar" é completamente, absolutamente e inegavelmente correto. Mas, traduzir "&forward" para "Encaminhar" é arriscado (com todos os -mente). É introduzir um bug em um software já testado. O nome para isso não é outro senão sabotagem (apesar de, claro, não-intencional).
Não discordo de você. Mas nossas visões são complementares. Eu disse que traduziria por "Encaminhar" apenas porque não há mais contexto. Se o contexto da Lilian permite que se use uma palvra com "F", como sugeriu o yves la, tudo bem. Acontece que, às vezes, é simplesmente impossível de se manter uma palavra que tenha a mesma letra. O que fiz foi explicar que se pode traduzi-las, mas que é preciso levar em consideração algumas coisas.
Assim, concluíndo, tenha extremo cuidado nessa tradução e, em nenhuma hipótese, tome decisões sobre retirar ou manter um atalho sem acompanhamento dos desenvolvedores.
A cada fase, o custo de correção, como vimos, aumenta exponencialmente. Se entra nessa história um outro personagem, o tradutor, e esse inclui um bug em um software, o custo de correção (em dinheiro e em dor de cabeça também) vai ser muito maior do que os erros encontrados pelos outros três personagens. Sem falar que eles, muito provavelmente, serão responsabilizados por isso (inocentemente por que até chegar nas mãos do tradutor o bug não existia).
Isso não é exatamente sobre a tradução em questão, mas é para que vocês saibam o quanto a opção 4 pode ser prejudicial (e também por falta de espaço na text area anterior).
Sem entrar no mérito do desenvolvimento ágil ou cascata ou qualquer outra metodologia, um software é sempre idealizado por um analista, programado por um programador, testado por um testador e usado por um usuário (aqui, obviamente podem ser mais de um em cada papel e a mesma pessoa pode assumir vários papeis). Se o analista encontra uma situação que pode causar problemas (nesse caso ainda não pode nem ser chamado de bug) e a ataca, a tendência é que esse problema não cause muitos danos ao trabalho dos outros personagens dessa estória. Se o programador comete um erro e o corrige, o trabalho do testador e do usuário são simplificados (embora talvez haja alguma discussão com o analista). Se o tester encontra uma issue, envolve quem está antes dele, mas o usuário ainda foi preservado, apesar de que, quanto mais issues o testador for capaz de encontrar, mais o sofware pode atrasar. Se nenhum desses três for capaz de encontrar um erro, e este chegar ao usuário, todos podem se preparar para muita dor de cabeça.
O Daniel está certo; alguém de TI vai ter que revisar para eliminar as repetições de letras devidas à tradução;nmo seu caso, traduza normalmente, mantendo , claro, o & na frente da palavra.
Não no sentido de que não possam ser traduzidas, mas, sim ao dizer que podem ser traduzidas sem problemas. É preciso muito, muito cuidado ao traduzir esse tipo de coisa. Se você pudesse ser acompanhada por alguém do time de desenvolvimento do software a ser traduzido seria bem melhor.
Existem várias coisas a ser consideradas:
1) O conhecimento prévio dos usuários - Exemplo: existem versões do Office em em que o comando "Selecionar tudo" é acessado através do atalho "Ctrl+A" - all, em outras o atalho é "Ctrl+T" - tudo. Isso causa extremo desconforto em quem está bem acostumado a usar uma versão e por um motivo qualquer tem que usar outra.
2) Se escolhermos usar &Encaminhar, podemos criar um conflito de atalho com algum outro comando (que também começe com E).
3) Se escolhermos outra letra do meio da palavra (sabemos que isso existe), que letra escolheremos? Ninguém melhor que o designer da interface (que, pelo menos em teoria, deve conhecer seu público) para decidir se Encaminhar casa melhor com E&ncaminhar ou com En&caminhar.
4) Se escolhermos não fazer atalho algum, será, sinceramente, o pior dos piores dos mundos. Introduziremos um bug numa fase tardia do desenvolvimento.
Elas podem ser traduzidas sem problemas. O símbolo & representa um atalho que é acessado por meio da letra seguinte, nesse caso a letra F. No caso de &Forward, dependendo do contexto, a minha primeira opção seria Encaminhar, que não possui a letra F. Nesse caso, o símbolo poderia ser retirado, retirando assim o atalho.
Automatic update in 00:
Answers
4 mins confidence:
&forward
&Frente
Explanation: Parece ítens de menu de um caso de uso;
deve, portanto deixar o & na frente da palavra traduzida.
yves la Local time: 17:26 Specializes in field Native speaker of: French, Portuguese PRO pts in category: 16