Integrasi kontrol versi¶
Weblate currently supports Git (with extended support for Permintaan tarik GitHub, Permintaan penggabungan GitLab, Permintaan tarik Gitea, Gerrit review requests, Subversion, Permintaan penarikan Bitbucket Cloud, Permintaan penarikan Bitbucket Data Center, and Permintaan penarikan Azure DevOps) and Mercurial as version control back-ends.
For provider-specific setup steps that combine repository access, incoming notifications, and pushing translations back, see Integrasi hosting kode.
Mengakses repositori¶
Repositori VCS yang ingin Anda gunakan harus dapat diakses oleh Weblate. Dengan repositori yang tersedia untuk umum, Anda hanya perlu memasukkan URL yang benar (misalnya https://github.com/WeblateOrg/weblate.git), tetapi untuk repositori privat atau URL dorong, pengaturannya lebih rumit dan memerlukan autentikasi.
Troubleshooting repository URLs¶
Weblate validates repository and push URLs before connecting. HTTPS and SSH
are permitted by default; instance administrators can adjust this using
VCS_ALLOW_SCHEMES.
Repository hostnames have to resolve from the Weblate server. When
VCS_RESTRICT_PRIVATE is enabled, Weblate also rejects destinations
which resolve to internal or otherwise non-public addresses. Use a publicly
reachable repository URL where possible. For an intentionally private
repository on a trusted network, ask the instance administrator to add its
hostname to VCS_ALLOW_HOSTS.
Git over HTTPS and SSH can bind connections to addresses approved during
validation. Backends which cannot do this safely, including Mercurial and
Subversion, require the trusted repository hostname in
VCS_ALLOW_HOSTS while private-address restrictions are enabled.
Configure the final repository URL directly when possible. Weblate can automatically accept a permanent HTTP redirect only when it stays on the same host and the target is successfully validated. Redirects to another host or protocol have to be configured manually.
Mengakses repositori dari Hosted Weblate¶
Catatan
Bagian ini hanya berlaku untuk Hosted Weblate (hosted.weblate.org). Jika Anda menjalankan instansi Weblate yang dihos sendiri, silakan lihat bagian selanjutnya sebagai gantinya.
For GitHub repositories on Hosted Weblate, use the Hosted Weblate app from Weblate's Connect GitHub account flow whenever possible. The App grants repository access, receives incoming notifications, pushes translation branches, and creates pull requests without inviting the Hosted Weblate weblate user. See GitHub repository access for the full setup.
For direct SSH access outside the GitHub App workflow, and for Bitbucket,
Codeberg, and GitLab repositories, Hosted Weblate has a dedicated push user
(with the username weblate, e-mail hosted@weblate.org, and a
name or profile description Weblate push user).
Petunjuk
Mungkin ada lebih banyak pengguna Weblate di platform yang ditunjuk untuk instansi Weblate lainnya. Pencarian melalui surel hosted@weblate.org disarankan untuk menemukan pengguna yang tepat untuk Hosted Weblate.
Anda perlu menambahkan pengguna ini sebagai kolaborator dan memberinya izin yang sesuai ke repositori Anda (hanya baca diperbolehkan untuk kloning, tulis diperlukan untuk mendorong). Tergantung pada layanan dan pengaturan organisasi Anda, hal ini akan segera dilakukan, atau memerlukan konfirmasi di sisi Weblate.
The weblate user on GitHub accepts invitations automatically within five minutes when you intentionally use direct SSH access there. Manual processing might be needed on the other services, so please be patient.
For this direct SSH-user setup, once the weblate user is added to
your repository, you can configure Repositori kode sumber and
URL dorong repositori using the SSH protocol, for example
git@example.com:group/project.git.
Accessing repositories on code-hosting sites (GitHub, GitLab, Bitbucket, Azure DevOps, ...)¶
Catatan
Bagian ini berlaku untuk instansi Weblate yang dihos sendiri. Jika Anda menggunakan Hosted Weblate (hosted.weblate.org), lihat Mengakses repositori dari Hosted Weblate sebagai gantinya.
For self-hosted Weblate, a single private repository is often easiest to set up using an HTTPS repository URL with an access token, see Integrasi hosting kode.
For multiple repositories, create a dedicated code-hosting user associated with a Weblate SSH key (see Kunci SSH Weblate). This way you associate Weblate SSH key with a single user, because platforms frequently enforce single use of an SSH key. Grant this user access to the repositories, and use SSH URLs to access them (see Repositori SSH).
Repositori SSH¶
One common method to access private repositories is based on SSH. Authorize the public Weblate SSH key (see Kunci SSH Weblate) to access the upstream repository this way.
Peringatan
On GitHub, each key can only be used once, see GitHub repository access and Mengakses repositori dari Hosted Weblate.
Weblate juga menyimpan sidik jari kunci host pada sambungan pertama, dan gagal terhubung ke host jika diubah kemudian (lihat Memverifikasikan kunci hos SSH).
Jika penyesuaian diperlukan, lakukan dari antarmuka admin Weblate:
Kunci SSH Weblate¶
Berubah pada versi 4.17: Weblate sekarang menghasilkan kunci SSH RSA dan Ed25519. Penggunaan Ed25519 direkomendasikan untuk pengaturan baru.
Kunci publik Weblate dapat dilihat oleh semua pengguna yang menelusuri halaman Tentang.
Admin dapat membuat atau menampilkan kunci publik yang saat ini digunakan oleh Weblate dalam sambungan (dari Kunci SSH) di halaman awal antarmuka admin.
Catatan
Kunci SSH privat yang sesuai saat ini tidak dapat memiliki kata sandi, jadi pastikan kunci tersebut dilindungi dengan baik.
Petunjuk
Buat cadangan kunci SSH Weblate privat yang dihasilkan.
Memverifikasikan kunci hos SSH¶
Weblate secara otomatis menyimpan kunci hos SSH pada akses pertama dan mengingatnya untuk penggunaan lebih lanjut.
When VCS_RESTRICT_PRIVATE is enabled, Weblate resolves and validates
the repository host before scanning its key and connects ssh-keyscan only
to the approved addresses. The stored key remains associated with the original
hostname.
For Git connections, Weblate also applies HostName and Port from
DATA_DIR/ssh/config before validating and pinning the effective
destination. SSH configuration and SSH_EXTRA_ARGS are trusted
administrator-controlled inputs. They can alter connection routing, and
SSH_EXTRA_ARGS can override Weblate's address pinning;
administrators are responsible for their effects.
Jika Anda ingin memverifikasikan sidik jari kunci sebelum terhubung ke repositori, tambahkan kunci hos SSH server yang akan Anda akses di Tambahkan kunci hos, dari bagian yang sama di antarmuka admin. Masukkan nama hos yang akan Anda akses (mis. gitlab.com), lalu tekan Kirim. Pastikan sidik jarinya cocok dengan server yang Anda tambahkan.
Kunci tambahan dengan sidik jari ditunjukkan dalam pesan konfirmasi:
Menghubungkan ke server SSH lawas¶
Rilis OpenSSH terkini (misalnya yang digunakan dalam kontainer Docker Weblate) menonaktifkan tanda tangan RSA menggunakan algoritma hash SHA-1 secara bawaan. Perubahan ini dilakukan karena algoritma hash SHA-1 rusak secara kriptografis, dan tabrakan hash dengan awalan terpilih dapat terjadi untuk <USD$50K.
Bagi sebagian besar pengguna, perubahan ini seharusnya tidak terlihat dan tidak perlu mengganti kunci ssh-rsa. OpenSSH telah mendukung tanda tangan RFC8332 RSA/SHA-256/512 sejak rilis 7.2 dan kunci ssh-rsa yang ada akan secara otomatis menggunakan algoritma yang lebih kuat jika memungkinkan.
Ketidakcocokan lebih mungkin terjadi saat menghubungkan ke implementasi SSH lama yang belum diperbarui atau belum dipantau secara ketat terkait peningkatan protokol SSH. Sambungan SSH ke server tersebut akan gagal jika:
no matching host key type found. Their offer: ssh-rsa
Untuk kasus ini, RSA/SHA1 mungkin perlu diaktifkan kembali secara selektif untuk memungkinkan sambungan dan/atau autentikasi pengguna melalui opsi HostkeyAlgorithms dan PubkeyAcceptedAlgorithms. Misalnya, bait berikut dalam DATA_DIR/ssh/config akan mengaktifkan RSA/SHA1 untuk autentikasi host dan pengguna untuk satu host tujuan:
Host legacy-host
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
Kami sarankan mengaktifkan RSA/SHA1 hanya sebagai tindakan sementara hingga implementasi lawas dapat ditingkatkan atau dikonfigurasikan ulang dengan jenis kunci lain (seperti ECDSA atau Ed25519).
Repositori GitHub¶
Detailed GitHub repository access is covered in GitHub repository access.
Repositori GitLab¶
Detailed GitLab repository access is covered in GitLab repository access.
URL internal Weblate¶
Berbagi satu pengaturan repositori antar komponen yang berbeda dengan merujuk penempatannya sebagai weblate://project/component di komponen lain (yang tertaut). Dengan cara ini, komponen yang tertaut menggunakan konfigurasi repositori VCS dari komponen utama (yang direferensikan).
Peringatan
Menghapus komponen utama juga menghapus komponen tertaut.
Linked components share the complete repository checkout; the link does not isolate them to particular files or directories. Users allowed to administer a linked component can configure operations affecting files anywhere in the shared checkout. For example, they can change file masks, formats, and templates, or install and configure add-ons that read, generate, or modify repository files. Weblate can commit and push resulting changes using the main component's repository configuration.
Only link components when the repository owner trusts the administrators of every linked component with the complete checkout. Use separate repositories when components require file-level isolation.
Weblate secara otomatis menyesuaikan URL repositori saat membuat komponen jika menemukan komponen dengan pengaturan repositori yang cocok. Anda dapat menimpakan pengaturan ini di langkah terakhir konfigurasi komponen.
Alasan untuk menggunakan ini:
Menghemat ruang cakram pada server, repositori disimpan hanya sekali.
Membuat pembaruan lebih cepat, hanya satu repositori yang diperbarui.
Hanya ada satu repositori yang diekspor dengan terjemahan Weblate (lihat Eksportir Git).
Beberapa pengaya dapat beroperasi pada beberapa komponen yang berbagi satu repositori, misalnya Lumatkan komit Git.
Repositori HTTPS¶
Lihat juga
Untuk mengakses repositori HTTPS yang dilindungi, sertakan nama pengguna dan kata sandi di URL. Jangan khawatir, Weblate akan menghapus informasi ini ketika URL ditampilkan kepada pengguna (bahkan jika diizinkan untuk melihat URL repositori tersebut).
Misalnya URL GitHub dengan autentikasi yang ditambahkan mungkin terlihat seperti: https://user:your_access_token@github.com/WeblateOrg/weblate.git.
Jika Anda tidak memberikan kredensial di URL dan repositori memerlukannya, Git akan gagal dengan galat:
fatal: could not read Username for 'https://github.com': terminal prompts disabled
Berubah pada versi 5.10.2: Weblate menggunakan autentikasi proaktif dengan Git 2.46.0 dan yang lebih baru saat kredensial HTTP diberikan.
Hal ini memungkinkan untuk mengakses repositori Azure DevOps dan membuat akses ke repositori yang diautentikasikan lebih cepat.
Catatan
Jika nama pengguna atau kata sandi Anda berisi karakter khusus, karakter tersebut harus dienkodekan URL, misalnya https://user%40example.com:%24password%23@bitbucket.org/….
Menggunakan proksi¶
If you need to access Git repositories over HTTPS using a proxy server, configure the per-protocol environment variables described in Proksi HTTP.
Parameter kontrol versi¶
Added in version 2026.9.
Version control parameters tune how a component interacts with its repository without having to choose a different version control system. They are configured per component in Parameter kontrol versi, and only the parameters applicable to the selected Sistem kontrol versi are offered.
List of version control parameters¶
Nama parameter |
Version control systems |
Label |
Teks bantuan |
|---|---|---|---|
create_merge_request |
|
Buat permintaan penggabungan |
Buka pull atau merge request untuk perubahan terjemahan. Saat dimatikan, Weblate mendorong langsung ke cabang yang diterjemahkan, yang memerlukan akses tulis kepadanya. |
git_force_push |
|
Paksa dorong |
Timpa cabang remote alih-alih menolak mendorong perubahan non-fast-forward. Hanya gunakan ini dengan repositori yang dikhususkan untuk terjemahan, karena ini membuang commit hulu yang tidak ada di Weblate. |
merge_request_automerge |
|
Gabungkan pull request secara otomatis |
Aktifkan auto-merge GitHub untuk pull request yang dibuat oleh Weblate, sehingga pull request tersebut digabungkan setelah pemeriksaan yang diperlukan lolos. Pull request yang tidak memiliki hal yang perlu ditunggu akan langsung digabungkan. |
merge_request_merge_method |
|
Metode penggabungan |
Metode yang digunakan saat menggabungkan pull request secara otomatis. Repositori harus mengizinkannya. Pilihan yang tersedia:
|
Git¶
Petunjuk
Weblate needs Git 2.46 or newer.
Catatan
Weblate validates permanent HTTP redirects which stay on the repository hostname and automatically stores the canonical repository URL. The change is recorded in the component history as repository maintenance. Redirects to another hostname have to be configured manually.
Lihat juga
Lihat Mengakses repositori untuk informasi tentang cara mengakses berbagai jenis repositori.
Git LFS¶
Weblate does not support files tracked by Git LFS as translation files. It does not download or upload Git LFS objects. Git LFS smudging and pre-push uploads are disabled for Weblate-managed repositories, so LFS-tracked files remain pointer files. This behavior applies to every Git hosting provider.
A repository can use Git LFS for files that Weblate does not need to read or modify. The upstream repository remains the authoritative source for these LFS objects. Clone from upstream when you need the actual files rather than their pointers because repositories served by Weblate do not include LFS objects.
For the GitLab merge request workflow, Weblate disables Git LFS in its managed fork. This prevents GitLab from rejecting pointer-only translation branches when the upstream repository added LFS objects after the fork was created. Existing managed forks are reconfigured on their next push. This does not change the Git LFS configuration of the upstream project.
Git submodules¶
Weblate does not populate Git submodules when cloning repositories. It does not initialize or update submodules, and it does not recurse into submodule repositories during file discovery or translation updates. Files stored inside a submodule are therefore not available to file masks when Weblate is connected to the parent repository.
If translation files live in a submodule, add the submodule repository to Weblate as its own component instead of reaching it through the parent repository. Weblate can then clone, update, commit, and push to the repository that actually stores the translation files. The parent repository only records the submodule commit pointer, so updating that pointer has to happen outside Weblate, for example in your normal development workflow or CI.
Force pushing¶
Turn on the git_force_push version control parameter to
make Weblate always force push. This is intended only in the case of using a
separate repository for translations.
Peringatan
Gunakan dengan hati-hati, karena hal ini mudah menyebabkan hilangnya komit di repositori hulu Anda.
Berubah pada versi 2026.9: This used to be a separate Git with force push version control
system. Existing components were migrated to Git with the git_force_push
parameter turned on.
Menyesuaikan konfigurasi Git¶
Weblate memanggil semua perintah VCS dengan HOME=$DATA_DIR/home (lihat DATA_DIR), oleh karena itu penyuntingan konfigurasi pengguna perlu dilakukan di DATA_DIR/home/.git.
Permintaan tarik GitHub¶
Detailed GitHub pull request setup is covered in Permintaan tarik GitHub.
Permintaan penggabungan GitLab¶
Detailed GitLab merge request setup is covered in Permintaan penggabungan GitLab.
Permintaan tarik Gitea¶
Detailed Gitea pull request setup is covered in Permintaan tarik Gitea.
Permintaan penarikan Bitbucket Data Center¶
Detailed Bitbucket Data Center pull request setup is covered in Permintaan penarikan Bitbucket Data Center.
Permintaan penarikan Bitbucket Cloud¶
Detailed Bitbucket Cloud pull request setup is covered in Permintaan penarikan Bitbucket Cloud.
Permintaan penggabungan Pagure¶
Detailed Pagure merge request setup is covered in Permintaan penggabungan Pagure.
Gerrit¶
Detailed Gerrit review request setup is covered in Gerrit review requests.
Permintaan penarikan Azure DevOps¶
Detailed Azure DevOps pull request setup is covered in Permintaan penarikan Azure DevOps.
Mercurial¶
Mercurial adalah VCS lain yang dapat Anda gunakan langsung di Weblate.
Catatan
Seharusnya berfungsi dengan versi Mercurial mana pun, tetapi terkadang ada perubahan yang tidak kompatibel pada antarmuka baris perintah yang merusak integrasi Weblate.
Lihat juga
Lihat Mengakses repositori untuk informasi tentang cara mengakses berbagai jenis repositori.
Subversion¶
Weblate menggunakan git-svn untuk berinteraksi dengan repositori subversion. Ini adalah skrip Perl yang memungkinkan subversion digunakan oleh klien Git, memungkinkan pengguna untuk memelihara klon penuh dari repositori internal dan komit secara lokal.
Catatan
Weblate mencoba untuk mendeteksi tata letak repositori Subversion secara otomatis - ia mendukung URL langsung untuk cabang atau repositori dengan tata letak standar (branch/,tag/ dan trunk/). Info lebih lanjut tentang ini dapat ditemukan di Dokumentasi git-svn. Jika repositori Anda tidak memiliki tata letak standar dan Anda menemukan galat, coba sertakan nama cabang di URL repositori dan biarkan cabang kosong.
Kredensial Subversion¶
Weblate mengharapkan Anda untuk menerima sertifikat terlebih dahulu (dan kredensial Anda jika diperlukan). Weblate akan mencoba memasukkannya ke dalam direktori DATA_DIR. Terima sertifikat dengan menggunakan svn sekali dengan variabel lingkungan $HOME yang diatur ke DATA_DIR:
# 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
Lihat juga
Berkas lokal¶
Petunjuk
Di bawahnya, ini menggunakan Git. Ini membutuhkan Git yang sudah terpasang dan memungkinkan Anda beralih menggunakan Git secara asli dengan riwayat terjemahan yang lengkap.
Weblate juga dapat beroperasi tanpa VCS jarak jauh. Terjemahan awal diimpor dengan mengunggahnya. Nantinya, Anda dapat mengganti berkas individual dengan mengunggah berkas, atau menambahkan string terjemahan langsung dari Weblate (saat ini hanya tersedia untuk terjemahan ekabahasa).
Di latar belakang Weblate membuat repositori git untuk Anda dan semua perubahan dilacak. Jika Anda kemudian memutuskan untuk menggunakan VCS untuk menyimpan terjemahan, Anda sudah memiliki repositori di dalam Weblate dapat mendasarkan integrasi Anda.