Os princípios de documentação e localização ou como obter uma boa localização a um custo mínimo

Olá pessoal!

Meu nome é Denisov Alexander. Trabalho na Naumen e sou responsável por documentar e localizar o produto de software Naumen Contact Center (NCC).

Neste artigo, falarei sobre os problemas que encontramos ao localizar o NCC em inglês e alemão e como resolvemos esses problemas. É claro que hoje resolvemos longe de todas as nossas tarefas e, muito provavelmente, esse processo é geralmente interminável. O artigo considera a visão de todo o processo como um todo e os princípios aos quais tentamos aderir ou aos quais estamos começando a tentar aplicar. O material será útil para aqueles que estão começando a projetar software, planejam localizá-lo ou já enfrentam problemas, mas ainda não sabem como resolvê-los.

1. Introdução

Geralmente, uma empresa pensa na localização de software quando o produto está pronto e a documentação foi escrita para ele. E também costuma ser tarde demais para fazer algo para obter uma boa localização em um curto espaço de tempo e não gastar uma quantidade enorme de recursos nela.

É impossível escrever em detalhes sobre todos os problemas e dificuldades em um artigo, por isso vou falar um pouco sobre as principais etapas da documentação e localização e abordar várias, na minha opinião, as questões mais importantes:

• Quais estágios do ciclo de vida de desenvolvimento de software afetam a qualidade da documentação e localização?
• O que e quando fazer em cada etapa?
• Quais abordagens, recursos de ferramentas podem ser usados ​​para resolver problemas e problemas de cada estágio?
• Como uma organização. A estrutura afeta a documentação e a localização?
• Como organizar o recebimento de feedback dos usuários da documentação?
• Como economizar tempo e custos financeiros em cada etapa?

Com base em meus muitos anos de experiência na documentação e localização de NCC, tentarei responder a essas perguntas.

Características do NCC e do processo de desenvolvimento

O Naumen Contact Center é um software sofisticado para organizar grandes centros de contato corporativos ou de terceirização.

Qual é a dificuldade de documentar e localizar este sistema:

1. O sistema não está nublado.
2. Configuração complexa, muitas integrações com vários sistemas.
3. Suporte para várias versões.
4. Como resultado dos parágrafos 1 a 3, temos implementações e atualizações complexas. Cada cliente tem sua própria versão, sua própria configuração e integração com vários sistemas.
5. O sistema não é massivo; é usado apenas por grandes empresas. Portanto, o número de clientes não é muito grande em comparação com pequenos produtos de massa.
6. Um grande número de termos específicos.
7. Modelo multifuncional. E isso significa que a documentação e a interface devem ser adaptadas às características de cada função (nível de conhecimento e recursos das tarefas).
8. As interfaces do sistema contêm cerca de 30.000 linhas de texto e cerca de 3.000 páginas de documentação técnica complexa são gravadas.
9. Lançamentos são lançados 2-3 vezes por ano.
10. Após cada release, aproximadamente 10% do texto e da documentação da interface são atualizados e complementados.
11. 3 idiomas: russo (fonte), inglês e alemão.

Ciclo de vida do desenvolvimento

Vamos dar uma olhada no ciclo de vida do desenvolvimento de software e selecionar apenas os estágios relacionados à documentação e localização:

• Desenvolvimento de recursos. Como parte dessa fase, são desenvolvidos textos para a interface.
• Documentação Como parte dessa fase, a documentação é desenvolvida, incluindo a criação de capturas de tela e outras imagens.
• Localização da interface em vários idiomas.
• Tradução da documentação para outros idiomas, incluindo localização de capturas de tela e outras imagens.

Agora vamos imaginar que um pequeno erro foi cometido na interface. Aplica-se automaticamente a cada estágio, a várias versões e idiomas.



Erros adicionais podem aparecer em cada estágio, ou seja, como resultado, podemos obter um grande número de erros. Erros menores na interface provavelmente nunca serão corrigidos; sempre há tarefas mais importantes. E se você editá-las, o custo dessas edições será muito alto, pois você terá que percorrer toda a cadeia, todas as versões e idiomas. E quanto mais versões e idiomas, mais caro.

Nesse contexto, não se pode falar apenas da qualidade da localização da interface ou da qualidade da documentação traduzida, pois o resultado do trabalho de cada etapa é a base para a próxima etapa. É por isso que é muito importante fazer tudo imediatamente em cada estágio. E é por isso que vale a pena considerar o desenvolvimento, a documentação e a localização de software como etapas de um único processo inextricável.

Organização do texto na interface

Quando nossos programadores adotaram a localização do sistema, ele não estava absolutamente pronto para isso. O texto da interface estava armazenado no código, e o desejo da gerência era: "faça tudo rapidamente". Os programadores escreveram um script que retirou todo o texto do código e o jogou nos arquivos de recursos. No dia seguinte, eles entregaram os arquivos de recursos ao primeiro funcionário que sabia inglês, que rapidamente traduziu tudo para o bloco de notas. O que veio disso pode ser visto abaixo.



A imagem mostra um botão simples, abre algum formulário com parâmetros, onde esses parâmetros podem ser alterados. Existem dezenas desses botões no sistema. Em russo, havia 3 opções para esse botão; a localização em inglês já continha 7 opções.

Nessa situação, imediatamente existe um grande desejo de limpar as linhas da interface. Para fazer isso, proponho aplicar as seguintes regras:

• Divisão de todas as linhas em grupos.
  
  Todas as linhas devem ser divididas em grupos de acordo com o tipo de elementos da interface. Mesmo que as linhas tenham o mesmo texto, regras de tradução diferentes podem ser aplicadas a grupos diferentes. Por exemplo, a regra de letras maiúsculas para a primeira letra de cada palavra em inglês. Para alguns tipos de elementos da interface, ele é usado, para outros não.
• Removendo duplicatas.
  
  Em cada grupo, faz sentido excluir todas as linhas duplicadas, ou seja, as linhas com o mesmo texto. Depois, haverá a única opção em russo e em outros idiomas. Isso economiza custos de tradução. Observo que muito provavelmente as linhas repetidas ainda permanecerão, pois em alguns casos o contexto pode ser diferente. Além disso, essas linhas com o mesmo texto de origem podem ser traduzidas de maneiras diferentes. Por exemplo, a palavra Nome , no contexto do nome de uma pessoa, pode ser traduzida como Primeiro nome e, no contexto de um nome de arquivo, simplesmente Nome .
• Adicionando contexto aos identificadores de linha.
  
  O identificador de linha pode consistir no identificador da própria linha e do grupo ao qual a linha pertence. Isso é necessário para que o tradutor possa usar o identificador para selecionar uma regra de localização. Se tivermos esses identificadores corretos, o processo de verificação e correção dos mesmos erros de capitalização poderá ser facilmente automatizado.

Infelizmente, a aplicação dessas regras a todas as 30.000 linhas existentes ao mesmo tempo consome muito tempo. Aqui estamos no estágio inicial e, gradualmente, ordenamos as linhas repetidas com mais freqüência e desenvolvemos regras para novas linhas. Mas você deve admitir, seria ótimo se todas as regras fossem explicitadas e implementadas imediatamente!

Processo de documentação e localização

Vamos dar uma olhada na documentação baseada em tempo e no processo de localização. Se você começar a documentar e localizar antes que o desenvolvimento do recurso termine, precisará refazer tudo (talvez várias vezes).

A mesma coisa com a tradução de documentação.

E se você fornecer a documentação aos usuários antes que todas as edições terminem, poderá contar com vários comentários. Provavelmente, alguns desses comentários serão corrigidos nos últimos estágios de desenvolvimento, mas você precisará gastar tempo extra para processá-los.



Se os processos não forem coordenados e não acompanharmos todas as alterações no prazo, então “nada-nada-em-lugar-nenhum” não corresponderá.

A documentação não corresponderá à interface. As capturas de tela não correspondem à interface e ao texto da documentação.



O mesmo com a localização. O texto da interface e a documentação no idioma de origem não corresponderão ao texto da interface e da documentação em outros idiomas.



Decidimos que, no momento, podemos dar ao luxo de iniciar cada nova etapa somente depois que terminarmos a anterior.



Sim, nossa documentação e localização saem tarde após o lançamento. E por falar em localização, já garantimos a possibilidade de localização contínua, mas não usamos essa oportunidade e fazemos toda a localização em uma etapa no final do lançamento. Alguns dias, como parte de um lançamento semestral, é um estágio muito pequeno.

Contanto que nosso produto não seja grande, não precisamos urgentemente de documentação e localização para aparecer no mesmo dia. Temos lançamentos longos, grandes clientes corporativos, dos quais não há muitos em comparação com produtos pequenos e mais maciços, e eles não começam imediatamente a instalar uma nova versão do produto ou a atualizá-lo. Os custos de remodelação constante são visivelmente reduzidos.

Problemas de terminologia

No estágio de documentação e localização, constantemente enfrentamos problemas com a terminologia:

• As mesmas entidades foram chamadas de maneira diferente e entidades diferentes foram nomeadas da mesma forma.
• Os mesmos termos foram traduzidos de maneiras diferentes, e termos diferentes foram traduzidos da mesma maneira.
• Uma entidade pode ser equiparada às suas entidades filhas das quais consiste, ou entidades pai.
• Termos mal sucedidos ou incorretos foram escolhidos para denotar uma entidade.

O processo de desenvolvimento para nós por algum tempo ficou assim:

• Analistas estão escrevendo uma produção.
• Os testadores testam a produção.
• Código de desenvolvedores.
• Os testadores testam o resultado.

E ao tentar nos aprofundar nesse processo com terminologia, recebemos essas desculpas:

• Você irá desacelerar todo o processo.
• Isso geralmente não é tão importante.
• Você tem as ferramentas, você pode consertar tudo mais tarde.

Mas "mais tarde", descobriu-se que não podemos consertar tudo. Por exemplo, houve situações em que, devido à terminologia incorretamente entendida, os objetos do sistema foram colocados nos níveis de hierarquia incorretos ou combinados em grupos incorretos.

Agora, estamos verificando os termos e o texto da interface em paralelo com o teste de configuração. Ou seja, enquanto os testadores escrevem seus comentários, nós escrevemos os nossos.



O que fazemos durante o teste de produção:

• Nós revelamos novos termos.
• Verifique o texto da interface: para o uso correto dos termos, conformidade com o guia de estilo e conformidade com as funções.
• Identificamos as linhas existentes para não duplicar.
• Concordamos com a necessidade de localização, pois algumas partes da interface podem ser usadas apenas em um país.

Ao revelar novos termos, os adicionamos ao glossário, enquanto:

• Adicione uma definição ou contexto.
• Indicamos o relacionamento com outros termos (indicam os termos pai e filho).
• Estamos tentando indicar imediatamente o significado em inglês, pois depois de escolher o nome em inglês, às vezes fica claro que o russo não é escolhido corretamente.

Podemos dizer que, devido à coordenação dos textos de terminologia e interface no estágio de definição da aprovação, começamos a economizar muito tempo em várias correções nos estágios subseqüentes.

Documentação

Os princípios aos quais aderimos ao documentar:

• Usando um sistema de fonte única.
• Usando o glossário.
• Use o guia de estilo.
• Divisão da documentação em documentos pequenos e facilmente alienáveis.
  Vale a pena fazer isso, mesmo que o formato principal seja a Web. Se necessário, você não pode traduzir toda a documentação, mas apenas os documentos mais importantes, ou fazê-lo em etapas.

Agora vou falar sobre alguns dos aspectos mais importantes do processo de documentação.

Reutilizar texto

Na maioria dos sistemas de fonte única, variáveis ​​podem ser usadas. Portanto, desenvolvemos scripts que convertem automaticamente arquivos de recursos da interface em arquivos variáveis. No processo de desenvolvimento da documentação, não digitamos textos dos elementos da interface, mas inserimos variáveis ​​no texto. Assim, na versão russa, as linhas russas são automaticamente puxadas, na versão inglesa, inglês, em alemão alemão.



