PR 145 from translatewiki has been merged into main.

@Nikerabbit, given that we review complex PRs in ~7 days, and we've mandatory code-owner-review to avoid any security vulnerabilities, we'd be better to move with pull requests than direct push to main.

Hi @NishthaJain7, is there any progress on this?

I tried this for my own userpage on Meta, and the tool fails to parse through the pipes there. Perhaps explore different types of infoboxes used, such as User info, among others.

In T393170#12058133, @Super_nabla wrote:

The idea is to create a user script that modifies the standard Meta-Wiki (www.metawiki.org) or other project interface, adding a button like "add translation tag" that calls the gadget and modifies the page content to add translation tags.

I have found these guidelines:

https://www.mediawiki.org/wiki/Gadget_kitchen
https://www.mediawiki.org/wiki/Extension:Gadgets
https://www.mediawiki.org/wiki/Manual:Interface/JavaScript

Actually, the task talks about a full-fledged "gadget", not just a "user script", but I think the two of them are strongly correlated, and a user script is a good starting point.

Feel free to work on this Nishtha.

All localisable links (leading to Wikipedia pages across editions) need to be skipped in the tvar mechanism. Example, [[en:page title|page display title]], should be rendered as is.

In T393255#10802048, @theprotonade wrote:

I was reading some documentation and it seems that chunks of <code></code> should not be wrapped with tvars. Am I missing something?

https://meta.wikimedia.org/wiki/Meta:Internationalization_guidelines#Translation_variables

I'd use the following, based on how it's on Urdu Wikipedia:

All seems well at my end.

The revised wordmark is here:

Thanks for the thoughts @Pppery, but you seem to have linked the wrong wordmark file. I was trying to locate the urwikiquote wordmark file, but I haven't been able to yet. The link for the current version I can find is: https://ur.wikiquote.org/static/images/mobile/copyright/wikiquote-wordmark-ur.svg

Outbound emails from wm-deoband sent yesterday & days earlier, have been reported to be received today. Tested with 2025110410006642, received within a minute or so.

Confirmation receipts are also not received by customers, and several of our community members reported that they didn't receive any response emails from the wm-deoband queue. Checked with CC'ing myself, but no luck.

@Samwilson, yep, this should suffice. Since talk-pages aren't really created, it won't show any.

Seems issues around T173141, and composer behaviour make the work tedious. With that, the challenges proceeds to T402742.

Let me see around. Seems all to do with unneeded and conflicting updates as like T173141.

In T402730#11112915, @Tgr wrote:

Sounds like an autoloading issue. Maybe you didn't run composer?

Thanks for the note @Aklapper. This was probably my first time filling a bug like this. I will take care of this in future, and thanks again for adding the backtrace here.

@Astinson, Content Translators? That would mean giving an important deal in the hand of disruptive vandals - we have been talking here about Translation administrators, they are way different that "content translators". What's missed?

Though it's been a long, the logo was recently adjusted according to the relevant en variant, and seems to work one. The tests seem fine on my side.

I agree with both @DerHexer and @Johannnes89 but I must reiterate from my previous messages. Although translation admins should be allowed to mark such translations as published, they should not be necessitated to do it as they are unlikely the people who would be deciding on how good a translation is but if they know the languages, they must be trusted to push the publish button.

In T372243#10424651, @Pols12 wrote:

Such a nice revival of T348497: Special:PagePreparation improvements [FY2023/24-Q2]. 🙂 I wrote there I have been believing an heuristics can add a proper markup in most cases:

• For lists, the tool should wrap each item in its own translate tag pair.
• For headings, the tool should ensure there is an empty line just before and just after it.
• For tables, the tool should wrap each cell in its own translate tag pair. If the cell contains a new line, it should ensure there are an empty new line just after the first line of the cell (so the next paragraph of the cell is isolated in its own unit).

I think there are two exceptions:

