Krita 설명서 기여 가이드¶

Welcome to the Krita Manual Contribution Guide!

If you’re interested in contributing to Krita’s documentation, you’re in the right place.

Krita는 (자유) 오픈 소스 소프트웨어로, 수십 명의 자원 봉사자가 더 나은 프로젝트를 만들기 위해 참여하는 커뮤니티 프로젝트입니다. 따라서 새로운 자원 봉사자가 참여하여 Krita를 도울 수 있는 설명서와 노하우를 구축해야 합니다. 그 동안 이 작업을 해 왔던 곳은 꽤 넓게 퍼져 있었고 종종 관리되지 않기도 했습니다. 기여자 설명서는 모든 정보를 한 곳에 모으려는 시도입니다. 따라서 매우 기술적인 내용을 다루고 있습니다.

This documentation will include:

Krita 참조 설명서

This one is probably what everyone is expecting when they look up Krita’s documentation. Dry, basic, ‘what does this button do’ type of information.

일반적인 개념 자습서.

지난 2년 동안 특정한 사용자에게는 예시가 있는 참조 설명서도 충분하지 않다는 것을 확인했습니다. 또한 설명서는 개념을 빠르고 간결하게 설명해야 하며, 웹에서 사용할 이미지를 준비하기 위한 기본적인 작업 흐름을 다뤄야 합니다.

또한 Krita의 색 관리나 레이어 처리와 같은 특정 개념은 일반적인 예술가가 익숙한 것보다 훨씬 더 진보된 것으로 나타났습니다. Krita는 자유롭게 사용할 수 있으며, 많은 사용자는 디지털 아트워크 공식 교육을 받지 않았습니다. 따라서 예술가라면 알고 있었을 수도 있는 색상 관리 또는 필터 레이어를 사용하는 방법을 모를 수도 있습니다.

In addition there are systems that are unique to Krita, for example the brush system, the transform masks, the alpha inheritance and the perspective assistants. Finally, there are users who aren’t familiar with even standard painting workflows, and are not flexible enough to understand how to port a tutorial for SAI or Photoshop to Krita.

알려진 자습서 및 비디오 자습서의 목록

Krita 팀의 가장 큰 장점 중 하나는 예술가와 연결하고 그들이 멋진 일을 하고 있다는 것을 인정하는 것입니다. Krita를 사용하고 그림을 그리는 독특한 방법이 있으며, 사람들이 지식을 공유하도록 장려해야 하기 때문에 자습서도 마찬가지여야 합니다.

Contributors’ Manual

What you’re reading right now!

krita.org 자습서

krita.org 및 krita-foundation.tumblr.com에는 수많은 자습서가 있습니다. krita.org 사이트에는 새로운 기능을 사용하는 방법 위주로 설명하고, Tumblr에는 사용자 요청으로 쓴 글 위주로 설명하고 있습니다.

자주 묻는 질문

현재 온라인에 게시되어 있으며 그 동안 만들어졌던 여러 가지 자주 묻는 질문을 통합한 것입니다. 현재 번역 중이며, 앞으로도 계속 이 문서를 주 문서로 업데이트합니다.

처음 시작하기 전에¶

미디어위키와는 다르게 Sphinx 문법은 Krita 코드 작성과 비슷합니다.

어떻게 시작해야 할지 모르겠다면 먼저 저희와 연락하십시오! Matrix를 사용해서 “#krita” 대화방에 입장할 수 있습니다. Matrix에 대한 정보는 이 문서를 참조하십시오. webchat.kde.org 사이트에 Matrix 계정을 등록하고 #krita:kde.org 채널에 입장하십시오. 작업을 더 간단하게 하려면 identity.kde.org에 계정을 만들 수 있습니다. KDE Identity 계정은 invent.kde.org 사이트와 Krita 개발을 조직하는 Phabricator에 모두 사용할 수 있는 공통 계정입니다.

Sphinx는 reStructuredText 마크업을 사용하여 작성한 간단한 텍스트 파일로부터 작동하며, 해당 텍스트 파일을 처리하여 설명서로 변환합니다. 설명서의 변경 사항은 버전 관리 시스템 Git으로 추적합니다.

변경 사항 만들기¶

저희가 사용하는 Git 버전 관리 시스템에 파일을 넣을 수 있는 사람은 몇 안 되기 때문에 내용을 변경하려면 우선 검토 요청을 올려야 합니다.

