I'm using signup on a multilingual site.
When the same event is available in 3 languages via i18n, the signup list and count is by default only the number of signups for the event in the current language. Is it possible to list all people that have signed up for the event, whatever language they have submitted their signup?
The argument in the view signup_user_list seems to have only the option to select only one nid, not the translated versions.
Comments
Comment #1
creando sensaciones commentedHello
I have exactly the same problem. Did you found a solution?
Thanks
Achim
Comment #2
hansrossel commentedNo solution yet unfortunately...
Comment #3
dwwYeah, I have no idea how to solve this problem in general. It's not specific to views, it's a more wide-reaching problem. E.g. signup limits are also tied to a specific node ID, so the limits would be per-language, not per-event. ;)
I don't know enough about how i18n works. Does each translated node have a reference back to the "parent" node?
If so, it'd probably be possible to add code to signup so that whenever it's operating on a node, it checks if the node is a translation of another node, and if so, to basically operate on the other node instead. So, the signups would be entered into {signup_log} as belonging to the parent nid, not the translated nid. Similarly, all displays of signup data on the translated nids would have to pull data from the parent nid, etc.
That's probably going to be a lot of work. I have no need for this or interest in doing it all myself. If someone wanted to hire me to do so, that'd help change my mind. ;) Or, someone who was sufficiently skilled and motivated could try to get it working on their own and post the patch here. If it's a good patch and doesn't make signup hopelessly complicated, I'd probably commit it.
Sorry there's not a better answer here. :(
Good luck,
-Derek
Comment #4
daniel sanchez commentedSubscribing...
Dealing with same issue.
Comment #5
cyberwolf commentedThere is a property tnid, which is the translation source nid of the translation set.
I would be very interested to see becoming the signup module multilingual-aware, maybe I will write a patch.
Comment #6
creando sensaciones commentedI found a usefull workaround for my case.
We have about 20 different type of events which repeat with changing dates and prices. But the description and the fotos always stay the same.
So I have the "eventtype" contenttype which is translated. And then the "event"-contenttype which is a child node of the "eventtype"-sourcenode and just carrying the not translated data like date and price. The signups are made to the childnode. This is working perfect for me.
Comment #7
adraskoy commentedsubscribe
Comment #8
doublejosh commented+1