Discuss strategy for use of Calypso on web properties moving forward

[hannahkane]

Specifically looking at Learning, Science, and Advocacy

See this early version of what we thought the Science site use of Calypso might be: https://public.etherpad-mozilla.org/p/sciencesiteapproach

And here's some early documentation on the use of Calypso at Mofo: https://docs.google.com/document/d/1VYsorOj75we-kV-a0h8tTV7DwvPRr7NksiiBCM77iyI/edit

Possible deliverable: list of rules for when we use Calypso vs. other content creation tools

[gvn]

My primary criteria for using Calypso are:

• Content requires frequent updates (more than once a month)
• Content is unstructured (eg: blog posts, or other blocks of free form text)
• Site or app candidate requires multiple levels of administration for content or multiple authors
• Content doesn't require localization (AFAIK there is no way to vary content based on locale for Calypso/WP-API)

Criteria for using structured data management tools and/or JSON string files:

• Content requires localization
• Ample time for a developer (or anyone comfortable with creating a pull request) to perform edits is generally available
• Content must adhere to a schema to be displayed properly on the front-end, making freely editable HTML blobs untenable

[hannahkane]

This list is great.

The lack of localization on Calypso might make this far less useful. I just ran through our list of use cases, and several of them involve content that's likely to be localized. A primary example is a list of resources and guides for Clubs, and potentially the resources/guides themselves, though those are already being localized without Calypso. They are currently being localized either by forking github repos or in some cases they are Thimble remixes.

I'm a bit confused though. Wouldn't something on the React side facilitate what content is displayed?

Is it possible to handle localized content with a different workflow? There's nothing to stop someone from creating content in any language using Calypso, right?

[gvn]

I'm a bit confused though. Wouldn't something on the React side facilitate what content is displayed?

Can you elaborate on that question?

Is it possible to handle localized content with a different workflow? There's nothing to stop someone from creating content in any language using Calypso, right?

You can create content in any language, but there's no way to programmatically choose what language you retrieve on the front end that doesn't involve hard coding endpoints for every different language. Not only is this poor engineering practice, but it also requires a developer to update code every time new localized content is added, which detracts from our goal of eliminating developer involvement in content updates. Also, AFAIK there's no way to add metadata to posts indicating what language they're in, and if there is I don't think you'd get anything beyond a free text entry with no validation to ensure that the locale code conforms to the standard (eg: fr-CA).

The localization problem is compounded by the fact that there's no system for resolving discrepancies between instances of a page when one of them changes. With structured data (typically JSON) we can at least see if keys change in the English JSON and then I believe Transifex can handle facilitating necessary updates to the other languages.

TL;DR – There is nothing in Calypso to facilitate localization. It's all up to us to manage and attempt to maintain consistency without any sort of validation or safety net. It's going to get out of control really quickly and be highly error prone.

[gvn]

CC: @simonwex

[hannahkane]

In the case of Clubs guides, which is the best example I have right now, a traditional l10n process might not be what we need anyway. In this case, we're not talking about translating strings. I would compare it more to Wikipedia, where there might be entries for the same topic in different languages, but they're not direct translations. So, they're might be a list of en-US resources and a list of zh-CN resources, but they are totally different.

When I asked about the React side, I was wondering if on, say, learning.mozilla.org/clubs/resources (not an existing page yet), we could detect the user's locale and turn up different content based on that. It sounds like we can't.

It would be great if the team exploring this in London could brainstorm some possible solutions for this particular use case. I think there's a lot of content that we're unlikely to translate, though, so we could start the migration to Calypso with those pages. Two great examples are https://learning.mozilla.org/community/community-call and https://learning.mozilla.org/community/curriculum-workshop. Since the calls those pages are advertising are conducted in English, we likely won't localize those pages.

[gvn]

We can potentially display different content based on a user's locale, but what I'm trying to express is that it's hacky with Calypso because there's nothing to facilitate localization within it. We'd have to create a bunch of different versions of a page and try to enforce some kind of consistent organization of associated translations without Calypso validating anything for us. It's error prone and hard to manage.

We also have to make explicit callouts to every different instance of a localized page on the front end, which means a developer has to be involved any time a page is localized to map a given locale code to a localized page slug.

[alanmoo]

What's the latest on this? Is it still at all relevant?