Folyamatos lokalizáció¶

Olyan infrastruktúra áll rendelkezésre, amely biztosítja, hogy a fordítások szorosan kövessék a fejlesztést. Így a fordítók folyamatosan dolgozhatnak a fordításokon, ahelyett hogy a kiadás előtt kellene egyszerre nagy mennyiségű új szöveget lefordítaniuk.

Lásd még

Az alapvető integrációs lehetőségeket a fejlesztési folyamattal az Integráció a Weblate-tel dokumentáció ismerteti.

A folyamat a következő:

A fejlesztők módosításokat hajtanak végre, majd feltöltik azokat a VCS (verziókezelő) tárolóba.
Igény esetén frissítik a fordítási fájlokat, lásd: Új szövegek bevezetése.
A Weblate letölti a változásokat a VCS (verziókezelő) tárolóból, feldolgozza a fordítási fájlokat és frissíti az adatbázisát, lásd: Tárolók frissítése.
A fordítók a Weblate webes felületén keresztül vagy offline módosítások feltöltésével végzik a fordításokat.
Amint a fordítók elkészülnek, a Weblate véglegesíti a módosításokat a helyi tárolóban (lásd: Késleltetett véglegesítések (Lazy commits)).
A változások visszatöltésre kerülnek a forrás tárolóba, lásd: Változások feltöltése Weblate-ből.

Tipp

Nincs feltétlenül szükség külső kódtárolóra, a Weblate használható Helyi fájlok módban is, amikor a tároló csak a Weblate-en belül létezik.

Tárolók frissítése¶

Érdemes beállítani valamilyen módszert a háttérrendszeri tárolók frissítésére az eredeti forrásból.

Használhatja a Értesítési hookok funkciót, hogy integrálódjon a legnépszerűbb kódtároló szolgáltatásokkal:
A működéshez a projektben is engedélyezni kell a Hookok engedélyezése funkciót.
Indítson frissítést manuálisan a tároló kezelőfelületén vagy az API vagy Weblate kliens használatával
Engedélyezze az AUTO_UPDATE beállítást, hogy automatikusan frissítse az összes összetevőt a Weblate példányában
Futtassa a updategit parancsot (egy adott projekt kiválasztásával vagy a --all opcióval az összes projekt frissítéséhez)

Amikor a Weblate frissíti a tárolót, a frissítés utáni kiegészítők is automatikusan lefutnak, lásd: Kiegészítők.

Ütközések (merge conflict) elkerülése¶

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:

Ütközések elkerülése azzal, hogy a fordítási fájlokat kizárólag Weblate-ben szerkeszti
Ütközések elkerülése Weblate zárolásával külső módosítások idejére
Ütközések elkerülése Git műveletekre fókuszálva

Ütközések elkerülése azzal, hogy a fordítási fájlokat kizárólag Weblate-ben szerkeszti¶

Ha elkerüli a Weblate-en kívüli módosításokat, különösen egynyelvű fájlok esetén, akkor az új szövegeket közvetlenül a Weblate-ben lehet hozzáadni, és a teljes fájlszerkesztés ott történhet. Kétnyelvű fájloknál általában valamilyen üzenetkinyerési folyamat állítja elő a lefordítható fájlokat a forráskódból. Ez sokszor két lépésre bontható:

Az első lépés során sablon (például gettext POT fájl) készül, például az xgettext programmal.
A második lépés a sablon összeolvasztása a meglévő fordításokkal (például a gettext PO-fájlok frissítése az msgmerge használatával).

A második lépést a Weblate-en belül is el lehet végezni, így biztosítva, hogy minden függő változtatás beépüljön a művelet előtt.

Ütközések elkerülése Weblate zárolásával külső módosítások idejére¶

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 to force Weblate to push all pending changes and lock the translation while you are doing changes on your side.

Az ilyen frissítési szkript például így nézhet ki:

# 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

Ha több összetevő osztozik ugyanazon a tárolón, mindegyiket külön zárolni kell:

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

Megjegyzés

A példa a Weblate kliens eszközt használja, amely API-kulcsokat igényel a Weblate távoli vezérléséhez. A Weblate kliens helyett bármilyen HTTP kliens (például curl) is használható, lásd: Weblate REST API.

Tároló-karbantartás¶

The Repository maintenance view shows repository status for a project, component, or translation and lets privileged users run maintenance operations from the user interface.

The same actions can also be triggered using Weblate REST API or, for the supported subset, Weblate kliens.

