We have an our custom translation and just want to use it and only it, ignoring player languages.
Currently we can do that by removing any language files except for our, but plugin still tries to use the player language and every time floods the server logs with this useless (for us) warning:

[OpenInv] [LanguageManager] Missing translations from en_ca.yml: messages.error.consoleUnsupported, messages.error.lootNotGenerated, 
messages.error.invalidMaterial, messages.error.invalidNumber, messages.error.invalidPlayer, messages.error.permissionOpenSelf, messages.error.permissionEnderAll, 
messages.error.permissionExempt, messages.error.permissionCrossWorld, messages.error.permissionPlayerOnline, messages.error.permissionPlayerOffline, 
messages.error.commandException, messages.info.containerBlocked, messages.info.containerBlockedSilent, messages.info.containerSilent, 
messages.info.settingState, messages.info.player.noMatches, messages.info.player.matches, messages.info.container.noMatches, messages.info.container.matches, 
messages.info.true, messages.info.false, container.player, container.enderchest

Add ability to shut up the LanguageManager, please :D

Also plugin creates an empty and useless yml files in their folder every time I use the oi (player name) command, named en_ca, en_gb etc.

The goal of this functionality is to increase the quality of the user experience, not maximize the ease with which server administrators can force the user to to see a particular thing. This is effectively the same as a resource pack's .lang files, just server-side and easier to edit.

If by "floods" you mean "prints once per language per restart when a user attempts to access it" then that is intended behavior, a hint to you the administrator that your users could benefit from the missing translations being filled in. The empty files are intentionally created so you don't have to go back and forth trying to remember which languages are missing, especially if you happened to miss the single warning in the logs.

If you really want to force certain messages, stop deleting the other language files and copy in the contents of your custom translation. If you don't feel like copying your translations into each file and don't want to see messages about the missing keys, you can use a custom log4j2 configuration to filter messages out of your logs (though setting that up is arguably a lot more work than just copying some content twice). The only reason your approach works is because OI does not (yet) bundle those languages. As soon as OI bundles a language it will use that language's defaults over the default language.

I did think of a couple ways in which the LanguageManager can be improved over the course of this writeup, but overall the end result for you is the same, so I'm going to open a separate issue detailing that.

If you do something for others, then it seems to me that deciding for them how it will be better and more convenient for them is not a good idea ):

The system is modeled after how Mojang handles translations. The goal is to get as close to a seamless vanilla-style experience for users as possible without needing a resource pack. You can customize every vanilla message, but you'll have to edit every vanilla language in use by your users via a resource pack to do so.
If you don't want to do that and do want to enforce a certain UX, you could write a plugin to whitelist certain languages and kick users who don't use them.

You're also free to make any changes you like in your own fork. Removing all additional language files could be done fully automatically very easily with Github Actions, which would make the log4j2 filter option completely reliable. All you'd have to do is merge upstream updates every so often.
Alternately, instead of periodically merging upstream into a fork, you could write a simple script to unzip the jar, delete the offending files, and re-zip it. Run that every time you download a new build and you're set.

I talked to my team and we came to the conclusion that you are doing the right thing, and we need to do the same.
So I apologize for the time spent on me and thank you for creating & updating OI!

I appreciate the kind words. I know it's not a common tactic in Bukkit plugins, but I think that average user experience is king over making configurations less of a pain to work with.

In case anyone else has similar wants in the future and stumbles on this issue: This isn't something I am willing to invest my own time in, but I would accept a well-formed PR to add a language-overrides.yml or similar.