search

wordpress-mobile / gutenberg-mobile

Mobile version of Gutenberg - native iOS and Android
GNU General Public License v2.0
245 stars 56 forks source link

Experiment with i18n caches in CI #6724

Open mokagio opened 6 months ago

mokagio commented 6 months ago

Fixes #

To test:

PR submission checklist:

geriux commented 6 months ago

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 🤩

mokagio commented 6 months ago

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!

geriux commented 6 months ago

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?

fluiddot commented 6 months ago

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.