I really dont like the idea of solving this by hardcoding - it really feels like the wrong approach.
does the same problem occur if the access level for the language is anything but public eg special

@infograf768 is it possible to add a message to the user?

we change there settings with the code. I think we should inform there that we have do somthing like this.

Only like: It don't work that you set the languages as [selectet access level] so we change this to public

The problem with hardcoding the access level ID is that I can easily create another Guest type viewing access level, assign the language to that new group, and still have the issue. I have tested this. Unfortunately, I think that it needs to go deeper and check the actual access rights.

@betweenbrain

is it possible to check

if ($data['access'] != 1)
{
$data['access'] = 1;
}

but is it also possible to create a "new" public access level? (!= ID 1)

but is it also possible to create a "new" public access level? (!= ID 1)

Yes it is.

The basic issue is that any hard coded ID only works with the default groups. I believe the correct solution would be to check the actual access rights of the assigned group.

Thanks @betweenbrain

You're very welcome @zero-24 . If I get a chance to dig deeper into this, I will propose some code.

The problem isn't so much the guest viewlevel, the same would happen if you select registered or anything else than public. It's the missing default value for this field which causes the problem.
But simply adding the default value to the form xml doesn't solve it. It seems like something is missing in the formfield.

Ah no, I was wrong. Apparently there is a default value since it works for new languages.
What happens is that we have a value of 0 stored in the database, which is an invalid option (there is no such access level). If the value is 0, the default value is ignored since there is actually a value already.

Before https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_languages/models/language.php#L79 add this lines:

        // Set a valid accesslevel in case '0' is stored due to a bug in the installation SQL (was fixed with PR 2714).
        if ($table->access == '0')
        {
            $table->access = (int) JFactory::getConfig()->get('access');
        }

That should set the proper value for the access field in case it's stored as 0 (which isn't a valid value).

The original bug has been fixed by Michael with PR #2714

Thanks a lot! corrected the PR for that specific issue. Please test.

NOTE: remains an important issue to solve in the languagefilter plugin.
Indeed setting a default site Content Language (whether global or defined by user, which means ANY Content language de facto) as not Public may create issues and a loop when Language selection for new visitors (whether through Browser Settings or Default site Language) loads that language or when clicking on a web link.
This should be he object of new patch as we do not only have to test the access levels but define a redirection.