Настанови учасника написання підручника Krita¶

Вітаємо на сторінці настанов учасника написання підручника Krita!

Якщо ви хочете взяти участь у написанні документації до Krita, ви потрапили на потрібну вам сторінку.

Krita є вільним програмним забезпеченням із відкритим кодом, тобто, фактично, проєктом спільноти, результатом зусиль десятків людей, які хочуть зробити програму кращою. Тому, звичайно ж, нам потрібні підручники і настанови для тих, хто хоче приєднатися до проєкту і допомогти нам. Різні платформи, на яких ми намагалися це зробити призводили до розпорошення зусиль та, почасти, до недостатнього супроводу вже створених навчальних матеріалів. Підручник учасника — спроба сконцентрувати усю наявну інформацію. Саме тому, у деяких місцях цього підручника ви можете зустріти доволі складні з технічної точки зору відомості.

До цієї документації буде включено таке:

Довідник з Krita

Це, ймовірно, те, що кожен очікує побачити, коли шукає документацію до Krita. Короткий, базовий тип відомостей «для чого призначено цю кнопку».

Підручники із загальних понять

Протягом останніх двох років ми переконалися, що для певних категорій користувачів довідкового підручника, навіть із певними прикладами, просто недостатньо. У підручнику мають бути короткі і точні пояснення щодо принципів роботи, а також описи робочих процедур приготування зображень для оприлюднення у мережі.

Нами також було виявлено, що деякі інструменти, зокрема керування кольорами та робота з шарами, мають у Krita ширші можливості, ніж звик звичайний художник. Krita є безкоштовною програмою і багато з її користувачів не мають формальної підготовки у цифровому малюванні. Отже, у користувачів немає попереднього фокусованого на художнику значення щодо того, як користуватися керуванням кольорами або шарами фільтрування.

Окрім того, існують системи, які є унікальними для Krita, наприклад, система пензлів, маски перетворення, успадкування прозорості та допоміжні засоби перспективи. Нарешті, існують користувачі, які не обізнані навіть із стандартними робочими процедурами з малювання, — таким користувачам важко зрозуміти, як скористатися настановами щодо малювання у SAI або Photoshop у Krita.

Список відомих підручників та відеопідручників

Ймовірно, однією з найпрекрасніших речей, які можна сказати про команду Krita, є те, що ми тісно пов’язані із художниками і завжди вдячні їм за те, що вони роблять. Те саме має стосуватися підручників, особливо через те, що існують способи використання Krita та техніки малювання, які є унікальними для програми і ми хочемо, щоб користувачі ділилися ними із іншими користувачами.

Підручник учасника розробки

Те, що ви читаєте зараз!

Підручники на krita.org

На krita.org та krita-foundation.tumblr.com було багато навчальних матеріалів, на першому з цих сайтів акцент було зроблено на пояснення того, як користуватися новими можливостями, а на другому — на запитах користувачів.

Поширені питання

Цей розділ вже створено, він є об’єднанням різних розділів питань і відповідей. Цей розділ вже можна перекладати. Ми сподіваємося оновлювати його у першу чергу.

Для початківців¶

На відміну від Mediawiki, Sphinx працює у спосіб, подібний до того, у який ми пишемо коду для Krita.

Спочатку, звичайно ж, канали для спілкування із нами! Для спілкування ви можете долучитися до нас у кімнаті обговорення «#krita» у matrix. Вступні зауваження щодо Matrix наведено тут. Створіть обліковий запис matrix у webchat.kde.org і долучайтеся до каналу #krita:kde.org. Крім того, що важливіше, варто створити обліковий запис на identity, яким можна скористатися як для доступу до invent.kde.org, так і для роботи з phabricator, системою, за допомогою якої ми упорядковуємо розробку Krita.

Sphinx працює на основі написаних прости текстових файлів з розміткою reStructuredText. Система обробляє ці текстові файли і перетворює їх на підручник. Ми стежимо за змінами у підручнику, зберігаючи їх до системи керування версіями, яка має назву Git.

Внесення змін¶

