Foire aux questions¶
Configuration¶
Comment créer un flux de travail automatisé ?¶
Weblate can handle all the translation things semi-automatically for you. If you give it push access to your repository, the translations can happen without interaction, unless some merge conflict occurs.
Set up your Git repository to tell Weblate when there is any change, see Déclencheurs de notification for info on how to do it.
Set a push URL at your Configuration des composants in Weblate, this allows Weblate to push changes to your repository.
Turn on Pousser lors du commit on your Configuration des composants in Weblate, this will make Weblate push changes to your repository whenever they happen at Weblate.
Voir aussi
Comment accéder aux dépôts avec SSH ?¶
Please see Accès aux dépôts for info on setting up SSH keys.
How to fix merge conflicts in translations?¶
Merge conflicts happen from time to time when the translation file is changed in both Weblate and the upstream repository concurrently. You can usually avoid this by merging Weblate translations prior to making changes in the translation files (e.g. before running msgmerge). Just tell Weblate to commit all pending translations (you can do it in Repository maintenance in the Manage menu) and merge the repository (if automatic push is not on).
If you’ve already encountered a merge conflict, the easiest way to solve all conflicts locally on your machine, is to add Weblate as a remote repository, merge it into upstream and fix any conflicts. Once you push changes back, Weblate will be able to use the merged version without any other special actions.
Note
Depending on your setup, access to the Weblate repository might require authentication. When using the built-in Exportateur Git in Weblate, you authenticate with your username and the API key.
# Open an existing checkout of the upstream repository or perform a fresh one:
git clone UPSTREAM_REPOSITORY_URL
cd REPO
# Commit all pending changes in Weblate, you can do this in the UI as well:
wlc commit
# Lock the translation in Weblate, again this can be done in the UI as well:
wlc lock
# Add Weblate as remote:
git remote add weblate https://hosted.weblate.org/git/project/component/
# You might need to include credentials in some cases:
git remote add weblate https://username:APIKEY@hosted.weblate.org/git/project/component/
# Update weblate remote:
git remote update weblate
# Merge Weblate changes:
git merge weblate/main
# Resolve conflicts:
edit …
git add …
…
git commit
# Rebase changes (if Weblate is configured to do rebases)
git rebase origin/main
# Push changes to upstream repository, Weblate will fetch merge from there:
git push
# Open Weblate for translation:
wlc unlock
If you’re using multiple branches in Weblate, you can do the same to all of them:
# Add and update Weblate remotes
git remote add weblate-one https://hosted.weblate.org/git/project/one/
git remote add weblate-second https://hosted.weblate.org/git/project/second/
git remote update weblate-one weblate-second
# Merge QA_4_7 branch:
git checkout QA_4_7
git merge weblate-one/QA_4_7
... # Resolve conflicts
git commit
# Merge main branch:
git checkout main
git merge weblates-second/main
... # Resolve conflicts
git commit
# Push changes to the upstream repository, Weblate will fetch the merge from there:
git push
In case of gettext PO files, there is a way to merge conflicts in a semi-automatic way:
Fetch and keep a local clone of the Weblate Git repository. Also get a second fresh local clone of the upstream Git repository (i. e. you need two copies of the upstream Git repository: An intact and a working copy):
# Add remote:
git remote add weblate /path/to/weblate/snapshot/
# Update Weblate remote:
git remote update weblate
# Merge Weblate changes:
git merge weblate/main
# Resolve conflicts in the PO files:
for PO in `find . -name '*.po'` ; do
msgcat --use-first /path/to/weblate/snapshot/$PO\
/path/to/upstream/snapshot/$PO -o $PO.merge
msgmerge --previous --lang=${PO%.po} $PO.merge domain.pot -o $PO
rm $PO.merge
git add $PO
done
git commit
# Push changes to the upstream repository, Weblate will fetch merge from there:
git push
Comment traduire plusieurs branches simultanément ?¶
Weblate supports pushing translation changes within one Configuration du projet. For every Configuration des composants which has it turned on (the default behavior), the change made is automatically propagated to others. This way translations are kept synchronized even if the branches themselves have already diverged quite a lot, and it is not possible to simply merge translation changes between them.
Once you merge changes from Weblate, you might have to merge these branches (depending on your development workflow) discarding differences:
git merge -s ours origin/maintenance
Voir aussi
How to translate multi-platform projects?¶
Weblate supports a wide range of file formats (see Localization file formats) and the easiest approach is to use the native format for each platform.
Once you have added all platform translation files as components in one project (see Ajouter des projets et des composant de traduction), you can utilize the translation propagation feature (turned on by default, and can be turned off in the Configuration des composants) to translate strings for all platforms at once.
Voir aussi
How to export the Git repository that Weblate uses?¶
There is nothing special about the repository, it lives under the
DATA_DIR directory and is named vcs/<project>/<component>/. If you
have SSH access to this machine, you can use the repository directly.
For anonymous access, you might want to run a Git server and let it serve the repository to the outside world.
Alternatively, you can use Exportateur Git inside Weblate to automate this.
What are the options for pushing changes back upstream?¶
This heavily depends on your setup, Weblate is quite flexible in this area. Here are examples of some workflows used with Weblate:
Weblate automatically pushes and merges changes (see Comment créer un flux de travail automatisé ?).
You manually tell Weblate to push (it needs push access to the upstream repository).
Somebody manually merges changes from the Weblate git repository into the upstream repository.
Somebody rewrites history produced by Weblate (e.g. by eliminating merge commits), merges changes, and tells Weblate to reset the content in the upstream repository.
Of course you are free to mix all of these as you wish.
How can I limit Weblate access to only translations, without exposing source code to it?¶
You can use git submodule for separating translations from source code while still having them under version control.
Create a repository with your translation files.
Add this as a submodule to your code:
git submodule add git@example.com:project-translations.git path/to/translations
Link Weblate to this repository, it no longer needs access to the repository containing your source code.
You can update the main repository with translations from Weblate by:
git submodule update --remote path/to/translations
Please consult the git submodule documentation for more details.
How can I check whether my Weblate is set up properly?¶
Weblate includes a set of configuration checks which you can see in the admin
interface, just follow the Performance report link in the admin interface, or
open the /manage/performance/ URL directly.
Voir aussi
Why are all commits committed by Weblate <noreply@weblate.org>?¶
This is the default committer name, configured by
DEFAULT_COMMITER_EMAIL and DEFAULT_COMMITER_NAME.
The author of every commit (if the underlying VCS supports it) is still recorded correctly as the user that made the translation.
For commits where no authorship is known (for example anonymous suggestions or
machine translation results), the authorship is credited to the anonymous user
(see ANONYMOUS_USER_NAME). You can change the name and e-mail in the
management interface.
Voir aussi
How to move files in the repository without losing history in Weblate?¶
To keep the history, comments, or screenshots linked to strings after changing the files location you need to ensure that these strings are never deleted in Weblate. These removals can happen in case the Weblate repository is updated, but the component configuration still points to the old files. This makes Weblate assume that it should delete all the translations.
The solution to this is to perform the operation in sync with Weblate:
Verrouiller le composant dans Weblate.
Valider et fusionner les modifications en attente dans le dépôt.
Disable receiving webhooks the Configuration du projet; this prevents Weblate from immediately seeing changes in the repository.
Do any needed changes in the repo (for example using git mv), push them to the upstream repository.
Change the Configuration des composants to match the new setup; upon changing configuration, Weblate will fetch the updated repository and notice the changed locations while keeping existing strings.
Unlock the component and re-enable hooks in the project configuration.
Indication
Sauvegarde au niveau Projet might be useful to perform prior to such disrupting changes.
Utilisation¶
Comment relire les traductions des autres ?¶
There are several review based workflows available in Weblate, see Flux de travail de traduction.
You can subscribe to any changes made in Notifications and then check others contributions as they come in by e-mail.
There is a review tool available at the bottom of the translation view, where you can choose to browse translations made by others since a given date.
Voir aussi
How do I provide feedback on a source string?¶
On context tabs below translation, you can use the Comments tab to provide feedback on a source string, or discuss it with other translators.
How can I use existing translations while translating?¶
Toutes les contributions dans Weblate peuvent être utilisées grâce au mémoire de traduction partagé.
Vous pouvez importer un fichier de mémoire de traduction existant dans Weblate.
Use the import functionality to load compendium as translations, suggestions or translations needing review. This is the best approach for a one-time translation using a compendium or a similar translation database.
You can set up tmserver with all databases you have and let Weblate use it. This is good when you want to use it several times during translation.
Another option is to translate all related projects in a single Weblate instance, which will make it automatically pick up translations from other projects as well.
Weblate fait-il la mise à jour des fichiers de traduction en plus des traductions ?¶
Weblate essaie de limiter au minimum les modifications des fichiers de traduction. Pour certains formats de fichiers cela pourrait conduire à un reformatage. Si vous souhaitez garder le fichier formaté à votre façon, veuillez utiliser pour cela une accroche avant le commit.
Voir aussi
De où viennent les définitions des langues et comment puis-je ajouter la mienne ?¶
The basic set of language definitions is included within Weblate and Translate-toolkit. This covers more than 150 languages and includes info about plural forms or text direction.
You are free to define your own languages in the administrative interface, you just need to provide info about it.
Voir aussi
Can Weblate highlight changes in a fuzzy string?¶
Weblate supports this, however it needs the data to show the difference.
For Gettext PO files, you have to pass the parameter --previous to
msgmerge when updating PO files, for example:
msgmerge --previous -U po/cs.po po/phpmyadmin.pot
For monolingual translations, Weblate can find the previous string by ID, so it shows the differences automatically.
Why does Weblate still show old translation strings when I’ve updated the template?¶
Weblate does not try to manipulate the translation files in any way other than allowing translators to translate. So it also does not update the translatable files when the template or source code have been changed. You simply have to do this manually and push changes to the repository, Weblate will then pick up the changes automatically.
Note
It is usually a good idea to merge changes done in Weblate before updating translation files, as otherwise you will usually end up with some conflicts to merge.
Comment traiter le renommage des fichiers de traduction ?¶
When renaming files in the repository, it can happen that Weblate sees this as removal and adding of the files. This can lead to losing strings history, comments and suggestions.
To avoid that, perform renaming in following steps:
Lock the translation component in Gestion du dépôt du VCS local.
Commit pending changes in Gestion du dépôt du VCS local.
Merge Weblate changes to the upstream repository.
Disable receiving updates via hooks using Activer les points d’ancrage.
Réaliser le renommage des fichiers dans le dépôt.
Update the component configuration to match new file names.
Enable update hooks and unlock the component.
Indication
Sauvegarde au niveau Projet might be useful to perform prior to such disrupting changes.
Dépannage¶
Requests sometimes fail with « too many open files » error¶
This happens sometimes when your Git repository grows too much and you have many of them. Compressing the Git repositories will improve this situation.
The easiest way to do this is to run:
# Go to DATA_DIR directory
cd data/vcs
# Compress all Git repositories
for d in */* ; do
pushd $d
git gc
popd
done
Voir aussi
When accessing the site I get a « Bad Request (400) » error¶
This is most likely caused by an improperly configured ALLOWED_HOSTS.
It needs to contain all hostnames you want to access on your Weblate. For example:
ALLOWED_HOSTS = ["weblate.example.com", "weblate", "localhost"]
Voir aussi
What does mean « There are more files for the single language (en) »?¶
This typically happens when you have translation file for source language. Weblate keeps track of source strings and reserves source language for this. The additional file for same language is not processed.
In case the translation to the source language is desired, please change the Langue source in the component settings. You might want to use English (Developer) as a source language, or utilize Passerelle pour la qualité des chaînes sources.
Si le fichier de traduction de la langue source n’est pas nécessaire, veuillez le supprimer du dépôt.
Si le fichier de traduction de la langue source est nécessaire, mais qu’il doit être ignoré par Weblate, veuillez ajuster le Filtre sur la langue pour l’exclure.
Indication
You might get similar error message for other languages as well. In that case the most likely reason is that several files map to single language in Weblate.
This can be caused by using obsolete language codes together with new one
(ja and jp for Japanese) or including both country specific and
generic codes (fr and fr_FR). See Analyse des codes de langue for
more details.
Fonctionnalités¶
Does Weblate support other VCSes than Git and Mercurial?¶
Weblate currently does not have native support for anything other than Git (with extended support for Requêtes de fusion GitHub, Gerrit and Subversion) and Mercurial, but it is possible to write backends for other VCSes.
You can also use Assistants distants Git in Git to access other VCSes.
Weblate also supports VCS-less operation, see Fichiers locaux.
Note
For native support of other VCSes, Weblate requires using distributed VCS, and could probably be adjusted to work with anything other than Git and Mercurial, but somebody has to implement this support.
De quelle manière Weblate crédite-t-il les traducteurs ?¶
Toute modification faite dans Weblate est validée dans VCS avec le nom du traducteur. De cette manière toute modification élémentaire a son propre auteur, et vous pouvez la suivre en utilisant les outils VCS standard dont vous vous servez pour le code.
De plus, lorsque le format du fichier de traduction prend cela en charge, les entêtes des fichiers sont mis à jour pour inclure le nom du traducteur.
Pourquoi Weblate force l’affichage de tous les fichiers PO dans une seule arborescence ?¶
Weblate a été conçu de sorte à ce que chaque fichier PO soit représenté comme un seul composant. C’est bénéfique pour les traducteurs, afin qu’il sachent ce qu’ils sont en train de traduire.
Modifié dans la version 4.2: Les traducteurs peuvent traduire l’ensemble des composants d’un projet dans une langue spécifique.
Pourquoi Weblate utilise-t-il les codes de langue tels que sr_Latn ou zh_Hant ?¶
Ce sont les codes de langue définis par la RFC 5646 pour indiquer d’une meilleure façon qu’il s’agit de langues réellement différentes au lieu des précédents modificateurs mal utilisés (pour les variantes de @latin) ou pour les codes de pays (pour le chinois).
Weblate comprend encore les anciens codes de langue et les traduit en codes actuels - par exemple sr@latin sera utilisé en tant que sr_Latn ou zh@CN pour zh_Hans.
Note
Weblate defaults to POSIX style language codes with underscore, see Définitions de langue for more details.