User talk:Shirayuki

From mediawiki.org

Archives
/Archive 1 (pre-Flow) Original Flow board 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024

Hi, in -> https://www.mediawiki.org/w/index.php?title=Help:Advanced_editing&diff=prev&oldid=6940302 it is right, but how (from where) I do identify the ID of the user interface to be used ? Thanks. --Christian 🇫🇷 FR (talk) 10:16, 24 December 2024 (UTC) Reply

See Help:System message . Shirayuki (talk) 10:35, 24 December 2024 (UTC) Reply

Thank you for taking care of the translators and pages. Would you care to indicate why a particular sentence was unmarked for translation please? I understand that T:75 and T:76 ignore one sentence between them. Omotecho (talk) 03:51, 31 December 2024 (UTC) Reply

You inserted unwanted ‎<nowiki>...‎</nowiki> tags. Shirayuki (talk) 05:03, 31 December 2024 (UTC) Reply

My bad! Case solved, I will be more careful switching between Source and Visual Editors. Not comprehended why nowiki tags are involved though... /: Thank you for your golden wisdom as always. Omotecho (talk) 05:56, 31 December 2024 (UTC) Reply

Hi Shirayuki, I have made some minor changes to Help:Notifications. However, it is not clear to me if the community here is invited to edit Help documentation. I hope the changes I made meet with your approval? Cheers, Ottawahitech (talk) 20:42, 23 January 2025 (UTC) Reply

Hi again, I have made a few more minor changes to Help:Notifications/Thanks. I assume that you have no objection? Ottawahitech (talk) 20:58, 4 February 2025 (UTC) Reply

Hey, I can't see any reasons to leave text out of translation tags, like you did on Wikimedia Language and Product Localization/Newsletter/2025/January. I understand that you did a lot of work on that page, because it had to be properly tagged. But whole lists and paragraphs ended up outside translate tags. Is it that you just didn't notice that? Ата ^(talk) 09:18, 5 February 2025 (UTC) Reply

I didn't have enough time, so I only marked for translation the parts where the tagging was correct. For the other sections, I tried to indicate how they should be fixed to some extent. Shirayuki (talk) 10:57, 5 February 2025 (UTC) Reply

Is there anywhere a template to mark pages if parts are not tagged or would that not be usefull? True (talk) 12:25, 18 February 2025 (UTC) Reply

Good day, please nuke the contribution as machine translation, per m:User talk:Allan Candido Guedes - ACG Minorax (talk) 04:06, 8 February 2025 (UTC) Reply

Yes Done Shirayuki (talk) 04:38, 8 February 2025 (UTC) Reply

Hi Shirayuki, can you please create the Manual:$wgLinterWriteNamespaceColumnStage page? USB4215 (talk) 14:04, 17 February 2025 (UTC) Reply

I haven't checked for configuration variables additions/removals for weeks, so I'll do it in the coming days and reflect the changes on the pages. Shirayuki (talk) 22:57, 17 February 2025 (UTC) Reply

@USB4215: I've checked the history of the MediaWiki core repository, but I couldn't find such a configuration variable.-- Shirayuki (talk) 09:39, 8 March 2025 (UTC) Reply

@USB4215: That variable is defined by Extension:Linter. Configuration variables defined by extensions are not subject to the creation of separate manual pages.-- Shirayuki (talk) 09:08, 9 March 2025 (UTC) Reply

You reverted my edit [1]. There are two sentences outside of the translation which should be inside, how can i do that? --Ailura (talk) 14:13, 25 February 2025 (UTC) Reply

Use ‎<tvar>...‎</tvar> tags to make text untranslatable. -- Shirayuki (talk) 21:02, 25 February 2025 (UTC) Reply

I wanted to make the text translatable, thank you. Ailura (talk) 06:49, 26 February 2025 (UTC) Reply

Hi Shirayuki, can you please help me to translate the name of the page "Special:ViewXML" in the sentence below

Data Transfer defines a special page, "Special:ViewXML"

thank you --JLTRY (talk) 09:57, 27 February 2025 (UTC) Reply

To simplify translation units, use ‎<code>...‎</code> tags instead of quotes and enclose special page names with ‎<tvar>...‎</tvar> tags.-- Shirayuki (talk) 21:56, 27 February 2025 (UTC) Reply

Hi Shirayuki, can you help I have an issue in this page when viewing it Extension:ContactPage/fr

Personnalisation supplémentaire
<span id="Adding_a_link_to_special_page_"Contact"_to_the_footer"> 

--JLTRY (talk) 08:43, 28 February 2025 (UTC) Reply

If a heading contains links or code, you need to add the nowrap attribute to the surrounding translate tag. For details, read the manual.--Shirayuki (talk) 12:09, 28 February 2025 (UTC) Reply

Hi Shirayuki I do not really know how I should write the translate part for this paragraph My both last trials were reverted for Extension:Data_Transfer:

KO

<translate>You can also import content into page "slots" other than the main one, using MediaWiki's <tvar name=1>{{ll|Multi-Content Revisions}}</tvar> feature, by adding the "Slot" column, like so:</translate>

KO

<translate>You can also import content into page "slots" other than the main one, using MediaWiki's {{ll|Multi-Content Revisions}} feature, by adding the <code>Slot</code> column, like so:</translate>

--JLTRY (talk) 12:42, 5 March 2025 (UTC) Reply

Enclose each part that translators should not translate or modify with a separate ‎<tvar>...‎</tvar> tag. Your markup does not seem to meet that requirement, based on my reading of the page content.-- Shirayuki (talk) 21:07, 5 March 2025 (UTC) Reply

I corrected Extension:Data_Transfer JLTRY (talk) 07:16, 6 March 2025 (UTC) Reply

Hi @Shirayuki

