swift-format VS fluent

I actually don't see anything worth changing. It looks good to me. I think the most important thing is just to maintain the constructive attitude you already have about future-you dealing with the code, because only future-you will really know where you could have done better. One personal-preference thing I carried over from working on Go code is to look for a tool like gofmt [1,2] for Swift. I've been using swift-format [3] for about 2 years and haven't been dissatisfied enough to reach for something more fully featured like SwiftLint [4]. I didn't like the idea at first of delegating most formatting control over to a tool designed with someone else's subjective idea of formatting. But my feeling afterward was that it was freeing: it was no longer (completely) my job/burden/responsibility. An "assistant" would clean up the formatting of my code every time I saved the file. That's a nightmare if you can't configure the tool as much as you need, but if you're lucky and find a configuration you can live with, it lets you focus more on naming and other conventions that aren't so easily automated (yet). [1] https://go.dev/blog/gofmt [2] https://twitter.com/bitfield/status/953395343353315329 [3] https://github.com/apple/swift-format [4] https://github.com/realm/SwiftLint

if you want your code to be formatted with a specific set of rules in mind, you can forward the generated code to a formatting utility, e.g. swift-format

VERSION=0.50500.0 # replace this with the version you need git clone https://github.com/apple/swift-format.git cd swift-format git checkout "tags/$VERSION" swift build -c release ln -s /usr/local/bin/swift-format .build/release/swift-format

Apple literally provides a version that you can integrate into Xcode should you wish to.

swift-format works across different platforms and does a pretty good job with minimal configuration fuss.

Tried BoldVoice right now and almost immediately hit a bit of awkwardness: “Tomorrow, we’ll work on Practice your consonant skills”. Usually I wouldn’t complain about this sort of thing, but in a language learning app it seems unfortunate. (Mozilla’s Project Fluent[1] was built to handle these situations in a localization setting, but you can probably get away with something much simpler.)

[1] https://projectfluent.org/

Hi! Thank you for your critique!

> 1) “Your knight has killed a dragon with a crossbow”

We have a proposal for dynamic references to address this problem - https://github.com/projectfluent/fluent/issues/80 - it's non-trivial but I hope we'll see it solved in Fluent and/or in MessageFormat 2.

> 2) The parser is extremely sensitive

True. It's on purpose. We wanted to start with strict and loosen, rather than the opposite.

> 3) The input files mandate a weird arrangement of new lines for even the simplest branching

Same as above.

> 4) The documentation is too Spartan to know what happens in edge cases.

We're a small team :)

> It heralds itself to be the saviour of all i18n, but it’s literally worse than the mess that came before it.

I'm sorry to hear it doesn't work for you. I'm relieved that your criticism is seems more subjective except of one missing feature that no other l10n system has as of yet.