Commons:Village pump/Proposals/Archive/2024/03

Proposal for a common "culture and society" category

Although Culture and Society are different topics, the two are pretty much interrelated and easily confused (this is why {{Topic of country}} template deploys hatnotes at culture and society categories). I think there should be a common Culture and society category, which would cover the two related topics together. Sbb1413 (he) (talk • contribs) 13:21, 9 March 2024 (UTC)

Don't think think that's a good idea – sure they are interrelated but many things are. There are good reasons for why on ENWP these are separate as well. If we were to merge interrelated cats then we should also merge in Economics because society is largely or to a large degree about economics mechanisms/systems/activities. It's more distant to culture so that is one of the rough brief descriptions for why these need to be separate at that layer (there can be and are overlaps and linking subcats). Prototyperspective (talk) 13:28, 9 March 2024 (UTC)

I don't want Culture and Society to be merged into a single category. Instead, I want them to be separate, with Culture and society be a common category covering concepts common to both culture and society. Although economy and society are interrelated, the two are not easily confused topics. Culture and society are both interrelated and easily confused, and many languages combine the two concepts together (for instance, we Bengali people commonly talk about সমাজ-সংস্কৃতি (romanized samāj-saṃskṛti) in Bengali, literally "society and culture"). Sbb1413 (he) (talk • contribs) 13:53, 9 March 2024 (UTC)

Ah okay, that wasn't clear. The idea in general seems good but not this terminology/implementation in specific (for example because it does not include socioeconomic system). I'll ping you from the discussion at a larger-order cat which I think would better encompass these in some way. Prototyperspective (talk) 14:34, 9 March 2024 (UTC)

•  Oppose There was a pretty rigorous discussion awhile back where it was determined that there shouldn't be categories that combine multiple topics. To quote Commons:Categories "We should not classify items which are related to different subjects in the same category. There should be one category per topic; multi-subject categories should be avoided. The category name should be unambiguous and not homonymous." Any categories along the line of "X topic and Y topic" will inherently go against that, including a common Culture and society category. Although I acknowledge that the original proposer is saying they don't want to merge Culture and Society, but that's essentially what will happen if you create a parent category that combines both. People will just media loosely related to both of them in Culture and society and then it will impossible to sort said media into one or the other. Otherwise, there's probably zero reason to have the parent category in the first place.

A better approach is probably to better define the purpose of each category. If it were me I'd stick to a definition for both similar to Googles. I. E. for society "the aggregate of people living together in a more or less ordered community" and with culture "the arts and other manifestations of human intellectual achievement regarded collectively." Or to put it another way, society is a group of people living together in a society and culture is the event, action, or object that clearly shows or embodies said society. Hopefully that's not to convoluted, but essentially Culture should be for images that relate to the output of a society and Society should be for the more amorphous (or non-material) things having to do with the people in it. --Adamant1 (talk) 14:53, 9 March 2024 (UTC)

 Oppose Performances, arts groups, etc. are culture, but not particularly society. Government functions and NGOs are society, but not particularly culture. Yes, some things are in the intersection, but I don't think that we should lose the distintion. It's fine if some cats have both as ancestors. - Jmabel ! talk 17:57, 9 March 2024 (UTC)

Proposed template for simple media labels

Given the size of categories such as Vinyl singles, should there be specific templates for simple labels of physical media? The following is my proposed text for the templates:

PD record labels

This label of a phonograph record consists only of a simple background, logo and/or non-literary text. It does not meet the threshold of originality needed for copyright protection, and is therefore in the public domain.

PD tape labels

This label of a cassette tape or videotape consists only of a simple background, logo and/or non-literary text. It does not meet the threshold of originality needed for copyright protection, and is therefore in the public domain.

PD disc labels

This label of an optical disc (such as a CD or DVD) consists only of a simple background, logo and/or non-literary text. It does not meet the threshold of originality needed for copyright protection, and is therefore in the public domain.

Thoughts? JohnCWiesenthal (talk) 17:48, 4 March 2024 (UTC)

 Question Why are the existing PD templates, such as {{PD-simple}} and {{PD-textlogo}}, insufficient? Why do we need three substantially similar new templates? The Squirrel Conspiracy (talk) 19:29, 4 March 2024 (UTC)