편집 모드를 사용하여 병합 요청 만들기¶

참고

이 방법은 KDE 저장소에 푸시 권한이 없을 때에만 유용합니다. 변경 사항을 저장소에 바로 커밋하므로, 현재 가이드라인에 적합하지 않습니다.

기술 지식이 없는 사용자에게 권장됩니다.

한 번에 두 개 이상의 파일을 변경하려는 경우에는 권장되지 않습니다.(추가 파일을 변경하거나, 단순히 병합 요청당 하나만 편집하려면 WebIDE를 사용하여 병합 요청 만들기 또는 명령행으로 병합 요청 만들기 섹션을 참조하십시오).

기여하려고 하는 변경 사항이 많을 경우, 다음 지침을 따르는 것이 좋습니다.

KDE Identity 계정을 만드십시오.
KDE_gitlab에 로그인하십시오.
repository로 이동하여 fork를 누르십시오.
이제 포크된 저장소로 이동합니다. 일반적으로 invent.kde.org/YOUR_KDE_LOGIN_NAME/docs-krita-org에 생성됩니다.
공식 저장소로 돌아가십시오. 자신의 포크가 아닌 Documentation > Krita.org Documentation 저장소를 탐색하고 있는지 확인하십시오. 그렇지 않으면 이 방법이 제대로 작동하지 않습니다.

Gitlab에는 Gitlab 자체에서 파일을 편집할 수 있는 옵션이 있습니다. 기능을 사용하려면 Repository ‣ Files로 이동합니다.

페이지 맨 위에 master가 선택된 항목이 있는 드롭박스가 표시됩니다.

편집할 파일을 찾아 열고 Edit를 클릭하십시오.

변경합니다.(참고: 이 모드에서는 한 번에 하나의 파일만 편집할 수 있습니다).

아래 작은 텍스트 상자로 이동하여 커밋 메시지 부분에 변경한 내용을 요약하는 멋진 메시지를 작성하십시오. 완료되면 Commit changes를 누르십시오. 이렇게 하면 병합 요청이 이루어지며 여기에 설명한 대로 모든 필드를 채우십시오: 새 병합 요청에 대한 지침.

이 방법의 단점은 현재로서는 마크업 오류가 있는지 확인할 수 있는 방법이 없다는 것입니다. 온라인 Sphinx 편집기에서 변경 사항을 확인하십시오(편집할 전체 파일을 복사하여 붙여넣기만 하면 됩니다).

주의

Edit와 WebIDE는 별개의 것입니다! Edit를 선택하십시오.

WebIDE를 사용하여 병합 요청 만들기¶

여러 파일을 한 번에 편집하려는 약간의 Git 지식이 있는 사용자에게 권장됩니다.

브랜치가 무엇인지 모른다면 권장되지 않습니다(대신 편집 모드를 사용하여 병합 요청 만들기를 참조하십시오).

위의 안내에 따라 KDE_gitlab에 로그인하여 포크를 만듭니다.
포크로 이동합니다(URL에 사용자 이름이 들어 있는지 확인).
master 브랜치에 있는지 확인하십시오.
WebIDE를 클릭합니다. 그러면 왼쪽에 파일 목록이 있고 오른쪽에 파일 내용이 비어 있는 페이지로 이동합니다.
편집하려는 파일을 열고 변경하십시오.
Commit…을 클릭합니다. Unstaged changes 분류의 모든 파일을 두 번 클릭하여 Staged changes로 이동하십시오.
Commit…을 다시 클릭하면 커밋 메시지 텍스트 상자가 확장됩니다. 변경한 내용과 그 이유를 설명하는 커밋 메시지를 작성하십시오.
설정이 올바른지 확인하십시오: Create a new branch를 선택해야 합니다(브랜치 이름은 다음과 같아야 함: [username]/[very short description of your changes]). 변경을 완료한 다음 Start a new merge request가 선택되어 있는지 확인하십시오. 그렇지 않으면 나중에 수동으로 새 병합 요청을 만들어야 합니다.
Stage & Commit을 클릭하십시오.
모든 필드를 올바르게 입력하십시오: 참조 - 새 병합 요청에 대한 지침.
새 병합 요청을 수동으로 생성하려면 Krita 설명서 공식 저장소(지금 URL에 사용자 이름이 없는지 확인)로 이동하고, Create a new merge request(왼쪽 밝은 녹색 단추)를 클릭합니다. 내 포크를 선택하고 WebIDE에서 만든 브랜치를 선택하십시오.

