Guia de Contribuição do Manual do Krita¶

Bem-vindo ao Guia de Contribuição do Manual do Krita!

Se você estiver interessado em contribuir para a documentação do Krita, você está no lugar certo.

O Krita é um software de código aberto (gratuito), o que nos torna um projeto comunitário com dezenas de voluntários contribuindo para melhorá-lo. Isso, é claro, exige que mantenhamos um registro dos manuais e tutoriais para que novos voluntários possam nos ajudar. Os vários lugares onde fizemos isso foram bastante dispersos, então o manual do colaborador é uma tentativa de consolidar todas as informações. Portanto, é muito técnico em alguns pontos.

Esta documentação incluirá:

Um manual de referência para Krita

Provavelmente é isso que todos esperam ao consultar a documentação do Krita. Informações secas, básicas, do tipo “o que este botão faz?”.

Tutoriais de conceitos gerais.

Nos últimos dois anos, descobrimos que, para certos tipos de usuários, um manual de referência, mesmo com alguns exemplos, simplesmente não é suficiente. O manual também deve fornecer explicações rápidas e concisas sobre os detalhes, além de um fluxo de trabalho básico para preparar uma imagem para a web.

Também descobrimos que certos conceitos, como gerenciamento de cor e manipulação de camadas, são muito mais avançados no Krita do que o artista médio está acostumado. O Krita é gratuito e muitos de seus usuários não têm treinamento formal em arte digital. Portanto, não há conhecimento prévio focado no artista sobre como usar o gerenciamento de cores ou camadas de filtro.

Além disso, existem sistemas exclusivos do Krita, como o sistema de pincéis, as máscaras de transformação, a herança de alfa e os assistentes de perspectiva. Por fim, há usuários que não estão familiarizados nem mesmo com fluxos de trabalho de pintura padrão e não são flexíveis o suficiente para entender como portar um tutorial do SAI ou do Photoshop para o Krita.

Uma lista de tutoriais e tutoriais em vídeo conhecidos

Aparentemente, uma das coisas mais incríveis sobre a equipe do Krita é como nos conectamos com os artistas e reconhecemos que eles estão fazendo coisas legais. O mesmo vale para os tutoriais, especialmente porque existem maneiras únicas de usar o Krita e de abordar a pintura, e devemos incentivar as pessoas a compartilhar seus conhecimentos.

Manual do Colaborador

O que você está lendo agora!

Tutoriais no krita.org

Existem vários tutoriais no krita.org e no krita-foundation.tumblr.com. O primeiro focando em explicar como usar uma nova funcionalidade e o último estimulado pelos pedidos do usuário.

FAQ

Este já está online e é uma fusão das diferentes perguntas frequentes que tínhamos. Ele está sendo traduzido e esperamos que este seja o principal a ser atualizado.

Para iniciantes¶

Ao contrário do Mediawiki, o Sphinx funciona mais como escrevemos código para o Krita.

Antes de mais nada, você vai querer falar conosco! Para isso, você pode se juntar a nós na sala de bate-papo “#krita” via matrix. Uma introdução sobre o Matrix está disponível aqui <https://community.kde.org/Matrix>. Entre no seu cliente Matrix com uma conta da instância de sua escolha e entre no canal #krita:kde.org. Ou, mais importante, crie uma conta em identity.kde.org <https://identity.kde.org/>. A conta criada em identity pode ser usada tanto para acessar invent.kde.org quanto para o phabricator, onde organizamos o desenvolvimento do Krita.

O Sphinx funciona escrevendo arquivos de texto simples com a marcação reStructuredText e, em seguida, pega esses arquivos de texto e os transforma no manual. Acompanhamos as alterações no manual, inserindo-as em um sistema de controle de versão chamado Git.

Fazendo alterações¶

Como usamos o Git, há apenas algumas pessoas que podem colocar coisas no sistema de controle de versão, então se você quiser fazer alterações, precisará colocá-las para revisão.

Criando solicitações de mesclagem usando o modo de edição¶

Nota

Este método só é adequado se você não tiver acesso push aos repositórios do KDE. Caso contrário, ele enviará suas alterações diretamente para o repositório, o que vai contra as diretrizes atuais.

Recomendado para usuários sem conhecimento técnico.

Não recomendado quando você deseja alterar mais de um arquivo de uma vez. (Consulte Criando solicitações de mesclagem usando WebIDE ou Criando solicitações de mesclagem usando linha de comando se quiser alterar mais arquivos ou simplesmente editar apenas um por solicitação de mesclagem).

