Wikipedia talk:Extended image syntax/Archive 4

Archive 1

Archive 2

Archive 3

Archive 4

Coordinates of the thing the image is of

Is there syntax for or a way to use coordinates for the thing that the image is an image of? E.g. if you have a picture that is of a particular building in a town, the coords for the article will be for the town. The picture may have coords in its metadata of course, but that’s invisible in any article it’s included in. I ask because a friend in real life recently added a picture and wanted to specify exactly where it was, and I realized I’d never seen this use case before.

For example, I took two of the pictures in Loch Muick, and they’re far enough apart to have noticeably different coords. Is there a natural way to add that information to those images in that article? Mike Christie (talk - contribs - library) 02:02, 13 July 2021 (UTC)

The obvious place for such coordinates would be via {{coord}} in the image's caption. -- Michael Bednarek (talk) 03:22, 13 July 2021 (UTC)

I tried this with {{Coord| 56.851082| -3.741822|display=inline|name=Dail-an-eas bridge}} in the fourth image in Glen Tilt. (The documentation for {{Coord}} made me think it was only for the main article location.) It works, but it doesn't look as if anyone ever expected coord to be used this way -- the "name" parameter does nothing in the article, and in the linked GeoHack page it does use it as the (easily missed) page title, but also gives it as the article name in the link back to Wikipedia. It would be nice if the image syntax allowed something prettier to be automatic. For example the Glen Tilt page itself has "Coordinates: 56.833°N 3.776°W / 56.833; -3.776" at the top right, with tooltip text for the button saying "Show location on an interactive map". Can something like that be made to happen when a coord is used in an image caption? Perhaps using the name parameter to make it "Show Dail-an-eas bridge on an interactive map" for the tooltip? Mike Christie (talk - contribs - library) 05:34, 13 July 2021 (UTC)

A facility for image coordinates already exists, although not in the form you want. See "Camera location" in the "Summary" section of the file description page for this image. We could debate the merits of making it more visible/accessible, but in my opinion it would be a bad idea for multiple reasons. It would be unwise to allow the same information in both places, with no mechanism to ensure that they are in agreement. The information in the file description is for readers as well as editors, and it would not serve readers in the long term to protect them from having to learn to use it. My suggestion is to update the file description with the coordinates, revert your change to the caption, and call it a day. 68.97.42.64 (talk) 06:21, 13 July 2021 (UTC)

The popup for WikiMiniAtlas is obscured if {{coord}} appears in the last line of an image caption. This can be avoided by using it earlier in the caption, or by adding 2 line breaks after it. -- Michael Bednarek (talk) 11:05, 13 July 2021 (UTC)

I see what you mean; I added a couple of line breaks and the WikiMiniAtlas popup is now visible. It sounds like that's the best current answer. I take the IP's point about the image file being the natural places for the coordinates to live, but that shouldn't prevent useful reader functionality -- a template that was able to extract the coords from the image file and display a WikiMiniAtlas link would be a nice gadget to place inside a caption. I'll suggest that at VPT. Mike Christie (talk - contribs - library) 12:35, 13 July 2021 (UTC)

I'm with 68.97.42.64 on this. Commons provides a number of templates specifically for this, which are used on file description pages - they include c:Template:Globe location, c:Template:Location and c:Template:Object location. --Redrose64 🌹 (talk) 15:55, 13 July 2021 (UTC)

Thanks for the links; those look like what I was looking for. Mike Christie (talk - contribs - library) 09:25, 15 July 2021 (UTC)

@Mike Christie: those look like what I was looking for. That seems unlikely, since they can't be used in image captions. They are for use in the file description like the example I gave above. that shouldn't prevent useful reader functionality Said functionality is in the file description, provided editors don't go out of their way to prevent readers from learning to use it. Your solution would tend to undermine the intent of the file description, both for coordinates and for all of the other useful information there. Curious and resourceful users of any software poke around for things that might be useful to them, rather than assuming that everything that might be of use is placed in front of them with no effort on their parts. Those users will always be more productive, and that's just a fact of life. Again, it doesn't serve the lazy users to keep them lazy, and in my opinion those users are becoming less common with each new generation. This is from a person who had a long career working with the human-computer interface. You're free to disagree with my philosophy on this, but I wanted to be sure you understand it. The file description is intended to be used. 68.97.42.64 (talk) 20:11, 15 July 2021 (UTC)

