Subsurface 5.0.7 has been released

[Dirk Hohndel]

Hallo Christof

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').
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...

/D


> On Mar 26, 2022, at 4:25 PM, Christof Arnosti <charno at charno.ch> wrote:
> 
> 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 <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 <mailto: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 <mailto: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 <mailto: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 would be 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/79b23935/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/79b23935/attachment-0001.png>