Se você tiver muitas alterações que deseja contribuir, recomendamos tentar seguir estas instruções.

Obtenha uma KDE identity.
Entre no KDE_gitlab.
Vá para o repositório e pressione fork.
Você será redirecionado para a sua bifurcação do repositório. Normalmente, ela está localizada em invent.kde.org/SEU_NOME_DE_LOGIN_KDE/docs-krita-org.
Volte ao repositório oficial. Certifique-se de estar navegando em Documentação > Documentação do Krita.org, e não no seu próprio fork. Caso contrário, este método não funcionará corretamente.

O Gitlab tem uma opção para editar arquivos no próprio Gitlab. Para acessá-la, vá para Repositório ‣ Arquivos.

No topo da página, você verá uma caixa de depósito com master como item escolhido.

Encontre o arquivo que deseja editar, abra-o e clique em Editar.

Faça suas alterações. (Observação: neste modo, você pode editar apenas um arquivo por vez).

Vá para a caixa de texto menor abaixo e escreva uma mensagem na seção de mensagem de commit com as alterações feitas. Quando terminar, pressione Commit changes. Isso criará uma solicitação de mesclagem para você. Basta preencher todos os campos conforme explicado aqui: Diretrizes para novas solicitações de mesclagem.

A desvantagem é que, no momento, não há como saber se você cometeu erros na marcação usando este método. Verifique suas alterações com o Editor Sphinx Online (basta copiar e colar o arquivo inteiro que você está editando).

Atenção

Editar e WebIDE são duas coisas diferentes! Certifique-se de selecionar Editar.

Criando solicitações de mesclagem usando WebIDE¶

Recomendado para usuários com algum conhecimento sobre Git que desejam editar vários arquivos de uma só vez.

Não recomendado quando você não sabe o que é um branch (veja Criando solicitações de mesclagem usando o modo de edição).

Siga as instruções acima para fazer login no KDE_gitlab e criar seu fork.
Vá até seu fork (certifique-se de que a URL contém seu nome de usuário).
Certifique-se de que você está no branch master.
Clique em WebIDE. Isso o levará a uma página com uma lista de arquivos no lado esquerdo e um grande espaço vazio para o conteúdo dos arquivos no lado direito.
Abra os arquivos que deseja editar e faça as alterações.
Clique em Commit…. Clique duas vezes em todos os arquivos na categoria Unstaged Changes para movê-los para Staged Changes.
Clique em Commit… novamente - isso expandirá uma caixa de texto com uma mensagem de commit. Escreva uma mensagem de commit explicando quais alterações você fez e por quê.
Certifique-se de que as configurações estejam corretas: você precisa selecionar Criar uma nova ramificação (o nome da ramificação deve ser: [nome de usuário]/[breve descrição das suas alterações]). Se você concluiu suas alterações, certifique-se de que Iniciar uma nova solicitação de mesclagem esteja marcado. Caso contrário, você precisará fazer uma nova solicitação de mesclagem manualmente mais tarde.
Clique em Stage & Commit.
Preencha todos os campos corretamente: veja Diretrizes para novas solicitações de mesclagem.
Para criar uma nova solicitação de mesclagem manualmente, acesse o repositório oficial do Krita Manual (certifique-se de que a URL não contenha seu nome de usuário) e clique em Criar uma nova solicitação de mesclagem (botão verde brilhante à esquerda). Selecione seu fork e a ramificação que você criou no WebIDE.

Nota

Se você não tiver acesso push ao repositório oficial, o Gitlab não permitirá que você salve suas alterações caso tenha editado o repositório oficial por engano (e Criar uma solicitação de mesclagem não ajudará nisso: você ainda precisa enviar suas alterações para sua branch, mas se não tiver acesso push, não poderá fazê-lo). Ele apenas exibirá a mensagem: Ocorreu um erro ao enviar suas alterações. Tente novamente.

Neste caso, basta copiar o conteúdo de todos os arquivos que você alterou, ir até o seu fork e colá-los no WebIDE do fork.

Criando solicitações de mesclagem usando linha de comando¶

Recomendado para usuários que sabem como o Git funciona e como usar a linha de comando.

Não recomendado quando você não sabe o que é um branch (veja Criando solicitações de mesclagem usando o modo de edição).

