Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Syncing locales #142

Open
nboliver-ventureweb opened this issue Apr 1, 2024 · 5 comments
Open

Syncing locales #142

nboliver-ventureweb opened this issue Apr 1, 2024 · 5 comments

Comments

@nboliver-ventureweb
Copy link

First, want to mention that Shopkeeper is exactly the tool that we've been looking for - thank you!
When working with multiple shops on the same theme, it's fairly common for the locales to be edited via the "Edit default theme content" button located in the context menu of each theme on the themes page.
However, looking at the docs, it doesn't seem like locales files are accounted for. How do you recommend keeping those files in sync between stores that use the same theme?

@jeffreyguenther
Copy link
Member

jeffreyguenther commented Apr 2, 2024

Awesome! I'm glad you're finding value in Shopkeeper!

You bring up a good point regarding locales. Let me think on this and make a suggestion. The stores we work on are in English only so this is case I haven't accounted for.

There are two options, I think:

  • Treat locales like theme settings and let them be stored per bucket
  • Treat locales like theme code and keep a single instance per theme and sync them accordingly.

While I investigate, can you describe how you'd like them to work based on your experiences?

@nboliver-ventureweb
Copy link
Author

The locale files are a bit tricky because they contain both the schema and the associated string values. With settings we have separate settings_schema and settings_data files, so it makes sense to store settings_data per bucket and keep settings_schema centralized. This lets us push code from GitHub up to Shopify and pull settings / content back down, keeping things nicely separated.

I think the main challenge with the locale files is that we kind of need a way to handle them both ways:

  • Developer builds a new feature, adds strings to locale file(s), pushes to GitHub, creates a PR, merges PR, triggers deployment (changes are pushed from GitHub to theme).
  • Merchant / app / developer needs to make changes to locales file from Shopify admin, or perhaps needs different strings per store that share the same theme (maybe more of an edge use-case). Checkout text string changes are generated from Shopify admin, and pulling changes down from Shopify admin is needed for that.

The current workflow doesn't really account for pulling down changes (besides settings) from Shopify admin, unless the Shopify CLI is used directly. That could be an option if the project only needs a single instance per theme, but it would be nice to have it included in the deployment pipeline somehow, otherwise it would be easy to overwrite changes from Shopify admin.

Maybe I'm over-complicating it and we should just tell merchants to let us know if any changes are made via the "Edit default theme content" button, or else their changes may be lost? 🤷‍♂️

@jeffreyguenther
Copy link
Member

Thank you for the notes. I follow.

Before we drive into the details, there are a couple assumptions that Shopkeeper is built on that we need to acknowledge:

  • The source of truth for settings is the live theme
  • The source of truth for theme code is the codebase you're running the deploy command from.

We do this because we want to ensure that whatever is live on the store is what remains live after a deploy.

First, let's deal with the scenario where a change is made in the Shopify admin.

In The Complete Guide, we use the backup action to sync the current theme settings to GitHub. This is done to ensure the latest settings are in GitHub. It is possible, however, that the theme has changes and the backup action hasn't run yet, so the repo is out of date. This is why, on deploy, we pull down theme settings before pushing up the latest code.

For locales, we could add a step to the deploy workflow that pulls down the locale files. We could add a command like:

shopify theme locales download

We would also update the deploy command to download locales. This would ensure whatever locale changes have been made in the theme are persisted across deploys.

A temporary fix would be to add a step to your deploy and backup workflows that does:

shopify theme pull --only "locales/*.json"

Adding a step to the settings backup workflow to download the locales would ensure that the latest settings make their way back to the repo.

To make support locales first-party, we would need to:

  • Store locales in a bucket
  • Add theme locales download command
  • Update theme deploy command to pull down locales when it does its settings sync

Now, let's deal with the scenario:

Developer builds a new feature, adds strings to locale file(s), pushes to GitHub, creates a PR, merges PR, triggers deployment (changes are pushed from GitHub to theme).

This one is harder. This workflow is also an issue when creating a JSON template on a dev theme and want to use the normal deploy workflow. It's something we've been wrestling with internally. We typically fix things manually in the on-deck theme in the rare occasions when we're adding a completely new template, but it still trips us up at times.

There are moments where you want the repo to be the source of truth and others where you want the admin to be the source of truth.

@jeffreyguenther
Copy link
Member

I wonder if detecting a string in a commit message might do the job. Something like how [skip-ci] is used. Maybe [skr-from-local] or something like that?

I'm open to suggestions. 😄

@nboliver-ventureweb
Copy link
Author

I wonder if a good compromise may be to offer the ability to store locales in a bucket, but not require it? This would give flexibility to track changes from the admin / across different stores if required, but also allow you to keep it simple if not required. Once locales are tracked in buckets, any new additions will need to be made separately to each store, which could be a minor inconvenience. Perhaps it could somehow be configured as an optional flag from the shopkeeper bucket init command? Just a thought 😄

I like the idea of a specific commit message string to skip downloading before deploying. That would allow you to make json changes alongside code changes, with the caveat that you could possibly overwrite content from Shopify admin.

One other thing I was thinking about is assets. We have our build assets prefixed with dist__ and then we have assets/dist__* in .gitignore. This allows us to track other theme assets in the directory, if needed. There are also app-generated files that often need to be retained in the assets directory. Do you typically just keep the Shopify admin as the source of truth for assets (ie don't track in git), and use the --nodelete flag with the deploy command to ensure that app / merchant assets don't get wiped?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants