User tests: Successful: Unsuccessful:
Filtering display of User fields by Active language and ALL
Profile, edit profile and registration should only display custom fields tagged to the same language as the Active language or tagged to ALL
Create a multilingual site (2 languages are enough)
Create User fields: 1 per language and 1 tagged to ALL
All user fields display, whatever the assigned language. Examples for English, the French tagged field also displays
etc.
Note: using the getData() method solves the filtering for profile display and edit, but not registration. See #18474 (comment)
Status | New | ⇒ | Pending |
Category | ⇒ | Administration com_fields |
Having a second look on it. I'm not sure honestly what to do with users. Guess we need to be clear what for a use case we want to fix with multilingual custom fields.
For example when somebody wants to display the actual user for an article in an override, then it can make sense to fill values for all languages, as the user can be displayed on different languages. Where do you have that issue @infograf768?
For example when somebody wants to display the actual user for an article in an override
Not sure what you mean. What would such an override display exactly?
Concerning Contacts in general (custom fields or not), in multilang, we have to
This screenshot shows that user's custom fields create a slider with no content when displaying a contact while contacts custom fields are already filtered correctly.
This with patch or not.
EDIT: I found out why custom fields may be added in contact ;) So that is unrelated.
Where do you have that issue @infograf768?
As explained by the test instructions, this PR concerns profile, profile edit and registration.
My question is what you want to do with the multilingual values of a user? So, assume a user edits is profile with the front end language French, according to your pr, only the french fields will be filled. Now you want to show that user in a contact page on your English version. The fields will not appear then because the user didn't fill them in English. He has also no chance to fill them.
Perhaps I do miss something, but for me is the user not connected to a language and has to fill all fields in all languages.
I understand what you mean but I doubt a registered user would be able to enter stuff in languages she/he would not know...
My usual multilang test site uses 7 content languages and I can write stuff correctly in 2 languages only.
The idea is that the user would rather edit her/his profile in the language he/she masters and enter nothing for the other languages (except if she/he does know what he/she is doing).
And would therefore switch in this case to the language concerned to fill the right fields, at least for the fields tagged to the active language.
If nothing is entered for a specific language then the field is not displayed.
Another issue I just remarked is that the user editing his profile has no way to know which custom field is tagged to a specific language which makes the feature non-usable in multilang except if we display the flag or lang code next to the rendered field label.
Note: Contacts are already filtering per Active language and ALL, as you can see in these screenshots, both for specific Contacts custom fields and Users custom fields
So, maybe we should rather concentrate on getting these User fields show a flag/langtag when editing profile and registration instead of this PR.
I think it would lead to confusion when the member is visiting in french she/he has to edit different custom fields than when she/he is visiting it in english for its profile.
I guess then that these Users Custom fields should never be used on a multilingual site (these for which value may change depending on language), except if set to ALL languages and label using language constants when label is displayed.
See #18817 which solves the translation of the label in Contacts display.
Closing this PR.
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-11-23 07:47:36 |
Closed_By | ⇒ | infograf768 | |
Labels |
Added:
?
|
I will have a look on registration, for me this is the wrong approach as the FieldsHelper class should not do special conditions for a specific context.