Krita Kılavuzuna Katkıda Bulunma Yönergesi¶

Krita Kılavuzu Katkıda Bulunma Yönergesine Hoş Geldiniz

Krita’nın belgelendirmesine katkıda bulunmak istiyorsanız doğru yerdesiniz.

Krita (ücretsiz) açık kaynaklı bir yazılımdır ve bu da bizi daha iyi hale getirmek için çabalayan düzinelerce gönüllüyle etkili bir şekilde bir topluluk projesi haline getirir. Bu, elbette, yeni gönüllülerin gelip bize yardım etmesi için kılavuzları ve nasıl yapılırları takip etmemizi gerektirdi. Bunu yaptığımız çeşitli yerler oldukça dağınıktı, bu nedenle katkıcıların el kitabı, bir tüm bilgileri bir araya getirme girişimidir. Bu nedenle yer yer çok tekniktir.

Belgelendirme şunları içerir:

Krita için bir başvuru kılavuzu

Bu muhtemelen herkesin Krita’nın belgelerine baktığında beklediği şeydir. Düz, basit, ‘bu düğme ne işe yarar’ türünden bilgiler.

Genel konsept öğreticileri.

Son iki yılda, belirli kullanıcı türleri için başvuru kılavuzunun bazı örneklerle bile yeterli olmadığını gördük. Kılavuz ayrıca, hızlı ve özlü açıklamalar sağlamalı ve web için bir görüntü hazırlamak için temel bir iş akışı sağlamalıdır.

Ayrıca renk yönetimi ve katman işleme gibi belirli kavramların Krita’da ortalama bir sanatçının alışık olduğundan çok daha gelişmiş olduğunu anladık. Krita ücretsizdir ve kullanıcılarının çoğu sayısal çizim konusunda resmi bir eğitime sahip olmayacaktır. Bu nedenle, renk yönetiminin veya süzgeç katmanlarının nasıl kullanılacağına dair önceden sanatçı odaklı bir bilgi yoktur.

Ayrıca, fırça sistemi, dönüşüm maskeleri, alfa kalıtımı ve perspektif yardımcıları gibi Krita’ya özgü sistemler de vardır. Son olarak, standart boyama iş akışlarına bile aşina olmayan ve SAI veya Photoshop için bir öğreticiyi Krita’ya nasıl taşıyacağını anlayacak kadar esnek olmayan kullanıcılar var.

Bilinen yazılı ve video öğreticilerin bir listesi

Görünüşe göre, Krita’nın ekibiyle ilgili harika şeylerden biri, sanatçılarla nasıl bağlantı kurduğumuz ve harika şeyler yaptıklarını kabul etmemiz. Aynısı öğreticiler için de geçerli olmalı, özellikle de Krita’yı kullanmanın ve resme yaklaşmanın benzersiz yolları olduğu için ve insanları bilgilerini paylaşmaya teşvik etmeliyiz.

Katkıcılar Kılavuzu

Şu an okuduğunuz şey!

krita.org Öğreticileri

Krita.org’da ve krita-foundation.tumblr.com’da bir sürü öğretici var, ilki yeni bir özelliğin nasıl kullanılacağını açıklamaya odaklanıyor ve daha sonra kullanıcı öz isteğiyle teşvik ediliyor.

SSS

Bu zaten çevrimiçi ve sahip olduğumuz farklı SSS’lerin birleşmesi. Şu anda çevriliyor ve bunu güncellenecek birincil metin olarak tutmayı umuyoruz.

İlk kez gelenler için¶

Mediawiki’nin aksine, Sphinx, bizim Krita’ya yazdığımız kodlara benzer bir biçimde çalışıyor.

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.

Sphinx, reStructuredText imlemesi ile basit metin dosyaları yazarak çalışır ve ardından bu metin dosyalarını alır ve bunları kılavuza dönüştürür. Kılavuzdaki değişiklikleri Git adlı bir sürüm denetim sistemine koyarak takip ediyoruz.

Değişiklikler yapmak¶

