[Theme Check] MatchingTranslations rule handling Customer Accounts translations incorrectly

[jamespeilow]

Describe the bug

When running shopify theme check, the MatchingTranslations reports errors for the customer_accounts. namespaced translations when a merchant has changed one or more of the Customer Accounts translations.

When the merchant changes one of the Customer Accounts translations, the changed string gets added to the theme locale JSON file under the customer_accounts namespace. However only the changed line gets added and only to the changed language's locale JSON file, causing Theme Check to then report the MatchingTranslations error as the translation is missing from the other locales.

The customer_accounts. translations all exist, and are visible in the Admin under in Languages and in Translate & Adapt, but they don't exist in a themes locales JSON files. This is the same behaviour as how Checkout translations are handled.

Expected behaviour

The MatchingTranslations rule should ignore translations that start with customer_accounts., similarly to how it ignores translations starting shopify.

Actual behaviour

The MatchingTranslations rule reports missing translations when a customer_accounts. translation does not appear in every locale file.

Additional context

This issue isn't an problem with Checkout translations, as these get added under the shopify namespace, which is excluded by the isShopifyPath check in the MatchingTranslations rule - https://github.com/Shopify/theme-tools/blob/90577cd2b5381eb6b8c50cde00186dccf0088577/packages/theme-check-common/src/checks/matching-translations/index.ts#L51

Updating that function to also return true for paths starting customer_accounts. would fix the issue:

    const isShopifyPath = (path: string) => path.startsWith('shopify.') || path.startsWith('customer_accounts.');

[karreiro]

👋 Hey @jamespeilow,

Thanks for reporting this!

The shopify. is indeed a special case. However, it looks like in the customer_accounts scenario, the matching translations feature is correctly identifying and reporting missing translations, as we can see in the example below:

https://github.com/user-attachments/assets/832f66a9-0339-47a5-8804-dc75c7537b22

Thanks again for highlighting this! Please let me know if I've misunderstood the issue you're experiencing.

[jamespeilow]

Hi @karreiro

I believe that customer_accounts should also be handled as a special case, the same way that shopify. translations are.

The scenario we are seeing with some of our clients is the following:

1. Client updates a "Customer Accounts" translation in one of their locales
2. The updated locale gets added to the corresponding locale JSON file (e.g. in your video, the locale was added to the en.default.json file)
3. Now all other locales are reporting the MissingTranslation error (as shown in your video with the pt-BR.json locale)

I think that customer_accounts. should have the same special treatment as shopify. because if a translation is not in the locale file in the theme, it still gets served correctly on the front end based on the default account translations. This is the same way that Checkout translations are handled - If I checkout translation is customised for a single locale it is not needed to be added on the other locales.

In your video, you resolved the issue by adding the missing locale string to the pt-BR.json file, however you added a custom message into the pt-BR.json file. This isn't the best workflow because we would then need to go through every other locale file and add the missing customer accounts locale strings, and we would not want to add the English text for each of the missing locales as that would show English on the other locales, so we would instead need to add translated locales for each of the missing strings, adding a lot more overhead.

It seems that the customer_accounts. translations should probably have been saved inside of the shopify. object so that it behaves in the same way as Checkout translations, but appreciate that would create some breaking changes.

We're currently getting around this issue by adding a custom MissingTranslations rule to our theme check yml files on our repos that are using the new Customer Accounts - but it would be great see this resolved in the main MissingTranslations check so that we don't need to use a custom rule for this.

Thanks!

[karreiro]

Hi @jamespeilow,

Thank you for sharing the additional reasoning.

I think that customer_accounts. should have the same special treatment as shopify. because if a translation is not in the locale file in the theme, it still gets served correctly on the front end based on the default account translations.

I believe that falling back to the default translation is the behavior for all kinds of translations and is not specific to customer_accounts. or shopify..

The reason I'm trying to clarify the differences for customer_accounts. is to ensure we don't unintentionally bypass the intended purpose of the matching translations check. If we disable checks for all keys with this prefix, other developers might lose the benefit of the matching translations check for this specific family of keys.

Please let me know if I'm following your reasoning accurately—I'm happy to revisit this as needed :)

[jamespeilow]

Hi @karreiro - Just checking back in on this. We've been rolling our own custom check to get around this for the last couple of months but it would be great to see this rolled into the core theme check.

To clarify on the locale differences there are: 1 - Theme specific locales

• these are added by the theme developer
• If you try to reference one of these locales, and it doesn't exist then you get an error output in the liquid code
• e.g. if I add:

<p>{{ 'does.not.exist' | t }}</p>

Then the theme will output

<p>Translation missing: en.does.not.exist</p>

2 - Shopify provided locales

• these locales are provided by Shopify, but can be overridden by a merchant
• the values for these locales are stored elsewhere in Shopify (not in the theme locales files)
• Only if the merchant modifies one of these translations does their custom translation gets stored in the theme's locale file
• You do not get a Translation missing: warning with these locales

The shopify. name-spaced locales are a special case, which is already accounted for by the Theme Check, but the introduction of the new Customer accounts introduced a new special case for customer_accounts. name space - so customer_accounts should also be included.