Quais são os benefícios:

• Os erros no texto dos elementos da interface serão excluídos se forem mencionados na documentação. Os textos dos elementos da interface na documentação são sempre idênticos aos textos na interface.
• Se as linhas de texto foram alteradas na interface, elas são alteradas automaticamente na documentação.
• Os erros são excluídos ao traduzir textos dos elementos da interface na documentação.
• Um tradutor gasta menos tempo trabalhando.

Existem muitas frases duplicadas na documentação. Por exemplo, uma frase como - "Clique no botão Salvar ". Em sistemas de fonte única, essa proposta pode ser colocada em um trecho. Um trecho é um arquivo tão pequeno que pode ser inserido em outras páginas da documentação.



Como você pode ver, o texto do botão Salvar no snippet também é substituído pela variável

Isso fornece os seguintes benefícios:

• Frases idênticas em significado são idênticas em todos os lugares, o que significa que a uniformidade do texto aumenta.
• O custo do desenvolvimento de documentação através da reutilização é reduzido.
• Tais frases são traduzidas apenas 1 vez. Isso reduz o custo do tradutor.

Capturas de tela e outras imagens

Em nossa documentação, geralmente usamos capturas de tela e outras imagens que podem conter texto.

Para capturar capturas de tela em diferentes idiomas por conta própria, em cada captura de tela, escrevemos o texto que é usado nela. Este texto está marcado e não aparece na documentação finalizada. Antes de traduzir a documentação, traduzimos textos para capturas de tela. E durante a tradução da documentação, capturamos capturas de tela de escritores técnicos sem conhecimento do idioma.

Usando capturas de tela, há outras dificuldades. Por exemplo, como rastrear todas as alterações se a interface alterar uma linha de texto, usada em 50 locais?

Como encontrar todas as capturas de tela desses 50 locais para substituí-las na documentação?

Para resolver esse problema, usamos a ferramenta QVisual que desenvolvemos na Tinkoff. O processo de trabalhar com isso é assim:

1. Durante o desenvolvimento da documentação, em cada captura de tela, criamos um link para o estande onde a captura de tela é feita.
2. Em um determinado momento, preparamos uma lista de todos os links.
3. Carregamos a lista recebida no QVisual.
4. O QVisual executa uma versão do produto e tira um conjunto de capturas de tela.
5. Em seguida, pegamos a nova versão do produto e o QVisual o executa usando os mesmos links.
6. O QVisual compara 2 conjuntos de capturas de tela e gera um relatório. No relatório, graficamente, você pode ver as diferenças entre as duas versões. Um exemplo está abaixo. Você pode ver imediatamente que na nova versão da captura de tela apareceu um campo adicional Idioma da interface do usuário .
7. Em seguida, repetimos o procedimento de comparação (p. 1-6) para cada idioma.
8. Tomamos os relatórios e examinamos as capturas de tela na documentação.

Assim, reduzimos o custo de várias verificações manuais de captura de tela. Além disso, nem sempre é possível identificar todos os erros manualmente, você pode simplesmente ignorar algo.

É verdade que nem todas as janelas podem ser abertas usando links e isso funciona apenas para a interface baseada na Web, mas ainda remove alguns dos problemas com a atualização de capturas de tela.

Localização da interface

Antes de localizar a interface, se isso ainda não tiver sido feito, você precisará traduzir todos os termos do glossário.

Quando o glossário é traduzido, a localização pode começar. Nesse processo, aderimos aos seguintes princípios:

• Use o glossário.
• Nós usamos a memória de tradução.
• Nós usamos o guia de estilo.
• Nós usamos um contexto.
• Utilizamos a garantia de qualidade automática (QA).

Observo que o contexto pode ter uma prioridade mais alta para tomar uma decisão de tradução do que ter a mesma linha já traduzida na memória de tradução. Além disso, com base no contexto, certas regras de conversão especificadas no guia de estilo podem ser aplicadas.

