Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

gemini:// space

spwhitton.name

Post reply on HN
Print view View original

91–100 of 177 posts

Re: gemini:// space

#91

Post by _wolfie_ »

amadsen wrote: post #22
Mediterraneo10 wrote: post #14

Earlier quoted context omitted.

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 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 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.

Re: gemini:// space

#92

Post by fckthisguy »

wwn_se wrote: post #26
Mediterraneo10 wrote: post #14

Earlier quoted context omitted.

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.

How would a user not using a screen reader know?

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

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

Re: gemini:// space

#93

Post by fckthisguy »

robryk wrote: post #48
Mediterraneo10 wrote: post #12

I really like the idea of having a more bare-bones text-only web, 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 visually impaired should not be second-class citizens in any new internet…

This is first I'm hearing about the lang attribute (edit: for something smaller than the whole document), so I'm curious how commonly is it used in the "web at large". Do you know?

I live in a multilingual country and don't see it used as often as I would hope, even if it's more common here than elsewhere.

I often see it on elements/sections of sites that link to content in another language.

Here, German is the "main" language and lots of documents are available in German but not English. If you need to link to a German page/doc from an English one, it's not uncommon for the link text to be in German too.

Re: gemini:// space

#94

Post by alpaca128 »

amadsen wrote: post #22
Mediterraneo10 wrote: post #14

Earlier quoted context omitted.

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 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.

> 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.

Re: gemini:// space

#95

Post by mattmanser »

cabalamat wrote: post #82
Mediterraneo10 wrote: post #79

Earlier quoted context omitted.

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…

> 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 tag). A counte…

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.

Re: gemini:// space

#96

Post by bzb6 »

Mediterraneo10 wrote: post #79
cabalamat wrote: post #78

Earlier quoted context omitted.

> 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 t…

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…

> a matter of justice

Ooof. This kind of wording makes me flinch away.

Re: gemini:// space

#97

Post by efsavage »

madeofpalk wrote: post #81
simias wrote: post #65

Earlier quoted context omitted.

Multilingual accessibility seems to be a niche within a niche. I'm bilingual but I seldom read mixed-language content. And even when I do I wonder how often the author can/bothers to include the markup for it. If I write "ceci n'est pas du français" here for instance it'll remain untagged. I think the only websites where you can reliably expect the text to be tagged correctly are dictionaries and the like, where it c…

Just to be really clear here - accessibility isnt a "niche". People being able to use software (which presumably is what gemini is about??) is important for everyone, obviously. Imagine saying accessability hardware - like corrective lenses - is niche.

Also, accessibility numbers are almost always measured very low because people who need those affordances aren't even attempting to use it, since so much software ignores it. Years ago when browsers let you lock font sizes, I heard many times from both designers and usability "experts" alike, "well, it's not a big deal nobody ever changes the font anyways", not realizing their own self-fulfilling prophecies.

I've always loved that the Kindle, even with such a simple use case as reading a book, supports so many ways to see it and interact with it, so even people without vision or motor problems can use it the way they like best.

Re: gemini:// space

#98

Post by computeruser000 »

madeofpalk wrote: post #81
simias wrote: post #65

Earlier quoted context omitted.

Multilingual accessibility seems to be a niche within a niche. I'm bilingual but I seldom read mixed-language content. And even when I do I wonder how often the author can/bothers to include the markup for it. If I write "ceci n'est pas du français" here for instance it'll remain untagged. I think the only websites where you can reliably expect the text to be tagged correctly are dictionaries and the like, where it c…

Just to be really clear here - accessibility isnt a "niche". People being able to use software (which presumably is what gemini is about??) is important for everyone, obviously. Imagine saying accessability hardware - like corrective lenses - is niche.

Fair in general, but for this example accessible writing is maybe more the issue - whoever made the content should avoid mixing languages if they want to be accessible.

Re: gemini:// space

#100

Post by dancek »

Arnavion wrote: post #7
prepperdev wrote: post #3

Gemini is a cool piece of simple tech. I had a genuine pleasure reading the spec: https://gemini.circumlunar.space/docs/specification.html I've entertained an idea to build a set of tools for contemporary development (version control, code review, CI, etc) which would only speak Gemini. That would be both the UI and the API. Blockers came fast: * no way to upload anything that exceeds 1024 bytes, * escaping is subtly…

The one thing that puts me off the most is the limit of two levels of headings. (There are three, but you need one for the page title, and it would be awkward to reuse the "title" heading level for "section" headings. Even if you got over this awkwardness, three levels is still annoyingly constraining.)

IMHO you could just use

    # Page title
    
    # 1. First heading
and go from there. The format is meant to be human-understandable, not machine-readable.

But your point is a good one, and made me wonder how the documentation of Gemini itself handles the issue. And behold, the Gemini FAQ [0] itself has the first level 1 heading as

    ## 1. Overview
and the second one as

    # 2. Protocol design
That's really disturbing once you notice, but I'd wager that hundreds of people have read the page and not noticed.

[0]: https://proxy.vulpes.one/gemini/gemini.circumlunar.space/doc...

Post reply on HN