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 <[email protected]> wrote: > > Am 25.03.22 um 16:03 schrieb Dirk Hohndel: >> >> >>> On Mar 25, 2022, at 7:46 AM, Christof Arnosti <[email protected] >>> <mailto:[email protected]>> 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
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