Pode haver várias maneiras de fornecer contexto:

• Como escrevi acima, o contexto pode ser estabelecido no próprio identificador de string ou em campos adicionais de arquivos de recursos (se o formato permitir).
• Imagens podem ser adicionadas. No momento, podemos adicionar capturas de tela manualmente a linhas particularmente complexas.
• Fornecendo estandes e documentação no idioma de origem. Como mostra a prática, esse método não funciona. Os tradutores geralmente não usam os materiais e estandes fornecidos a eles. Talvez porque o tempo necessário para traduzir uma linha aumente muitas vezes.

Tradução de documentação

Os princípios que tentamos aderir ao traduzir a documentação:

• Primeiro, traduzimos textos para capturas de tela e outras imagens. Como escrevi acima, as capturas de tela são tiradas em paralelo com a tradução da documentação. Isso é feito no estande, usando textos traduzidos para capturas de tela.
• Traduzimos apenas linhas alteradas e novas. As linhas traduzidas anteriormente com uma correspondência de 100% simplesmente não parecem. Sim, você pode reler toda a documentação de cada release, mas levando em consideração o fato de que cada release é atualizado em aproximadamente 10% do texto, subtrair os 90% restantes do texto é um custo injustificado.
• Use o glossário. O glossário deve ser traduzido anteriormente, no estágio de localização da interface.
• Usamos a documentação de tradução de memória.
• Usamos a interface de conversão de memória.
• Nós usamos o guia de estilo.
• Usamos o controle automático de qualidade (QA).

Estrutura organizacional e feedback

Vou dizer algumas palavras sobre a estrutura organizacional da empresa. É diferente para todos, mas imagine um caso em que cada departamento tenha seu próprio departamento.



O feedback de um departamento para o anterior nesta versão será difícil, a interação entre funcionários de diferentes departamentos é difícil. A solução de todos os problemas na cabeça também é um "pescoço estreito". Cada líder tem sua própria visão, objetivos e prioridades. Muito tempo pode ser gasto em aprovações adicionais.

Na minha opinião, um departamento deve ser responsável por todos os textos em todos os idiomas.

Com essa distribuição de responsabilidade, cada versão do produto é um projeto separado de várias etapas e a qualidade da implementação deste projeto deve ser respondida como um todo. É mais fácil estabelecer feedback, entender rapidamente qualquer problema, fazer uma retrospectiva e encontrar a causa raiz do problema.

Eu darei um exemplo

Devido ao fato de nossos escritores técnicos verificarem traduções usando o controle de qualidade, vimos dezenas, se não centenas, de erros de inconsistência.

Verificou-se que o tradutor vê as sentenças com significado idêntico, mas de maneiras diferentes, e faz a mesma tradução para elas. Iniciamos a tarefa e o redator técnico substituiu todas as versões diferentes do mesmo texto, no significado de um trecho. Agora não haverá tais erros repetidos. Os profissionais não terão que gastar tempo analisando-os e a tradução para novos idiomas será mais fácil no futuro.



No caso geral, se o tradutor tiver perguntas durante a tradução, então para nós já é um "sino" que algo está errado nos estágios iniciais e precisamos executar a tarefa de correção.

Que documentação de qualidade é necessária

Antes de tentar criar a documentação perfeita em todos os idiomas, vale a pena considerar a qualidade necessária? Perguntas adicionais ajudarão a responder a essa pergunta:

• Quem são os usuários da documentação?
  Se a documentação é de domínio público e os clientes, com base nela, decidem comprar o produto, a qualidade deve estar próxima do ideal. ( ), . , . , : , , . .
• ?
  , , . . ? , , .

:

• .
  
  , , -50 , . - 1-2 , .
• .
  
  CAT-. , (, ), .
• , , , .
• , .

Web- . , , .

. , .

. . , .

:

• .
  
  - , . . , Ctrl+Enter . . .
• .
  
  , . , , .
• .
  
  , , . , ( ), . , . .

, , , . , , .

Conclusões

, -, .

, , .

. .

, ! !

, !