Currently translations can be imported without a proper header

[psmits1567]

With GlotPress you can translate originals for your locale. When you export lines from a project, it contains a header with several lines of info
One of them is the locale.
However if you import translated originals, you can do that without this header. I have experienced large import containing translations for a different locale. That causes a lot of work, to reject them all, and unnecessary records in the already huge database.

One solution would be to only accept imports with a proper header containing the locale. If the locale does not match the locale of the project, then the import should fail.
That is the first and most easy step to implement a fix. I am aware that you still can import translations from a different locale, by setting the matching locale. But in that case we know who imported them, and can point out, that this is very wrong

[tobifjellner]

On the other hand, exporting and then importing may be the easiest way to reuse translations between locales, for instance from en_GB to en_AU (or between various Spanish locales).
It would be quite inconvenient if the user would need to edit the po in a text editor every time.

[psmits1567]

Toby, it will take little effort to edit the header. What currently is happening, makes me think to stop spending so much time in handling translations. It is not only the fact that imports are done in the wrong locale, also the increasing amount of imports done with the proper locale. They are all unchecked by a native speaker. So every effort to improve this process must be taken. We cannot omit the fact that AI is increasingly used to translate.