I didn't pay attention and entered the wrong flavor of Portuguese as the
parent translation. The one for Portugal is complete and should be the
parent, back-filling the one for Brazil where needed.
Suggested-by: Christof Arnosti <charno@charno.ch>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Many language have country specific differences. We recognize different
flavors of English (US, UK (and South Africa)), German (Germany and
Switzerland), and Portuguese (Brazil and Portugal). For many other
flavors of the languages that we have translations for we have no
support and the way we hard-coded the fallbacks in the past was odd and
meant that in the cases where we do have two flavors, missing strings in
one weren't taken from the other (English as the default language being
the exception).
This tries to do a better job of recognizing some of those parent
languages and loading translators for them, first. Which means if we
then find a translator for the specific language (i.e., de_CH), strings
missing in that translation are next searched in the parent language
(de_DE), before finally providing the source language string (en_US).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This function was not used anywhere. Moreover, remove a few
unused includes from qthelper.h. Surprisingly, a number of users
of qthelper.h depend on these, so readd them at the appropriate
places.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
As we switched to the qmake based build we now bundle the translations
via the Qt resource system instead of explicitly as Android assets. This
adjusts the code that opens the translations accordingly.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It turns out that contrary to what the documentation states, a few languages
are still only using the 'qt' translation. But those exist for all languages,
so we need to first search for the 'qtbase' translations, and only if that
fails do we try to load the 'qt' translations.
And even that will fail for languages in which Qt simply isn't localized (like
Dutch).
To make the code more readable, the check for 'US English' was moved earlier as
there is no point to look for a Qt translation for that (simply doesn't exist).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We were still using the 'qt' translations instead of 'qtbase' as we should have
been using since forever - it's a little unclear from reading the documentation
when in the Qt5 life cycle this happened, but definitely several years ago.
These are the strings used in situations where Qt already provides us with text
(e.g., the entries in the 'Subsurface' menu on Mac, or the button labels in
many dialogs).
Additionally we didn't try hard enough to find those translations in cases
where they are bundled with the app; so basically all scenarios except for
Linux distro specific packages or 'build from source' on macOS or Linux were
not going to work, even after addressing the qt->qtbase conversion.
But of course the developers pretty much all fall into those last two
categories. Still, I cannot believe we never fixed this in all those years...
To make it more obvious if we still aren't finding the Qt translations this
commit also makes that warning be shown in all cases, not just when running in
verbose mode.
Fixes#2954
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is pointless bike-shedding: instead of allocating the QTranslators
on the heap an assigning them to a variable at translation-unit scope,
we can simply generate them as static objects.
That makes
1) two fewer lines of code
2) the translator-resources are properly released when the application
closes.
Not that either of these points would make *any* difference.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The uiLanguage() function was used for two purposes: to initialize
the language related preferences and to read the current language.
To make things more easy to follow, split this function in two:
one for initializing, one for getting the current language.
Moreover, don't return the current locale in an out-parameter
as there is already a function to do that [getLocale()].
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Simply replace it with QLatin1String. There is a tiny performance penalty,
but none of that code would care.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I was reminded to do this when a user in French speaking Switzerland reasonably
suggested that fr_FR would be a much better fallback than en_US in their
situation.
Fixes: #2388
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Move the declarations of the "report_error()" and "set_error_cb()"
functions and the "verbose" variable to errorhelper.h.
Thus, error-reporting translation units don't have to import the
big dive.h header file.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
For unrecognized locales we use en_US by default. It makes much more sense for
South Africa to use en_GB.
Reported-by: Willem Ferguson <willemferguson@zoology.up.ac.za>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
remove use of SettingsObjectWrapper::
remove include of SettingsObjectWrapper.h
use qPrefFoo:: for setters and getters
replace prefs.foo with qPrefXYZ::foo() where feasible
(this expands to the same code, but gives us more control
over the variable).
Signed-off-by: Jan Iversen <jani@apache.org>
Disables the WindowContextHelpButtonHint by default on Qt::Sheet and
Qt::Dialog widgets. This hides the ? button on Windows, which only
makes sense if you use QWhatsThis functionality.
This value has been added in Qt 5.10.
Signed-off-by: Stefan Fuchs <sfuchs@gmx.de>
commit ec0511e824 ("ios: concentrate build dirs") moved the translations around
without updating the way they are accessed, causing our release 2.1.0 on iOS to
not be localized.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
helpers.h included qthelper.h and all functions declared in helpers.h
were defined in qthelper.h. Therefore fold the former into the latter,
since the split seems completely arbitrary.
While doing so, change the return-type of get_dc_nichname from
"const QString" to "QString".
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This was only done explicitly for Windows. Other platforms were
implicitly supposed to be UTF-8.
Suggested-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This is a change mainly for developers working on both mobile and
desktop application. As the current setup is that all preferences
are stored in one file (Subsurface.conf), for both mobile and desktop,
the unwary developer might get confused that the things tested on
mobile-on-desktop are not working on mobile-on-device. As we share
a lot of code between the desktop and the mobile code, also
our fairly extensive set of preferences play a significant role
in the inner workings of our applications.
So, this commit introduces an own preferences file for mobile
(on desktop) resulting in the preferences between the plain
desktop apllication now invisible to the mobile-on-desktop
application and vise versa. Making the mobile-on-desktop a
much more realistic test plaform for mobile development.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
This way in the en_US locale we no longer get shown the odd "dive(s)"
and instead get correct singular and plural forms.
Most of the patch is just a reindentation as it removes the if clause
that used to do the special case of NOT loading a translation for the
en_US case.
Right now we start with a trivial en_US translation file. My guess is
that this will be overwritten once we do the next round of "new strings,
new translations".
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
No point in having it defined in each main program's .cpp. Especially
since the unit tests don't define them.
Signed-off-by: Thiago Macieira <thiago@macieira.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is a feature that many people have asked for. This implementation is
somewhat simplistic because we simply use a different name for the
program settings - but interestingly enough this appears to be enough to
capture a lot of the core functionality that people are looking for in
multi-user support.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Having subsurface-core as a directory name really messes with
autocomplete and is obviously redundant. Simmilarly, qt-mobile caused an
autocomplete conflict and also was inconsistent with the desktop-widget
name for the directory containing the "other" UI.
And while cleaning up the resulting change in the path name for include
files, I decided to clean up those even more to make them consistent
overall.
This could have been handled in more commits, but since this requires a
make clean before the build, it seemed more sensible to do it all in one.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2016-04-04 22:33:58 -07:00
Renamed from subsurface-core/qt-init.cpp (Browse further)
