i18n: Fix translatable title strings rendering on purchases sections

[yuliyan]

Changes proposed in this Pull Request

• Define /me/purchases titles with getters that would fire translate function every time they're being accessed, so that titles would update properly for async loaded translations.
• Remove setTitle action dispatcher and use <DocumentHead /> instead for setting the title
• Wrap components that use the shared titles in localize hoc, to ensure component will be re-rendered and call the translate functions after adding translation asynchronously.

Testing instructions

• Change UI language no any non-English Mag-16
• Go to /me/purchases?flags=use-translation-chunks
• Confirm navigation items are translated in the selected language

Merge instructions

• Requires build-tools: Fix RequireChunkCallbackPlugin installed chunks getter #49730 to be merged first
• Drop 144fecd before merging

Related to p1612455006017200-slack-C74C3THK7

[matticbot]

Test live: https://calypso.live/?branch=fix/translatable-purchases-titles

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

Sections (~157 bytes added 📈 [gzipped])

name            parsed_size           gzip_size
purchases           +1429 B  (+0.1%)     +157 B  (+0.0%)
site-purchases       +867 B  (+0.1%)     +131 B  (+0.0%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[dlind1]

This appears to be untranslated when going to details from 'Active Upgrades' section.

[sirbrillig]

Yeah, there seems to be some inconsistency here.

If I load /me/purchases with the flag, then go to add a card, it seems to be correct.

But then as @dlind1 mentioned, if I click on a purchase from the list, the subtitle is not translated:

Here's how it looks (translated) if I reload the purchase page:

I'm not 100% sure how flags persist, but if I load the purchase page with that flag explicitly in the URL, neither the main title nor the subtitle is translated:

[yuliyan]

Thank you for catching this. Turns out purchases controller is not subscribed to i18n changes and therefore the components are not re-rendering after loading translations asynchronously past their initial render.
I'll see how can this be resolved.

[yuliyan]

I've replaced the setTitle with <DocumentHead /> and wrapped all components that use the shared titles with localize to ensure components will re-render after loading the translations.

Could you do another round of testing and see if that resolves the problem?

[sirbrillig]

This works as described. Here's the screenshots for the cases I had tried before that were untranslated:

I did have one question about what side effects localize() has, but I'll approve this anyway.

[sirbrillig]

I'm curious: what does localize() do here? I thought that it just added a translate prop, but clearly there must be some other reason it's used. Does useTranslate have the same effect?

[yuliyan]

I'm curious: what does localize() do here? I thought that it just added a translate prop, but clearly there must be some other reason it's used.

Yes, it enhances the component with the i18n props, but it also subscribes the component to the i18n's change event and forces the component to re-render. This event is being fired when switching the locale or when adding translations to the existing Tannin locale data, as it is in our case with async loaded translation chunks.

So the problem here was that the component rendered before the translations were available in the locale data, and didn't re-render after translations were added.

Does useTranslate have the same effect?

Yes, it subscribes the component to the same event.

[sirbrillig]

🙇‍♂️ Thank you for the explanation! Does this mean that it's a good idea to always use either the HOC or the hook on top-level components?

[yuliyan]

🙇‍♂️ Thank you for the explanation! Does this mean that it's a good idea to always use either the HOC or the hook on top-level components?

I don't think it matters that much, but using the hook without assigning it to a variable may look a bit strange, imo. Essentially, it should be the same in terms of performance and behaviour.