Git’i kullandığımız için sürüm denetim sistemine bir şeyler koyabilecek yalnızca birkaç kişi var, bu nedenle değişiklik yapmak istiyorsanız incelemeye koymanız gerekecek.

Düzenleme kipini kullanarak birleştirme istekleri oluşturmak¶

Not

Bu yöntem, yalnızca KDE depolarına itme erişiminiz yoksa uygundur. Aksi takdirde, var olan yönergelere aykırı olarak, değişikliklerinizi doğrudan depoya kaydeder.

Teknik bilgisi olmayan kullanıcılar için önerilir.

Aynı anda birden fazla dosyayı değiştirmek istediğinizde önerilmez. (Daha fazla dosya değiştirmek veya birleştirme isteği başına yalnızca bir tane düzenlemek istiyorsanız WebIDE kullanarak birleştirme istekleri oluşturmak veya :ref:`merge-request-terminal`e bakın).

Katkıda bulunmak istediğiniz birçok değişiklik varsa aşağıdaki yönergeleri izlemeniz önerilir.

Bir KDE kimliği alın.
KDE_gitlab. sayfasına oturum açın.
Depoya gidin ve Fork düğmesine basın.
Artık çatalladığınız depoya yönlendirileceksiniz. Genelde, invent.kde.org/KDE_OTURUM_AÇMA_ADINIZ/docs-krita-org konumunda olur.
Resmi depoya geri gelin. Kendi çatalınız değil de, Documentation > Krita.org Documentation sayfasını görüntülediğinizden emin olun. Aksi takdirde bu yöntem düzgün çalışmaz.

Gitlab’ın dosyaları kendi içinde düzenlemenize izin veren bir ‘Edit’ işlevi vardır. Buna erişmek için Repository ‣ Files konumuna gidin.

Sayfanın en tepesinde seçili öge olarak master’ı gösteren bir açılır menü görmelisiniz.

Düzenlemek istediğiniz dosyayı bulun, onu açın ve Edit düğmesine tıklayın.

Değişikliklerinizi yapın. (Not: Bu kipte bir kerede yalnızca bir dosyayı düzenleyebilirsiniz).

Aşağıdaki küçük metin kutusuna gidin ve yaptığınız değişiklikleri anlatan güzel bir işleme iletisi yazın. Bittiğinde, Commit changes düğmesine tıklayın. Bu, sizin yerinize bir birleştirme isteği açacaktır, tüm alanları şurada açıklandığı gibi doldurun: Yeni birleştirme istekleri için yönergeler.

Bu yöntemin dezavantajı, metin biçimlendirmesini yaparken bir hata yapıp yapmadığınızı anlamanın bir yolu olmamasıdır. Lütfen değişikliklerinizi Çevrimiçi Sphinx Düzenleyicisi ile denetleyin (düzenlediğiniz dosyanın tümünü kopyalayıp yapıştırın).

Dikkat

Edit ve WebIDE farklı iki araçtır! Edit’i seçtiğinizden emin olun.

WebIDE kullanarak birleştirme istekleri oluşturmak¶

Git hakkında biraz bilgisi olan ve aynı anda birkaç dosyayı düzenlemek isteyen kullanıcılar için önerilir.

Dal sözcüğünün bu bağlamdaki anlamını bilmiyorsanız önerilmez (bunun yerine Düzenleme kipini kullanarak birleştirme istekleri oluşturmak bölümüne bakın).