I'm not saying that they're insufficient. I'm just saying that there could be a template that condenses them together (and may also automatically put files in a specific category). JohnCWiesenthal (talk) 00:27, 5 March 2024 (UTC)

Leaning towards  Support, we need public domain templates that are specific to works depicted. @The Squirrel Conspiracy: , PD-textlogo is supposedly for images of texts like logos, but not photos that are derivative works of the works said above. I made {{PD-structure}} specifically for infrastructure and simple structures, as {{PD-ineligible}} does not fit into the said types of works. JWilz12345 (Talk|Contrib's.) 02:13, 5 March 2024 (UTC)

•  Support I was actually thinking about proposing something similar myself since as JWilz12345 points out we need public domain templates for specific types of works and PD-textlogo doesn't seem to cover record labels. Really, it would be great to have similar templates for other types of physical media to though. --Adamant1 (talk) 02:39, 5 March 2024 (UTC)

  What other types of physical media are you referring to? JohnCWiesenthal (talk) 03:03, 5 March 2024 (UTC)

Unified proposal

PD-medialabel

This audio or audiovisual media label consists only of a simple background, simple logo, and/or non-literary text. It does not meet the threshold of originality needed for copyright protection, and is therefore in the public domain. Although it is free of copyright restrictions, this image may still be subject to other restrictions.

We could probably also have a 1= field for vinyl/tape/disc to make subcategories, but I think all three can share one template. The Squirrel Conspiracy (talk) 07:40, 6 March 2024 (UTC)

I also listed labels of audiovisual physical media as well, such as videotapes and DVDs.

Also, the name PD-label is ambiguous. JohnCWiesenthal (talk) 14:22, 6 March 2024 (UTC)

@JohnCWiesenthal: PD-medialabel?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 16:54, 6 March 2024 (UTC)

That seems more suitable. JohnCWiesenthal (talk) 16:57, 6 March 2024 (UTC)

Adjusted. The Squirrel Conspiracy (talk) 19:25, 11 March 2024 (UTC)

Feedback needed on proposed changes to Describe step

Hi all! As part of our work on improving UploadWizard, we are now collecting feedback on some proposed changes to its "Describe" step. Please, feel free to join our discussion in our project talk page, and share your feedback. We are looking for your opinion to improve further our suggested changes. Thanks in advance to those who will participate! Sannita (WMF) (talk) 11:16, 12 March 2024 (UTC)

Comment It'd be neat if the created/published box were two distinct boxes instead, so people reusing from WikiCommons don't have to guess whether the date refers to creation or publication. Moreover, both dates can now be listed. Bremps... 07:30, 19 March 2024 (UTC)

Proposal for history maps template

Hi, if you are interested in "Maps of the history of Europe/Asia/etc" and the template(s) that could provide more order among its subcategories:
Please feel invited to participate in Template talk:Subject by century#Proposal.
Proposed features:

• New navigation template for "history maps" - well, those that are sorted by region/country, and then by century. Such a template is currently not existing.
• Switching naming standard from "Maps of 17th-century France/India" --> "Maps of France/India in the 17th century" (for all history-showing "maps of X in Yth century")
• How to group current and historical countries regionally, within the template (adaptable later)

Hope to see you there. Bring some time and long breath: I don't expect we will wrap up this open topic soon. Also, ancient history is unlikely to be covered, I think we can start with 5th century at the very earliest, but I am rather optimistic about the structure in 12-14th century onwards. --Enyavar (talk) 19:58, 24 March 2024 (UTC)

Image categories by year

The more we have images categories divided up by year, the less applicable the categories become when looking for a good image for an article. In my opinion this syndrome/phenomenon has gotten completely out of hand and done very serious damage to the project. A person of royalty, for example, may have 40 different categories of "So-and-so by year" making it practically impossible to find the best image to use notwithstanding what year it was created. Would it be possible by some kind or bot or AI to duplicate all images sorted by year to the subject's main category? SergeWoodzing (talk) 19:47, 5 March 2024 (UTC)

Year categories are often very useful, especially for maps, charts and so on...the problem you described is not specific to years-cats but lots of other subcats as well. For example, cats for all the countries in Category:Milky Way Galaxy and a place on Earth‎ or Gender subcategories in (1 example) Category:People exercising or and countless other cases.

A problem not quite clear from your description is that also when one intends to subcategorize them by something else such as 'which exercise' it is or what's actually shown in the image rather than common distinguishers, then this becomes very difficult when one has to browse lots of subcategories from where these have then been removed (often even before the cat has been created or despite it missing there; see COM:OVERCAT). There could be further and complementary potential solutions to this issue but for now what I proposed is a Wall of Images view for category pages so you can easily see all images in the subcats on one page like in the search results. And in addition one could sort (and filter) them by things like year or number of uses where these as well as the ability to just scroll through glanceable images make it possible to quickly find a good / fitting image. Prototyperspective (talk) 20:08, 5 March 2024 (UTC)

Thank you so much! I just voted there. --SergeWoodzing (talk) 20:31, 5 March 2024 (UTC)

An option to simply disable subcategories for a specific category would be a lot simpler Trade (talk) 20:41, 7 March 2024 (UTC)

+2 to that. Although there's nothing wrong with Prototyperspective's proposal, but at the of the day there should be multiple options and the issues with people over using "by year" categories should be dealt with regardless of if their idea takes off or not. Really, there should just be a guideline about when it's cool or not to make "by year" categories in the first place. We shouldn't have to create work arounds to compensate for the lack of guidelines or policies about these types of things. --Adamant1 (talk) 02:50, 8 March 2024 (UTC)

A good rule of thumb is that a by-year division should not be the only or primary subdivision of a given category. While by-year and similar categories are valuable for certain purposes, they are not useful when someone is looking for a general image of the subject or a certain aspect. For that, depending on the size of the main category and other factors, it's better to either have the single main category or have subcategories by aspect.

For example, Category:Construction of the Green Line Extension (MBTA) has about 750 files, which necessitated subcategories. By-year subcategories are useful in this case to see what construction activities were happening at what time - but they would be useless to find a picture of a certain station under construction, so all files are also in categories for what portion of the project was being constructed. Pi.1415926535 (talk) 00:08, 30 March 2024 (UTC)

Creation of an AI bot to add structured data to files

Note: I know that most things regarding AI are controversial right now (and for good reason in many cases), but I still think this is an idea worth considering. Also, AI being able to correctly identify items in a photo is still in its infancy, so this is a more long-term proposal/idea.

I hope all is well! AI technology has seen many advances in the past few years, including the ability for it to identify objects in photos. My proposal, simply put, is to create a bot, which uses some form AI, to add and/or adjust current structured data on files. It would mainly identify what is portrayed, from the main parts to the smaller items in a photo, using an identification algorithm, but it would also use the categories included on the file page to also identify object. Structured data is very underused on Wikimedia Commons, but it has wide-ranging effects on how a file is viewed and seen by humans and bots alike. To show an example using this picture, it could quickly deduce that water, glass, sidewalk, skyscraper, etc. are pictured, but then, using categories and possibly text included on its file page, it could deduce that the prominent part of the picture is City Hall, London (Newham), not just a random building, and depending on its knowledge of location, it could tell that the London cable car is pictured, and not just a random structure. Importantly though, it would not adjust anything on an image's file page, including its categories, captions, or descriptions.

I can think of some general reasons why it would be useful for day-to-day use on Wikimedia Commons (not organized in any order):

1. Structured data is mainly used by programs to sort images correctly and properly on the website; so using a computer program to identify structured data would reduce the possibility of lost data due to human error (i.e. it would know what to look out for more in images than humans adding the structured data).

2. It would improve the search engine of Wikimedia Commons, which can sometimes struggle when searching for a broad term or terms with multiple meanings and/or parts.

3. It would allow copy editors, file patrollers, admins, etc. to focus on more important things. As well as that, it would reduce the possibility of new editors incorrectly tagging files (or just skipping the process altogether).

4. Structured data is not like categories, mainly because it doesn't need to be filed into smaller subsections (e.g. using that image again, the term "water" isn't filed under something like "waterways in England"). Though, its identification algorithm could always be fine-tuned to better decide what should or shouldn't be tagged.

If this idea was to be further investigated and approved, I also propose that it be introduced to the community gradually. It could start as an opt-in program, in which users, who approve its use, would allow for it to edit the structured data on their uploaded files only. Then it could go to being automatically used for files uploaded by new users, then older files without structured data. Basically, the AI bot could either be turned into an automatic program like SchlurcherBot or BotMultichillT, or it could stay a permanent opt-in setting in the preferences tab.

Thank you for your time and consideration; I'd be more than happy to answer any questions. Have a great day! -- DiscoA340 (talk) 22:20, 24 March 2024 (UTC)

What you're describing sounds a lot like the Commons:Structured data/Computer-aided tagging project, which was an abject failure. You may want to review how that system worked and why it failed. Omphalographer (talk) 01:16, 25 March 2024 (UTC)

Strong oppose per the abject failure (exactly the words I would use as well) of the computer-aided tagging project. - Jmabel ! talk 09:09, 25 March 2024 (UTC)

Wasn't that AI centuries ago implemented in a suboptimal manner (i.e. mixed with manual edits)? Enhancing999 (talk) 09:18, 25 March 2024 (UTC)

The fact that it required users to manually approve edits was probably the only thing protecting it from adding even more bad tags, like tagging pictures where the sky is visible with "depicts: blue", or tagging logos with "depicts: graphics". Omphalographer (talk) 17:59, 25 March 2024 (UTC)

SD/CAT was apparently set up before 2020 and ran (amok) until 2023. "AI" has developed quite a bit since that time: Midjourney went online in 2022-07, ChatGPT in 2022-11, and has since undergone multiple revisions. Now, there is no documentation available, which advancements SD/CAT went through, but I am certain that we (well-meaning enthusiasts) cannot compare with the tech giants who don't seem to think their "AI" is an abject failure.

I think that a new attempt should at some point be started: some general  Support from me. Although I am still sceptical and don't have any interest in getting involved myself. And yes, a review why the SD/CAT project failed is crucial, before committing the same errors again. Sadly, there is no such review readily available on the linked project page. --Enyavar (talk) 09:25, 25 March 2024 (UTC)

The biggest problem with SD/CAT was that it had no idea what was important for Commons categorization, so it was constantly proposing useless categories ("tree", "stop sign", "building", "person" etc.), often for images that were already well categorized. Yes, AI has advanced, but try feeding an image to even an excellent present-day AI to describe verbally, and then think about how far that description is from actually useful Commons categories. - Jmabel ! talk 11:15, 25 March 2024 (UTC)

Yes, the category tree is way too detailed for any so-called AI. Good thing: Disco's proposal idea talks about structured data (i.e. tagging), not about categories, except to use the existing categories of a file for better tagging. Myself, I only categorize as deeply and intricately as possible, I don't touch the SD-interface with a ten meter selfie stick if I can help it... But I think there are people who'd like to improve the state of SD, and this could be a way. --Enyavar (talk) 13:52, 25 March 2024 (UTC)

The tags suggested by "computer-aided tagging" were actually exactly that: tags, not categories. Also they didn't fit into what is expected in SD as a "describes"-statement (whatever that actually is). Maybe we would just need a search interface that can work with such "tags". Enhancing999 (talk) 10:00, 27 March 2024 (UTC)

instead of trying to build something close to an AGI, how about doing a simple task first?

1. tag the faces for Category:Unidentified people.
2. further, identify any pics with human faces that have not been tagged, and then tag them.

RZuo (talk) 13:58, 25 March 2024 (UTC)

I don't think that would be appropriate. There are a lot of images on Commons which include people but which deliberately don't identify the individuals, either because that's unknowable (e.g. photos of street scenes), or because the subject(s) of the photo would prefer to remain anonymous. Omphalographer (talk) 18:07, 25 March 2024 (UTC)

