> 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.
Tesla is in trouble for exactly the reasons many of us saw coming. Irrespective of Elons political antics, Teslas product offering strategy is very different from the rest of the market. They’re banking on this approach changing the market, my bet is they are wrong. Model 3 and Y are long in the tooth, getting stale.
> Model 3 and Y are long in the tooth, getting stale.
Musk's antics and focus issues (i.e. too many resources focused on Cybertruck) aside: The thing with Tesla is, they operate completely antithetical to the classic car industry.
The classic car industry designs a model series and signs four-ish year contracts with all the suppliers for the expected amount of vehicles to sell, with a few extension clauses to cover for higher than expected demand. During these four years, the "rebrush" is designed, keeping most of the car the same but incorporating learnings during production, newly developed technologies (e.g. improved compute power) and maybe retooling to make production more efficient, and then it's another four-ish years that are used to make the next generation. That business model makes sense when operating with a shit ton of suppliers, so both the manufacturer and the suppliers can plan for the mid term.
Tesla however, just like SpaceX, takes pride in not following this business model. As much as possible is made in-house, which means less vendors to deal with, and that enables continuous improvements and iteration.
The downside is that it makes life so much harder for spare parts because any given part might just have been in production for a few weeks if not days, and for consumers and consumer protection agencies it's orders of magnitude harder to warn about construction defects because there is no such thing as a "generation" any more.
> Apple tells you why they rejected the app, and you correct the problem and resubmit.
Such as, elsewhere in this thread, app for viewing HealthKit data “unnecessarily using HealthKit”?
App Store rejections are arbitrary bullshit most of the time. We stopped shipping through MAS because of that and went direct-only, the 30% wasn’t even part of the decision; the bullshit and broken sandbox were.
People care about the tools they are using a lot and spend a great deal of time on finding the perfect knife, the perfect editor, the perfect scissors.
People who care about their tools. If I have to stare at it all day, being pleasant on the eyes is a feature. If every time I grab my tool I think “urk, this is so ugly”, it affects my flow.
As for being "sure" Apple will find the right balance, they never fixed usability regressions in macOS introduced in the last redesign. And they have ~10 weeks to fix all this.
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.
reply