• Images: some textual image may want to be fully replaced, whereas we only want to translate the captions for pictures.
• Some Template parameters are string constants (no localization expected), whereas other one are literal content which should be translated. We could use templateData (string vs content parameter types), but those are rarely well provided.

For images and template calls, the early version of the tool should probably ignore them and make them fully translatable as any text. A more advanced version of the tool would include a prompt which would allow the user to choose between options:

• Do you want to allow translators to replace this image with another one (i.e. a localized version of the image)?
• Do you want to allow translators to change the value of this template parameter (i.e. translating the text)?

While deleting one of the the Topic pages on Commons, I came across this error:
[b81ebde5-b932-404b-8f19-0dd5929528a0] 2024-12-24 11:03:36: Fatal exception of type "MediaWiki\Page\PageAssertionException"

We have had some good improvements today, during the first day of Indic MediaWiki Hackathon in Bhubhaneswar. For the sake of transparency, I have asked for ideas/suggestions on TA noticeboard's on Wikimedia Commons, Meta-Wiki and Wikidata.

A test-page to help improve created at:
https://test.wikipedia.org/wiki/User:Aafi/Test_for_Bhubaneswar_Hackathon

I have been looking around this since my conversation with Gopavasanth at Wikimedia Technology Summit in Hyderabad. It is a good start. Has there been any improvement since then?

@Hamishcn, a resized version of the logo has been uploaded. Could you please take a look if it works?

Closing as resolved per the latest usage updates by Usage Bot.

In T378262#10264757, @Aklapper wrote:

Hi, this does not sound like a bug in the MediaWiki code for Categories, thus removing that project tag. This sounds like a support request (how to change settings, questions how to do something, etc.). As Wikimedia Phabricator is for bug reports, enhancement requests, and planning work, please check https://www.mediawiki.org/wiki/Communication. Probably https://meta.wikimedia.org/wiki/Tech is the best place where to bring this up. Thanks for your understanding!

I am re-opening this task given that it doesn't appear to work. Having updated to the latest master branch from Git/ran update.php commands as well - it doesn't seem that the files are being marked as used. For example: this and this. I have also tried removing the residuals of the previously installed extension and then purging - it doesn't seem working. Could you please take a look and see what is missing? Both of the files are used here.

@Samwilson , do we have anything new in this?

@Samwilson , I don't think a two-column display would do any good (3 might be an idea to try). I feel we should try with the same format as it comes on the desktop view.

In T359764#9618373, @Koavf wrote:

If you use your Wikimedia credentials via OAuth, just see here: https://meta.wikimedia.org/wiki/Global_rename_policy

Possibly related: https://phabricator.wikimedia.org/T49918

Since WMAU skin does not look like regular Wikimedia skins, we can use any extension that allows enabling comments at the bottom of any given article. However, by default, I am not sure if pages such as About, and others, require any kind of public comments through a talk page, or even generic comments at the bottom.

Please find the community consensus here.

I have initiated a local Village pump discussion and will get back here once there appears to be a community consensus.

The note by Base makes sense. The number of active admins on ur-wiki has fallen below 7 (afaics). Please consider this request withdrawn. We might revisit this at a later time.

The removal of administrator flag would remain subject to community discussions, and a crat' should be able to do that. ur-wiki is not that much small wiki. I could see successful local discussions for CU's such as this, but I'm not sure why Urdu Wikipedia doesn't have any CU yet.

This appears to be fixed for me. See this and this for reference. The "Marked.... for translation" does not remain unpatrolled anymore.

Although I agree with @Pols12 that translation admins are not supposed to be translation reviewers but I feel it to be alright if they have ability to mark translations as "published", for example, in the languages that they know. I know Urdu and if I believe a translation is perfect and should me marked as published, I should be allowed to do it, instead of me waiting for someone else to do it, stewards? I am not sure if we have one knowing Urdu language.

In T345890#9152022, @Soda wrote:

@TheAafi Also reported this error previously