Оскільки ми користуємося Git, доступ до запису до системи керування версіями має лише обмежене коло розробників. Якщо ви хочете внести якісь зміни до підручника, вам слід передати їх для рецензування.

Створення запитів щодо об’єднання за допомогою режиму редагування¶

Примітка

Це основний спосіб, лише якщо у вас немає безпосереднього доступу на запис до сховищ коду KDE. Якщо у вас є такий доступ, ваші зміни буде записано безпосередньо до сховища, що суперечить поточним настановам щодо роботи з кодом.

Рекомендуємо користувачам, у яких немає значного технічного досвіду.

Не рекомендуємо, якщо хочете внести зміни до декількох файлів одночасно. (Див. Створення запитів щодо об’єднання за допомогою WebIDE або Створення запитів щодо об’єднання за допомогою командного рядка, якщо хочете внести зміни до декількох файлів або просто створіть запит щодо об’єднання для змін у кожному з файлів).

Якщо ви хочете змінити значну частину підручника, рекомендуємо скористатися саме цими настановами.

Отримайте власний обліковий запис KDE.
Увійдіть до KDE_gitlab.
Перейдіть до сторінки repository, натисніть кнопку fork.
У відповідь має бути відкрито сторінку відгалуження сховища. Типово, це буде сторінка invent.kde.org/ВАШ_ПСЕВДОНІМ_У_KDE/docs-krita-org.
Поверніться до офіційного сховища. Переконайтеся, що ви переглядаєте сторінку Documentation > Krita.org Documentation, а не сторінку створеного вами відгалуження. Якщо ви цього не зробите, цей спосіб не спрацює належним чином.

У Gitlab передбачено можливість редагувати файли на самому gitlab. Щоб отримати доступ до цієї можливості, скористайтеся пунктом Repository ‣ Files.

У верхній частині сторінки буде показано спадне меню із вибраним пунктом master.

Знайдіть файл, який ви хочете редагувати, відкрийте його, а далі, натисніть кнопку Edit.

Внесіть зміни. (Зауваження: у цьому режимі одночасно можна редагувати лише один файл).

Перейдіть до меншої панелі для введення тексту, яку розташовано нижче, і впишіть відповідне до внеску повідомлення. Після цього, натисніть кнопку Commit changes. У відповідь буде автоматично створено запит щодо об’єднання. Достатньо лише заповнити усі поля, які описано тут: Настанови щодо нових запитів щодо об’єднання.

Недоліком є те, що за поточних умов неможливо визначити, чи є помилки у розмітці, якщо ви використовуєте цей спосіб. Будь ласка, перевіряйте внесені вами зміни за допомогою Online Sphinx Editor (просто скопіюйте і вставте увесь вміст файла, який ви редагуєте).

Увага

Edit і WebIDE — два різних інструменти! Вам слід вибрати Edit.

Створення запитів щодо об’єднання за допомогою WebIDE¶

Рекомендуємо для користувачів, які мають певні знання з Git і хочуть внести зміни до декількох файлів одночасно.

Не рекомендуємо тим, хто нічого не знає про гілки у сховищі (вам варто скористатися порадами з розділу Створення запитів щодо об’єднання за допомогою режиму редагування).