then those images should not have been in Category:Unidentified people in the first place. what you said is never a problem of the tool, but of correct categorisation. RZuo (talk) 07:40, 4 April 2024 (UTC)

@RZuo: I'm not sure I follow that. The fact that someone is not identified does not inherently mean identification would be either possible or welcome. - Jmabel ! talk 10:15, 4 April 2024 (UTC)

you dont know commons' maintenance practice about the whole tree Category:Unidentified, is it? RZuo (talk) 16:07, 4 April 2024 (UTC)

•  Oppose I want to see a specific proposal with a narrow, defined scope - like we'd see in ordinary bot requests. Blanket authorization without those details is a recipe for trouble. The Squirrel Conspiracy (talk) 00:37, 28 March 2024 (UTC)
•  Support Commons SD has always been animated with the spirit of “machine readable” data (the 1970s called wanting their terminology back) versus the purportedly messy “legacy” of categories and templates. Well, I want to see this proposal greenlit, so that humans can go on working unimpeded while brainless bots and their likewise fans go on piling up more and more detritus onto their huge GIGO machine. -- Tuválkin ✉ ✇ 00:58, 28 March 2024 (UTC)
•  Oppose And strongly per Jmabel and The Squirrel Conspiracy. You can't just make a blanket bot request. And how is this going to be any different or better then the abject failure that we already had attempting to automatically add structured data? Don't tell it would be different "because AI technology" either. If anything AI would just be worse. Otherwise I'd like to see some actual examples of AI being used to do add structured data on other projects has worked out well. We shouldn't be a test bed for new, untested technologies regardless of the potential benefits structured data might provide us though. --Adamant1 (talk) 23:27, 29 March 2024 (UTC)
• The quality we need for Commons seems not to be possible with currently available machine learning tools. I would really like to get a tool that could calculate the view direction of an image based on the location and the time as this is the most crucial and difficult task when identifying what is depicted on the photo. But this is a task not even the tools of companies with many billions of dollars could manage. There is not even a tool that identifies photos of buildings when there is Google Street View data available of the building. We definitely do not have the capacity to build such tools. GPSLeo (talk) 11:18, 30 March 2024 (UTC)

 Oppose, if this is a step towards retirement of all categories. One thing about the usefulness of categories is that these help to track possible violations of copyrights that are subsisting in the images, especially images of France, South Korea, Ukraine, Indonesia, Greece, Slovenia, Lithuania, and most other so-called republics or democracies that do not provide commercial Freedom of Panorama. We tag categories of problematic landmarks with {{NoFoP-category}}, which makes tracking and hunting files down easier. Can the structured data provide similar mechanism that enables users to track and hunt down files that may show copyrighted public monuments? May or may not be, but may not be easy (Visual File Change currently works in categories, not structured data). Note that there are also other derivative works issues, many of which are appropriately warned in the relevant categories, like those of contemporary toy brands, characters, and 20th/21st-century painters and sculptors. JWilz12345 (Talk|Contrib's.) 10:18, 1 April 2024 (UTC)

(??) Nothing in the proposal hinted towards "retirement of all categories", though. Instead, it sounds that working+existing categories are seen as the prerequisite by the proposer, and also that they intend to help users to focus on more important work. Myself, I don't "tag" or do anything with structured data, because I am a firm believer in categories as well. So the daily work of users like you and me is unlikely to be affected at all, I'd say. --Enyavar (talk) 20:21, 1 April 2024 (UTC)

@Enyavar just ask one supporter above (Tuvalkin) who suggested retirement of what they called "messy" category system in favor of structured data. JWilz12345 (Talk|Contrib's.) 23:05, 1 April 2024 (UTC)

I think you're missing a bit of sarcasm in that comment. Omphalographer (talk) 06:17, 2 April 2024 (UTC)

It’s not even sarcasm: I said «purportedly messy» and JWilz12345 misquoted me as having said only «messy». With this kind of natural intelligence around, who needs the artificial kind? -- Tuválkin ✉ ✇ 06:46, 2 April 2024 (UTC)

@Tuvalkin: are you implying I have a low IQ? "Purportedly" is some kind of weasel word, but I think you want to tone down your opposition to the "categories" system by the use of that word. I won't entertain your further false accusations of false IQ against me, using indirect words (weasel words and implicit claims). @Omphalographer: , the user already said it is not a sarcasm. JWilz12345 (Talk|Contrib's.) 10:38, 2 April 2024 (UTC)

@JWilz12345: I will presume your IQ is fairly high, but the point of "purportedly" in a structure like Tuvalkin used is to suggest that someone else purports it to be so, not to endorse the claim; rather the opposite, in fact. - Jmabel ! talk 17:26, 2 April 2024 (UTC)

Indeed, and to ellaborate: My support of this proposal is not mere “rage against the machine” (ha ha) or a way to troll those I think are not steering this project in the right direction. While I personally would do away with all of this, with the whole concept of structured / machine-readable data, which I consider a giant GIGO machine, my view is this: Since the “depicts” statement was meant as a (ironically) unstructured tagging system for random one-time contributers to use in a gamified, non-involved way, implicitly directed to mobile users — then adding A.I. to that brainless, tentative, stochastic (mis)curation is the logical next step. I expect it become a cancerous mess akin to the keywords one can find in Alamy or Getty, and A.I. would simply get us there faster. That will/would vindicate those who think this is a huge misstep without contaminating serious Human curation made via categories and templates, and will/would, I think, also make happy those people up in the WMF foodchain who would marvel to type in "puppy" in the search bar and be granted with a pageful of puppy images, and feel their work is done. In short: A.I. in S.D.? Yes, please and pass the popcorn. -- Tuválkin ✉ ✇ 20:35, 2 April 2024 (UTC)

@Tuvalkin: Do you really think there's no value to structured data what-so-ever? I can't think of any examples right now, but I've been under the impression that it would allow certain things down the line once we fully implement it that can't be done currently for whatever reason. --Adamant1 (talk) 10:25, 4 April 2024 (UTC)

Category:Damaged clocks. -- Tuválkin ✉ ✇ 23:39, 9 April 2024 (UTC)

If, based on what I said above, you think that I am in any shape or form in «opposition to the "categories" system», then you told me all I need to know about your IQ. -- Tuválkin ✉ ✇ 20:23, 2 April 2024 (UTC)

Proposal of dual naming convention for galleries

According to COM:GAL, the naming convention of galleries is very different from the naming convention of categories. Galleries tend to use local names, while categories tend to use English names. This may cause problems with many users who don't understand the local language (for example, you won't know that কলকাতা মেট্রো is about the Category:Kolkata Metro unless you know the local language or have opened the gallery in question).

