Right, you said you're from the UK so that's in line with what I would have expected. My unstated point was that multinyms are intrinsically tied to dialects so there is no absolute list of multinyms
> "e'er" would sound slightly different as it's spoken almost like two syllables, though not quite.
I'm a native English speaker (US). Sometimes when I say "ever"/"never", the 'v' sound drops out. So I end up saying "e'er"/"ne'er" but it sounds like "air"/"nair".
> Further down the list, I've just spotted "taught, taut, tot" and "tot" doesn't belong there.
I'm from South Carolina, USA and I pronounce 'greater' and 'grader' the same. There is a subtle difference and that difference can be more noticeable sometimes, but most of the time I'm saying them the same.
For everything in this list, its incredibly common for these groupings to have the same pronunciation where I live.
I think the acronym thing is related but a separate phenomenon. My guess would be that speakers intuitively think the acronym isn't easily understandable so they add an extra word to clarify it, intentionally or unintentionally duplicating one of the actual words in the acronym.
"pont bridge" sounds like the exact phenomenon though. Does it have a more specific meaning that "bridge"?
My argument is that it's not a mistranslation. In Spanish, "horno" means any kind of oven. In English, it means specifically an earth oven because when English speakers started using the word, they always used it to mean that kind of oven.
A sibling comment mentioned chai tea. It's the same phenomenon. Chai means any tea in its original language, but in English it means a specific variety and preparation of tea.
English is a bastardized language and has a lot of words borrowed from other languages. But once they're borrowed, they're English words and have their own meaning separate from their original loanword.
When a common word from another language is borrowed into English, it tends to take on a more specific meaning. Most native English speakers wouldn't use "salsa" to describe any other sauce. Horno oven sounds perfectly reasonable in English to specifically describe an earth oven in that style, not the common household appliance.
EDIT: Probably the reason this happens is that most English speakers wouldn't be familiar with the foreign word, so the speaker uses it as a modifier to the standard English word. The listener doesn't need to know anything specific about the foreign word in that case and can just assume it's a type of the common item.
> just make transit more attractive, not make driving less attractive
If ppl drive more than use transit, they won't support improvements to transit. This is the first step to improving transit. Make driving less attractive, more ppl use transit, complain about its shortcomings, and then fixes get implemented.
I also don't see why we shouldn't make driving less attractive. As the grandparent comment said, drivers should be the ones paying for the problems caused by drivers, not residents.
> The basic thing I am saying is that if you call it a web browser and use the same core protocols etc., you have a practically infinite (for an individual) set of requirements to implement and will never be truly compatible
But what the parent is saying is you don't have to be compatible with 100% of websites. If you build a browser with good HTML/CSS/Javascript handling, you'll be compatible with the large majority of the web. Yes, there are other specs that are in use by a tiny portion of the web. But your browser can still exist if it doesn't support them. Users of that website will know or find out that they can't use your browser for that, but for every other user that browser could be exactly what they need.
> without having to worry about a fuzzy and ever-expanding definition of what you have to support.
It's only ever-expanding if you're trying to keep up with the Jones's. You can define a subset of the web you want to support and build a clean, small browser that supports that.
Aren't you the developer of Smithereen (a fediverse server)? Nearly every other fediverse software has a web interface that can act as a PWA. I launch lemmy.ml and kbin.social as standalone PWAs from my homescreen. My pleroma instance also has some PWA features (though not standalone display mode). I don't use Mastodon, but @[email protected] did some amazing work years ago to make it a really fast and responsive PWA (which has since been undone ).
It's ok if you don't like to use PWAs but that doesn't mean nobody does or that they're worthless.
I asked for it, and a lot of other ppl did too. These are great features and removing them would cause more than 1% of websites to lose some functionality.
But, importantly, they shouldn't lose their core functionality (if they're written well) because that's the "Progressive" part of PWA. If you don't use the feature or your browser doesn't support it, the website should still have basic functionality. One of the big ideas behind PWAs is "progressive enhancement", where you layer on features that may not be supported everywhere but add value when they are supported.
And a progressively built browser that doesn't implement every spec goes hand-in-hand with that. I think having more under-featured browsers like that would push webdevs into caring more about progressive enhancement.
Discoverability is a little better since Pleroma exposes the public timelines for non-logged in users (though the admin can disable that). I'm not sure about search.
The repos they linked are just for the clients. I think the server software would be way more interesting, but it's also their secret sauce so it unlikely they'll open source that.
I'm with you that allowing the clients to connect to a different sync server (gpodder, etc) would be a great feature. Though, again, I don't see that happening because it would cut into their subscription service.
Except in situations exactly like this one. A user shouldn't have to worry about local vs remote videos if they want to share the link outside the fediverse and someone clicking that link definitely shouldn't have to know about instances, federation, etc to be able to watch the video. Clicking the link should take them to a watchable video; if for some reason, it's not available for watching on the instance, it should use a http redirect instead of loading an intermediary page
Right, but that doesn't mean the server can't support other post types or leave complex UI to other clients. Each server could fallback to displaying a link to an external post at a bare minimum, or display whatever the `content` field. I'm just arguing that the C2S is perfectly viable and would make the fediverse so much richer and more usable. Using the Masto API to federate only specific types with specific software is limiting the fediverse.
> The UX is important. It's important that all users have the same one. For link aggregators, you want comments displayed as a tree. For microblogging, flat lists work better, especially when people post "threads", which they do.
That's subjective and exactly the type of thing that could be handled in a client. In both cases you're displaying the exact same data. A microblogging thread may be displayed as a flat list, but it's still a tree like a link aggregator thread.
> I meant a Facebook-style social network.
So a platform to post what are essentially blog posts. In ActivityPub, that would be the Article type, which, according to the spec, has no semantic difference from Note. An Article could be created as a Note and vice versa with no semantic difference or loss of data. Just like above, the data is the same and the only distinction is the visual presentation of it.
You could ask around the indieweb irc, https://chat.indieweb.org/ Some of the people there have messed around with syndicating to ActivityPub. I think one of them maintains a Wordpress activitypub plugin