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, Bitbucket Cloud sunucusu çekme isteği, Bitbucket Data Center çekme istekleri ve Azure DevOps 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¶
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.
Özel barındırılan Weblate için, kod barındırma sitelerindeki depolara erişmek genellikle bir Weblate SSH anahtarıyla ilişkili bir özel 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 (platformlar genellikle bir SSH anahtarının bir kez kullanılmasını zorunlu kılar) 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ı).
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ı¶
Weblate ile GitHub depolarına erişmek için iki ana yaklaşım vardır:
1. seçenek: Kişisel erişim kodu ile HTTPS (başlamak için daha basit)
HTTPS kimlik doğrulamasını bir kişisel erişim kodu ve GitHub hesabınızla kullanın. Bu hem salt okunur erişim (çoğaltma) hem de okuma-yazma erişimi (değişiklikleri itme veya çekme istekleri oluşturma) için çalışır.
Bu yaklaşımı kullanmak için:
Komut satırı kullanımı için bir erişim kodu oluşturmak bölümünde açıklandığı gibi bir kişisel erişim kodu oluşturun.
Kodu depo adresinize ekleyin:
https://kullaniciadi:kod@github.com/sahip/depo.git
Bu seçenek, Weblate ile başlarken veya tek bir depoyla çalışırken uygundur.
2. seçenek: Özel Kullanıcı ile SSH (birden fazla depo için önerilir)
Birden fazla deposu olan kurulumlarda Weblate için bir özel kullanıcı oluşturulması önerilir. Böylece, GitHub tarafından her SSH anahtarının platform başına yalnızca bir kez kullanılabileceği sınırlama önlenir.
Bu yaklaşımı kullanmak için:
Bir özel GitHub kullanıcısı hesabı oluşturun (örneğin,
weblate-bot)Weblate herkese açık SSH anahtarını bu kullanıcıya ekleyin (ayrıntılı bilgi almak için: Weblate SSH anahtarı)
Bu kullanıcıya, çevirmesini istediğiniz tüm depolara erişme izni verin
Depolarınız için SSH adresleri kullanın:
git@github.com:sahip/depo.git
Bu yaklaşım, bu amaç için bir özel weblate kullanıcısı olan Hosted Weblate için de kullanılır.
Not
Çekme istekleri için GitHub çekme istekleri kullanılırken, İtme işleminin yapılacağı dal yapılandırması davranışı etkiler: Ayarlanmadığında, proje dallandırılır ve değişiklikler bir daldan geçirilir. Ayarlandığında, değişiklikler yukarı akış deposuna ve seçilmiş dala itilir.
GitLab 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ı uyarısı ile bir GitLab 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.
Kişisel veya proje erişim kodları da kullanılabilir. Kod, değişiklikleri depoya gönderebilmek için write_repository kapsamına gerek duyar. Proje erişimi kodunda, itme için Developer rolü gerekir.
Adreste bir kullanıcı adının bulunması gerekir. Kişisel erişim kodu için gerçek kullanıcı adıdır (https://kullanici:kisisel_erisim_kodu@gitlab.com/ornek/ornek.git) proje erişim kodları için boş olmayan bir değer olabilir (https://ornek:proje_erisimi_kodu@gitlab.com/ornek/ornek.git).
Not
Proje erişimi kodlarını kullanma kuralları GitLab sürümleri arasında değişti. Şu anda değerin boş olmaması zorunlu. Ancak eski sürümlerin farklı beklentileri vardı (proje adı, bot kullanıcı adı). Emin değilseniz sürümünüze uygun GitLab belgelerine bakın.
İç 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¶
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 Data Center çekme istekleri¶
Added in version 4.16.
Bu yöntem, Git üzerine çeviri değişikliklerini doğrudan depoya itmek yerine Bitbucket Data Center 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 Data Center çekme istekleri 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 Data Center seçeneğini göreceksiniz.
Bitbucket Cloud sunucusu çekme isteği¶
Added in version 5.8.
Bu yöntem, Git üzerine çeviri değişikliklerini doğrudan depoya itmek yerine Bitbucket Cloud API ile çekme istekleri olarak itmeyi sağlayan ince bir katman ekler.
Uyarı
Bu, Bitbucket Data Center API uygulamasından farklıdır.
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 Cloud sunucusu çekme isteği birleştirme isteği oluşturur.
Bunun çalışması için Weblate ayarlarında API kimlik doğrulama bilgilerini (BITBUCKETCLOUD_CREDENTIALS) yapılandırmanız gerekir. Yapılandırdığınızda, Sürüm denetimi sistemi seçerken Bitbucket Cloud seçeneğini göreceksiniz.
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.
The optional İtme işleminin yapılacağı dal setting selects the target branch for
the Gerrit review. Leave it empty to use Depo dalı. Use the short
branch name, such as main; Weblate and git-review push the review to
refs/for/<branch> automatically.
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
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.