<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hallo Christof<br class=""><div><br class=""></div><div>Yes, we Qt isn't translated into all of the languages that Subsurface is translated into. So some of the 'standard' texts are missing (like 'Ok', 'Cancel', 'Save').</div><div>I've never tried to figure out if we could work around that, TBH. I'm sure we could just create our own limited translation files that we bundle with the app...</div><div><br class=""></div><div>/D</div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 26, 2022, at 4:25 PM, Christof Arnosti <<a href="mailto:charno@charno.ch" class="">charno@charno.ch</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div class=""><p class="">Thanks, Dirk!</p><p class="">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) :-)<br class="">
</p><p class="">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.</p><p class="">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).</p><p class=""><br class="">
</p><p class="">One thing I noticed: When I set the language to pt_*, I get the
following message when I start subsurface:</p><p class="">$ ./Subsurface.AppImage<br class="">
can't find Qt base localization for locale "pt-BR" searching in
"/tmp/.mount_Subsurpq0Kcw/usr/translations"<br class="">
$ ./Subsurface.AppImage<br class="">
can't find Qt base localization for locale "pt-PT" searching in
"/tmp/.mount_Subsur7l2t9d/usr/translations"</p><p class="">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?<br class="">
</p><p class="">Best<br class="">
Christof<br class="">
</p><p class=""><br class="">
</p>
<div class="moz-cite-prefix">On 26.03.22 22:29, Dirk Hohndel wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:775BED76-52B1-4083-91E9-7820281A2F1B@hohndel.org" class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
There's a new pull request that addresses this.
<div class=""><br class="">
</div>
<div class=""><a href="https://github.com/subsurface/subsurface/pull/3425" class="moz-txt-link-freetext" moz-do-not-send="true">https://github.com/subsurface/subsurface/pull/3425</a></div>
<div class=""><br class="">
</div>
<div class="">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 :)
<div class=""><br class="">
</div>
<div class="">/D<br class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On Mar 26, 2022, at 7:56 AM, Christof
Arnosti <<a href="mailto:charno@charno.ch" class="moz-txt-link-freetext" moz-do-not-send="true">charno@charno.ch</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
<div class=""><p class="">Sounds good! :-)</p><p class="">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?<br class="">
</p><p class="">Best<br class="">
Christof<br class="">
</p>
<div class="moz-cite-prefix">On 26.03.22 15:52, Dirk
Hohndel wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:8FEBD281-B93A-418E-80C5-6EB520F019A2@hohndel.org" class="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
OK, I did some more searching and I think there is a
clean solution - I'll try to implement this later
today.
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">Stay tuned :)</div>
<div class=""><br class="">
</div>
<div class="">/D<br class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On Mar 25, 2022, at 8:31 AM,
Christof Arnosti <<a href="mailto:charno@charno.ch" class="moz-txt-link-freetext" moz-do-not-send="true">charno@charno.ch</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div class="">
<div class="moz-cite-prefix">Am 25.03.22
um 16:03 schrieb Dirk Hohndel:<br class="">
</div>
<blockquote type="cite" cite="mid:A0FAAF77-D911-4F3D-A7EC-B725D0C181AD@hohndel.org" class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<br class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On Mar 25, 2022, at
7:46 AM, Christof Arnosti <<a href="mailto:charno@charno.ch" class="moz-txt-link-freetext" moz-do-not-send="true">charno@charno.ch</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
<div class=""><p class=""><font class="" face="Arial">Hi,</font></p><p class=""><font class="" face="Arial">So, I now get
where the problem with the
missing Strings is coming
from:</font></p><p class=""><font class="" face="Arial"><font class="" face="Arial">I'm using
German (Switzerland)
locale on my secondary
computer. </font>The
German (Germany) translation
is complete, but the German
(Switzerland) translation is
not. <br class="">
</font></p><p class=""><font class="" face="Arial">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).<br class="">
</font></p><p class=""><font class="" face="Arial">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"? <br class="">
</font></p>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">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.</div>
</div>
</blockquote>
<font class="" face="Arial">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?<br class="">
</font>
<blockquote type="cite" cite="mid:A0FAAF77-D911-4F3D-A7EC-B725D0C181AD@hohndel.org" class="">
<div class="">
<blockquote type="cite" class="">
<div class=""><p class=""><font class="" face="Arial">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 would</font><font class="" face="Arial"><font class="" face="Arial"> be</font>
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...</font></p>
<div class=""><br class="">
</div>
</div>
</blockquote>
<br class="">
</div>
<div class="">I agree. Again, I don't
think the infrastructure allows that.</div>
</blockquote><p class="">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...</p><p class="">Currently (before my
translation updates today) the context
menu of the dive list looks like this
for de_CH:</p><p class=""><img alt="" class="" apple-inline="yes" id="FBB9571E-8BB4-498C-B028-FC7FD3DE2086" src="cid:part1.GEjf4310.302kM9Ke@charno.ch"></p>
<blockquote type="cite" cite="mid:A0FAAF77-D911-4F3D-A7EC-B725D0C181AD@hohndel.org" class="">
<div class=""><br class="">
</div>
<div class="">/D</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</blockquote>
</div>
</div></blockquote></div><br class=""></body></html>