Remove region tags from translations that don't need them #5813
Conversation
|
These filenames must match the language tags that we have on Transifex, and there is unfortunately no way to change a language tag on Transifex (other than recreating the language from scratch, which makes us lose data) as far as I know. So even though I would like to change this, it seems problematic... I'll have to take a look later at how much data actually gets lost. I think it's something like keeping the translated strings but losing the associated history. |
|
Ah okay, let me know what you find out! |
|
Would symlinks work? A bit on the hacky side, but that would allow keeping the Transifex history. |
|
I think it would be simpler to add a script for renaming the files before and after syncing with Transifex. |
|
After receiving a request from one of the Danish translators to change da_DK to da a while ago, I looked into the Transifex situation more. It'll be possible to keep the current translation of each string but not the history for each string or any review marks, which probably is good enough. In order to check if the affected translators think that's good enough, I sent out a Transifex PM a few days ago telling them to raise objections before the end of the month if they have any. So if that time passes without any objections, let's change the language codes. We have to make sure that the language codes get updated in Dolphin and on the website too, though. So... @ligfx: Can you rebase this PR? @delroth: I'm not sure exactly what needs to be done on the website side, but could you take a look at it? The list of language codes that I'm planning to change is (not all of these are complete enough to have been included into Dolphin): hi_IN |
|
@JosJuice done |
The Danish, Malay, and Romanian translations all specify a region (Denmark, Malaysia, and Romania, respectively). I'm not a translator, so I'm not sure why they might be this way, but I'm going to put forward some arguments from a software perspective:
The language and region tags are not guaranteed to match up. macOS is possibly the weirdest here, since it generates tags like "da-US" (Danish as spoken in the United States). In these cases, the region probably doesn't matter, and we want to use the translation anyways.
To add some numbers to this, according to Debian's metrics the region-less tags are far more popular: ~480K strings are translated to "da", ~130K to "ms", and ~300K to "ro". Only ~8K are translated to each of "da_DK", "ms_MY", and "ro_RO".
These language are stored without the region tag when configured manually by the user from the interface pane.
Qt will refuse to match a region-less tag, like "da", against a language with a region tag, like "da-DK". It loosely follows RFC 4647 "Matching of Language Tags", which specifically notes that tags can be matched against less specific ones, but should not be matched against more specific ones.