Shirayuki

This is a MediaWiki.org user page. If you find this page on any site other than MediaWiki.org, you are viewing a mirror site. Be aware that the page may be outdated, and that the user this page belongs to may have no personal affiliation with any site other than MediaWiki.org itself. The original page is located at https://www.mediawiki.org/wiki/User_talk:Shirayuki.

The MediaWiki logo

Previous page history was archived for backup purposes at User talk:Shirayuki/LQT Archive 1 on 2015-07-10.

Hi,

There is a problem on this page (not a big one but it needs to be fixed), I wanted to fix it but I don't have authorization.

The last category is wrong, it shows a page with one item : Category:Global Objects variables when it should show this page Category:Global object variables

Could you fix this ?

It also means that the first category will be empty so the page (and the translated pages) should be removed.

Regards

The category name is determined in Template:SettingSummary based on the value of the section parameter. However, since there is no handling for section=global objects, the page is categorized under the default category name (Global Objects variables).

Ok, but why not to change the section Global Objects into Global object Manual:Configuration settings - MediaWiki ? Especially when you look at the manual : Manual:Global object variables - MediaWiki where this var is not listed  : a bug ?

Ask about these inconsistencies on Project:Support desk.

After viewing the recent edits on Extension:Scribunto/Lua reference manual, I have some questions:

• Currently, separators in some compound sentences are included in <tvar> tags, it seems fine to reducing variable usages and well formatting in languages like English. But in some language, Simplified Chinese for example, is more prefer to use 、 as separator to express such relation, or use full-width comma ，, is there have a proper way to both simplify translation units and formentioned translation issue?
• I noticed that some translation units have formatting characters (e.g. the starting *) included, it's proper to include them in translate units? Since some translators might lose such formatting character to cause formatting issue, although is a rare situation.
• Some translation units have multiple bullets (like T:2559), should them be separated or using multiple lines starting with bullet to list them? I noticed that the surrounding translation units contains only one item, should it be consistent with others?

Many translation units already have translations in multiple languages. Forcing a trivial change, such as removing bullets from translation units, imposes the tedious task of updating existing translations on translators.

Despite of that, I still oppose introduce more leading format characters to new translation units. For existing ones, it might better to change it incidentally when other part is needed to change.

I’m not talking about new translation units. If you insist on removing the formatting characters from existing translation units, please take responsibility for updating the existing translations.

• https://www.mediawiki.org/w/index.php?title=Special:Translations&message=Translations%3AExtension%3AScribunto%2FLua_reference_manual%2F1295

K

Stop insisting on making edits that remove formatting characters and respect the existing translations.

How many more times do I have to explain this for you to understand?

I have nothing to say, I will just quote what you just said "please take responsibility for updating the existing translations", if you not accept what I did, its fine for me to keep the current text, I don't realy care about that.

See https://www.mediawiki.org/w/index.php?title=Special:Translations&message=Translations%3AExtension%3AScribunto%2FLua_reference_manual%2F1295

With the translation units being split, the existing translations have become invalidated, and the changes from that split have not been reflected. Who will be responsible for updating them?

I will responsible to source edits I made, absolutely. In fact, I have listed changed unit numbers for my last change, and I believe I'm ready to find these by numbers change them (if translations is already up to date in its literal meaning) when you approve it, but you didn't.

For unit 1295, if you want to blame someone, I'm sure that you find the wrong person since I checked edit I made in that day. Although, since you mention the unit, I will help splitting it if existing translations are up to date, as I mentioned above. For translations that not up to date, its more safe to wait a translator using that language, since non-formatting changes is responsible to these translators.

Since you are saying that you are willing to remove formatting characters from translation units, even if it requires you to update each translation in other languages one by one, I will trust you and approve your edits.

Simply editing the source page does not invalidate translations; translations are only invalidated once a translation administrator approves the page, marking it for translation. Thus, I showed unit 1295 as an example by marking it experimentally, with no intent beyond demonstrating this process.

Also, translation unit separation (if also considered as trivial changes) like T:2559, I think it doesn't involve issues of imposes tasks to translators, since this type of separation is easy to handle during marking revision to be translated, or simply find the units that not separated yet and split it by its proposer.

When dividing a translation unit into multiple translation units, it is easier to update existing translations by simply splitting at line breaks, regardless of the presence of bullet points. In particular, separating each item with a line break allows for easier confirmation of consistency with the original translation. This approach offers translators the advantage of maintaining consistency while responding quickly. Additionally, it helps minimize the impact of the split and avoids unnecessary confusion.

