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

Flattening reorders keys #209

Open
thewilkybarkid opened this issue Oct 23, 2024 · 2 comments
Open

Flattening reorders keys #209

thewilkybarkid opened this issue Oct 23, 2024 · 2 comments
Labels

Comments

@thewilkybarkid
Copy link

We've tried out the flatten command, and it works great. However, it reorders the keys (and adds backend and description properties). It probably shouldn't change the structure of the file.

Related, could 'should be flattened' be a lint rule?

@samhh samhh added the bug label Nov 8, 2024
@samhh
Copy link
Member

samhh commented Nov 8, 2024

For key reordering context there's #46. It didn't matter to us when we were in early development, but it's a reasonable request, along with not adding previously absent keys.

I'd personally advise against flattening by hand rather than with tooling as it can severely harm readability (for a dev, anyway). There wouldn't be any harm in adding a lint rule for if you'd prefer to go that route, however there's currently no infrastructure for enabling or disabling specific rules and it wouldn't be appropriate to enable it by default. In the meantime you might be able to get by with flattening and compare each key's message.

To be fully transparent I don't expect us to get around to this any time soon as the tool is pretty much feature complete for our needs and, alongside the wider economic context, time is a little tighter than it once was. I'm also personally striking a healthier balance with extracurricular development than I was a couple of years ago. But I'd be very happy to review any contributions. 🙂

@thewilkybarkid
Copy link
Author

I'd personally advise against flattening by hand rather than with tooling as it can severely harm readability (for a dev, anyway). There wouldn't be any harm in adding a lint rule for if you'd prefer to go that route, however there's currently no infrastructure for enabling or disabling specific rules and it wouldn't be appropriate to enable it by default. In the meantime you might be able to get by with flattening and compare each key's message.

Yeah, I'm trying to imagine using this in CI. At the minute this is the only option, and to see if it makes any changes. The results are rather explosive at the moment though and everything if different. 😄

For key reordering context there's #46. It didn't matter to us when we were in early development, but it's a reasonable request, along with not adding previously absent keys.

Sorry I didn't spot that issue. We could live with making everything alphabetical, but the extra keys are more of a problem: empty description values are noisy, and backend isn't something we'll need/use.

But I'd be very happy to review any contributions. 🙂

I'm not familiar with Haskell myself (other than reading the docs in regards to understanding fp-ts and its ecosystem better), but as we're now using Intlc in production I'll see what we can do. 🙂

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

No branches or pull requests

2 participants