Como registrar o aceite da tradução por versão do software

Para documentar o aceite de uma entrega de localização, registre a versão do software, os arquivos traduzidos e os idiomas aprovados. Vincule os resultados de revisão a um build ou a um identificador reproduzível. A confirmação do comprador deve indicar qual versão foi aceita, especialmente quando a interface continua mudando durante o projeto.

Defina qual versão entra na revisão

Peça ao cliente uma referência estável. Pode ser uma versão de lançamento, um identificador de commit, um pacote de teste ou outro registro do processo dele. Registre também o ambiente e os arquivos de tradução usados. A documentação do GitHub descreve releases e tags como formas de relacionar um lançamento a um ponto do histórico. Use a referência compatível com a ferramenta do comprador.

Se o cliente envia texto e build em datas diferentes, confirme que os recursos localizados correspondem à versão que será testada. Um arquivo pode conter strings novas que ainda não aparecem na interface. Outro pode omitir chaves usadas em uma tela antiga. Documente o recorte antes de solicitar aprovação.

Prepare o quadro de aceite

A documentação de internacionalização da Microsoft trata de recursos localizáveis e metadados de contexto. Use essa orientação para registrar chaves e placeholders que exigem verificação. Se o cliente aprovou o texto, mas ainda falta testar a interface, indique essa separação. O acordo deve dizer se a cobrança depende da revisão linguística, do teste no produto ou dos dois.

Exemplo com duas versões durante o teste

Uma empresa brasileira localiza uma interface em espanhol e francês para um cliente estrangeiro. A versão 2.4 tem 180 strings revisadas. O cliente aprova o espanhol na versão 2.4 e pede correção de três textos em francês. Antes de concluir, a equipe recebe a versão 2.5, com duas telas novas. O aceite em espanhol continua associado à versão 2.4 e às telas previstas.

A empresa registra as três correções em francês e confirma se a versão 2.5 entra no escopo atual. Se o cliente quer revisar as telas novas, a equipe compara as chaves e apresenta o ajuste. Se o lançamento exige manter o escopo original, conclui a entrega da 2.4 e documenta o que ficará para o próximo ciclo. Assim a cobrança se apoia na versão efetivamente aprovada.

Preserve evidências para reproduzir a revisão

Guarde o inventário de arquivos, os resultados e as referências de chamados. Se houver gravações ou capturas, use o canal autorizado e mantenha a versão visível na evidência. Quando uma tradução é aprovada por revisor do comprador, registre a data e o idioma. Uma confirmação genérica de “tudo aprovado” pode não cobrir todas as variantes e plataformas.

Depois de atualizar uma string, confira se ela aparece corretamente no build de destino. Se a correção foi entregue no arquivo, mas ainda não entrou no aplicativo, mantenha o estado correto. O documento de aceite deve mostrar o que foi conferido, em qual ambiente e por quem.

Relacione o aceite à invoice

Na cobrança, indique o produto, o ciclo, a versão e os idiomas. Se houve ampliação de escopo, guarde o aceite e a contagem das alterações. Para o fechamento, associe proposta, invoice, aceite e comprovante de recebimento. Preserve recursos de tradução e arquivos do produto no ambiente autorizado.

Confira a versão que segue para lançamento

Se o cliente junta várias correções antes de lançar, peça uma referência do pacote final. Compare com a versão revisada e identifique as diferenças que afetam o idioma ou o layout. Registre se haverá teste de confirmação, quem o executará e qual evidência encerra a etapa. Assim o comprador consegue distinguir uma entrega aprovada de uma alteração posterior.

Trate correções urgentes como novos registros

Se o time descobrir uma frase cortada durante o lançamento, registre a correção na versão efetivamente distribuída ao público. Identifique o texto antigo, o texto novo, o idioma afetado e as telas que precisam de nova conferência. Combine quem fará o aceite e qual prova é suficiente para aquela urgência. Um vídeo curto da tela pode demonstrar que a frase aparece inteira, enquanto o pacote de strings identifica a versão alterada. Envie os dois no mesmo ticket. Isso dá ao cliente um histórico para distinguir a revisão de tradução original do trabalho extra que surgiu no lançamento. Confirme o tratamento comercial com quem pode aprovar o adicional.

Perguntas frequentes

Posso usar o aceite da versão anterior para cobrar a versão nova?

Confira o escopo e as mudanças entre as versões. Preserve o aceite anterior e registre uma nova conferência para os itens que mudaram.

O que fazer se a versão muda durante a revisão?

Conserve a referência do pacote original, compare as diferenças e confirme se a revisão continuará no mesmo escopo ou terá novo prazo e valor.

Que documentos devo guardar para a cobrança?

Guarde o inventário, a versão, os idiomas aprovados, o registro de aceite e o comprovante de recebimento. Vincule os arquivos ao marco contratado.

Fontes oficiais

• GitHub Docs — versões de software
• Microsoft Learn — internacionalização de software

Leituras relacionadas

• Como orçar localização de software por string e memória de tradução
• Guias para exportadores de serviços

Como a Zen pode ajudar

A contabilidade para exportação de serviços da Zen ajuda a organizar documentos, conciliar recebimentos e analisar as regras da sua operação. Peça uma proposta personalizada para conversar sobre o seu caso.