If you absolutely need to change the comma style within ‎<tvar>...‎</tvar>, the following can be used without creating tedious work for translators:

• A{{int|comma-separator}}B → A, B
• A{{int|and}}{{int|word-separator}}B → A and B

Use Project:Support desk

hi

Documentation

[create]

Documentation

This template provides a standard layout for infoboxes.

Usage

To use this template, include the following in your article:

{{Infobox
| name            = 
| image           = 
| image_size      = 
| caption         = 
| property1       = 
| value1          = 
| property2       = 
| value2          = 
| ... (additional properties) ...
}}

Template Code

style="width: 22em;"
image =	image_size =	caption =
property1 =	value1 =
property2 =	value2 =
... (additional fields as needed) ...

Greetings,

I notice that you have been reverting changes incorrectly in several recent cases:

1. Special:Diff/6770494
2. Special:Diff/6770519
3. Special:Diff/6813778

Although the first 2 reversions are correct, all of these are misleading because they are marked as minor edits. Edits which revert a recent intentional change by another contributor should never be marked as minor. Additionally, "wrong markup" is not an appropriate edit summary for #3, where you:

1. altered formatting
2. changed whole sentences
3. inserted a stray newline
4. prevented translation of localized text.

In a case like this, the discussion page must be used to explain your changes and why you think the markup is wrong. You must also notify the contributor whose changes you revert.

• The translation unit marker <!--T:474--> is duplicated. As it is added automatically, it should not be inserted manually.
• The translation unit beginning with "MediaWiki interprets certain" is too large. To reduce the impact of source text changes on translations, more granular markup is necessary.
• The link text "Help:Extension:ParserFunctions#Escaping pipe characters in tables" should remain translatable. To respect existing translations, the translation unit marker should not be removed.

1. The text beginning with "MediaWiki interprets certain" is not a translation unit. It is just a localizable text.
2. The link text you mention is basically a shortened URL, and as such, cannot be translated at least in this case.