Siga as instruções acima para fazer login no KDE_gitlab e criar seu fork.
Clone o repositório localmente com git clone. A página do repositório contém as URLs a partir das quais você pode executar o comando git clone, e você pode então enviar para o seu fork. A vantagem disso é que você pode usar todas as ferramentas do seu computador para editar esses arquivos de texto, bem como compilar o manual localmente para verificar se há erros. (Você precisa executar esta etapa apenas uma vez).
# para acesso ssh git clone git@invent.kde.org:<username>/docs-krita-org.git git remote add upstream git@invent.kde.org:documentation/docs-krita-org.git # para acesso https git clone https://invent.kde.org/<username>/docs-krita-org.git git remote add upstream https://invent.kde.org/documentation/docs-krita-org.git
Lembre-se de sempre obter as alterações do repositório oficial antes de fazer novas alterações:
git pull upstream master
Certifique-se de criar uma nova ramificação para suas alterações, pois desde setembro de 2019 todas as alterações devem ser ramificadas de master.
git checkout master # e então: git checkout -b "<nomeusuário>/<descrição da nova funcionalidade>"

Após fazer as alterações, confirme-as e envie-as para o seu fork. Para uma descrição detalhada de como usar o Git no terminal neste fluxo de trabalho, acesse Forking on Gitlab.

# instale o pacote python3-sphinx para o seu sistema. Por exemplo, para o Ubuntu:
sudo apt install python3-sphinx
# compile o manual (relata erros potenciais, permite inspecionar alterações no navegador)
make html
# certifique-se de que tudo está correto
git status
git diff
# adicione todos os arquivos
git add .
# commit suas alterações
git commit
# submit suas alterações ao seu fork
git push

Por fim, acesse o site do repositório original e, em seguida, “Merge Requests”. Selecione seu fork e a ramificação correta e crie uma nova solicitação de mesclagem. Para obter instruções sobre como preencher os campos, consulte Diretrizes para novas solicitações de mesclagem.

Diretrizes para novas solicitações de mesclagem¶

Suas mensagens de commit devem estar em conformidade com os padrões explicados aqui: Como escrever uma mensagem de commit do Git
Título e Descrição devem explicar quais alterações você fez e por que as fez, assim como uma mensagem de confirmação, então siga as diretrizes do link acima neste caso também.
Alvo deve apontar para master.
Se você tiver certeza de que a solicitação de mesclagem exigirá algumas alterações posteriormente, comece o título da sua solicitação de mesclagem com [WIP].
Certifique-se de ter marcado Permitir commits de membros que podem fazer merge para o branch de destino. – muitas vezes, por motivos técnicos, é necessário que a solicitação de merge seja rebaseada no branch principal, o que tecnicamente altera a solicitação de merge, mas não altera o conteúdo real dela. O rebase pode ser feito por você ou pelo revisor – se não quiser ser incomodado muito mais tarde, é melhor marcar esta caixa de seleção para que o revisor possa fazer isso sozinho com apenas alguns cliques.
Você pode marcar com segurança Excluir branch de origem quando a solicitação de mesclagem for aceita na maioria dos casos.
A menos que seus revisores digam o contrário, marque Eliminar commits quando a solicitação de mesclagem for aceita. A primeira linha da mensagem de commit virá do Título da sua solicitação de mesclagem e o restante será retirado da Descrição da solicitação de mesclagem.
Quando terminar de criar sua solicitação de mesclagem, vá ao IRC (veja Internet Relay Chat) e peça a alguém com acesso push para adicionar o rótulo Necessita de revisão na sua solicitação de mesclagem.
Você poderá receber feedback sobre sua solicitação de mesclagem caso ela contenha erros. Basta corrigir os erros na sua ramificação de uma das seguintes maneiras.
- Se você quiser usar o modo Editar, vá para a seção Alterações da solicitação de mesclagem e clique no ícone de lápis (com uma dica de ferramenta que diz Editar) para usar o modo Editar novamente.
- Se você quiser usar o modo WebIDE, vá até seu fork, selecione o branch em que suas alterações estão e vá para o WebIDE.
- Se você editar arquivos no seu computador e trabalhar com o terminal, certifique-se de estar no branch correto e envie suas alterações - o gitlab atualizará sua solicitação de mesclagem automaticamente.
Depois de fazer as alterações, peça para alguém alterar o rótulo para Precisa de revisão novamente.

Para informações mais detalhadas, confira Forking on Gitlab na seção técnica.

Nota