KDE_gitlab sayfasına oturum açmak ve kendi çatalınızı oluşturmak için yukarıdaki yönergeleri izleyin.
Çatalınıza gidin (URL’nin kullanıcı adınızı içerdiğinden emin olun).
master dalında olduğunuzdan emin olun.
WebIDE düğmesine tıklayın. Bu, sizi solda bir dosya listesi ve sağda dosya içeriği için büyük bir boş alan olan bir sayfaya yönlendirmelidir.
Düzenlemek istediğiniz dosyaları açın ve değişiklikleri yapın.
Commit… düğmesine tıklayın. Unstaged changes kategorisindeki tüm dosyaları Staged changes kategorisine taşımak için tüm dosyaların üzerine sağ tıklayın.
Commit… düğmesine yeniden tıklayın - bu, bir işleme iletisi girebileceğiniz bir metin kutusunu genişletir. Yaptığınız değişiklileri ve onları neden yaptığınızı anlatan bir işleme iletisi yazın.
Tüm ayarların doğru olduğundan emin olun: Create a new branch ögesini seçmelisiniz (dalın adı [kullanıcıadı]/[değişikliklerinizin çok kısa bir özeti] olmalıdır). Değişikliklerinizi bitirdiyseniz Start a new merge request seçeneğinin imli olduğundan emin olun. Aksi takdirde daha sonra elle bir tane oluşturmanız gerekecektir.
Stage & Commit seçeneğine tıklayın.
Tüm alanları düzgünce doldurun; bkz. Yeni birleştirme istekleri için yönergeler.
Elle yeni bir birleştirme isteği oluşturmak için Krita Kılavuzu resmi deposuna gidin (URL’nin sizin kullanıcı adınızı içermediğinden emin olun) ve Create a new merge request seçeneğine tıklayın (soldaki açık yeşil düğme). Çatalınızı seçin ve WebIDE içinde oluşturduğunuz dalı seçin.

Not

Resmi depoya itme erişiminiz yoksa Gitlab değişikliklerinizi doğrudan resmi depoya yazmanıza izin vermez (ve Create a merge request de yardımcı olamaz, değişikliklerinizi her halükarda işlemeniz gerekiyor; itme erişiminiz yoksa bunu yapamazsınız). Yalnızca şu iletiyi gösterir: An error occurred whilst committing your changes. Please try again.

Bu durumda, değiştirdiğiniz tüm dosyaların içeriğini kopyalayın, çatalınıza gidin ve onları çatalınızda açacağınız WebIDE içinde yapıştırın.

Komut satırı kullanarak birleştirme istekleri oluşturma¶

Git işleyişini ve komut satırını kullanmayı bilen kullanıcılar için önerilir.

Dal sözcüğünün bu bağlamdaki anlamını bilmiyorsanız önerilmez (bunun yerine Düzenleme kipini kullanarak birleştirme istekleri oluşturmak bölümüne bakın).

KDE_gitlab sayfasına oturum açmak ve kendi çatalınızı oluşturmak için yukarıdaki yönergeleri izleyin.
Depoyu, git clone kullanarak yerelde klonlayın. Depo sayfasında git clone yapabileceğiniz URL’ler vardır ve sonrasında onları kendi çatalınıza itebilirsiniz. Bunun avantajı, bu metin dosyalarını bilgisayarınızdaki araçları kullanarak düzenleyebilme ve hataları denetlemek için yerel olarak yapabilme desteğidir. (Bu adımı yalnızca bir kez yapmanız gerekir).
# SSH erişimi için git clone git@invent.kde.org:<username>/docs-krita-org.git git remote add upstream git@invent.kde.org:documentation/docs-krita-org.git # HTTPS erişimi için git clone https://invent.kde.org/<username>/docs-krita-org.git git remote add upstream https://invent.kde.org/documentation/docs-krita-org.git
Yeni değişiklikler yapmadan önce her zaman resmi depodaki değişiklikleri çekmeyi unutmayın:
git pull upstream master
Değişiklikleriniz için yeni bir dal oluşturmayı unutmayın, 2019 Eylül’ünden bu yana tüm değişiklikler master üzerinden dallanmalıdır.
git checkout master # sonrasında: git checkout -b "<kullanıcıadı>/<yeni-özelliğin-açıklaması>"

Değişikliklerinizi yaptıktan sonra onları işleyin ve çatalınıza itin. Bu iş akışı ile Git kullanımının ayrıntılı bir açıklaması için Forking on Gitlab bölümüne gidin.

