Guia de Contribuições para o Manual do Krita¶

Bem-vindo ao Guia de Contribuições para o Manual do Krita!

Se estiver interessado em contribuir para a documentação do Krita, está no local correcto.

O Krita é uma aplicação de código aberto (e gratuito), que nos torna efectivamente um projecto comunitários, como dezenas de voluntários a contribuir para o tornar ainda melhor. Isto, como é óbvio, obriga-nos a acompanhar os manuais e os HOWTO’s, para que os novos voluntários venham e nos ajudem. Os diversos locais onde isto já foi feito já foram relativamente espalhados e não estão a ser mantidos ultimamente. O manual dos contribuintes é uma forma de tentar consolidar toda a informação. Como tal, é muito técnico em certos sítios.

Esta documentação irá incluir:

Um manual de referência para o Krita

Este é o que provavelmente todos estarão à espera quando procuram pela documentação do Krita. Directo, básico, com informações do tipo “o que faz este botão”.

Tutoriais com conceitos gerais.

Descobrimos durante os últimos dois anos que, para certos tipos de utilizadores, um manual de referência, mesmo que tenha alguns exemplos, simplesmente não é o suficiente. O manual deverá também fornecer explicações rápidas e concisas para as coisas, assim que oferece um processo simples para preparar uma imagem para a Web.

Descobrimos também que certos conceitos, com a gestão de cores e o tratamento das camadas, estão muito mais avançados no Krita do que o artista médio está habituado. O Krita é gratuito e muitos dos utilizadores não terão uma formação formal sobre arte digital. Como tal, não existe um conhecimento prévio e focado nos artistas em como usar a gestão de cores ou as camadas de filtros.

Para além disso, existem sistemas que são únicos ao Krita, como por exemplo o sistema de pincéis, as máscaras de transformação, a herança do alfa e os assistentes de perspectivas. Finalmente, existem utilizadores que não estão familiarizados com os processos de pintura padrão de todo, e que não são flexíveis o suficiente para compreender como migrar um tutorial do SAI ou Photoshop para o Krita.

Uma lista com tutoriais conhecidos e vídeos.

Aparentemente, uma das coisas boas sobre a equipa do Krita é a forma como nos associamos com os artistas e que compreendemos como eles fazem as coisas giras. O mesmo também se deve aplicar nos tutoriais, especialmente porque existem formas de usar o Krita e formas de abordar a pintura que são únicas e que devemos encorajar as pessoas a partilhar o seu conhecimento.

Manual do Contribuinte

O que está a ler neste momento!

Tutoriais do krita.org

Foram feitos alguns tutoriais no krita.org e no krita-foundation.tumblr.com, focando-se o primeiro na explicação de uma nova funcionalidade e o último foi resultante de pedidos de utilizadores.

FAQ

Esta já se encontra na Internet e é uma junção de todas as diferentes FAQ’s (Perguntas Frequentes) que temos tido. Está de momento a ser traduzida e esperamos que seja esta a principal a ser actualizada.

Para os primeiros utilizadores¶

Ao contrário do Mediawiki, o Sphinx funciona mais como se escrevêssemos código para o Krita.

First things first, you will want to talk to us! For this you can join us in the chatroom «#krita» via matrix. A introduction about Matrix is given here. Log in to your Matrix client with an account from your instance of choice, and join the #krita:kde.org channel. Or more importantly, make an account at identity.kde.org. The account you make at identity can be used to both access invent.kde.org as well as the phabricator, where we organise Krita development.

O Sphinx funciona através da criação de ficheiros de texto simples com a formatação do reStructuredText, e então ele pega nesses ficheiros de texto e transforma-os no manual. Mantemos o registo histórico das alterações no manual, colocando-as num sistema de controlo de versões chamado Git.

Fazer alterações¶

Dado que usamos o Git, existem só algumas pessoas que conseguem colocar coisas no sistema de controlo de versões; por isso, se quiser fazer alterações, terá de as disponibilizar para revisão.

