-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Translations are being submitted with userId
values of null
#412
Comments
And, if possible, we should probably fix the current string files that have this problem. |
Below is a list of the string files that have at least one instance of
|
I've run some tests and looked through the code, and I have a preliminary hypothesis about why this is happening. The way the code is structured, when the user submits a translation, the client-side code requests the "website user data" from the server, then submits this data as part of the whole translation submission. However, I'm not seeing any handling in the client-side code of the case where the user's session has timed out. To test this theory out, I added a button to the admin page through which the user's login credentials could be logged to the dev tools console, then logged in, went to that page and waited for 15 minutes, then pressed the button. The request failed, which would seem to support this theory. I'll dig into this some more tomorrow, but if this is true we may need to consider another way of associating a submission with a user ID. |
I think this hypothesis is sound. I think there are 2 possible solutions. The first is that you can read the cookie The other solution is to just make the submission process more robust:
This solution would require either (a) implementing a login dialog in rosetta instead of using the sign-in page or (b) creating a callback page that can handle a submission after a redirect from the sign-in page. |
I have put a workaround in place that stores the user's ID in session storage and pulls it out and uses it if the user tries to publish a translation but the client code gets an indication that the session has expired. This isn't perfect, but I think it will work until we implement #413. As of this moment, this workaround is deployed on the live translation utility. I'll keep an eye on the logs to make sure we aren't seeing any indications of null user IDs. For reference, here are all of the build requests currently in Rosetta's server log, which starts on May 18. This gives us a sense of how frequently null user IDs were being used, which appears to be around once or twice a day on average.
|
Log check: We've had ~15 translation submissions since I put the workaround into place, and there are no instances of build request objects with null values for the |
I checked the logs again today and there are no instances of For reference, the last instance of a build object with
|
I've written some scripts to help with this. Here is the edited output of one of them that lists all translations with only
|
I discussed how to approach fixing up the translations with @kathy-phet. While it would be possible to comb through the login records from the website data and correlate this with translations submissions, it would be incredibly time consuming. We agreed on this following as a reasonable approach:
This may not be perfect, but I suspect that it will be pretty close, and far quicker to implement. |
Hey JB, I thought for the last use case (For any files that contain all null user IDs and for which multiple translators have worked in that locale, use the ID of the user who made the most recent contribution.) You were going to ask @solaolateju . |
Thanks for the reminder. I'll do that. Is it also worth checking in with @DianaTavares on some of the es-related locales with multiple translators with recent activity? |
Yes. Thanks. |
Once the user IDs are fixed, the following sims will need to be rebuilt to make sure the translation credits are correct on the website.
|
I've updated all cases of null user IDs for locales where there was only ever a single translator. This addressed 15 translation files, and I rebuilt 11 sims as a result (some of the files were for common code, which don't require a rebuild). Here are the files:
|
I've created and run a script to do the second step of the plan described in #412 (comment) and committed the changes. Below is the output of that script, which summarizes which user IDs were found in each file and what the
|
In the above commit I set the remaining |
In the above commit I set the remaining |
I used git logs to look for successful commits of translations for the sv locale and found that most if not all activity in the time frame where the problems were occurring were done by one translator, so I've changed all |
I used the same technique of looking at git logs to figure out which translator was working on the cs locale translations during the time frame in question and replaced the |
For the last remaining instances of |
The translations have all been rebuilt, and there are no more |
While working on phetsims/perennial#326 I found a number of instances of sims with
userId
values ofnull
for all string entries in the file. Here is an example of a commit where this is happening: phetsims/babel@5686531.We'll need to figure out why this is happening and correct it.
The text was updated successfully, but these errors were encountered: