Subsurface 5.0.7 has been released

Sat Mar 26 16:25:27 PDT 2022

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 <charno at charno.ch> 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 <charno at charno.ch> wrote:
>>>>
>>>> Am 25.03.22 um 16:03 schrieb Dirk Hohndel:
>>>>>
>>>>>
>>>>>> On Mar 25, 2022, at 7:46 AM, Christof Arnosti <charno at charno.ch> 
>>>>>> 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
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20220327/8f1e80db/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 36JN75WJc1baOu0x.png
Type: image/png
Size: 16593 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20220327/8f1e80db/attachment-0001.png>