Criar pedidos de reunião com o modo de Edição¶

Nota

Este método só é adequado se não tiver permissões de publicação (“push”) nos repositórios do KDE. Caso contrário, iria enviar as suas alterações directamente para o repositório, o que é contra as regras actuais.

Recomendado para os utilizadores sem conhecimentos técnicos.

Não é recomendado quando desejar mudar mais que um ficheiro de uma vez. (Veja o Criar pedidos de reunião com o WebIDE ou o Criar pedidos de reunião com a linha de comandos se quiser mudar mais ficheiros, ou edite apenas um ficheiro por cada pedido de reunião).

Se tiver um conjunto de alterações que deseja contribuir, recomendamos que tente seguir essas instruções.

Obtenha uma identidade do KDE.
Autentique-se no KDE_gitlab.
Vá ao repository e carregue em fork (replicar).
Deverá ser encaminhado agora para a réplica do seu repositório. Normalmente está localizado em invent.kde.org/O_SEU_UTILIZADOR_KDE/docs-krita-org.
Volte ao repositório oficial. Certifique-se que está a navegar Documentation > Krita Documentation e não a sua réplica. Caso contrário, este método não irá funcionar correctamente.

O Gitlab tem uma opção para Editar os ficheiros no próprio Gitlab. Para aceder ao mesmo, vá a Repositório ‣ Ficheiros.

No topo da página, poderá ver uma lista com o item master escolhido.

Descubra o ficheiro que deseja editar, abra-o e depois carregue em Editar.

Faça as suas alterações. (Nota: neste modo, poderá editar apenas um ficheiro de cada vez).

Vá ao campo de texto pequeno em baixo e escreva uma mensagem adequada na secção da mensagem de modificação com as alterações que fez. Quando terminar, carregue em Commit changes (Enviar as modificações). Isto irá criar um pedido de reunião para si; basta preencher todos os campos como está explicado aqui: Recomendações para os pedidos de reunião novos.

A desvantagem é que agora não existe uma forma de indicar se cometeu algum erro com a formatação se usar este método. Por favor, verifique as suas alterações com o Online Sphinx Editor (basta copiar e colar o ficheiro inteiro que está a editar).

Atenção

O Editar e o WebIDE são duas coisas diferentes! Certifique-se que selecciona o Editar.

Criar pedidos de reunião com o WebIDE¶

Recomendado para os utilizadores com algum nível de conhecimento sobre o Git e que queiram editar vários ficheiros de cada vez.

Não recomendado quando não souber o que é uma ramificação (veja em alternativa Criar pedidos de reunião com o modo de Edição).

Siga as instruções acima para se autenticar no KDE_gitlab e crie a sua réplica.
Vá à sua réplica (certifique-se que o URL contém o seu utilizador).
Certifique-se que está na ramificação master.
Carregue no WebIDE. Isto devê-lo-á conduzir a uma página que tem uma lista de ficheiros do lado esquerdo e um grande espaço vazio para o conteúdo do ficheiro do lado direito.
Abra os ficheiros que deseja editar e faça as alterações.
Carregue em Commit… (Enviar). Faça duplo-click sobre todos os ficheiros na categoria Unstaged changes (Modificações não confirmadas) e mova-as para as Staged changes (Modificações confirmadas).
Carregue em Commit… (Enviar) de novo - irá expandir um campo de texto com a mensagem da modificação. Escreva a mensagem da modificação que explica as alterações que fez e porquê.
Certifique-se que a configuração está correcta: tem de seleccionar Create a new branch (Criar uma nova ramificação) - o nome da ramificação deverá ser: [utilizador]/[descrição muito curta das suas alterações]). Se terminar as suas alterações, certifique-se que a opção Iniciar um novo pedido de reunião está assinalada. Caso contrário, terá de fazer manualmente um novo pedido de reunião mais tarde.
Carregue em Stage & Commit (Confirmar & Enviar).
Preencha correctamente todos os campos: veja o Recomendações para os pedidos de reunião novos.
Para criar manualmente um novo pedido de reunião, vá ao repositório oficial do Manual do Krita (certifique-se que o URL não contém agora o seu utilizador) e carregue em Create a new merge request (Criar um novo pedido de reunião) - o botão verde claro à esquerda. Seleccione a sua réplica e seleccione a ramificação que criou no WebIDE.

Nota

Se não tiver permissões para publicar no repositório oficial, o Gitlab não lhe permitirá gravar as suas alterações se estiver a editar o repositório oficial por engano (e a opção Create a merge request (Criar um pedido de reunião) não o irá ajudar também: terá à mesma de gravar as suas modificações na sua ramificação, mas se não tiver acesso de publicação, não o poderá fazer). Simplesmente irá mostrar a mensagem Ocorreu um erro ao gravar as suas modificações. Por favor tente de novo.

Neste caso, basta copiar o conteúdo de todos os ficheiros que modificou, vá à sua réplica e cole-os no WebIDE da réplica.

Criar pedidos de reunião com a linha de comandos¶

Recomendado para os utilizadores que sabem como funciona o Git e como usar a linha de comandos.

Não recomendado quando não souber o que é uma ramificação (veja em alternativa Criar pedidos de reunião com o modo de Edição).

Siga as instruções acima para se autenticar no KDE_gitlab e crie a sua réplica.
Clone o repositório a nível local com o git clone. A página do repositório tem os URL’s a partir dos quais poderá fazer o “git clone”, podendo-os enviar depois para a sua própria réplica. A vantagem disto é que poderá usar todas as ferramentas no seu computador para editar esses ficheiros de texto, assim como compilar localmente o manual para procurar por erros.
# para o acesso por SSH git clone git@invent.kde.org:<utilizador>/docs-krita-org.git git remote add upstream git@invent.kde.org:documentation/docs-krita-org.git # para o acesso por HTTPS git clone https://invent.kde.org/<utilizador>/docs-krita-org.git git remote add upstream https://invent.kde.org/documentation/docs-krita-org.git
Lembre-se de obter sempre todas as modificações do repositório oficial antes de fazer novas alterações:
git pull upstream master
Certifique-se que criou uma nova ramificação para as suas alterações; desde Setembro de 2019, todas as alterações deverão ramificar a partir do master.
git checkout master # e então: git checkout -b "<utilizador>/<descrição da nova funcionalidade>"

Depois de fazer as suas alterações, confirme-as e envie para a sua réplica. Para uma descrição detalhada de como usar o Git no terminal, no caso deste processo de trabalho, vá a Forking on Gitlab.

# instale o pacote 'python3-sphinx' no seu sistema. Por exemplo no Ubuntu:
sudo apt install python3-sphinx
# compile o manual (vendo os erros potenciais, permite ver as alterações no navegador)
make html
# certifique-se que está tudo correcto
git status
git diff
# adicione todos os ficheiros
git add .
# confirme as suas alterações
git commit
# envie as suas alterações para a sua ramificação
git push

Finalmente, vá à página Web do repositório original e depois aos Pedidos de Reunião. Seleccione a sua réplica e a ramificação correcta e crie um novo pedido de reunião. Para mais instruções de preenchimento dos campos, veja Recomendações para os pedidos de reunião novos.

Recomendações para os pedidos de reunião novos¶

As suas mensagens de modificações devem estar em conformidade com as normas aqui explicadas: How to Write a Git Commit Message
O Título e a Descrição devem explicar as alterações que você fez e porque é que as fez, tal como numa mensagem de modificação, como tal siga também as instruções no endereço acima neste caso.
O Destino deverá apontar para master.
Se tiver a certeza que o pedido de reunião irá obrigar a algumas alterações posteriores, inicie o título do seu pedido de reunião com [WIP].
Certifique-se que assinalou a opção Allow commits from members who can merge to the target branch. (Permitir as modificações dos membros que podem reunir com a ramificação de destino) – normalmente é necessário por razões técnicas que o pedido de reunião passe a basear-se no “master”, o que irá mudar a nível técnico o pedido de reunião, mas não altera o conteúdo actual do mesmo. Esta mudança de base poderá ser feita por si ou pelo revisor – se não se quiser incomodar muito, é melhor assinalar esta opção para que o revisor possa ele mesmo fazê-lo ao assinalar algumas opções.
Pode assinalar à vontade o Apagar a ramificação de origem quando o pedido de reunião for aceite na maioria dos casos.
A menos que os seus revisores lhe digam algo em contrário, assinale a opção Squash commits when merge request is accepted (Juntar as modificações quando o pedido for aceite). A primeira linha da mensagem de modificação virá do Título do seu pedido de reunião e o resto do mesmo será retirado da Descrição do pedido de reunião.
Quando acabar de criar o seu pedido de reunião, vá ao IRC (veja em Internet Relay Chat) e peça a alguém com permissões de publicação (“push”) para adicionar a etiqueta Needs Review (Precisa de Revisão) no seu pedido de reunião.
Poderá obter reacções sobre o seu pedido de reunião se tiver erros. Basta corrigir os erros na sua ramificação de uma das seguintes formas.
- Se quiser usar o modo de Edição, basta ir à secção de Modificações do pedido de reunião e carregue no ícone do lápis (com uma dica que diz Editar) para usar o modo de Edição de novo.
- Se quiser usar o modo do WebIDE, vá à sua réplica, seleccione a ramificação onde estão as suas modificações e vá ao WebIDE.
- Se editar os ficheiros no seu computador e trabalhar com o terminal, certifique-se que está na ramificação correcta e publique as suas modificações - o Gitlab irá actualizar automaticamente o seu pedido de reunião.
Depois de fazer as alterações, certifique-se que pede a alguém para mudar a etiqueta para Needs Review de novo.

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

Nota

Na altura em que este guia foi escrito, a atribuição de etiquetas nos pedidos de reunião só é possível pelos colaboradores com permissões de escrita activas no repositório oficial. (Se não souber o que isto significa, provavelmente não será um deles). Por causa disso, quando criar ou modificar o seu pedido de reunião, terá de ir ao IRC (veja a A Comunidade do Krita) e peça a alguém para atribuir a etiqueta por si.

Compilar o manual na linha de comandos¶

Para os que desejam experimentar algumas alterações antes de solicitar um pedido de reunião desde logo (e já saibam como usar o “git” na linha de comandos), isto é descrito como sendo parte do passo 5. do Criar pedidos de reunião com a linha de comandos.

Filosofia geral¶

Isto é para determinar o que é um estilo apropriado de escrita. Um estilo de escrita, quer olhemos para as suas qualidades práticas ou estéticas, normalmente está marcado por um objectivo ou filosofia geral. O que queremos obter com o manual, e para quem se destina o manual?

Demografia e audiências-alvo¶

Não podemos falar sobre demografia, no sentido em que que sabemos que todos os utilizadores do Krita são homens de 55 anos. O Krita é usado para uma quantidade bastante diferente de pessoas, e estamos de facto orgulhosos que temos uma base de utilizadores assim tão variada.

Apesar disso, sabemos algumas coisas sobre os nossos utilizadores:

Eles são artistas. Isto é explicitamente o tipo de utilizadores em que nos focamos.
- Como tal, sabemos que eles preferem imagens bonitas.
- Eles são visuais.
- Eles estão a tentar obter imagens bonitas.

Como tal, o objectivo implícito de cada página seria obter a funcionalidade usada para imagens bonitas.

Para além disso, observámos os seguintes grupos:

Os estudantes do ensino secundário e superior que experimentar aplicações de desenho para ilustrações. Estes normalmente têm alguma experiência prévia com aplicações de desenho, como o Paint Tool SAI ou Photoshop, mas que precisam de ser apresentadas às possibilidades do Krita. A força deste grupo é que eles partilham bastantes informações entre si, como sugestões, truques e tutoriais.
Os profissionais, as pessoas que ganham o seu dinheiro com aplicações de desenho digital. A força deste grupo é que temos bastantes conhecimentos e estamos dispostos a doá-los para melhor o programa. Estes vêm sob duas formas:
- Os profissionais não-técnicos. Estas são as pessoas que não se preocupam realmente com os detalhes matemáticos de uma componente de “software”, mas que desenvolveram processos sólidos ao longo dos anos e que trabalham com as aplicações com os seus instintos mais apurados. Estes tendem a ser ilustradores, pintores e pessoas que lidam com a impressão.
- Profissionais técnicos. Estas são pessoas que usam o Krita como parte de um processo, e preocupam-se com as contas matemáticas e a manipulação dos pixels. Tendem a ser pessoas que trabalham no mundos dos jogos e da indústria do VFX, mas ocasionalmente encontra-se algum cientista entre eles.
Adultos e idosos com “hobbie”. Este grupo não sabe muito sobre computadores, e normalmente ficam sempre confusos com algum pequeno passo em falta no tutorial. O seu poder no grupo é que adaptam processos pouco convencionais da vida real que os estudantes não conhecem e que os profissionais não têm tempo para adquirir conhecimentos, e que criam coisas bonitas com isso, assim como têm efeito de equilíbrio do primeiro grupo em toda a comunidade.

A partir destes quatro grupos…

só existe um que é técnico. É por isso que precisamos das páginas do conceito, para que possamos criar uma base sólida para escrever os nossos textos do manual.
três deles provavelmente terão alguma experiência prévia com as aplicações e poderão necessitar de guias de migração e explicar como se faz.
dois deles precisam de saber como ter o Krita a cooperar com outras aplicações.
dois deles não fazem a ideia do que estão a fazer e poderão ter de ser conduzidos pelos passos mais básicos.

A partir daí, ficamos com as seguintes regras:

Escrita Geral¶

Use o Inglês dos EUA, se possível.: Usamos o Inglês dos EUA no manual, de acordo com a interface do Krita ser em Inglês dos EUA por omissão.
Mantenha a linguagem educada, mas não use linguagem académica.: Como uma comunidade, queremos ser calorosos a dar as boas-vindas aos utilizadores, portanto tentamos evitar linguagem que não seja hospitaleira. O uso de calão já é algo não aceite pelo KDE, mas ir até ao outro extremo, com um estilo académico em que nem o escritor nem o leitor se vêem reconhecidos, poderá dar a ideia que o texto muito mais complexo que o necessário, o que poderá espantar os utilizadores.
Evite usar GIF’s (aberto a debate): A razão é que as pessoas com epilepsia podem ser afectadas por imagens em movimento rápido. De forma semelhante, os GIF’s podem às vezes trazer muita da responsabilidade da explicação. Se não conseguir outra forma que não seja através de GIF’s, ao menos notifique o leitor deste facto na introdução da página.
Mantenha o texto compatível com traduções: Isto consiste no uso do SVG para gráficos informativos, e usando a formatação adequada para um dado texto.

Detalhes sobre as fotografias e pinturas¶

Desejaria desencorajar o uso de fotografias e pinturas tradicionais no manual, caso não estejam a ilustrar um dado conceito. A razão é que é um pouco pateta e desonesto mostrar o trabalho de Rembrandt dentro da interface do Krita, quando temos tantos trabalhos modernos que foram feitos no Krita. Todas as obras da Pepper&Carrot foi feito no Krita e os ficheiros originais estão disponíveis, pelo que, quando não tem uma imagem à mão, comece por aí. As fotografias devem ser evitadas, porque o programa do Krita é um programa de pintura. Demasiadas fotografias poderão dar a impressão que o Krita está a tentar ser uma solução para retoque de fotografias, quando não é esse o foco.
Obviamente, gostaríamos de demonstrar certos conceitos em acção nas fotografias e pinturas de mestres, como o brilho ou a luz indirecta. Nesse caso, adicione uma legenda que mencione o nome da pintura ou do pintor, ou que mencione que é uma fotografia.
As fotografias ainda podem continuar a ser usadas para fins lúdicos ou outros fins semelhantes, mas só se estiver obviamente nesse contexto.

