Como gerenciar a tarefa de revisar seqüências de caracteres localizadas por um não desenvolvedor?

No .NET Framework, cadeias localizadas estão localizadas em um arquivo XML (ou vários arquivos). Esses arquivos fazem parte do projeto e são confirmados no controle de origem como qualquer outro arquivo de código-fonte. Normalmente, o Visual Studio é usado para exibir esses arquivos como uma tabela e editar as seqüências de caracteres localizadas.

Eu trabalho em uma equipe pequena em um produto que deve ter uma interface multilíngue.

1. Como desenvolvedor, rascunho as seqüências localizadas nos dois idiomas, pois a tradução pode ser inexata,

2. Outra pessoa da equipe (não desenvolvedora) analisa o conteúdo nos dois idiomas e o corrige, se necessário.

O problema atual é que a pessoa que não é desenvolvedor não usaria nem o controle de origem, nem um IDE, pois seria muito complicado e difícil (o controle de versão é difícil para não-desenvolvedores) para essa pessoa.

Uma solução alternativa seria exportar as seqüências localizadas como um arquivo do Excel, aguardar essa pessoa revisar o Excel e reimportar as seqüências modificadas. A ressalva aqui é que eu posso estar criando outras strings, renomeando as existentes, etc., dificultando a difusão da versão local com a revisada.

O que fazer?

Como isso acontece em outras equipes?

A localização é muito mais complexa do que apenas editar XML no Visual Studio, especificamente:

1. Embora o que KateGregory diz seja correto, o Visual Studio é caro e a compra de cópias para localizadores é proibitiva.
2. A menos que o localizador também seja um desenvolvedor, eles não podem ver as strings no produto e testar se as strings são exibidas corretamente (caracteres não europeus, como idiomas asiáticos, ou texto da direita para a esquerda, como árabe). palavras) e não causa ataques de injeção (como o uso de apóstrofos em francês)
3. Embora o controle de versão não seja uma ferramenta complexa, conceder acesso ao controle de origem a localizadores remotos ou contratados é um risco. Eles poderiam copiar o código-fonte sem o conhecimento da equipe ou cometer alterações significativas (intencionalmente ou não).
4. Ele também pressupõe que a única coisa que você está localizando são os arquivos RESX. Alguns produtos podem ter dados localizados, como nomes de relatórios.

Portanto, a melhor coisa a fazer é criar um site simples que exponha as várias strings, ocultando a sintaxe subjacente. O processo de construção inclui seqüências de caracteres fornecidas pelos localizadores após uma rápida verificação de integridade e a construção compartilhada com os localizadores para teste. O site pode usar logons para diferentes localizadores (e acompanhar e faturar se você quiser ir tão longe). Isso é mais trabalho, mas é uma solução melhor a longo prazo.

A edição de XML é péssima. O Visual Studio possui uma exibição que você pode usar para editar recursos:

Eu acho que o check-out-on-edit combinado com um minuto de demonstração da janela "alterações pendentes" deve permitir que seu não desenvolvedor use o controle de origem necessário.

Gostaria de encontrar um editor XML * para o não desenvolvedor usar.

Você precisará fornecer extrações com versão para o não desenvolvedor para revisão.

Depois de concluir a revisão, você poderá fazer o check-in do arquivo novamente.

Quando você fizer alterações, basta diferenciar os arquivos XML antes do check-in e enviar as seções atualizadas por você para o não-desenvolvedor para revisão. Suas atualizações são o motivo pelo qual você precisa manter os arquivos de revisão com versão.

Tentar usar o Excel tornará as coisas extremamente difíceis, pois as ferramentas de diff para o Excel deixam muito a desejar. Você também corre o risco de comentários adicionais surgirem nas células extras da planilha. Esses comentários exigiriam um tratamento adicional da sua parte para mesclá-los novamente.

Em uma vida anterior, usamos um processo bastante semelhante para várias traduções de organizações externas. Nossos arquivos eram essencialmente arquivos de texto com uma forma semelhante, mas diferente da XML. E tivemos várias alterações enquanto os arquivos estavam sendo revisados, então aprecio a diversão da sua situação.

Uma opção é criar um aplicativo auxiliar em que o tradutor possa ver a lista de strings em um painel e inserir o idioma específico em outro. Dessa forma, os dados são armazenados de volta no XML e você pode fazer com que o aplicativo exporte o arquivo.

Se você processar as chaves em um banco de dados e armazenar cada idioma lá, isso permitirá que as alterações sejam integradas e o tradutor veja o que precisa ser atualizado. Em seguida, você pode exportar para o arquivo XML específico do idioma que você coloca novamente no controle de versão ou o tradutor poderia.

Utilizamos um método semelhante a esse com o nosso código Rails, nunca editamos nem fornecemos os arquivos específicos do idioma, todos são mantidos e depois exportados pelo aplicativo externo que nossa equipe de tradução usa. Desculpe, não sei se o software deles é personalizado ou não, mas não deve ser tão difícil montar algo simples.

Como você sabe que possui todas as strings e se elas estão formatadas corretamente no aplicativo? Como você sabe que números, moeda, fuso horário e outras informações de localidade estão formatadas corretamente? Que tudo está carregado e a serialização multibyte funciona corretamente?

Não. A localização é um recurso como outro qualquer. Faça o check-in. Faça uma compilação. Deixe o testador obter a compilação e verifique se o recurso foi feito corretamente como qualquer outro. Quando você cria uma nova compilação, é possível fazer testes de regressão na localização - como qualquer outro recurso.