User Details
- User Since
- Apr 22 2017, 3:37 PM (360 w, 2 d)
- Availability
- Available
- IRC Nick
- Lofhi
- LDAP User
- Lofhi
- MediaWiki User
- Lofhi [ Global Accounts ]
Thu, Mar 14
Does WMF have a position on frwiki's infobox header colors? At the very least, they need to be reworked for contrast, but would WMF argue that it would be better to adopt a consistent, global color for all of them?
Wed, Mar 13
Alright. I don't really know how do you want to enable the dark mode only for the technical editors but I can only wait.
Tue, Mar 12
Let me rephrase: how do you expect us to notice compatibility problems with night mode if we have to constantly add ?vectornightmode=1 to the URL? By not blocking the beta feature rollout, you allow frwiki registered editors to use night mode as they choose, and to report problems as they read through our two million (almost three) articles.
I only see hacks.less getting bigger and this will surely complicate fixes in the long term. How easily should itwiki (and all projects) know that one of its CSS classes is hard-corrected in MediaWiki?
How do you expect projects to correct their issues by making night mode inaccessible?
Mon, Mar 11
Blocks deployment to French Wikipedia [...]
Sun, Mar 10
Wed, Mar 6
Tue, Mar 5
There is something I don't understand @Esanders. Why are you uninverting the CSS filter on images? I will ask a very dumb question: why not using the not CSS selector to exclude img? For old browsers support?
I believe the entire community would be willing to participate as pilots for the new night mode, given their constructive contributions when they participated as one of the few major wikis to test the new discussion tools early on.
Mon, Mar 4
I wanted to know the proportion of the active editors not using Vector (both versions).
Sat, Mar 2
[...] when necessary [...]
Fri, Mar 1
Since I've been kicking myself for the past two months with all these new services using a web service based on node, I may write a tutorial if the WMF doesn't mind. My memory is fresh enough to point out the blocking points.
Wed, Feb 28
In my experience, I was confirmed after a brief wait. It appears to be the sole process within the WMF ecosystem that requires approval, but I believe it's acceptable. From what I remember, the only prerequisite for potentially using this type of service is when you are creating an account to create your first Toolforge tool.
Mon, Feb 26
We need stability for communication to communities: are we talking about a night mode, or a dark mode? I read MediaWiki-extensions-DarkMode. But the WMF wrote this page: recommendations for night mode compatibility on Wikimedia wikis, initially named recommendations for dark mode compatibility on Wikimedia wikis. Also, the WMF published the "Dark mode is coming" blog post 4 days before the recommandations page rename.
Fri, Feb 23
@Jdlrobson, could you please share the percent usage by skin? The SQL results for my user_properties view is heavily redacted for obvious reasons.
What would the WMF think about mass editing instead of using their "temporary" gadget based on individual actions? Currently, I see ~1 900 edits per minute, for all the projects. Adding 300 edits per minute to this average for 10 minutes in the middle of the night in Europe to process all the pages on frwiki would be an acceptable stress on the DBs? We have like ~ 1 000 pages.
Thu, Feb 22
Finally found that DifferenceEngine was modified and then I found this task. T357213 caused some community noises on frwiki too and yes, the problem is only met by editors with "Do not show page content below diffs" enabled. Thanks for the reporting @Yann, and @Jdlrobson for the permanent fix.
Tue, Feb 20
To recap, a palette already exists and needs to be integrated into the tokens defined with Codex. So I've got the answer to my question. In addition, it's already planned to add "themes" to Codex components (Vue and only-CSS ones?). So it's more than I expected!
Mon, Feb 19
No misunderstanding: I was just asking the questions to find out what the WMF thought about it! I am not sure that volunteers patches to update external dependencies would be appreciated by the WMF staff ; it's a bit of an interference for my taste, and it seems even less trivial to touch mediawiki/core. Updating now to 3.4 seems a bad idea, but 3.3.13 should be good. Not sure about my capacity about sending patches, MediaWiki ecosystem is big and scary.
Also, it seems that @egardner sees into the future. He had already planned interventions like mine. https://gerrit.wikimedia.org/r/c/design/codex/+/978712/1/packages/codex/package.json#86
My bad for the last minor, I quoted the one just before the release of 3.4.0-beta.1.
I'm uncertain where to seek clarification. Could you please share on a MediaWiki/Wikitech page the strategy for Vue, which serves for much of the client-side now with Codex? Found nothing on https://www.mediawiki.org/wiki/Vue.js
Feb 16 2024
Feb 11 2024
Thanks, will notify them. Good luck with the rest!
Jan 31 2024
The link work by itself. Now, try to paste it in visual mode, or add an internal link using the “add a link” button on source mode. The previewed generated link has no trailing _, the identifier is broken. Firefox 122, Windows 11.
Jan 30 2024
Guess I still need some years with Phabricator. Sorry for the indirect spam.
Jan 28 2024
Nevermind, I was going to commit more HTML-validation attributes (inputmode="numeric" pattern="\d{6}" minlength="6" maxlength="6"), then I remembered that the same input is used for scratch tokens. Welp.
Phabricator does not offer to add a blocking task, so linking T313058 that wants to disable this mechanism.
Jan 25 2024
Alright, it seems a cool feature, but also a pretty big one. I took the time to read about EditCheck and wrote a bit on frwiki.
"URL adress", maybe? Also, I don't understand you later-examples... MediaWiki:BlockedExternalDomains.json is a list of blocked domains, no? They can't be added?
Jan 24 2024
Just putting T311099 here, cause maybe the work you are doing here or there will have an impact on the respective tasks.
Thanks for the details, I guess we can just wait for things to progress for now.
There's clearly something I don't understand. You build a whole palette and graphic guidelines, update skins, standardize nomenclatures between Codex mediawiki.skin.defaults.less; /mediawiki.skin.variables.less... Years of work. But it's impossible for communities to easily reuse classes when Codex has adopted a rather atomic approach to CSS rules? Neither we could hope to use generated Codex CSS components classes?
frwiki use MediaWiki:Spam-blacklist and MediaWiki:BlockedExternalDomains.json for general purposes: spams, block URL shorteners to prevent bypassing, sites used only by banned contributors, promotional sources. And when bypassing is carried out by experienced MediaWiki users, a private AbuseFilter is used. So, "unreliable" seems fine, but "source" doesn't seem totally representative. Maybe just "this website", "this link", "this domain name"?
Jan 23 2024
I was talking to a French-speaking Quebec contributor editing on frwiki. And they confirmed what I'd never really taken the time to study: discussions are indeed the space where dates are not localized, whereas the rest of the interface is. They told me they do conversions manually, mentally...
Thanks for pointing it, I though I was the only one to think about just inverting colors. I really don't think they thought of this option, thanks for the hint. I tried on Google, Bing and DuckDuckGo and I confirm that searching "wikimedia foundation dark night mode invert" will not display a Dark mode is coming blog post.
Jan 22 2024
And for the answering the main question, If the SVG approach is the chosen one, self-containing is the best? I think? Alternatives are doing the same, i.e. https://fonts.google.com/icons ; https://thenounproject.com/icons/
I didn't read the entire source code of Codex, so I don't really know the directions you've taken, but to better understand, it surprised me that .cdx-message__icon is a class with a SVG for the background-image (cases with success or error) within @wikimedia/codex/dist/codex.style.css, but you have to start using NPM and play with mixins to use any other icon.
Still displayed.
Jan 18 2024
I think that my request goes a little against the spirit of the project since a class like cdx-icon--medium is not an independent token (with @wikimedia/codex-design-tokens), but a class linked to the components (with @wikimedia/codex). I guess this means that classes shouldn't be used directly? Even the documentation is ignoring them:
Use the third parameter of the .cdx-mixin-css-icon() mixin, @param-size-icon, to use one of the pre-defined size options (@size-icon-medium, @size-icon-small, or @size-icon-x-small) - https://doc.wikimedia.org/codex/latest/components/demos/icon.html#icon-sizes-1
Jan 7 2024
So, I tried.
Jan 6 2024
Gonna try this weekend, thanks for the notice.
Dec 16 2023
Successfully deployed the (broken) webservice from a built image: https://hitaden.toolforge.org/
So the envvars buildpack support removed is not truly problematic; at least for this project. Still waiting for the builder update with the pnpm support!
It seems that the documentation is just wrong and the YAML lockfile is indeed looked up. Running out of explanations on my side! https://github.com/heroku/buildpacks-nodejs/blob/ee76b7b620a59c1799ef09ddbc3b6435264b84f4/buildpacks/nodejs-pnpm-install/src/main.rs#L35C35-L35C35
This buildpack's bin/detect will only pass if a pnpm-lock.json exists in the project root. This is done to prevent the buildpack from providing indeterminate and unpredictable dependency trees.
Something I don't understand is: if the Build Service is already using Cloud Native Buildpacks with Builder:22, why using pnpm is not supported? Are we one version behind? https://github.com/heroku/buildpacks-nodejs/blob/main/buildpacks/nodejs-pnpm-install/README.md
It seems so complicated. The npm cli or npm install choice is only depending of the major version of npm.
https://github.com/heroku/buildpacks-nodejs/blob/ee76b7b620a59c1799ef09ddbc3b6435264b84f4/buildpacks/npm/lib/build.sh#L78
Dec 15 2023
A nice xmas-gift I see! Anyway, I can't go any further on the subject until next week, there's no hurry. Thanks for the expertise!
Here you go: P54485
Dec 14 2023
I don't know where to ask, but this is the new recommended way before deploying a web service on Toolforge? The node18 version is one year old on the Kubernetes cluster.
Dec 12 2023
Not sure to be frank... I think I am just lazy.
Dec 10 2023
At least, I think that if it will not be changed a notice should be added on the documentation.
Aug 2 2023
Easy-peasy.
Mar 25 2023
I'll work on it in early April.
Mar 26 2021
I believe these changes are related to the disappearance of interlang and interwiki links when an article is edited ($action !== 'view') with the WikiEditor (2010). Can you confirm or disconfirm?
Feb 3 2021
Ah, sorry, I'll think about it next time. Special pages should not be accessed by robots (robots.txt disallow it), and the expected result is that these pages are not referenced (<meta name="robots" content="noindex,nofollow">). So I think the problem is this: the pages can't be accessed and Google can't take the noindex into account. For some reason, these pages have been indexed before.
Jan 15 2021
I just saw that the text was truncated because of me. I uploaded a new version on Commons. Sorry.
The "e" should not be removed since it's on the file. With the "e", it will be perfect (if the images are not blurred in the final result)!