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 review requests, Subversion, Bitbucket Cloud sunucusu çekme isteği, Bitbucket Data Center çekme istekleri, and Azure DevOps sunucusu çekme isteği) and Mercurial as version control back-ends.
For provider-specific setup steps that combine repository access, incoming notifications, and pushing translations back, see Code hosting integrations.
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¶
Not
Bu bölüm yalnızca Hosted Weblate (hosted.weblate.org) için geçerlidir. Özel barındırılan Weblate kopyanızı işletiyorsanız, lütfen bunun yerine sonraki bölüme bakın.
Hosted 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 hosted@weblate.org ve bir 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 üzerinde, Hosted Weblate GitHub uygulamasını kullandığınızda bile, Hosted Weblate weblate kullanıcısını yazma erişimine eklemeniz veya davet etmeniz gerekir. Uygulama GitHub üzerinden gelen bildirimleri işler, ancak değişiklikleri geri itme işleminde hala Hosted Weblate weblate kullanıcısı kullanılır.
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ı ayarlayabilirsiniz (örneğin git@github.com:WeblateOrg/weblate.git).
Kod barındırma sitelerindeki depolara erişmek (GitHub, GitLab, Bitbucket, Azure DevOps, …)¶
Not
Bu bölüm özel barındırılan Weblate kopyaları için geçerlidir. Hosted Weblate (hosted.weblate.org) kullanıyorsanız, bunun yerine Hosted Weblate üzerinden depolara erişmek bölümüne bakın.
For self-hosted Weblate, accessing repositories on code hosting sites is typically done by creating a dedicated user who is associated with a Weblate SSH key (see Weblate SSH anahtarı). This way you associate Weblate SSH key with a single user (platforms frequently enforce single use of an SSH key) and grant this user access to the repository. You can then use SSH URL to access the repository (see SSH depoları).
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ı
On GitHub, each key can only be used once, see GitHub repository access and 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ı¶
Detailed GitHub repository access is covered in GitHub repository access.
GitLab depoları¶
Detailed GitLab repository access is covered in GitLab repository access.
İç Weblate adresleri¶
Bir depo kurulumunu, diğer (ilişkili) bileşenlerde weblate://project/component olarak konumlandırılmasına referans vererek farklı bileşenler arasında paylaşın. Bu şekilde ilişkili bileşenler, asıl (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 (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ı¶
Ayrıca bakınız
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.
Adres içinde kimlik doğrulama bilgilerini vermemeniz ve depo için bunun gerekmesi durumunda, Git bir hata bildirerek çalışmaz:
fatal: could not read Username for 'https://github.com': terminal prompts disabled
5.10.2 sürümünde değişti: HTTP kimlik bilgileri verildiğinde Git 2.46.0 ve daha yeni sürümlerde proaktif kimlik doğrulaması yapılması sağlandı.
Bu Azure DevOps depolarına erişmeyi sağlar ve kimliği doğrulanmış depolara erişimi hızlandırır.
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.28 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.
GitHub çekme istekleri¶
Detailed GitHub pull request setup is covered in GitHub çekme istekleri.
GitLab birleştirme istekleri¶
Detailed GitLab merge request setup is covered in GitLab birleştirme istekleri.
Gitea çekme isteği¶
Detailed Gitea pull request setup is covered in Gitea çekme isteği.
Bitbucket Data Center çekme istekleri¶
Detailed Bitbucket Data Center pull request setup is covered in Bitbucket Data Center çekme istekleri.
Bitbucket Cloud sunucusu çekme isteği¶
Detailed Bitbucket Cloud pull request setup is covered in Bitbucket Cloud sunucusu çekme isteği.
Pagure birleştirme istekleri¶
Detailed Pagure merge request setup is covered in Pagure birleştirme istekleri.
Gerrit¶
Detailed Gerrit review request setup is covered in Gerrit review requests.
Azure DevOps sunucusu çekme isteği¶
Detailed Azure DevOps pull request setup is covered in Azure DevOps sunucusu çekme isteği.
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.