Subsurface 5.0.7 has been released

[Christof Arnosti]

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/20220326/17f2be13/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/20220326/17f2be13/attachment-0001.png>