Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do NOT automatically change e.g. #ClimateEmergency to #climateemergency #2295

Open
jdaviescoates opened this issue Dec 4, 2022 · 4 comments
Labels
accessibility Accessibility (a11y) bug Something isn't working

Comments

@jdaviescoates
Copy link

At present whenever I try to add a CamelCase hashtag it automatically gets converted too all lowercase.

I always dislike it when whatever I type is auto-changed by an app (whether that is autocorrection or whatever), but in this case it's not just annoying, it reduces accessibility because people who rely on screen readers really need hashtags to be CamelCase so that they are correctly spoken as two words.

@nolanlawson nolanlawson added bug Something isn't working accessibility Accessibility (a11y) labels Dec 4, 2022
@nolanlawson
Copy link
Owner

I can repro. The repro steps are:

  1. Toot something like #thisisalllowercase
  2. Start composing a new toot
  3. Type #ThisIsAllLowercase
  4. Press enter
  5. It is inserted as #thisisalllowercase

The issue is actually that the Mastodon server is sending it to us as lowercase. So Pinafore just dutifully inserts the hashtag as-is.

The issue does not reproduce if you replace step 1 with tooting #ThisIsAllLowerCase. In that case, you actually have the opposite issue: it will correct you from lowercase to camelcase.

So this looks like a kind of "cache poisoning" issue. Whatever people happen to use (or maybe the first time the hashtag is used?) the server interprets that as the canonical way of representing the hashtag.

Pinafore could try to proactively use the hashtag however you type it, but that would potentially have the opposite issue where lowercase is kept as lowercase rather than corrected to camel case. Ultimately Pinafore can't "know" what the correct casing is. The user might even type it wrong.

I don't have a good solution for this.

@NickColley
Copy link
Collaborator

Would it be too clever to weight the decision making towards camelcase?

So if the user types camelcase and the server is lowercase, pick the client.

If the user types lowercase and the server is camelcase, pick the server.

@jdaviescoates
Copy link
Author

I couldn't actually reproduce the behaviour @nolanlawson described, but to give a bit more info:

In Pinafore, if I type #ClimateEmergency I see this:

image

If I click on the suggested #climateemergency hashtag it changes #ClimateEmergency to #climateemergency.

Whereas if I do the exact same thing using the standard Mastodon web app it doesn't change #ClimateEmergency to #climateemergency

@nolanlawson
Copy link
Owner

nolanlawson commented Dec 10, 2022

@jdaviescoates Right, what I'm saying is that your server is recommending #climateemergency either because a majority of people used it that way, or the first person your server is aware of used it, they used it that way. (I have no idea how Mastodon does it.)

Whereas if I do the exact same thing using the standard Mastodon web app it doesn't change #ClimateEmergency to #climateemergency

Yeah I just tested it locally, and they just ignore the server's casing and use whatever casing you chose on the client-side. So if the server says #UpperCase and you type #uppercase then it'll give you #uppercase.

Would it be too clever to weight the decision making towards camelcase?

@NickColley I don't think this is too clever. I also don't care if we just do what the Mastodon FE is doing right now, which is prefer whatever the user typed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accessibility Accessibility (a11y) bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants