feat(newTask): support locales being selected by default

[matthewborgman]

This change allows the locales returned by getLocales to include an optional selected property.

When set to "true", and the existing enabled property is not explicitly set to "false", this will pre-select the corresponding locale's button.

[matthewborgman]

For context, I have a scenario where the desired locales may differ between pieces of content, but the superset of available locales is the same. For example, to support the EU the configured locales may be, say, "da-DK", "de-DE", "en-GB", and "fr-FR".

Some content may only be translated to "da-DK" and "de-DE", while other content is translated to all locales. It would be difficult then for content managers to remember which content translates to which locales. By allowing selected, my implementation may track which content maps to which locales and then when the "Translations" tab is opened for a piece of content then preselect the corresponding locales.

[matthewborgman]

For context, I have a scenario where the desired locales may differ between pieces of content, but the superset of available locales is the same. For example, to support the EU the configured locales may be, say, "da-DK", "de-DE", "en-GB", and "fr-FR".

Some content may only be translated to "da-DK" and "de-DE", while other content is translated to all locales. It would be difficult then for content managers to remember which content translates to which locales. By allowing selected, my implementation may track which content maps to which locales and then when the "Translations" tab is opened for a piece of content then preselect the corresponding locales.

Actually, pause on this. I just realized that I may not have access to the current document ID when necessary to make this work.

[cngonzalez]

If this is still in a paused state, I'll hold off on the review, but I think this is a great UX choice. I wonder if it's reasonable to create a function that is declared in the configuration object that takes in the document, and can inject whatever conditional logic there to pre-select locales. Something like how localeIdAdapter works.

[matthewborgman]

If this is still in a paused state, I'll hold off on the review, but I think this is a great UX choice.

OK, so I confirmed that I have access to the data I need so this would still be useful to me -- if not others too.

inject whatever conditional logic there to pre-select locales...

So here's how I've approached it so far in the GlobalLink adapter:

  getLocales: async (secrets: Secrets | null, documentId: string) =>
    Promise.all([getLocales(secrets), getDocumentsMetadata([documentId])])
      .then(([languageDirections, documentsMetadata]) =>
        Promise.resolve({
          languageDirections,
          documentSupportedLocales:
            documentsMetadata?.[0]?.supportedLocales || [],
        })
      )
      .then(({ documentSupportedLocales, languageDirections }) =>
        languageDirections.map(
          ({ targetLanguage, targetLanguageDisplayName }) => ({
            description: targetLanguageDisplayName,
            localeId: targetLanguage,
            selected: documentSupportedLocales.includes(targetLanguage),
          })
        )
      ),

To your point re: the configuration, perhaps there's an optional transformLocales (or whatever) function that when present would be "applied" to the results of getLocales. The thought being that getLocales would still be defined at the adapter level, but may be transformed however at the implementation level. Thoughts?