The author is an unreliable narrator. The very first thing, the location of the script, can’t possibly be true (the app itself won’t be in per-user support data directory). They conflate things, they definitely don’t know enough about macOS to know to use sudo. I mean, they even rant about bog standard localization files…
Sadly, there are apps out there whose installers drop helper apps in ~/Library/Application Support. Or worse: Eve Online actually puts the whole game there. The Eve.app in /Applications (or wherever you choose to put it) is just the launcher/downloader.
You improve this skill by not using LLMs more and getting more experienced as a programmer yourself. Spotting problems during review comes from experience, from having learned the lessons, knowing the codebase and libraries used etc.
The LLM would, under that argument, be a transformative derivative work, which has important fair use implications (that don’t exist in the chardet case)…
> IMHO pluralization is a prime example, with an API that only cleanly handles the English case
That’s not true at all? Gettext is functionally limited to source code being English (or alike). It handles all translation languages just fine, and competently so.
What is doesn’t have is MessageFormat’s gender selectors (useful) or formatting (arguably not really, strays from translations to locales and is better solvable with placeholders and locale-aware formatting code).
> fully in the translator's hands.
That is a problem that gettext doesn’t suffer from. You can’t reasonably expect translators to write correct DSL expressions.
> Gettext is functionally limited to source code being English (or alike). It handles all translation languages just fine, and competently so.
The *ngettext() family of functions take two strings (typically singular/plural) and rely on a language-wide expression to choose the variant (possibly more than 2 variants). There's no good reason for taking two strings, this should be handled in the language file, even without a DSL. Ngettext handling a single countable makes some corner-cases awkward, like gendering a group with possibly mixed-gender elements. The Plural-Forms expression not being per-message means that for example even in English "none/one/many foo" has to be handled in code, and that a language with only a rare 3rd plural has to pay the complexity for all cases.
Arguably, those are all nitpicks, Gettext is adequate for most projects. But quality translations get cumbersome very quickly.
> You can’t reasonably expect translators to write correct DSL expressions.
This feels demeaning. Translators regularly have to check the source code, and often write templates, they're well able for a DSL like MessageFormat's, especially when it's always the same expressions for their language. It saves a trip to the bugtracker to get developers to massage their code into something translatable. You can't reasonably expect a English-speaking developer armed with ngettext to know (and prepare their code for) the subtleties of Gaelic numerals.
Because GHA was stagnant and expensive and multiple services like https://www.warpbuild.com/ popped up, with better performance and much lower price. Looks like they ate enough of GH’s lunch…
Hey, WarpBuild founder here.
While it makes it harder for us to communicate this, we're still, we're still faster and cheaper even after the $0.002/min self hosting tax.
Overall costs go up for everyone but we remain the better option.
- Barely literate native English speakers not comprehending even minimally sophisticated grammatical constructs.
- Windows-centric people not understanding that you can trivially type em-dash (well, en-dash, but people don’t understand the difference either) on Mac by typing - twice.
reply