# Sisteminiz için olan python3-sphinx paketini kurun. Ubuntu için:
sudo apt install python3-sphinx
# Kılavuzu yapın (olası hataları bildirir, değişiklikleri tarayıcı içinde denetlemenize izin verir):
make html
# Her şeyin doğru olduğundan emin olun:
git status
git diff
# Tüm dosyaları ekleyin:
git add .
# Değişikliklerinizi işleyin:
git commit
# Değişikliklerinizi çatalınıza gönderin:
git push

Son olarak, özgün deponun web sayfasına ve sonrasında Merge Requests’e gidin. Çatalınızı ve doğru dalı seçin ve yeni bir birleştirme isteği oluşturun. Alanları doldurma konusunda yönergeler için Yeni birleştirme istekleri için yönergeler bölümüne bakın.

Yeni birleştirme istekleri için yönergeler¶

İşleme iletileriniz bu standarda uymalıdır: Nasıl bir Git İşleme İletisi Yazılır
Title ve Description alanları, yaptığınız tüm değişiklikleri ve onları neden yaptığınızı içermelidir (işleme iletisi gibi), bundan dolayı yukarıdaki yönergeleri burada da izleyebilirsiniz.
Target, master’a işaret etmelidir.
Birleştirme isteğinize sonradan değişiklikler yapacağınızdan eminseniz isteğin başlığını [WIP] ile başlatın.
Allow commits from members who can merge to the target branch. seçeneğini imlediğinizden emin olun – birleştirme isteğinin, birleştirme isteğini teknik olarak değiştiren; ancak gerçek içeriğini değiştirmeyen, master’a yeniden temellendirilmesi teknik nedenlerden dolayı genellikle gereklidir.
Çoğu durumda Delete source branch when merge request is accepted seçeneğini güvenlice imleyebilirsiniz.
Denetmenler başka türlü söylemediği sürece Squash commits when merge request is accepted seçeneğini imleyin. İşleme iletisinin ilk satırı, birleştirme isteğinizin Title kısmından ve geri kalanı da Description kısmından alınır.
Birleştirme isteğinizi tamamladığınızda IRC’ye gidin (bkz. IRC) ve itme erişimine iye birisinden birleştirme isteğinize Needs Review etiketini eklemesini söyleyin.
Birleştirme isteğinizde yanlışlar varsa bununla ilgili geri bildirim alabilirsiniz. Dalınızdaki yanlışları aşağıdaki yollardan biriyle düzeltin.
- Edit kipini kullanmak istiyorsanız birleştirme isteğinizin Changes bölümüne gidin ve kurşun kalem simgesine tıklayın (Edit yazan bir araç ipucu vardır).
- WebIDE kipini kullanmak istiyorsanız çatalınıza gidin, değişikliklerinizin olduğu dalı seçin ve WebIDE’ye tıklayın.
- Dosyalarını bilgisayarınızda düzenliyor ve uçbirimle çalışıyorsanız doğru dalda olduğunuzdan emin olun ve değişikliklerinizi itin - Gitlab, birleştirme isteğinizi kendiliğinden güncelleyecektir.
Değişiklikleri yaptıktan sonra başka birisinden etiketi Needs Review olarak değiştirmesini istemeyi unutmayın.

Daha ayrıntılı bilgi için teknik bölümdeki Forking on Gitlab kısmına bakın.

Not

Bu kılavuzun yazıldığı zaman itibarıyla, birleştirme isteklerindeki etiketleri ayarlama yalnızca resmi depoya yazma erişimi olan katkıcılar tarafından yapılabilmektedir (Bunun ne demek olduğunu bilmiyorsanız büyük olasılıkla onlardan biri değilsinizdir). Bundan dolayı, birleştirme isteğinizi oluşturduktan veya değiştirdikten sonra IRC’ye gidip (bkz. Krita Topluluğu) bunu sizin yerinize yapmalarını istemeniz gereklidir.

Kılavuzu komut satırında yapmak¶

Bir birleştirme isteğine binmeden önce değişikliklerinizi denemek isteyenler (halihazırda Git ve komut satırı kullanımını bilenlere) için bu, 5. adımın Komut satırı kullanarak birleştirme istekleri oluşturma bölümünde açıklanmıştır.