Therefore, I propose to use dual naming for galleries in the format "[English name] / [local name]". Such dual naming should be used if not more than one non-English local language is associated with the subject. For example, Москва would be renamed as "Moscow / Москва", while India will remain as it is because India is not associated with a particular language. I have seen many galleries that already use dual naming (like New Zealand / Aotearoa, Delhi - दिल्ली). I'm proposing to use slash for dual naming instead of hyphen because slash is more common in such naming. --Sbb1413 (he) (talk • contribs) 18:13, 29 March 2024 (UTC)

• Support with English / Local. Very good idea! --SergeWoodzing (talk) 19:06, 29 March 2024 (UTC)
•  Oppose IMO gallery names should closely, if not exactly, follow the names of categories. And having multiple languages in a single gallery name is needlessly convoluted. Why not just use redirects? There's no reason there can't be a gallery named "Москва" that redirects to a gallery called "Moscow" or visa versa. That's essentially what redirects exist for already. --Adamant1 (talk) 23:31, 29 March 2024 (UTC)

  Users don't always browse galleries through the search engine. They can also visit galleries through the corresponding categories. If a gallery is named in a non-Latin alphabet, users will have a hard time looking for that gallery from the corresponding category. I think my proposal should be limited to local languages using a non-Latin alphabet. Sbb1413 (he) (talk • contribs) 04:03, 30 March 2024 (UTC)

