Sürekli yerelleştirme¶

Çevirinizin gelişimi yakından izleyen hazır bir altyapı vardır. Böylece çevirmenler, yayın öncesinde büyük miktarda yeni metinler üzerinde çalışmak yerine, tüm zaman boyunca çeviriler üzerinde çalışabilirler.

Ayrıca bakınız

Weblate ile bütünleştirmek geliştirme çalışmalarınızı Weblate ile bütünleştirmenin temel yollarını açıklar.

Süreç şu şekildedir:

Geliştiriciler değişiklikler yapar ve bunları sürüm denetimi sistemi deposuna iter.
İsteğe bağlı olarak çeviri dosyaları güncellenir. Ayrıntılı bilgi almak için: Yeni dizgeler sunmak.
Weblate, sürüm denetimi sistemi deposundan değişiklikleri çeker, çeviri dosyalarını işler ve veri tabanını günceller. Ayrıntılı bilgi almak için: Depoları güncellemek.
Çevirmenler Weblate arayüzünü kullanarak çevirleri yapar ya da çevrim dışı yaptıkları değişiklikleri yükler.
Çevirmenlerin çalışması tamamlandıktan sonra, Weblate değişiklikleri yerel depoya işler (ayrıntılı bilgi almak için: Lazy commit işlemeleri).
Değişiklikler yukarı akış deposuna geri itilir (ayrıntılı bilgi almak için: Weblate üzerindeki değişiklikleri itmek).

İpucu

Yukarı akış kodunun barındırılması gerekli değildir, Weblate Yerel dosyalar ile kullanılabilir. Burada depo yalnızca Weblate içinde bulunur.

Depoları güncellemek¶

Arka uç depolarını kaynaklarından güncellemek için bir yöntem ayarlamalısınız.

