feat: make blog config options and navbar versions dropdown label translatable

[Josh-Cena]

Motivation

Resolve (partially) #4542. This makes the "Versions" label and all the blog options (blogSidebarTitle, blogTitle, blogDescription) translatable.

Have you read the Contributing Guidelines on pull requests?

Yes

Test Plan

yarn start --locale zh-Hans

[netlify]

✔️ [V2]
Built without sensitive environment variables

🔨 Explore the source changes: 8ae7dfa

🔍 Inspect the deploy log: https://app.netlify.com/sites/docusaurus-2/deploys/611f9ccd3a53b50008d87096

😎 Browse the preview: https://deploy-preview-5371--docusaurus-2.netlify.app

[github-actions]

⚡️ Lighthouse report for the changes in this PR:

Category	Score
🟢 Performance	97
🟢 Accessibility	98
🟢 Best practices	100
🟢 SEO	100
🟢 PWA	95

Lighthouse ran on https://deploy-preview-5371--docusaurus-2.netlify.app/

[Josh-Cena]

@slorber Translating the options seems less straightforward than I thought because the translateLoadedContent only translates the BlogContent which does not include the sidebar title / all the other plugin options. Do you think including those translated fields in the BlogContent interface is a good solution?

[slorber]

@slorber Translating the options seems less straightforward than I thought because the translateLoadedContent only translates the BlogContent which does not include the sidebar title / all the other plugin options. Do you think including those translated fields in the BlogContent interface is a good solution?

Yes, any option that need to be translated should be added to the loadedContent result

[slorber]

Thanks, that looks good 👍

Just let some comments in case you want to take a look, but I'm ok to merge this.

[slorber]

I'd prefer to have code to get the options file, this won't break if we add other translation files later? Not a big deal for now we may not have many translation files for the blog 🤪

[Josh-Cena]

I don't know how to do this gracefully since plugin-docs and theme-classic handle this in pretty different ways. I hope destructuring is better:

const [{content: optonsTranslations}] = translationFiles;

[slorber]

let's keep this for now 👍 we'll see later if there's a need to improve it

[slorber]

It's worth double-checking that if the options.json file is empty or incomplete, it doesn't crash the translation process.
I think it's safe because translated content is merged into untranslated content to make sure all keys are always available, but worth double-checking that.

[Josh-Cena]

Added a jest test, not sure if it's representative though (not very confident with unit tests)

[slorber]

have you pushed? I don't see any change?

I don't think a Jest test can test it anyway, it's more a contract of how core is supposed to call the lifecycle (ie, provide exactly ALL the files with ALL the keys that getTranslationFiles have). I checked code and it should be the case, so was just asking for a local test ;)

But having some basic tests for translations.ts can be useful. Something simple, similar to what we have for docs:

function getSampleTranslationFiles() {
  return getLoadedContentTranslationFiles(SampleLoadedContent);
}
function getSampleTranslationFilesTranslated() {
  const translationFiles = getSampleTranslationFiles();
  return translationFiles.map((translationFile) =>
    updateTranslationFileMessages(
      translationFile,
      (message) => `${message} (translated)`,
    ),
  );
}

describe('getLoadedContentTranslationFiles', () => {
  test('should return translation files matching snapshot', async () => {
    expect(getSampleTranslationFiles()).toMatchSnapshot();
  });
});

describe('translateLoadedContent', () => {
  test('should not translate anything if translation files are untranslated', () => {
    const translationFiles = getSampleTranslationFiles();
    expect(
      translateLoadedContent(SampleLoadedContent, translationFiles),
    ).toEqual(SampleLoadedContent);
  });

  test('should return translated loaded content matching snapshot', () => {
    const translationFiles = getSampleTranslationFilesTranslated();
    expect(
      translateLoadedContent(SampleLoadedContent, translationFiles),
    ).toMatchSnapshot();
  });
});

[Josh-Cena]

Ugh, forgot to push😅 My tests are pretty similar to what you have here, indeed

[slorber]

instead of translating each page title this way, I'm wondering if we shouldn't create a bundle with all those generic blog infos, so that multiple pages could use the same bundle?

Like:

const blogMetadataProp = await createData({title,description,sidebarTitle})

addRoute({
  modules: {
    blogMetadata: blogMetadataProp
  }
});

Not sure it make sense though so I'll let you figure out, current implementation is good enough for me

[Josh-Cena]

No strong feelings, I also considered this, but the current implementation equally makes sense. I was thinking if it is possible to have a translateOptions lifecycle?

[slorber]

Let's keep it this way, I may refactor this plugin a bit in the near future because it's a bit messy.

About translateOptions, I think adding options to content is fine and we don't need another new lifecycle, but let's see, we may add this later if this becomes a common need for ourselves or other plugin authors

[slorber]

Thanks LGTM 👍

About feed options, I'd rather use feedOptions = null to disable rather than feedOptions.type = null , but this would be a breaking change, not sure it's worth it now