Open stijns96 opened 2 months ago
👋 Thank you for reporting this, @stijns96!
That's a valid and fair problem to solve. However, I'm not so sure if the described solution is the ideal one, as the fallback.default.json
might lead developers to think their theme is in a valid state when it's not. If you have considered any other alternatives that fit well in your workflow, I'd love to hear them. Otherwise, the future assignee for this issue may explore the described one and other alternatives.
Thanks again for reporting this!
Hi @karreiro,
Unfortunately we don't have alternatives... You need a locale file for this. What might be a solution, is that you create warnings for this in the CLI, or automatically create a en.default.json
from the local fallback file, but only when there is no other local .default.json
file.
So there should be some local locale file like local.json
or development.json
and a {local}.default.json
. Whenever there isn't a .default.json
, it will be created from the local.json
.
Does that sound good?
I'm not sure I 100% follow the discussion. Been triaging over 50 issues in the past 2h.
I feel like the ask is that when no *.default.json
file exists, pick any one of them to power completions/checks.
That sounds like a reasonable-ish ask, but it's hard to prioritize given our backlog. We're willing to accept contributions.
Hi @charlespwd,
It's not really about a *.deafult.json
being there or not. It's about local development.
Imagine we have 5 different stores (languages) for 1 client. On development we need a translation file. We don't want to use en.default.json
or en.json
for this, because we don't want to override their translation on a push.
Still we have to add new ones every now and then when working on their theme and requests. How do we get them in the published theme? Not with the en of en.default, because we can not override that.
Is your feature request related to a problem? Please describe. Our client often have separated stores. For this, we only use one code-base. The problem we have is with the translations.
Currently we don't have a dedicated translation file for local development. That means that we're always stuck with our own
en-dev.deafult.json
. file. The client is then using this file, but since we are also developing with this file, we don't push it with new releases. Only an initial release. Due to this, new translations are not coming through correctly and we had to create our own translation snippet where we can provide a fallback. This is also something that is not really developer friendly, because we are now missing some simple features like autocompletion, error handling and intellisense. Additionally it adds extra lines of code and an extra render.Describe the solution you'd like A dedicated locale file (
fallback.default.json)
for development and can be used as a fallback for our client stores. With this, we can safely push these changes to their stores without overriding their current translations