I am trying to work with the Pagelinks file in order to extract the number of articles that link to a specific Wiki page (same idea as can be seen in the "What-links-here" tool.

However, when I loop over this sql like file, I find very weird cases of links that doesn't seem to exist in Wikipedia.

For example, the first line in the file indicate that there is a link between page ids 1939 and 2. PageID 2 doesn't even seems to exist.

Even when I look on pageIDs that do exist, the link indicated in the file does not exist in the actual wiki page.

Am I missing anything?

thanks a lot! Avrahami-isr (talk) 18:10, 28 February 2025 (UTC) Reply

Please ask at Project:Support desk. Shirayuki (talk) 22:10, 28 February 2025 (UTC) Reply

Sure, thanks! Avrahami-isr (talk) 02:07, 1 March 2025 (UTC) Reply

hello i need your help if you agree. My first steps in template coding let me create a simple template {{categoryPages}} today. Tests seem ok on the flow but when I call the template from a list # in Manual:Adding_support_for_new_filetypes#What_do_I_need_to_do? it lost the numbering. Where to look for ?

blabla..... complete list in: Category:Media handling extensions . ..is correct on the flow ..blabla

1. this is first list item on the same line but it breaks complete list in: Category:Media handling extensions .
2. second item
3. third item

Thankx -- Christian 🇫🇷 FR 🚨 (talk) 21:00, 15 March 2025 (UTC) Reply

@Wladek92: Writing {{CategoryPages}} will transclude Template:CategoryPages/en. Templates with translation-aware transclusion enabled behave in the same way.-- Shirayuki (talk) 23:26, 15 March 2025 (UTC) Reply

Yes my problem is not if it is transcluded or not but as you see in the source, transclusion is requested to be made on the same line without breaking the list.

blabla..... {{categoryPages|cat=Media handling extensions}}. ..is correct on the flow ..blabla

1. this is first list item on the same line but it breaks {{categoryPages|cat=Media handling extensions}}.
2. second item
3. third item

Christian 🇫🇷 FR 🚨 (talk) 10:43, 16 March 2025 (UTC) Reply

@Wladek92: Compare the source of {{CategoryPages}} and {{CategoryPages/en}}. Although you are transcluding the former, in reality, the latter is transcluded, which causes confusion.-- Shirayuki (talk) 11:39, 16 March 2025 (UTC) Reply

Thanks seems having satisfying functionality , pb of the includes tags Christian 🇫🇷 FR 🚨 (talk) 21:21, 16 March 2025 (UTC) Reply

Sorry, that's already a few pages you've written about that I shouldn't translate. I have a few questions. Why are these pages marked as being intended for translation? So why are they displayed in "Translante content"? Shouldn't these pages have a block for displaying that they are/are not available for translation? How is it possible that some of these pages are already translated? Thank you Rebulka (talk) 16:26, 29 March 2025 (UTC) Reply

@Rebulka See the source of MediaWiki Language Extension Bundle/installation-- Shirayuki (talk) 22:26, 29 March 2025 (UTC) Reply

Thank you for the answer. Unfortunately, I did not find the answer to my question on the recommended pages. I do not require an answer. It is only a suggestion for possible improvement. "The page should not be translated - it is not published anywhere in the translation offer". Sunny day Rebulka (talk) 07:00, 30 March 2025 (UTC) Reply

@Rebulka The above source says "This file text is included in MLEB tarball. Please do not wikify if that would make it not work as plain text file", so the page should not be prepared for translation.-- Shirayuki (talk) 07:41, 30 March 2025 (UTC) Reply

@Rebulka We handle a lot of pages, so it would be helpful if you could provide a link to the specific page you're referring to. (I have a general idea, but it would help to clarify.)-- Shirayuki (talk) 07:55, 30 March 2025 (UTC) Reply

Thank you for your reply. I will keep you posted on these pages. It is amazing that they are being released for translation and have even been partially translated. Slunicky's Day Rebulka (talk) 08:59, 30 March 2025 (UTC) Reply

Hi, why did you revert my edits to Project:Requests for permissions/Header? – Svārtava (t ɕ) 05:40, 7 April 2025 (UTC) Reply

@Svartava: The reason for reverting the change is to better preserve the original intent. The phrase "Promotion to" in the original text emphasizes the process of advancing to specific roles, which was important for clarity. The revised version lost this nuance and became overly simplified. Retaining the original phrasing ensures the meaning is conveyed more accurately.~~ Shirayuki (talk) 11:39, 9 April 2025 (UTC) Reply

OK, but there are some minor issues which I was trying to solve with my edit. For example, there should be mention of other user groups like importer and bot which are granted through that requests page only. Then, the page reads as "Use this page for requests for: autopatrollers, uploaders [...]" but "requests for autopatrollers" does not mean "requests for autopatroller rights" or "requests for autopatrollership"; ordinarily it implies "requests that are to be fulfilled by autopatrollers". – Svārtava (t ɕ) 09:53, 11 April 2025 (UTC) Reply

I understand the intention behind your edits, and I appreciate your effort to improve the clarity. That said, I believe the original phrasing carries specific intent, particularly in how it distinguishes types of requests and roles. Rewording it for grammar or simplification at the cost of that nuance is not ideal.

Even if the current version isn't perfect, it has been working well enough — it's already translated and widely understood. Preserving the original meaning is more important than smoothing it out in a way that alters the intent.

I'm happy to help refine the text if needed, but ultimately, this feels like something that should be discussed at Project:Village Pump.-- Shirayuki (talk) 00:29, 12 April 2025 (UTC) Reply

For segmenting translation units, I trust your judgement, however, it actually causes pain to those translators who had already worked on them: sorry, I do not have to repeat what you were not happy with, or I appreciate shorter units, too usually.

Is there something I could do to improve the situation, like go to the Portal and raise a flag, maybe to ask tech ppl consider something? I have encountered somebody who was segmenting longer ones and matching the existing translation to new short bits at the same time, but not recall who it was to ask for attention...

Unfortunately, the T:91 as above link is an old part of the page, that I do not doubt I am not the only one who had already translated it many days back.

Well, we both understand segmenting translation units does not require human hands actually, since the issue is to align the longer units into new T: numbers, but not the contents themselves... Of course, shorter units saves everybody's energy in the long run, since the system has better chances to reuse shorter ones later compared to longer ones, which means translators will see samples on the right pane to work less pain (;. Kindly, Omotecho (talk) 21:07, 22 April 2025 (UTC) Reply

@Omotecho: I do not split all translation units; I only split them when it is necessary to add or change translation variables due to changes in the source text (which may be changes made by others or by myself), and afterwards, sometimes I also update the translations.

It is not just a matter of splitting; since the source text may have been modified beforehand or the corresponding translations may have become outdated, I believe it is difficult to handle the splitting of translations systemically.

I think we should also request cooperation from those who are adding variables to large translation units on various pages, asking them to refrain from making changes. Shirayuki (talk) 10:55, 23 April 2025 (UTC) Reply

You are so kind indeed showing the larger picture to me, and there are more points to watch for, I was blind folded. Yes, we need to accommodate changes made in the translation originals. And truly, if the translation original be segmented _after_ many translators on languages have already worked on that part, that is annoying from a translator's scope, not appreciated nor encourage working on that part: It leaves bitter taste with me, that readers will wonder why the headnote tells them their local language page is not updated or which part is not suited to the reality.

I will note and be careful for those parts updated, and wish I will coordinate my translation as you do. Thank you taking time replying me. veru much. I'd call it case solved for my question here. Kindly, Omotecho (talk) 15:19, 23 April 2025 (UTC) Reply

As a translator, here are my cons for long units:

• It is a burden to translate big units, as you seem not to progress.
• You dont see easily what has changed.
• They are difficult to reread and correct since a single ID is assigned to the long unit (several sentences sometimes) and you must search within the text.
• The long units are those which most remain untranslated.
• Translation suggestions not often appear with long units.
• diff on messages cannot be closed to retrieve space on the screen.
• units with 4,5,6... sentences are repulsive

My pros for short units:

• It is pleasant translate short units and progression is fast.
• You see immediately what has changed.
• rereading is fast.
• correction is fast since each small unit has its ID
• The short units are those which are most translated.
• Translation suggestions often appears immedialty for short units.
• diff is reduced and leaves space on the screen.
• units with 2 to 3 sentences are acceptable
• splitting long translated units into smaller ones is easy since you move already translated lines in sequence to following units
• I am favorable to @Shirayuki principle even if detail is pushed to each sentence.

Christian 🇫🇷 FR 🚨 (talk) 07:17, 2 May 2025 (UTC) Reply

Hi Shirayuki :) Could I ask why you're changing external links to doc.wikimedia.org to wmdoc: wikilinks? In many cases, IMO, the external link styling looks/fits better in the context of the page (e.g., [2]); and - in any event - I'm not sure that all external links to doc.wikimedia.org need to be replaced with wikilinks in this way. Is there a reason to prefer formatting them as wikilinks that I'm not aware of? Apologies if I've missed anything here. Best wishes, ‍—‍a smart kitten _[meow] 21:25, 27 April 2025 (UTC) Reply