No momento em que este guia foi escrito, a definição de rótulos em solicitações de mesclagem só era possível para colaboradores com acesso de escrita ao repositório oficial. (Se você não sabe o que isso significa, provavelmente não é um deles). Por isso, ao criar ou alterar sua solicitação de mesclagem, você precisa acessar o IRC (consulte A Comunidade Krita) e pedir para alguém rotulá-la para você.

Compilando o manual na linha de comando¶

Para aqueles que querem primeiro testar algumas mudanças antes de embarcar em uma solicitação de mesclagem imediatamente (e já sabem como usar o git e a linha de comando), isso é descrito como parte da etapa 5 em Criando solicitações de mesclagem usando linha de comando.

Filosofia geral¶

Isto serve para determinar qual é o estilo de escrita apropriado. Um estilo de escrita, sejam suas qualidades práticas ou estéticas, geralmente é sustentado por um objetivo ou filosofia geral. O que queremos alcançar com o manual e a quem ele se destina?

Dados demográficos e público-alvo¶

Não podemos falar de um grupo demográfico no sentido de que sabemos que todos os usuários do Krita são homens de 55 anos. O Krita é usado por um número enorme de pessoas, e temos orgulho de ter uma base de usuários tão variada.

Apesar disso, sabemos algumas coisas sobre nossos usuários:

Eles são artistas. Esse é explicitamente o tipo de usuário que almejamos.
- Portanto, sabemos que eles preferem imagens bonitas.
- Eles são visuais.
- Eles estão tentando fazer imagens bonitas.

Portanto, o objetivo implícito de cada página seria obter a funcionalidade usada para criar imagens bonitas.

Além disso, observamos os seguintes grupos:

Estudantes do ensino médio e da faculdade testando softwares de desenho para ilustrações. Geralmente, eles já têm alguma experiência com softwares de desenho, como Paint Tool SAI ou Photoshop, mas precisam conhecer as possibilidades do Krita. O ponto forte desse grupo é que eles compartilham muitas informações entre si, como dicas, truques e tutoriais.
Profissionais, pessoas que ganham dinheiro com softwares de desenho digital. A força desse grupo é que eles têm muito conhecimento e estão dispostos a contribuir para melhorar o programa. Eles se dividem em dois tipos:
- Profissionais não técnicos. São pessoas que não entendem muito bem as partes mais matemáticas de um software, mas desenvolveram fluxos de trabalho sólidos ao longo dos anos e trabalham com software usando seus instintos apurados. Geralmente são ilustradores, pintores e profissionais de impressão.
- Profissionais técnicos. São pessoas que usam o Krita como parte de um pipeline e se preocupam com a matemática precisa e o pixel push. Geralmente, trabalham na indústria de jogos e efeitos visuais, mas ocasionalmente também há um cientista envolvido.
Adultos e idosos amadores. Este grupo não entende muito de computadores e sempre parece se prender naquele pequeno detalhe que falta em um tutorial. A força deles como grupo é que adaptam fluxos de trabalho não convencionais da vida real, que o aluno não conhece e para os quais o profissional não tem tempo, e criam coisas legais com isso, além de terem um efeito moderador no primeiro grupo da comunidade em geral.

Destes quatro grupos…

só há uma que é técnica. É por isso que precisamos das páginas de conceito, para que possamos criar uma base sólida sobre a qual escrever nossos textos.
três deles provavelmente têm experiência anterior com software e podem precisar de guias de migração e saber como fazê-lo.
dois deles precisam saber como fazer o Krita cooperar com outro software.
dois deles não têm ideia do que estão fazendo e podem precisar ser guiados pelos passos mais básicos.

Disso podemos tirar as seguintes regras:

Escrita em geral¶

Use inglês americano se possível.: Usamos inglês americano no manual, pois a interface do Krita é em inglês americano por padrão.
Mantenha uma linguagem educada, mas não use linguagem acadêmica.: Como comunidade, queremos ser acolhedores com os usuários, por isso tentamos evitar linguagem pouco acolhedora. Xingamentos já não são tolerados pelo KDE, mas, indo além, um estilo acadêmico em que nem o autor nem o leitor são reconhecidos pode dar a impressão de que o texto é muito mais complexo do que o necessário, e assim afastar os usuários.
Evite usar GIFs (aberto para debate): O motivo é que pessoas com epilepsia podem ser afetadas por imagens em movimento rápido. Da mesma forma, GIFs podem, às vezes, carregar muito peso na explicação. Se você não puder deixar de usar GIFs, pelo menos avise o leitor sobre isso na introdução da página.
Mantenha-o compatível com a tradução: Isso consiste em usar SVG para infográficos e usar a marcação apropriada para um determinado texto.

