I have tested this item ✅ successfully on 2ae0954

Patch ok for me

A questions.

1. Why in backend, the english and french tabs disappear? French and english languages are not a subset of All language?
2. Why in frontend, when the active language is fr-FR, the Article ALL not shown the custom field fr-FR? French language is not a subset of All language?

Why in backend, the english and french tabs disappear? French and english languages are not a subset of All language?

Nope, they are not.

Why in frontend, when the active language is fr-FR, the Article ALL not shown the custom field fr-FR? French language is not a subset of All language?

Nope.

Specific languages are not subset of All languages. Language ALL exists only for display.
Setting an item to ALL languages means that this item may display whatever the Active language.
Example: Modules or articles or categories, etc.

In the case of custom fields, their display should depend on the item language itself.
This is why a custom field tagged to ALL languages should display whatever the item language while custom fields tagged to a specific language should only display when the item language is tagged to the same specific language (which in that case corresponds to the active language).

A specific language (A) is a subset of all lanuguages (B):

If this is the final change It means that I will continue to use module to filter custom fileds

Do you want to rather get that?

If this is what you want, it can be done. It will mean that fields will show depending on the active language and no more on the item language.
In backend, all fields would display when editing for example an article tagged to ALL.

exactly, but it is only my opinion, I don't know if this is the right way.

@AlexRed
@ggppdk
@laoneo

Please give your opinion here.
The code would change this way:
add $app = JFactory::getApplication(); and then further

		if ($app->isAdmin())
		{
			if (JLanguageMultilang::isEnabled() && isset($item->language) && $item->language != '*')
			{
				self::$fieldsCache->setState('filter.language', array('*', $item->language));
			}
		}
		elseif ($app->isSite())
		{
			if (JLanguageMultilang::isEnabled() && isset($item->language))
			{
				$lang = JFactory::getLanguage()->getTag();

				if ($item->language = $lang || $item->language = '*')
				{
					self::$fieldsCache->setState('filter.language', array('*', $lang));
				}
			}
		}

I think there are arguments for all ways of displaying custom fields, we should be careful and not change behaviour because this can break sites. This needs to be B/C

Work for me

I would not filter the fields depending on of the language of this site. The problem is when you edit an article on the front which doesn't belong to the active language, the existing field data get erased of the fields which are not attached to the site language. Was that not the reason why #12656 was made? To have the same field on multiple languages with a translated label?

@laoneo
That only concerned fields labels and not their content and multilang filtering was not present in code at the time.
Deciding to tag fields by language and then filtering them has changed the situation which is very well described by the original poster in #18396
Basically, in fields.php, filtering is done the same way for site and admin, which was an error.
That's why we get, for an item tagged to ALL, fields tagged to all other languages than the active one or ALL.

result: for example in an article tagged to ALL, one could add a bunch of text in French in a custom field tagged to French and it would still show in French when the article is displayed in the site when en-GB is the active language.

My first solution may not have been the right one but the second proposal solves precisely that issue.

Also:
Using JText for labels is nevertheless extremely useful, and specially for fields tagged to ALL languages in frontend, but not only, because different languages may be available in backend (specially in multilang) which would require translation depending on the language used by the user.

Also

The problem is when you edit an article on the front which doesn't belong to the active language, the existing field data get erased of the fields which are not attached to the site language.

I tested here by editing a field set to ALL, therefore unrelated to the Active site language, and I have no issue because the content of the field depends on content entered in the article itself.
Compare this edited with screenshot above

So when you edit on the front the article "French Demo" which has the language fr-FR but the site language is set to de-DE. Will then the fields which belong to fr-FR also appear?

@laoneo
In native multilang, the French demo article tagged to fr-FR will just not display when site language (active language) is de-DE. This is the basics of multilang. One has to switch to fr-FR to edit it in frontend.
If is was tagged to "ALL" languages, it would display whatever the active language.

@laoneo
Let me explain again:

This PR (the original code or the one that I also proposed above) does not change the display or not of the custom field tagged to a specific language or ALL when the item language (article as example) has the same language as the custom field.
In that case, a custom field tagged to All will also display for that article.
That is perfectly OK.

The issue concerns ONLY an item/article tagged to ALL.
first proposal (the PR code): only custom fields tagged to ALL will display for an item (article in our case) tagged to ALL.
Second proposal (in my second proposal above): Custom fields tagged to ALL as well as tagged to the same language as the active language ( site language) will display for an article tagged to ALL.

@laoneo
Sorry to insist, but we do have a bug in multilang with custom fields and we should solve this.

We can't accept displaying in an article tagged to ALL the French tagged custom field when the Active language is English