Detalhes sobre as imagens em geral¶

Evite texto nas imagens e use os títulos em alternativa. Poderá fazer isto com a instrução “figure”.
Se não precisar de usar o texto, crie um SVG, para que o texto dentro dele possa ser manipulado com maior facilidade ou tente minimizar a quantidade de texto.
Tente criar as suas imagens com alta qualidade/bonitas. Convém dar a ideia às pessoas de que estão a usar um programa de desenho!
Lembre-se que o manual está licenciado segundo a GDPL 1.3, por isso as imagens enviadas serão licenciadas segundo estes termos. No caso do CC-By-Sa/CC-By, garanta que o ficheiro fica atribuído de forma adequada na legenda de uma figura. Não sendo necessário referi-lo, não submeta imagens que não possam ser licenciados segundo uma destas licenças.

Protocolo¶

Como tal, iremos descrever aqui todos os procedimentos aborrecidos.

Marcação e Ramificações¶

A adição e remoção de texto será feita na ramificação draft.

Os resultados de revisão das páginas antigas serão considerados correcções de erros e, como tal, irão para a ramificação master e serão reunidas com a ramificação draft de acordo com as necessidades.

Antes de a ramificação draft ser reunida para uma dada versão:

A ramificação master será marcada com a versão antiga.
A ramificação draft é verificada com atenção para saber se tem o número de versão actualizado e se actualizou a capa do ePub.

A ramificação draft não será reunida até ao dia antes de um dado lançamento, para manter as páginas intactas durante algum tempo.

Cada lançamento terá uma versão do ePub enviada como parte do processo de migração… De onde é que obtemos os ficheiros POT? Mesmo as versões traduzidas?

Remover as Páginas¶

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

Serão primeiro marcadas como obsoletas.

Isto poderá ser feito da seguinte forma:

.. deprecated:: número de versão

    Texto para indicar o que o utilizador deverá fazer sem esta funcionalidade.

Será associada a uma página chamada “deprecated” (obsoleta)
Se a próxima versão entrar, todas as páginas ligadas à secção obsoleta serão removidas.

Adicionar Páginas¶

Certifique-se que se encontra no local correcto.
Siga as Convenções de formatação para o Manual do Krita para garantir que a página está formatada correctamente.
Adicione a página ao índice analítico.

Se a funcionalidade nova, adicione no “versionadded”:

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

    uma coisa opcional ou a outra.

Como no caso das imagens, não adicione texto que não tenha permissão para adicionar. Isto significa que o texto ou é escrito por si, ou que tenha autorização para o transcrever do autor original. O manual está na GDPL 1.3+, pelo que o texto será licenciado de novo segundo estes termos.

Modificar as Páginas¶

Se remodelar por completo uma página, em vez de a rever simplesmente, a página resultante deverá ser revista.

Se mudar uma página porque mudou uma funcionalidade, e caso tenha acesso de escrita, a modificação poderá ser enviada por “push” sem revisões (a menos que se sinta mais confortável com uma revisão), mas deverá adicionar:

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

    Isto e aquilo mudou.

Em todos os casos, verifique se se deseja adicionar a si mesmo no campo de autor, na secção de meta-dados no topo.

Usando o “deprecated”, o “versionadded” e o “versionchanged” com o número de versão, permite-nos pesquisar facilmente no manual por estes termos com o “grep”:

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

Páginas com problemas¶

Se uma página passar nos pingos da chuva, então…

Faça um pedido de revisão pela secção Fazer alterações.
Crie uma tarefa no Quadro do Projecto Manual.
Crie um erro no bugzilla no projecto Krita, na secção “documentation” (documentação).

Revisão de textos¶

Existem dois tipos de revisões que precisam de ser feitas.

