VisualEditor: When inserting a new link (not annotating on existing text), the suggested link is capitalised even if your input text isn't, so leading to unexpected capitalisation of link anchors
Closed, ResolvedPublic

Description

When adding a new link to an existing page, the text is automatically capitalized, even if the user entered the text in lowercase. Many links don't need to be capitalized, so users shouldn't have to clean up after VisualEditor decides to capitalize them.

Note that when you're adding a new link to a page that doesn't exist, the inserted link preserves the capitalization that was entered by the user (which is the expected behavior)


Version: unspecified
Severity: major
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50945
https://bugzilla.wikimedia.org/show_bug.cgi?id=50678
https://bugzilla.wikimedia.org/show_bug.cgi?id=50745
https://bugzilla.wikimedia.org/show_bug.cgi?id=53566

bzimport set Reference to bz50452.
gpaumier created this task.Via LegacyJun 30 2013, 10:19 AM
Elitre added a comment.Via ConduitAug 22 2013, 12:08 PM

Is this still happening, Guillaume? I can't reproduce it.

gpaumier added a comment.Via ConduitAug 22 2013, 12:51 PM

Yes, I can still reproduce it. Note that I'm talking about the behavior when you enter Ctrl+K and type text, not the behavior when you add a link to existing text.

Esanders added a comment.Via ConduitAug 26 2013, 11:09 PM

Are you talking about:

  1. Ctrl+K
  2. Type a lcase work
  3. Press enter twice

because that's the only way I can reproduce, and after the first press of enter it shows you that it has capitalised the word due to autocomplete?

gpaumier added a comment.Via ConduitAug 27 2013, 9:04 AM

(In reply to comment #3)

Are you talking about:

  1. Ctrl+K
  2. Type a lcase work
  3. Press enter twice

Yes. For step 3, it also happens when you click on a suggestion.

Thryduulf added a comment.Via ConduitAug 29 2013, 6:56 PM
  • Bug 53495 has been marked as a duplicate of this bug. ***
Thryduulf added a comment.Via ConduitAug 29 2013, 6:58 PM

From bug 53495:
Currently whenever a user enters a link when no text is selected the first
character of the displayed link is always capitalised. This is often incorrect,
e.g. in the middle of a sentence or for articles like [[iPhone]] or [[grep]].

Especially until bug 50678 is fixed, correcting this is not at easy or
intuitive.

So, at least until bug 48789 and bug 50945 are fixed and the display text is
settable in the dialog, and probably beyond that, it would be best if the
displayed link used the same case as the search term entered. i.e.

User entry -> wikitext equivalent of desired output
Green -> [[Green]]
green -> [[green]]
iPad -> [[iPad]]
HAMmer -> [[Hammer]]
london -> [[london]]

Yes, this will result in some wrong captialisations, but no more than at
present and will only be temporary (as noted above)

Jdforrester-WMF added a comment.Via ConduitAug 29 2013, 7:04 PM

Clarifying what this is in the title:

New link annotations' anchors get their first character capitalised, even if you didn't want that

->

When inserting a new link (not annotating on existing text), the suggested link is capitalised even if your input text isn't, so leading to unexpected capitalisation of link anchors

The problem is in the link suggester (it's the same behaviour in category and template selection, except that those always capitalise the first character so no-one cares.

When you trigger the link inspector on no selection and type in "foo", you are given suggestions like:

  • Foo
  • Foobar
  • Fooian

Selecting any of these picks not just the target, but also the text of that target as the anchor (good) and the capitalisation of that target (less good).

However, if I've typed "foo", did I definitely want [[foo]] rather than [[Foo]]? Should we show both [[Foo]] and [[foo]] options in the list if you type in "foo", but only [[Foo]] if you type in "Foo"?

Thryduulf added a comment.Via ConduitAug 29 2013, 7:31 PM

The best thing, as noted at 48789, is for there to be two input boxes - one for the link target and one for the displayed text.
Until that happens I think we should preserve the case of the input, as even if that isn't what people want it is easily possible to change and pretty intuitive how to do it - ie, type "foo" get "[[foo]]" but wanted "[[Foo]]", all you need to do is type "Foo" instead. The current behaviour means you get "[[Foo]]" regardless of what you want or do.

When the second input box is added then we should use the case as input as the default.

The only other thing I can think of is for VE to read and respect things like {{lowercase title}}. Once it does that then it should also respect things like {{correct title}} for a default display text, and we should probably create a {{Proper noun title}} for titles that should always be capitalised by default. Or rather than using templates we could move the title information into page metadata. I have no idea whether any of this is practical, but if it is I guess it would be better as one or maybe two separate bugs.

Jdforrester-WMF added a comment.Via ConduitAug 29 2013, 8:38 PM

(In reply to comment #8)

Until that happens I think we should preserve the case of the input, as even
if that isn't what people want it is easily possible to change and pretty
intuitive how to do it - ie, type "foo" get "[[foo]]" but wanted "[[Foo]]",
all you need to do is type "Foo" instead. The current behaviour means you get
"[[Foo]]" regardless of what you want or do.

Possible, but a bit messy when writing certain articles like BLPs where most link targets will be proper nouns.

The only other thing I can think of is for VE to read and respect things like
{{lowercase title}}. Once it does that then it should also respect things
like {{correct title}} for a default display text, and we should probably
create a {{Proper noun title}} for titles that should always be capitalised by
default.

Or rather than using templates we could move the title information into page
metadata. I have no idea whether any of this is practical, but if it is I
guess it would be better as one or maybe two separate bugs.

Yes, certainly for this to be used in VisualEditor it would need to be a proper feature and not one hacked into a template; I think creating a bug for MediaWiki having page-level meta-data about the correct display of a page's title would be great, yes.

Thryduulf added a comment.Via ConduitAug 29 2013, 9:32 PM

(In reply to comment #9)

I think creating a bug for
MediaWiki having page-level meta-data about the correct display of a page's
title would be great, yes.

Done, see bug 53566

gerritbot added a comment.Via ConduitAug 30 2013, 10:10 PM

Change 82054 had a related patch set uploaded by Esanders:
Offer the typed text as a link suggestion if the page is valid

https://gerrit.wikimedia.org/r/82054

gerritbot added a comment.Via ConduitSep 4 2013, 12:32 AM

Change 82054 merged by jenkins-bot:
Offer the typed text as a link suggestion if the page is valid

https://gerrit.wikimedia.org/r/82054

Jdforrester-WMF added a comment.Via ConduitSep 4 2013, 12:34 AM

The above changes behaviour if the user types in the entire anchor in a different case (e.g. iPhone vs. IPhone), which is I think sufficient to close this bug for now; different ways of suggesting links might want to come off the outcome of bug 53566. (It will be deployed to the cluster from Thursday 5 September, and to Wikipedias on Thursday 12 September).

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.