RFC: Translations on Project Pages

[goplayoutside3]

Package

app-project

Problem

Project homepages and /about pages should incorporate translations for text based on locale.

Next.js 10 provides localization by sub-path routing or domain routing. For static pages, it generates separate versions for each locale. For instance at build time, Next.js would spit out two index.js pages, one in english and one in french. Here’s an example repo provided by Next.js that shows a normal page, a non-dynamic getStaticProps page, a dynamic getStaticProps page, and a getServerSideProps page.

Questions to consider

1. Should we utilize the Next.js built-in way of handling localization?

2. Should translations be fetched as a panoptes resource or loaded from a static content library such as counterpart or next-translate?

(Issue #54 has some discussion of whether to use panoptes or a static content library. The ProjectHomePage is already configured to use counterpart for text in several components such as Introduction)

3. Should translations be loaded via server side or client side?

4. Should the user’s preferred locale be detected and redirected automatically?

[srallen]

Should we utilize the Next.js built-in way of handling localization?

I think we'll have to do a sandboxed/time boxed prototyping experiment with this. I'm really unsure if we should follow their API or not and what the consequences would be either way. A separate experimental next.js app could be spun up that say just built a single project about page with a mix of static content translations and resource translations just to see how it'd work?

Should translations be fetched as a Panoptes resource or loaded from a static content library such as counterpart or next-translate

I think we'll find that most pages in the project app are going to be a mix of both. The about pages will have some static content with the page titles and role titles that aren't editable by project owners, but the markdown content is from the page resource stored by Panoptes. So, how we handle loading a language will have to handle both.

As an initial step I think we can do the following:

• Add setting and storing the chosen locale to the project app's UI store
• Default to the project's primary language
• Add the language menu to the project UI and use the available languages as the menu options

Should translations be loaded via server side or client side?

Like the mix of static content and resource content, I think we'll have a mix for loading server side and client side as well. For the about pages, I think these would load server side so it could be cached. For other resources like the workflow and tutorial, these would be loaded client side alongside the loading of the original resource from Panoptes.

Should the user’s preferred locale be detected and redirected automatically?

Yes, I think this is good idea. We could at least store the chosen language in a cookie like we do the theme mode so the choice can be retained between sessions. Another enhancement would be to detect the language set on the OS and this is an enhancement we can do for theme mode as well.

[eatyourgreens]

Roger added some localisation when he set up the workflow menu for the project home page, so we do have an example of server-side translations in the code at the moment.

Translated workflow names are fetched here:

front-end-monorepo/packages/app-project/src/helpers/fetchWorkflowsHelper/fetchWorkflowsHelper.js

Lines 22 to 39 in 2530309

	async function fetchDisplayNames (language, activeWorkflows, env) {
	let displayNames = {}
	try {
	const response = await panoptes.get('/translations', {
	env,
	fields: 'strings,translated_id',
	language,
	'translated_id': activeWorkflows.join(','),
	'translated_type': 'workflow'
	})
	const { translations } = response.body
	displayNames = createDisplayNamesMap(translations)
	} catch (error) {
	logToSentry(error)
	throw error
	}
	return displayNames
	}

Then workflow.display_name is replaced with the corresponding translation string here:

front-end-monorepo/packages/app-project/src/helpers/fetchWorkflowsHelper/fetchWorkflowsHelper.js

Lines 64 to 65 in 2530309

	const displayName = displayNames[workflow.id] || workflow.display_name
	return buildWorkflow(workflow, displayName, isDefault, env)

[goplayoutside3]

Linking the FEM Translations planning board for reference
https://github.com/zooniverse/front-end-monorepo/projects/15