(3) Disable translations, forcing English

[rschwab]

Edit: We've decided on option A, disable translations.

Patron reported this link, with the interface translated to French: https://digitalcollections.library.ucsc.edu/catalog?f%5Bancestor_collection_titles_ssim%5D%5B%5D=UC+Santa+Cruz+Campus+History+Collections&f%5BsubjectTopic_sim%5D%5B%5D=College+teachers&locale=fr&q=Image&search_field=resourceType&sort=system_modified_dtsi+asc

Somehow Google has indexed at least one link in French. We need to decide whether we want to: A) Disable translations, forcing English B) Utilize translations, and offer a language switch UI. C) Something else.

Then implement this decision. As of now users potentially end up on non-English pages with no way to change it back (other than URL editing).

[sara-g]

@rmjaffe How did you want this handled?

[rmjaffe]

@sara-g Thanks for asking -- I checked with both @rschwab and @JessWaggs, our UX librarian, and we'd like to go with option A: disabling translations, forcing English.

[rschwab]

Note: We can set some variables on the Rails internationalization gem to limit the supported languages to English, however this leads to an error page when other locale's are used in the URL. I will undo those changes and instead attempt to redirect non-English traffic back to the English version using htaccess or another server-side redirection method.

[rschwab]

@rmjaffe I've tried using a redirect to address this, basically telling the server to always remove "locale=whatever" from the URL and then move on. This worked great for searching or loading a specific work. But when I tried clicking a search result it rewrote the whole URL, for example instead of going to /concern/works/r494vk33w as expected, the link loaded /catalog/r494vk33w/track?counter=23&search_id=601 which results in an page-not-found error.

This makes me think that Hyrax is rewriting URL's from Blacklight, and is probably doing this in other places as well. I wonder if fixing the translations problem in this way might not be worth the risk of breaking an unknown number of things.

I could continue investigating how those rewrites are happening, or we could settle on the previous fix (setting the Rails configuration variables for the Internationalization gem), which results in an error page for non-English pages. I think if we were to do that we should consider improving the error page (at min with a link to the homepage), and potentially doing that first before finishing this ticket. @JessWaggs you may want to weigh in on that too.

[rmjaffe]

Thanks for the investigation and update. I agree -- chasing down every instance where the rewrites are happening doesn't seem like the highest priority use of time. Likely some serious wishful thinking on my part, but is there any chance this might be resolved with the stack upgrade?

Improving the error message 100% makes sense. @JessWaggs I'll defer to you as to whether the impact on users is enough that we should continue to chase this rabbit.

[rschwab]

Updating the stack won't solve this as the translations are working as intended in Rails.

And just an FYI, updating the error page is very simple and involves just writing some html+css on this file. Updating the 404 page is the same easy process.

[rschwab]

@JessWaggs & @rmjaffe How does this look for an interim error page?

[JessWaggs]

I'd be in favor of removing the "report this problem" link and just having the "return to homepage" link.

[rschwab]

@rmjaffe @JessWaggs This is ready for QA in Sandbox. Changing any "locale=en" to another language code (fr, de, etc) should lead to the error page with a link back home.

[rmjaffe]

@rschwab Just looked at a couple random works/pages in sandbox and updated the URLs:

1) http://digitalcollections-staging-sandbox.library.ucsc.edu/concern/works/v979v3346?locale=en --> http://digitalcollections-staging-sandbox.library.ucsc.edu/concern/works/v979v3346?locale=de

2) http://digitalcollections-staging-sandbox.library.ucsc.edu/concern/works/rj430493h?locale=en -- http://digitalcollections-staging-sandbox.library.ucsc.edu/concern/works/rj430493h?locale=jp

3) http://digitalcollections-staging-sandbox.library.ucsc.edu/collections/kp78gg41b?locale=en --> http://digitalcollections-staging-sandbox.library.ucsc.edu/collections/kp78gg41b?locale=gr

Seems everything is coming up error pages! Is weird though -- after I change the language code in the URL and hit enter, it briefly reverts back to "en" before then changing back to whichever language code I entered and serving up the error page. I think this is good to move forward.

[JessWaggs]

Working for me as expected as well!

@rschwab Is it correct that Google will stop indexing these pages once they resolve to a 500 error page?

[rschwab]

@JessWaggs That's correct!

[rmjaffe]

Working as expected in production.