gutenberg-mobile

gutenberg-mobile copied to clipboard

Fixes #

To test:

PR submission checklist:

• [ ] I have considered adding unit tests where possible.
• [ ] I have considered if this change warrants user-facing release notes more info and have added them to RELEASE-NOTES.txt if necessary.

Hey @mokagio 👋 I was wondering how this experiment was going. It looks like the i18n cache is being loaded correctly as I saw in this job 🤩

Hey @geriux . I started this but then stopped because I wanted to learn more about the cache. Maybe you can answer my question.

How does the codebase know about the i18n cache validity? I mean, the only check I've seen in the code is "is the cache in the repo? if not, download" but how is this cache maintained and updated?

For the purpose of the automation here, would looking at when package.json changes be a good proxy for when to update the cache? Or are there better files to check?

Thanks!

How does the codebase know about the i18n cache validity? I mean, the only check I've seen in the code is "is the cache in the repo? if not, download" but how is this cache maintained and updated?

This cache folder only stores the un-optimized translations, there's no mechanism currently to invalidate its content other than manually running npm run i18n:update.

When we run the Build JS Bundles Buildkite job for tag releases it runs npm run prebundle:js which calls npm run i18n:update to fetch the latest strings and it also optimizes them.

For the purpose of the automation here, would looking at when package.json changes be a good proxy for when to update the cache? Or are there better files to check?

I think we could rely on the version of the app? If we can pick the version of the package.json I think that would be great to use as part of the cache key to invalidate it. @fluiddot Do you think that's a good approach for this?

How does the codebase know about the i18n cache validity? I mean, the only check I've seen in the code is "is the cache in the repo? if not, download" but how is this cache maintained and updated?

Updating the localizations is a bit tricky process because it requires analyzing the React Native bundle. The scripts behind the i18n:update command mainly seek for the used strings in the native editor. Hence, I don't think there's an optimal way to validate the cache without running that process.

Further information can be found in: p9ugOq-2xq-p2.

I think we could rely on the version of the app? If we can pick the version of the package.json I think that would be great to use as part of the cache key to invalidate it. @fluiddot Do you think that's a good approach for this?

Yep, as you pointed out @geriux, we only generate the optimized localizations in releases. Although to be accurate, we run this process when pushing a Git tag, so this would also cover when creating alpha versions. Using an outdated version of localizations in alpha builds shouldn't be an issue, as translations are expected to be included only in final releases. That said, I think relying on the version of the app would work as a way to validate the localizations cache.