Wikitech-l April 2016

wikitech-l@lists.wikimedia.org

100 participants
90 discussions

Missing Section Headings
by Marc Riddell 13 Sep '24

13 Sep '24

Hello, I have been a WP editor since 2006. I hope you can help me. For some reason I no longer have Section Heading titles showing in the Articles. This is true of all Headings including the one that carries the Article subject's name. When there is a Table of Contents, it appears fine and, when I click on a particular Section, it goes to that Section, but all that is there is a straight line separating the Sections. There is also no button to edit a Section. If I edit the page and remove the "== ==" markers from the Section Titles, the Title then shows up, but not as a Section Heading. Also, I don't have any Date separators on my Want List. This started 2 days ago. Any thoughts? Thanks, Marc Riddell [[User:Michael David]]

10 11

How to make commits from mirrored Wikimedia repos show up on your GitHub profile
by Bartosz Dziewoński 27 Jun '24

27 Jun '24

I know it has been annoying a couple of people other than me, so now that I've learned how to make it work I'll share the knowledge here. tl;dr: Star the repositories. No, seriously. (And yes, you need to star each extension repo separately.) (Is there a place on mw.org to put this tidbit on?) ------- Forwarded message ------- From: "Brian Levine" <support(a)github.com> (GitHub Staff) To: matma.rex(a)gmail.com Cc: Subject: Re: Commits in mirrored repositories not showing up on my profile Date: Tue, 09 Jul 2013 06:47:19 +0200 Hi Bartosz In order to link your commits to your GitHub account, you need to have some association with the repository other than authoring the commit. Usually, having push access gives you that connection. In this case, you don't have push permission, so we don't link you to the commit. The easy solution here is for you to star the repository. If you star it - along with the other repositories that are giving you this problem - we'll see that you're connected to the repository and you'll get contribution credit for those commits. Cheers Brian -- Matma Rex

3 3

bluejeans
by Jeremy Baron 22 Feb '23

22 Feb '23

Hi, On Tue, Mar 1, 2016 at 3:36 PM, David Strine <dstrine(a)wikimedia.org> wrote: > We will be holding this brownbag in 25 minutes. The Bluejeans link has > changed: > > https://bluejeans.com/396234560 I'm not familiar with bluejeans and maybe have missed a transition because I wasn't paying enough attention. is this some kind of experiment? have all meetings transitioned to this service? anyway, my immediate question at the moment is how do you join without sharing your microphone and camera? am I correct thinking that this is an entirely proprietary stack that's neither gratis nor libre and has no on-premise (not cloud) hosting option? are we paying for this? -Jeremy

9 16

productivity of mediawiki developers
by rupert THURNER 29 May '17

29 May '17

hi, is there a statistics about mediawiki developer productivity? i just fell over a couple of pages and i am quite impressed i must say: * gabriel, https://github.com/gwicke, 2'300 commits last year * jeroen, https://github.com/JeroenDeDauw, 3'700 commits a year * ori, https://github.com/atdt, 1'700 * james, https://github.com/jdforrester, 1'200 * yuri, https://github.com/nyurik, 900 * matt: https://github.com/mattflaschen, 400 commits rupert

11 14

Deploying the UrlShortener extension to Wikimedia wikis
by Legoktm 12 Nov '16

12 Nov '16

