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

Integráció a Weblate-tel describes basic ways to integrate your development with Weblate. Kódtároló-integrációk lists provider-specific setup steps for common code hosting sites.

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)).
Changes are pushed back to the upstream repository (see 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.

Use Értesítési hookok to integrate with the majority of common code hosting services, see Kódtároló-integrációk. You must also Hookok engedélyezése for this to work.
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)).

The reason for merge conflicts is different in this case. Weblate can have new local commits after you merge earlier Weblate commits upstream. This typically happens if merging is not automated and changes wait for days or weeks for a human review. Git is then sometimes no longer able to identify upstream changes as matching the Weblate ones and refuses to perform a rebase.

Squash merging Weblate changes makes this harder to recover from. A squash merge creates a new commit instead of preserving the individual Weblate commits in the upstream history. Weblate still has the original commits in its local repository, and Git can no longer prove that upstream already contains them. If the conflict was also resolved manually, the file contents can differ from both repositories, so Weblate can keep failing to update even after the pull request was merged upstream.

If upstream no longer contains Weblate commits because they were squash merged, updating the repository might not be enough. Use Reset and reapply from Repository maintenance to reset Weblate to upstream while keeping pending translations; see Reset and reapply recovery behavior. Use Reset and discard only when upstream should fully replace Weblate’s local changes.

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:

Do not use Git véglegesítések összevonása or squash merging for Weblate changes. Squashing is why Git might no longer recognize the changes after merging.
When resolving conflicts outside Weblate, merge the Weblate commits with a regular merge commit and push that result upstream. Do not squash merge the conflict-resolution pull request.
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

Code hosting notifications¶

Provider-specific app and webhook instructions for GitHub, GitLab, Bitbucket, Pagure, Azure Repos, Gitea, Forgejo, and Gitee are covered in Kódtároló-integrációk.

Provider-specific notifications¶

These legacy anchors are kept for compatibility. Current provider-specific app and webhook setup is documented in Kódtároló-integrációk.

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¶

Each translation component can have a push URL set up (see Tároló feltöltési URL), and in that case Weblate will be able to push changes to the remote repository. Weblate can also be configured to automatically push changes on every commit, see Feltöltés véglegesítéskor (Push on commit).

For the push options table and provider-specific pull, merge, and review request workflows, see Változások feltöltése Weblate-ből.

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