Commit from Sugar Labs: Translation System by user samybt.: 395 of 395 messages translated (0 fuzzy).
Commit from Sugar Labs: Translation System by user cjl.: 95 of 395 messages translated (5 fuzzy).
Merge branch 'master' of github.com:sugarlabs/sugar
Merge branch 'master' of github.com:sugarlabs/sugar
Use the new toolkit unit test discover helper
Commit from Sugar Labs: Translation System by user cjl.: 398 of 398 messages translated (0 fuzzy).
Commit from Sugar Labs: Translation System by user cjl.: 398 of 398 messages translated (0 fuzzy).
Commit from Sugar Labs: Translation System by user cjl.: 398 of 398 messages translated (0 fuzzy).
Merge branch 'master' of github.com:sugarlabs/sugar
Commit from Sugar Labs: Translation System by user samybt.: 398 of 398 messages translated (0 fuzzy).
Bundle registry: Cleanup/clarify bundle installation

Management of bundle installs/upgrades was a mess, this attempts to
clean it up and sort it out.

It was not clear under which circumstances a bundle should be installed
via the bundle object vs via the bundle registry. The logical answer here
is that it should be done by the registry, so document why that is the case.

In bundleregistry, upgrade() seemed like it should be used for bundle
updates, but actually install() duplicated some of that logic in a slightly
different way. Touch up the upgrade logic in install(), remove upgrade(),
and add some documentation to make the situation clear.

The install() API differed between JournalEntryBundle, ActivityBundle and
ContentBundle. Eliminate the differences. JEB uid's are now stored at
initialization time, and the Bundle classes themselves choose the install
path (this does not vary when activities are installed this way).

The journal had two codepaths that dealt with activity installation/upgrade
(on arrival of the bundle in the datastore, and on resume)); unite them into
one and update for the above changes.
bundleregistry: Fix conflict between file monitoring and its own operations (#3707)

When an activity is installed via bundleregistry, it is effectively
registered twice: once by bundleregistry after installing it, and again
when the file operations monitor picked up the event.

This lead to error messages in the logs and occasional duplication
of activity icons in the home view.

Refactor the code slightly so that it is resilient and accepting that
some activities may try to be registered twice. To avoid the duplication
of icons, be more careful to only emit the bundle-added signal when we
really add the bundle.

Also clean up the installation of MIME types. The ActivityBundle class
does this, so there is no need for bundleregistry to do so.
Store content bundles in bundle registry

Previously, only activity bundles were maintained in the bundle registry.
Extend this to cover all kinds of "trackable" bundles, which in reality
just means the addition of content bundles.

This is needed in order to clean up the code and bundle API (as has happened
here) and to allow content bundle updates through the updater control
panel.
Move activity update code to jarabe.model

In preparation for implementing automatic/background activity updates,
move the code from an extension-specific model into jarabe.

The main update code is now in jarabe.model.update and the downloader
has been made generic and moved to jarabe.util.downloader. It now
downloads files into the temporary 'data' directory which is cleaned up
on every Sugar launch, avoiding leaving stale files around in failure
cases.
Push multiple PO files
Merge branch 'master' of github.com:sugarlabs/sugar
Push POT file
Revert "Push POT file"

This reverts commit 57de6045fdefa32f21c7857b2d57f43604774cd1.
Migrate sugar-install-bundle to sugar3 package.
Implement only the test target, not check

At the moment our tests requires to be run inside a clean
dbus/xvfb session, which is not always available where the
check target is used (for example in distcheck). Also when
running distcheck in buildbot we don't really want to run
tests again, since we just run them in the check step.

We might revisit this in the future but using a non standard
target is the easiest solution for now.