Genel felsefe¶

Bu, uygun yazı biçeminin ne olduğunu belirlemek içindir. İster pratik ister estetik niteliklerini göz önünde bulunduralım, bir yazı biçemi genellikle bir amaç veya genel bir felsefe tarafından desteklenir. Kılavuzla neyi başarmak istiyoruz ve bu kılavuz kimin içindir?

Demografi ve hedef kitle(ler)¶

Tüm Krita kullanıcılarının 55 yaşında erkekler olduğunu varsaydığımız bir demografiden söz edemeyiz. Krita çok farklı sayıda insan tarafından kullanılıyor ve aslında bu kadar çeşitli bir kullanıcı tabanımız olduğu için gurur duyuyoruz.

Buna rağmen, kullanıcılarımız hakkında birkaç şey biliyoruz:

Onlar sanatçıdır. Bu, açıkça hedeflediğimiz kullanıcı türüdür.
- Bu nedenle güzel resimleri tercih ettiklerini biliyoruz.
- Onlar görseldir.
- Güzel resimler elde etmeye çalışıyorlar.

Bu nedenle, her sayfanın örtük amacı, özelliğin güzel resimler için kullanılmasını sağlamak olacaktır.

Bunun dışında şu grupları gözlemledik:

İllüstrasyonlar için çizim yazılımı deneyen lise ve üniversite öğrencileri. Bunlar genellikle Paint Tool SAI veya Photoshop gibi çizim yazılımlarıyla önceden deneyime sahiptir; ancak Krita içindeki olanaklarla tanıştırılmaları gerekir. Bu grubun gücü; ipuçları, püf noktaları ve öğreticiler gibi birçok bilgiyi birbirleriyle paylaşmalarındadır.
Profesyoneller, parasını sayısal çizim yazılımı ile kazanan insanlar. Bu grubun gücü, pek çok bilgi birikimine sahip olmaları ve programı geliştirmek için bağış yapmaya istekli olmalarıdır. Bunlar iki türdendir:
- Teknik olmayan profesyoneller. Bunlar, bir yazılımın daha matematiksel parçalarını gerçekten kavramayan; ancak yıllar içinde sağlam iş akışları geliştirmiş ve hassas içgüdülerini kullanarak yazılımla çalışan kişilerdir. Bunlar genellikle çizerler, ressamlar ve baskı ile çalışan kişilerdir.
- Teknik uzmanlar. Bunlar Krita’yı bir ardışık düzenin parçası olarak kullanan ve kesin matematik ve piksel itmeyle ilgilenen kişilerdir. Bunlar genellikle oyunlarda ve VFX endüstrisinde çalışan kişilerdir; arada sırada bir bilim adamı da bu gruba girer.
Yetişkin ve yaşlı meraklılar. Bu grup bilgisayarlar hakkında pek bir şey bilmezler ve her zaman bir öğreticiden eksik olan o küçük adıma takılıp kalırlar. Grup olarak güçleri, iş akışlarında bir öğrencinin aklına gelemeyecek veya bir profesyonelin kullanmak için vakti olamayacak alışılmışın dışında yöntemler kullanmalarıdır. Bunun yanı sıra, daha geniş topluluktaki ilk grup üzerinde yumuşatıcı bir etkiye sahiplerdir.

Bu dört gruptan…

yalnızca biri tekniktir. Bundan dolayı konsept sayfalarına gereksinimimiz var ki böylece kılavuz sayfalarımızı sağlam bir temel üzerine yazabilelim.
üçünün büyük olasılıkla yazılımlarla deneyimi var ve bir göç kılavuzuna ve bunu nasıl yapmaları gerektiğinin onlara anlatılması gerekiyor.
ikisinin Krita’yı başka yazılımlarla işbirliği içinde kullanabilmeleri için yardıma gereksinimleri var.
ikisinin ne yaptıkları hakkında en ufak bir fikri yok ve en temel adımların onlara anlatılması gerekiyor.

