Wikimedia Commons

Commons:Structured data/Get involved/Feedback requests/Multilingual Captions

< Commons:Structured data‎ | Get involved
This page is presently inactive and retained primarily for historical interest.
If you want to revive discussion regarding the subject, you may try using the talk page (though your voice may not be heard) or start a discussion at the Village pump.

Description edit

The first implemented feature for Structured Data on Commons will involve file "captions." The Caption field will enable users to enter brief descriptions of media in multiple languages. These descriptions will be stored on Commons as structured data using Wikibase, via the MediaInfo extension, instead of wikitext. (Caption information will not be stored on Wikidata.)

On the surface level, the multilingual Caption field (and the forthcoming multilingual Details field) are the structured data versions of the Title and Description fields. The purpose of the new field is the same, but markup capabilities in the new field (and the subsequent new field, multilingual Details) may be different than how the Title and Description fields are handled.

The following wireframes explore designs for the process of adding captions during the upload process, when the contributor using the Upload Wizard.

Full requirements will be determined out at a later date, but some initial requirements/needs include:

  • allowing users to enter captions in more than one language at a time
  • determining an appropriate max character length for the Caption field and how to communicate this clearly to the user
  • handling both right-to-left languages and left-to-right languages
  • options to use the filename (minus extension) as the initial text box value for the caption

Phabricator ticket: T180642

Wireframes edit

The multimedia team would like feedback on the direction of this feature. Please post your ideas at the end of this page, in the Discussion section.

Version 1: Only a Caption field added; no further changes to the Upload Wizard edit

With version 1, the current design of the Upload Wizard can be maintained, with multilingual captions handled in the same way that multilingual Descriptions are handled. There would be minimal changes to the user interface and workflow, and it would be the easiest to implement.

 
Version 1: Minimal change

Designer notes for version 1 edit

  • Adding the Caption field follows the existing design pattern of Description.
  • The “Next” button is changed to “Publish”, to be clear that the Describe step is complete.
  • The minimal change to the UI will mean that people can quickly pick up on the existing design pattern of multilingual description.
  • Should be the easiest to implement, which might be preferable due to a possible complete redesign of the Upload Wizard in the future.
  • Each additional field will make the Describe step in the Upload Wizard even longer.

Version 2: Caption field added; help text visible edit

Version 2 is a “middle of the road” approach. The current pattern for adding metadata in a multilingual field is maintained, but the help text is made more visible to users, especially new or infrequent users.

 
Version 2: Some changes

Designer notes for version 2 edit

  • Echoing the previous mockup, adding the Caption field follows the existing design pattern of Description, and the “Next” button is changed to “Publish”.
  • The biggest difference between version 1 and version 2 is that the help text has been moved from the “i” (information widget) to the surface. Note: All of the help text is illustrative, and would need to be rewritten for accuracy.
  • Placing the help text directly on the surface will help contributors put their information in the correct fields, by explaining what belongs in each field.
  • The other change is the date field, which has been updated to match the Wikimedia UI design system.
  • Note: Just like the previous mockup, each additional field will make the Describe step even longer.

Version 3: Caption field added; help text visible; tabs for extra languages edit

Lastly, multilingual captions can go down a different path. Version 3 uses a new design pattern for adding multilingual fields that can be extended to additional multilingual fields during the upload process, if new ones are added.

 
Version 3, with a language dropdown option

Designer notes for version 3 edit

  • Incorporates the benefits of version 2: the “Next” button is changed to “Publish,” the help text is brought to the surface, and the date field is updated.
  • The biggest difference is the multilingual fields (Caption and Description) have a different design pattern, with the ability to add 3 to 5 additional languages.
  • Combining all languages in one tabbed field will take up less screen space for contributors who add multilingual metadata.

Interaction flows for version 3 edit

The screenshots below illustrate the interaction flow of adding languages in the Upload Wizard with version 3. The images shows what the page looks like, how it changes when you hover over a tab, and then what happens when you click the tab.

Adding a second language edit
 
Adding a language to a caption
Adding an additional language edit
 
Adding a second language to a caption
Removing a caption edit
 
Removing a caption

Discussion edit

The following discussion is archived. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Thank you for participating. A couple of notes on points not necessarily related to the three designs specifically:
  • We appreciate the comments on the confusion with title/caption/description. We're working on making that clearer for everyone
  • The number of people advocating a change in the way we handle filenames was useful feedback that we're researching now