From a behind the scenes point of view, Its better for how they are tracked in the various DB tables such as the externallinks table. P858snake (talk) 11:12, 28 April 2025 (UTC) Reply

@P858snake Fair enough - I suppose my next question would be, is that something that we need to be/should be considering when editing pages on MW.org? (/genuine question) If it is, then I guess the changes make sense (though IMO it'd be nicer if they had an edit summary with a brief reason behind the change). I guess I'm used to enwiki's w:en:Wikipedia:Don't worry about performance from when I was editing over there, but I don't know whether MW.org generally shares that perspective :) Best, ‍—‍a smart kitten _[meow] 11:43, 28 April 2025 (UTC) Reply

Hi, you have cancelled -> https://www.mediawiki.org/w/index.php?title=Help%3AExtension%3AKartographer&oldid=prev&diff=7601386 but I dont understand japanese. The idea, if you take time to analyse my proposal was : 1. do not impact translators if the number is modified 2. respect the number format according to user language

I dont see what is wrong. If you suspect formatnum: is making a bad translation you should request the correction for japanese to be aligned correctly with other formats rather than making an undo and hiding the problem being aware of it. If the problem is known, a reference should be appreciated for checking.

Can you clarify please ? Thanks. -- Christian 🇫🇷 FR 🚨 (talk) 06:49, 2 May 2025 (UTC) Reply

formatnum is fine — Japanese also uses "3.6" for decimals. But this case is special because it’s followed by "million".

In Japanese, "3.6 million" is translated as "360万", not "3.6百万", which sounds unnatural and confusing.

If the number is turned into a variable, the translation interface shows 1ドル million instead of 3.6 million, and we can no longer rewrite the number.

So I reverted the change to keep the number as a literal, allowing translators to produce natural output like "360万". Thanks.-- Shirayuki (talk) 10:56, 2 May 2025 (UTC) Reply

Adding comma-separator + word-separator and then getting all three actions inside a tvar doesn't fix my problem... My language only allows me to translate the word "itself" if it comes before protect, not after. Eduardogobi (talk) 05:57, 9 May 2025 (UTC) Reply

@Eduardogobi: I made adjustments based on feedback from someone who understands Brazilian Portuguese. I hope this helps — how does it look now?-- Shirayuki (talk) 10:54, 9 May 2025 (UTC) Reply

Yep, commit your last edit to Fuzzy, it will solve our issue. Thanks! Eduardogobi (talk) 05:34, 10 May 2025 (UTC) Reply

Hi @Shirayuki, you just reverted this edit I made on Download. As I wrote in my edit summary, I believe the content is largely duplicated in the "All versions" box. You mentioned the old branch support. I don't see why this is so relevant, as this page seem to be about downloading for new installations, not Manual:Upgrading.

I have a strong motivation to make the documentation generally much more concise, but I am always grateful when people push back, because I am relatively new here! Douginamug (talk) 22:12, 9 May 2025 (UTC) Reply

@Douginamug: Instead of listing the releases, I think it would be better to direct users to Manual:Upgrading, but that page does not mention the "heavily modified installations" you removed.

The translation unit you removed has been translated into many languages, so I’m generally opposed to its removal.-- Shirayuki (talk) 22:27, 9 May 2025 (UTC) Reply

@Douginamug: Your changes to Download is quite bold and has a significant impact on the many existing translations. How about drafting it in a subpage of your user page first, and then proposing it at Project:Village Pump? Shirayuki (talk) 23:25, 9 May 2025 (UTC) Reply

(talk page stalker) Personally I agree with Douginamug that the content removed was redundant on the merits, but also with Shirayuki that it would be wise to draft and discuss changes rather than implementing them boldly. * Pppery * _{it has begun} 05:27, 10 May 2025 (UTC) Reply

@Shirayuki I have reverted all my recent edits, restoring the last version you marked for translation. I will do as you suggest, and make a personal subpage first before proposing it at the Village pump.

I was intentionally being bold, you are right! I fear that being less bold will mean I ultimately do less editing, and as far as I'm concerned, there is really a lot that should be edited (eventually). Despite being bold, I meant no respect to all the translation work that has and is being done. Douginamug (talk) 05:32, 10 May 2025 (UTC) Reply

This specific page is super high-profile (linked from the main page and the sidebar), so uses special rules. For lower-profile pages (basically anything else), boldness is fine and encouraged. * Pppery * _{it has begun} 05:38, 10 May 2025 (UTC) Reply

Practical questions before I beging: Is it preferred to always wrap translated blocks in the {{void}} template instead of deleting them? If yes, can I move voided blocks to the end of the page, to avoid cluttering the source? (It seems only possible to edit translated content properly with the source editor) Douginamug (talk) 05:42, 10 May 2025 (UTC) Reply

The purpose of the void blocks is for translated content that cycles in and out of existence as new versions are released (for example, sometimes there's a legacy non-LTS version and a legacy LTS version, sometimes there's two legacy LTS versions, etc.), so it always appears in the translate UI and the translations can be reused with each cycle. Example void cycling edit. Content that's going to disappear and stay gone forever can just be deleted.

(It seems only possible to edit translated content properly with the source editor) -> indeed, VE and translate don't play nice with each other, which is a known issue and not easy to fix because they work in fundamentally incompatible ways. * Pppery * _{it has begun} 05:50, 10 May 2025 (UTC) Reply

Since this "void cycling edit" is quite tedious every time, I’m hoping someone could write a Lua module to automate the toggling of visibility? It would be a huge help! :) -- Shirayuki (talk) 06:06, 10 May 2025 (UTC) Reply

And, as a technical matter, it doesn't matter where the void blocks are, but personally I would prefer they stay near where they will get unvoided to, to make the voiding an d unvoiding easier. * Pppery * _{it has begun} 05:53, 10 May 2025 (UTC) Reply

Great! Thanks both of you for the information, that's enough for me to work from for now :) Douginamug (talk) 05:54, 10 May 2025 (UTC) Reply

Your edit summary "Revert as most of their edits have been reverted and are not trustworthy" is nonsense as most reverted does not make sense as ip address may be shared by multiple users. 185.137.137.154 07:53, 24 May 2025 (UTC) Reply

Hi, Shirayuki. As you know, in translations of this page where segment 10 (a section title containing two variables) is translated, a spurious span is generated above the section. Even though you tried to fix the issue (among other users, in different ways, such as @Tooki, @Pppery or myself), as of now, the issue is still there, as the following code is generated where it shouldn't:

<span id="Scenario_2:_Incorrect_use_of_<tag">_instead_of_</tag>"></span>

Sabbut (talk) 09:41, 8 June 2025 (UTC) Reply

