Integrarea cu Weblate¶
Bazele Weblate¶
Structura proiectului și a componentelor¶
În Weblate, traducerile sunt organizate în proiecte și componente. Fiecare proiect poate conține un număr de componente, iar acestea conțin traduceri în limbi individuale. Componenta corespunde unui fișier traductibil (de exemplu GNU gettext PO (Portable Object) sau Resurse de șiruri Android). Proiectele au rolul de a vă ajuta să organizați componentele în seturi logice (de exemplu, pentru a grupa toate traducerile utilizate în cadrul unei aplicații).
Additionally, components within projects can be structured using categories. Components can belong to a category, and categories can be nested.
La nivel intern, fiecare proiect are în mod implicit traduceri ale șirurilor de caractere comune propagate în alte componente din cadrul acestuia. Acest lucru ușurează povara traducerilor repetitive și în mai multe versiuni. Propagarea traducerilor poate fi dezactivată pentru fiecare Configurația componentei folosind Permite propagarea traducerii în cazul în care traducerile ar trebui să fie divergente.
Repository integration¶
Weblate is built to integrate with upstream version control repository, Traducere continuă describes building blocks and how the changes flow between them.
Vezi și
Architecture overview describes how Weblate works internally.
User attribution¶
Weblate keeps the translations properly authored by translators in the version control repository by using name and e-mail. Having a real e-mail attached to the commit follows the distributed version control spirits and allows services like GitHub to associate your contributions done in Weblate with your GitHub profile.
This feature also brings in risk of misusing e-mail published in the version control commits. Moreover, once such a commit is published on public hosting (such as GitHub), there is effectively no way to redact it. Weblate allows choosing a private commit e-mail in Cont to avoid this.
Therefore, admins should consider this while configuring Weblate:
Such a usage of e-mail should be clearly described in service terms in case such document is needed. Legal can help with that.
PRIVATE_COMMIT_EMAIL_OPT_INcan make e-mails private by default.
Importing a localization project into Weblate¶
Weblate has been developed with VCS integration in mind as it’s core feature, so the easiest way is to grant Weblate the access to your repository. The import process will guide you through configuring your translations into Weblate components.
Alternatively, you can let Weblate set up a local-only repository containing all the translations without integration.
Preluarea traducerilor actualizate din Weblate¶
Weblate stores updated strings in a database and commits them to a local version-control repository. You can add a Weblate repository (when Exportator Git is turned on) as an additional remote repository and fetch translation updates from it.
Prior to this, you might want to commit any pending local changes made in Weblate (see Angajări leneșe). This can be done from the user interface (in the Repository maintenance), or from the command-line using Client Weblate.
Pushing changes can be automated if you grant Weblate push access to your repository and configure URL de încărcare depozitar in the Configurația componentei, see Împingerea modificărilor din Weblate.
Alternatively, use Weblate’s REST API to update translations so that they match the latest version from the upstream in your remote VCS repository.
Preluarea modificărilor de la distanță în Weblate¶
To fetch any strings recently updated in your remote VCS repository into Weblate, allow Weblate to pull from the upstream repository. This can be achieved in the user interface (in the Repository maintenance), or from the command-line using Client Weblate.
This can be automated by setting a webhook in your repository to trigger Weblate whenever there is a new commit. See Actualizarea depozitelor for more details.
If not using VCS integration, you can use the UI or Weblate’s REST API to update the translations so that they match your codebase.
Vezi și
Adăugarea de noi șiruri de caractere¶
If your translation files are stored in a remote VCS together with the code, you most likely have an existing workflow for developers to introduce new strings. Any way of adding strings will be picked up, but consider using Poartă de calitate pentru șirurile sursă to avoid introducing errors.
When translation files are separated from the code, the following ways can introduce new strings into Weblate.
Manually, using Add new translation string from Tools menu in the source language. You can choose between the radio buttons Singular and Plural inside the form. Select the appropriate form of the new translation string to be added.
Programatic, utilizând API
POST /api/translations/(string:project)/(string:component)/(string:language)/units/.Prin încărcarea fișierului sursă ca Înlocuiți fișierul de traducere existent (acest lucru suprascrie șirurile existente, așa că asigurați-vă că fișierul include atât șirurile vechi, cât și cele noi) sau Adaugați șiruri noi, consultați metoda de încărcare.
Notă
The ability to add strings in Weblate requires Gestionează șiruri.
Updating target-language files¶
For monolingual files (see Formate de fișiere acceptate), Weblate might add new translation strings present in the Fișier de limbă de bază monolingvă, and not in actual translations. It does not however perform any automatic cleanup of stale strings, as that might have unexpected results. If you still want to do this, please install the Curăță fișierele de traducere add-on, which handles cleanup according to your requirements.
Weblate will also not try to update bilingual files when the source changes,
so if you need po files to be updated from pot, do it yourself by
using Update source strings Metode de import, or by using
the Actualizare fișiere PO pentru a se potrivi cu POT (msgmerge) add-on.
Sugestie
Source string extraction tools, such as xgettext or lupdate, need to be executed outside of Weblate.
Introducing new strings¶
You can add new strings in Weblate with Gestionează șiruri turned on, but it is usually better to introduce new strings together with the code changes that introduced them.
Monolingual formats need to be configured so that new strings are added to Fișier de limbă de bază monolingvă. This is typically done by developers, as they write the code. You might want to use a review process of those strings using Poartă de calitate pentru șirurile sursă.
Bilingual formats typically extract strings from the source code using some tooling (like xgettext or intltool-update). Follow your localization framework documentation for instructions how to do that. Once the strings are extracted, there might be an additional step needed to update existing translations, see Updating target-language files.
Sugestie
Automating string extraction is presently out of scope for Weblate. It typically involves executing untrusted code what makes it more suitable for a generic continuous integration than localization-specific platform.
You might want to integrate this into your continuous integration pipelines to make new strings automatically appear for translation. Such pipeline should also cover Evitarea conflictelor de fuziune.
Managing the local VCS repository¶
Weblate stores all translations in its underlying version control repository. It is suggested to be connected to a remote one, but internal-only setup is also possible. The Repository maintenance allows controlling this repository.
Sugestie
With Traducere continuă, any changes are automatically pushed from the repository, so there is usually no need to manually manage it manually.