Availability of individual actions depends on permissions, the configured version control system, whether pushing is configured, and whether the selected object can be locked.

Művelet	What it does	Typical use
Commit	Commits pending changes stored in Weblate to the local repository.	Flush pending Weblate changes before doing repository work elsewhere.
Push	Pushes committed local repository changes to the configured upstream.	Send committed translations upstream when automatic push is disabled or delayed.
Update	Fetches upstream changes and integrates them using the component’s configured Egyesítési mód.	Bring Weblate in sync with upstream using the default integration strategy.
Update with merge	Fetches upstream changes and integrates them with an explicit merge.	Override the default merge style for a single update.
Update with rebase	Fetches upstream changes and rebases local Weblate commits on top of upstream.	Keep history linear when that matches your workflow.
Update with merge without fast-forward	Fetches upstream changes and creates an explicit merge commit even when a fast-forward would be possible.	Preserve merge commits for auditing or branch-management reasons.
Lock / Unlock	Prevents or allows translators to make further changes in Weblate.	Freeze translation changes while doing repository maintenance outside Weblate.
Reset and discard	Resets Weblate’s local repository to upstream and discards pending Weblate changes.	Use when upstream should overwrite the local Weblate repository state.
Reset and reapply	Resets Weblate’s local repository to upstream while preserving pending translations. See Reset and reapply recovery behavior.	Recover from diverged history while keeping pending Weblate translations.
Cleanup	Removes untracked files and stale branches from the local repository checkout.	Clean up leftover files or stale repository state in Weblate’s checkout.
Synchronize	Forces Weblate to write all known translations back to the repository files.	Repair cases where repository files became out of sync with the database state.
Rescan	Re-reads translation files from the local repository into Weblate.	Import file changes after manual repository work or file creation.

Reset and reapply recovery behavior¶

The Reset and reapply operation keeps pending translations from Weblate while resetting the local repository state to match upstream.

The operation can restore pending translations only when the target language files still exist after the reset or when Weblate can create them for the component, for example using a valid Sablon az új fordításokhoz.

If neither of these conditions is met, Weblate keeps the pending changes in its database and reports a recovery error instead of failing later with a generic parse error.

Ütközések elkerülése Git műveletekre fókuszálva¶

Még akkor is felléphetnek ütközések, ha csak a Weblate végzi a fordítási fájlok módosítását, például ha használja a Git véglegesítések összevonása kiegészítőt vagy ha a Egyesítési mód beállítása Rebase értékre van állítva, illetve ha Weblate-en kívül squash műveletet végez. (módosítási kérelmek (pull request) összevonása egy véglegesítésbe (commit)).

Ebben az esetben az ütközések oka más: a Weblate-ben történtek módosítások azután, hogy a Weblate véglegesítéseit már összevonták. Ez gyakran akkor fordul elő, ha az összeolvasztás nem automatizált, és napokig vagy hetekig manuális ellenőrzésre vár. Ilyenkor a Git nem tudja felismerni a Weblate változtatásait és megtagadja a rebase műveletet.

Ennek kezelésére vagy minimalizálni kell a Weblate-ben függőben lévő változtatások számát, amikor egy módosítási kérelmet (pull request) összevon vagy teljesen elkerülheti az ütközéseket azzal, hogy nem vonja össze a változtatásokat egyetlen véglegesítésbe (commitba) (azaz nem végez squash-olást).

Ennek kezelésére a következő lehetőségek állnak rendelkezésre:

Ne használja sem a Git véglegesítések összevonása kiegészítőt, sem a squash összeolvasztási módszert. Ezek a fő okai annak, hogy a Git nem ismeri fel a változtatásokat.
Hagyja, hogy a Weblate véglegesítse a függő változtatásokat még a módosítási kérelem (pull request) összeolvasztása előtt. Így a módosítási kérelem frissül az összes változással, és a két tároló szinkronban marad.
Használja a Weblate beépített felülvizsgálati funkcióit (lásd: Fordítási munkafolyamatok), így automatikusan összeolvaszthatja a GitHub módosítási kérelmeket (pull requests), amint a CI tesztek sikeresen lefutottak.
Használjon Weblate zárolást, hogy elkerülje a változtatásokat a GitHub módosítási kérelem (pull request) felülvizsgálata közben.

Lásd még

Weblate kliens

Változások automatikus fogadása a GitHubról¶

A Weblate natív támogatást nyújt a GitHubhoz.