참고

공식 저장소에 푸시 접근 권한이 없다면, 실수로 공식 저장소를 편집했다고 하더라도 Gitlab에서 변경 사항을 저장할 수 없습니다. 또한 Create a merge request를 누른다고 해도 달라지는 것이 없습니다. 개인 브랜치에 변경 사항을 커밋해야 하지만 푸시 권한이 없으면 수행할 수 없습니다. 다음과 같은 메시지만 표시됩니다: An error occurred whilst committing your changes. Please try again.

이 경우, 변경한 모든 파일의 내용을 복사한 다음, 포크로 이동하여 포크 WebIDE에 붙여 넣기만 하면 됩니다.

명령행으로 병합 요청 만들기¶

Git 작동 방식과 명령행 사용법을 알고 있는 사용자에게 권장됩니다.

브랜치가 무엇인지 모른다면 권장되지 않습니다(대신 편집 모드를 사용하여 병합 요청 만들기를 참조하십시오).

위의 안내에 따라 KDE_gitlab에 로그인하여 포크를 만듭니다.
저장소를 git clone 명령으로 로컬에 복제합니다. 저장소 페이지에는 Git 복제를 수행할 수 있는 URL이 있으며, 해당 URL을 사용하여 포크로 푸시할 수 있습니다. 이 방식의 장점은 컴퓨터에서 사용하던 도구로 텍스트 파일을 편집하고 로컬에서 직접 설명서를 빌드해서 오류를 검사할 수 있습니다.(이 단계는 한 번만 수행하면 됩니다.)
# SSH 접근 git clone git@invent.kde.org:<사용자_이름>/docs-krita-org.git git remote add upstream git@invent.kde.org:documentation/docs-krita-org.git # HTTPS 접근 git clone https://invent.kde.org/<사용자_이름>/docs-krita-org.git git remote add upstream https://invent.kde.org/documentation/docs-krita-org.git
새 내용을 변경하기 전에 항상 공식 저장소에서 변경 사항을 가져와야 합니다:
git pull upstream master
변경 사항을 포함하는 새 브랜치를 만들기 전에 master 브랜치에서 생성했는지를 확인하십시오(2019년 9월부터 적용됨).
git checkout master # 그 다음: git checkout -b "<사용자_이름>/<새_기능에_대한_설명>"

변경한 후 커밋하고 포크로 푸시합니다. 이 작업 흐름을 따른다면, 터미널에서 Git을 사용하는 방법에 대한 자세한 설명을 Forking on Gitlab 섹션에서 읽어 보십하십시오.

# 시스템에 python3-sphinx 패키지를 설치하십시오. 우분투의 경우 예시:
sudo apt install python3-sphinx
# 설명서 빌드(잠재적 오류를 보고하며 웹 브라우저에서 변경 사항 확인 가능)
make html
# 모든 것이 올바른지 확인
git status
git diff
# 모든 파일 추가
git add .
# 변경 사항 커밋
git commit
# 변경 사항을 포크로 제출
git push

마지막으로 원본 저장소의 웹사이트로 이동한 다음, Merge Request로 이동하십시오. 포크 및 올바른 브랜치를 선택하고 새 병합 요청을 생성하십시오. 필드를 입력하는 방법은 새 병합 요청에 대한 지침 섹션을 참조하십시오.

새 병합 요청에 대한 지침¶