Sobre fotos e pinturas¶

Gostaríamos de desencorajar fotos e pinturas tradicionais no manual se elas não ilustrarem um conceito. O motivo é que é muito tolo e um pouco desonesto mostrar a obra de Rembrandt dentro da interface gráfica do Krita, quando temos tantas obras modernas feitas no Krita. Todas as artes do Pimenta&Cenoura foram feitas no Krita e os arquivos originais estão disponíveis, então, se você não tiver uma imagem à mão, comece por elas. Fotos devem ser evitadas, pois o Krita é um programa de pintura. Muitas fotos podem dar a impressão de que o Krita está tentando ser uma solução para retoque fotográfico, o que realmente não é o foco.
É claro que ainda queremos mostrar certos conceitos em jogo em fotos e pinturas de mestres, como brilho ou luz indireta. Nesse caso, adicione uma legenda que mencione o nome da pintura ou do pintor, ou mencione que se trata de uma fotografia.
Fotos ainda podem ser usadas para photobashing e coisas do tipo, mas somente se forem usadas obviamente no contexto de photobashing.

Sobre imagens em geral¶

Evite texto nas imagens e, em vez disso, use a legenda. Você pode fazer isso com a diretiva figure.
Se você precisar usar texto, crie um SVG para que o texto interno possa ser manipulado mais facilmente ou tente minimizar a quantidade de texto.
Tente fazer com que suas imagens sejam de alta qualidade/fofas. Vamos dar às pessoas a impressão de que estão usando um programa para desenhar!
Lembre-se de que o manual está licenciado sob a GDPL 1.3, portanto, as imagens enviadas serão licenciadas sob essa licença. No caso de CC-By-Sa/CC-By, certifique-se de que o arquivo seja atribuído corretamente por meio de uma legenda de figura. Obviamente, não envie imagens que não possam ser licenciadas sob nenhuma dessas licenças.

Protocolo¶

Então aqui destacamos todos os fluxos de trabalho chatos.

Marcação (tagging) e ramificações (branching)¶

A adição e remoção de texto serão feitas na branch draft.

Os resultados da revisão de páginas antigas serão considerados como correções de bugs e, portanto, irão para a branch master e serão mesclados na branch draft conforme necessário.

Antes que a branch draft seja mesclada para uma determinada versão:

A branch master será marcada com a versão antiga.
A branch draft é primeiro verificada duas vezes para garantir que ela tenha um número de versão atualizado e uma capa epub atualizada.

A branch draft não será mesclada até o dia anterior ao lançamento para manter as páginas intactas por tempo suficiente.

Cada lançamento terá uma versão do epub carregada como parte do processo de lançamento. … De onde obtemos os arquivos POT? Até mesmo das versões traduzidas?

Removendo páginas¶

Se uma funcionalidade for removida em uma determinada versão, as páginas correspondentes:

Primeiro serão marcadas como obsoletas.

Isso pode ser feito assim:

.. obsoleto:: número da versão

    Texto para indicar o que o usuário deve fazer sem este recurso.

Será vinculada a uma página chamada ‘obsoleto’
Se a próxima versão for lançada, todas as páginas vinculadas na seção obsoleta serão removidas.

Adicionando páginas¶

Certifique-se de que ela esteja localizada no lugar certo.
Siga as Convenções de marcação para o Manual Krita para garantir que a página esteja formatada corretamente.
Adicione a página ao índice.

Se a funcionalidade for nova, adicione versionadded:

.. versionadded:: número da versão

    algo opcional ou outro.

Assim como com imagens, não adicione texto para o qual você não tenha permissão. Isso significa que o texto foi escrito por você ou você tem permissão para transferi-lo do autor original. O manual está em conformidade com a GDPR 1.3+, portanto, o texto será licenciado novamente sob essa norma.

Alterando páginas¶

Se você reescrever uma página completamente, em vez de revisá-la, a página resultante deverá ser revisada.

Se você alterar uma página porque uma funcionalidade foi alterada e você tiver acesso de confirmação, a alteração poderá ser enviada sem revisão (a menos que você se sinta mais confortável com uma revisão), mas você deve adicionar:

.. versionchanged:: número da versão

    Isso e aquilo mudaram.