• By enclosing the large paragraph starting with "MediaWiki interprets certain" within translate tags, you turned it into a single translation unit.
• Additionally, by moving the tvar tags, the link text was excluded from translation and became untranslatable. The freedom to translate link text (especially “#Escaping pipe characters in tables”) should not be restricted.

These were both instances of incorrect markup that would inconvenience translators, so I have reverted them.

First, the purpose of rollback is to deal with bad edits.

I made an edit, you did not understand it, but nonetheless you reverted it with 'undo button' with a false claim of wrong markup, which it was not. I challenged you and restored it. Instead of you to explain your reasoning, you went ahead and just 'rollbacked' it with absolutely no reason just because you can. You cannot even explain what you're doing.

I will revert it. If you disagree with the edit, explain yourself and stop misusing rollback thinking just everything has to suit you.

Adding ‎<br> to a sentence that already has translations invalidates the existing translations and creates extra work for translators in each language. If you only want to reduce the width, we should use TemplateStyles .

@Shirayuki was right to revert your change. Your markup was indeed incorrect, and the reason why you added it was also wrong. His edit summary could have been much clearer, but it was not false. Your intentions may have been good, but I consider that your edit was "bad".

I have explained sufficiently. ‎</br> is not a valid HTML tag.

Shirayuki,

I'm asking you one last time.

Please stop splitting paragraphs in translatable pages into many units. Especially if they are already translated, and even if they are not.

The page Global templates/Proposed specification was completely translated to several languages. You messed it up with your "translation tweaks".

You didn't bother fixing the translations. You didn't even translate the page into your language. You are just doing it over and over again, and you call it "tweaks".

It's not a "tweak". A tweak is supposed to improve something. This is not an improvement. This is making a mess.

You contribute a lot to translatable pages, which is good, but this incessant splitting is not desirable. I'll propose to revoke your translation administrator rights if you keep doing this.

Sorry, but I feel the need to defend Shirayuki's actions. As a translator, developer and editor of translation wiki pages, I am fully aware of why he does this. Technical texts, if they are longer, are much more difficult to translate in large blocks.

Next.

Do you know what revision looks like in the database? In that case, you know that is much advantageous for it, if the content of the page consists of a larger number of smaller TUs than vice versa.

Why?

• A paragraph composed from several TU is better for update. Only one sentence usually is add or changed, not the whole paragraph.
• Shortly text is better to understand. Easy TU can be fastly translated and the code expert translate only complicated TU.
• Databases can work more efficiently with repetitives datas and shortly TUs on MW are often repeated.
• When you need to change the link in TU on the origin page, you don't need to revoke the entire paragraph (and do big change). And someone may be actualized it and not must be understand the language – just look at the differences before.

More reasons I can give for it, but reaction in talk page isn't not right place for it, because it limited chars.

I am one of the developers of the Translate extension, so yes, I know how it looks like in the database, and I have no reason to think that what you say is technically correct.

In that case, you should explain how I'm wrong. I also manage the server my wiki runs on, so I'm looking at this as root as well.

As far as I know, create template for each language subversion after tagging for translation, and the translations messages are incorporate into it then interpreted. Each edition is a unique revision. Not all are loaded, but only the currently valid ones. If I do change in small TU is revision minimal. It must be effect to database work.

I have written an essay on this topic, but it is not finished yet. The weekend starts and I'm going away – User:Want/Splitting translatable paragraphs or not?

I generally avoid translating long translation units composed of multiple sentences. This is because there is a high risk that they will be modified later, rendering the translations invalid.

Additionally, there are translation administrators who invalidate the entire paragraph’s translation for trivial edits, such as changing quotation marks.

From major changes to trivial ones, the task of investigating each modification and reflecting it in the translation is a painstaking task.

This quotation marks example is not so good for two reasons:

1. I'm also updating the translations myself, so no one actually has to worry about it. (I haven't finished it yet for all languages because there's a lot of other mess to clean up.)
2. Even if I didn't, addressing those updates is trivial: just look at the list of outdated messages and checking the diffs.

Updating translations after splitting a paragraph is much harder. You do this splitting, but you don't bother to update the translations. Please stop.

Sorry, but you obviously have no idea what the effect of marking a page for translation on a multilingual wiki is. I intend to make it clear in that essay, but I'll be off the internet in a little while.

I fully agree with both Shirayuki and Want.

I am a translator. It is much easier for me to work with a shorter text than with a long one with several sentences. I'd rather register incorrect text or finesse of the language. Also, a shorter text is more advantageous when using text hints in the Translator. Long texts are actually not displayed at all and the advantage of the hints is greatly suppressed. I don't understand at all why a text made up of several long sentences should be divided three times by semicolons. Another problem is the marking of untranslatable texts ('shape'). I get lost in it in long paragraphs, just like marking with different texts used to be. It just doesn't suit me and I like to use shorter sentences. I propose a very extensive discussion on this topic with a large number of people involved in translations and preparation for translations. It is a really complex topic and solutions cannot be made with regard to already translated texts. That's the development tax.

I agree that translatable units should be short. The question is how short should they be and how to achieve it technically.

The right way to do it is to write shorter paragraphs from the start. The responsibility for this should be on the original page's author. A ten-sentence paragraph is a bad idea in any case, but a five-sentence paragraph is OK.

Taking a paragraph that is already short and splitting it into even smaller parts is a bad idea. I haven't seen anyone except Shirayuki doing this. It's an exaggeration that does more harm than good.

I started a discussion about this a couple of weeks ago on this page: m:Talk:Translatability

Thanks for the reply. I had quite a few problems with Shirayuki's attitude at the beginning, but so far, apart from a few individuals, I have not found such an enthusiastic and especially fast collaborator. I understand him. It probably wouldn't be out of place for you to talk about this problem in a big plenum. It's really up for a great discussion without jumping to conclusions!

Several edits prior to my revision Special:Diff/6624825/6626346 added variables to translation units consisting of multiple sentences (as well as splitting them into multiple translation units).

I believe it is better to split them before adding variables and making them complex.

BenyElbis: Please refrain from adding variables to translation units consisting of multiple sentences.

I don't understand, please give an example. Thank you

Thank you for reading the discussion. See the reply immediately above (at this point in time).

This is related to your addition of variables to complex translation units, for example in Special:Diff/6624825/6626346, and my subsequent partial reversion and splitting of those translation units in Special:Diff/6627645.

I had thought it would be better to split them first before adding variables, but if you hadn't added the variables, I wouldn't have felt the need to actively split them.

I understand. The easiest solution is to leave the TU as they are and not divide them. The fact is that some TUs are so absurdly long or rather complex that they deserve to be divided. I support you in that. And thanks for your cooperation

Yes, it's usually good to split a very long paragraph. But the right way to do it is to split the paragraph into two or three paragraphs in the source and not to add tags in the middle of the paragraph.

Don't be mad, but this sentence doesn't make sense to me. My proposal: If during the translation I encounter the need to split a paragraph, I will let you know and ask for an assessment. It is a way to understand each other. Thank you

No, there is nothing wrong about adding variables to translation units consisting of multiple sentences.

There is something wrong about adding <translate> tags in the middle of paragraphs, especially if they were already translated to multiple languages, and forcing people to re-translate them for no reason at all.

 Done

Hi Shirayuki, Thank You for your edit. Can I ask you, if it is generally possible, instead of 1, 2, 3, 4 to use something like 5, 10, 15, 20. Than there is space for later passages to insert. Maybe in this case it doesn't matter, but in more complex texts it makes it a bit difficult from the perspective of an editor to insert later a passage, E.G. in this edit I was happy, that there was T:39 still free for use, but if not..T:170?. Another idea could be, starting for each chapter with a new 10. eg. 1, 2, 3, - 10, 11, 12, - 20, 21, 22,.. or with more space inbetween: 2, 4, 6, - 10, 12, 14, 16, - 20, 22, 24, 26, ... That will keep enouph flexibility for future changings. Is this a usefull idea? Regards

Do NOT manually add translation unit markers (T:NN). They are automatically added by the system, not by translation administrators.

For example, even if T:39 appears to be free, it may have been previously used for an entirely different English sentence, or translations may exist for it, causing confusion.

See .

Someone has assigned the translation unit T:39 for "Description" to the unrelated "Maps is a single data structure..." text!

As a result, incorrect translations for "Description" exist in languages other than English, causing inconvenience to readers and translators in other languages!!

hmm, ok. So using T:39 was wrong, I had to use T:172 ?

By the way: Did we accidentally edit the same time or do you not like the Capital Letters? They were intended as a navigational aid. Regards

I just didn't want the braces to be included in the link, similar to {{Mbox templates}}.

Feel free to add the capital letters if needed.

ok, done. funny by the way, "layout!" - "style!" :-D Best Regards By the way, 2009/10 I was living for one year in Osaka, was nice! My beginning was the total solar eclipse in 2009 Amami Oshima. Where are you from or living?

Warning:

NEVER add translation unit markers (T:NN) manually!

See .

Instead of the correct English text "Maps is a single data structure...", "説明" (the Japanese translation of "Description") has been mistakenly inserted.

hmm, ok. Sry for the chaos!!

 Done

Hello Shirayuki please can you mark this header for translation Wikimedia Tech Safari Program/Header. Also the final gif banner uploaded is currently on reflecting on the overview page and the header page but the other sub pages currently have the old gif banner. If that can be fixed for me i will be greatful.

I was wondering about the margin of this image, but it turns out to be an animated GIF. In my environment, the animation doesn't play, and only the outline of the African continent is displayed.

From my end it works perfectly, tried viewing it on commons and it also works perfectly. The African image is static and the other content is animated.

On the page, the image at the following URL is embedded, and it is not an animated GIF:

https://upload.wikimedia.org/wikipedia/commons/thumb/4/48/Wikimedia_Tech_Safari_Program_GIF.gif/920px-Wikimedia_Tech_Safari_Program_GIF.gif

Oh okay i can now see it via this URL. I don't know how this can be fixed.

See Manual:$wgMaxAnimatedGifArea (Default value: 12,500,000).

920[px] x 424[px] x 127[frames]=49,540,160 is larger than the default value.

oh okay i do understand it now.

Also to be marked: Extension:SkinCustomiser

Hello @Shirayuki please can the pages be marked for translation again

Right now the only changes i will do is for the schedule, discussion, organizers and team. So the overview can be marked for the overview and participate can be marked for translation.

Hello @Shirayuki Please can you mark this page for translation Wikimedia Tech Safari Program/Terms and Conditions apply

@Shirayuki Please can you mark the overview page for translation again, this is the final schedule. Wikimedia Tech Safari Program

Pages that need to be marked for translation are listed on Special:PageTranslation, and in most cases, they are marked by one of the translation administrators within 24 hours.

So, there's no need to notify each time.

Oh okay well noted with lots of thanks

 Done

Hello,

Per the consensus from conference organizers, we need to rename the "MediaWiki Users and Developers Conference 2024" page into "MediaWiki Users and Developers Conference Spring 2024" because there will probably be a MediaWiki Users and Developers Conference Fall 2024. Your help would be much appreciated.

CC: @CCicalese (WMF) in case a +1 is needed.

 Done

Thanks!

 Done

Hello, thanks for marking the article for translation. Why did you remove ‎<translate>...‎</translate> tags from the first sentences though?

I removed the respective sentences from translation because translation variables were missing.

I see. I added them.