Subsurface 5.0.7 has been released

Dirk Hohndel dirk at hohndel.org
Sat Mar 26 14:29:56 PDT 2022


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 <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/20220326/1cd130a8/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/1cd130a8/attachment-0001.png>


More information about the subsurface mailing list