If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for five days.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
Hello, I found a problem on Commons. The problem is with images in SVG format, where there is distortion in the display of the text of the image, a change in the location of the text display, and a difference in the size of the text display.
This is a sample image, please click and view. So if you click on it, it will appear to you like this.
I thought the problem was due to the program I use to edit photos. For about a full day, I was experimenting with solving the problem, trying different size dimensions and so on, but it was not solved. Then in the end I discovered that the cause of the problem was the Commons website and not me.
I was also able to find out the reason for the problem on the Commons website. It occurs because the text is in a large size, and if you reduce it, the text size will be displayed at approximately the correct size.
Therefore, I ask that the technicians responsible please fix this defect, because it is a major problem. I have stopped editing images until the problem is fixed. Unfortunately, many people must have stopped designing images in this format and uploading them to Wikipedia articles because of this problem.
Note: I do not want to raise the discussion within the Commons project, because it is a very important problem related to the display of images in Wikipedia articles, and Because there is no interest from technicians within the Commons project. Mohmad Abdul sahibtalk☎talk21:55, 25 July 2024 (UTC)[reply]
How do you know technicians from the Commons project wouldn't be interested in this issue if you haven't raised it there? Tule-hog (talk) 22:06, 25 July 2024 (UTC)[reply]
@Tule-hogYou can take a look here There are problems raised a year ago that have not been answered. Also, the problem I raised is urgent and important. I have stopped all my projects until the bug is fixed. In addition, the problem is linked between the two projects. Mohmad Abdul sahibtalk☎talk19:42, 26 July 2024 (UTC)[reply]
Not saying you shouldn't have raised it here, just that you might also try raising it there to increase coverage. Arabic's SVG rendering possibly not working is a serious, global bug to be sure. Have you happened to find any graphics that don't have the issue? Tule-hog (talk) 02:58, 27 July 2024 (UTC)[reply]
I think the problem is that your used the Arial font in your image, which is not a free font, and thus is not installed on the Wikimedia servers. Try changing the text in the image to use one of the fonts listed here: https://meta.wikimedia.org/wiki/SVG_fonts – I suggest Liberation Sans, which was designed as an alternative to Arial – and see if that makes it display right. Matma Rextalk22:28, 26 July 2024 (UTC)[reply]
@Matma Rex: Nope. I have tried (LiberationSans-Bold), and the problem is the same. There has only been a slight difference in text measurements, but text distortion, positioning, and size are still there. Mohmad Abdul sahibtalk☎talk02:50, 27 July 2024 (UTC)[reply]
Hmm, you're right. I uploaded a new version of the file (File:Anterior Thyroid - Arabic.svg) just to be sure, and it still looks very wrong. I want to try some other things, but I'm not sure how the result is supposed to look like – the SVG file on my computer also has slightly weird-looking text, and I'm not sure if it's a problem with the file or with my applications: https://phabricator.wikimedia.org/F56717722. Can you export it to PNG on your computer and upload that version to Commons too, so that we may compare? Matma Rextalk03:34, 27 July 2024 (UTC)[reply]
@Matma Rex: I think I discovered the cause of the problem, it is caused by a difference in dots per inch. Because I downloaded an image in SVG format for the year 2010 and wanted to modify it, but I saw this message inside the program:
was created in an older version of Inkscape (90 DPI) and we need to make it compatible with newer versions (96 DPI). Tell us about this file. This file contains digital artwork for screen display (Choose if unsure.) This file is intended for physical output, such as paper or 30 prints. Create a backup file in same directory. More details: We've updated Inkscape to follow the CSS standard of 36 OPI for better browser compatibility we used to use 50 DPI. Digital artwork for screen. display will be converted to 96 DPI without scaling and should be unaffected. Artwork drawn at 90 DPI for a specific physical size will be too small if converted to 96 DPI without any scaling. There are two scaling methods. Scaling the whole document: The least error-prone method, this preserves the appearance of the artwork, including filters and the position of masks etc. The scale of the artwork relative to the document size may not be accurate. Scaling individual elements in the artwork: This method is less reliable and can result in a changed appearance but is better for physical output that relles on accurate sizes and positions (for example for 3D printing. More information about this change are available in the Inliscape
I have installed Inkscape version 0.48 (2010). Then I tried editing the image and uploading it to Commons, and I did not see any distortion or any problems with the text.
__________________
There is another problem, which is when you open the image in this way, right-click on it and then download it directly, without clicking on the download icon, the image is not downloaded in SVG format, but rather in PNG format, and this is a big problem that should not happen. Mohmad Abdul sahibtalk☎talk04:55, 27 July 2024 (UTC)[reply]
@Matma Rex: This is the original image. We do not have distortion problems with PNG images because their texts are more like printed matter or more like hardsub, meaning that the text is not editable, nor are the image objects. As for SVG files, they are more like an image project that can be edited and translated, including the text. I work with SVG images so that they can be easily modified and translated into other languages. I hope in the future that Wikipedia's policy will change so that it does not allow uploading any PNG images of any images with text on them.
In fact, I suggest that Wikipedia provide the feature of translating SVG image texts without the need to upload them repeatedly for each language. This will facilitate the work and reduce the size of the Commons server data. I mean, if the Commons project provides us with the advantage of recognizing image texts and translating them so that they are displayed directly without the need to repeatedly upload the image in each language, then the matter will become easier and faster and will save space on the Commons project server. Mohmad Abdul sahibtalk☎talk05:16, 27 July 2024 (UTC)[reply]
SVG image rendering is done using librsvg, if you have problems with how the image renders it is probably a problem in the librsvg library. We don't do direct work on developing the software that renders the SVG (it is a dependency). If you find the issue, perhaps you can report it with the librsvg project. —TheDJ (talk • contribs) 08:50, 27 July 2024 (UTC)[reply]
" I suggest that Wikipedia provide the feature of translating SVG image texts without the need to upload them repeatedly for each language" You are welcome to write such functionality for MediaWiki. Most of this kind of functionality is written by volunteers. —TheDJ (talk • contribs) 08:58, 27 July 2024 (UTC)[reply]
The user stated they wish to do this without having to reupload for each translation. While svg translate allows combining translations into a single upload, each edit to them or each new translation still requires a reupload. —TheDJ (talk • contribs) 08:54, 28 July 2024 (UTC)[reply]
"right-click on it and then download it directly" then you are downloading the thumbnail, and this is expected. If you want the original file, you always need to use the link below it "original file" and choose Save file as. —TheDJ (talk • contribs) 08:48, 27 July 2024 (UTC)[reply]
Thanks for all this information.
@TheDJ: yes, I know this. I meant that the image must be downloaded in SVG format even if it is clicked directly without clicking on the download icon - otherwise some people may not pay attention to the download icon and a problem and suspicion will occur.
@The wubThe wub: This is something legendary, I didn't know about it. But I have a problem, which is when I access a Commons project in English, its interface will switch to Arabic. Unfortunately, the Commons project cannot be accessed according to the desired language، and unfortunately, the (Content Translation/V2) is not available in this project, and for this reason I cannot translate many explanatory articles in the Commons project. I hope that the Commons:SVG Translate tool icon is present on the information page of every SVG image uploaded to Commons, so that everyone knows that this feature exists, whether writing on images or translating them.
I have informed the members of the Librsvg project, and am waiting for their response to find out if the problem is due to the library. We still need to find out the cause of the malfunction, to determine the cause of the problem, any information about this would be helpful. I hope that we will cooperate in fixing the defect, because the problem is related to a major error related to Wikipedia, especially the display of images. I have currently stopped all my projects related to image design, because if I now upload images with small texts in them so that they will be displayed in a large size, it is expected that after fixing the defect, the text size will decrease.Mohmad Abdul sahibtalk☎talk08:05, 28 July 2024 (UTC)[reply]
I have opened a report here. I cannot handle the issue and follow up the problem programmatically, because I am not a programmer. By opening the issue in the Librsvg project forum, it becomes clear that following up on the problem and diagnosing its cause is the responsibility of Wikipedia members. I did everything I could do, and the rest requires your intervention. Mohmad Abdul sahibtalk☎talk17:40, 28 July 2024 (UTC)[reply]
Usually the start discussion notice is displayed on talk pages with no comments; But, now its in all talk pages. Even in Wikipedia talk:Village pump (technical), Don't know how long it has been but I just noticed it. Is it a glitch or something??? Vestrian24Bio (TALK) 11:48, 26 July 2024 (UTC)[reply]
There's this recurring issue at Special:WantedCategories where a redlinked Category:Clean-up categories from YYYY gets generated because somebody has erroneously backdated a maintenance template to 15 or 20 years ago — following which a bot automatically recreates the resulting redlinked maintenance-queue category for that specific template, but then leaves the general "clean-up" container as a redlink that ends up becoming the category cleanup crew's job to fix.
For example, Category:Articles with unsourced statements from July 2004 has been recreated four times within the past two weeks, just from people accidentally typing 2004 instead of 2024 in a {{citation needed}} template somewhere in an article, which is obviously just a disruptive pain in the badonkadonk to have to keep dealing with over and over.
I've asked here before, and was told that it was possible, but obviously it didn't happen: is there any way that maintenance templates like {{citation needed}} can be made to do an ifexist check on categories, and file nonexisters in an error-catcher category (e.g. "citation needed with dating problems" or something along those lines) instead of causing the recreation of a redlinked category that's already been cleaned up and deleted in the past? Bearcat (talk) 13:21, 28 July 2024 (UTC)[reply]
Also, given that it's clearly possible for bots to detect and automatically create redlinked maintenance categories as needed, then can any of the following things that inevitably hit WantedCategories on a regular basis get farmed out to bots instead of becoming my job to fix?
"Wikipedia Today's featured article nominations from [Current Month and Year]", which consistently lands there at some point in the middle of every month without fail, and should really just be automatically created by a bot right off the top of the month if it's routinely expected to exist?
Any non-empty redlinks of the "Articles containing [Insert Language Here] text", "Pages with [Insert Language Here] IPA" and "CS1 [Insert Language Here]-language sources (lang code)" varieties?
Dated maintenance categories (such as Category:Articles with unsourced statements from July 2024) are created by AnomieBOT (talk·contribs) if either of two conditions apply: (i) it's now the last day of the preceding month; (ii) there's a page in the category and the date is valid - even if the year is a typo. I would expect that if you want different behaviour from AnomieBOT, your first contact should be Anomie (talk·contribs), who (unlike some botops I could name) is not only active but also replies to talk page messages.
Obviously sockpuppet ones should be the responsibility of the admin or clerk who tagged the page, but mistakes can and do happen — so there really needs to be a way to catch such mistakes before they become my problem to fix.
When it comes to the backdated maintenance templates, it's really a thing that the template needs to handle rather than the bot. The bot is just going to come along and create any non-empty redlink it finds, and can't easily modify a redlinked category to be different than what's there — it's the template that needs to be prevented from being able to generate a backdated redlink like that at all, so that there's nothing for the bot to have to recreate. So it's really that the template needs to have "if asked to regenerate outdated category that does not exist, then replace with problem-catcher category instead of redlinked date" code inside the template, because a bot can't make that happen if the template isn't already handling it. Bearcat (talk) 21:14, 28 July 2024 (UTC)[reply]
AnomieBOT won't create dated categories for any date, only dates since 2004. I forget why I picked that year specifically, beyond deciding that anything earlier was definitely not some ancient article being undeleted or some ancient edit removing a maintenance tag being reverted. I could bump it to 2010 easily enough if people typing "200X" instead of "202X" is a common thing.
The non-date examples would need to be considered case by case. "Wikipedia sockpuppets of" and Wikipedia suspected sockpuppets of" seem like reasonable prefixes to search for. Not sure about "Articles containing", "Pages with", or "CS1".
Regarding bumping from 2004 to 2010 – can the bot look up the earliest existing month/year category and not create categories which are earlier than that? —andrybak (talk) 15:00, 30 July 2024 (UTC)[reply]
I wonder how often people validly undelete, or unredirect, or otherwise revert to a revision that has a maintenance tag older than that. Or how often people change a tag from one category to another, suddenly populating the "another" category with a bunch of old dates. Also I'd rather have a consistent cutoff rather than having to try to look up an earliest date for every different category. Anomie⚔23:47, 30 July 2024 (UTC)[reply]
Can I butt in here for a moment to ask if we're seriously considering making the lives of people who actually work the backlogged cleanup categories (I'm sure they exist) significantly harder, so that the people who keep Special:WantedCategories tidy are less inconvenienced? I've also had empty maint categories I've G6'd years ago pop back up, and that's a good thing, because it means someone's reverted an unsourced article that was made into a redirect years ago, or copy-pasted in an old version of a deleted article, or reverted a page to a really old version, and those all need to be dealt with. If we make the maintenance tags not categorize such edits, then they're going to be noticed by a lot fewer people. If it's just a matter of the bot not recreating redlinked grandfather cats, then have it make those. Or, y'know, deal with the underlying problem - most of the time the correct thing to do was a simple rollback or G4 speedy, in my experience - and then G6 the maintenance cat again. Even if you omit the last, it's not going to last an hour anyway; we've got admins who race each other for easy speedies like that. —Cryptic03:56, 31 July 2024 (UTC)[reply]
In dark mode, at {{Stabbing Westward}}, the actual link for Stabbing Westward is an extremely dark grey that is difficult to see on a black background. Also, when editing, anything that is NOT a link is grey text on a white background. It was not this way before. Does anyone know how to fix this?
Grey text on white background when editingBlack text on black background when viewing
I don't edit templates, generally, but even when I edit regular pages after hours (when the site changes colours), I now have that white edit window with light-coloured text, rendering everything essentially unreadable. I've been eschewing editing when the site is dark (or, like right now, typing in a plain-text program and copying/pasting), thinking surely this is a widespread problem and will be fixed quickly, but maybe it's only tied to what you're discussing, here? You linked to a discussion about templates and navboxes; will that proposed fix also affect all white-background editing issues, too? — Fourthords | =Λ= |02:27, 1 August 2024 (UTC)[reply]
Reply - The issue is fixed when I am logged in to my home computer. However, when I am in dark mode on a public computer, the title of a music navbox is very dark grey. --Jax 0677 (talk) 12:51, 4 August 2024 (UTC)[reply]
On Wikispecies (where I am an admin), if I view the history of a page with multiple unpatrolled edits, I see an option to "Mark all revisions as patrolled". I do not see this here on en.Wikipedia, nor on Wikidata.
How can I enable this on the latter projects (where I am not an admin; if that is relevant)?
I searched for that string, and found only one discussion, from 2009, which refers to an "Enchanted [SIC: enhanced?] recent changes" option under preferences -> Recent changes, but I see no such option on any of the listed projects. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits12:20, 30 July 2024 (UTC)[reply]
@SandyGeorgia: With some browsers, the zoom setting is remembered in a non-intuitive way. For example, if you zoom out on one page, click through to another page, the zoom level is inherited; if on that you reset to normal zoom then return to the first page, it may be normal, or it may still be zoomed out. --Redrose64 🌹 (talk) 21:46, 31 July 2024 (UTC)[reply]
I noticed on Hey Jude#Auctioned lyrics and memorabilia that the inflation conversion from pounds to US$ is showing "US$FXConvert/Wordify error: cannot parse value 'Unknown country code for year 2023: GBR '". Many of the GBR test cases on Template:FXConvert/testcases are similarly broken, so it's probably affecting a lot of articles. I can't tell where exactly this data is coming from or if there were recent changes causing this. hinnk (talk) 19:00, 31 July 2024 (UTC)[reply]
What Anomie is saying there is that FXConvert was already broken. The changes there just made it clear that it is. Izno (talk) 23:09, 31 July 2024 (UTC)[reply]
Oh my mistake, I had read it as the template working (or at least, not showing any errors) until the new data exposed a case it couldn't handle. Is there a more appropriate place to raise this issue then? I notice Template:FXConvert doesn't have a talk page. hinnk (talk) 23:58, 31 July 2024 (UTC)[reply]
There are many errors at {{FXConvert/doc}} and that template's testcases page. It looks like the error is generated by {{To USD/data/2023}}, which is much smaller than {{To USD/data/2021}}. It appears that if a country code is missing from the "/2023" template, it generates an error message. It is unclear to me how numbers are chosen for the /2023 template. – Jonesey95 (talk) 04:49, 1 August 2024 (UTC)[reply]
Most of the pages currently transcluding errors have this problem. I noticed it started about a month ago with Canada (CAN) on a few pages. I tried to trace it but it became too much of a time sink to debug. Now it's really gotten bigger since GBR joined in. Where, oh, where is the editor who designed and implemented all this obscure complexity? – wbm1058 (talk) 04:05, 4 August 2024 (UTC)[reply]
The WB data does not provide EUR. Somebody had added it without mentioning the source. I have restored that, but I will have to update the ECB data so that the conversion goes through ToEUR. Trigenibinion (talk) 15:02, 4 August 2024 (UTC)[reply]
Recently and editor asked a question at WP:HD. I replied that the correct place to have asked that question was Help talk:Citation Style 1. In response, the editor said that they didn't because there is a notice that reads:
Attention
Talk pages in this namespace are generally not watched by many users. Please consider visiting the Help desk for a more prompt response or reviewing the Help contents for quick tips.
That message is displayed when the editor is seeing the edit view. Is there any way to suppress that warning/notice for a single Help talk: page?
Yes. I don't want editors to be scared away from the talk page where they can get cs1|2 help. All of the cs1|2 template and module talk pages redirect to Help talk: Citation Style 1. Editors should not arrive there and then think that they must go to some other page for help. If we wanted editors to ask questions at WP:HD, we'd have redirected the cs1|2 template and module talk pages there.
You assume correctly. I'm not convinced that conflicting messages are ever a good thing. Is it possible to create a template that does nothing but drag in a templatestyles css page that contains something like:
It looks like that should almost work, and work from the page-specific edit notice, but .visibility looks like it wouldn't be correct (also the !important should be unnecessary). As things are you'd want to target #Visibility, although personally I'd probably do .editnotice-namespace#Visibility just in case. Anomie⚔14:52, 1 August 2024 (UTC)[reply]
It should be possible to specify the colour-scheme to be used when rasterising SVG files. This would influence the default styling applied to SVG elements and activate any CSS media queries that target prefers-color-scheme. For example, a background normally rendered as pale blue for white backgrounds might select a darker shade in night-mode to avoid the garish contrast:
The MediaWiki thumbnail generator already provides a means of specifying language when rendering multilingual SVGs by prefixing the thumbnail's filename with langid- (where id is the BCP 47 tag of the desired language). The same approach could be used to request a rendering of an SVG using a particular colour-scheme; for example, by supporting an optional dark- prefix in thumbnail URLs. Expressed in BNF, the format of thumbnail URLs would be:
<thumbnail-url>::=<base> "/" <name> "/" [<theme>] [<lang>] <size> "-" <name> ".png"
<base>::= "https://upload.wikimedia.org/wikipedia/commons/thumb/1/14/"
<theme>::= "dark-" | "light-"
<lang>::= "lang" <locale> "-"
<size>::=<width> "px-"
; Variables (values shown here by way of example)
<name>::= "Lang_Status_01-EX.svg"
<locale>::= "de"
<width>::= "480"
I'm aware of a CSS class named .skin-invert-image that inverts image colours for dark-mode users, but it's an inelegant and hacky solution that really only works for images with simple colour palettes (like this). A more robust and seamless approach would be to extend the image syntax to include a new parameter named theme that recognises one of three values: dark, light, and auto (the default). Auto would select either the dark or light rendering of an SVG based on the reader's display preferences, while dark or light specify motifs unconditionally (potentially facilitating the use of <picture> tags, should MediaWiki support them in the future). — Alhadis (talk) 23:07, 1 August 2024 (UTC)[reply]
That is pretty well written, but SVG´s are outputted as PNG´s to the client. So, either the "wgSVGNativeRenderingSizeLimit" or "wgSVGNativeRendering" server settings would be have to be on for this to work, as per phab:T208578. Snævar (talk) 01:53, 3 August 2024 (UTC)[reply]
That's a lot of extra complexity in the software, and equally important, requires editing and reuploading a lot of images. For that reason it is not very likely to happen soon. —TheDJ (talk • contribs) 17:21, 3 August 2024 (UTC)[reply]
There is a problem with the behaviour of User:Cobaltcigs's IllWill.js: If I fill in the edit summary as I go along editing an article, and then invoke that script, it overwrites my edit summary with its own. I'm no expert in JavaScript, but it occurs to me that changing in line 162 the operator = to += would fix that. Then again, it might need more elaborate coding.
I'm not sure what Izno means. The newline is inserted by {{Welcome}} which could be changed to not insert a newline in the future. It wouldn't affect past substitutions, and I don't know whether the template is used in circumstances where it would be bad to omit the newline. PrimeHunter (talk) 22:01, 3 August 2024 (UTC)[reply]
AFAICS removing the newline would make it so that welcome normally substs like == Welcome ==Ipsum rather than the intended == Welcome ==\nIpsum. Perhaps you can make it work. Izno (talk) 22:11, 3 August 2024 (UTC)[reply]
The rules for whitespace stripping and rendering are complicated and the template actually leaves two newlines which is why it renders as extra whitespace. I have removed the first newline in the sandbox version with a method [4] which leaves behind a nowiki on substitution. Not elegant but are there real problems? PrimeHunter (talk) 23:47, 3 August 2024 (UTC)[reply]
That's pretty gross to be plopping on new editor talk pages. They don't need an introduction to nowiki in that way.... Izno (talk) 23:51, 3 August 2024 (UTC)[reply]
With Baghdad Conservatory in my Firefox edit the start of the line is left of the edit box. Previously this resulted in someone adding an extra "T" to yield "TThe". But now the "The" looks like "he" in the edit box. Somewhere in the Arabic text there is a left to right unicode direction indicator as I can tell by trying to add spaces to it. How can we find and remove such characters? And is that character messing up the edit box? Graeme Bartlett (talk) 22:33, 3 August 2024 (UTC)[reply]
It looks fine in my Firefox (128.0.3), with Monobook, Vector, or Vector2022, in the "2010 editor", with and without &safemode=true added to the URL. I don't see any LRM or similar characters in that article. Anomie⚔13:02, 4 August 2024 (UTC)[reply]
This is one of the reasons that the cs1|2 templates support |script-title=. Try this:
{{cite news|script-title=ar:الراحل حنّا بطرس جزء من تاريخ الموسيقى في العهد الملكي |url=http://www.daraddustour.com/%D8%A7%D9%84%D8%AA%D9%81%D8%A7%D8%B5%D9%8A%D9%84/tabid/94/smid/604/ArticleID/31615/reftab/123/Default.aspx |accessdate=31 July 2011 |newspaper=Addustour |date=28 September 2010 |url-status=dead |archiveurl=https://web.archive.org/web/20120328094702/http://www.daraddustour.com/%D8%A7%D9%84%D8%AA%D9%81%D8%A7%D8%B5%D9%8A%D9%84/tabid/94/smid/604/ArticleID/31615/reftab/123/Default.aspx |archivedate=28 March 2012}}
|script-title= causes cs1|2 to wrap the title in <bdi>...</bdi> (bidirectional isolate) tags:
'"`UNIQ--templatestyles-0000002C-QINU`"'<citeclass="citation news cs1 cs1-prop-script">[https://web.archive.org/web/20120328094702/http://www.daraddustour.com/%D8%A7%D9%84%D8%AA%D9%81%D8%A7%D8%B5%D9%8A%D9%84/tabid/94/smid/604/ArticleID/31615/reftab/123/Default.aspx <bdilang="ar">الراحل حنّا بطرس جزء من تاريخ الموسيقى في العهد الملكي</bdi>]. ''Addustour''. 28 September 2010. Archived from [http://www.daraddustour.com/%D8%A7%D9%84%D8%AA%D9%81%D8%A7%D8%B5%D9%8A%D9%84/tabid/94/smid/604/ArticleID/31615/reftab/123/Default.aspx the original] on 28 March 2012<spanclass="reference-accessdate">. Retrieved <spanclass="nowrap">31 July</span> 2011</span>.</cite><spantitle="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Addustour&rft.atitle=%D8%A7%D9%84%D8%B1%D8%A7%D8%AD%D9%84+%D8%AD%D9%86%D9%91%D8%A7+%D8%A8%D8%B7%D8%B1%D8%B3+%D8%AC%D8%B2%D8%A1+%D9%85%D9%86+%D8%AA%D8%A7%D8%B1%D9%8A%D8%AE+%D8%A7%D9%84%D9%85%D9%88%D8%B3%D9%8A%D9%82%D9%89+%D9%81%D9%8A+%D8%A7%D9%84%D8%B9%D9%87%D8%AF+%D8%A7%D9%84%D9%85%D9%84%D9%83%D9%8A&rft.date=2010-09-28&rft_id=http%3A%2F%2Fwww.daraddustour.com%2F%25D8%25A7%25D9%2584%25D8%25AA%25D9%2581%25D8%25A7%25D8%25B5%25D9%258A%25D9%2584%2Ftabid%2F94%2Fsmid%2F604%2FArticleID%2F31615%2Freftab%2F123%2FDefault.aspx&rfr_id=info%3Asid%2Fen.wikipedia.org%3AWikipedia%3AVillage+pump+%28technical%29"class="Z3988"></span>[[Category:CS1 uses Arabic-language script (ar)]]
Just thrown {{welcome-foreign/Persian}} on a user, and it hasn’t prompted a == Welcome == title to spawn. I’m pretty sure most use of welcome-foreign prompts a title? Unless I’m thinking of another template that Welcoming Committee often use? MM(Give me info.)(Victories)08:44, 4 August 2024 (UTC)[reply]
Well that template does not include any header. So if you are able to write Persian, you could add in the header to the template. The header should have == translation of welcome == , though one I checked out had === instead of ==. Graeme Bartlett (talk) 10:41, 4 August 2024 (UTC)[reply]
Wikipedia:Categories for discussion/Log/2024 July 21#German Confederation has had the effect of leaving behind 56 non-empty redlinked categories for Special:WantedCategories cleanup, because "YYYY in Germany" categories were moved to "YYYY in the German Confederation", but then various subcategories were left behind in the redlinks because the category was template-transcluded onto them instead of being directly declared — and while it is technically possible for me to fix them by manually going around switching {{EstCatCountry|Germany}} to {{EstcatCountry|the German Confederation}}, doing that would have the side-effect of simultaneously breaking other categories on the same contents (e.g. "[Decade] establishments in Germany", "Establishments in Germany by year"), by turning them from bluelinks into redlinks because they still need the Estcatcountry template to be saying "Germany" rather than "the German Confederation".
So, essentially, there's no way for me to fix the existing redlinked categories without causing new redlinked categories in the process, and thus I need technical help getting them cleaned up. Thanks. Bearcat (talk) 13:27, 4 August 2024 (UTC)[reply]
Note that not even all the "YYYY in Germany" categories were renamed, only the ones for years prior to 1871. Category:1871 in Germany and later still exist. As for Template:EstcatCountry, its documentation suggests that passing Germany and having redirects from "[Decade] establishments in Germany" to "[Decade] establishments in the German Confederation" where appropriate should work. Or maybe vice versa, passing "the German Confederation" and having appropriate category redirects in the other direction. Anomie⚔14:24, 4 August 2024 (UTC)[reply]