lookit / lookit-api

Codebase for Lookit v2 and Experimenter v2. Includes an API. Docs: http://lookit.readthedocs.io/
https://lookit.mit.edu/
MIT License
10 stars 18 forks source link

Rhodri/Sho broken link issue? #973

Open mekline opened 2 years ago

mekline commented 2 years ago

Seen during the MBAH zoom call 5/30 -

This page on the Japanese version of the site: https://lookit.mit.edu/ja/studies/c3dc8dc6-ee80-4399-afba-d852225712ae/

Clicking the blue button (participate now) leads to an XML error:

This XML file does not appear to have any style information associated with it. The document tree is shown below.

AccessDenied Access denied.
Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object.

May also appear at this link: https://lookit.mit.edu/ja/studies/c3dc8dc6-ee80-4399-afba-d852225712ae/095c1558-56ab-4d1d-94e8-16082e51c300/

becky-gilbert commented 2 years ago

This 403 Access Denied error is described in the GCP docs here: https://cloud.google.com/storage/docs/troubleshooting#access-denied Here's the solution from the docs:

Check that your credentials are correct. For example, if you are using gsutil, check that the credentials stored in your .boto file are accurate. Also, confirm that gsutil is using the .boto file you expect by using the command gsutil version -l and checking the config path(s) entry.

Assuming you are using the correct credentials, are your requests being routed through a proxy, using HTTP (instead of HTTPS)? If so, check whether your proxy is configured to remove the Authorization header from such requests. If so, make sure you are using HTTPS instead of HTTP for your requests. I'm not sure why it would be specific to the Japanese version of the site.

@okaycj any suggestions/guidance? If not I'll try to work through the above checks.

okaycj commented 2 years ago

@becky-gilbert So it looks like any link that forcefully translated (adding the language to the URL) doesn't work.

Examples:

If you remove the language from the URL, the link works.

Example:

Still unsure of the solution.

mekline commented 2 years ago

What is the expected behavior here? @rhodricusack might be able to chime in - once a participant clicks "participate" (or relevant translated text) to launch the Lookit study player, are there expected differences between languages? Another way to ask this would be whether you (Rhodri) have also been working on changes to https://github.com/lookit/ember-lookit-frameplayer

mekline commented 2 years ago

If not, then @okaycj @becky-gilbert the expected behavior should be "launch experiment builder with no difference in regard to language, then exit the experiment builder back to a link with the same language setting/URL as before"

But in the future the expected behavior (in need of serious scoping!!!!!) would be "launch experiment builder, using language-specific parameters to [[some currently unspecified set of changes]], then exit the experiment builder back to a link with the same language setting/URL as throughout"

rhodricusack commented 2 years ago

I think the desired behaviour is to launch ember to use the appropriate language, so that the lookit template pages are translated using the ember yaml translation files. I'm not sure how ember determines which language it should use!

becky-gilbert commented 2 years ago

Thanks for clarifying @rhodricusack!

@okaycj @mekline Fortunately ember-lookit-frameplayer will translate at runtime rather than hardcoding in the build. At the moment, translations can be set by the researcher by adding the language parameter to the first frame. This means that currently researchers can get translated versions of their experiments by:

  1. Hard-coding a language value into their study protocol (useful if recruiting speakers of one particular non-English language, but not useful for running a single study with different translations), or
  2. Using a protocol generator function to dynamically set the first frame's language value based on the information passed to the generator function: child and pastSessions.

For the protocol generator function, the child object contains languageList (languages child is exposed to), and the pastSessions object contains demographicsSnapshot, which I assume contains information about the child's country. So that information could be used to dynamically set the first frame's language value, which should translate the study.

If the protocol generator solution doesn't cover all of the use cases that are needed here, then we could provide a 3rd option to researchers:

  1. Automatically translate the study based on the locale code in the Lookit site's URL.

I can think of two approaches to adding this feature:

  1. Add the locale from the Lookit site URL into the information stored in pastSessions, so that the researcher has access to it via the protocol generator function and can use it to dynamically set the language value for the first frame.
  2. Add the locale from the Lookit site URL as a query parameter sent to the study URL, so that the ember-lookit-frameplayer can pick it up and automatically set the study's language. In this case, the researcher would not need to use a protocol generator function. And we would need to set this up so that a language value set by the researcher would take precedence over the query parameter value.

