User talk:Shirayuki

Hi Shirayuki. I found out that you added 17.7.2019 a change Special:Diff/3319554/3319557 to the Template:Languages, which I don't understand how it works.

I don't know nothing about attributes for the tag 'languages', but code use inline attribut 'exists'. Why? Function #ifeq four arguments, accepted, but result is still false (because tag 'languages' element with attribut not exists). Could you please clarify this for me? Thank you. -- Want (talk) 15:20, 15 July 2024 (UTC)

translatewiki:Special:Diff/8860519.

If the page is not marked for translation, I believe that <languages exists /> outputs nothing.

Your believe is a wrong. I prepared as example three pages to you on my wiki:

• test-translate is translated page
• test-dontmarkup is page prepared to markup
• test-insert include page test-translate by transclusion

Note that the #ifeq function returns FALSE forever if used tag languages, regardless of whether the page is being translated or not.

Only test for the existence of a language version subpage of the marked page works. It returns TRUE for 'test-translate' because the test-translate/cs page exists - the page has been marked for translation, but for 'test-insert' return FALSE code because subpage test-insert/cs not exist. It's exactly the same for the translated template. -- Want (talk) 05:07, 16 July 2024 (UTC)

Hi,

Sometimes you do it by splitting the paragraph several lines like here, and sometimes you add <translate> tags in the middle of the paragraph like here.

Is there a suggestion documented anywhere to split paragraphs into smaller translation units? Or is it just something that you do yourself?

I thought I wrote it down somewhere, but I couldn't find it.

• By making translation units as small and simple as possible, translations become easier and are less likely to be left untranslated.
• Additionally, fewer types of variables ($1, $2, etc.) are needed.
• Moreover, simplifying variable names increases the likelihood of hitting the translation memory, thereby making the translation process more efficient.

Topic:Xnd7su3ew0fba4py#flow-post-xpd5yauhp5kj864w

• MediaWiki.org pages are frequently updated, and shorter translation units are less susceptible to changes. Longer translation units can lead to the invalidation of entire translations.

> By making translation units as small and simple as possible, translations become easier and are less likely to be left untranslated.

Have you measured it? Are pages where you did this split actually more likely to have more translations?

> Moreover, simplifying variable names increases the likelihood of hitting the translation memory, thereby making the translation process more efficient.

It's not significant. Sentences within paragraphs of body text are not likely to be in translation memory anyway.

Making translation units shorter is generally a good idea, but the way in which you do it is not great. It adds a lot of markup, which makes the page hard to edit.

It's better to make the paragraphs shorter and rely on the Translate extension's capability to mark each paragraph for translation.

• MediaWiki.org pages are frequently updated, and shorter translation units are less susceptible to changes. Longer translation units can lead to the invalidation of entire translations.

That's OK, but is it worth adding so much markup to achieve that? Just making sure that paragraphs are no longer than four sentences achieves a much better balance of translation ease and markup heaviness than splitting everything to single sentences. Besides, keeping paragraphs shorter is a good thing in general for readability in the source language.

Yes. Markup is only signal to parser. Every text unit is numbered. Experience editors have not problem with orientation in wikicode of this type. You must first understand as functioned this concept of translations. Text unit is really a wiki page from Translation namespace. Every change has own id. If a change only one char, TU waiting to new revision of the volunteer translator. And more senteces in one TU complicate it.

Experience editors have not problem with orientation in wikicode of this type - actually, they do. I do, and lots of other people do. It's way too much code, and it makes editing the source page harder.

And more senteces in one TU complicate it. - paragraphs of five senteces is not too much. More than that is, and when I prepare pages for translation, I try to reduce paragraphs to five sentences or fewer. But splitting a paragraph to single sentences doesn't help much.

I am sorry, but page Extension:DynamicPageList_(disambiguation) isn't simple page, because combine very complexity wikicode:

• outline text where paragraph can't be split as common, because new line don't as continuation of the outline paragraph, but new paragraph for the same outline level, without outline char and tab (must be used colon for it)
• parametrized multilanguage links created by Template:ll
• and syntax example code, which must be protected before parser interpretation

I have multilanguage wiki and use it very much – see my Main Page, which is generated by it. For it I know specifics of the wiki code markup of it for using by multilanguage page very good. I don't use any lua modules for it.

