Básico do Weblate

Estrutura de projetos e componentes

No Weblate, as traduções são organizadas em projetos e componentes. Cada projeto pode conter vários componentes, os quais contêm traduções para idiomas individuais. O componente corresponde a um arquivo traduzível (por exemplo, GNU gettext PO (Objeto Portátil) ou Recurso de textos do Android). Os projetos estão lá para ajudá-lo a organizar componentes em conjuntos lógicos (por exemplo, para agrupar todas as traduções usadas dentro de um aplicativo).

Além disso, componentes dentro de projetos podem ser estruturados usando categorias. Componentes podem pertencer a uma categoria, e categorias podem ser aninhadas.

Internamente, cada projeto tem traduções para textos comuns propagados em outros componentes dentro dele por padrão. Isso alivia o fardo da tradução repetitiva e de várias versões. A propagação da tradução pode ser desabilitada por Configuração de componente usando Permitir propagação de tradução caso as traduções devam divergir.

Integração com repositório

O Weblate foi criado para integrar-se ao repositório de controle de versão upstream, Tradução contínua descreve os blocos de construção e como as alterações fluem entre eles.

Ver também

Visão geral da arquitetura descreve como o Weblate funciona internamente.

Atribuição ao usuário

O Weblate mantém as traduções devidamente criadas pelos tradutores no repositório de controle de versão usando nome e e-mail. Ter um e-mail real anexado ao commit segue os espíritos do controle de versão distribuído e permite que serviços como o GitHub associem suas contribuições feitas no Weblate com seu perfil do GitHub.

Esse recurso também traz o risco de uso indevido de e-mail publicado nos commits de controle de versão. Além disso, uma vez que tal commit é publicado em hospedagem pública (como GitHub), não há efetivamente nenhuma maneira de redigi-lo. O Weblate permite escolher um e-mail de commit privado em Conta para evitar isso.

Portanto, os administradores devem considerar isso ao configurar o Weblate:

  • Esse uso de e-mail deve ser claramente descrito nos termos de serviço, caso tal documento seja necessário. Legal module pode ajudar com isso.

  • PRIVATE_COMMIT_EMAIL_OPT_IN pode tornar os e-mails privados por padrão.