Виконайте наведені вище настанови щодо входу до системи KDE_gitlab і створення вашого відгалуження сховища.
Перейдіть до вашого відгалуження (переконайтеся, що адреса сторінки містить ваше ім’я користувача).
Переконайтеся, що ви перебуваєте у гілці master.
Натисніть кнопку WebIDE. У відповідь буде відкрито сторінку зі списком файлів ліворуч і великою порожньою панеллю для вмісту файлів праворуч.
Відкрийте файли, які слід змінити, і внесіть потрібні зміни.
Натисніть кнопку Commit…. Двічі клацніть на пунктах усіх файлів у категорії Unstaged changes, щоб пересунути їх до списку Staged changes.
Натисніть кнопку Commit… ще раз. У відповідь буде знову відкрито панель для введення текстового повідомлення із описом внеску. Впишіть повідомлення щодо внеску, яке описує внесені вами зміни і причини для внесення цих змін.
Переконайтеся, що параметри вказано правильно: вам слід позначити пункт Create a new branch (назвою гілки має бути [користувач]/[короткий опис ваших змін]). Якщо внесення змін завершено, переконайтеся, що позначено пункт Start a new merge request. Якщо ви плануєте подальші зміни, вам доведеться створити запит щодо об’єднання пізніше вручну.
Натисніть кнопку Stage & Commit.
Заповніть усі поля належним чином: див. Настанови щодо нових запитів щодо об’єднання.
Щоб створити запит щодо об’єднання вручну, перейдіть до сторінки офіційного підручника з Krita (переконайтеся, що у адресі сторінки немає вашого імені користувача) і натисніть кнопку 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. Далі, ви можете записати (push) внесені змінні до вашого відгалуження. Перевагою цього способу є те, що ви можете скористатися усіма інструментами вашої операційної системи для редагування текстових файлів, а також зібрати підручник локально, щоб перевірити, чи не припустилися ви якихось помилок. (Цей крок має бути виконано лише один раз.)
# для доступу за допомогою 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
Не забудьте створити нову гілку для ваших змін, оскільки з вересня 2019 року усі зміни має бути відгалужено від master.
git checkout master # потім: git checkout -b "<користувач>/<опис нової можливості>"

Після внесення змін, запишіть їх до вашої копії (commit) і надішліть (push) до вашого відгалуження. Докладний опис користування Git у терміналі для цієї процедури редагування підручника наведено тут: Forking on Gitlab.

# встановіть пакунок python3-sphinx для вашої системи. Наприклад, для Ubuntu:
sudo apt install python3-sphinx
# зібрати підручник (повідомляє про потенційні помилки, надає змогу ознайомитися зі змінами у програмі для перегляду сторінок інтернету)
make html
# переконайтеся, що все працює як слід
git status
git diff
# додайте усі файли
git add .
# запишіть ваші зміни
git commit
# надішліть ваші зміни до відгалуження
git push

Нарешті, перейдіть до сторінки сайта початкового сховища, а потім перейдіть до розділу Merge Requests. Виберіть ваше відгалуження і належну гілку, потім створіть запит щодо об’єднання. Настанови щодо заповнення полів запиту можна знайти у розділі Настанови щодо нових запитів щодо об’єднання.

Настанови щодо нових запитів щодо об’єднання¶

Ваші повідомлення внесків мають відповідати стандартам, які описано тут: How to Write a Git Commit Message
Поля 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 (див. Internet Relay Chat) і попросіть когось із доступом до запису сховища додати мітку Needs Review до вашого запиту щодо об’єднання.
Якщо у новому коді буде виявлено помилки, вас можуть попросити їх виправити. Виправте помилку у вашому відгалуженні у один із описаних нижче способів.
- Якщо ви хочете скористатися режимом Edit, просто перейдіть до розділу Changes сторінки запиту щодо об’єднання і натисніть на піктограмі із зображенням олівця (її підказкою є Edit), щоб знову перейти до режиму редагування.
- Якщо ви хочете скористатися режимом WebIDE, виберіть гілку із внесеними вами змінами і перейдіть до WebIDE.
- Якщо ви редагуєте файли на вашому комп’ютері і працюєте з терміналом, переконайтеся, що вибрано належну гілку і запишіть ваші зміни до сховища — gitlab автоматично оновить ваш запит щодо об’єднання.
Після внесення змін знову попросіть когось змінити мітку на Needs Review.

Щоб дізнатися більше, ознайомтеся із розділом Forking on Gitlab у технічній главі.

Примітка

На час написання цього підручника встановлення міток для запитів щодо об’єднання було можливим лише для учасників із правами запису до офіційного сховища. (Якщо ви не знаєте, що це усе означає, ймовірно, у вас немає таких прав.) Через це, коли ви створюєте запит щодо об’єднання або вносите до запиту зміни, вам слід звернутися до IRC (див. Спільнота Krita) і попросити когось встановити відповідну мітку.

