Sürüm denetimi bütünleştirmesi#
Weblate şu anda Git (gelişmiş destek ile GitHub çekme istekleri, GitLab birleştirme istekleri, Gitea çekme isteği, Gerrit, Subversion ve Bitbucket sunucusu çekme isteği) ve Mercurial sürüm denetimi sistemlerini destekliyor.
Depolara erişmek#
Kullanmak istediğiniz sürüm denetimi deposuna Weblate üzerinden erişilebiliyor olması gerekir. Herkese açık olan bir depoda doğru adresi yazmanız yeterlidir (https://github.com/WeblateOrg/weblate.git gibi). Ancak gizli depolar ya da itme adresleri için kurulum daha karmaşıktır ve kimlik doğrulaması gerekir.
Hosted Weblate üzerinden depolara erişmek#
Hosted Weblate için GitHub, Bitbucket, Codeberg ve GitLab üzerinde kayıtlı özel bir itme kullanıcısı bulunur (kullanıcı adı weblate, e-posta adresi hosted@weblate.org ve adı Weblate push user olan). Bu kullanıcıyı katılımcı olarak eklemeniz ve deponuza uygun izni vermeniz gerekir (kopyalama için salt okunur izni uygundur, itme için yazma izni gereklidir). Hizmete ve kuruluş ayarlarınıza bağlı olarak, bu işlem hemen yapılır ya da Weblate tarafında onay gerekir.
GitHub üzerindeki weblate kullanıcısı davetleri beş dakika içinde kendiliğinden kabul eder. Diğer hizmetlerde işlemi el ile yapmak gerekebilir, bu nedenle lütfen sabırlı olun.
weblate kullanıcısı eklendikten sonra, SSH iletişim kuralını kullanarak Kaynak kod deposu ve Depo itme adresi değerlerini yapılandırabilirsiniz (örneğin git@github.com:WeblateOrg/weblate.git).
SSH depoları#
Gizli depolara erişmek için en sık kullanılan yöntem SSH kullanmaktır. Herkese açık Weblate SSH anahtarını (bilgi almak için: Weblate SSH anahtarı) yukarı akış deposuna bu şekilde erişmesi için yetkilendirin.
Uyarı
GitHub üzerinde her anahtar yalnızca bir kez kullanılabilir. Bilgi almak için: GitHub depoları ve Hosted Weblate üzerinden depolara erişmek.
Weblate ayrıca ilk bağlantıda sunucu anahtarının parmak izini saklar ve daha sonra değişmesi durumunda sunucu ile bağlantı kuramaz (bilgi almak için: SSH sunucu anahtarlarını doğrulamak).
Ayarlama yapılması gerektiğinde, bunu Weblate yönetim arayüzünden yapın:
Weblate SSH anahtarı#
4.17 sürümünde değişti: Weblate artık hem RSA hem de Ed25519 SSH anahtarları üretebiliyor. Yeni kurulumlar için Ed25519 kullanılması önerilir.
Tüm kullanıcılar herkese açık Weblate anahtarını, Hakkında sayfasında görebilir.
Yöneticiler, yönetim arayüzü açılış sayfasında (SSH anahtarları bölümünden) Weblate tarafından bağlantıda kullanılmakta olan herkese açık anahtarı oluşturabilir veya görüntüleyebilir.
Not
İlgili kişisel SSH anahtarının şu anda bir parolası olamaz. Bu nedenle iyi korunduğundan emin olun.
İpucu
Oluşturulan kişisel Weblate SSH anahtarının yedeğini alın.
SSH sunucu anahtarlarını doğrulamak#
Weblate, SSH sunucu anahtarlarını ilk kez eriştiğinde kendiliğinden depolar ve sonraki kullanımlar için hatırlar.
Depoya bağlanmadan önce anahtar parmak izini doğrulamak isterseniz, erişeceğiniz sunucuların SSH sunucu anahtarlarını yönetim arayüzünün aynı bölümünden Sunucu anahtarı ekle ile ekleyin. Erişeceğiniz sunucu adını yazın (gitlab.com gibi) ve Gönder üzerine basın. Parmak izinin eklediğiniz sunucuyla eşleştiğini doğrulayın.
Parmak izli eklenen anahtarlar onay iletisinde görüntülenir:
GitHub depoları#
SSH üzerinden erişilebilir (bilgi almak için: SSH depoları). Ancak birden fazla depoya erişmeniz gerekirse, izin verilen SSH anahtarı kullanımında uyarısı ile bir GitHub sınırlamasıyla karşılaşırsınız (her anahtar yalnızca bir kez kullanılabilir).
İtme işleminin yapılacağı dal ayarlanmamışsa, proje dallanır ve değişiklikler bir daldan itilir. Ayarlanmış ise, değişiklikler yukarı akış deposuna ve seçilen dala itilir.
Daha küçük dağıtımlar için, kişisel erişim belirteci ve GitHub hesabınızla HTTPS kimlik doğrulaması kullanın. Bilgi almak için: Komut satırı kullanımı için erişim belirteci oluşturmak.
Daha büyük kurulumlar için, Weblate için özel bir kullanıcı oluşturmak, Weblate üzerinde oluşturulan genel SSH anahtarını atamak (bilgi almak için: Weblate SSH anahtarı) ve çevirmek istediğiniz tüm depolara erişim izni vermek genellikle daha iyidir. Bu yaklaşım Hosted Weblate için de kullanılır. Bunun için özel bir weblate kullanıcısı vardır.
Ayrıca bakınız
İç Weblate adresleri#
Bir depo kurulumunu, diğer (bağlantılı) bileşenlerde weblate://project/component olarak konumlandırılmasına atıfta bulunarak farklı bileşenler arasında paylaşın. Bu şekilde bağlantılı bileşenler, ana (başvurulan) bileşenin sürüm denetimi sistemi deposu yapılandırmasını kullanır.
Uyarı
Ana bileşenin kaldırılması, bağlantılı bileşenleri de kaldırır.
Weblate, eşleşen bir depo kurulumu olan bir bileşen bulursa, bileşen oluştururken depo adresini kendiliğinden ayarlar. Bileşen yapılandırmasının son adımında bunu değiştirebilirsiniz.
Bunun kullanılma nedenleri:
Sunucuda daha az disk alanı kullanır, depo yalnızca bir kez kaydedilir.
Güncellemelerin daha hızlı yapılmasını sağlar, yalnızca bir depo güncellenir.
Weblate çevirilerinin bulunduğu yalnızca tek bir depo dışa aktarılır (bilgi almak için: Git dışa aktarıcı).
Bazı eklentiler bir depoyu paylaşan birden fazla bileşen üzerinde çalışabilir. Örneğin Git işlemelerini bir araya toplar.
HTTPS depoları#
Korunmuş HTTPS depolarına erişmek için adrese kullanıcı adını ve parolayı ekleyin. Endişelenmeyin, Weblate, adresi kullanıcılara görüntülerken (depo adresinin görülmesine izin verilse bile) bu bilgileri çıkarır.
Örneğin, kimlik doğrulaması eklenmiş GitHub adresi şöyle görünebilir: https://kullanıcı:erişim_kodunuz@github.com/WeblateOrg/weblate.git.
Not
Kullanıcı adınızda ya da parolanızda özel karakterler varsa, bunların URL olarak kodlanması gerekir. Örneğin ``https://kullanıcı%40örnek.com:%24parola%23@bitbucket.org/…’’.
Vekil sunucu kullanmak#
Bir vekil sunucu kullanarak HTTP/HTTPS sürüm denetimi sistemi depolarına erişmeniz gerekiyorsa, sürüm denetimi sistemini bunu kullanacak şekilde yapılandırın.
Bunun için, http_proxy, https_proxy ve all_proxy ortam değişkenlerini kullanın (bilgi almak için: cURL belgeleri) ya da sürüm denetimi sistemi yapılandırmasından dayatın. Örneğin:
git config --global http.proxy http://user:password@proxy.example.com:80
Not
Vekil sunucu yapılandırmasının Weblate çalıştıran kullanıcı ile (ayrıca bilgi almak için: Dosya sistemi izinleri) ve HOME=$DATA_DIR/home (bilgi almak için: DATA_DIR) yolunda yapılması gerekir. Yoksa Weblate tarafından yürütülen Git bunu kullanmaz.
Ayrıca bakınız
Git#
İpucu
Weblate için Git 2.12 ya da daha yeni sürümü gereklidir.
Ayrıca bakınız
Farklı türde depolara nasıl erişileceği ile ilgili bilgi almak için: Depolara erişmek.
Git (itme dayatması ile)#
Bu tam olarak Git gibi davranır. Tek fark her zaman itmenin dayatılmasıdır. Yalnızca çeviriler için ayrı bir depo kullanılması durumunda seçilmesi amaçlanmıştır.
Uyarı
Dikkatli kullanın, çünkü kolayca yukarı akış deponuzda eksik işlemelere yol açar.
Git yapılandırmasını özelleştirmek#
Weblate, tüm sürüm denetimi sistemi komutlarını HOME=$DATA_DIR/home ile çağırır (bilgi almak için DATA_DIR). Bu nedenle kullanıcı yapılandırması DATA_DIR/home/.git içinde düzenlenmelidir.
Git uzak yardımcıları#
Ek olarak diğer sürüm denetim sistemlerini desteklemek için Git remote helpers kullanabilirsiniz. Ancak bunun yol açabileceği sorunları çözmeye hazır olmalısınız.
Şu anda, Bazaar ve Mercurial yardımcıları GitHub üzerindeki ayrı depolarda bulunabilir: git-remote-hg ve git-remote-bzr. Bunları el ile indirin ve arama yolunuzda bir yere koyun (~/bin gibi). İlgili sürüm denetim sistemlerinin kurulmuş olduğundan emin olun.
Kurduktan sonra, bu uzak yardımcılar Weblate üzerinde bir depo belirtmek için kullanılabilir.
Bazaar kullanarak Launchpad üzerindeki gnuselam projesini kopyalamak için:
bzr::lp:gnuhello
Mercurial kullanarak selenic.com üzerindeki selam deposu için:
hg::http://selenic.com/repo/hello
Uyarı
Git uzak yardımcılarını kullanmanın zorluğu, örneğin Mercurial üzerinde, uzak yardımcının değişiklikleri geri iterken yeni bir ipucu oluşturmasıdır.
GitHub çekme istekleri#
Bu yöntem, Git üzerine çeviri değişikliklerini doğrudan depoya itmek yerine GitHub API ile çekme istekleri olarak itmeyi sağlayan ince bir katman ekler.
Git değişiklikleri doğrudan bir depoya iterken, GitHub çekme istekleri çekme istekleri oluşturur. İkincisi, yalnızca Git depolarına erişmek için gerekmez.
Bunun çalışması için Weblate ayarlarında API kimlik doğrulama bilgilerini (GITHUB_CREDENTIALS) yapılandırmanız gerekir. Yapılandırdığınızda, Sürüm denetimi sistemi seçerken GitHub seçeneğini göreceksiniz.
Ayrıca bakınız
GitLab birleştirme istekleri#
Bu yöntem, Git üzerine çeviri değişikliklerini doğrudan depoya itmek yerine, GitLab API ile birleştirme istekleri olarak itmeyi sağlayan ince bir katman ekler.
Git depolarına erişmek için bunu kullanmak gerekmez. Sıradan Git aynı şekilde çalışır. Tek fark bir depoya itme işleminin nasıl yapıldığıdır. Git ile değişiklikler doğrudan depoya itilirken, GitLab birleştirme istekleri birleştirme isteği oluşturur.
Bunun çalışması için Weblate ayarlarından API kimlik doğrulama bilgilerini (GITLAB_CREDENTIALS) yapılandırmanız gerekir. Yapılandırdığınızda sonra, Sürüm denetimi sistemi seçerken GitLab seçeneğini göreceksiniz.
Ayrıca bakınız
Gitea çekme isteği#
4.12 sürümünde geldi.
Bu yöntem, Git üzerine çeviri değişikliklerini doğrudan depoya itmek yerine Gitea API ile çekme istekleri olarak itmeyi sağlayan ince bir katman ekler.
Git depolarına erişmek için bunu kullanmak gerekmez. Sıradan Git aynı şekilde çalışır. Tek fark bir depoya itme işleminin nasıl yapıldığıdır. Git ile değişiklikler doğrudan depoya itilirken, Gitea çekme isteği birleştirme isteği oluşturur.
Bunun çalışması için Weblate ayarlarında API kimlik doğrulama bilgilerini (GITEA_CREDENTIALS) yapılandırmanız gerekir. Yapılandırdığınızda, Sürüm denetimi sistemi seçerken Gitea seçeneğini göreceksiniz.
Ayrıca bakınız
Bitbucket sunucusu çekme isteği#
4.16 sürümünde geldi.
Bu yöntem, Git üzerine çeviri değişikliklerini doğrudan depoya itmek yerine Bitbucket sunucu API ile çekme istekleri olarak itmeyi sağlayan ince bir katman ekler.
Uyarı
Bu yöntemde, Bitbucket Cloud API desteği yoktur.
Git depolarına erişmek için bunu kullanmak gerekmez. Sıradan Git aynı şekilde çalışır. Tek fark bir depoya itme işleminin nasıl yapıldığıdır. Git ile değişiklikler doğrudan depoya itilirken, Bitbucket sunucusu çekme isteği birleştirme isteği oluşturur.
Bunun çalışması için Weblate ayarlarında API kimlik doğrulama bilgilerini (BITBUCKETSERVER_CREDENTIALS) yapılandırmanız gerekir. Yapılandırdığınızda, Sürüm denetimi sistemi seçerken Bitbucket sunucusu seçeneğini göreceksiniz.
Ayrıca bakınız
Weblate üzerindeki değişiklikleri itmek,
BITBUCKETSERVER_CREDENTIALS
Pagure birleştirme istekleri#
4.3.2 sürümünde geldi.
Bu yöntem, Git üzerine çeviri değişikliklerini doğrudan depoya itmek yerine, Pagure API ile birleştirme istekleri olarak itmeyi sağlayan ince bir katman ekler.
Git depolarına erişmek için bunu kullanmak gerekmez. Sıradan Git aynı şekilde çalışır. Tek fark bir depoya itme işleminin nasıl yapıldığıdır. Git ile değişiklikler doğrudan depoya itilirken, Pagure birleştirme istekleri birleştirme isteği oluşturur.
Bunun çalışması için Weblate ayarlarında API kimlik doğrulama bilgilerini (PAGURE_CREDENTIALS) yapılandırmanız gerekir. Yapılandırdığınızda, Sürüm denetimi sistemi seçerken Pagure seçeneğini göreceksiniz.
Ayrıca bakınız
Gerrit#
Bu yöntem git-review aracını kullanarak, Git üzerine çeviri değişikliklerini doğrudan depoya itmek yerine Gerrit onaylama istekleri olarak itmeyi sağlayan ince bir katman ekler.
Gerrit belgelerinde, bu tür depoları kurmak için gerekli yapılandırma bilgilerini bulabilirsiniz.
Mercurial#
Mercurial, doğrudan Weblate içinden kullanabileceğiniz başka bir sürüm denetimi sistemidir.
Not
Herhangi bir Mercurial sürümüyle çalışmalıdır. Ancak bazen komut satırı arayüzünde Weblate bütünleştirmesini bozan uyumsuz değişiklikler olabilir.
Ayrıca bakınız
Farklı türde depolara nasıl erişileceği ile ilgili bilgi almak için: Depolara erişmek.
Subversion#
Weblate, subversion depolarıyla etkileşim kurmak için git-svn kullanır. Subversion depolarının bir Git istemcisi tarafından kullanılması ve kullanıcıların iç deponun tam bir kopyasını alarak yerelde işleme yapabilmesi bir Perl betiği tarafından sağlanır.
Not
Weblate, Subversion depo düzenini kendiliğinden algılamayı dener. Hem dal için doğrudan adresleri hem de standart düzendeki depoları (branches/ , tags/ ve trunk/) destekler. Bu konuda bilgi almak için git-svn belgeleri bölümüne bakabilirsiniz. Deponuzun düzeni standart değilse ve hatalarla karşılaşırsanız, dal adını depo adresine eklemeyi ve dalı boş bırakmayı deneyin.
Subversion kimlik doğrulama bilgileri#
Weblate, sertifikayı (ve gerekirse kimlik doğrulama bilgilerinizi) önceden onaylamış olmanızı bekler. Bunları DATA_DIR klasörüne eklemeye çalışır. $HOME ortam değişkeninin DATA_DIR olarak ayarlanmış olduğunu denetleyin ve svn kullanarak sertifikayı onaylayın:
# Use DATA_DIR as configured in Weblate settings.py, it is /app/data in the Docker
HOME=${DATA_DIR}/home svn co https://svn.example.com/example
Ayrıca bakınız
Yerel dosyalar#
İpucu
Bunun altında Git kullanılır. Git kurulu olmalıdır. Tüm geçmişleriyle birlikte çevirileriniz için doğal biçimde Git kullanmaya geçmenizi sağlar.
Weblate, uzak sürüm denetimi sistemi olmadan da çalışabilir. İlk çeviriler yüklenerek içe aktarılır. Daha sonra tek tek dosyalar dosya yükleme ile değiştirebilir ya da doğrudan Weblate üzerinden çeviri dizgeleri eklenebilir (şu anda yalnızca tek dilli çeviriler için kullanılabilir).
Arka planda Weblate sizin için bir Git deposu oluşturur ve tüm değişiklikler izlenir. Daha sonra çevirileri depolamak için bir sürüm denetimi sistemi kullanmaya karar verirseniz, Bütünleştirmenizde kullanabileceğiniz deponuz Weblate içinde hazır olur.