Heuristics might work for longer text where the sample is large enough to uniquely identify the language, but for single words there is not enough information. If I write "coin" in my text, for example, am I using an English word, French word, or Irish word? The pronunciation varies drastically, and screenreaders have to know what to say.

My go to anecdote on this is when I returned to Switzerland after several years in the US and walked by a bakery displaying a sign advertising a "Pain Surprise".

If anybody ever opens an S&M themed bakery, the problem will be accentuated.

Not strictly S&M :) but fresh out of the oven Sangak bread of Iran can offer a "pain surprise" followed by culinary pleasure! Picking those hot pebbles off the back of the flatbread on the way home in the morning is a cherished memory of my childhood in Iran.

Oh that bakery has a gimmick where they throw a loaf of bread at your face when you enter.

Spoiler! :-(

Now it won't be a surprise.

At least the pain remains.

Forwarding this to a friend of mine who owns a BDSM-themed coffeeshop...

My vision is good and I also don't know if the word you quoted was supposed to be in English, French of Irish? The point being, a screen reader has no more or less information than a human reader.

It might be better then to invest effort in improving language inference heuristics, which would help in all applications (pdf documents, text files) than to try to build in support in each underlying protocol.

But the screen reader needs to say the word, and the pronounciation of "coin" isn't the same in every language. I don't know about Irish, but it's radically different between French and English, the only sound in common is the "k".

This means that if the screenreader picks the wrong language, then the user has to guess the spelling from the way it's pronounced to understand the text.

Though I'll concede that right now on the web it isn't much better; but that's a failing of publishing tools, not the format.

Seems like the simplest fix is to allow the user to ask the screen reader how a word is spelled.

Not unthinkable that's how a human will read foreign language too.

> a screen reader has no more or less information than a human reader.

Indeed, so why not let the human writer clarify it?

Why do you prefer a resource intensive guessing algorithm that will never have a 100% accuracy over just having an annotation that takes less than 10 bytes and is trivial to parse?

In my opinion there's no reason to even consider the first option, especially with gemini's focus on simplicity in mind. This "what can another little JS library hurt" attitude is what lead to gemini in the first place.

Add language inference heuristics to cover all kinds of formats and now you've got a dependency. Then some people need different settings so you add config files and parsers/dependencies for those. At some point you update the model and now it can't properly differentiate Mandarin, Cantonese and short Japanese phrases anymore. You start adding cross-platform support and other features, and now some people say it's too slow on their Raspberry Pi Zero setup. Bloggers complain as they have to rearrange some quotes via trial-and-error so the heuristics pick up the correct language. Unfortunately that makes it worse for people running the older version 0.7.

After this rant it should be obvious, but: I prefer just adding a ["en"] or similar and stop worrying about it.

PDF actually has support for language tagging, and using it is a recommended part of any guide to accessibility for the visually impaired.

It may be that the language which a quoted foreign-language word is meant to read in was mentioned far back in the text. Human sighted readers will know how to read it, but computers won't yet (and perhaps won't for many years if not decades). However, there are visually impaired people now who need to be guaranteed the same Gemini experience as sighted users.

But some unicode characters are supposed to be rendered differently based on the language of the text that contains them. So this (language tagging) is required even for getting the thing rendered correctly.

Humans need to know what to read, though, too, right?

Obviously humans are a bit better at contextual clues, but.. the information has to be there for a human user to make the distinction.

Well if 'readable by a human' would be enough for screen readers then we wouldn't have to worry about accessibility surely?

Sure. But computers spotting foreign words in context similarly to how humans do is a lot more likely than getting most foreign words appropriately semantically tagged.

Sure. A quoted foreign word might (but not always) appear in some context where any reader will know how to read it. However, for the time being, computers won't, and a screenreader won't manage without adequate semantic tagging.

How would a user not using a screen reader know?

The difference is that the screen reader has to pick a pronounciation which could be wrong, a sighted user reading matches on the letters. Mentally matching from a wrongly-spoken word is harder.

In multilingual text, a foreign word/phrase/snippet is often shown between << and >>.

Not always, but often enough that it's an informal standard.

Gemini does support a `lang` parameter to its mime types, which can be used to indicate a document is in a mixture of languages. That could be enough of a hint for a client to tune its pronunciation.

I do agree though that this is a far bigger problem space than HTML's `lang` attribute is capable of solving. It's not like knowing the language of the text always tells you the unique pronunciation of a string of characters.

Fair point, for example is it read or read? Maybe a better option would be a phonics tag or attribute followed by phonemes that no matter the language of the following word(s) would be able to be spoken by a reader?

I can't wait until I have to annotate all my documents like:

  <sentence lang="en-US-x-Pittsburgh" intonation="falling"><word pos="subject-pronoun" ipa="hi">He</word> <word pos="verb-simple-past" ipa="ɹɛd">read</word> ... </sentence>

That sounds like a fun challenge: make a voice-to-text widget that also generates phonetic or semantic annotations...

That would surely place too great a burden on authors to do it and to get it right.

Reading, as a discipline, is hard at the edges, and lots of humans don’t get it right either!

Not having the ability to do this forces the screenreader to solve the problem, and it's a really hard problem in general - something like "real" that already exists in English but crops up in Spanish contexts fairly frequently is tough, let alone all the proper nouns etc.

On the other hand, there will also be a bunch of cases where people don't do the work to mark this up (maybe not even realising they need to)...

Did you know the chinese character '男' and japanese '男' are spoken totally differently?

Okay, now try to read this comment with a screen reader accurately. Someone who knows chinese, japanese, and english will be able to pronounced both of those words correctly. There's no heuristic that can do the same.

I should be able to annotate each of those characters with whether it's meant to be chinese or japanase.