Thanks, Dirk!
I just downloaded the AppImage built by github actions, and it works
fine for me, including completely translated context menu for de_CH!
(althouth I didn't test anything beside opening the context menu) :-)
I had a short look in the code, and added a small comment to the PR
regarding Portuguese. Since pt_PT is complete I think the fallback
should be pt_PT instead of pt_BR.
I did set my language to pt_PT and pt_BR to test this, and it seems in
pt_BR about the same strings in the context menu are missing
(pluralisation).
One thing I noticed: When I set the language to pt_*, I get the
following message when I start subsurface:
$ ./Subsurface.AppImage
can't find Qt base localization for locale "pt-BR" searching in
"/tmp/.mount_Subsurpq0Kcw/usr/translations"
$ ./Subsurface.AppImage
can't find Qt base localization for locale "pt-PT" searching in
"/tmp/.mount_Subsur7l2t9d/usr/translations"
This does not happen for de_* or en_* (which are the other languages I
tested). I also noticed that the "Save" etc. buttons in the preferences
dialog are not translated for pt_*, this might be connected?
Best
Christof
On 26.03.22 22:29, Dirk Hohndel wrote:
There's a new pull request that addresses this.
https://github.com/subsurface/subsurface/pull/3425
English is special because en_US is always the fallback language. What
we have hard-coded, though, is that our South African friends get
British English :)
/D
On Mar 26, 2022, at 7:56 AM, Christof Arnosti <[email protected]> wrote:
Sounds good! :-)
if you're already implementing this, for Portuguese there are also
two translation sets (pt_PT/pt_BR) with different completeness...
Also en_GB/en_US? But I guess en_US is the source language, thus
maybe only the plurals are translated in en_US?
Best
Christof
On 26.03.22 15:52, Dirk Hohndel wrote:
OK, I did some more searching and I think there is a clean solution
- I'll try to implement this later today.
Qt indeed allows you to install multiple translations and will
search them "last to first". So if we special case de_CH to first
load de_DE and then load de_CH, we should get the intended behavior.
It's surprisingly hard to find any documentation for this - I would
have expected this to be something that a lot of people would like
to take advantage of.
Stay tuned :)
/D
On Mar 25, 2022, at 8:31 AM, Christof Arnosti <[email protected]> wrote:
Am 25.03.22 um 16:03 schrieb Dirk Hohndel:
On Mar 25, 2022, at 7:46 AM, Christof Arnosti <[email protected]>
wrote:
Hi,
So, I now get where the problem with the missing Strings is
coming from:
I'm using German (Switzerland) locale on my secondary computer.
The German (Germany) translation is complete, but the German
(Switzerland) translation is not.
I started copying the missing values from German (Germany) to
German (Switzerland), but it's a boring manual process (transifex
does not seem to provide bulk copying between two translated
languages), and I suspect that in the future for new strings the
same problem will arise. The difference between the two languages
is very small, and to be honest, German (Switzerland) is not a
very "relevant" dialect in the sense that people who can read
German (Switzerland) are guaranteed to also be able to read
German (Germany).
Before I continue my work: Would it be possible to have German
(Germany) as fallback language for German (Switzerland)? Thus, if
German (Switzerland) is selected, the order of strings would be
"German (Switzerland) -> German (Germany) -> English" instead of
"German (Switzerland) -> English"?
I don't know if THAT is possible. But I could trivially populate
all the strings in the Swiss translation with the de_DE strings
and have you just modify those that aren't the same. Would that
work for you. I'd be able to do that this evening (so maybe 12
hours from now) - I need to write a small script that does that
and then upload the changes to Transifex.
This script would be a great help! Is there any way that I can
quickly find the strings that were manipulated by your script
afterwards?
With this solution, a reasonable user experience would be
provided to German (Switzerland) users when Strings are updated,
and the German (Switzerland) translation is missing. For the few
strings that are different between German (Switzerland) and
German (Germany), they could be overwritten in the German
(Switzerland) translation. Maybe it wouldbe even better if German
(Switzerland) would only contain the few strings that are
different in the two dialects, so that Swiss users would also
automatically get German (Germany) translation improvements...
I agree. Again, I don't think the infrastructure allows that.
Hmm... If it's easy to test, what would happen if you change the
locale from "de_DE" to "de" for German (Germany)? I know some
translation libraries work with this hierarchy...
Currently (before my translation updates today) the context menu of
the dive list looks like this for de_CH:
/D
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
