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:

  1. Geliştiriciler değişiklikler yapar ve bunları sürüm denetimi sistemi deposuna gönderir.

  2. İsteğe bağlı olarak çeviri dosyaları güncellenir. Ayrıntılı bilgi almak için: Yeni dizgeler sunmak.

  3. Weblate pulls changes from the VCS repository, parses translation files and updates its database, see Depoları güncellemek.

  4. Çevirmenler Weblate arayüzünü kullanarak çevirleri yapar ya da çevrim dışı yaptıkları değişiklikleri yükler.

  5. Once the translators are finished, Weblate commits the changes to the local repository (see Lazy commit işlemeleri).

  6. Changes are pushed back to the upstream repository (see Weblate üzerindeki değişiklikleri itmek).

digraph translations { graph [fontname = "sans-serif", fontsize=10, ranksep=0.6, newrank=true]; node [fontname = "sans-serif", fontsize=10, margin=0.15]; edge [fontname = "sans-serif", fontsize=10]; subgraph cluster_codehosting { rank=same; graph [color=lightgrey, label="Upstream code hosting", style=filled ]; "VCS repository" [shape=cylinder]; } subgraph cluster_weblate { rank=same; graph [color=lightgrey, label="Weblate", style=filled ]; repo [label="Weblate repository", shape=cylinder]; database [label=Database, shape=cylinder]; } "Developers" [shape=box, fillcolor="#144d3f", fontcolor=white, style=filled]; "Translators" [shape=box, fillcolor="#144d3f", fontcolor=white, style=filled]; "Developers" -> "VCS repository" [label=" 1. Push "]; "VCS repository" -> "VCS repository" [label=" 2. Updating translations ", style=dotted]; "VCS repository" -> repo [label=" 3. Pull "]; repo -> database [label=" 3. Parse translations "]; "database" -> repo [label=" 5. Commit changes "]; "Translators" -> "database" [label=" 4. Translate "]; "repo" -> "VCS repository" [label=" 6. Push repository "]; }

İpucu

Upstream code hosting is not necessary, you can use Weblate with Yerel dosyalar where there is only the repository inside Weblate.

Depoları güncellemek#

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

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#

Aynı dosya hem Weblate üzerinde hem de Weblate dışında değiştirildiğinde Weblate üzerinden gelen birleştirmelerde çakışmalar ortaya çıkar. Bu sorunu çözmek için kullanılabilecek iki yaklaşım vardır. Weblate dışındaki düzenlemelerden kaçınmak ya da güncelleme sürecinizi Weblate ile bütünleştirmek. Böylece Weblate dışındaki dosyalar güncellenmeden önce değişiklikler temizlenir.

Tek dilli dosyalar için ilk yaklaşım kolaydır. Weblate üzerinde yeni dizgeler ekleyebilir ve dosyaların tüm düzenleme işlemlerini orada yapabilirsiniz. İki dilli dosyalar için, kaynak kodundan çevrilebilir dosyalar oluşturmak için genellikle bir tür ileti ayıklama işlemi vardır. Bazı durumlarda bu işlem iki bölüme ayrılabilir. Birinci adım ayıklama kalıbını oluşturur (örneğin Gettext POT xgettext kullanılarak oluşturulur) ve ikinci adım onu gerçek çevirilerle birleştirir (Gettext PO dosyaları msgmerge kullanılarak güncellenir). İkinci adımı Weblate içinde yapabilirsiniz ve bu işlemden önce bekleyen tüm değişikliklerin katıldığına emin olabilirsiniz.

İkinci yaklaşım, Weblate REST API uygulaması ile Weblate uygulamasını bekleyen tüm değişiklikleri itmek ve kendi tarafınızda değişiklikler yaparken çeviriyi kilitlemek yoluyla uygulanabilir.

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

Aynı depoyu paylaşan birden fazla bileşeniniz varsa hepsini ayrı ayrı kilitlemeniz gerekir:

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

Not

Örnekte, uzaktan Weblate yönetimi için yapılandırmaya (API anahtarları) gerek duyan Weblate istemcisi kullanılır. Bunu wlc yerine curl gibi herhangi bir HTTP istemcisini kullanarak da yapabilirsiniz. Ayrıntılı bilgi almak için: Weblate REST API uygulaması.

Avoiding merge conflicts on Weblate originated changes#

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 Weblate (for example when merging a pull request).

The reason for merge conflicts is different in this case - there are changes in Weblate which happened after you merged Weblate commits. This typically happens if merging is not automated and waits for days or weeks for a human to review them. Git is then sometimes no longer able to idetify upstream changes as matching to Weblate one and refuses to perform rebase.

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

Here are few options how to avoid that:

  • Do not use neither Git işlemelerini bir araya toplar nor squashing at merge time. This is the root cause why git doesn’t recognize changes after merging.

  • 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.

  • Use locking in Weblate to avoid changes while GitHub pull request is in review.

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:

../_images/github-settings.png

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).

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).

../_images/bitbucket-settings.png

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).

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:

../_images/pagure-webhook.png

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.

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.

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.

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 otomatik olarak gönderecek ş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 seçeneğini 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.

In case you do not want direct pushes by Weblate, there is support for GitHub çekme istekleri, GitLab birleştirme istekleri, Gitea çekme isteği, Pagure birleştirme istekleri, Azure DevOps pull requests pull requests or Gerrit reviews, you can activate these by choosing GitHub, GitLab, Gitea, Gerrit, Azure DevOps, or Pagure as Sürüm denetimi sistemi in Bileşen yapılandırması.

Overall, following options are available with Git, Mercurial, GitHub, GitLab, Gitea, Pagure, and Azure DevOps:

İ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 it

Git

SSH adresi

Dal adı

İtme yok

Mercurial

empty

empty

Doğrudan itme

Mercurial

SSH adresi

empty

Ayrı bir dala it

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 pull request from fork

Azure DevOps pull requests

empty

empty

Azure DevOps pull request from branch

Azure DevOps pull requests

SSH URL [1]

Dal adı

Not

Weblate işledikten sonra değişikliklerin kendiliğinden gönderilmesini 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:

../_images/github-protected.png

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).