Sürüm denetimi bütünleştirmesi¶
Weblate currently supports Git (with extended support for GitHub çekme istekleri, GitLab birleştirme istekleri, Gitea çekme isteği, Gerrit, Subversion, Bitbucket Cloud pull requests, Bitbucket sunucusu çekme isteği, and Azure DevOps sunucusu çekme isteği) and Mercurial as version control back-ends.
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¶
Barındırılan Weblate için GitHub, Bitbucket, Codeberg ve GitLab üzerinde kayıtlı özel bir itme kullanıcısı vardır (kullanıcı adı weblate, e-posta adresi hosted@weblate.org ve ad veya profil açıklaması Weblate itme kullanıcısı).
İpucu
Diğer Weblate kopyaları için belirlenmiş platformlarda daha fazla Weblate kullanıcısı olabilir. Doğru barındırılan Weblate kullanıcısını bulmak için hosted@weblate.org e-posta adresiyle arama yapmanız önerilir.
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 verilmesi 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.
Deponuza weblate kullanıcısı eklendikten sonra, SSH iletişim kuralını kullanarak Kaynak kod deposu ve Depo itme adresi yapılandırmasını yapabilirsiniz (örneğin git@github.com:WeblateOrg/weblate.git).
Kod barındırma sitelerindeki depolara erişmek (GitHub, GitLab, Bitbucket, Azure DevOps, …)¶
Kod barındırma sitelerindeki depolara erişim genellikle Weblate SSH anahtarıyla ilişkilendirilmiş özel bir kullanıcı oluşturularak yapılır (Ayrıntılı bilgi almak için: Weblate SSH anahtarı). Bu şekilde, Weblate SSH anahtarını tek bir kullanıcıyla ilişkilendirirsiniz (bu uygulama platform tarafından sıklıkla yapılır) ve bu kullanıcıya depoya erişim izni verirsiniz. Daha sonra depoya erişmek için SSH adresini kullanabilirsiniz (Ayrıntılı bilgi almak için: SSH depoları).
İpucu
Hosted Weblate üzerinde bu yapılandırma, herkese açık sitelerin çoğu için önceden hazırlanmıştır. Ayrıntılı bilgi almak için: Hosted Weblate üzerinden depolara erişmek.
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ı (ayrıntılı 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. Ayrıntılı 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 (ayrıntılı 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:
Eski SSH sunucuları ile bağlantı kurmak¶
Son OpenSSH sürümlerinde (örneğin, Weblate Docker kapsayıcısında kullanılan), varsayılan olarak SHA-1 karma algoritmasını kullanılır ve RSA imzaları kullanılmaz. Bu değişiklik, SHA-1 karma algoritmasının şifreleme açısından bozuk olması ve 50.000 USD altındaki maliyetlerle seçilen ön ek karma çarpışmalarının oluşturulabilmesi nedeniyle yapılmıştır.
Çoğu kullanıcı için bu değişiklik görünmezdir ve ssh-rsa anahtarlarını değiştirmek gerekmez. OpenSSH, 7.2 sürümünden bu yana RFC8332 RSA/SHA-256/512 imzalarını destekliyor ve var olan ssh-rsa anahtarları, olabildiğince kendiliğinden daha güçlü algoritmayı kullanır.
Yükseltilmemiş ya da SSH iletişim kuralındaki iyileştirmeleri yakından izlemeyen eski SSH uygulamaları ile bağlantı kurarken uyumsuzluk yaşanması olasılığı daha yüksektir. Bu tür bir sunucu ile kurulacak SSH bağlantısı şu durumlarda başarısız olacaktır:
no matching host key type found. Their offer: ssh-rsa
Bu durumlarda, HostkeyAlgorithms ve PubkeyAcceptedAlgorithms seçenekleri ile bağlantıya ve/veya kullanıcı kimlik doğrulamasına izin vermek için özellikle RSA/SHA1 seçeneğinin yeniden etkinleştirilmesi gerekebilir. Örneğin, DATA_DIR/ssh/config dosyasındaki aşağıdaki bölüm, tek bir hedef sunucu için sunucu ve kullanıcı kimlik doğrulaması için RSA/SHA1 seçeneğini etkinleştirir:
Host legacy-host
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
Eski uygulamalar yükseltilene veya başka bir anahtar türüyle (ECDSA veya Ed25519 gibi) yeniden yapılandırılana kadar RSA/SHA1 seçeneğini yalnızca geçici bir önlem olarak etkinleştirmenizi öneririz.
GitHub depoları¶
SSH üzerinden erişilebilir (ayrıntılı 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. Ayrıntılı 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 (ayrıntılı 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¶
Share one repository setup between different components by referring to its
placement as weblate://project/component in other (linked) components. This
way linked components use the VCS repository configuration of the
main (referenced) component.
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 (ayrıntılı 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 (ayrıntılı 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 (ayrıntılı 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 (ayrıntılı 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¶
Added in version 4.12.
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¶
Added in version 4.16.
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
Bitbucket Cloud pull requests¶
Added in version 5.8.
This just adds a thin layer atop Git using the Bitbucket Cloud API to allow pushing translation changes as pull requests instead of pushing directly to the repository.
Uyarı
This is different from Bitbucket Server API.
There is no need to use this to access Git repositories, ordinary Git works the same, the only difference is how pushing to a repository is handled. With Git changes are pushed directly to the repository, while Bitbucket Cloud pull requests creates pull request.
You need to configure API credentials (BITBUCKETCLOUD_CREDENTIALS) in the
Weblate settings to make this work. Once configured, you will see a
Bitbucket Cloud option when selecting Sürüm denetimi sistemi.
Ayrıca bakınız
Weblate üzerindeki değişiklikleri itmek,
BITBUCKETCLOUD_CREDENTIALS
Pagure birleştirme istekleri¶
Added in version 4.3.2.
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.
Azure DevOps sunucusu çekme isteği¶
Bu yöntem, Git üzerine çeviri değişikliklerini doğrudan depoya itmek yerine Azure DevOps API ile çekme istekleri olarak itmeyi sağlayan ince bir katman ekler.
Git değişiklikleri doğrudan bir depoya iterken, Azure DevOps sunucusu çekme isteği ç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 (AZURE_DEVOPS_CREDENTIALS) yapılandırmanız gerekir. Yapılandırdığınızda, Sürüm denetimi sistemi seçerken Azure DevOps seçeneğini göreceksiniz.
Ayrıca bakınız
Weblate üzerindeki değişiklikleri itmek,
AZURE_DEVOPS_CREDENTIALS
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 yerleşimini 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 ayrıntılı bilgi almak için git-svn belgeleri bölümüne bakabilirsiniz. Deponuzun yerleşimi 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.