Translations

[srallen]

Add translation support before we get to far with this.

[simoneduca]

I'm probably missing something, but from how we plan of building translations, no particular support is needed. What were you thinking?

[srallen]

I mean translating the lab itself. Right now it's all just in English.

ETA: We need to add counterpart or yahoo's react-intl to translate the strings of all the help text, etc. I would presume the app you're building for the translation volunteers to submit translations for projects would also have an area to translate zooniverse.org itself and the lab.

[eatyourgreens]

At the moment, we're just building an editor for the translatable resources stored in Panoptes, so I'm assuming there will be an OrganizationContents resource to go alongside ProjectContents and WorkflowContents.

The UI text will also need an editor, but that's a separate problem. I'm completely okay with moving the UI dictionary into its own GitHub repo (it is just a big JSON blob, for counterpart at least), and asking volunteers to open PRs with translations.

[eatyourgreens]

I've opened zooniverse/pandora#6 to list project resources that would need to be translated. Will organisations use OrganisationContents resources, like projects?

[srallen]

@eatyourgreens yes: https://github.com/zooniverse/Panoptes/blob/master/app/serializers/organization_content_serializer.rb

Related to translations, @zwolf and I debugged zooniverse/panoptes#2318 yesterday and discovered that pages are currently locked to English as en: https://github.com/zooniverse/Panoptes/blob/master/app/controllers/concerns/pages.rb#L47-L49

This affects both orgs and projects since orgs is reusing the pages controller. We found that if the primary language parent resource, in this case the org, did not match the language set for the page, then the request for the pages would return as an empty array. I haven't added counterpart to the lab app yet and was setting the primary language for orgs on create using the window's navigator.language property. (On PFE, project's primary language are set by counterpart and defaults to en). Thus the org was set as en-US and the pages are set to en despite the fact that on page create I had been setting it to the org's primary language. Two issues come to mind:

• Pages will need to be fixed to support translations
• Should we continue to use counterpart for setting projects/organizations primary language? Is there a reason to use counterpart for this over the navigator object? The window navigator object is more precise, however, I can also see that defaulting to en and not using geo-specific language codes as being reasonable too.

[eatyourgreens]

The navigator property is readonly, isn't it? My argument against that would be the case where you're using a computer in a foreign country, so you don't control navigator.language, and you want to read a web page in English. I think the language code should come from something that the site user can change.

[eatyourgreens]

By the way, you might find that the language code is currently locked to en for tutorials and field guides too.

[srallen]

For a user I think we would want to store their language preference in their project preferences?

Thanks for explaining a case where the browser setting wouldn't be helpful. The staging orgs we're building with are already fixed to now be set to en instead of en-US and adding counterpart for setting the primary language instead of using the browser is a simple update. I'll get that in with the about page editor PR here.

[eatyourgreens]

Preferences sounds good for language codes. I think the older translation code used on Penguin Watch and Galaxy Zoo gets your language from preferences, so that it's saved across visits.