I have tested this item ✅ successfully on c3171fb

Thank you! The actual override behavior needled me a lot ;-)

I do understand why this has been proposed, but it is quite arbitrary.

For a monolanguage site
If the string is created for back-end, choosing the site default language would be quite counterproductive.
Let's not forget that a monolanguage site may have multiple languages installed to provide various UI languagess depending on the user choice.
A site with en-GB and de-DE installed, even if de-DE is the default language for frontend, can be displayed in admin (and site) in en-GB if a registered user have set such his preferences.

Also, this does not work at all on a multilingual site.
$this->default will always be en-GB.

I added here the code to var_dump stuff

protected function loadOverride()
	{
		$override = array();

		echo "So-called default site language ";
		var_dump($this->default);
		echo "language used on the page ";
		var_dump($this->lang);

		if ($this->lang !== $this->default)
[...]

I created a simple override for French site (which is my default site language in a multilingual site containing 3 content languages: fr-FR, it-IT, en-GB) and echoed it in Protostar.
OVERRIDE_STRING="Mon override special"

I get when French is used in frontend:
The override IS translated, but en-GB is considered as default.

For Italian :
The override is NOT translated. en-GB is considered as default, and language used on the page is at the same time fr-FR (because the override is set in fr-FR and your patch acts such) and it-IT...

For English

The override is NOT translated. en-GB is considered as default, and language used on the page is at the same time fr-FR (because the override is set in fr-FR) and your patch acts such) and en-GB...

Conclusion:
On a multilingual site, this would work ONLY if the override is created for en-GB site.
same issue in back-end as for monolanguage site

I have tested this item ? unsuccessfully on c3171fb

Set to unsuccessful for the reasons stated above.

@julienV
You may want to close this PR until you find another possible solution. In that case it will be easier to make a new PR.

ok sure