If it belongs only for the automatic display events, then I would do the language filtering there. Where you have placed it affects all possible calls like getting them for the form, etc.
The display logic can be found here https://github.com/joomla/joomla-cms/blob/staging/plugins/system/fields/fields.php#L326.

@laoneo
Got it. would this be OK for you?
Adding after https://github.com/joomla/joomla-cms/blob/staging/plugins/system/fields/fields.php#L326

		if ($fields)
		{
			$app = Factory::getApplication();

			if ($app->isClient('site') && Multilanguage::isEnabled() && $item->language == '*')
			{
				$lang = $app->getLanguage()->getTag();

				foreach ($fields as $key => $field)
				{
					if ($field->language == '*' || $field->language == $lang)
					{
						continue;
					}

					unset($fields[$key]);
				}
			}
		}

That would display fields tagged to ALL and fields tagged to the active language only when an item is tagged to ALL.

EDIT: also make sure $item has a language

Guess this should work. I'm not so much into the multilanguage stuff as you, but it is the better place to make the language filtering.

OK. As I guess it is too late for 3.8.2 which is in code freeze, will make a new PR and close this one.
@AlexRed I think we are more inline with general multilang behavior this way than if we only display fields tagged to ALL in items also tagged to ALL.
It is quite easy to not fill the value of a field when editing an item tagged to ALL (which means to not set a default value in the field itself)
@ajejebrazorf01 please follow up. will call you both when PR is ready.

@laoneo
while I was going to delete this PR and create a new one with the code above (which works fine for articles and contacts, I wanted to test how custom fields behave for user.

I found out that their display is independent of the display method in
https://github.com/joomla/joomla-cms/blob/staging/plugins/system/fields/fields.php#L304
as deleting the whole method there has no impact.

they do show (without language filtering, even after my patch which code is added in that method) in registration and site edit profile.

Values can be entered for edit profile in frontend, but NOT for a registration where inputs are greyed.

Where shall I look for the language filtering for these?
Why are they greyed but still display when registration?

Screenshot when editing profile in frontend

Screenshot when registration

The problem is with users, that it is based on the form and makes some weird stuff here https://github.com/joomla/joomla-cms/blob/staging/components/com_users/views/profile/tmpl/default_custom.php to display the form fields instead of rendering them as every other extension does. Probably here https://github.com/joomla/joomla-cms/blob/staging/components/com_users/models/profile.php#L126 or here https://github.com/joomla/joomla-cms/blob/staging/components/com_users/models/profile.php#L182 you can set the language of the user and then the form should only load the fields with the right language.

The fields are probably grayed out because of permissions.

@laoneo Will look for lang filtering.

The fields are probably grayed out because of permissions.

Nope. Fields were set to Public. I changed that to Guest and same result.

@infograf768 if you set Permission of Field to "Allowed" it isn't greyed out anymore:

Thanks @franz-wohlkoenig mixed permissions and access...

@laoneo
I can solve the issue for lang filtering User fields in frontend, but I have to do the patch in fields helper in the getFields() method.

		if ($context == 'com_users.user')
		{
			$app = JFactory::getApplication();

			if ($app->isClient('site') && JLanguageMultilang::isEnabled())
			{
				$lang = $app->getLanguage()->getTag();
				self::$fieldsCache->setState('filter.language', array('*', $lang));
			}
		}

this will work for registration as well as profile.
Could not find a simpler way.

@infograf768 didn't test it, but you should be able to set the language on the passed data and you should be fine, no need to do such a workaround.

Indeed, I obtain the correct results if I add in models/profile.php
in the loadFormData() or getData() methods

		if (JLanguageMultilang::isEnabled() && empty($data->language))
		{
			$data->language = JFactory::getLanguage()->getTag();
		}

the problem is that it is OK when editing a profile but does not work for registration...

I can have a look on the profile issue when the rest is done. Lets try to do it in different steps.

ok, will do.

Closing this PR in favor of #18536

@@ajejebrazorf01
Please test #18536

Hello infograf768,

exactly this Problem persists on Custom-Fields for User-Registrations-Form:
I have 3x Languages on my Site and 3x Custom-Fields for each Language in Frontend, but all 3x Custom-Fields are showing on website on User-Registration Form.
It should shows just one Custom-Field for User-Registration per Language.
How can i fix this?

Best Regards

@matiaio Comments on closed Issues didn't get much Notice. Please ask help on the forums. This repository concerns in first Place Joomla-Core coding, thanks.

@matiaio
This is a known issue. See #18743 and why we closed that PR.

so this issue it will be included into a new Joomla! update? or should i modify some php files in my Website?

@infograf768

@infograf768 i am asking again, because i never used github. sorry

#18743 was closed. It means that the specific code to solve your issue will not be included in Joomla.