I have question. You use for editation pages visual editor, or do edit plain wikicode? You call as editor for simple code, but translator wants simple TU. Text which uses more sentences want a lot more knowledge of the translator than you think. The consequence is that translators are few and far between, because translation a large chunks of text with a minor changes, not easy. They do not have time to update such pages and often remain untranslated a long time for it.

I am sorry, but page Extension:DynamicPageList_(disambiguation) isn't simple page, because combine very complexity wikicode - I'd argue that it's not so important to translate this page in the first place. I only used as an example because it was easy to find it. People who install extensions are more likely to know English. Some of them don't know English, so it's still useful to translate them, but it's less important than the Visual Editor user guide, for example.

For editing pages, I use the visual editor when I can and I wikitext when visual editor wouldn't work well. It's obvious that translators want simple translation units; what I say is that a translation unit with five sentences is usually simple enough.

No, you are wrong. Read m:Translatability page, please. But use translate markup as you see fit. For me, translating and preparing pages for translation on MediaWiki.org is a peripheral matter, for which no one pays me and which I do when I have the mood and the time, that be not create duplicity manuals on my wikis.

it's still useful to translate them, but it's less important than the Visual Editor user guide, for example. – Visual Editor user guide is important only for wiki where is use. My wiki's not use it. By my experience, users what use Visual Editor (default on Wikimedia wikis'), don't know a basic wiki markup and has problem with template using. My wikis have not a lot users, and I have not time to revision code of another user. I disable VE and users now better understanding code.

Don't you think enabling a syntax highlighter would improve understanding of wiki markup? It's indispensable for me when editing complex sources with translation tags. I don't like the visual editor and prefer to edit the source directly.

@Shirayuki, if you're asking me, then no, syntax highlighter doesn't really help. Splitting a single paragraph into many translation units makes it look too much like code. It shouldn't be like that. It's not code, it's text.

About your revert of my edit.

If you have specific comments/claims to my edit, please explain them. If not, please return the template to my version. Now on the main page the phrase "Other languages:" is always displayed in English. After my edit, this is synchronized with the displayed language version (if translations is provided), or displayed in the user interface language.

When I checked the source, the Template:Languages did not have a parameter '2'. That is why I reverted your changes and suggested using sandbox pages for prototypes of such high-impact pages.

However, I agree with the idea of synchronizing the phrase with the user interface language.

This change is on the one hand small and on the other hand difficult to verify outside of the current usage chain. That's why I did it on the Main Page directly, and also in the real templates.

Using {{ll|Project:Language policy|{{int:tpt-languages-legend/{{SUBPAGENAME}}}}}} in Template:Languages also justified - IMHO, there is necessary to first use a translation that matches the current language version of the subpage being called (regardless of the interface language). And then, if there is no translation, in the user interface language.

Check if this change on Template:Languages about 4 days ago resolved the issue.

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.

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!

Is there a handout to understand this stuff?

About Special:Diff/6296767:

1. Avoid fragmented or "patchwork" messages.
2. Separate heading and body text with a empty line to make them individual translation units.
3. Do not add unwanted html comments like <!---->.

OK, in that diff I can not see any fragmented or "patchwork" messages and also is not related to the ‎<translate> stuff.

One thing I don't understand is when a ‎<translate> tag is set and when it is skipped.

1. When the original text is cut off mid-sentence, as in The extension was tested with MediaWiki, it is unclear that version numbers follow. This leads to difficulties in accurately translating it into many languages.
2. Punctuation marks should also be translatable.

The idea is not to touch the existing translations if only the version numbers are updated.

MediaWiki:Sidebar does not work for translations. :-(

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

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

Recently, you undid my revision to {{main}} to make it use {{ll}} instead to automatically localize link names, with the summary "It does not localize". I am confused. As you can see on {{localized link/ja}}, the pagenames are automatically changed into their Japanese translations. The changes also hadn't been propagated to the translated versions yet.

Passing a second parameter to {{ll}} overrides the automatic localization of link names, so they are not automatically localized. Using that template compromises readability.

But if the corresponding parameters are empty, as {{main}} is often used, the second parameter would not be passed. By readability, if you mean that of the template code, that can easily be fixed by enabling syntax highlighting.

I'll go ahead with restoring the edit in a day.

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

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!!