Bunlardan aşağıdaki kuralları çıkarabiliriz:

Genel Yazım¶

Olanaklıysa Amerikan İngilizcesi kullanın.: Krita’nın öntanımlı arayüzünün Amerikan İngilizcesinde olmasından dolayı kılavuzda da Amerikan İngilizcesi kullanıyoruz.
Dili kibar tutun; ancak akademik bir dil kullanmayın.: Topluluk olarak, kullanıcılara sıcak davranmak istiyoruz, bu nedenle istenmeyen dilden kaçınmaya çalışıyoruz. Sövgüye zaten KDE tarafından göz yumulmuyor; ancak ne yazarın ne de okuyucunun anladığı akademik bir tarz kullanımı da hiç gerekli değil. Bu, metnin gerekenden çok daha karmaşık olduğu izlenimini verebilir ve bu nedenle kullanıcıları korkutabilir.
GIF kullanımından kaçının (tartışmaya açık): Bunun nedeni, epilepsi hastalarının hızlı hareket eden görsellerden etkilenebilmesidir. Benzer biçimde, GIF’ler bazen çok fazla açıklama yükü taşıyabilir. GIF’leri kullanmaktan kendinizi alamıyorsanız en azından okuyucuyu sayfanın başında bu konuda bilgilendirin.
Çeviri uyumlu tut: Bu, bilgi grafikleri için SVG kullanmaktan ve belirli bir metin için uygun imlemeyi kullanmaktan oluşur.

Fotoğraflar ve tablolar hakkında¶

Kılavuzda, fotoğrafların ve geleneksel tabloların bir konsepti göstermiyorlarsa kullanılmamasını isteriz. Bunun nedeni, Krita’da yapılmış o kadar çok çalışma varken Rembrandt eserlerini Krita arayüzünde göstermek çok aptalcadır ve biraz da sahtekarlıktır. Pepper&Carrot çizimlerinin tümü Krita’da yapılmıştır ve özgün dosyaları vardır, bu nedenle kullanışlı bir görseliniz olmadığında oradan başlayın. Krita bir boyama programı olduğu için fotoğraflardan kaçınılmalıdır. Çok fazla fotoğraf, Krita’nın aslında hiç de odak noktası olmayan fotoğraf rötuşları için bir çözüm olmaya çalıştığı izlenimini verebilir.
Tabii ki, yine de fotoğraflarda ve ana resimlerde, parlatma veya dolaylı ışık gibi belirli kavramları göstermek istiyoruz. Bu durumda, resmin veya ressamın adını içeren veya bunun bir fotoğraf olduğunu belirten bir başlık ekleyin.
Fotoğraflar hala fotoğraf baskısı ve benzerleri için kullanılabilir; ancak yalnızca açıkça fotoğraf baskısı bağlamında kullanılıyorsa.

Genel olarak görsellerle ilgili¶

Görsellerde metin kullanmaktan kaçının ve bunun yerine açıklamayı kullanın. Şekil yönergesi ile bunu yapabilirsiniz.
Metin kullanmanız gerekiyorsa, ya bir SVG yapın, böylece içindeki metin daha kolay işlenebilir ya da metin miktarını en aza indirmeye çalışın.
Görsellerinizi yüksek kaliteli/sevimli yapmaya çalışın. İnsanlara çizim için bir program kullandıkları fikrini verelim!
Kılavuzun GDPL 1.3 kapsamında lisanslandığını unutmayın, bu nedenle gönderilen görseller buna göre lisanslanacaktır. CC-By-Sa/CC-By söz konusu olduğunda, dosyanın bir şekil başlığı aracılığıyla uygun şekilde atfedildiğinden emin olun. Bunu söylemeye gerek olmadığını düşünüyoruz; ancak her iki lisans altında da lisanslanamayan görseller göndermeyin.

Protokol¶

Burada, tüm bu sıkıcı iş akışlarını sıralıyoruz.

künyeleme ve Dallar¶

Metin ekleme ve kaldırma draft dalında yapılır.