커밋 메시지는 여기에 설명된 표준을 준수해야 합니다: Git 커밋 메시지 작성 방법
Title 및 Description 항목은 커밋 메시지와 마찬가지로 변경한 내용과 변경한 이유를 설명해야 합니다. 역시 위의 링크의 지침을 따르십시오.
Target 항목은 master를 가리켜야 합니다.
나중에 병합 요청을 변경해야 한다면, 병합 요청 제목 맨 앞에 [WIP]를 붙이십시오.
Allow commits from members who can merge to the target branch. 옵션을 선택했는지 확인하십시오. 기술적인 이유로 필요합니다. 병합 요청은 master 브랜치로 리베이스되며, 해당 변경 사항을 기술적으로 변경하지만 실제로 내용을 변경하지 않기 때문입니다. 리베이스 작업은 본인 및 검토자가 실행할 수 있습니다. 나중에 더 귀찮은 문제를 피하려면 검토자가 몇 번의 클릭으로 스스로 할 수 있도록 이 옵션을 선택하는 것이 좋습니다.
대부분의 경우 Delete source branch when merge request is accepted를 선택해도 무방합니다.
검토자가 달리 말하지 않는 한, Squash commits when merge request is accepted 옵션을 선택하십시오. 커밋 메시지의 첫 번째 줄은 병합 요청의 Title에서 가져온 것이며, 나머지 줄은 병합 요청의 Description에서 가져온 것입니다.
병합 요청 작성을 마치면 IRC(참조: 인터넷 릴레이 채팅)로 이동하여 푸시 접근 권한이 있는 사용자에게 병합 요청에 Needs Review 레이블을 추가하도록 요청하십시오.
실수가 있는 경우 병합 요청에 대한 피드백을 받을 수 있습니다. 브랜치의 실수를 다음 방법 중 하나로 수정하십시오.
- Edit 모드를 사용하려면 병합 요청의 Changes 섹션으로 이동하여 연필 아이콘(풍선 도움말: Edit)을 클릭하여 편집 모드를 다시 사용하십시오.
- WebIDE 모드를 사용하려면 포크로 이동하여 변경 중인 브랜치를 선택하고 WebIDE로 이동합니다.
- 컴퓨터에서 파일을 편집하고 터미널에서 작업하는 경우, 올바른 브랜치에 있는지 확인하고 변경 사항을 푸시하십시오. Gitlab은 병합 요청을 자동으로 업데이트합니다.
변경한 후에는 다른 사람에게 레이블을 Needs Review로 다시 변경하도록 요청해야 합니다.

자세한 내용은 기술 섹션의 Forking on Gitlab 부분을 확인하십시오.

참고

이 문서를 작성하는 시점에서 병합 요청에 레이블을 붙이는 작업은 공식 저장소에 쓰기 권한이 있는 기여자만 가능합니다. 이 말의 의미를 이해하지 못했다면, 공식 저장소에 쓰기 권한 또한 없습니다. 따라서 병합 요청을 새로 했거나 변경했다면 IRC 대화방(Krita 커뮤니티 참조)에 접속하여 다른 사람에게 레이블을 지정해 달라고 요청해야 합니다.

명령행에서 설명서 빌드하기¶

git 및 명령행 사용법을 알고 있고 병합 요청을 하기 전에 변경 사항을 적용해 보려면 명령행으로 병합 요청 만들기 부분의 5단계를 참조하십시오.

일반적인 철학¶

어떻게 글을 쓸 것인가에 대한 논의입니다. 글을 쓰는 방법은 실용적 특성이나 미적 특성 외에도 글의 목적이나 글에 담겨 있는 철학에 의해서 결정됩니다. 설명서를 통해 달성하려고 하는 목적은 무엇이며, 누가 설명서를 읽을 것입니까?

인구 통계와 대상 독자¶

모든 Krita 사용자가 55세 남성이라는 식으로 Krita 사용자의 인구 통계를 집계할 수는 없습니다. Krita는 다양한 사용자가 있으며, 우리는 실제로 다양한 사용자 기반을 가지고 있다는 것을 자랑스럽게 생각합니다.

그렇다고 하더라도 Krita 사용자층의 일부 특성을 파악하고 있습니다:

예술가. 우리가 대상으로 하는 주된 사용자 유형입니다.
- 예쁜 그림을 선호한다는 것을 우리는 알고 있습니다.
- 시각적입니다.
- 예쁜 그림을 얻으려고 노력하고 있습니다.

따라서 각 페이지의 암묵적인 목표는 예쁜 그림에 필요한 기능을 알게 되는 것입니다.

그 외에도 다음 그룹을 파악했습니다:

High-school and college students trying out drawing software for illustrations. These usually have some previous experience with drawing software, like Paint Tool SAI or Photoshop, but need to be introduced to possibilities in Krita. This group’s strength is that they share a lot of information with each other like tips and tricks and tutorials.
디지털 그리기 소프트웨어로 돈을 버는 전문가 집단. 이 그룹의 강점은 많은 노하우를 가지고 있으며 프로그램을 개선하기 위해 기꺼이 기부할 의향이 있다는 것입니다. 이들은 두 가지 유형으로 구분됩니다:
- 비 기술적 전문가. 이들은 소프트웨어의 수학적 요소를 파악하지 못하지만, 수년간 탄탄한 작업 흐름을 구축하고, 자신의 날카로운 본능을 사용하여 소프트웨어로 작업하는 사람들입니다. 주로 일러스트레이터, 화가, 인쇄물로 작업하는 사람들입니다.
- 기술적 전문가. 이들은 Krita를 파이프라인의 일부로 사용하며, 정확한 계산과 픽셀 처리에 신경을 씁니다. 주로 게임이나 시각 효과(VFX) 분야에 종사하고 있지만, 종종 과학자도 있습니다.
성인 및 노인 취미 활동가. 이 그룹은 컴퓨터에 대해 많이 알지 못하며 항상 자습서에서 누락된 작은 한 단계에서 고생하는 것처럼 보입니다. 그룹으로서 그들의 장점은 학생들은 알지 못하고 전문가들은 파악할 시간이 없는 실 생활에서 우러난 통상적이지 않은 작업 흐름으로 대단한 작품을 제작하며, 대형 커뮤니티의 활발한 사용자 그룹에 절제 효과를 준다는 것입니다.

이 네 그룹에서 얻은 사실…

기술적인 그룹은 단 하나 뿐입니다. 따라서 설명서를 작성할 때 견고한 기반이 될 수 있는 개념 설명 페이지가 필요합니다.
세 종류의 그룹은 이전에 다른 소프트웨어를 사용해 보았으며 Krita에서 같은 기능을 수행하는 방법에 대한 안내가 필요합니다.
두 종류의 그룹은 Krita와 다른 소프트웨어를 연동하는 방법에 대한 안내가 필요합니다.
두 종류의 그룹은 자신이 하고 있는 일에 대해서 잘 모를 수도 있으며 가장 기본적인 단계부터 안내해야 합니다.

이를 통해 다음과 같은 규칙을 정했습니다:

일반적인 글쓰기¶

가능하면 미국 영어를 사용하십시오.: Krita의 사용자 인터페이스는 기본적으로 미국 영어이므로 설명서도 같은 미국 영어를 사용합니다.
언어를 공손하게 유지하되, 학문적인 언어를 사용하지 마십시오.: 우리의 커뮤니티는 항상 새로운 사용자를 받아들이기를 원하므로 이들에게 부담이 될 수 있는 언어를 최대한 사용하지 않으려고 노력합니다. KDE는 이미 비속어를 제재하고 있지만, 다른 한편으로는 작가나 독자가 쉽게 파악할 수 없고 필요한 것보다 더 복잡한 학술적인 글쓰기도 지양합니다. 사용자들은 이런 글을 읽고 부담이 되어서 다가오지 못할 것입니다.
GIF 사용 자제(현재 토론 중): 빠르게 움직이는 이미지 때문에 간질 환자들이 영향을 받을 수 있기 때문입니다. 또한 GIF 이미지는 때때로 설명하기에 너무 많은 정보를 포함하고 있습니다. 만약 그래도 GIF 이미지를 사용해야 한다면 각각 페이지 소개글에 GIF 사용에 대해서 알려 주십시오.
번역하기 쉽도록 유지: 인포그래픽에 SVG를 사용하고 텍스트에 올바른 마크업을 사용하십시오.

사진 및 그림에 대하여¶

We would like to discourage photos and traditional paintings in the manual if they are not illustrating a concept. The reason is that it is very silly and a little dishonest to show Rembrandt’s work inside the Krita GUI, when we have so many modern works that were made in Krita. All of the Pepper&Carrot artwork was made in Krita and the original files are available, so when you do not have an image handy, start there. Photos should be avoided because Krita is a painting program. Too many photos can give the impression Krita is trying to be a solution for photo retouching, which really isn’t the focus.
물론 사진이나 명화를 사용하여 광택이나 간접광 같은 특정한 개념을 나타내야 할 필요도 있습니다. 이 경우에는 그림이나 화가의 이름을 언급하거나 사진이라고 언급하는 캡션을 추가하십시오.
사진을 직접적으로 다루어야 한다면 사진 자료를 사용할 수 있지만, 사진을 다루는 경우에만 사용하십시오.

일반적인 이미지 권고 사항¶