And the takeaway from the designer, PDrouin: Version number 2 offers the best mix of continuity of design and ease of use.

  • Help text is brought to the surface, and will eventually be able to explain the differences between title, caption, and description.
  • All entered captions should be visible on the screen at once.
  • Coordinates located in one field is confusing and difficult to use. Coordinates will remain unchanged from their current form. When the discussion of adding “Depicts” occurs, it would be useful to explain file type and depicts a way similar to this: “The upload wizard should also ask "What is this image?" (it is a photograph, or a drawing, etc) and "What does this image represent?" (represents a dog and a cat, for instance).”

I look forward to seeing you all soon in our next discussion. Find out how to stay in touch with our newsletters and IRC office hours. Thanks again. Keegan (WMF) (talk) 18:12, 7 February 2018 (UTC)[reply]

 
Version 3 with the filename/title field removed. The user just needs to fill caption and description

Please add your comments, questions, or ideas in this section. Feedback on the three possible directions for adding multilingual captions is appreciated. Your comments will help the Multimedia team determine which direction to go.

This discussion period will be open for two weeks, ending 6 February 2018. There is no date set for making a decision on the final design; this is one step in the information-gathering process.

  • First off, I think #3 is probably the one that looks most like the rest of the Web and least like MediaWiki, for all that's worth. So it will be more user-friendly to outsiders in my estimation but make the internal use of the site less smooth. One thing I would like to request is please include mul as an option. That is to say, make "multi-lingual" a language which can be chosen. I want to have multilingual titles or explanations for things (e.g. just the name of a species) but at present, I don't think that's possible. —Justin (koavf)❤T☮C☺M☯ 06:12, 24 January 2018 (UTC)[reply]
  • I'd prefer #2. #3 makes translation between lang 1 to lang 2 too hard (maybe not hard, but annoying). — regards, Revi 11:18, 24 January 2018 (UTC)[reply]
  • #1 and #2 both look good to me. #3 isn't so good, since it means that you can't see all of the different language captions simultaneously, so it probably makes it more likely to have mistakes/inconsistencies between language captions. Thanks. Mike Peel (talk) 12:26, 24 January 2018 (UTC)[reply]
  • The graphical details don't matter so much to me. I'd be more interested in knowing whether there will be some easy process for willing translators to add captions (e.g. via Special:Translate). It would also be nice to know what methods will be used to increase the chances that we show captions in the correct language to users (at a minimum, I imagine we need to add some language code tags in the HTML for each caption; this might be considered obvious but doesn't work elsewhere). Nemo 12:59, 24 January 2018 (UTC)[reply]
  • I'm certainly one of the people who think StructuredData is the way to go but this is very, very confusing. Not the interface, but the new fields. A an uploading user, I wouldn't know what's the difference between "title" and "caption" as well as "caption" and "description" even with the added explanations. I suppose "title" is for the actual filename, like in "Mona Lisa.jpg"? Then just re-name it to actually say "file name", as that's what it really is. I never understood why it was called "title" in the UW anyway. I further guess "caption" is for the name of the work, like in "I name this portrait of a woman I created Mona Lisa"? Then rename "caption" to "title", as that's what it really is. Also, why would you have two different fields for "description" and "details", requiring the uploader to basically enter the same information twice, possibly with a different syntax? Store it at two different places if necessary (description field of the infobox template and wikibase), but have a common entry field for both in the upload form. Please take a moment every once in a while to look at things from the perspective of an average, non-wikimedian internet user … --El Grafo (talk) 13:37, 24 January 2018 (UTC)[reply]
    • Similarly to what El Grafo said, I wonder if the combination of 'title', 'description' and 'caption' confuse (new) users. We already ask for a 'descriptive title' in addition to 'description'. Can a user copy and paste between these 'title', 'caption' and 'description', and then edit? Should the UI help and encourage that? I have to wonder if the proposed 'caption' should simply replace 'description', assuming the existing file pages can stay without modification. (a bold move, but something that will have to happen eventually anyway?) See below for related concerns on mobile. --whym (talk) 13:38, 27 January 2018 (UTC)[reply]
    • We are still working on the naming of these fields. Earlier this year we had a feedback session with the community to gather thoughts on what the fields should be called, and response was mixed. The field labels in these early designs are not meant to represent final thinking. RIsler (WMF) (talk) 06:41, 31 January 2018 (UTC)[reply]
  • I like the cascading changes presented by each of the mockups, and thus like #3 most. Writing the instructions explicitly this way is a great advantage. Saving space by bundling translations seems handy, and better than spreading the translations across the page and below the fold in the worst case. Echoing the previous comment, I have hard time distinguishing the meaning of each field and how they are going to be used. On Wikipedia, in the Media viewer, in the attribution snippet etc. If I write a caption or a description, where will they show up? Why should I write captions if an editor will do it anyway contextually? Could there be live previews of the use cases? – Susanna Ånäs (Susannaanas) (talk) 15:30, 24 January 2018 (UTC)[reply]


  • Whatever you do, please do NOT use "langswitch", an implicit included "langswitch", or functionality equivalent to "langswitch". Unfortunately, "langswitch" was intended for user interface messages from the Wikimedia software itself, and always creates problems when it's used for other things (such as image captions). With the excessively rigid and simplistic "langswitch" approach, it's awkwardly difficult to do basic necessary tasks, such as check on the validity of the translations of image captions or descriptions between different languages... AnonMoos (talk) 16:13, 24 January 2018 (UTC)[reply]
  • my wish-upon-a-star suggestion would be to have something akin to the "depicts" (P180) Property on Wikidata, with links to Wikidata Q-items. This would
    • provide a crude but powerfuly multi-lingual description of the file (because let's face it, nobody will add an Arabic and a Chinese caption to a photograph File:Mirador de las Cíes - panoramio.jpg, but if it had links to Q-Items Q1658753 (Cíes Islands) and Q39715 (lighthouse), we could generate something understandable in these languages)
    • allow powerful thematic search (for instance using SPARQL, or other user-friendly interfaces)
Of course this would require bindings to Wikidata, and it would need to be explained and encouraged since it would amount to a rather new perspective on image metadata for most of our contributors.
Cheers! Rama (talk) 16:59, 24 January 2018 (UTC)[reply]
  • Version number 2 offers the best mix of continuity of design and ease of use. However, I don't understand why you merged the 3 boxes regarding the coordinates. If latitude and longitude are known to most people, heading is much less known. Merging the fields makes it look like the heading is compulsory (which is not currently true). Descriptions need updating, as noted in the notes. Version #1 can be confusing for people not knowing the difference between caption and description, and version #3 can quickly become crowded for many languages.--Strainu (talk) 18:56, 24 January 2018 (UTC)[reply]
  • My question is, how usable are any of these options on mobile devices? Recently the UploadWizard was expanded to include uploads from mobile browsers but it's still very buggy, will these options also be immediately implemented for us Mobile-users? Wikimedia Commons should automatically make any desktop feature available for us Mobile-users, especially since mobile devices outnumber desktops in the real world by a wide margin, but from what I've read mobile adoption of editing Wikimedia Commons is low, in fact the UploadWizard isn't that mobile-friendly. Can these captions be viewed in mobile browsers as well (or maybe they're more like descriptions). --Donald Trung (Talk 💬) ("The Chinese Coin Troll" 👿) (Articles 📚) 13:18, 25 January 2018 (UTC)[reply]
    • I have similar concerns on mobile. At [1] we (volunteer mobile app developers) have been discussing how 'title' and 'description' can be confusing to tell from each other, especially when a lot of filenames are automatically generated numbers — the least descriptive ones — in a mobile setting. Unlike the desktop situation where you already have named it, smartphone users will have to name it and then give a description while uploading. It also doesn't help that it's painful to type and even copy text on a mobile device. I'd be cautious to add another field to enter to avoid increasing the difficulty. I wonder how this will affect the work of the team responsible for the mobile web (https://commons.m.wikimedia.org) and what they are thinking about it. --whym (talk) 13:38, 27 January 2018 (UTC)[reply]
  • @Donald Trung and Whym: We are currently defining plans for mobile support of Structured Data features. However, there are multiple issues that prevent this from being an easy fix. Our design solutions for mobile will most likely be very specific to that use case, so it's best to consider these desktop designs only in the desktop context. We'll have a later conversation about how things can work on mobile web, the volunteer app, and WMF apps. As for title/description, we hear you and are working on making that clearer. RIsler (WMF) (talk) 06:56, 31 January 2018 (UTC)[reply]


  • I like #2. All entered captions should be visible on the screen at once. I agree with others above that it will be important to clearly explain the differences between "title", "caption" and "description". Also, titles are currently allowed to have language versions in Commons and this should be supported in the new interface unless captions will take the place of titles in Structured Commons. (As an obviously example, the Mona Lisa is widely known by other names in other languages.) - PKM (talk) 19:45, 25 January 2018 (UTC)[reply]
  • if information template is not wikidata linked, are not multiple language descriptions a dead end? (this is why i do not use upload wizard; and am editing metadata by hand.) i.e. you are enabling data input, that will be commons bound, without further development of template code. Slowking4 § Sander.v.Ginkel's revenge 00:04, 26 January 2018 (UTC)[reply]
    • Slowking4 The new multilingual fields will not use templates. They will be stored in a Wikibase instance on Commons, and the language-switching functionality will work like the multilingual label and description functionality on Wikidata. RIsler (WMF) (talk) 07:02, 31 January 2018 (UTC)[reply]
  • #2 is my favourite. #1 is okay, but I find #3-#4 overly complicated and "surprising" in terms of UX. My bigger concern is people getting confused about what distinguishes a title from a caption and a caption from a description. Some examples would be helpful, and it might be worth just hiding the description entirely and forcing the uploader to click a "Enter a longer description containing Wikitext instead of a caption in plain text" button if they explicitly want to enter descriptions. -- Gaurav (talk) 16:31, 26 January 2018 (UTC)[reply]
  • For this specific feature & interface, I'd sooner see a combination of #2 and #3. The idea behind #3 is best (plus sign near "English" to indicate other languages) but the horizontal implementation makes it harder to compare and translate against the English version. Instead, #3 configured vertically would be the best of both worlds. Side note: New users don't need to see blank category and lat/long fields—no way they can be expected to use those appropriately. Would be nice to have some back-end processing provide general categories based on the description and visual analysis. czar 13:47, 27 January 2018 (UTC)[reply]
  • Captions are a great idea IF filenames are generated and users are not forced to enter a description. The description should be explicitly optional, and the filename should be either an automatically generated identifier (similar to Wikidata QIDs), or at least a string automatically generated from the caption. See the "What to leave out" section of the W3C's instructions on designing good URIs: The URI (and that means the filename for us) must not contain the subject. Words are becoming obsolete or politically incorrect or start meaning completely different things at an ever faster pace in all languages around the globe, so we really must get rid of them in our file URIs. I am sure that in no time the Visual Editor will drop filename and only show captions, and wikicode editors like me 1) prefer short URIs when adding images 2) When reading wikicode written by others, captions are more useful than filenames. Compare: Which one is the most readable? [M43693|Black person at a bar in Williamsburg, 1954] or [***OFFENSIVE WORD REMOVED BY RIsler*** at groggery today in the suburb east of town.jpg|Black person at a bar in Williamsburg, 1954] (let's say the picture was uploaded when such words were commonly used, a dozen years later needless to say anyone sane would want to rename the file, which is exactly why filenames should not contain words and just be identifiers). Also, have you ever tried inserting right-to-left filenames (for instance Hebrew or Arabic) into wikicode? If yes you know why identifiers are the way to go. Syced (talk) 05:16, 29 January 2018 (UTC)[reply]
    • Edited for language. Not appropriate. Consider this a warning. RIsler (WMF) (talk) 17:32, 30 January 2018‎ (UTC)[reply]
      • @Syced: very bad inappropriate example. Please pick your words and examples more wisely. This does touch on a point that I recall discussing several times (probably also with Ramsey): Currently filenames on Commons have two functions:
        1. Title of the page (George Catlin - William Clark - NPG.71.36 - National Portrait Gallery.jpg)
        2. Identifier to link to the file (https://commons.wikimedia.org/wiki/File:George_Catlin_-_William_Clark_-_NPG.71.36_-_National_Portrait_Gallery.jpg)
      • Overwriting existing files and file renaming are a frequent source of problems because these two functions collide. Wikidata solved this problem by having an identifier (Q47510637) and label (William Clark). I would like to have that for Commons too, but the big difference between Wikidata and Commmons is that Wikidata could start from scratch. We don't have that luxury here. I'm not sure how feasible it is to try to switch to a system like Wikidata here.
      • As for the current designs. These confuse me. Should the "Title" field in the wizard be renamed to "filename" and instead of caption use title? Multichill (talk) 22:40, 30 January 2018 (UTC)[reply]
        • Yes. We're researching making a switch from the filename system. However, as you point out, there are consequences to that kind of decision. They may not be insurmountable, but they do need to be carefully considered. As for title/caption, as part of the filename issue we're also looking into how we rename all these things so they make sense. Community input so far about this has been valuable. RIsler (WMF) (talk) 07:06, 31 January 2018 (UTC)[reply]
        • FWIW Special:Upload calls that field 'Destination filename' instead of 'Title' CParle (WMF) (talk) 09:45, 31 January 2018 (UTC)[reply]
    • You removed the offensive word from the filename: That's what anyone would do, and that's why in 30 years you will need to rename 1% of all files on Commons (languages and public perception of words change faster than ever), thus breaking all third-party apps that rely on Commons media (I have several). That's why we absolutely must get rid of filenames, it will be one of the main benefits of Structured Commons. I have not seen any discussion about this in Structure Commons, if there has been any please kindly point to it, thanks Multichill! Syced (talk) 02:43, 31 January 2018 (UTC)[reply]
  •   Question So we have had a title and a description, and we will also have a caption? What's the purpose to have a new field? Since we already have difficulties to get meaningful titles and descriptions, this looks redondant to me, or even worrisome. Otherwise, I like better #2 and #3. Regards, Yann (talk) 03:28, 31 January 2018 (UTC)[reply]
    • For each picture, we should store all information we have about it, even if it is a very long story with everything explained about all background details. This is the description. On the other side, if I understand correctly we also have a need for a shorter text that can be used as a caption. For instance, my picture of the group photo at the UN conference 2018 will include the name and function of everyone present on the picture as well as what they discussed and why Takashi Shimizu is not in the picture because he had an emergency call from his family. The caption could be "Group picture at the UN conference 2018". Of course, when including this picture in the article "Formal wear" you would write a custom caption: a single picture can be used to illustrate several unrelated topics. Cheers! Syced (talk) 05:14, 31 January 2018 (UTC)[reply]
      • How is that different from the title? Regards, Yann (talk) 08:50, 31 January 2018 (UTC)[reply]
        • Excellent question! And my answer is: we don't need a title anymore. By replacing the old "title" feature by a "caption" feature, we gain multi-language support, which is good. To reference files from wikicode or elsewhere, we should have an opaque identifier, which is independent from any language. Syced (talk) 09:12, 31 January 2018 (UTC)[reply]
  • @Yann: The difference between description and caption at this time is three-fold: captions are "short descriptions" so may not include nearly all the same details, captions are stored in Wikibase on Commons instead of free-field wikitext, and captions can be stored and served in multiple languages on demand based on the user's preference. All of these captions will be able to be surfaced through future ways of searching, something that the current storage of Description does not offer. This is a simplified summary, but it's the big picture of the difference in conception. Keegan (WMF) (talk) 18:34, 1 February 2018 (UTC)[reply]
  • As is visible in this discussion, many users think that three is too many fields. So, now is actually the best time to have this conversation about titles. Switching from title+descriptions to captions+descriptions will be much easier than switching from title+descriptions to title+captions+descriptions, and easier for WMF to explain. Cheers! Syced (talk) 08:25, 3 February 2018 (UTC)[reply]
  • @Syced and Alina data: the concerns about having too many fields are relative and valid. Right now the conversation is around what some potential designs could look like, based on existing workflows and building new ones on top of it. The process of how workflows could be changed, and what is in there, is a different one. It will begin in the next few weeks with a conversation about the ontology of structured data, the What Goes Where, and In What Order talk. This consultation will help begin to talk about things to include and exclude in structured data, and will be a better venue for what you want to talk about. To make sure you hear about it, f you or anyone else would like to be notified on your talk page when we have new consultation requests for Structured Data on Commons, you can sign up for the focus group. I cannot stress enough that we are not at the actual decision-making stage yet, this is all information gathering to make those informed decisions in the near future. Keegan (WMF) (talk) 22:43, 5 February 2018 (UTC)[reply]
  • As for the design I prefer #2. As for the content: the discussions above is really important. Title+caption+description IS confusing and WILL lead to empty fields and mistakes. In my opinion the following things should resolve these problems:
  1. there should be identifiers instead of meaningful titles for the file name and the web-addresses - at least for all the new uploads from now on;
  2. 'title' should be removed as it is used for different things: you can have a title for an artwork and a file name for the reproduction of the artwork - this is confusing,
  3. only multilingual field 'caption' should stay and become an obligatory field with explicit explanation,
  4. 'description' and 'other information' are again almost the same and are confusing -> one of the two should be removed;
  5. short 'caption' and long 'description/other information' fields should visually not be next to each other in the Upload Wizard, so it is clear that the one is for short input and the other for a long story about everything that you can see on or know about the picture. The new Strcutured Commons should invite people to put as much data in structured fields and only in the very end if there is no other possibility use the free text description - Alina data (talk) 10:38, 5 February 2018 (UTC)[reply]
  • The proposal seems off the mark.
    • I'll second and extend Nemo's remark. Why worry about adding additional descriptions and captions at upload if one will want to do the same after the file is uploaded? In other words, a user should have the opportunity to simply upload the file and then go through an operation of adding details. Any subsequent user should have the same opportunity. Why should there be an upload app and a modify app? I don't expect the initial uploader to be multilingual, but I do expect many users to be fluent in other languages and add details/translations.
    • I'll second AnonMoos. Documentation for langswitch deprecates it for file description pages. I prefer to see the multilingual descriptions: it gives me a sense of accuracy and detail. But if SD is about translated descriptions, then it misses the mark and just becomes Google-lite. Searching text for information is not abstract. A Bulgarian user does not get the benefit if an image does not have a Bulgarian description. The effort above is focusing on something that is little different from the current environment. SPARQL on a text description does not get me much. The effort above is not showing vision but rather conformity. It's not even matching technical efforts by others or the promise re the Sloan Grant: automatic translations of "horse".[2] A better notion is not to think of captions and descriptions but rather focus on the potential queries. List all photographs of New Zealand lighthouses. Did Picasso ever sketch a lighthouse? List all images of 17th century lighthouses. List all images of Winston Churchill. List all images that contain Churchill, FDR, and Stalin. List all images of Gothic cathedrals. List all images of castles in Scotland.
    • I'll second Rama, but I think the current mindset of SD is not there to get what Rama sensibly wants. SD seems to have a forms view of the image description: the user is filling out a MediaInfo form about the image rather than making Wikidata statements about the image (the SD schema has an interrupting indirection which is the form).
    • The simple data above seems to be in the wrong place. If I take a picture with a modern camera, the JPEG has the latitude and longitude. That information should be in the file rather than elsewhere (a copy of the data can be elsewhere).
    • SD seems to have a parochial view: all the data is on Commons, but that runs counter to the idea that Commons is a repository of images to be shared. If somebody grabs a JPEG or an SVG file from Commons, then the file has been separated from its structured data. That's not what the rest of the world is doing. Authors, rights, titles and descriptions are embedded in the file. If the file is copied, then that information travels with it. If a tool is going to ask for a creation date or a location, then that information should be inserted into the file. SD should then extract that information from the file. The examples above should be part of a simple image metadata editor rather than an SD app.
    • The discussion above ignores the copyright / database issues brought up by Fae. SD should insist that titles, descriptions, and captions that are added by Commons users are CC0 and should be tagged as such. Titles, descriptions, and captions that are gleaned from, for example, GLAM collections should maintain their appropriate rights (e.g., CC-SA-BY 3 description even if the underlying image is now out of copyright).
    Glrx (talk) 00:49, 6 February 2018 (UTC)[reply]
  • While description can wait until later, my point of view is that a picture is not worth much if the author does not enter at least the caption, so I am for asking it at the same time during or immediately after the upload. The upload wizard should also ask "What is this image?" (it is a photograph, or a drawing, etc) and "What does this image represent?" (represents a dog and a cat, for instance). There is a balance between ease-of-use and precision, but it will probably be easier and finer and more multilingual than the current categorization system. I guess Commons categories as we know them will disappear, and the file samples will definitely be helpful to determine how they can be replaced by wikibase properties.
  • At first I disagreed with User:Glrx's idea of modifying files, I began writing a reply presenting arguments against it, but finally I realized that s/he is right. While we should keep the original as preciously as sacred relics, the files that we serve (under the "Download" buttons) should be "fixed", for instance if the GPS coordinates in the original were erroneous, they should be fixed by the software before the download takes place. The filename should also be changed from "M2352938" (or whatever filename or database identifier is used internally) to {caption in the user's language or fallback} + {correct filename extension}. Syced (talk) 09:23, 6 February 2018 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Structured_data/Get_involved/Feedback_requests/Multilingual_Captions&oldid=781429077"