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.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.