Could you allow translations of this page?
User talk:Shirayuki/Flow
About this board
|
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. |
 |
Archives
| |
|---|---|
| |
Not done
Could you allow translations for this page ?
In this category, the first listed page (in the "Pages in category MediaWiki hooks" section) is "Manual:Hooks".
If you change the language, the displayed name is, for example for Deutch: "de"; for Espanol: "es"; for French, "fr"; instead of "Manuel:Hooks/de_or_es_or_fr".
The problem probably is in the source of this page, could you fix it?
{{HideCategoryPrefix|Manual:Hooks/}} removes "Manual:Hooks/" from category names.
Ok, I understand why but the 'de' or 'fr' seems strange. I suspect there is no solution to restore the prefix only for these links?
There is no simple solution for this. I recommend reporting it as a bug or feature request on Phabricator.
Hi - in this edit you removed tags and added Template:Ll. Thanks for adding that template, which I often forget about. I wondered why the sentence needed the translate tags removing though - it looks like it could be marked for translation again now that this template has been added, or am I missing something?
The portions that should not be translated needed to be enclosed in <tvar>...</tvar> tags. Additionally, there might have been other necessary corrections, so I temporarily excluded the translation unit from the translation and then marked the page for translation.
Done
Could you allow translations for this page ?
Done
Could you allow the translation of this page ?
Done
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.
Done
Greetings,
I notice that you have been reverting changes incorrectly in several recent cases:
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:
- altered formatting
- changed whole sentences
- inserted a stray newline
- 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.
- The text beginning with "MediaWiki interprets certain" is not a translation unit. It is just a localizable text.
- 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.
Done
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.
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.
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, BA{{int|and}}{{int|word-separator}}B→A and B
Done