I'm not sure I entirely get this. We have `nn` translation indeed. We don't have `nb`. I am not sure how the locale selection is made for Norwegian (I guess when the configured language is either `no_NO` or `nb_NO`) as we rely on the system/on the gettext library to perform this step; but from your report I can *guess* that it falls back on `nn` if there's no `nb`.
The easy solution would be to just submit an `nb` translation I guess?
Please add `nb_NO`
This would require somebody contributing such a translation. And I would think it should be `nb` (without region) preferably (see below).
rename `nn` to `nn_NO`
Why? Is the translation we have really specific to the Norwegian variant of Nynorsk?
From research on my system there is *no* other common region for either `nb` or `nn`, and the norm seems to be not to add it:
| Language | Number of translations on my system | |--------|--------| | nb | 356 | | nn | 292 | | nb_NO | 10 | | nn_NO | 1 | | no | 4 | | no_NO | 0 |
Additionally, there's only 242 software that have both an `nb` and `nn` translations, which means there's 50 that don't provide an `nb` one. This doesn't mean anything relevant though, apart that most software that provide `nn` also provide `nb`.
and don't choose `nn_NO` in Geany if OS system language is set to `nb_NO`.
Again, I think that would likely solve itself if we had a `nb` translation.
Also, would it really be preferable to expose an untranslated UI rather than using the `nn` variant? I honestly don't know, but doesn't seem so likely from where I stand. If it's really the case though, you should raise the issue to the C/gettext library not to select it then.
---
Until I have more info, I feel like the only thing to do here is accept a new `nb` translation. We'll have to rely on user submission here, because none of "us" can write `nb` -- but we'd happily accept such a translation.