Hacker News Reader

Comment by cabalamat | Hacker News Reader

> but I can't get onboard with Gemini until it offers the same support for screenreaders as HTML. (For example, an equivalent of span lang=XX tags is missing, so if you quote a foreign-language word(s) in your text, you can't let screenreaders know what language to read it in).

The problem with this you'll get a million other people saying "Gemini is a really good simple format that the internet needs, but you need to just add feature X". But if Gemini added all those features, it would become as bloated as HTML/CSS/JS!

View on HN

Gemini is to a large degree a reaction to the commercialization of the web, all that huge load of Javascript etc. arose through the ad economy. Accessibility isn't that, accessibility is something that people trying to do business would prefer to avoid. But letting the disabled be first-class citizens in an online community alongside the rest of the population is a matter of justice. Adding accessibility features isn’t making a standard "bloated", it is simply doing the right thing.

> Adding accessibility features isn’t making a standard "bloated", it is simply doing the right thing.

Yes, and the other million people are going to say their proposed features are "simply doing the right thing".

It may be that marking up what language a short except of text is in is a good feature to have (and would be fairly easy to achieve if Gemini used the Markdown format as you could simply us a <span> tag). A counterargument would be that traditional text doesn't do this, so a text file format ought not to unless it is aiming at being something more than what text does.

But add too many features, the project becomes something else, is maybe less useful & doesn't gain traction. A Gemini project that is too bloated and thus gains no traction helps no-one, disabled or otherwise.

Really feel you're on the wrong side of this one. It's not the same at all in my book. Especially if, as the author of the blog claims, it will never be able to be changed.

> so a text file format ought not to unless it is aiming at being something more than what text does.

Gemini does aim at being more than text[0]:

> The "first class" application of Gemini is human consumption of predominantly written material - to facilitate something like gopherspace, or like "reasonable webspace" (e.g. something which is comfortably usable in Lynx or Dillo). But, just like HTTP can be, and is, used for much, much more than serving HTML, Gemini should be able to be used for as many other purposes as possible without compromising the simplicity and privacy criteria above. This means taking into account possible applications built around non-text files and non-human clients.

Lots of documents and books contain passages in other languages, it's reasonably common -- I don't get why people are saying this is a niche concern. Books get around that problem because they have controls around presentation, and they're not designed to be consumed visually, not as a semantic, parseable format. But Gemini, at least in theory, is designed to be parseable.

[0]: https://gemini.circumlunar.space/docs/faq.html

If you surveyed people on what features were missing from Gemini and got 10,000 responses how many people do you think would mention "semantic tags for when the language switches mid document" and at what priority when mentioned? Now the same for the top item on the list? Now pick 5 random responses only mentioned once, do you think there is one that could theoretically be used by a large percentage of the population if implemented but even if you had thrown it in the survey itself but still wouldn't have been selected by many people or as a high priority?

I.e. it's not enough for something to be possibly usable by a large portion of people - the userbase have to actually be interested in utilizing it and consider it more important than other things instead. I strongly think if you follow this logic you'll find it's a very niche group that cares this deeply about the semantic language tags. Maybe you truly strongly don't and consider it something everyone would love if only it was there.

That is a really good point, and a really good way of phrasing that point, but I still have two semi-objections.

First, I do think this kind of thing falls into a category of... maybe 'polish', for lack of a better word?

This is something that you're not going to notice you're missing until you think "I want to write one of these quick and dirty display clients that I've been encouraged to build over the weekend, and wow, embedded Japanese is just literally impossible to render well." If you have a document format that's designed to be adaptable and flexible, predicting what you're going to need is difficult.

So maybe the idea is that you're not going to throw transcriptions for comics/manga into this, and nobody would need to search documents for embedded passages in other languages, and stuff like auto-translations in a client wouldn't be useful. But to me it kind of just smacks of, "this is designed for the use cases we could think of right now." I don't know what features will be critically important until I try to do something creative, that's why I value a tightly constrained format that's simple to understand but still offers at least some flexibility.

The other objection that keeps coming up in my mind is: is Gemini actually swamped for feature requests right now? Are they being forced to prioritize features? I'll definitely concede that if you surveyed 10,000 people using Gemini, stuff like a hard limit of 2 subheaders is very likely annoying more people right now than anything to do with language types. But Gemini also doesn't look like it's trying to fix its subheader limit. The impression I get from the FAQ is that this is not a spec that's actively evolving much right now.

And that kind of loops me back around to thinking about polish again. On one hand, I'm inclined to think you're right, this is probably not the first thing on anyone's mind. But on the other hand, "a document with multiple languages in it" is a reasonably common thing that will show up in multiple settings. So I'm still looking at a text format that even just on the surface level doesn't seem to be very good at describing text, even in cases where the solutions seem pretty simple. Having a language switch tag in the spec or just allowing multiple top-level media types in the document doesn't seem like it would complicate the parser spec or make it any harder for me to build a client.

Part of this is, if I'm going to adopt a format, I want it to be well thought out -- I want the authors to have spent more time thinking about it than I have. So if I can immediately see problems before I even start using the spec, it makes me wonder what else I'm going to run into where I'll just be scratching my head over why it was designed that way.

On some level I get where you're coming from, and rendering multiple languages is not the end of the world. You can even potentially work around it, maybe. But it would also be very, very easy to get this right, and I don't understand why the first thought from a spec designer putting together a content type header wouldn't be "what if the content type changes mid-document". This is maybe unfair, but the immediate thing that it makes me think is, "these are people who have not spent much time considering how text documents work, even for simple cases."

But if Gemini was in heavy active development, my opinion would probably be different. I don't know, maybe it is? Are they actively evolving the spec right now? Maybe I'm just being over-critical. But I feel like I shouldn't be able to immediately think of use cases involving basic text that Gemini just can't handle, it should take me longer to see the limitations of a general-purpose text format.

> Lots of documents and books contain passages in other languages, it's reasonably common

Yes they do, and since Gemini allows Unicode, it can cope with this. Note that books typically don't mark what language foreign words/phrases are in.

> But Gemini, at least in theory, is designed to be parseable.

If I was designing Gemini I'd design the source format as something very like Markdown and have it compile to a format which would be a subset of HTML. This would allow <span lang=...> constructs.

> A counterargument would be that traditional text doesn't do this, so a text file format ought not to unless it is aiming at being something more than what text does.

Other text-centric media often emphasize foreign words in some fashion. For instance, in an English language novel foreign language text is often italicized. Same in many articles.

> a matter of justice

Ooof. This kind of wording makes me flinch away.

Reply on news.ycombinator.com