Well, there are two people looking for an answer here; my friend, who does want to put locations in captions, and for whom this is probably not the answer they were hoping for, and me. I think my friend's wish to display locations in captions is a reasonable opinion, though I don't find it useful myself, but I understand your point about storing the data in only one location and I think that if locations are ever to be displayed in captions it would be best to have it extracted from the underlying file. That's why I said Redrose64's answer was what I was looking for. Mike Christie (talk - contribs - library) 20:17, 15 July 2021 (UTC)

You seem to equate the file description to Wikidata; i.e. a data repository not to be used directly by readers. I think that's the crux of our disagreement. 68.97.42.64 (talk) 20:33, 15 July 2021 (UTC)

I was under the impression that one of the reasons to store data in {{Coord}} was that it was machine readable -- in fact the template documentation says as much. And you're right that I am assuming that it would be OK to programme something to read it. I can see that wikidata might want to take that data, and that any programmatic access might pull from there instead, but are you saying that it is actually undesirable to read the commons coord data via template coding, for some display purpose or other? I would think that would suffer from the same criticism as above: reading a copy of the data is less desirable than reading the source. Or are you saying that wikidata should be treated as the source here? Mike Christie (talk - contribs - library) 20:50, 15 July 2021 (UTC)

I'm saying that the coordinates should appear only in the file description, where the more resourceful users will find it, remember that they found it, and go whenever they want image coordinates. For those who don't want image coordinates, who I believe comprise a large majority, placing them in the caption creates visual clutter that detracts from the article. And, as I've said, it reduces the likelihood that a reader will ever discover the file description and the useful information often found in the "Description" and "Date" fields, for example. By your reasoning, we should have a way to pull those items from the file description and show them in the caption because some readers will find them informative; all to accommodate readers who lack the motivation to click through to the file description and investigate what's there. That's bad design in my opinion. 68.97.42.64 (talk) 21:16, 15 July 2021 (UTC)

Then we do have a difference of opinion. I agree that it is good for readers to discover the file description, for the reasons you give, and like you I don’t see much value in adding coordinates to captions. But I don’t think we should legislate that data should not appear in one place because it would be better for the user to have to go to another place to see it. How the data should be presented is a design decision that I feel we should leave to the editor working on each instance. Mike Christie (talk - contribs - library) 21:37, 15 July 2021 (UTC)

It's already legislated - MOS:CAPTION says Captions should be succinct; more information can be included on its description page, or in the main text. So we put coords on the file description page, not in the caption. --Redrose64 🌹 (talk) 22:08, 15 July 2021 (UTC)

Copiable text vs mouse-over text

Sometimes we need to substitute Unicode characters with images due to lack of widespread font support. Because a user manually copying the WP text should still get the correct character, the Unicode character is often added to the file syntax after a pipe. But that causes it to display as the mouse-over as well, which isn't useful (the mouse-over is either equivalent to the image, or displays as an empty box or question mark). I was thinking of adding the following text to our instructions to resolve the issue. But would this cause different problems with screen readers? Will a screen-reader recognize what a Unicode character is even if the user doesn't have the fonts to display it?

Suggested text:

The alt text is what gets copied when a reader manually copies a section of Wikipedia text that includes images. This may be useful when an image is used to substitute for a Unicode character that may not yet have widespread font support. The mouse-over, however, should be something more descriptive, as it would be unhelpful for it to look just like the image or, worse, to display as a blank box. The alt parameter provides for this distinction:

[[file:....svg|16px|(mouseover text)|alt=(copiable text)]]

For example,

Information: [[file:Infobox info icon.svg|16px|alt=🛈|The 'information' icon (circled 'i')]].

will display as:

Information: .

Note that the mouse-over display is a description of the symbol, while if you copy the text and paste it in another document, you'll faithfully reproduce the intended text "Information: 🛈." (You may need to install a supporting font for the Unicode character '🛈' to display.)

Hopefully, a screen-reader would handle the Unicode character better than we would with our verbal description. But if that won't work, would it be possible to add a 'character' param to the file syntax that would enable faithful copying of the intended WP text without interfering with screen-readers or mouse-over texts? Please ping me if you respond — kwami (talk) 00:08, 1 January 2022 (UTC)

em sizes

I think em sizes should be perfectly possible to support by now. Just have a bit JavaScript fix up the src-attributes if it turns out the initial guess was incorrect. 92.67.227.181 (talk) 16:31, 18 July 2022 (UTC)