Talk:Main Page
- For more info about Commons, see our welcome page.
- For more info about reusing media you find here, see Commons:Reusing content outside Wikimedia.
- To request an edit to be made to the caption of the Picture of the Day, make your request here by using {{edit request}}.
- Similarly, to request an edit to be made to the caption of the Media of the Day, make your request here.
- Please see Commons:Village pump or Commons:Help desk for discussion of topics other than the Main Page.
- For experiments and tests, please use the Commons:Sandbox
This page is protected: Because of excessive spam/offtopic this page is semi-protected. New or unregistered users can ask their questions at the help desk.
|
Restore localised main page pointer
This was introduced in 2010 (Main Page edit 1, MainPages.js edit) but was seemingly lost by accident when in 2013 a new header was introduced (archived discussion, Main Page edit 2).
I'm leaving this message here to have a place to point to in my edits that will remove the broken JS related to this, and to my edit that attempts to restore a simpler version of it (based on Lua, instead of late and janky JavaScript code).
--Krinkle 02:04, 18 April 2021 (UTC)
- @Krinkle: The very purpose of this JS solution was to use
navigator.userLanguage
instead of{{int:lang}}
(or anything else that depends on the user’s Commons language settings). Logged-out users will often have their Commons language set to English even if that’s not their preferred language. You could insert all links to the main page in a hidden state (e.g.<div class="localised-main-page-link" lang="de" style="display:none;">[[Hauptseite]]</div>
; instead of inline styles, you could use TemplateStyles as well) and dynamically show the one that matches using JS, utilizing the language fallback chain if possible. This would still mean an interdependence between Lua and JavaScript, but if you add a comment to the Lua module, hopefully it won’t be broken again. Unfortunately this can’t be solved on server-side without a massive amount of cache size growth (it would mean the output should be cached separately for each and every differentAccept-Language
HTTP header coming from clients, which would also open a door for DoS attacks using arbitrarily long language lists). —Tacsipacsi (talk) 10:29, 18 April 2021 (UTC) - As a side note, to optimize for maintenance costs, the list of main pages could probably be stored in JSON, which could be accessed by both JS and Lua, so that there’s one authoritative list of main pages instead of several ones that are bound to become out of sync. —Tacsipacsi (talk) 10:33, 18 April 2021 (UTC)
- @Tacsipacsi: I understand that that was the original reason, but I think much has changed since then. We now have the AnonymousI18N gadget, which considers http referers (e.g. Wikipedia language), and
navigator.userLanguage
, to actively invite users to switch languages. This makes the server-side more useful than it would've been previously, I think. Plus, even without this pointer, people also get a localised link to their Main Page via the logo and sidebar, which I believe didn't use to work very well, but now does. During the seven years it was broken, there appears to have been no mention of it, either as complaint or as new idea, so maybe it's something we could even remove entirely, but I thought it'd be easy enough to keep in the template to make it a little more obvious to users once they switch that a localised version exists, since we don't do that automatically currently. Perhaps with a little more work, that could be done? E.g. have "Main Page" with "uselang=nl" render as Hoofdpagina. Of course, that would probably be confusing if they keep having different layouts, so if we want to keep that separate, then automation might be worse. Right now it requires two clicks if people follow the path of least resistance (first to switch languages, then to follow the pointer). --Krinkle 18:26, 18 April 2021 (UTC)- @Krinkle: If I was a logged-out reader, I would much less consider setting the whole site to Hungarian than just visiting the Hungarian main page (the first one is a permanent configuration—which, by the way, has performance consequences as
uselang=
URLs are less aggressively cached—, while the second one is a one-time decision that I don’t have to worry about how to turn off), so the two are different enough IMO that it makes sense to keep both as JS. - What do you mean by
localised link to their Main Page
: localized to their Commons language or localized to their browser language? I experience the latter, which only means that the current solution doesn’t make much sense, since this is the one that’s duplicated in the sidebar. The user agent-based solution still makes sense IMO, see above. —Tacsipacsi (talk) 18:47, 18 April 2021 (UTC)
- @Krinkle: If I was a logged-out reader, I would much less consider setting the whole site to Hungarian than just visiting the Hungarian main page (the first one is a permanent configuration—which, by the way, has performance consequences as
- @Tacsipacsi: I understand that that was the original reason, but I think much has changed since then. We now have the AnonymousI18N gadget, which considers http referers (e.g. Wikipedia language), and
- @Tacsipacsi: I think the current link does have some value becausea typical user has no reason to believe the translated sidebar link will point to something other than the page they are already on. For special pages, file pages, and some translated pages, they would be right. There is one page and it is automatically translated if/when possible. The "Main Page" is unusual in this aspect, the localised pages are manually translated and only informally linked with each other. This pointer is... a pointer, an invitation to be clicked. The sidebar and logo are not.
- If we find a different position for this pointer, one that doesn't cause a layout shift or other rendering delay, we could work on restoring the JS code, but I do note again that in the seven years it was broken, there appears to have been no interest in it, so I'm inclined to just let it be how it's been for the past seven years, with the small added bonus that anons using the AnonymousI8N selector (and logged-in users), get a pointer now, at basically no performance cost.
- In addition, we also still have the collection of links at the bottom of the page with every language which can be followed by anons even without using the language selector.
- If there is interest in improving Main Page navigation, I'd suggest making the Main Page itself render with a LangSwitch so that the same URL works for everyone. And that way, AnonymousI8N which is based on browser settings, will automatically get you to the localised Main Page (instead of showing you a localised sidebar and still the same English Main Page). That might be a bigger gain and more beneficial to all users. It could work either by forcing a single layout and translating text only like with other templates, or we could even keep the current system where content can change completely if we configure LangSwitch to render entirely different pages, such as "en=Main Page/en","nl=Hoofdpagina", etc. --Krinkle 19:32, 21 April 2021 (UTC)
- @Krinkle: You might be right that the sidebar links are less obviously pointers than this one (however, I think your actual design isn’t really obvious, although I have no better idea); I admit that the links serve purpose already in their current form. But I still think that providing links based on the user agent’s settings is usually more appropriate.
- We don’t need to find a different position for the pointer, we just need to make sure it doesn’t shift the content below it, which is quite easy—if you take my suggestion about the hidden links added by Lua, it’s enough to add
min-height: 1.6em;
to the links’ parent node (because of theline-height: 1.6
setting). This will avoid the layout shift as long as the actually shown link is not longer than one line. - I don’t think converting to LangSwitch has much value—every usual way to access the main page (sidebar, logo, going directly to https://commons.wikimedia.org/ etc.) already uses the user interface language, except for links that contain the page name hardcoded, but those ones are probably intentional and often hardcode a non-English page (e.g. links from monolingual sister projects). Also, providing substantially different content through LangSwitch can create quite some confusion. —Tacsipacsi (talk) 23:41, 21 April 2021 (UTC)
- @Tacsipacsi: Regarding the styling, I used the same style and position as it had in 2013 when it last worked. (I dug through the various histories to find when it last worked and then bypassed some of the code paths to get it to render something.)
Regarding the finding of a better position, I would consider your suggestion to reserve a blank line for this a logically new position. I suppose the downside is that it would reserve a blank line, which might look a bit unprofessional. I was hoping to find a position that naturally has white space already, but without it reserving a notable block in the layout. For example the space to the right of the site name. Having said that, that too would look akward I think, hence I haven't done either of those as of yet.
Regarding confusion in LangSwitch, I personally don't think it should matter that the source code of Main Page may be confusing to the small group of people that 1) are active wikitext editors, 2) have prior experience using LangSwitch, 3) want to modify this proxy page for the Main Page. Anyone else, e.g. people editing the template, or editing the actual page for any given language, would not see this. And we'd of course document it with an inline comment in the source code. Anyway, that's how I'd do it.
I did not realize that "going directly to commons.wikimedia.org" rendered a localised Main Page. Both as a user and as a MediaWiki developer, I must say that is very interesting. I think that means we have a really easy way to solve this problem within the AnonymousI8N code. So far, I had restisted the urge to hardcode any solution there, thinking it would require yet-another copy of the list of Main Page (bad for maintenance), or some clever logic with language fallback chains, or an extra AJAX web request (also bad for performance). But, usinghttps://commons.wikimedia.org/?uselang=nl
neatly cuts through all that. Watch this space! --Krinkle 02:00, 22 April 2021 (UTC)- @Krinkle: I tried hiding the text with
visibility:hidden
(hackish solution for the sake of testing), and I don’t think the extra whitespace is annoying there; if you want to make sure, we can add some margin at the very top of the page content area to make it more balanced. - LangSwitch would be more confusing to readers of the main page than for its editors, I think. For example if one has an account with a non-English interface language, but visits Commons logged out every now and then (from a public computer, from a mobile device etc.), they would get totally different result at the exact same URL. —Tacsipacsi (talk) 23:10, 22 April 2021 (UTC)
- @Krinkle: I have just noticed the change and rather big "→ Strona główna" ("main page" in Polish) under small "a collection of…" looks horrible. And is a bit confusing at the first glance. Also I do not get the point of this, as there are links to the localized pages at the left side and at the bottom. --jdx Re: 07:53, 11 July 2021 (UTC)
- @Krinkle: I tried hiding the text with
"sea creature mask"
We might be able to be more precise; I think the sea creature the masker is imitating is a pufferfish. Meaning the mask could go under Category:Tetraodontidae illustrations. HLHJ (talk) 14:52, 20 June 2021 (UTC)
verwaiste Urheberrechte
Der Urheber einer ca. 1935 erstellen Photographie ist (erst) 1995 gestorben. Nach schriftlicher Auskunft des Einwohnermeldeamts hinterlässt weder er noch seine Frau Kinder. Andere Angehörige konnten nicht ermittelt werden. Mir ist klar: Eigentlich darf ich das Photo erst 70 Jahre nach dem Tod des Urhebers in Commons einstellen. Aber die Urheberrechte sind "verwaist". Es handelt sich um eine "ganz normale" Aufnahme: Mein Großvater sitzt in würdevoller Haltung an seinem Schreibtisch. Eigentümer des vom Photografen signierten und gerahmten Bildes bin als Alleinerbe ich. Frage: Spricht etwas dagegen, das Photo bereits heute in Commons einzustellen? --Hajo Lindner (talk) 13:01, 7 July 2021 (UTC)
It is clear to me: Actually, I am only allowed to post the photo in Commons 70 years after the author's death. But the copyrights are "orphaned". It is a "completely normal" recording: my grandfather sits at his desk in a dignified manner. I am the sole heir of the picture signed and framed by the photographer.
Question: Does something speak against putting the photo in Commons today?- @Hajo Lindner: Hallo und willkommen. Hatte Ihr Großvater einen Vertrag, der das Urheberrecht vom Fotografen auf ihn überträgt? Wer oder was hat die Rechte des Fotografen, die Negative, das Fotogeschäft usw. geerbt? Wenn Sie keine konforme Lizenz erhalten, kann das Foto dennoch in die englische oder deutsche Wikipedia gemäß en:WP:F oder de:Wikipedia:Bildrechte#Bilder, deren Urheber nicht bekannt ist, weil wir hier keine Fair Use erlauben.
- Hi, and welcome. Did your grandfather have a contract transferring copyright to him from the photographer? Who or what inherited the photographer's rights, negatives, photography business, etc. ? If you can't get a compliant license, the photo may still be uploaded to English or German Wikipedia in compliance with en:WP:F or de:Wikipedia:Bildrechte#Bilder, deren Urheber nicht bekannt ist because we don't allow Fair Use here. — Jeff G. ツ please ping or talk to me 14:38, 9 July 2021 (UTC)
- Hi Jeff, thank you so much. In 1935 there were no license problems yet. In this time it was quite clear, that my grandfather could do with his photo whatever he wanted to do. Of course he didn't get the negative and the possibilities of reproduction were poor. So me too doesn't have or get the negative. But today I'm able to reproduce the printout in a acceptable quality. The link ... "Bilder, deren Urheber nicht bekannt ist" doesn't help me, because I know the author, he has signed the printout. And his name is unforgotten in the community of my grandfathers living at that time. I'm not the heir of the photographer, I'm only the heir of the printout. So, as the photo dos not have a certain specific extraordinarity I propose to add the addendum to my photo that it may not get copied for any purpose, because it possibly doesn't met the standard of Commons. Would this be o.k.? Yours --Hajo Lindner (talk) 07:18, 11 July 2021 (UTC)
- @Hajo Lindner: Sorry, not until 2066, per COM:Germany and COM:L. — Jeff G. ツ please ping or talk to me 12:47, 11 July 2021 (UTC)
- Hi Jeff, thank you so much. In 1935 there were no license problems yet. In this time it was quite clear, that my grandfather could do with his photo whatever he wanted to do. Of course he didn't get the negative and the possibilities of reproduction were poor. So me too doesn't have or get the negative. But today I'm able to reproduce the printout in a acceptable quality. The link ... "Bilder, deren Urheber nicht bekannt ist" doesn't help me, because I know the author, he has signed the printout. And his name is unforgotten in the community of my grandfathers living at that time. I'm not the heir of the photographer, I'm only the heir of the printout. So, as the photo dos not have a certain specific extraordinarity I propose to add the addendum to my photo that it may not get copied for any purpose, because it possibly doesn't met the standard of Commons. Would this be o.k.? Yours --Hajo Lindner (talk) 07:18, 11 July 2021 (UTC)
Sisterprojects
@Izno has put together a version of {{Sisterprojects-en}} at {{Sisterprojects-en/sandbox}} that uses TemplateStyles and CSS flex boxes instead of layout tables. This improves readability for people using the mobile site, as the list of sister projects will reflow instead of bunching up or adding a scrollbar. It's also better for screen readers. On desktop screen sizes, there is almost no visible difference between the two. You can compare the two versions at Template:Sisterprojects-en/testcases. If there isn't any objection, I'd like to replace the current version with the sandbox version. It should work fine with the other language versions of the template, but will have to be manually copied over. The best way would probably be to use a layout template, but that would mean that every language has the same project order (currently not the case). AntiCompositeNumber (talk) 23:17, 14 July 2021 (UTC)
- @AntiCompositeNumber: That works well in 5 browsers x 2 devices x 2 orientations x 2 toggles. Good job! — Jeff G. ツ please ping or talk to me 17:14, 15 July 2021 (UTC)
- No, a layout template doesn’t mean that all languages have the same project order—only languages that opt into using that layout template. As long as these templates are not translated using the Translate extension (which I would prefer in the long run, by the way), nothing forces any language to use the layout template. I think an optional layout template would make sense even if some languages don’t use it in order to keep their order. (Probably in many of those languages actually it just happened to be different, and editors of those languages won’t have any problem switching to the same order as English.) Allowing to (optionally) override icons of projects having their own language domains (Wikipedia, Wikinews, Wiktionary, Wikibooks, Wikiquote, Wikiversity, Wikivoyage and Wikisource) while using the layout template would be useful, though: some Wiktionaries use a dictionary excerpt
as their logo and want to use that icon in this template as well; this may happen in other projects as well. —Tacsipacsi (talk) 20:41, 15 July 2021 (UTC)
- @Tacsipacsi That's true. I've put together Template:Sisterprojects/layout, and updated Template:Sisterprojects-en/sandbox to use it. I just made everything override-able, so language-specific logos and whatnot aren't a problem. You could change the order of projects by overriding everything with the other project, the parameters would just be named differently from the project. The interwiki links are localized automatically based on
{{{lang}}}
for every project but Wikidata, but can also be overridden if there's no project or main page in that language. Wikidata uses{{int:lang}}
to translate their main page without a great way to specify the language other than?uselang=
. AntiCompositeNumber (talk) 20:18, 18 July 2021 (UTC)- Hearing no objections, this is now
Done AntiCompositeNumber (talk) 17:47, 28 July 2021 (UTC)
- Hearing no objections, this is now
- @Tacsipacsi That's true. I've put together Template:Sisterprojects/layout, and updated Template:Sisterprojects-en/sandbox to use it. I just made everything override-able, so language-specific logos and whatnot aren't a problem. You could change the order of projects by overriding everything with the other project, the parameters would just be named differently from the project. The interwiki links are localized automatically based on
- No, a layout template doesn’t mean that all languages have the same project order—only languages that opt into using that layout template. As long as these templates are not translated using the Translate extension (which I would prefer in the long run, by the way), nothing forces any language to use the layout template. I think an optional layout template would make sense even if some languages don’t use it in order to keep their order. (Probably in many of those languages actually it just happened to be different, and editors of those languages won’t have any problem switching to the same order as English.) Allowing to (optionally) override icons of projects having their own language domains (Wikipedia, Wikinews, Wiktionary, Wikibooks, Wikiquote, Wikiversity, Wikivoyage and Wikisource) while using the layout template would be useful, though: some Wiktionaries use a dictionary excerpt
"File:VTS 01 2.webm" change to "Saber Mensur swordfight"
I want to rename this video "File:VTS 01 2.webm" to "Saber Mensur swordfight". Can you help me with that? Wname1 (talk) 20:08, 23 July 2021 (UTC)
- @Wname1: Hi, and welcome. You may use RenameLink or {{Rename}}. — Jeff G. ツ please ping or talk to me 18:50, 28 July 2021 (UTC)