@Ladsgroup, could you please make this mailing list as a private one? Over the last few months, we have had some discussions internally and we felt that keeping the list private would serve us in a better way.

@matmarex, I checked out with what you said in b and I see that I've similar options opted in both 1 and 2. When I checked the same with clicking the "keyboard like button" in scenario 1, it displayed "Use personal keyboard is active". The same is with discussion tools. I am sorry for not understanding Does the "ENG / IN" layout indicator change to reflect the Urdu input when that happens? In scenario one. I am able to write in Urdu without having to change from ENG/IN to Urdu but this doesn't work on the other areas that I have indicated. I'd definitely ask some other friends to check with this and see if the face this problem as well or is it just me.

If you can take a look at these images, you might be able to notice what I am asking for. We do not face such issues while writing articles or posting on talk pages by going through the "edit" option. Without having to change the keyboard layout from English to Urdu, we by default are able to write as such with a phonetic keyboard as I indicated in scenario 1 above, and also shared an image. I don't feel this is an issue with translations.

@matmarex, what I mean is that if I directly post a message using "edit" button at the top of any page, I am able to write in Urdu without having to changing my system's keyboard layout etc. from English to Urdu. However, this doesn't happen with posting a message by option "New section" button. In that if I want to write in Urdu language, I have to change my system's keyboard layout to Urdu unlike the first scenario. That's to say, if Urdu language can be typed without having to change the keyboard stuff (scenario 1) why is there a problem in the scenario two?

In T330594#8646873, @Esanders wrote:

You can provide translations here:

https://translatewiki.net/w/i.php?title=Special:Translate&group=ext-discussiontools&language=ur&filter=%21translated&action=translate

In T322996#8391475, @Ladsgroup wrote:

do you want it public or private?

I just faced this again on Wikidata. This shows Invalid value for parameter mcgroup.

Hmm, I did encounter this bug much earlier than you but I wasn't in hurry to bring this to Phab and instead asked @Pols12 that what went wrong. Waiting for a while sorted out all the problems even without purging the cache. That's to say, this was perhaps a temporary bug.

Given the criteria set forth by AffCom, I'm currently taking this request down and will come back on this once we feel we are ready for this. Thanks!

I got a follow up from MKaur and she said that, AffCom is actively passing an internal resolution on process related to such requests. You will hear from them soon.

@Ladsgroup You're right but I'm not able to understand why AffCom is moving away from the discussion. The email I had sent them received a weird response in a language that I don't know. Let me reproduce it here for you:
Affiliations Committee Google Группы Логотип Google Групп
Запись, которую вы недавно отправили в группу Affiliations Committee, отклонена ее владельцем или менеджером.
Возможные причины отклонения:
Ваша запись лучше подходит для другой группы или обсуждения.
Ваша запись нарушает правила группы.
Запись недостаточно информативна.
Дополнительную информацию об инструментах модерации можно найти в Справочном центре Google Групп.
В Google Группах можно создавать и посещать онлайн-форумы, а также группы, общение в которых происходит по электронной почте. Делитесь с другими участниками документами, изображениями, календарями, приглашениями и прочими материалами. Подробнее…/

I received a follow up from AffCom's Twitter handle. The response is from Camelia who says, "Hello, AffCom never managed the sites or had any decision making on this. And as the discussion went on that thread, only in the past chapters had this." But, I'm still waiting for MKaur's response because she just said two days back that she commits to sharing the update in the coming week. Lets see what happens. My question on this much is that, when AffCom had no decision making in this, why are we forcing them to have any?

MKaur has said that she will follow up with AffCom on Monday and commits to sharing the update in the coming week.

In T313151#8082200, @Ameisenigel wrote:

Stalled per T271539#6733959

In T271539#7171803, @Aklapper wrote:

Hmm, any news from AffCom here?

@Dereckson, following our conversation on Meta-Wiki, here is the request. Please let me know if you need any further information. Once the wiki is created, please make me the initial bureaucrat. Thanks!