Commit 9bf6bf98 authored by Ulrike Uhlig's avatar Ulrike Uhlig
Browse files

Merge branch 'master' of d53ykjpeekuikgoq.onion:tails

parents 164818fa 8ffe3ca9
......@@ -8,8 +8,8 @@ msgstr ""
"Project-Id-Version: Tails\n"
"Report-Msgid-Bugs-To: tails-l10n@boum.org\n"
"POT-Creation-Date: 2019-09-27 21:13+0000\n"
"PO-Revision-Date: 2019-08-17 12:26+0000\n"
"Last-Translator: Chre <tor@renaudineau.org>\n"
"PO-Revision-Date: 2019-10-01 17:23+0000\n"
"Last-Translator: xin <xin@riseup.net>\n"
"Language-Team: Tails translators <tails@boum.org>\n"
"Language: fr\n"
"MIME-Version: 1.0\n"
......@@ -577,34 +577,30 @@ msgstr ""
"openpgp_keys#sysadmins]])."
#. type: Plain text
#, fuzzy, no-wrap
#| msgid "<a id=\"tails-foundations\"></a>\n"
#, no-wrap
msgid "<a id=\"tails-translations\"></a>\n"
msgstr "<a id=\"tails-foundations\"></a>\n"
msgstr "<a id=\"tails-translations\"></a>\n"
#. type: Title -
#, fuzzy, no-wrap
#| msgid "tails-foundations\n"
#, no-wrap
msgid "tails-translations\n"
msgstr "tails-foundations\n"
msgstr "tails-translations\n"
#. type: Plain text
#, fuzzy, no-wrap
#| msgid "If you want to operate a Tails mirror, write to <tails-mirrors@boum.org>.\n"
#, no-wrap
msgid "To talk about the [[Tails translation platform|contribute/how/translate/with_translation_platform]], write to <tails-translations@boum.org>.\n"
msgstr "Si vous voulez administrer un miroir de Tails, écrivez à <tails-mirrors@boum.org>.\n"
msgstr ""
"Pour discuter de la [[plateforme de traduction de Tails|contribute/how/"
"translate/with_translation_platform]], écrivez à <tails-"
"translations@boum.org>.\n"
#. type: Plain text
#, fuzzy
#| msgid ""
#| "[[OpenPGP key|tails-foundations.key]] ([[details|doc/about/"
#| "openpgp_keys#foundations]])."
msgid ""
"[[OpenPGP key|tails-translations.key]] ([[details|doc/about/"
"openpgp_keys#translations]])."
msgstr ""
"[[Clé OpenPGP|tails-foundations.key]] ([[details|doc/about/"
"openpgp_keys#foundations]])."
"[[Clé OpenPGP|tails-translations.key]] ([[details|doc/about/"
"openpgp_keys#translations]])."
#. type: Plain text
#, no-wrap
......
......@@ -296,6 +296,8 @@ of forks, and follow the white GitHub rabbit(-hole):
from Trac to GitLab.
- They are considering using GitLab EE Ultimate, which includes
proprietary components.
- 2019-10-01 meeting: [agenda and notes](https://pad.riseup.net/p/e-q1GP43W4gsY_tYUNxf),
[logs](http://meetbot.debian.net/tor-meeting/2019/tor-meeting.2019-10-01-18.00.html)
* KDE migration to Gitlab:
- <https://gitlab.com/gitlab-org/gitlab-foss/issues/57338/designs>
- <https://gitlab.com/gitlab-org/gitlab/issues/24900>
......@@ -25,7 +25,7 @@ beginning of May.
- July 2019: muri
- August 2019: intrigeri
- September 2019: muri
- October 2019: u
- October 2019:
- November 2019:
- December 2019:
......@@ -135,8 +135,6 @@ Template
themselves, check the archives of tails-ux:
<https://lists.autistici.org/list/tails-XXX.html>
XXX: Use in Hong-Kong.
Hot topics on our help desk
===========================
......
......@@ -43,8 +43,6 @@ XXX: If you feel like it and the UX team does not do it
themselves, check the archives of tails-ux:
<https://lists.autistici.org/list/tails-XXX.html>
XXX: Use in Hong-Kong.
Hot topics on our help desk
===========================
......
......@@ -43,8 +43,6 @@ XXX: If you feel like it and the UX team does not do it
themselves, check the archives of tails-ux:
<https://lists.autistici.org/list/tails-XXX.html>
XXX: Use in Hong-Kong.
Hot topics on our help desk
===========================
......
......@@ -43,8 +43,6 @@ XXX: If you feel like it and the UX team does not do it
themselves, check the archives of tails-ux:
<https://lists.autistici.org/list/tails-XXX.html>
XXX: Use in Hong-Kong.
Hot topics on our help desk
===========================
......
......@@ -7,23 +7,24 @@ Git|contribute/how/translate/with_Git]]. This was a pretty high entry
barrier for new translators, especially those who are not familiar with
Git or the command line.
This is the technical design documentation of our setup.
This is the technical design documentation of our new setup.
It is by no means perfect. We track known issues via
[tickets on Redmine](https://redmine.tails.boum.org/code/projects/tails/issues?query_id=321).
We also provide a dedicated [[documentation for translators on how to use
Weblate|contribute/how/translate/with_translation_platform]] to contribute
translations.
We also provide dedicated [[documentation on how translators can use
Weblate|contribute/how/translate/with_translation_platform]] to
translate our website.
Terms used in this document
===========================
Terminology used in this document
=================================
- Canonical Git repository: the main Tails Git repository that our
website relies on, in scripts often called "main repository" or "main
- Canonical Git repository: the [[main Tails Git
repository|contribute/git#main-repo]] that our
website is built from, in scripts often called "main repository" or "main
Git"
- Production server: the server that hosts our website
- translate.lizard: the VM that hosts our Weblate web interface, the
corresponding Git repositories, as well as the staging website.
[Corresponding tickets on Redmine](https://redmine.tails.boum.org/code/projects/tails/issues?query_id=321)
corresponding Git repositories, as well as the [staging website](https://staging.tails.boum.org/).
Setup of our translation platform & integration with our infrastructure
=======================================================================
......@@ -31,27 +32,29 @@ Setup of our translation platform & integration with our infrastructure
We are using our own [Weblate instance](https://translate.tails.boum.org/).
Weblate uses a clone of the Tails main Git repository, to which
translations get committed, once they have been approved by a user with
translations get committed and pushed once they have been approved by a user with
reviewer status. Non-approved translations live on Weblate's database
only, until they get reviewed. A staging website allows translators to
only, until they get reviewed. A [staging website](https://staging.tails.boum.org/) allows translators to
preview non-reviewed translations in context.
Approved changes are automatically fed back into our canonical Git
repository. This presents a major challenge, indeed we need to ensure
repository. This presents a major challenge, because we need to ensure
that:
- no merge conflicts occur:
- No merge conflict occurs:
- such conflicts often occur on PO file headers which prevents Weblate
- such conflicts often occur in PO file headers which prevents Weblate
from automatically merging changes
- many contributors work on the same code base using different tools
(PO files can be edited by hand, using translation software such as
POedit, or they are generated by ikiwiki itself, which results in
Poedit, or they are generated by ikiwiki itself, which results in
different formatting)
- only PO files are committed.
- the committed PO files comply with shared formatting standards.
- no compromised code is introduced.
- Only PO files are committed.
- The committed PO files comply with shared formatting standards.
- No compromised code is introduced.
In order to integrate Weblate and the work done by translators into our
process, we have set up this scheme:
......@@ -61,11 +64,13 @@ process, we have set up this scheme:
Website and Weblate
-------------------
Our website uses ikiwiki and its PO plugin. It uses markdown files for
Our website uses ikiwiki and its [PO plugin](https://ikiwiki.info/plugins/po/).
It uses markdown files for
the English original language and carries a PO file for each translated
language. Thereby we distinguish languages that are activated on our
website from languages that have translations but are not yet activated
on the website because they do not [[cover enough of a portion of
on the website because they do not [[cover enough of
our core pages|contribute/how/translate/team/new/]] to be considered
usable.
......@@ -81,17 +86,18 @@ appear in the Weblate interface. For example, the component:
wiki/src/support.*.po
relates to the files support.mdwn, support.es.po, support.de.po, support.pot,
relates to the files `support.mdwn`, `support.es.po`, `support.de.po`, `support.pot`,
etc.
Repositories
------------
The repository used by Weblate is cloned and updated from the Tails main
repository, and its master branch. Changes generated on Weblate's copy
The repository used by Weblate is cloned and updated from the master
branch of the Tails main
repository. Changes generated on Weblate's copy
of the Tails main Git repository, located on the VM which hosts the
Weblate platform, are fed back to the Tails main repository, into the
master branch, automatically. This happens through a number of scripts,
Weblate platform, are automatically fed back to the master branch of
the Tails main repository. This happens through a number of scripts,
checks, and cronjobs that we'll describe below.
There are several languages enabled, some of them with few or no
......@@ -105,14 +111,14 @@ or added as a remote:
git clone https://translate.tails.boum.org/git/tails/index/
At the server the repository is located in
At the server the repository is located in:
~weblate/repositories/vcs/tails/index
Weblate can commit to its local repository at any time, whenever
translations get approved. Changes done in the canonical repository by
Tails contributors via Git and changes done in Weblate thus need to be
merged - in a safe place. This happens in an integration repository:
merged in a safe place. This happens in an integration repository:
~weblate/repositories/integration
......@@ -124,36 +130,37 @@ website:
Automatic merging and pushing
-----------------------------
The integration work between the different repositories is done by a
script which is executed on the VM hosting Weblate as [a cronjob every
5 minutes](https://git-tails.immerda.ch/puppet-tails/tree/manifests/weblate.pp). The script
[`cron.sh`](https://git-tails.immerda.ch/puppet-tails/tree/files/weblate/scripts/cron.sh)
has the following steps which we will explain:
The integration of changes from the different repositories is done by a
script which is executed on the VM hosting Weblate as [a cronjob](https://git-tails.immerda.ch/puppet-tails/tree/manifests/weblate.pp). The
[`cron.sh`](https://git-tails.immerda.ch/puppet-tails/tree/files/weblate/scripts/cron.sh) script
has the following steps which we will explain below:
1. Canonical → Integration:
Update the integration repository with changes made on the
canonical repository (called "main" in the script).
2. Make Weblate commit pending approved translations locally
2. Make Weblate locally commit any pending approved translation
3. Weblate → Integration:
Integrate committed changes from Weblate into the integration repository
4. Integration → Canonical:
Push up-to-date integration repository to canonical repository.
Push the up-to-date integration repository to the canonical repository.
5. Canonical → Weblate:
Pull from canonical and update the Weblate components.
Pull from the canonical repository and update the Weblate components.
6. Update Weblate's index for fulltext search
Whenever a contributor modifies a markdown (`*.mdwn`) file, and pushes
to master, the corresponding POT and PO files are updated, that is: the
Whenever a contributor modifies a markdown (`*.mdwn`) file and pushes
to master, the corresponding PO files are updated, that is: the
translatable English strings within those files are updated. This
update happens on the production server itself, when [[building the
wiki|contribute/build/website]] for languages that are enabled on the
production website.
update happens:
- on the production server itself, when [[building the
wiki|contribute/build/website]];
- only for languages that are enabled on the production website.
We need to ensure on the translation platform server, that PO files for
additional languages (that are enabled on Weblate but not on the
production website) are equally updated, committed locally, pushed to
production website) are equally updated, committed locally, and pushed to
the canonical Git repository. On top of this we need to update Weblate's
database accordingly, so that translations can be added for new or
database accordingly, so that translatable strings can be updated for new or
modified English strings in those files, in all languages.
### Step 1: Canonical → Integration
......@@ -163,72 +170,72 @@ repository**
The script fetches from the canonical (remote) repository and tries to
merge changes into the (local) integration repository. The merge
strategy used for this step is defined in [`update_weblate_git.py`](https://git-tails.immerda.ch/puppet-tails/tree/files/weblate/scripts/update_weblate_git.py): (XXX: Shouldn't this script be called update_integration_git.py according to this documentation?)
strategy used for this step is defined in [`update_weblate_git.py`](https://git-tails.immerda.ch/puppet-tails/tree/files/weblate/scripts/update_weblate_git.py):
When this script is executed, it merges changes in PO files based on
single translation units (`msgids`). Merge conflicts occur when the same
translation unit has been changed in the canonical and the integration
single translation units (`msgids`). A merge conflict occurs when the same
translation unit has been changed both in the canonical and the integration
repository (in the latter case, this would mean that the change has been
done via Weblate). In such a case, we always prefer the canonical
version. This makes sure that Tails developers can fix issues in
translations and have priority over Weblate.
Due to this procedure we never end up with broken PO files, however, we
Due to this procedure we never end up with broken PO files. However, we
may loose a translation done on Weblate.
Until here, only PO files of languages that are activated on our
production website will be merged, as the production website, i.e. the
canonical Git repository does not regenerate PO files of non activated
languages.
production website will be merged, as the production website
does not refresh PO files for languages that are not activated there,
so these PO files are outdated in the canonical Git repository at this point.
Because of this limitation of ikiwiki, once the activated language PO
files are merged, the script checks if PO files of additional,
non-production activated languages need updating. We do this by
generating POT files out of a PO file that we've previously defined as a
default language. We do this for all componenets. If the actual POT
file, generated on the production server differs from the POT file we've
files are merged, the script checks if PO files of other languages, that are not
activated in production, need updating. We do this by
generating POT files out of a PO file that we've previously defined as the
default language. We do this for all components. If the actual POT
file, generated on the production server, differs from the POT file we've
just created, then every additional language PO file needs to be
updated.
On top of this, if the PO file of the default language (that is, its
markdown file) have been renamed, moved or deleted, than the PO files of
additional languages need to follow this step.
Markdown file) has been renamed, moved, or deleted, then the PO files of
additional languages need to be accordingly renamed, moved, or deleted.
In summary, our script applies all changes detected on the default
language to the additional languages.
The described mechanisms always `touch` files and change metadata, such
as their `mtime`. That's why Git would always create a new commit for
such a change, but often those commits don't change the content of
files. In order to omit these empty unnecessary commits our script also
detects when a `fast-forward` is possible (the master branch is updated
to HEAD of either the canonical or the integration branch). If only
Weblate or only modifications on the canonical repository introduces new
commits, a fast-forward can be done.
With `python-git` creating a diff against working directory against the index
is very error-prone. But a diff between two commits works fine. That's why we
always create a new commit within the described script, but often those commits
don't change the content of any file. In order to omit these empty unnecessary
commits our script also detects when a `fast-forward` is possible (the master
branch is updated to HEAD of either the canonical or the integration branch).
If only Weblate or only modifications on the canonical repository introduces
new commits and the merge commit is empty, a fast-forward can be done, by a
force reset to the desired HEAD.
### Step 2: Trigger commits
Because Weblate tries to reduce the number of commits (aka. "lazy
commits"), we need to ask Weblate explicitly to commit every component
Weblate tries to minimize the number of commits (aka. "lazy
commits"), so we need to explicitly to ask Weblate to commit every component
which has outstanding changes since more than 24 hours.
This is done by triggering Weblate to commit pending approved
translations using the internal command ([`manage.py
commit_pending`](https://docs.weblate.org/en/weblate-2.20/admin/management.html#commit-pending)).
translations using the internal command ([`manage.py commit_pending`](https://docs.weblate.org/en/weblate-2.20/admin/management.html#commit-pending)).
### Step 3: Weblate → Integration
**Merging changes from Weblate's Git repository into the integration
repository**
Weblate's Git repository is not bare. Hence we need to pull changes
committed to Weblate's Git repository and merge them into the
integration repository. This is done by the script
[`merge_weblate_changes.py`](https://git-tails.immerda.ch/puppet-tails/tree/files/weblate/scripts/merge_weblate_changes.py).
The script fetches from the Weblate (remote) Git repository and tries to
merge changes into the (local) integration repository. The merge
strategy used for this step is defined in [`merge_weblate_changes.py`](https://git-tails.immerda.ch/puppet-tails/tree/files/weblate/scripts/merge_weblate_changes.py).
Changes already present in the integration repository are preferred over
the changes from the remote, Weblate repository. This is to allow fixes
done to PO files manually, via the canonical Git repository.
the changes from the remote, Weblate repository. This makes fixes
done to PO files manually, via the canonical Git repository, stick and propagate
to Weblate.
Again, PO file merges are done on translation units (`msgids`).
......@@ -242,65 +249,66 @@ that exists in canonical.
aka "production"**
After updating the Integration repository, we push the changes back to
Canonical aka puppet-git.lizard. After this the Canonical repository has
Canonical aka puppet-git.lizard. After this, the Canonical repository has
everything integrated from Weblate.
On the side of the canonical Git repository, gitolite has a special
hook,
[`tails-weblate-update.hook`](https://git-tails.immerda.ch/puppet-tails/tree/files/gitolite/hooks/tails-weblate-update.hook),
to make sure that Weblate is only allowed to push changes on PO files.
On the side of the canonical Git repository, a Gitolite hook
([`tails-weblate-update.hook`](https://git-tails.immerda.ch/puppet-tails/tree/files/gitolite/hooks/tails-weblate-update.hook))
makes sure that Weblate only pushes changes on PO files.
This hook also checks and verifies the committer of each commit, to make
sure only translations made on the Weblate platform are automatically
pushed, and no other changes than those on PO files accepted. Otherwise
pushed. Otherwise
the push is rejected, for security reasons.
### Step 5: Canonical → Weblate
**Integrating the changes made in the Canonical Git repository into
Weblate repository**
the Weblate repository**
After having merged changes from the canonical Git repository into the
integration Git repository, and integrated changes from Weblate there,
we can assume that every PO file now is up-to-date (in the Integration
and Canonical repository). Hence we can try to pull from the Canonical
repository using a fast-forward only (`git pull --ff-only`). The
we can assume that every PO file is now up-to-date, both in the Integration
and Canonical repositories. Hence we can try to pull from the Canonical
repository using a fast-forward only merge (`git pull --ff-only`). The
canonical and Weblate repositories may see new commits anytime. This
means: while our cronjob is running a new commit can be made. Then, a
new commit on one side (canonical or Weblate), prevents a
`fast-forward`. When this happens, the cronjob is run 5 minutes later
anew, and then step 1, 3 and 4 of the cronjob aim at fixing the cause of
anew, and then steps 1, 3 and 4 of the cronjob aim at fixing the cause of
why the fast-forward was not possible this time.
If the fast-forward was successful, we need to update Weblate's components
to reflect the modifications that happened on the side of Git, such as
If the fast-forward merge was successful, we need to update Weblate's components
to reflect the modifications that happened in Git, such as
string and file updates, removals, renames, or additions. This is
handled by another script:
[`update_weblate_components.py`](https://git-tails.immerda.ch/puppet-tails/tree/files/weblate/scripts/update_weblate_components.py).
Besides our scripts that modify the Weblate repository, Weblate itself
keeps creating commits and updates the master branch. That's why the
script is using an own Git remote named `cron` to keep track of which
script is using a dedicated Git remote named `cron` to keep track of which
commits need to be looked at for Weblate component changes. This remote
name is set in
[weblate.pp](https://git-tails.immerda.ch/puppet-tails/tree/manifests/weblate.pp)
and used in the cronjob `update_weblate_components.py
--remoteBranch=cron/master [...]`.
and used in the cronjob like this:
update_weblate_components.py --remoteBranch=cron/master [...]
### Step 6
Run [`manage.py
update_index`](https://docs.weblate.org/en/weblate-2.20/admin/management.html#update-index).
This updates Weblate's index for fulltext search. It is recommended by
Weblate upstream authors to run it every 5 mins.
Run [`manage.py update_index`](https://docs.weblate.org/en/weblate-2.20/admin/management.html#update-index).
This updates Weblate's index for fulltext search.
Weblate upstream authors recommend running it every 5 minutes.
<a id="staging-website"></a>
Staging website
---------------
### Goals
In order to allow translators to see their non committed suggestions as
well as languages which are not activated on https://tails.boum.org we
have put in place a [staging website](https://staging.tails.boum.org/) .
well as languages which are not activated on <https://tails.boum.org>, we
have put in place a [staging website](https://staging.tails.boum.org/).
It is a clone of our production website and is regularly refreshed.
On top of what our production website has, it includes:
......@@ -318,19 +326,15 @@ This allows:
- reviewers to check how translation suggestions look like on the
website, before validating them.
- check the sanity-check-website report:
[https://staging.tails.boum.org/last-sanity-errors.txt](https://staging.tails.boum.org/last-sanity-errors.txt)
### What is done behind the scenes to generate a new version of the staging website?
The cronjob
The
[`update-staging-website.sh`](https://git-tails.immerda.ch/puppet-tails/tree/files/weblate/scripts/update-staging-website.sh)
is run.
cronjob is run.
This cronjob calls a script that extracts suggestions from Weblate's
database and applies them to a local clone of Weblate's Git repository,
after having updated the clone with newer data from Weblate's VCS.
after having updated this clone:
[`save-suggestions.py`](https://git-tails.immerda.ch/puppet-tails/tree/files/weblate/scripts/save-suggestions.py)
After that we run `ikiwiki --refresh` using an dedicated `ikiwiki.setup`
......@@ -339,6 +343,12 @@ file for the staging website.
None of the changes on this repository clone are fed back anywhere and they
should not.
### Sanity checks
We automatically perform some sanity checks on this staging website.
The last report of these checks is published on
<https://staging.tails.boum.org/last-sanity-errors.txt>.
<a id="access-control"></a>
Access control on the Weblate platform
......@@ -380,7 +390,8 @@ Currently implemented proposal
- Every logged in user is in the `Users` group. Members of this group
are allowed to suggest translations but not to accept suggestions
nor to directly save new translations of their own.
nor to directly save new translations of their own. They can also
vote on suggestions.
- A reviewer, i.e. a member of the `@Review` group in Weblate, is
allowed to accept suggestions.
......@@ -438,10 +449,8 @@ Currently implemented proposal
Pending questions:
- Is the resulting UX good enough? Would it help if we allowed them
to vote up suggestions, even if this does not result in the
suggestion to be accepted as a validated translation?
(At the moment, suggestion voting is disabled.)
- Is the resulting UX good enough? Does the ability to vote up
suggestions helps sufficiently?
Machine translation
===================
......@@ -453,60 +462,50 @@ to the tmserver.
It is a very subtle way of increasing the quality of our translations.
It should give suggestions when you are translating, under the translation
window, tab 'Machine translation'.
It should give suggestions when one is translating, under the translation
window, in the _Machine translation_ tab.
We use tmserver for 'Machine translation'. You find the documentation
[here](https://docs.weblate.org/en/weblate-2.20/admin/machine.html#tmserver).
We use tmserver for machine translation ([upstream documentation](https://docs.weblate.org/en/weblate-2.20/admin/machine.html#tmserver)).
In order to update the suggestion we run
[`update_tm.sh`](templates/weblate/update_tm.sh.erb) via cronjob every month.
[`update_tm.sh`](https://git-tails.immerda.ch/puppet-tails/tree/templates/weblate/update_tm.sh.erb) via cronjob every month.
The tmserver can be queried like this [(see
`tmserver.service`)](manifests/weblate.pp):
`tmserver.service`)](https://git-tails.immerda.ch/puppet-tails/tree/manifests/weblate.pp):
<pre>
http://localhost:8080/tmserver/en/de/unit/contribute
</pre>
It should give suggestions when you are translating, under the translation
window, tab 'Machine translation'.
http://localhost:8080/tmserver/en/de/unit/contribute
Weblate administration
======================
- [[Enabling a new language|contribute/l10n_tricks#weblate-administration]]
- [[Enabling a new language|contribute/l10n_tricks#weblate-administration]]<br/>
Make sure to enable languages only if they are part of our tier-1
list or discuss the matter on the l10n-mailing list.
- Sysadmin: This documentation currently still lives in
translate-server.git and should be moved somewhere else.
[[!tails_ticket 15086]]
`translate-server.git` and might be moved somewhere else in the future
([[!tails_ticket 15086]]).
Manually fix issues
-------------------
We have our weblate codebase at
Our Weblate codebase is stored in `/usr/local/share/weblate`.
/usr/local/share/weblate
If commands have to be run, they should be run as user weblate (sudo -u weblate $COMMAND).
If commands have to be run, they should be run as the `weblate` user;
for example, with `sudo -u weblate COMMAND`.
However, this VM is supposed to run smoothly without human
intervention, so be careful with what you do and please document
modifications you make so that they can be fed back to puppet.git or other
places if necessary.
modifications you make so that they can be fed back to a more
appropriate place, such as our Puppet code or this document.
Reload translations from VCS and cleanup orphaned checks and suggestions
Reload translations from Git and cleanup orphaned checks and suggestions
------------------------------------------------------------------------
The following commands mayby run manually if something went wrong:
- Reload all translations from proper folder on disk (eg. in case you
did some updates in VCS repository) to components of weblate
`sudo -u weblate ./manage.py loadpo --all`
If something went wrong, we may need to ask Weblate to reload all
translations from Git, using the following command:
sudo -u weblate ./manage.py loadpo --all
Weblate installation and maintenance
====================================
......@@ -517,7 +516,7 @@ A hybrid approach
The Tails infrastructure uses Puppet to make it easier to enforce and
replicate system configuration, and usually relies on Debian packages to
ensure stability of the system. But the effort to maintain a stable
system somehow conflicts with installing and maintaining Weblate, a
system conflicts with installing and maintaining Weblate, a
Python web application, which requires using up-to-date versions of
<