Mentioned in #1801304-316: Add Entity reference field Task B.
Problem/Motivation
Cannot figure out how to add a context that will get default argument of nid's translation's language (from the url) and use that to filter a list of users by those users who have the same langcode in their account language setting.
Proposed resolution
?
Remaining tasks
It may not be possible. See what Tim or Daniel says.
User interface changes
N/A
API changes
N/A
Comments
Comment #1
YesCT CreditAttribution: YesCT commentedHere are notes from a poor first attempt:
maybe I dont want to list users. Maybe I want to list content, and then the language and then a relationship to users with that language?
Comment #2
dawehnerSo there is for sure a limit what views can do out of the box.
The approach with using somehow a listing of users and try to use default argument is the right approach, though we need a new default plugin which could be called "node language from url". I'm happy to write one of those plugins.
Comment #3
YesCT CreditAttribution: YesCT commented@dawehner if you write in words how to write a plugin like that, me or someone else can try and do the task. Maybe there is some documentation to point us to?
Comment #4
dawehnerJust a general question: Do you want to list all users, which have configured a certain langcode, which is the same as the langcode from the current node?
Comment #5
YesCT CreditAttribution: YesCT commentedYep.
Thinking back, I was testing the entity reference addition and wanted to see if with worked with multilingual.
I think I was imagining that I wanted to fill in some (reference) to a user, and wanted to use language to limit all the users on a site, to just those users with the same language (default language setting) in their account as the language of the node being edited.
But I imagine, that something similar would be involved in making a block of 5 users for display with a piece of content, if we wanted to limit the list of users to those that had selected the same language as the content was.
Comment #6
YesCT CreditAttribution: YesCT commentedActually, thinking more.. are users... do they have a "language" associated with the actual user, not their setting of what they want the default language of content to be is... but the language of the user thingy itself... like the language of the profile.
Say a user has a job title field. That user can write the name of their job title there, and translate it. So the 'user' itself might exist in one language and their might be translations of that user too.
We can probably come up with a reason to want to filter users by that kind of language also.
Comment #7
dawehner@yesct
Is this issue still relevant?
Comment #8
Gábor Hojtsy@YesCT: re #6, #2323939: Views user language field/filter is for original language code, no translation language field/filter added all user language fields to views also :)
Comment #9
YesCT CreditAttribution: YesCT commentedI went back again, and still could not figure out how to make a block of usernames whose preferred language was af, when viewing a translation of a node into af: af/node/1
"language of the content" seems to always be english... from the context? (views ui preview) maybe it is just the preview!
tried saving and viewing the block placed in the sidebar of a en node translated into af, and an af node translated into en
this exported block seems to work.
but does not use entity reference.
maybe I'm not sure how to use an entity reference view anymore... I'll think on it. for now. here is the view block export.
Comment #10
YesCT CreditAttribution: YesCT commentedI added an entity ref display view to the view, I added an entity ref field to the article content type, picked user, and selected the ER view for the field. but when editing node/1/edit (or af/node/1/edit) the ER field autocomplete does not complete, the spinny wheel does not spin.
Comment #23
LendudeReading back, #10 might have been a symptom of #2910501: Reference method "Views: Filter by an entity reference view" is broken or something like that, the entity reference field should work now.
I don't think you can build the requested View out-if-the-box, as @dawehner pointed out in #2 you would need a custom default argument plugin for that probably. But adding that seems like something we shouldn't do for this, seems a bit limited in scope to add to core.
Closing this as "won't fix" for now, feel free to open this back up if you think there is still value to changing something in core.
Thanks!