Maybe I'm just misunderstanding what your saying, but wouldn't it be a non-issue if someone is visiting the galleries through a corresponding category regardless of what it's named because galleries show up in the "This category contains only the following page" section of the category? Like if I go to Category:Postcards published by Frank Patterson there's a link to the gallery Postcards published by Frank Patterson in the pages section, which would obviously be for postcards published by Frank Patterson regardless of what the actual name of the gallery is. Otherwise it wouldn't be in Category:Postcards published by Frank Patterson. No one is going to mistakenly think it's a gallery for images of cats no matter what it's called though. --Adamant1 (talk) 04:18, 30 March 2024 (UTC)

But as a side to that, I still think it's helpful if the names of categories and galleries closely match each other for easier entering in the URL bar. I don't think it's helpful if people have to remember when a gallery has multiple names in different languages or special characters if they just want to get there by way of the raw URL. --Adamant1 (talk) 04:23, 30 March 2024 (UTC)

•  Comment, personally, I think that the best solution would be to have the MediaWiki software updated to recognise page titles (preferably through Wikidata) and then translate those titles based on the language a user is searching in. The main gallery name would be in English, the alternative titles would be redirects, and then if you have your standard display language in Russian you'd see all titles in Russian. This would be technically feasible and the current issues with galleries can be considered to be a technical issue rather than a policy issue. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 05:21, 1 April 2024 (UTC)

  I have created {{LangSwitch title}} as an experiment to show the page title on the user's preferred language. However, it looks like {{DISPLAYTITLE}} does not work in Commons, otherwise the title of the gallery India would display as ভারত in Bengali and भारत in Hindi. Unless there's a long-term solution to internationalization of page titles, the best we can do is to use English in gallery names and dual "English / Local" in galleries. Sbb1413 (he) (talk • contribs) 06:50, 1 April 2024 (UTC)

Have you thought about filing a Phabricator ticket? I have to agree with Donald Trung that it should be a technical issue instead needing a change to policy. Especially if we haven't even tried technical fixes yet. Regardless, I think Donald Trung's solution makes sense and you could also see about them supporting {{DISPLAYTITLE}} in Commons. It would probably be worth supporting anyway. --Adamant1 (talk) 08:45, 1 April 2024 (UTC)

DISPLAYTITLE works fine on Commons. However, I think wgRestrictDisplayTitle is turned on, so it may just be for formatting, and not changing the title -- if a "normalized" version is not the same as the actual page title, it may be ignored (Category:Pages with ignored display titles). Currently, the LangSwitch template in that gallery is returning the text "LangSwitch Error: no default" so there may be multiple issues. Carl Lindberg (talk) 05:47, 2 April 2024 (UTC)

under what circumstances will a user see "কলকাতা মেট্রো" without opening the gallery page? RZuo (talk) 07:37, 4 April 2024 (UTC)

•  Comment I have a sneaking suspicion that by 'galleries' you mean the FP Galleries. Using the 'slash' as in "[English name] / [local name]" for the gallery pages would be very bad since it will coincide with how the addresses (wiki and http) are written for the gallery pages (and other pages). Example: Commons:Featured pictures/Places/Natural/New Zealand. We have bots sorting the images into the galleries and inexperienced users trying to get their nomination in the right gallery. Mixing in a character that is vital to coding is not a good idea on COM:FP or any other page. --Cart (talk) 20:54, 16 April 2024 (UTC)

  For clarity, my nomination is applicable for mainspace galleries only. Since FP galleries are in Commons, it makes sense to use only English words there. Mainspace gallery names should not be written as HTTP addresses; they should be named according to the target topics. For example, España should not be written as Earth/Europe/Iberia/Spain, but as Spain / España. The space around the slash make it clear that slash indicates dual naming and not an HTTP address. Sbb1413 (he) (talk • contribs) 06:42, 17 April 2024 (UTC)

Yes, that difference is very clear to you and me and some more experienced code writers. However, after having to correct hundreds of times when normal users get this wrong, I tend to avoid things that are so easy to misspell. --Cart (talk) 07:04, 17 April 2024 (UTC)