Eski sayfalardaki metinleri denetlemek hata düzeltmesi olarak kabul edilir ve master dalına gider; gerektiğinde draft dalına da alınır.

draft dalı, herhangi bir sürüm için birleştirilmeden önce:

master dalı, eski sürümle künyelenir.
draft dalı, güncellenmiş sürüm numarasına ve Epub kapağına sahip olup olmadığı için çifte denetlenir.

draft dalı, sayfaları yeterince bozulmamış tutmak için yayımdan bir gün öncesine kadar birleştirilmez.

Her bir yayım, yayım sürecinin bir parçası olarak ayrı bir Epub sürümü alır. POT dosyaları nereden geliyor? Çevrilmiş sürümler?

Sayfaları Kaldırma¶

Eğer bir özellik, herhangi bir sürümde kaldırılmışsa ilgili sayfalar:

Önce kullanılmıyor olarak imlenir.

Bu şöyle yapılabilir:

.. deprecated:: version number

    Kullanıcının özelliği yok varsayması gerektiğini anlatan metin.

‘deprecated’ adlı bir sayfada bağlantı verilir
Yeni sürüm geldiğinde, kullanılmayan tüm bu sayfalar kaldırılır.

Sayfalar Ekleme¶

Doğru konuma ekleme yaptığınızdan emin olun.
Sayfanın düzgünce biçimlendirildiğinden emin olmak için Krita Kılavuzu için imleme kuralları kurallarını izleyin.
Sayfayı, İçindekiler bölümüne ekleyin.

Özellik yeniyse versionadded:: içine ekleyin:

.. versionadded:: sürüm numarası

    isteğe bağlı bir veya başka bir şey.

Görsellerde olduğu gibi, ekleme izniniz olmayan metinleri eklemeyin. Bu, metnin sizin tarafınızdan yazıldığı veya özgün yazardan aktarma izninizin olduğu anlamına gelir. Kılavuz GDPL 1.3+ olduğundan metin bununla yeniden lisanslanacaktır.

Sayfaları Değiştirme¶

Sayfa hatalarını düzeltmek yerine sayfayı tümden yeniden yazarsanız sayfanın denetlenmesi gerekir.

Bir özellik değiştiği için bir sayfayı değiştirirseniz ve işleme erişiminiz varsa değişiklik inceleme yapılmadan aktarılabilir (incelemeye gerek olmadığını düşünüyorsanız): ancak şunları eklemelisiniz:

.. versionchanged:: sürüm numarası

    Bu ve bu değiştirildi.

Her durumda, kendinizi üstteki üst veri bölümündeki yazar alanına eklemek isteyip istemediğinizi denetleyin.

deprecated, versionadd ve versionchanged’i sürüm numarasıyla birlikte kullanmak, bu terimler için kılavuzda grep ile kolayca arama yapmamızı sağlar:

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

Hatalı Sayfalar¶

Eğer bir sayfa herkesin gözünden kaçmışsa…

Değişiklikler yapmak bölümünü izleyerek bir birleştirme isteği yapın.
Kılavuz Projesi Tahtası’nda bir ‘task’ (görev) oluşturun.
bugzilla’da Krita projesinde ‘documentation’ bölümü altında bir hata kaydı açın.

Düzeltme¶

Yapılması gereken iki tür düzeltme vardır.

En önemlisi, başkalarının yaptığı değişiklikleri incelemektir. Bunu, KDE_gitlab üzerinde iki biçimde yapabilirsiniz:

Birleştirme isteklerini gözden geçirmek

Birleştirme isteklerini incelemeye yardımcı olabilirsiniz. İstek inceleme genellikle programcılar tarafından birbirlerinin kodundaki hataları bulmak için yapılır; ancak programlama kodu tıpkı normal metin gibi metin tabanlı olduğundan, bunu yazım hatalarını denetlemek için de kullanabiliriz!