Hello Shirayuki, your latest update to mark this document for translation leaves the "It is preferable to use..." paragraph untranslated again. Why? It's pointless to translate when some strings are still left in English and there's nothing we can do.

While I'm at it I should mention that translation markup of lists in that page is all wrong according to the manual, with translation tags wrapping also bullets for single items. Tactica (talk) 14:06, 22 June 2025 (UTC) Reply

@Tactica: There's no need to make the ‎<code>...‎</code> tag translatable, so it should be excluded using the ‎<tvar>...‎</tvar> tag instead.

In Special:Diff/7701851, you wrapped * {{ll|Skin:MonoBook}} in ‎<translate>...‎</translate>, which is also incorrect.

If the tagging is not correct, I can't just mark the page for translation as-is.

As for the existing tagging of list items, there are already many translations that would be affected by any change. Therefore, it's preferable not to modify them just to follow the manual.-- Shirayuki (talk) 22:04, 22 June 2025 (UTC) Reply

This revert of yours doesn't make any sense. As it is, the page is again broken because MediaWiki:pagecategories was deleted on this site. With my change, the intent of the document remains intact as translators can still translate "Categories" as intended.

Really, with this kind of behaviour sometimes it gets frustrating to try and contribute anything to this site. Tactica (talk) 22:52, 23 June 2025 (UTC) Reply

Even if MediaWiki:pagecategories doesn't exist on this site, it's still a standard MediaWiki message, and its source text and translations do exist. You seem to have no understanding of that fact.

The translation unit T:18 you tried to change has a large number of translations, and I don’t think your edit is important enough to justify invalidating all of them and forcing them to be retranslated. Shirayuki (talk) 22:59, 23 June 2025 (UTC) Reply

In other words, saving you some work is more important than usable documentation.

I'll remember that. Tactica (talk) 23:04, 23 June 2025 (UTC) Reply

Hi Shirayuki :) If possible, please could I ask that you provide more information in edit summaries when making changes to previously-prepared translation markup (e.g., removing translation tags from certain text)? E.g., in Special:Diff/7732048, you removed the translation tags from the custom step within the 'installation' section; but, as the edit summary for that edit was just simplify translation units, I'm not sure why that removal was made.

From my perspective, that sentence should be fine to be translated (& I imagine that it might potentially be confusing to people reading the translated versions of the page if it isn't). So I guess I'm left not really seeing a clear reason why the tags have been removed (and therefore wanting to re-add them to the page); but at the same time not wanting to edit-war by reverting your removal of them.

As another example within that edit, I'm not sure why the multiple translation variables within the description for $wgEmailAuthUnmaskedDomains were condensed down into one. From my perspective, when preparing that description for translation, I deliberately put each domain name into its own tvar; so that (e.g.) languages that would organise the list in a different way (and/or that would use a different separator between the domain names than a comma) could do so with more flexibility than with one 'mega-tvar' that contained all the domains together. But without knowing the reason behind your change, and because I don't want to edit war, I'm again reluctant to blindly revert.

Let me know if I've worded anything poorly, and/or if you have any queries about anything I've said. I apologise if there's anything here that I'm not taking into account. Best wishes, ‍—‍a smart kitten _[meow] 06:09, 10 July 2025 (UTC) Reply

@A smart kitten: Thank you for your message, and I’m sorry for not providing enough detail in the edit summary — it's indeed too short to fully explain everything.

As you know, parts that should not be changed by translators need to be excluded from translation using ‎<tvar>...‎</tvar>. I reverted parts where this wasn't sufficiently enforced, to avoid unintended edits in translated versions.

Also, regarding the variable names like $domain1, I’ve seen several cases where translators mistakenly translate such names when they’re written in plain English words. To avoid this, I replaced them with numeric placeholders like 1,ドル which are generally safer and less likely to be changed.

I'm certainly aware that some languages use something other than commas for list separators.

Using messages like {{int|comma-separator}} allows commas to be automatically replaced with the appropriate symbol for the page language, so I’d like to apply that where possible when there's time.

However, doing this can make the source harder to read, so in some cases it might be better to exclude the list from translation and present it as bullet points instead. Shirayuki (talk) 11:56, 10 July 2025 (UTC) Reply

Thanks for the quick reply (and apologies for taking a few days to get back to you) :)

As you know, parts that should not be changed by translators need to be excluded from translation using ‎<tvar>...‎</tvar>. Indeed :)

I reverted parts where this wasn't sufficiently enforced, to avoid unintended edits in translated versions. For the sentence in question, I marked it up as:

Add a {{ll|<tvarname=1>Manual:Hooks#Writing_a_hook_handler</tvar>|hook handler}} for the <tvarname=2>{{ll|Extension:EmailAuth/EmailAuthRequireToken|EmailAuthRequireToken}}</tvar> hook.

Please could you let me know how this could be improved? As far as I can see, everything not in a tvar (except for the first {{ll}} template name) is a part of the sentence that should be translated. (Am I missing something?)

Also, regarding the variable names like $domain1, I’ve seen several cases where translators mistakenly translate such names when they’re written in plain English words. To avoid this, I replaced them with numeric placeholders like 1,ドル which are generally safer and less likely to be changed. Hmmm... yeah, that makes sense. I gave the variables names like $domain1 in case knowing their type of text would make life easier for translators. I guess there are probably benefits and drawbacks to either approach - I see where you're coming from with the issue you've pointed out.

Using messages like {{int|comma-separator}} allows commas to be automatically replaced with the appropriate symbol for the page language, so I’d like to apply that where possible when there's time. However, doing this can make the source harder to read [...] Yeah. I get the reasoning for using {{int|comma-separator}}; but at the same time it does make the page a bit more unwieldy to edit, and potentially also allows for less flexibility when translating (although - as I'm not a translator - I'd defer to others on that front).

One thing I forgot to say in my original message is that I also split the domain names into multiple tvars so that I could include the word "and" at the end of the list (to allow the sentence to flow a little more easily), but I guess it's not a massive problem if the sentence doesn't include that.

It might also be worth noting that the current (singular) tvar appears to have potentially confused one translator, who may have been expecting it to only contain a single value - [3]. (I'll add some qqq documentation for that segment after leaving this message.)

[...] in some cases it might be better to exclude the list from translation and present it as bullet points instead. Personally speaking, I'd probably prefer not to do that here, as I feel like the current structure (where the default values can be included in the same line as the config variable's description) might be slightly cleaner/more readable than if the default values were in a list. In any event, thanks for the suggestion, though - I'll keep it in mind for the future :)

Best, ‍—‍a smart kitten _[meow] 13:15, 13 July 2025 (UTC) Reply

Regarding the {{ll|<tvarname=1>...</tvar>|hook handler}} markup: the ll| part should also be included in the ‎<tvar>, since the template name isn’t meant to be translated or changed. Shirayuki (talk) 21:10, 13 July 2025 (UTC) Reply

Ah, thanks for pointing that out! I'm not sure why I didn't think to include that before. Best, ‍—‍a smart kitten _[meow] 07:39, 14 July 2025 (UTC) Reply

Hi again - please could you explain if there was anything else wrong with the updated markup, or if there was another reason for its re-removal without an edit summary? The updated markup was:

Add a {{<tvarname=1>ll|Manual:Hooks#Writing_a_hook_handler</tvar>|hook handler}} for the <tvarname=2>{{ll|Extension:EmailAuth/EmailAuthRequireToken|EmailAuthRequireToken}}</tvar> hook.

As far as I can see, everything that shouldn't be translated (including the {{ll}} template call) is now within a tvar; and the segment can be translated similarly to Add a {{1ドル|hook handler}} for the 2ドル hook.. Am I missing something again (as I previously was)? /genq

(As a side note, I preferred the style of the "EmailAuthHooks in WikimediaEvents" link prior to this change - IMO it makes more sense with all of the text within the link (as I believe - when reading the text - it makes it slightly clearer what the link is pointing to); and TBH I don't like the idea that we have to make the page slightly less readable in general, to be able to make it translatable. Do you mind if I change it back? I recognise that - with its number of tvars - this segment may not be the easiest to translate, and I was planning to add qqq documentation to assist translators on that front.)

Best, ‍—‍a smart kitten _[meow] 08:55, 15 July 2025 (UTC) Reply

@A smart kitten: I reverted the change temporarily because I thought the hook page name might be missing "/Hooks" after the extension name. However, since the markup itself was correct, it seems the reversion wasn’t actually necessary.-- Shirayuki (talk) 10:18, 15 July 2025 (UTC) Reply

Thanks for the reply :) I'll reapply the markup. Best, ‍—‍a smart kitten _[meow] 10:36, 15 July 2025 (UTC) Reply

Unless you enjoy doing this kind of edits every time someone modifies a translatable page I strongly suggest you amend the documentation. That page doesn't mention {{Ll }} at all for example.

I'd do it myself but (1) the logic behind the syntax is beyond my comprehension and (2) documenting it with wikitext requires developer-grade template knowledge. It's hardly surprising that text based examples are scarce (and defective, it seems) and it's all mostly done with videos. Tactica (talk) 06:00, 20 July 2025 (UTC) Reply

> On mediawiki.org, you can use Template:Localized link to link to pages on the same wiki as a simpler alternative to Special:MyLanguage/.

Since {{Ll }} is just a shorthand for {{Localized link }}, it's not entirely unmentioned.-- Shirayuki (talk) 06:49, 20 July 2025 (UTC) Reply

Great, so it is mentioned but not used, so the documentation remains suboptimal.

BTW your latest simplification in Extension:Cite made the second wikilink within the Limitations section use a hardcoded string, so the Spanish translation now looks like crap with a first capital letter in the middle of a sentence. Thank you very much. Tactica (talk) 07:41, 20 July 2025 (UTC) Reply

@Tactica I've boldly modified that link so that only its target (and the ll| template call) are now within the <tvar></tvar> tags, given that the link's text needs to be capitalised differently to the target page's title. Best, ‍—‍a smart kitten _[meow] 15:15, 20 July 2025 (UTC) Reply

Thanks ~2025-27996-1 (talk) 21:41, 27 July 2025 (UTC) Reply

Thank you for your previous work on marking Skin:Lakeus for translation and helping me with formatting! It's sort of pity that I couldn't find a documentation about translation pages.

So, in my newer edits regarding the dark mode, I used links like this:

[[#Migration to dark mode|Migration to dark mode]]

and I sort of don't know how should I wrap them into tvars. Could you kindly help me with this matter? Thanks in advance! -- Lakejason0 (talk) 09:42, 28 July 2025 (UTC) Reply

I have created a separate anchor, could you please kindly check if that was correct? Thanks in advance! -- Lakejason0 (talk) 12:52, 29 July 2025 (UTC) Reply

@Lakejason0 I've marked it for translation. Ciencia Al Poder (talk) 20:39, 29 July 2025 (UTC) Reply

Hi, I don't really understand why these reverts were made, without explanation:

• https://www.mediawiki.org/w/index.php?title=Help:Temporary_accounts&diff=next&oldid=7807234
• https://www.mediawiki.org/w/index.php?title=Help:Temporary_accounts&diff=prev&oldid=7807209

Am I doing something wrong? I'm just removing accidental newlines created by the placement of the html tags. Thanks. FaviFake (talk) 11:34, 11 August 2025 (UTC) Reply

@FaviFake: I did not revert your edits, but only added blank lines to follow the conventions below:

• It is common practice to insert a blank line immediately before section headings. In fact, when editing by section, a blank line is automatically inserted just before the edited section.
• However, there is a special case when the line immediately before a section heading is ‎<translate>. In that case, insert a blank line immediately before that tag.

Shirayuki (talk) 12:33, 11 August 2025 (UTC) Reply

@Shirayuki Thanks. That effectively resulted in the 2 accidental newlines being reinstated again. Is there a way they can be removed for good? I think the conventions shouldn't be applied if applying them necessarily creates a blank newline between sections. FaviFake (talk) 12:54, 11 August 2025 (UTC) Reply

@FaviFake: As long as translators can translate the page and the translations display correctly, I don't really care whether there is one blank line or two blank lines between sections.-- Shirayuki (talk) 13:27, 11 August 2025 (UTC) Reply

@Shirayuki Sure. I fixed them again, but this time my fix complies with the two conventions you mentioned. Thanks FaviFake (talk) 13:32, 11 August 2025 (UTC) Reply

Why did you revert this?? Waddie96 (talk) 22:18, 13 August 2025 (UTC) Reply

@Waddie96 Help:System_message#Avoid_fragmented_or_"patchwork"_messages Shirayuki (talk) 22:21, 13 August 2025 (UTC) Reply

Okay, can we capital S Waddie96 (talk) 22:24, 13 August 2025 (UTC) Reply

@Shirayuki: related question about Special:Diff/8274164: can you tell me in which human language that won't work? AFAIK that's the only part in the statement that anyone in a locale other than English will change, hence my attempt to make that part translatable. The blanket URL you mention doesn't even begin to give an explanation for your revert, and if this is an rtl/ltr issue then the change needs to be improved, not reverted. Not making things translatable isn't the solution. Tactica (talk) 21:29, 9 March 2026 (UTC) Reply

@Tactica: Because word order differs by language, making only "/path/to" translatable is inappropriate. There is no proper way to mark this up right now.-- Shirayuki (talk) 21:39, 9 March 2026 (UTC) Reply

I can't figure out this change of yours. It needs to be updated, because it's showing the wrong information on the page (1.44.0 is not LTS, but 1.43.3 is). Please consider making this portion of the page easier for others to update. - dcljr (talk) 03:44, 21 September 2025 (UTC) Reply

@Dcljr: Ask for help at Project:Village Pump. Manually updating this every time a new version is released is a waste of time, especially since there are only about four possible patterns that appear in a cyclical manner. Someone should automate this using Lua.-- Shirayuki (talk) 05:28, 21 September 2025 (UTC) Reply

OK, but you are the one who made the edit that is causing the incorrect information to be displayed now. It would be great if you took a little time to fix the problem you caused. - dcljr (talk) 12:29, 21 September 2025 (UTC) Reply

Nevermind. I got it to work. - dcljr (talk) 14:19, 21 September 2025 (UTC) Reply

That means you will be the one asked to fix things next time there is a version update :P -- Shirayuki (talk) 21:59, 21 September 2025 (UTC) Reply

Unless I do something about the crap way things are done on that and similar pages. - dcljr (talk) 23:58, 21 September 2025 (UTC) Reply

Hello, as you usually mark this page for translation: Some recently added parts of Help:CirrusSearch cannot be translated in the moment. These are Help:CirrusSearch#Articlecountry in total and Help:CirrusSearch#creationdate and lasteditdate in parts (some sentences, all the tables, the title itself due to the "and", but there could be, instead, added a comma). For sentences, I’ve added the tags myself in the past, but I am unsure about the section title. By the way: Maybe all the other section captions should be made translatable, as well, for non-Latin script additions? I am undecided. — Speravir (talk) – 01:42, 8 October 2025 (UTC) Reply

@Speravir: Regarding the section headings, I think they should not be made translatable because the current headings are the keywords themselves, not the search target categories.

Also, when section headings contain "and" or commas, requests often arise to make them translatable, so using slashes to separate them might be a more neutral approach.-- Shirayuki (talk) 21:16, 8 October 2025 (UTC) Reply

Furthermore, I think insource should not be capitalized, because it does not work when the first letter is uppercase. The same probably applies to the other keywords as well.-- Shirayuki (talk) 21:35, 8 October 2025 (UTC) Reply

Thank you for your edits. So, there have been even more sentences missing the translation tags. — Speravir (talk) – 22:34, 8 October 2025 (UTC) Reply

FYI I've undone several of your translation encouragement actions. Since the translate UI doesn't allow edit summaries, I'm explaining why here:

• Manual:CommonElements.css, Manual:checkLanguage.inc - the file was removed from MediaWiki years ago, there's no point in translating it now.
• Extension:GoogleLogin/PreAuthManager - this is documentation for a decade-old bit of code that isn't being maintained, there's no point in translating it now.

* Pppery * _{it has begun} 23:02, 23 November 2025 (UTC) Reply

@Pppery: I haven't seen the manuals for the removed files marked as "discouraged" at all. Should each of them ideally be marked that way?-- Shirayuki (talk) 23:20, 23 November 2025 (UTC) Reply

I do it when I notice, not via any kind of systematic review, but yes, any manual page for a file (or configuration setting, or anything else) marked as removed before {{MW legacy lts branch number }} (currently 1.43) should definitely be discouraged, and I wouldn't object to discouraging anything marked as removed in any version either. * Pppery * _{it has begun} 23:31, 23 November 2025 (UTC) Reply

LBLaiSiNanHai (talk) 11:15, 24 December 2025 (UTC) Reply  

@LBLaiSiNanHai: Yes Done - Shirayuki (talk) 11:19, 24 December 2025 (UTC) Reply

excuse me, I wrote a page Manual:NotificationService.php, may you mark it translate? thanks very much LBLaiSiNanHai (talk) 11:50, 24 December 2025 (UTC) Reply

also, you are the most active current Translate Admin, i hope you see this topic, you suggestion to me will be important LBLaiSiNanHai (talk) 11:52, 24 December 2025 (UTC) Reply

@LBLaiSiNanHai: Thank you for your work on expanding the documentation pages.

However, the page you mentioned currently contains incorrect or problematic markup, so it cannot be marked for translation in its present state. In general, the necessary translation markup should be added by one of the existing Translate administrators. If contributors add it themselves in a non-standard way, it can actually increase the workload for the Translate admins, so I would appreciate it if you could avoid doing so.

Regarding your request for TA rights, I will not comment on that here, but I believe you will understand my position from the above. -- Shirayuki (talk) 12:06, 24 December 2025 (UTC) Reply

Many user using old version of MediaWiki, we should archive them, not delete them, I think. LBLaiSiNanHai (talk) 06:18, 30 December 2025 (UTC) Reply

@LBLaiSiNanHai: Thanks for your message.

I understand the concern about people still using older versions of MediaWiki, and in general I also think archiving can be preferable to deleting. However, the pages I deleted all shared the same characteristics:

• They were created mechanically by me in 2020.
• Since creation, nobody has added any further description or documentation.
• There is no realistic prospect that these pages will ever be expanded.
• The features described were removed in versions older than the current legacy LTS (1.39), meaning they are already outside the range of currently supported releases.

Given that these pages only existed as empty placeholders for obsolete functionality, I felt it was cleaner to delete them rather than leave them indefinitely in that state.-- Shirayuki (talk) 06:36, 30 December 2025 (UTC) Reply

Agreed these should be deleted. * Pppery * _{it has begun} 06:55, 30 December 2025 (UTC) Reply

Hello, Shirayuki-san, so appreciating you taking up the role of translation admin every day. May I bother you and request to fuzzy a caption on File:Editing maps in TemplateData Editor.png [4] please? Wish you another brilliant year in 2026, kindly, -- Omotecho (talk) 23:19, 17 January 2026 (UTC) Reply

Hello, could you please take look at Project:Village_Pump#Move_draft_in_my_user_page_to_main_namespace? Thanks! Diskdance (talk) 08:45, 9 February 2026 (UTC) Reply

Hello,@Shirayuki You have just canceled the markup we made. Please note that more than 45% of the text is not marked for translation, which I have already done. We need this page to complete the translation. As I do not have the rights in MediaWiki, I hope that an administrator will be able to correct this for me. Thank you very much for your support. Best regards, Dezedien (talk) 19:24, 11 February 2026 (UTC) Reply

Hi @Shirayuki, I have added a mark. Could you please check if it is correct and activate it if possible? Thank you very much. Dezedien (talk) 00:40, 12 February 2026 (UTC) Reply

@Dezedien: Read Help:System message#Avoid fragmented or "patchwork" messages.-- Shirayuki (talk) 11:53, 12 February 2026 (UTC) Reply

@Shirayuki, I would like to clarify my intention.

When a page is written in French, all original English text should be translated completely. Leaving full sentences in English inside a French page creates inconsistency for readers.

Using the translate tag is not "patchwork." It is simply the correct way to mark text for translation in MediaWiki. The goal is clarity and full localization.

This does not affect internationalization. I have translated content into multiple languages for many years without causing any i18n issues.

My objective is only to ensure that French readers receive fully translated content, not partially English text.

Thank you for your understanding. Dezedien (talk) 00:17, 16 February 2026 (UTC) Reply

You should use tvars rather than splitting nontranslatable bits into separate units. * Pppery * _{it has begun} 07:19, 22 February 2026 (UTC) Reply

I don ́t see Wikivy Foundation in Hosting services although it is a wiki farm powered by MediaWiki. Darrrrmilk (talk) 01:48, 15 February 2026 (UTC) Reply

Hi can you please answer to this Darrrrmilk (talk) 22:00, 15 February 2026 (UTC) Reply

@Darrrrmilk: I don't know that foundation, so there's nothing I can do about it.-- Shirayuki (talk) 23:04, 15 February 2026 (UTC) Reply

Ok thank you for replying @Shirayuki Darrrrmilk (talk) 23:18, 15 February 2026 (UTC) Reply

The wiki farm is not made yet put it is TBA but I heard the registration page and document is filled out but it is not founded yet Darrrrmilk (talk) 00:26, 16 February 2026 (UTC) Reply

I want to add localization to "Extension:UniversalCalendar". Could you tell me how to do it? HoshinoKennji (talk) 09:40, 15 February 2026 (UTC) Reply

@HoshinoKennji: Please refrain from preparing the page of an experimental extension for translation.-- Shirayuki (talk) 10:49, 15 February 2026 (UTC) Reply

I am writing a plugin introduction and plan to translate it into at least Chinese, Japanese, English and Korean. This is my first time creating an extension page and I have no experience, so I am gaining experience for the second extension that will be released soon. ~2026-10146-04 (talk) 10:59, 15 February 2026 (UTC) Reply

I see. Please disregard my previous reply; I misunderstood earlier. ~2026-10146-04 (talk) 11:12, 15 February 2026 (UTC) Reply

As the extension is still experimental, the page may change substantially.

Marking it for translation now could impose unnecessary work on translators due to frequent updates.

Therefore, it would be better to wait until the content stabilizes.-- Shirayuki (talk) 11:16, 15 February 2026 (UTC) Reply

--Warning: You are currently editing an outdated version of this page. If you publish it, all later changes will be lost.-- appears only after opening the history and some of the edits. Then after opening the edit, Sometimes I have to perform this operation twice or more. Thanks for the editing and cooperation. :)) ENeRZet (talk) 10:57, 16 February 2026 (UTC) Reply

Shirayuki,

I need to move lines 306-344 into a separate template in order to implement support for multiple licenses, as this code will be called once per every stated license and it would be silly to repeat this in an already intricate template. Shall I remove the ‎<translate>...‎</translate> tags in the new template or is there any way existing translations can be reused? I would prefer the change to be as painless as possible for everyone. TIA.

Oh, and I know Template:ExtensionLicense exists, but it never solved the underlying problem of pages being categorized as using an "unknown license". That's the problem I intend to solve here. Tactica (talk) 16:08, 24 February 2026 (UTC) Reply

So basically I want to report this brand new wiki farm created this month called the WIkivy Foundation and here is the link-https://meta.wikivy.com/ but I know I should not be reporting this on MediaWiki Steward's talk pages so please tell me where to report this.

Reason:Copy and pasting policies from Miraheze without proper attributions. While they do mention that some of their policies are inspired by Miraheze it almost looks like a copy and paste for a lot of them. Such as global policies,templates,Meta pages,and Wiki Policies(there are more,these are just some major ones). So basically they replace the "Miraheze" part in policies and replace it with "Wikivy"

Here is an example of what I said above:

Wikivy-"The Content Policy exists to help the Wikivy Foundation maintain a safe, welcoming, and productive environment for all contributors. Wiki requesters, reviewers, and administrators are expected to understand and apply this policy when requesting new wikis and when overseeing existing ones.

Administrators play a crucial role in ensuring that on-wiki content complies with these guidelines. Repeated violations—especially those left unaddressed by local admins—may result in wiki closure or Steward conservatorship.

This policy applies to everyone.

All editors, not just leadership, should make an effort to follow these guidelines as well as any additional local content policies a wiki adopts. Together, we can keep Wikivy a collaborative, mission-aligned, and trustworthy platform for free knowledge."-Wikivy Content Policy

Miraheze-"The Content Policy seeks to help Miraheze maintain a safe, welcoming, and productive environment for everyone. We'd like to remind our wiki requesters, reviewers and administrators to be familiar with this policy and apply it when handling new requests or overseeing their wikis. Wiki administrators play a crucial role in ensuring that on-wiki content complies with these guidelines – repeated policy violations without local administrator action may result in wiki closure or Steward conservatorship.

This policy is not just for those in leadership roles. All our editors should make an effort to adhere to this policy and any additional local content policies that might be in place on the specific wikis they contribute to. Together, we can make Miraheze a fantastic place for knowledge-sharing and collaboration!"-Miraheze Content Policy

You see this is just copy and paste but replacing "Miraheze" with "Wikivy"

Now I'll show an example of copy and pasting policies(Using Privacy Policy as example):

Wikivy-"(snip)"

Also not to mention that the founder of Wikivy foundation is not a Miraheze Steward nor did they ever get permission to straight-up just copy and paste Miraheze stuff. Darrrrmilk (talk) 05:58, 1 March 2026 (UTC) Reply

Wait ur not steward mb Darrrrmilk (talk) 05:58, 1 March 2026 (UTC) Reply

On top of this,they also deleted my wiki saying my copy and pasted without attributions while I did give attributions multiple times throughout the wiki and they refused to block 2 people that where harassing me,one of which was blackmailing another user,spreading false info,stating his opinions as facts,and vandalizing my wiki. But a steward blocked me one day for vandalizing that guys userpage because I got really mad since he was spewing a big hate on me but while I do commit to have vandalized what the other 2 users have done is very worse yet they got away due to this corruption. Darrrrmilk (talk) 06:10, 1 March 2026 (UTC) Reply

@Darrrrmilk: This matter does not concern MediaWiki.org, nor am I affiliated with Miraheze.

Please refrain from posting further comments about disputes unrelated to this site on my talk page.

If this continues, I may take administrative action.-- Shirayuki (talk) 06:22, 1 March 2026 (UTC) Reply

Dear @Shirayuki:

At the risk of becoming a PITA (and believe me, I'm doing my best to avoid just that) I must ask because I'm completely baffled now. The section "Symbols, colons, brackets, etc. are parts of messages" under Help:System message advocates this, and yet you keep undoing about every effort towards that end, for example in T:37 as part of Special:Diff/8277169, which looks the more surprising coming from a Japanese person. As I understand it this isn't patchwork because I was making the whole string translatable, and besides there's absolutely no reason to prevent "Category:Cars" from being translatable too. ISTR reading Arabian text must not be italicised for example or something along those lines, so the more reason to make e.g. style translatable...?

I'll be very interested in your reasoning for this one. Tactica (talk) 23:50, 11 March 2026 (UTC) Reply

@Tactica: I could understand making Category:Cars a separate translation unit. However, I don't see a strong reason to include the bold markup in the same translatable message.

The actual text here is just "No translation", and the bold markup is only formatting.

Including the colon in the existing T:37 unit might make sense, since some languages insert a space before a colon. But extending the same translation unit further to include formatting or the category name doesn't seem necessary to me.-- Shirayuki (talk) 11:08, 12 March 2026 (UTC) Reply

Almost two months ago, you protected the above page at the administrator level. I suggest lowering the protection to autoconfirmed since all accounts that have vandalized the page weren't autoconfirmed at the time of vandalism occurrence, also the fact that certain WMF accounts might not be able to update the page due to not having thre required permission as well. ToadetteEdit (talk) 15:31, 18 March 2026 (UTC) Reply

@ToadetteEdit: Thank you for your suggestion. You are correct, so I have lowered the protection level. Shirayuki (talk) 21:18, 18 March 2026 (UTC) Reply

Hi Shirayuki,

The reason why in {{Wrapper }} I changed the condition {{#ifeq:{{{any-left|}}}|no|...|...}} into {{P{{#ifeq:{{{any-left|}}}|no|1|2}}|...|...}} is that the text shown was "...will work here.However, the following are...". The rationale is the fact that if I write a{{#ifeq:XXX|YYY| B | C }}d I get "aCd", whereas if I write a{{P{{#ifeq:XXX|YYY|1|2}}| B | C }}d I get "a C d". However, despite my edit, here the leading space is still suppressed. Is there any way around this? --Grufo (talk) 13:39, 2 April 2026 (UTC) Reply

Hi there, Shirayuki. Thanks for your tireless work here on mediawiki.org, including cleaning up some of the stuff I do, sometimes oblivious to the implications to the translated tags. However, I can't understand why you performed this revert. Can you explain what was the issue with my changes? --Waldyrious (talk) 13:27, 3 May 2026 (UTC) Reply

@Waldyrious: Conversely, explain what issue exists in the current version. Your edit summary "allow reason string to be omitted" is unclear.-- Shirayuki (talk) 14:55, 3 May 2026 (UTC) Reply

The current default value for the reason parameter refers to MediaWiki versions, but this template is useful in pages that may not necessarily be outdated due to new releases of MediaWiki. The particular example I meant to use this in was Manual:PHP unit testing/Getting started, which was marked as outdated without sufficient details to fill in the reason parameter. Omitting the parameter therefore allows editors to mark a page as outdated even if their knowledge of the specifics is insufficient to provide a detailed reason, and without having the template incorrectly claim that the cause of the out-of-dateness is linked to old versions of MediaWiki.

Furthermore, this makes the template code's simpler, and more inline with the MediaWiki's default behavior for template parameters.

In any case, following the principles of AGF, I still believe your reversal would be justified only if my original edit caused actual issues, rather than merely because its rationale was not clear to you (I'd be happy to explain it, as I did above, had you asked). I therefore ask that you restore the edit — unless, of course, there are actual negative consequences to my edit that I have failed to identify. --Waldyrious (talk) 14:36, 8 May 2026 (UTC) Reply

@Waldyrious: Thank you for the detailed explanation. I understand your intention now.

My concern was that the change makes the behavior depend on the distinction between an omitted parameter and an explicitly empty one.

While this is valid MediaWiki template behavior, I do not think it is very intuitive for template users, especially since the TemplateDoc currently describes the default value simply as "It was written for an older version...". From a user's perspective, it is not obvious that providing an empty string suppresses the default message entirely.

Because the edit summary only said "allow reason string to be omitted", I initially interpreted the change as an almost-equivalent simplification rather than an intentional behavioral change. That is why I reverted it.

I agree that your use case is legitimate, but I think such a behavioral difference should either be documented clearly in TemplateDoc or implemented in a more explicit way.-- Shirayuki (talk) 15:05, 8 May 2026 (UTC) Reply

Do note that the documentation was added by me, precisely because I found it unexpected that the template (1) would assume such a specific reason as the default, despite bearing such a generic name; and (2) would not allow me to override that default value in the cases where it doesn't apply. I understand how it might make sense to mention that the parameter can be overridden by an empty value in the template's documentation, but honestly, as that is the default behavior of MediaWiki for any template parameter, it feels inappropriate to document it specifically for this template, as if it were a custom behavior implemented deliberately in this particular template. Waldyrious (talk) 15:31, 8 May 2026 (UTC) Reply

@Waldyrious: I understand your point regarding MediaWiki's normal handling of empty template parameters.

However, I still think it is somewhat unintuitive that the mere presence or absence of reason= changes the template's semantics. To me, that suggests that the template is effectively combining two different behaviors in a single interface.

Template:Wrapper gives several examples of wrapper templates whose role is to provide default parameter values. From that perspective, I think it would make more sense for the base template to be the variant without the default reason, while the version that outputs the predefined reason could instead be implemented as a separate wrapper template supplying that default value.-- Shirayuki (talk) 23:54, 9 May 2026 (UTC) Reply

Hello, thank you very much for all the work you’ve done on translations and cleanup. I’ve run into a small issue - it seems that Instant Diffs/Header/en is not created automatically, so I can’t transclude this page as a template. I was hoping I could transclude a translatable page the same way as meta:Coolest Tool Award/2026 and meta:Coolest Tool Award. Serhio Magpie (talk) 16:18, 18 May 2026 (UTC) Reply

It seems your last changes helped. Thank you! Serhio Magpie (talk) 21:21, 18 May 2026 (UTC) Reply

@Serhio Magpie: I only marked the page for translation, so I’m not entirely sure why the subpage was not created automatically. If this keeps happening with translatable templates, it may be worth reporting as a bug.-- Shirayuki (talk) 21:24, 18 May 2026 (UTC) Reply

I recently added the createpreviouslyrenamedaccount and createwithcontentmodel permissions to the list of core MediaWiki permissions. However, I don't know what version of MediaWiki they were introduced in. What I do know is that they were introduced in a later version of MediaWiki than the ignore-restricted-groups permission. I've never been very good with tracking down introduction version information for core MediaWiki permissions. Which is why I was hoping you'd be able to help me figure out which version of MediaWiki those permissions were introduced in. ― C.Syde (talk | contribs) 23:44, 26 May 2026 (UTC) Reply

@C.Syde65

• createpreviouslyrenamedaccount: 98b1f82122874b309b2a7f97cd36f5474a694dea, gerrit:1271055, phab:T196386, 1.47
• createwithcontentmodel: 06c6b0d0d0bf7436935fb6cb6dd267a412495d2e, gerrit:1222750, phab:T248294, 1.46

Shirayuki (talk) 21:56, 28 May 2026 (UTC) Reply

Thanks! :) ― C.Syde (talk | contribs) 22:22, 28 May 2026 (UTC) Reply

This change you made doesn't seem to actually reflect reality. In the patchset you linked to, the code that was removed from DefaultSettings.php was moved to Setup.php, so it looks like the value of this variable was not actually changed (only where it gets defined in the code was changed). Do you agree? - dcljr (talk) 01:50, 31 May 2026 (UTC) Reply

@Dcljr: I think the documented default value should reflect what is defined in DefaultSettings.php. Since the variable is now initialized to null there and later assigned a value in Setup.php, my view is that the page should show null as the default and use {{DefaultExplanation}} to indicate that the actual value is determined during setup. Shirayuki (talk) 03:31, 31 May 2026 (UTC) Reply

Hi Shirayuki. What was the problem with this revision? What I am trying to do is transforming the boolean parameter |any-left= into an other parameter named |passing-through= containing a more descriptive list (see {{w:Wrapper}} for an example of the final result). --Grufo (talk) 15:19, 11 June 2026 (UTC) Reply

care because now all tunits are broken without explaination. Please provide at least one /ja translation to prove it is NOK. The /fr version works perfectly on all sample_code pages. I have checked that. Thanks . -- 🚨 Christian 🇫🇷 FR (talk) 13:53, 25 July 2026 (UTC) Reply

It is up to me whether or not to translate it, and at this moment, I have no intention of doing so.

The problem is that your markup does not render correctly when no translation exists. In other words, the markup should degrade gracefully even if a page has not yet been translated. Since it does not, I believe the markup is incorrect. Shirayuki (talk) 23:04, 25 July 2026 (UTC) Reply

Retrieved from "https://www.mediawiki.org/w/index.php?title=User_talk:Shirayuki&oldid=8537767"

Category:

• User pages using deprecated source tags