Em todos os casos, marque se você deseja se adicionar ao campo de autor na seção de metadados na parte superior.

Usar deprecated, versionadded e versionchanged com o número da versão nos permite pesquisar facilmente no manual por esses termos com grep:

grep -d recurse versionadded * --exclude-dir={_build,locale}

Páginas com erro¶

Se uma página com erro passar despercebida, ou…

Faça uma solicitação de mesclagem conforme a seção Fazendo alterações.
Crie uma tarefa no Quadro de Trabalho do Projeto Manual.
Crie um bug no bugzilla no projeto Krita na seção ‘documentação’.

Revisão¶

Há dois tipos de revisão que precisam ser feitos.

O mais importante é revisar as alterações feitas pelas pessoas. Você pode fazer isso no KDE_gitlab de duas maneiras:

Revisando solicitações de mesclagem

Você pode ajudar a revisar solicitações de mesclagem. A revisão de solicitações geralmente é feita por programadores para encontrar erros no código uns dos outros, mas como o código de programação é baseado em texto, assim como o texto comum, podemos usar isso para verificar erros de digitação também!

Uma solicitação de mesclagem é uma série de alterações feitas em um documento (adicionadas, removidas) e colocadas em um arquivo legível por máquina. Quando alguém envia uma solicitação de revisão (em sistemas como o GitLab ou o GitHub, trata-se de uma solicitação de mesclagem ou pull request), os responsáveis pela manutenção dos arquivos originais terão que analisá-las e podem fazer comentários sobre os pontos que precisam ser alterados. Isso permite que eles comentem sobre coisas como erros de digitação, textos muito complexos, mas também sobre coisas que estão incorretas. Após um patch ser aceito, ele pode ser enviado para o sistema de controle de versão.
Comentando sobre mudanças no manual.

Os comentários sobre as alterações ocorrem após o fato. Você pode comentar uma alteração acessando a mensagem de commit (na página do repositório, vá para o histórico e clique em uma entrada), onde poderá comentar as alterações realizadas.

Em ambos os casos, a interface consiste na exibição da diferença, com a versão antiga à esquerda e a nova à direita. As linhas adicionadas serão marcadas em verde, enquanto as linhas removidas serão marcadas em vermelho. Você pode clicar no ícone de um balão de fala para adicionar um comentário “inline”.

A segunda maneira principal de revisar o manual é em todo o arquivo. Muitas páginas foram verificadas apenas quanto à correção, mas não quanto ao estilo e à gramática.

Para isso, você precisará seguir a seção Fazendo alterações para ter acesso total às páginas e editá-las.

Traduzindo¶

A tradução do manual é feita pela comunidade de localização do KDE. Para participar do esforço de tradução, acesse o site de localização, selecione a lista de equipes de tradução, selecione o idioma para o qual deseja traduzir e siga as instruções na página da equipe para entrar em contato com outros tradutores.

Consulte https://community.kde.org/Get_Involved/translation para obter instruções mais gerais sobre como se envolver na localização do KDE.

A equipe de localização tem acesso aos arquivos PO deste manual, um tipo de arquivo usado por programas de tradução como POEdit e Lokalize. Uma equipe de tradução pode trabalhar em conjunto na tradução desses arquivos e enviá-los para o SVN de traduções. Um script especial então pegará as traduções do SVN e as trará para a seção do manual para serem incorporadas diariamente.

As imagens podem ser traduzidas se uma equipe de tradução quiser fornecer suas próprias imagens. Todas as imagens na pasta de imagens são, por padrão, para “en”. Quando você quiser traduzir uma imagem específica, acesse essa pasta e adicione outra pasta com o código do seu idioma para adicionar as versões traduzidas das imagens. Assim, o Sphinx procurará por uma versão em holandês de /images/Pixels-brushstroke.png em /images/nl/Pixels-brushstroke.png e por uma versão em holandês de /images/dockers/Krita-tutorial2-I.1-2.png em /images/dockers/nl/Krita-tutorial2-I.1-2.png.

As traduções finalizadas também precisam ser adicionadas ao script de compilação para serem exibidas online. As equipes de tradutores que estiverem confiantes no estado de suas traduções devem entrar em contato com a equipe principal do Krita por meio da lista de discussão do kimageshop (kimageshop@kde.org) ou foundation@krita.org para fazer isso.

Outro¶

Para convenções de texto reestruturado, verifique Convenções de marcação para o Manual Krita.