이미지에 텍스트를 직접 삽입하지 말고 캡션을 사용하십시오. figure 지시문으로 이 작업을 수행할 수 있습니다.
텍스트를 사용해야 한다면 SVG를 사용하여 내부의 텍스트를 쉽게 변경할 수 있도록 하거나 텍스트 사용량을 최소화하십시오.
최대한 고화질의 귀여운 이미지를 제작하십시오. 그리기 프로그램을 사용하고 있다는 것을 확실히 알려 주십시오!
이 설명서의 라이선스는 GDPL 1.3이므로 이 문서에 포함된 이미지 역시 같은 라이선스 조항을 따르게 됩니다. CC-BY-SA/CC-BY 이미지를 사용한다면 캡션에 저작자 정보를 올바르게 표시했는지 확인하십시오. 이 외 라이선스로 배포되는 이미지는 설명서에 사용할 수 없습니다.

규약¶

여기에 모든 지루한 작업 흐름이 정리되어 있습니다.

태그 지정 및 브랜치¶

텍스트 추가 및 제거는 draft 브랜치에서 수행됩니다.

이전 페이지에 대한 교정 결과는 버그 수정으로 간주되므로 master 브랜치로 이동하여 필요에 따라 draft 브랜치로 병합됩니다.

지정된 릴리스에 대해 draft 브랜치가 병합되기 전에 다음과 같은 작업을 수행합니다:

master 브랜치에는 이전 버전으로 태그가 지정됩니다.
draft 브랜치는 먼저 업데이트된 버전 번호와 업데이트된 EPub 표지가 있는지 다시 확인합니다.

draft 브랜치는 페이지를 오래 유지하기 위해 릴리스 전날까지 병합되지 않습니다.

각각 릴리스에는 릴리스 준비 과정의 일부로 EPub 버전이 업로드됩니다. .. POT 파일은 어디에서 생성됩니까? 번역된 버전은?

페이지 삭제¶

특정 버전에서 기능이 제거되면 해당 페이지는 다음과 같이 처리됩니다:

먼저 더 이상 사용되지 않음으로 표시됩니다.

이 작업은 다음과 같이 수행할 수 있습니다:

.. deprecated:: version number

    사용자가 이 기능을 사용하지 않고 작업을 수행하는 방법을 안내합니다.

‘deprecated’ 라는 페이지에 링크됩니다
다음 버전이 출시되면 사용되지 않음 페이지에 링크된 모든 페이지가 삭제됩니다.

페이지 추가¶

올바른 위치에 있는지 확인합니다.
Krita 설명서의 마크업 표기 규칙에 따라 페이지 형식이 올바른지 확인합니다.
페이지를 TOC에 추가합니다.

새로 추가된 기능이라면 versionadded에 추가합니다:

.. versionadded:: 버전 번호

    선택적인 것 또는 다른 것.

이미지와 마찬가지로 추가 권한이 없는 텍스트는 추가하지 마십시오. 즉, 텍스트는 귀하가 작성했거나 원본 작성자로부터 텍스트를 이식할 권한이 있음을 의미합니다. 설명서는 GDPL 1.3 이상이므로 텍스트는 그에 따라 라이선스가 부여됩니다.

페이지 변경¶

페이지를 교정하는 것이 아니라 완전히 다시 작성한다면 작성 결과는 검토 과정을 거쳐야 합니다.

기능이 변경되어 페이지를 변경했고, 커밋 접근 권한이 있다면 (검토 과정이 필요하다고 생각하지 않는다면) 검토 없이 변경 사항을 푸시할 수 있지만 다음 사항을 추가해야 합니다:

.. versionchanged:: 버전 번호

    이런저런 것이 달라졌습니다.

위 모든 상황에서 페이지 상단의 메타데이터 섹션에 작성자 이름을 추가해야 할지 여부를 확인하십시오.

deprecated, versionadded, versionchanged 키워드와 버전 번호를 같이 사용하면 해당 단어로 grep을 수행하여 설명서를 쉽게 검색할 수 있습니다:

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

잘못된 페이지¶

만약 특정한 페이지가 잘못되었음을 발견했다면…

변경 사항 만들기 섹션에 따라 병합 요청을 해 주십시오.
Manual Project Workboard에 작업을 생성하십시오.
bugzilla의 Krita 제품의 ‘documentation’ 섹션에 버그를 보고해 주십시오.

교정¶

교정에는 두 가지 유형이 있습니다.

가장 중요한 것은 사람들이 변경한 사항을 검토하는 것입니다. KDE_gitlab에서 두 가지 방법으로 이 작업을 수행할 수 있습니다:

병합 요청 검토

병합 요청을 검토하는 데 도움이 될 수 있습니다. 요청 검토는 일반적으로 프로그래머들이 서로의 코드에서 실수를 찾기 위해 수행하지만, 프로그래밍 코드는 일반 텍스트와 마찬가지로 텍스트 기반이기 때문에 이것을 사용하여 오타를 확인할 수도 있습니다!

병합 요청은 컴퓨터에서 읽을 수 있는 파일에 넣은 문서(추가됨, 제거됨)에서 수행된 변경 사항입니다. 누군가가 검토 요청을 제출(Gitlab 또는 Github와 같은 시스템에서 이것은 병합 또는 풀 요청임)할 때, 원본 파일을 유지 관리하는 사람들은 파일을 살펴보고 변경해야 하는 것에 대해 의견을 낼 수 있습니다. 이를 통해 오타, 지나치게 복잡한 글쓰기, 잘못된 항목에 대한 댓글을 달 수 있습니다. 패치가 수락된 후에는 버전 관리 시스템으로 푸시할 수 있습니다.
설명서의 변경 사항에 대한 댓글 달기.

변경 사항이 커밋된 후에 댓글을 달 수 있습니다. 커밋 메시지(저장소 페이지에서 기록으로 이동한 다음 항목을 클릭)로 이동하여 변경 사항에 대한 댓글을 작성할 수 있습니다.

두 경우 모두 인터페이스는 왼쪽에 이전 버전과 오른쪽에 새 버전으로 표시되는 차이점으로 구성됩니다. 추가된 선은 녹색으로 표시되고 제거된 선은 빨간색으로 표시됩니다. 말풍선 아이콘을 클릭하여 ‘인라인’ 댓글을 추가할 수 있습니다.

설명서를 교정하는 두 번째 주요 방법은 전체 파일을 검토하는 것입니다. 대부분의 페이지는 정확성만 확인했을 뿐 스타일과 문법은 확인되지 않았습니다.

이 작업을 수행하기 전에 변경 사항 만들기 섹션을 따라서 페이지 전체를 보고 편집할 수 있어야 합니다.

번역¶

설명서의 번역은 ‘KDE 지역화 커뮤니티 <https://l10n.kde.org/>’_에서 처리합니다. 번역 활동에 참여하려면 지역화 사이트로 이동하여 ‘번역 팀 <https://l10n.kde.org/teams-list.php>’_의 목록을 선택하고, 번역할 언어를 선택하고 팀 페이지의 지침에 따라 동료 번역가에게 연락하십시오.

Please refer to https://community.kde.org/Get_Involved/translation for more general instructions on getting involved in KDE localization.

지역화 팀은 POEdit 및 Lokalize와 같은 번역 프로그램에서 사용하는 파일 형식인 이 설명서의 PO 파일에 접근할 수 있습니다. 번역 팀은 이러한 파일을 번역하고 번역 SVN에 업로드하는 작업을 함께할 수 있습니다. 그런 다음 특수 스크립트는 SVN에서 번역한 내용을 설명서 섹션으로 가져와서 매일 통합합니다.

번역 팀이 자체 이미지를 제공하려는 경우 이미지를 번역할 수 있습니다. 이미지 폴더의 모든 이미지는 기본적으로 ‘en’입니다. 특정 이미지를 번역하려면 해당 폴더로 이동한 다음 언어 코드가 있는 다른 폴더를 추가하여 이미지의 변환된 버전에 추가합니다. 그래서 Sphinx는 /images/nl/Pixels-brushstroke.png에서 /images/Pixels-brushstroke.png의 네덜란드어 버전과 /images/dockers/nl/Krita-tutorial2-I.1-2.png에서 /images/dockers/Krita-tutorial2-I.1-2.png의 네덜란드어 버전을 검색합니다.

완성된 번역도 빌드 스크립트에 추가하여 온라인으로 표시해야 합니다. 번역 상태에 자신감을 가지고 있는 번역 팀은 kimageshop 메일링 리스트(kimageshop@kde.org) 또는 foundation@krita.org 메일 주소를 통해서 주 Krita 팀에 연락해야 합니다.

기타¶

reStructuredText 표기법 규칙을 보려면 Krita 설명서의 마크업 표기 규칙 문서를 참조하십시오.