Yaygın kullanılan kod barındırma hizmetlerinin çoğuyla bütünleştirmek için :ref:`hooks’ kullanın:
Bunun çalışması için Kancalar kullanılsın işlemini de yapmalısınız.
Depo yönetiminden ya da Weblate REST API uygulaması ya da Weblate istemcisi kullanarak güncellemeyi el ile başlatabilirsiniz
Weblate kopyanızdaki tüm bileşenlerin kendiliğinden güncellenmesi için AUTO_UPDATE seçeneğini kullanıma alın
updategit komutunu yürütün (projeyi seçin ya da tümünü ‘’—güncellemek için all kullanın)

Weblate depoyu her güncellediğinde, güncelleme sonrası eklentileri tetiklenir. Ayrıntılı bilgi almak için: Eklentiler.

Birleştirme çakışmalarından kaçınmak¶

The merge conflicts from Weblate arise when same file was changed both in Weblate and outside it. Depending on the situation, there are several approaches that might help here:

Avoiding merge conflicts by changing translation files in Weblate only
Avoiding merge conflicts by locking Weblate while doing outside changes
Avoiding merge conflicts by focusing on Git operations

Avoiding merge conflicts by changing translation files in Weblate only¶

Avoiding edits outside Weblate is easy with monolingual files — you can add new strings within Weblate and leave whole editing of the files there. For bilingual files, there is usually some kind of message extraction process to generate translatable files from the source code. In some cases, this can be split into two parts:

The extraction generates template (for example gettext POT is generated using xgettext).
Further process merges it into actual translations (the gettext PO files are updated using msgmerge).

You can perform the second step within Weblate and it will ensure that all pending changes are included before this operation.

Avoiding merge conflicts by locking Weblate while doing outside changes¶

Integrating Weblate into your updating process so that it flushes changes before updating the files outside Weblate can be achieved by using Weblate REST API uygulaması to force Weblate to push all pending changes and lock the translation while you are doing changes on your side.

Güncelleme betiği şunun gibi görünebilir:

# Lock Weblate translation
wlc lock
# Push changes from Weblate to upstream repository
wlc push
# Pull changes from upstream repository to your local copy
git pull
# Update translation files, this example is for Django
./manage.py makemessages --keep-pot -a
git commit -m 'Locale updates' -- locale
# Push changes to upstream repository
git push
# Tell Weblate to pull changes (not needed if Weblate follows your repo
# automatically)
wlc pull
# Unlock translations
wlc unlock

If you have multiple components sharing the same repository, you need to lock them all separately:

wlc lock foo/bar
wlc lock foo/baz
wlc lock foo/baj

Not

The example uses Weblate istemcisi, which needs configuration (API keys) to be able to control Weblate remotely. You can also achieve this using any HTTP client instead of Weblate istemcisi, for example curl, see Weblate REST API uygulaması.

Avoiding merge conflicts by focusing on Git operations¶

Even when Weblate is the single source of the changes in the translation files, conflicts can appear when using Git işlemelerini bir araya toplar add-on, Birleştirme biçemi is configured to Rebase, or you are squashing commits outside of Weblate (for example, when merging a pull request).

Bu durumda birleştirme çakışmalarının nedeni farklıdır; Weblate işlemlerini birleştirdikten sonra Weblate üzerinde değişiklikler bulunur. Bu durum genellikle birleştirme işlemi kendiliğinden yapılamadığında ve bir kişinin bunları incelemesi için günlerce veya haftalarca beklendiğinde ortaya çıkar. Git bu durumda bazen yukarı akış değişikliklerini Weblate ile eşleştiremez ve yeniden yerleştirme işlemini reddeder.

To approach this, you either need to minimize the amount of pending changes in Weblate when you merge a pull request, or avoid the conflicts completely by not squashing changes.

Bunu önleyecek bazı seçenekler:

Birleştirme sırasında Git işlemelerini bir araya toplar veya sıkıştırma kullanmayın. Birleştirme sonrasındaki değişikliklerin Git tarafından tanınmamasının temel nedeni budur.
Let Weblate commit pending changes before merging. This will update the pull request with all its changes, and both repositories will be in sync.
Use the review features in Weblate (see Çeviri iş akışları) so that you can automatically merge GitHub pull requests after CI passes.
GitHub çekme isteği incelenirken değişiklikler yapılmasını önlemek için Weblate kilitleme özelliğini kullanın.

Ayrıca bakınız

Weblate istemcisi

GitHub değişikliklerini kendiliğinden almak¶

Weblate doğal GitHub desteği ile gelir.

Hosted Weblate kullanıyorsanız, Weblate uygulaması kurmanız önerilir. Böylece çok fazla şeyi ayarlamanız gerekmeden doğru kurulumu elde edersiniz. Değişiklikleri geri itmek için de kullanılabilir.

GitHub deposuna yapılan her itmede bildirim almak için, depo ayarlarına (Webhooks) aşağıdaki görseldeki gibi Weblate internet kancasını ekleyin:

Yük adresi olarak, Weblate adresinizin sonuna “/hooks/github/” ekleyin. Örneğin Hosted Weblate hizmeti için “https://hosted.weblate.org/hooks/github/” kullanabilirsiniz.

Diğer ayarları varsayılan değerlerinde bırakabilirsiniz (Weblate her iki içerik türünü de işleyebilir ve yalnızca push işlemine gerek duyar).

Ayrıca bakınız

POST /hooks/github/, Hosted Weblate üzerinden depolara erişmek

Bitbucket değişikliklerini kendiliğinden almak¶

Weblate, Bitbucket internet kancalarını destekler. Weblate kurulumunuza hedef olarak /hooks/bitbucket/ adresiyle depo itme işlemi sırasında tetiklenecek bir internet kancası ekleyin (https://hosted.weblate.org/hooks/bitbucket/ gibi).

Ayrıca bakınız

POST /hooks/bitbucket/, Hosted Weblate üzerinden depolara erişmek

GitLab değişikliklerini kendiliğinden almak¶

Weblate, GitLab kancalarını destekler. Weblate kurulumunuza hedef olarak /hooks/gitlab/ adresiyle hedefi bir proje internet kancası ekleyin (``https://hosted.weblate.org/hooks/gitlab/``gibi).

Ayrıca bakınız

POST /hooks/gitlab/, Hosted Weblate üzerinden depolara erişmek

Pagure değişikliklerini kendiliğinden almak¶

Weblate, Pagure kancalarını destekler. Weblate kurulumunuza hedef olarak /hooks/pagure/ internet kancasını ekleyin (https://hosted.weblate.org/hooks/pagure/ gibi). Bu işlem, Proje ayarları bölümündeki Web kancaları kullanılsın seçeneği ile yapılabilir:

Ayrıca bakınız

POST /hooks/pagure/, Hosted Weblate üzerinden depolara erişmek

Azure Repos değişikliklerini kendiliğinden almak¶

Weblate, Azure Repos kancalarını destekler. Weblate kurulumunuza İtilecek kod işlemi için hedef olarak /hooks/azure/ internet kancasını ekleyin (https://hosted.weblate.org/hooks/azure/ gibi). Bu işlem, Proje ayarları bölümündeki Hizmet kancaları seçeneği ile yapılabilir.

Ayrıca bakınız

Azure DevOps rehberinde internet kancaları, POST /hooks/azure/, Hosted Weblate üzerinden depolara erişmek

Gitea depoları değişikliklerini kendiliğinden almak¶

Weblate, Gitea kancalarını destekler. Weblate kurulumunuza İtme işlemleri içinden Gitea internet kancası işlemi için hedef olarak /hooks/gitea/ internet kancasını ekleyin (https://hosted.weblate.org/hooks/gitea/ gibi). Bu işlem, Ayarlar bölümündeki Web kancaları seçeneği ile yapılabilir.

Ayrıca bakınız

Gitea rehberinde internet kancaları, POST /hooks/gitea/, Hosted Weblate üzerinden depolara erişmek

Gitee depoları değişikliklerini kendiliğinden almak¶

Weblate, Gitee kancalarını destekler. Weblate kurulumunuza İtme işlemi için hedef olarak /hooks/gitee/ internet kancasını ekleyin (https://hosted.weblate.org/hooks/gitee/ gibi). Bu işlem, Yönetim bölümündeki Web kancaları seçeneği ile yapılabilir.

Ayrıca bakınız

Gitee rehberinde internet kancaları, POST /hooks/gitee/, Hosted Weblate üzerinden depolara erişmek

Depoları her gece kendiliğinden güncellemek¶

Weblate, daha sonra değişiklik birleştirme başarımını artırmak için her gece uzak depoları kendiliğinden alır. İsteğe bağlı olarak, AUTO_UPDATE seçeneğini kullanıma alarak bunu gecelik birleştirmeler yapmaya da dönüştürebilirsiniz.

Weblate üzerindeki değişiklikleri itmek¶

Her çeviri bileşeni için ayrı bir itme adresi ayarlanabilir (ayrıntılı bilgi almak için: Depo itme adresi) ve bu durumda Weblate, değişikliği uzak depoya itebilir. Weblate, değişiklikleri her işlemede kendiliğinden itecek şekilde de yapılandırılabilir (varsayılan davranış, ayrıntılı bilgi almak için: İşleme ile itme). Değişikliklerin kendiliğinden itilmesini istemiyorsanız, bunu el ile Depo bakımı bölümünden ya da wlc push API kullanarak yapabilirsiniz.

İtme seçenekleri, kullanılan Sürüm denetimi bütünleştirmesi değerine göre farklılık gösterir. Ayrıntılı bilgileri bu bölümden alabilirsiniz.

İtme işleminin doğrudan Weblate tarafından yapılmasını istemiyorsanız, GitHub çekme istekleri, GitLab birleştirme istekleri, Gitea çekme isteği, Pagure birleştirme istekleri, Azure DevOps sunucusu çekme isteği çekme istekleri ya da Gerrit onayları desteklenmektedir. Bunları Bileşen yapılandırması içindeki Sürüm denetimi sistemi bölümünden GitHub, GitLab, Gitea, Gerrit, Azure DevOps ya da Pagure olarak seçerek etkinleştirebilirsiniz.

Genel olarak, Git, Mercurial, GitHub, GitLab, Gitea, Pagure, Azure DevOps, Bitbucket Server ve Bitbucket Cloud ile şu seçenekler kullanılabilir:

İstenilen kurulum	Sürüm denetimi sistemi	Depo itme adresi	İtme işleminin yapılacağı dal
İtme yok	Git	empty	empty
Doğrudan itme	Git	SSH adresi	empty
Ayrı bir dala itilsin	Git	SSH adresi	Dal adı
İtme yok	Mercurial	empty	empty
Doğrudan itme	Mercurial	SSH adresi	empty
Ayrı bir dala itilsin	Mercurial	SSH adresi	Dal adı
GitHub dalından çekme isteği	GitHub çekme istekleri	empty	empty
GitHub dalına itme isteği	GitHub çekme istekleri	SSH URL [1]	Dal adı
GitLab dalından birleştirme isteği	GitLab birleştirme istekleri	empty	empty
GitLab dalından birleştirme isteği	GitLab birleştirme istekleri	SSH URL [1]	Dal adı
Gitea çatalından birleştirme isteği	Gitea çekme isteği	empty	empty
Gitea dalından birleştirme isteği	Gitea çekme isteği	SSH URL [1]	Dal adı
Pagure çatalından birleştirme isteği	Pagure birleştirme istekleri	empty	empty
Pagure dalından birleştirme isteği	Pagure birleştirme istekleri	SSH URL [1]	Dal adı
Azure DevOps dalından çekme isteği	Azure DevOps sunucusu çekme isteği	empty	empty
Azure DevOps dalına itme isteği	Azure DevOps sunucusu çekme isteği	SSH URL [1]	Dal adı
Daldan Bitbucket Server çekme istekleri	Bitbucket Server çekme istekleri	empty	empty
Daldan Bitbucket Server çekme istekleri	Bitbucket Server çekme istekleri	SSH URL [1]	Dal adı
Daldan Bitbucket Cloud sunucusu çekme isteği	Bitbucket Cloud sunucusu çekme isteği	empty	empty
Daldan Bitbucket Cloud çekme isteği	Bitbucket Cloud sunucusu çekme isteği	SSH URL [1]	Dal adı

Not

Weblate işledikten sonra değişikliklerin kendiliğinden itilmesini de kullanıma alabilirsiniz. Bu işlem İşleme ile itme içinden yapılabilir.

Ayrıca bakınız

SSH anahtarlarını ayarlamak için Depolara erişmek ve değişikliklerin Weblate tarafından ne zaman işleneceğine karar verildiği ile ilgili ayrıntılı bilgi almak için :ref:’lazy-commit’ bölümlerine bakabilirsiniz.

Korunmuş dallar¶

Weblate ile korumalı dal kullanıyorsanız, çekme isteklerini kullanacak ve çeviriler üzerinde gerçek gözden geçirme yapacak bir yapılandırma ayarlayabilirsiniz (bilmediğiniz diller için sorunlu olabilecek şeyler). Alternatif olarak, Weblate itme kullanıcısı için bu sınırlamayı kaldırabilirsiniz.

Örneğin bu işlem GitHub üzerinde, depo yapılandırmasında ayarlanabilir:

Diğerleri ile etkileşim¶

Weblate, API uygulaması -başkalarıyla etkileşim kurmayı kolaylaştırır.

Ayrıca bakınız

Weblate REST API uygulaması

Lazy commit işlemeleri¶

Weblate, olabiliyorsa aynı yazardan gelen işlemeleri tek bir işleme olarak gruplandıracak biçimde davranır. Böylece, işleme sayısı büyük ölçüde azaltılır. Bununla birlikte, sürüm denetimi sistemi deposunu eşitlemek isterseniz bunu açıkça belirtmeniz gerekir. Örneğin birleştirme için (varsayılan olarak Yöneticiler’`grubu için izin verilir, ayrıntılı bilgi almak için: :ref:`privileges).

Bu kipteki değişiklikler, aşağıdaki koşullardan herhangi biri yerine getirildiğinde işlenir:

Başka biri zaten değiştirilmiş bir dizgeyi değiştirdiğinde.
Yukarı akıştan bir birleştirme gerçekleştirildiğinde.
Açık bir işleme isteği yapıldığında.
Bir dosyanın indirilmesi istendiğinde.
Değişiklik, Bileşen yapılandırması üzerinde İşlenecek değişikliklerin yaşı olarak tanımlanmış dönemden daha eski olduğunda.

İpucu

İşlemeler her bileşen için ayrı oluşturulur. Bu nedenle, birçok bileşeniniz varsa, gene çok sayıda işleme görürsünüz. Bu durumda Git işlemelerini bir araya toplar eklentisini kullanabilirsiniz.

Değişikliklerin daha sık ve yaşları denetlemeden yapılmasını istiyorsanız, işlemeyi yapacak bir zamanlanmış görev ayarlayabilirsiniz. Bu işlemi Django yönetim arayüzü içinde Zamanlanmış görevler bölümünden yapabilirsiniz. Önce istediğiniz Sıklık ögesini oluşturun (120 saniye gibi). Ardından yeni bir zamanlanmış görev ekleyin ve Görev olarak weblate.trans.tasks.commit_pending, Anahtar sözcük parametreleri ve istenilen sıklık olarak {"hours": 0} yazın.

Betikleri kullanarak depo işlemleri yapmak¶

Weblate ile depo arasındaki etkileşim Eklentiler ile özelleştirilebilir. Eklentiler ile dış betiklerin nasıl yürütüleceği ile ilgili ayrıntılı bilgi almak için Eklentiden betikleri çalıştırma bölümüne bakabilirsiniz.

Bileşenler arasında çevirilerin tutarlığını sağlamak¶

Birden çok çeviri bileşeniniz olduğunda, aynı dizgelerin çevirilerinin de aynı olduğundan emin olmak isteyebilirsiniz. Bu tutarlılık birkaç düzeyde sağlanabilir.

Çevirilerin yayılmasını sağlamak¶

Çevirilerin yayılmasını sağlamak seçeneği kullanıma alınmışken (varsayılan değer nedir, ayrıntılı bilgi almak için: Bileşen yapılandırması), tüm yeni çeviriler dizgeleri eşleşen tüm bileşenlerde kendiliğinden yapılır. Bu tür çeviriler, tüm bileşenlerde çeviriyi yapan geçerli kullanıcının hesabına yazılır.

Not

Çeviri yayılması için, anahtarın tek dilli çeviri biçimleriyle eşleşmesi gerekir. Çeviri anahtarlarını oluştururken bunu aklınızda bulundurun.

Tutarlılık denetimi¶

Dizgeler farklı olduğunda Tutarsız denetimi tetiklenir. Bu tür farklılıkları el ile incelemek ve doğru çeviriyi seçmek için bunu kullanabilirsiniz.

Kendiliğinden çeviri¶

Farklı bileşenleri temel alan kendiliğinden çeviri, çevirileri bileşenler arasında eşitlemenin bir yöntemi olabilir. El ile tetikleyebilir (ayrıntılı bilgi almak için: Kendiliğinden çeviri) veya eklentiyi kullanarak depo güncellemelerinde kendiliğinden çalışmasını sağlayabilirsiniz (ayrıntılı bilgi almak için: Kendiliğinden çeviri).