Збирання підручника з командного рядка¶

Ті, хто спочатку хочуть спробувати результати змін, перш ніж створювати запит щодо об’єднання (і вже знайомі із користуванням git та командним рядком), можут знайти опис у кроці 5 у розділі Створення запитів щодо об’єднання за допомогою командного рядка.

Загальна філософія¶

Цей розділ присвячено визначенню відповідного стилю викладення. Стиль викладення, розглядатимемо ми його практичні чи естетичні якості, зазвичай, визначається призначенням або загальною філософією матеріалу. Чого ж ми хочемо досягти у підручнику і для кого призначено сам підручник?

Демографія і цільова аудиторія¶

Ми не можемо нічого сказати щодо демографічного зрізу у сенсі того, що, наприклад, ми знаємо, що усі користувачі Krita є чоловіками 55 років. Krita використовують зовсім різні люди, і ми навіть дещо пишаємося тим, що у нас така різнорідна база користувачів.

Незважаючи на це, ми дещо знаємо про наших користувачів:

Вони художники. Це саме той тип користувачів, на яких ми розраховуємо.
- Тому ми знаємо, що вони надають перевагу зображенням.
- Вони мислять візуально.
- Вони намагаються досягти краси у зображеннях.

Тому неявною метою створення кожної сторінки підручника має бути використання певної можливості для отримання ілюстративних прикладів.

Крім того, нашими цільовими групами є такі:

Учні старших класів та студенти, які користуються програмним забезпеченням для малювання для створення ілюстрацій. Ця категорія користувачів, зазвичай, вже має досвід користування іншим програмним забезпеченням для малювання, зокрема Paint Tool SAI або Photoshop, але потребує вступних відомостей щодо можливостей Krita. Перевага цієї групи полягає у тому, що користувачі з неї активно діляться інформацією, зокрема підказками та настановами, між собою.
Професіонали, люди, які заробляють гроші за допомогою програмного забезпечення для цифрового малювання. Перевага цієї групи полягає у тому, що користувачі з неї володіють багатьма унікальними методиками малювання і можуть ділитися ними та фінансово підтримувати розробку програми. Користувачів з цієї групи можна поділити на два типи:
- Професіонали-гуманітарії. Це користувачі, які не дуже розуміються на математичних принципах роботи програмного забезпечення, але які мають величезний досвід і користуються ним для роботи із програмним забезпеченням, покладаючись на власні інстинкти. Такі користувачі трапляються серед ілюстраторів, художників та тих, хто має справу із друкарством.
- Професіонали-технологи. Це користувачі, які використовують Krita як частину технологічного конвеєра і розуміються на точній математиці та роботі з пікселями. Такі користувачі трапляються серед тих, хто працює у ігровій індустрії та просторовому моделюванні, але серед них є і справжні науковці.
Дорослі аматори та аматори у віці. Користувачі з цієї групи не дуже-то знаються на комп’ютерах. У них виникають труднощі, якщо у настановах з певної причини пропущено якийсь крок. Перевага цієї групи полягає у тому, що користувачі з неї можуть придумувати незвичайні робочі процедури з реального життя, такі процедури, про які нічого невідомо студентами, і на які немає часу у професіоналів. Ці процедури надають змогу створювати унікальні речі. Такі користувачі корисні також тим, що можуть модерувати надмірний ентузіазм користувачів з першої групи у великій спільноті.

З цих чотирьох груп…

Лише одна група є технічною. Ось чому на потрібні сторінки щодо понять: вони створюють надійну основу для побудови решти текстів підручника.
Три з цих груп, ймовірно, вже мали попередній досвід із іншим програмним забезпечення і можуть потребувати настанов із переходу на використання Krita.
двом з них потрібні дані щодо того, як змусити Krita працювати із іншим програмним забезпеченням.
дві з них не мають гадки про те, що вони роблять, і можуть потребувати настанов щодо виконання навіть дуже простих дій.

Звідси, маємо такі правила:

Загальні зауваження щодо текстів¶

Використовуйте американську англійську, якщо можливо.: У підручнику ми використовуємо американську англійську, оскільки базовий інтерфейс користувача Krita використовує американську англійську.
Мова підручника має бути ввічливою, але не занадто академічною.: Як спільнота, ми маємо добре поводитися один з одним, тому маємо уникати будь-яких моментів у спілкуванні, які можуть когось образити. Грубощі є неприйнятними вже на рівні KDE, але, з іншого боку, спілкування в академічному стилі, де є певне відчуження між автором тексту і читачем, може створити враження, що текст є надто складним і відлякати користувачів.
Уникайте використання GIF (можливі варіанти): Причиною цього є те, що у людей з епілепсією швидка зміна зображення може призвести до нападу. Крім того, GIF іноді містять надто велику частину пояснення. Якщо ви все ж не можете обійтися без GIF, принаймні попередьте про це читачів у вступі до сторінки.
Намагайтеся продумувати наперед можливість перекладу: Зокрема, користуйтеся SVG для інфографіки та використовуйте відповідну розмітку для тексту.

Щодо фотографій та малюнків¶

Не варто використовувати фотографії і традиційні карти у підручнику, якщо вони не ілюструють якусь концепцію. Причиною є те, що доволі нерозумно і дещо нечесно показувати роботу Рембрандта у графічному інтерфейсі Krita, коли ми маємо так багато сучасних робіт, які було створено у Krita. У Krita було створено увесь комікс pepper&carrot, доступні початкові файли, отже, якщо у вас немає потрібних вам зображень, ви можете скористатися цим коміксом. Фотографій слід уникати, оскільки Krita є програмою для малювання. Забагато фотографій може створити враження, що Krita — програма для ретушування фотографій, що, звичайно ж, не є основним призначенням програми.
Звичайно ж, для показу роботи певних інструментів, зокрема глазурування та розсіяного світла, можна скористатися фотографіями та полотнами майстрів. Якщо ви використовуєте фотографію або якесь відоме полотно, не забудьте згадати у підписів назву картини або ім’я художника чи вказати, що використано фотографію.
Фотографіями можна скористатися у межах фотобашинґу (домальовування на фотографії), але якщо їх використано саме у контексті фотобашинґу.

Щодо зображень загалом¶

Уникайте тексту на зображеннях — використовуйте для текстових повідомлень підпис. Створити підпис можна за допомогою команди figure.
Якщо хочете використати текст на зображенні, або створіть SVG, щоб пізніше було легше працювати з цим текстом, або використовуйте якомога коротші написи.
Намагайтеся робити високоякісні і красиві зображення. Нехай читачі розуміють, що це програма для якісного малювання!
Не забувайте, що підручник випущено за умов ліцензування GDPL 1.3, тому зображення до нього повинні мати такі самі умови ліцензування. У випадку ліцензування CC-By-Sa/CC-By не забувайте належним чином повідомити про авторство у підписі до рисунка. Не варто навіть згадувати, але не надсилайте зображення, умови ліцензування яких конфліктують з умовами ліцензування підручника.

Протокол¶

Отже, тут ми розповідаємо про усі нудні робочі процедури.

Мітки і гілки¶

Додавання і вилучення тексту виконується у гілці draft.

Виправлення друкарських помилок на старих сторінках розглядатиметься як виправлення вад, а отже записуватиметься до гілки master, а зміни об’єднуватимуться із гілкою draft, якщо у цьому виникатиме потреба.

Перш ніж гілку draft буде об’єднано із гілкою певного випуску:

Гілка master позначається міткою старої версії.
Виконується ретельна перевірка того, що у гілці draft оновлено номер версії та обкладинку epub.

Гілку draft не буде об’єднано із основною до настання дня перед випуском, щоб зберігати незмінність сторінок достатньо довго.

Для кожного випуску буде виконано окремо вивантаження версії epub, як частини приготувань до випуску.

Вилучення сторінок¶

Якщо у певній версії вилучено якусь можливість програми, відповідні сторінки:

Буде спочатку позначено як застарілі.

Зробити це можна так:

.. deprecated:: version number

    Пояснення щодо того, що робити користувачам без цієї можливості.

Їх буде пов’язано зі сторінкою із назвою «deprecated»
Після виходу наступної версії усі сторінки, які пов’язано із застарілим розділом «deprecated», буде вилучено.

Додавання сторінок¶

Переконайтеся, що сторінку розміщено у належному місці.
Виконуєте настанови з розділу Правила розмітки у підручнику з Krita, щоб забезпечити належне форматування сторінки.
Додайте сторінку до таблиці змісту.

Якщо можливість є новою, додайте 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, це запит щодо об’єднання або отримання змін), користувачі, які здійснюють супровід початкових файлів, мають переглянути їх і можуть лишити коментарі щодо потрібних змін. Це надає змогу цим користувачам вказувати на помилки, зокрема друкарські, надто складне викладення матеріалу або помилкові твердження. Після прийняття латки її може бути записано до системи керування версіями.
Коментування змін у підручнику.

Коментування змін відбувається після записування до сховища. Ви можете виконати коментування змін, відкривши повідомлення про внесок (на сторінці сховища перейдіть до журналу (history), а потім натисніть відповідний пункт). Там ви зможете додати коментарі щодо внесених змін.

У обох випадках у інтерфейсі буде показано відмінності між версіями. Ліворуч буде показано стару версію, а праворуч — нову версію. Рядки, які було додано, буде позначено зеленим кольором, а рядки, які було вилучено — червоним. Ви можете клацнути на рядку і додати рядковий коментар. Зазвичай, при рецензуванні ви переглядаєте увесь набір змін і вписуєте коментарі там, де це потрібно. Щоб надіслати рядкові коментарі, натисніть піктограму із зображенням виносної репліки.

Другим важливим способом вичитування підручника є перевірка усього файла. Багато сторінок проходили лише перевірку на відповідність настанов, але не на стиль та граматику.

Для такої вичитки вам слід скористатися настановами розділу Внесення змін, щоб отримати повний доступ до сторінок та їхнього редагування.

Переклад¶

Переклад підручника виконує спільнота локалізації KDE. Щоб долучитися до перекладачів, відкрийте сайт локалізації, виберіть сторінку команд перекладачів, натисніть пункт команди мови, якою ви хочете перекладати і виконайте настанови на сторінці, яку буде відкрито, для встановлення зв’язку із колегами-перекладачами.

Будь ласка, зверніться до сторінки https://community.kde.org/Get_Involved/translation, де викладено загальні настанови щодо участі у локалізації KDE.

Команда з локалізації має доступ до файлів PO цього підручника. Цей тип файлів призначено для обробки у програмах для перекладу, зокрема POEdit та Lokalize. Команда перекладачів може працювати разом над перекладом цих файлів і вивантажувати результати до SVN перекладів. Далі, спеціальний скрипт отримає переклади з SVN і розмістить їх у розділі підручника для щоденного оновлення перекладу на сайті.

Зображення можна локалізувати, якщо команда перекладачів хоче надати локалізовані версії. Усі зображення у теці зображень (images) типово призначено для локалі „en“. Якщо ви хочете створити перекладену версію певного зображення, просто перейдіть до цієї теки і додайте теку із назвою, яка є кодом вашої локалі, для додавання до цієї теки перекладених версій зображень. Наприклад, Sphinx шукатиме українську версію /images/Pixels-brushstroke.png за адресою /images/uk_UA/Pixels-brushstroke.png, а українську версію /images/dockers/Krita-tutorial2-I.1-2.png — /images/dockers/uk_UA/Krita-tutorial2-I.1-2.png.

Завершені переклади також має бути додано до скрипту збирання, щоб їх можна було бачити у інтернеті. Команди перекладачів, які впевнені у стані перекладу, мають повідомити про завершення перекладу основну команду Krita за допомогою списку листування kimageshop (kimageshop@kde.org) або foundation@krita.org, щоб розробники додали переклад на сайт документації.

Інше¶

Настанови щодо форматування тексту у коді restructured наведено у розділі Правила розмітки у підручнику з Krita.