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 <[email protected]> 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 <[email protected] >>> <mailto:[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