Either way, we'll need the lookit-api to strip the locale out of the study URL or set up redirection so that participants are always sent to the same study URL, which will fix the GCP broken link issue (unless you disagree @okaycj?).

If you could let me know your thoughts then I'll break up this into separate issues.

rhodricusack commented 2 years ago

Thank you @becky-gilbert! I think that the most desirable behaviour would be to use the site URL rather than the child's registered language, so that they receive a coherent experience. Otherwise, I worry about a sudden switch of language, the reason for which may not be entirely obvious. It sounds like this could be implemented through a protocol generator.

I have a question about the XML translation layer for ember. We've been translating the text for the templates. Do you know if there is any mechanism where we might be able to translate text for our own studies as well? Or should we handle that either with different versions of the studies (with a risk of divergence) or something in a protocol generator?

rhodricusack commented 2 years ago

@becky-gilbert @okaycj @mekline (1) Would be able to fix the dead link issue, as we can't move forwards without this? (2) We will then use the protocol generator (as described in last message) to switch the frame language based on the URL (haven't done this yet - but presume it should be reasonably straightforward). (3) Don't worry about the JSON ember mechanism - I can imagine this will be complex, so we will just create a different experiment per language

becky-gilbert commented 2 years ago

Hi @rhodricusack, sorry for not keeping you posted on this. I created issue #1000 for the broken study links (but not the automatic translation of the studies themselves, which is the other piece of this issue), and hopefully fixed the study link problem in PR #1008. I just need to do some testing on the staging server before it gets moved to production. I'm sorry this has been holding you up and will let you know as soon as it's fixed!

rhodricusack commented 2 years ago

Thank you very much!

Get Outlook for Androidhttps://aka.ms/AAb9ysg


From: Becky Gilbert @.> Sent: Tuesday, August 9, 2022 11:16:49 PM To: lookit/lookit-api @.> Cc: Rhodri Cusack @.>; Mention @.> Subject: Re: [lookit/lookit-api] Rhodri/Sho broken link issue? (Issue #973)

Hi @rhodricusackhttps://github.com/rhodricusack, sorry for not keeping you posted on this. I created issue #1000https://github.com/lookit/lookit-api/issues/1000 for the broken study links (but not the automatic translation of the studies themselves, which is the other piece of this issue), and hopefully fixed the study link problem in PR #1008https://github.com/lookit/lookit-api/pull/1008. I just need to do some testing on the staging server before it gets moved to production. I'm sorry this has been holding you up and will let you know as soon as it's fixed!

— Reply to this email directly, view it on GitHubhttps://github.com/lookit/lookit-api/issues/973#issuecomment-1209946767, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAL7HSNUHCNJBOIVMLJPFIDVYLKFDANCNFSM5XOKPUFQ. You are receiving this because you were mentioned.Message ID: @.***>

mekline commented 2 years ago

Just to expand on this, your points above are in line with what we're doing for this update - the links themselves should function once this hits production!

For the Ember translations, you are right that you should use the protocol generator - this is an area where we predict that different researchers will want different things, so you should expect to explicitly set the intended language for a study like this using the conditional logic you want (rather than needing to maintain parallel studies with different languages). You can do this based on the child's information (e.g. child and pastSessions objects). @becky-gilbert can you clarify whether this update includes storing the locale info from the URL so it's accessible to generateProperties as well? If not, we'll make a separate issue for that additional functionality.

becky-gilbert commented 2 years ago

@mekline no, this update doesn't include that piece of the problem, because I wanted to fix the broken study links ASAP. I've created a separate issue for storing the locale and adding it to the info passed to generateProperties: #1013.

becky-gilbert commented 2 years ago

@rhodricusack sorry for the delay in finding a fix for this. We've just pushed an update to the production server (PR #1023) that should fix the broken link part of this issue. Now if you visit a translated version of the Lookit site (with a locale in the URL, e.g. https://lookit.mit.edu/ja/studies/c3dc8dc6-ee80-4399-afba-d852225712ae/) then you should be able to start the study after clicking the Participate Now / Preview Now button.

I'm going to leave this issue open because we still haven't dealt with the other part of this issue, which is linking the Lookit site locale/translation information to the Ember study so that the study can be presented in the same language (e.g. by storing the locale value in the pastSessions information and using that to set the language parameter via a protocol generator function).