Comment by jrochkind1 | Hacker News Reader

Comment by jrochkind1 | Hacker News Reader

Parent Full thread

By "niche" here, we mean affecting very few people, I think?

Then "accessiblity" in general is not niche, it effects everyone or almost everyone.

But "accessibilty" is a broad concept, applying to all sorts of different unrelated needs. Vision impairment, cognitive differences, mobility needs, etc.

Some of them effect more people than others. Some of them will be "niche", effecting few people. it is just a fact, right? It is faulty logic to say that because "accessibility" effects everyone, every single accessibility accomodation is also therefore of use to everyone. It's not so.

How much need is there for multi-lingual screen-reading? I have no idea. It's obviously not universal -- I don't need it for instance, although I may need other kinds of accessibility attention -- but there may be lots of need for it! But we can't prove it one way or another just from language games around the general concept of "accessiblity".

Whether developers ought to accomodate even niche accessibility needs is a separate ethical or practical argument.

> By "niche" here, we mean affecting very few people, I think?

A text only web is pretty niche. Can this project really afford to start slicing off additional portions of its userbase? I agree that multilingual blind users are in the minority, but those users are probably the most likely of anyone to be interested in a text-only web.

And even ignoring blind users, it's just... what's the point of any of this if Gemini is not going to be semantic? It's like religiously adhering to the GNU principles of always printing human-readable text on the command line, and then not shipping a shell with a pipe command or any text parsing capabilities. From just about any perspective, whether you're worried about accessibility, or parsing, or search -- it's useful to know what language a document/section is in.

One of the few advantages of having a limited, well-defined, non-extensible spec is that it's easy to work with and write parsers around. And immediately Gemini is just saying, "filtering sections by language? Good text-to-speech support? No need for that."

If nothing else, Gemini is theoretically built specifically for generality[0], and it's already guaranteeing out of the box that it can't be used well with voice assistants. Those things aren't a fad, a general-purpose document format kind of needs to support them. And trying to have a voice assistant that intuits the current language is just a really bad system for everyone.

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

You could still do multi-lingual content just by having it in separate .gmi pages and then linking between then. And your screenreader could follow links by embedding the text in the other language in the first page.

I agree with you that those behind Gemini should take this issue seriously, but maybe something like what I've mentioned is what they have in mind as their answer. Not sure.

One of Gemini's explicit goals is for client implementation to be so simple as to be a weekend project for the average developer.

That's one reason inline links are not allowed (they have to be a separate line): it would complicate the parser.

It shouldn't be too hard to add a "language switch" line, so that sections (but not words within sections) can be different languages.

Making Wiktionary or Etymonline in Gemini would require you to add a line break for each foreign word, which seems annoying to read.

I don't see though, why the spec can't allow links that are written on a newline for markup simplicity but displayed inline? And then the same could be done for foreign words.

you seem to be confusing "any" with "all".

it would be nice to have more accesible interfaces for everyone. helping one person doesn't mean you fail to help everyone, in fact, helping one person in terms of accessibility generally has the effect of helping everyone.

we're asking for some access. not all the access. scoped properly, it doesn't seem to be that insurmountable of a development goal, honestly.

> in fact, helping one person in terms of accessibility generally has the effect of helping everyone.

How does facilitating multilingual screen-reading help someone who is neither multilingual nor uses a screen-reader? How can it possibly help everyone? (like literally 100% of people, you are suggesting?) What am I missing?

- better client displays (allowing a user client to switch out fonts based on the language, for example)

- better support for users who are not multi-lingual (a client could try to auto-translate sections that are not in the user's native language)

- better search capabilities (find me all documents that contain a French passage)

- better voice-assistant support (if a document is being read out loud for any reason, it would be nice to be able to handle multiple languages well. This also combines with the auto-translate capabilities above.)

Basically, all of the reasons why Gemini includes a "lang" attribute in the first place, except recognizing that parsers and clients want to be able to make use of that on a section-by-section basis rather than purely at the document level.

Sometimes documents are big and expand across multiple languages. It's just a bad abstraction in general to assume that each document would only have one language type[0]. Documents/books in the real world don't work that way, and a document format that can't accurately represent a giant portion of classic literature isn't a very good general-purpose format.

[0]: yes, technically Gemini allows you to specify multiple top-level languages, but that's not useful for anything. If I'm parsing a document, I don't want it to tell me "hey, there's some French in here somewhere, good luck!" Tell me where it is.

Reply on news.ycombinator.com