Weblate can handle all the translation things semi-automatically for you. If you will give it push access to your repository, the translations can live without interaction unless some merge conflict occurs.
See also
Please see Private repositories for information about setting up SSH keys.
The easiest way is to solve all conflicts locally at your workstation - simply add Weblate as remote repository, merge it into upstream and fix conflicts. Once you push changes back, Weblate will be able to use merged version without any other special actions.
# Add remote
git remote add weblate git://git.weblate.org/debian-handbook.git
# Update remotes
git remote update
# Merge Weblate changes
git merge weblate/master
# Resolve conflicts
edit ....
git add ...
...
git commit
# Push changes to upstream respository, Weblate will fetch merge from there
git push
Weblate supports pushing translation changes within one Project. For every Subproject which has it enabled (the default behavior), the change made is automatically propagated to others. This way the 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
There is nothing special about the repository, it lives under GIT_ROOT directory and is named as project/subproject/. If you have SSH access to this machine, you can use the repository directly.
For anonymous access you might want to run git server and let it serve the repository to outside world.
This heavily depends on your setup, Weblate is quite flexible in this area. Here are examples of workflows used with Weblate:
Of course your are free to mix all of these as you wish.
Weblate includes set of configuration checks, which you can see in admin interface, just follow Performace report link in admin interface or directly open /admin/performance/ URL.
Weblate uses Django sites framework and it defines site name inside the database. Please open admin interface and edit default site name and domain (you can do that directly at /admin/sites/site/1/ URL under your Weblate installation).
On context tabs below translation, you can use Source tab to provide feedback on source string or discuss it with other translators.
Weblate provides you several ways to utilize existing translations while translating:
See also
Weblate tries to limit changes in translation files to minimum. For some file formats it might unfortunately lead to reformatting the file. If you want to keep the file formattted in your way, please use pre commit hook for that.
For monolingual files (see Supported formats) Weblate might add new translation units which are present in the template and not in actual translations. It does not however perform any automatic cleanup of stale strings as it might have unexpected outcome. If you want to do this, please install pre commit hook which will handle the cleanup according to your needs.
Weblate also will not try to update bilingual files in any way, so if you need po files being updated from pot, you need to do it on your own.
Basic set of language definitions is included within Weblate and Translate-toolkit. This covers more than 150 languages and includes information about used plural forms or text direction.
You are free to define own language in administrative interface, you just need to provide information about it.
Weblate supports this, however it needs the data to show the difference.
For Gettext PO files, you have to pass 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.
This happens sometimes when your Git repository grows too much and you have more of them. Compressing the Git repositories will improve this situation.
The easiest way to do this is to run:
# Go to GIT_ROOT directory
cd weblate/repos
# Compress all Git repositories
for d in */* ; do
pushd $d
git gc
popd
done
See also
Depending on various conditions (frequency of updates, server restarts and other), fulltext index might get too fragmented over time. It is recommended to rebuild it from scratch time to time:
./manage.py rebuild_index --clean
See also
This is usually caused by concurrent updates to fulltext index. In case you are running multi threaded server (eg. mod_wsgi), this happens quite often. For such setup it is recommended to enable OFFLOAD_INDEXING.
See also
Whoosh uses temporary directory to build indices. In case you have small /tmp (eg. using ramdisk), this might fail. Change used temporary directory by passing as TEMP variable:
TEMP=/path/to/big/temp ./manage.py rebuild_index --clean
See also
Weblate does not have native support for anything else than Git, however Git is versatile system, which allows plugging in remote helpers for other VCS as well.
At this time, helpers for Bazaar and Mercurial (hg) are available within Git source code, they might be also included in your Git package. If this is not the case, you can download them manually and put somewhere in your search path (for example ~/bin). You also need to have installed appropriate version control programs.
Once you have these installed, you can use such remotes to specifi repository in Weblate.
To clone gnuhello project from Launchpad with Bazaar use:
bzr::lp:gnuhello
For hello repository from selenic.com with Mercurial use:
hg::http://selenic.com/repo/hello
Note
For native support of other VCS, Weblate requires distributed VCS and could be probably adjusted to work with anything else than Git, but somebody has to implement this support.
Every change made in Weblate is committed into VCS under translators name. This way every single change has proper authorship and you can track it down using standard VCS tools you use for code.
Additionally, when translation file format supports it, the file headers are updated to include translator name.
Weblate was designed in a way that every po file is represented as single subproject. This is beneficial for translators, that they know what they are actually translating. If you feel your project should be translated as one, consider merging these po files. It will make life easier even for translators not using Weblate.
Note
In case there will be big demand for this feature, it might be implemented in future versions, but it’s definitely not a priority for now.