This means the strings are always translated using the correct domain,
regardless of which program libmalcontent-ui is used in.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This ensures that the translation domain is loaded for malcontent as
soon as the library is loaded.
The same is not needed for libmalcontent-ui, because it always causes
libmalcontent to be loaded.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Rather than application i18n functions and `#include`s. This ensures
that the correct translation domain is used.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When ordering commercial translations, at least one translator
translated these literally, eg "Sitio web de mal gusto" and
"créditos-de-traductor".
It's likely that translators familiar with GNOME would not make this
mistake, but let's be explicit anyway.
These translations are taken from the eos3.7 branch of
gnome-control-center. I apparently missed these when importing the last
batch in 39bdde5, I think due to the empty zh_TW.po file generated by
`ninja malcontent-update-po` being in some broken encoding that polib
can't read. I tried a different approach here:
- Copy the file from gnome-control-center
- `ninja malcontent-update-po`
- Manually remove fuzzy and obsolete translations
- `ninja malcontent-update-po`
Just add it as a dependency instead. It’s a lot less painful (git
submodules are still a pain to use; and `git evtag` doesn’t work well
with them); and libglib-testing has just done a 0.1.0 release which we
can depend on.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Debian Unstable now has libglib-testing packaged, which can be used to
avoid having to build it as a submodule. Otherwise, building on Debian
should be largely equivalent to building on Fedora.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: !3
Much of this code previously lived in Endless's fork of
gnome-control-center, and so many strings had previously been translated
there. I imported a bunch of them from
https://github.com/endlessm/gnome-control-center/tree/eos3.7 as follows:
cp ~/src/endlessm/gnome-control-center/po/LINGUAS po
ninja -C _build/ meson-malcontent-update-po
for x in po/*.po; do
t3k copy ~/src/endlessm/gnome-control-center/$x $x
done
ninja -C _build/ meson-malcontent-update-po
Then manually reviewed the output from t3k to exclude languages where
only trivial translations such as "Help" were copied.
Many of these translations are for OARS rating descriptions, which are
actually originally from gnome-software, and were imported into our
gnome-control-center in a similar way. I have long been sad that these
strings were not present in some common shared library; hooray! now they
are.
[t3k]: https://gitlab.gnome.org/wjt/translate-o-tron-3000/
This is a hack to allow `MctUserControls` to be used from `GtkBuilder`
templates, where it’s not possible to pass construct-only properties in
to the `MctUserControls` constructor. It’s not feasible to make
`MctUserControls:dbus-connection` not construct-only, because it gets
used to construct an `MctManager` which then subscribes to various
signals.
So for the cases where `MctUserControls` is used from a builder
template, the code has to connect to the system bus manually, which is
possibly (though unlikely) a blocking operation.
This fixes a critical warning when enabling parental controls in
gnome-initial-setup.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
WARNING: Project specifies a minimum meson_version '>= 0.49.0' but
uses features which were added in newer versions:
* 0.50.0: {'install arg in configure_file'}
When building without UI, there are no icon or desktop files so there is no need to run the commands to refresh the caches.
It would be even nicer to move the postinstall script to the malcontent-control subdirectory but it really applies to the installation output of the whole project, not just the malcontent-control part.
Without a GType for the error enum, g-ir-scanner fails to properly
associate it with the error quark function, and (for example) error code
matching in JS doesn’t work.
This adds the enum types in a new public header file.
Signed-off-by: Philip Withnall <withnall@endlessm.com>