Hi, YuviPanda, prtksxna, and myself (with help from Tim and Aaron) have been working the UrlShortener extension, which is designed to implement the URL shortener RfC[1] (specifically Tim's implementation suggestion). I've filed T108557[2] to deploy the extension to Wikimedia wikis. We'd like to use the "w.wiki" short domain, which the WMF is already in control of. A test wiki has been set up mimicking what Wikimedia's configuration would be like: http://urlshortener.wmflabs.org/, and has an accompanying "short" domain at us.wmflabs.org (e.g. http://us.wmflabs.org/3). Please play with it and report any bugs you might find :) [1] https://www.mediawiki.org/wiki/Requests_for_comment/URL_shortener [2] https://phabricator.wikimedia.org/T108557 Thanks, -- Legoktm

3 5

Recent authentication session instability (was Re: Update from the Wikimedia Performance Team)
by Bryan Davis 19 Jun '16

19 Jun '16

On Thu, Feb 4, 2016 at 8:20 AM, MZMcBride <z(a)mzmcbride.com> wrote: > Federico Leva (Nemo) wrote: >>Login pretty much never does what I expect nowadays, but I'm not sure my >>expectations are correct so I can't identify actual bugs. > > There are various open tasks in Phabricator about user sessions currently, > such as <https://phabricator.wikimedia.org/T124440>. Being unexpectedly > logged out lately has been a bit annoying, though I don't know if it's > related to the Performance team or some other team. The origin of the unexpected logouts falls on the AuthManager project and specifically the SessionManager component that rolled out in 1.27.0-wmf.11 [0]. We had various issues related to the session handling changes including a bug that was overloading the storage capacity of the Redis servers that store session data [1] and two other issues which required rolling the wikis back to 1.27.0-wmf.10 [2][3]. Both rollbacks were accompanied by a run of the "resetGlobalUserTokens.php" maintenance script which updates each user's CentralAuth records in such a way that their authentication session will be considered invalid the next time it is used on a wiki. This was done from an abundance of caution point of view concerning possible issues with sessions that had been issued by the SessionManager software. The reset script is not fast [4], so session invalidation has slowly worked its way across the CentralAuth user table. Part of the enhancements that are being applied in order to bring SessionManager back to production with 1.27.0-wmf.13 is a new config setting that can be used to give us a nearly instant switch to throw to invalidate all active sessions. This setting is actually included in 1.27.0-wmf.12, but the configuration on the Wikimedia cluster has not been changed to make use of it yet. Invalidating all user sessions is not something we plan to do for fun certainly, but there have been in the past (and likely will be in the future) software and configuration issues that necessitate the use of that heavy hammer approach. [0]: https://phabricator.wikimedia.org/T123451 [1]: https://phabricator.wikimedia.org/T125267 [2]: https://wikitech.wikimedia.org/wiki/Incident_documentation/20160123-Session… [3]: https://tools.wmflabs.org/sal/log/AVKZtfQXW8txF7J0uNE2 [4]: https://phabricator.wikimedia.org/T124861 Bryan -- Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org> [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855

7 13

Reducing the environmental impact of the Wikimedia movement
by Lukas Mezger 24 May '16

24 May '16

Dear readers of the Wikitech mailing list, I am a member of the Wikipedia community and I have started a project to reduce the environmental impact of the Wikimedia movement <https://meta.wikimedia.org/wiki/Environmental_impact>. The main idea is to use renewable energy for running the Wikimedia servers and the main reason for this is that by doing so, Wikipedia can set a great example for environmental responsibility in the entire internet sector. My project was started after Greenpeace USA published a report <http://www.greenpeace.org/usa/global-warming/click-clean/> about the energy consumption of the biggest sites on the Internet in 2015 and in which Wikipedia, to my astonishment, performed poorly, receiving a "D" score and only passing because of the Wikimedia Foundation's openness about its energy consumption. I would very much like to change that and set up a page called "Environmental impact <https://meta.wikimedia.org/wiki/Environmental_impact>" on Meta. I have already discussed the issue with a few people both from the Wikimedia Foundation's management and from the Wikimedia community and have received positive responses. In order to further advance the project, I would like to learn more about how much energy Wikipedia's servers use. As far as I can tell, these figures are not public, but I believe they could very well be. Also, I am interested to learn how changing a server site's energy sources can be carried out on the operations side since the United States energy sector hasn't been completely deregulated yet. So, thank you very much for any comments! Maybe there also is an even better forum to discuss these questions? Finally, if you would like to support my project, please consider adding your name to this list <https://meta.wikimedia.org/wiki/Environmental_impact#Show_your_support>. Thank you. Kind regards, Lukas Mezger / User:Gnom <https://meta.wikimedia.org/wiki/User:Gnom>

14 18

Community Tech survey on watchlist use
by Danny Horn 20 May '16

20 May '16

Hi everyone, WMF's Community Tech team is starting to work on a Cross-wiki watchlist, one of the top 10 wishes in the Community Wishlist Survey that we conducted at the end of last year. [1] We're running a survey on how people use their watchlists, to help inform our work. If you've got a minute and want to share your thoughts, here's the survey link: https://wikimedia.qualtrics.com/SE/?SID=SV_1BRVhdayaTyuGJ7 The survey's hosted on a third-party service. We'll be running the survey for about a week, and once it's closed, we'll publish aggregated results on Meta.[2] Feel free to pass the link on, if you'd like to. Let me know if you have any questions. Thanks! Danny Horn Product Manager, WMF Community Tech [1] Info on the Community Wishlist Survey: https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey Info on the Cross-wiki watchlist project: https://meta.wikimedia.org/wiki/Community_Tech/Cross-wiki_watchlist [2] Survey Privacy Statement: https://wikimediafoundation.org/wiki/Survey_Privacy_Statement_for_March_201…

2 1

12-May-2016 CREDIT, going back to Hangouts on Air/YouTube
by Adam Baso 12 May '16

12 May '16

Hi all, The next CREDIT showcase will be Thursday, 12-May-2016 at 1800 UTC (1100 SF). https://www.mediawiki.org/wiki/CREDIT_showcase For this one we'll use Hangouts on Air for presenters, and the customary YouTube stream for viewers. See you next month! -Adam

2 2

Re: [Wikitech-l] [Mediawiki-i18n] Providing the effective language of messages
by Niklas Laxström 10 May '16

10 May '16

2016-04-12 14:01 GMT+03:00 Adrian Heine <adrian.heine(a)wikimedia.de>: > Hi everyone, > > as some of you might know, I'm a software developer at Wikimedia > Deutschland, working on Wikidata. I'm currently focusing on improving > Wikidata's support for languages we as a team are not using on a daily > basis. As part of my work I stumbled over a shortcoming in MediaWiki's > message system that – as far as I see it – prevents me from doing the right > thing(tm). I'm asking you to verify that the issue I see indeed is an issue > and that we want to fix it. Subsequently, I'm interested in hearing your > plans or goals for MediaWiki's message system so that I can align my > implementation with them. Finally, I am hoping to find someone who is > willing to help me fix it. First of all, thanks for working on this issue. It is a real issue, but not often requested. I think that is because manually checking in every place whether the language code is unexpected (different from the one in current context) would be cumbersome and always outputting language codes on every tag would be bloaty. Best would be if this checking was automated in a templating library, but so far templating hasn't been much adopted in MediaWiki core. But of course this information needs to be exposed first, which is what I understand you are doing. > == The issue == > > On Wikidata, we regularly have content in different languages on the same > page. We use the HTML lang and dir attributes accordingly. For example, we > have a table with terms for an entity in different languages. For missing > terms, we would display a message in the UI language within this table. The > corresponding HTML (simplified) might look like this: > > <div id="mw-content-text" lang="UILANG" dir="UILANG_DIR"> > <table class="entity-terms"> > <tr class="entity-terms-for-OTHERLANG1" lang="OTHERLANG1" > dir="OTHERLANG1_DIR"> > <td class="entity-terms-for-OTHERLANG1-label"> > <div class="wb-empty" lang="UILANG" dir="UILANG_DIR"> >  > </div> > </td> > </tr> > </div> > </div> > > This works great as long as the missing label message is available in the UI > language. If that is not the case, though, the message is translated > according to the defined language fallbacks. In that case, we might end up > with something like this: > > <div class="wb-empty" lang="arc" dir="rtl">No label defined</div> > > That's obviously wrong, and I'd like to fix it. > > == Fixing it == > > For fixing this, I tried to make MessageCache provide the language a message > was taken from [1]. That's not too straight-forward to begin with, but while > working on it I realized that MessageCache is only responsible for following > the language fallback chain for database translations. For file-based > translations, the fallbacks are directly merged in by LocalisationCache, so > the information is not there anymore at the time of translating a message. I > see some ways to fix this: > > * Don't merge messages in LocalisationCache, but perform the fallback on > request (possibly caching the result) > * Tag message strings in LocalisationCache with the language they are in > (sounds expensive to me) > * Tag message strings as being a fallback in LocalisationCache (that way we > could follow the fallback until we find a language in which the message > string is not tagged as being a fallback) > > What do you think? The current localisation cache implementation quite obviously trades space for speed. In this light I would suggest option two, to tag the actual language the string is in. However, this trade-off might not make sense anymore, as we have more languages and more messages, resulting in almost gigabyte size caches. See also for example https://phabricator.wikimedia.org/T99740. I added wikitech-l to CC in hopes that people who have worked on localisation cache more recently would comment on whether option one, to not merge messages, would make more sense nowadays. > > [1] https://gerrit.wikimedia.org/r/282133 > -Niklas

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l April 2016