Birleştirme isteği, makinede okunabilir bir dosyaya konulan bir belgede yapılan (eklenen, çıkarılan) değişiklik miktarıdır. Birisi bir inceleme isteği gönderdiğinde (Gitlab veya Github gibi sistemlerde bu bir birleştirme veya çekme isteğidir), özgün dosyalara bakan kişiler, bunlara bakmak zorunda kalacak ve değiştirilmesi gereken şeyler hakkında yorum yapabileceklerdir. Bu; yazım hataları, aşırı karmaşık yazım ve aynı zamanda yanlış olan şeyler hakkında yorum yapmalarını sağlar. Bir yama kabul edildikten sonra sürüm denetim sistemine aktarılır.
Kılavuzdaki değişiklikler hakkında yorum yapmak.

Değişikliklere yorum yapmak işleme sonrası yapılır. Bir değişikliğe yorum yapmak için işleme iletisine gidin (depo sayfasında geçmişe gidin ve bir girdiye tıklayın). Yorumunuzu buraya ekleyebilirsiniz.

Her iki durumda da arayüz, solda eski sürüm ve sağda yeni sürümle gösterilen farktan oluşur. Eklenen satırlar yeşil renkle işaretlenirken, kaldırılan satırlar kırmızı ile işaretlenir. Bir ‘satır içi’ yorum eklemek için bir konuşma balonu simgesini tıklayabilirsiniz.

Kılavuzun yeniden okunmasının gerekli olduğu ikinci önemli yol, tüm dosyanın üzerinden geçmektir. Sayfaların çoğu yalnızca doğruluk açısından denetlenmiştir; ancak biçem ve dilbilgisi açısından kontrol edilmemiştir.

Bunun için Değişiklikler yapmak bölümünü izlemelisiniz; böylece tüm sayfaya erişiminiz olabilir ve onu düzenleyebilirsiniz.

Çeviri¶

Kılavuzun çevirisi KDE yerelleştirme topluluğu tarafından yapılır. Çeviri girişimine katkıda bulunmak için yerelleştirme sitesine gidin, çeviri takımı listesinden katkıda bulunmak istediğiniz takımı seçin ve diğer çevirmenlerle iletişime geçmek için takım sayfasındaki talimatları izleyin.

KDE yerelleştirmesine dahil olmaya ilişkin daha genel yönergeler için lütfen https://community.kde.org/Get_Involved/translation adresine bakın.

Yerelleştirme takımının, bu kılavuz için, POEdit ve Lokalize gibi çeviri programları tarafından kullanılan bir dosya türü olan PO dosyalarına erişimi vardır. Bir çeviri takımı, bu dosyaları çevirmek ve çevirilerin SVN’ye yüklemek için birlikte çalışabilir. Özel bir betik dosyası daha sonra çevirileri SVN’den alacak ve bunları günlük olarak dahil edilmek üzere kılavuz bölümüne getirecektir.

Çeviri takımı kendi görsellerini sağlamak istiyorsa görseller bu doğrultuda yerelleştirilebilir. Görsel klasöründeki tüm görseller öntanımlı olarak ‘en’ içindir. Belirli bir görseli yerelleştirmek istediğinizde o klasöre gidin ve kendi dil kodunuzu içeren bir alt klasör oluşturup görselleri oraya koyun. Örneğin, Sphinx, /images/Pixels-brushstroke.png dosyasının Türkçe sürümünü /images/tr/Pixels-brushstroke.png konumunda arayacaktır. Başka bir örnek olarak, /images/dockers/Krita-tutorial2-I.1-2.png dosyası için /images/dockers/tr/Krita-tutorial2-I.1-2.png dosyası olmalıdır.

Bitmiş çevirilerin de çevrimiçi görünmesi için yapı komut dosyasına eklenmesi gerekir. Bunun yapılması için, çevirilerinin durumundan emin olan çevirmen takımları, kimageshop posta listesi (kimageshop@kde.org) veya foundation@krita.org aracılığıyla ana Krita takımıyla iletişime geçmelidir.

Diğer¶

Yeniden yapılandırılmış metin kuralları ile ilgili ayrıntılı bilgi için Krita Kılavuzu için imleme kuralları bölümüne bakın.