Jump to content
MediaWiki

User talk:Shirayuki

Add topic
From mediawiki.org
Latest comment: 16 days ago by Waddie96 in topic Revert
Archives

where are the id of the UI messages ?

[edit ]
Latest comment: 8 months ago 2 comments2 people in discussion

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

Wikimedia_Apps/Team/iOS/Personalized_Wikipedia_Year_in_Review/How_your_data_is_used

[edit ]
Latest comment: 7 months ago 3 comments2 people in discussion

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

Help:Notifications -can I edit it?

[edit ]
Latest comment: 6 months ago 2 comments1 person in discussion

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

Why do you leave whole chunks of the page out of translation markup?

[edit ]
Latest comment: 6 months ago 3 comments3 people in discussion

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

Special:Contribs/Allan_Candido_Guedes_-_ACG

[edit ]
Latest comment: 6 months ago 2 comments2 people in discussion

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

Question

[edit ]
Latest comment: 5 months ago 4 comments2 people in discussion

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

Revert

[edit ]
Latest comment: 6 months ago 3 comments2 people in discussion

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

Translation tricks

[edit ]
Latest comment: 5 months ago 7 comments2 people in discussion

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

Pagelinks.sql.gz file

[edit ]
Latest comment: 5 months ago 3 comments2 people in discussion

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

how to call the template {{categoryPages}} without breaking the list ?

[edit ]
Latest comment: 5 months ago 5 comments2 people in discussion

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

Pages that should not be translated

[edit ]
Latest comment: 4 months ago 6 comments2 people in discussion

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

Reversion

[edit ]
Latest comment: 4 months ago 4 comments2 people in discussion

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

Segmenting translation units?

[edit ]
Latest comment: 3 months ago 4 comments3 people in discussion

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
[edit ]
Latest comment: 4 months ago 3 comments2 people in discussion

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

cancelling formatnum: for japanese

[edit ]
Latest comment: 3 months ago 2 comments2 people in discussion

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

$wgRestrictionTypes

[edit ]
Latest comment: 3 months ago 3 comments2 people in discussion

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

Work on Download page

[edit ]
Latest comment: 3 months ago 11 comments3 people in discussion

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 reverting

[edit ]
Latest comment: 3 months ago 1 comment1 person in discussion

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

Spurious span in translated versions of Help:Lint errors/multiple-unclosed-formatting-tags

[edit ]
Latest comment: 2 months ago 1 comment1 person in discussion

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

Extension:MobileFrontend

[edit ]
Latest comment: 2 months ago 2 comments2 people in discussion

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

Your revert in Help:Categories doesn't make sense

[edit ]
Latest comment: 2 months ago 3 comments2 people in discussion

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

Edit summaries

[edit ]
Latest comment: 1 month ago 8 comments2 people in discussion

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

Defective documentation

[edit ]
Latest comment: 1 month ago 5 comments4 people in discussion

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
[edit ]
Latest comment: 1 month ago 3 comments2 people in discussion

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

Not sure why my edits are getting reverted?

[edit ]
Latest comment: 18 days ago 5 comments2 people in discussion

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

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

Revert

[edit ]
Latest comment: 16 days ago 3 comments2 people in discussion

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

AltStyle γ«γ‚ˆγ£γ¦ε€‰ζ›γ•γ‚ŒγŸγƒšγƒΌγ‚Έ (->γ‚ͺγƒͺγ‚ΈγƒŠγƒ«) /