A mais importante é rever as alterações feitas pelas pessoas. Poderá fazer isto no KDE_gitlab de duas formas:

Rever os pedidos de reunião

Poderá ajudar a rever os pedidos de reunião. A revisão de modificações é normalmente feita por programadores para descobrir erros no código uns dos outros, mas como o código de programação é baseado em texto, como no texto normal, podemos usar a revisão de “patches” (modificações) para validar erros da mesma forma!

Uma modificação, ou “patch”, é um conjunto de alterações feitas num documento (adicionadas, removidas) que são colocadas num ficheiro legível para a máquina. Quando alguém submete um pedido de revisão (em sistemas como o GitLab ou o GitHub, isto é um pedido de “merge” ou “pull”), as pessoas que fazem a manutenção dos ficheiros originais terão de olhar para elas e poderão fazer comentários sobre as coisas que precisam de ser aleradas. Isto permite-lhes comentar sobre coisas como erros ortográficos, escrita demasiado complicada mas também por coisas que estejam incorrectas. Depois de ter sido aceite uma modificação, poderá ser enviada (“pushed”) para o sistema de controlo de versões.
Comentar as modificações no manual.

A auditoria de alterações ocorre após o sucedido. Poderá auditar uma modificação se for à mensagem de modificação (na página do repositório, vá ao histórico e depois carregue num elemento), onde poderá fazer comentários sobre as alterações efectuadas.

Em ambos os casos, a interface consiste na diferença a ser apresentada, estando do lado esquerdo a versão antiga e do lado direito a nova versão. As linhas que foram adicionadas ficarão marcadas a verde, enquanto que as linhas que foram removidas ficarão marcadas a vermelho. Poderá carregar numa linha para adicionar um comentário “incorporado”.

A segunda forma mais importante em que o manual precisa de ser revisto é em todo o ficheiro. Muitas das páginas só foram verificadas a nível de correcção, mas não a nível de estilo e gramática.

Para tal, irá precisar de seguir a secção Fazer alterações, para que possa ter acesso total às páginas e editá-las.

Tradução¶

A tradução do manual é feita pela comunidade de traduções do KDE. Para se juntar ao esforço de traduções, vá à página de localização, seleccione a lista de equipas de tradução, seleccione a língua que deseja traduzir e siga as instruções na página da equipa para ficar em contacto com os colegas tradutores.

Consulte por favor a página https://community.kde.org/Get_Involved/translation para obter instruções mais gerais sobre como se envolver na tradução do KDE.

A equipa de traduções tem acesso aos ficheiros PO deste manual, o qual é um tipo de ficheiro usado pelos programas de traduções, como o POEdit e o Lokalize. Uma equipa de traduções será capaz de trabalhar em conjunto na tradução destes ficheiros e de os enviar para ao SVN das traduções. Nesse caso, um programa especial irá então pegar nas traduções do SVN e trazê-las para a secção do manual, para serem incorporadas numa base diária.

As imagens poderão ser traduzidas se uma equipa de traduções quiser fornecer as suas próprias imagens. Todas as imagens na pasta de imagens estão por omissão em “en”. Quando quiser traduzir uma imagem específica, vá a essa pasta e adicione outra pasta com o código da sua língua para adicionar as versões traduzidas das imagens. Assim, o Sphinx irá procurar por uma versão em Português do /images/Pixels-brushstroke.png em /images/pt/Pixels-brushstroke.png e por uma versão em Português do /images/dockers/Krita-tutorial2-I.1-2.png em /images/dockers/pt/Krita-tutorial2-I.1-2.png.

As traduções terminadas também precisam de ser adicionadas ao programa de compilação para aparecerem “online”. As equipas de traduções que estão confiantes com o estado das suas traduções deverão contactar a equipa principal do Krita com a lista de correio “kimageshop” (kimageshop@kde.org) ou em foundation@krita.org, para conseguir isto.

Outro¶

Para as convenções de restructuredText, consulte a página Convenções de formatação para o Manual do Krita.