If you are using Hosted Weblate, the recommended approach is to install the Weblate app. The app delivers GitHub notifications to Hosted Weblate, so you do not need to configure a separate Webhook in GitHub. It does not by itself grant Hosted Weblate write access to the repository, though. To push changes back, you still need to add the Hosted Weblate weblate GitHub user as a collaborator with write access, see Tárolók elérése a Hosted Weblate szolgáltatásból.

If you are not using the app, add the Weblate Webhook in the repository settings (Webhooks) to receive notifications on every push to a GitHub repository, as shown on the image below:

A Payload URL (adatküldési URL) a Weblate címe után /hooks/github/ útvonallal bővül, például Hosted Weblate esetén: https://hosted.weblate.org/hooks/github/.

A többi beállítás maradhat az alapértelmezett értékeken (a Weblate mindkét tartalomtípust kezeli, és csak a push eseményt használja).

Lásd még

Változások automatikus fogadása Bitbucket-ről¶

A Weblate támogatja a Bitbucket webhook-okat. Hozzon létre egy webhook-ot, amely a tárolóba történő feltöltés (push) eseményre indul, és amely a Weblate telepítésén a /hooks/bitbucket/ URL-re irányít (például https://hosted.weblate.org/hooks/bitbucket/).

Lásd még

Változások automatikus fogadása GitLab-ról¶

A Weblate támogatja a GitLab webhook-okat. Adjon hozzá egy projekt webhook-ot, amely a /hooks/gitlab/ URL-re mutat a Weblate telepítésén (például https://hosted.weblate.org/hooks/gitlab/).

Hibaelhárítás

Check GitLab webhook request history if webhooks are delivered.
The response payload contains information about matched components.

Lásd még

Változások automatikus fogadása Pagure-ról¶

A Weblate támogatja a Pagure webhook-okat. Hozzon létre egy webhook-ot, amely a /hooks/pagure/ URL-re mutat a Weblate telepítésén (például https://hosted.weblate.org/hooks/pagure/). Ezt az Activate Web-hooks menüpontban, a Project options alatt teheti meg:

Lásd még

Azure Repos: automatikus változásfogadás¶

A Weblate támogatja az Azure Repos webhook-okat. Hozzon létre egy webhook-ot a Code pushed (kód feltöltésre került) eseményre, amely a /hooks/azure/ URL-re mutat a Weblate telepítésén (például https://hosted.weblate.org/hooks/azure/). Ezt a Service hooks alatt, a Project settings résznél tudja beállítani.

Lásd még

Változások automatikus fogadása Gitea Repos-ról¶

A Weblate támogatja a Gitea webhook-okat. Adjon hozzá egy Gitea Webhook-ot a Push events (feltöltési) eseményre, amely a /hooks/gitea/ URL-re mutat a Weblate telepítésén (például https://hosted.weblate.org/hooks/gitea/). Ezt a tároló Settings részében, a Webhooks alatt lehet megtenni.

Lásd még

Automatically receiving changes from Forgejo Repos¶

Weblate has support for Forgejo webhooks, add a Forgejo Webhook for Push events event with destination to /hooks/forgejo/ URL on your Weblate installation (for example https://hosted.weblate.org/hooks/forgejo/). This can be done in Webhooks under repository Settings.

Lásd még

Változások automatikus fogadása Gitee Repos-ról¶

A Weblate támogatja a Gitee webhook-okat. Adjon hozzá egy WebHook-ot a Push (feltöltés) eseményre, amely a /hooks/gitee/ URL-re mutat a Weblate telepítésén (például https://hosted.weblate.org/hooks/gitee/). Ezt a tároló Management részében, a WebHooks alatt tudja megtenni.

Lásd még

Tárolók éjszakai automatikus frissítése¶

A Weblate éjszakánként automatikusan letölti a távoli tárolók frissítéseit, hogy a későbbi változások összeolvasztása gyorsabb legyen. Opcionálisan engedélyezheti az éjszakai összeolvasztást is az AUTO_UPDATE bekapcsolásával.

Változások feltöltése Weblate-ből¶

Minden fordítási összetevőhöz beállítható egy feltöltési URL (lásd: Tároló feltöltési URL), így a Weblate képes lesz visszaküldeni a módosításokat a távoli tárolóba. A Weblate alapértelmezetten minden véglegesítés után automatikusan feltölti a változásokat (lásd: Feltöltés véglegesítéskor (Push on commit)). Ha nem szeretné, hogy a feltöltés automatikus legyen, manuálisan is indíthatja a Tároló karbantartás alatt vagy az API-n keresztül, például a wlc push paranccsal.

A feltöltési lehetőségek a használt Verziókezelő integráció típusától függően változnak, részletesebben lásd az adott fejezetben.

In case you do not want direct pushes by Weblate, there is support for GitHub módosítási kérelmek (pull request), GitLab egyesítési kérelmek (merge request), Gitea módosítási kérelmek (pull request), Pagure egyesítési kérelmek (merge request), Azure DevOps egyesítési kérelmek (pull request) or Gerrit reviews, you can activate these by choosing GitHub, GitLab, Gitea, Gerrit, Azure DevOps, or Pagure as Verziókezelő rendszer in Összetevőkonfiguráció.

Összességében a következő lehetőségek érhetők el Git, Mercurial, GitHub, GitLab, Gitea, Pagure, Azure DevOps, Bitbucket Data Center és Bitbucket Cloud esetén:

Kívánt beállítás	Verziókezelő rendszer	Tároló feltöltési URL	Feltöltési ág
Nincs feltöltés (No push)	Git	üres	üres
Közvetlen feltöltés (Push directly)	Git	SSH URL	üres
Feltöltés külön ágra (Push to separate branch)	Git	SSH URL	Ágnév megadása (Branch name)
Nincs feltöltés (No push)	Mercurial	üres	üres
Közvetlen feltöltés (Push directly)	Mercurial	SSH URL	üres
Feltöltés külön ágra (Push to separate branch)	Mercurial	SSH URL	Ágnév megadása (Branch name)
GitHub módosítási kérelem külső másolatból (pull request from fork)	GitHub módosítási kérelmek (pull request)	üres	üres
GitHub módosítási kérelem saját ágról (pull request from branch)	GitHub módosítási kérelmek (pull request)	SSH URL [1]	Ágnév megadása (Branch name)
GitLab egyesítési kérelem külső másolatból (merge request from fork)	GitLab egyesítési kérelmek (merge request)	üres	üres
GitLab egyesítési kérelem saját ágról (merge request from branch)	GitLab egyesítési kérelmek (merge request)	SSH URL [1]	Ágnév megadása (Branch name)
Gitea egyesítési kérelem külső másolatból (merge request from fork)	Gitea módosítási kérelmek (pull request)	üres	üres
Gitea egyesítési kérelem saját ágról (merge request from branch)	Gitea módosítási kérelmek (pull request)	SSH URL [1]	Ágnév megadása (Branch name)
Pagure egyesítési kérelem külső másolatból (merge request from fork)	Pagure egyesítési kérelmek (merge request)	üres	üres
Pagure egyesítési kérelem saját ágról (merge request from branch)	Pagure egyesítési kérelmek (merge request)	SSH URL [1]	Ágnév megadása (Branch name)
Azure DevOps módosítási kérelem külső másolatból (pull request from fork)	Azure DevOps egyesítési kérelmek (pull request)	üres	üres
Azure DevOps módosítási kérelem saját ágról (pull request from branch)	Azure DevOps egyesítési kérelmek (pull request)	SSH URL [1]	Ágnév megadása (Branch name)
Bitbucket Data Center módosítási kérelem külső másolatból (pull request from fork)	Bitbucket Data Center módosítási kérelmek (pull request)	üres	üres
Bitbucket Data Center módosítási kérelem saját ágról (pull request from branch)	Bitbucket Data Center módosítási kérelmek (pull request)	SSH URL [1]	Ágnév megadása (Branch name)
Bitbucket Cloud módosítási kérelem külső másolatból (pull request from fork)	Bitbucket Cloud módosítási kérelmek (pull request)	üres	üres
Bitbucket Cloud módosítási kérelem saját ágról (pull request from branch)	Bitbucket Cloud módosítási kérelmek (pull request)	SSH URL [1]	Ágnév megadása (Branch name)

Megjegyzés

A Weblate-ben be lehet állítani, hogy minden véglegesítés után automatikusan töltse fel a változásokat; ezt a Feltöltés véglegesítéskor (Push on commit) beállítással lehet elérni.

Lásd még

SSH kulcsok beállításához lásd: Tárolók elérése, a Weblate véglegesítési döntéseiről pedig a Késleltetett véglegesítések (Lazy commits) szakaszban talál további információt.

Védett ágak (Protected branches)¶

Ha Weblate-et védett ágon használ, konfigurálható, hogy módosítási kérelmeken (pull request) keresztül történjenek a fordítások felülvizsgálatai (ez problémás lehet, ha a célnyelvet nem ismeri). Alternatív megoldásként felmentheti a Weblate-felhasználót ez alól a korlátozás alól, és közvetlenül feltöltheti a változtatásokat.

Például GitHub-on ezt a tároló beállításainál lehet megadni:

Kapcsolattartás másokkal¶

A Weblate egyszerűvé teszi az együttműködést az API használatával.

Lásd még

Weblate REST API

Késleltetett véglegesítések (Lazy commits)¶

A Weblate viselkedése az, hogy azonos szerzőtől származó módosításokat lehetőség szerint egyetlen véglegesítésbe vonja össze. Ez jelentősen csökkenti a véglegesítések számát, de ha a VCS (verziókezelő) tárolót szinkronban szeretné tartani (például összeolvasztás előtt), előfordulhat, hogy manuálisan kell kérni a véglegesítést. Alapértelmezés szerint ezt a Kezelők csoport teheti meg, lásd: Jogosultságok listája.

Ebben a módban a változtatások véglegesítése az alábbi esetekben történik meg:

Valaki más módosít egy már megváltoztatott szöveget.
Egy forráság (upstream) összeolvasztás történik.
Kifejezett kérés érkezik a véglegesítésre.
Fájlletöltés történik.
A változás régebbi, mint az összetevő beállításánál megadott Változások kora véglegesítéshez időszak.

Tipp

A véglegesítések minden összetevőhöz külön jönnek létre, tehát ha sok összetevője van, így is sok véglegesítést fog látni. Ilyenkor érdemes lehet a Git véglegesítések összevonása kiegészítőt használni.

If you want to commit changes more frequently and without checking of age, you can schedule a regular task to perform a commit. This can be done using Periodic Tasks in A Django adminisztrációs felület. First create desired Interval (for example 120 seconds). Then add new periodic task and choose weblate.trans.tasks.commit_pending as Task with {"hours": 0} as Keyword Arguments and desired interval.

Tároló kezelése szkriptekkel¶

A Weblate és a tároló közötti egyedi integrációkhoz a Kiegészítők használhatóak. További információért lásd: Parancsfájlok futtatása kiegészítőből, ahol bemutatjuk, hogyan lehet külső szkripteket végrehajtani kiegészítőkön keresztül.

Fordítások egységesítése összetevők között¶

Ha több fordítási összetevője van, érdemes lehet biztosítani, hogy az azonos szövegek ugyanazt a fordítást kapják. Erre többféle megoldás is létezik.

Fordítási terjesztés¶

Ha a Fordítások terjesztésének engedélyezése beállítás engedélyezve van (ami alapértelmezés szerint így van, lásd: Összetevőkonfiguráció), akkor az új fordítások automatikusan megjelennek minden olyan összetevőben, ahol a szövegek megegyeznek. Az ilyen módon terjesztett fordítások minden összetevőben a fordítást végző felhasználó nevéhez lesznek rögzítve.

Terjesztési előfeltételek:

Minden összetevőnek egyazon projekten belül kell lennie (az összetevők összekapcsolása önmagában nem elegendő).
Engedélyezze a Fordítások terjesztésének engedélyezése beállítást a megfelelő szövegek fordításainak automatikus újrahasznosításához.
Fontos: az egynyelvű fordítási formátumok esetében a kulcsoknak is egyezniük kell a fordítás terjesztéséhez, erre figyeljen a fordítási kulcsok létrehozásakor.
A szövegek csak fordítás közben kerülnek terjesztésre, a tárolóból betöltött szövegek nem terjednek tovább.

Javaslat

Ez a funkció jelenleg korlátozásokkal működik, és célunk annak általánosabbá tétele. Ossza meg véleményét a https://github.com/WeblateOrg/weblate/issues/3166 oldalon.

Konzisztencia-ellenőrzés¶

A Nem egységes ellenőrzés akkor jelez hibát, ha a szövegek eltérnek egymástól. Ez a funkció lehetőséget ad arra, hogy manuálisan felülvizsgálja az eltéréseket, és kiválassza a helyes fordítást.

Automatikus fordítás¶

Más összetevőkön alapuló automatikus fordítással szinkronban tartható a fordítások állapota az egyes összetevők között. Ez a folyamat manuálisan is elindítható (lásd: Automatikus fordítás) vagy automatikusan is lefuttatható a tároló frissítésekor kiegészítő segítségével (lásd: Automatikus fordítás).