[Wikimedia-l] Wikimedia Community Group Math Activity Report

[Physikerwelt]

Dear friends of math in Wikipedia,

Last year our effort was focused on improving the W3C standard MathML;
we shifted the focus this year back to the implementation of Math
rendering.
A new purely PHP and MathML-based math rendering pipeline is in the
making and will be available as an opt-in by the end of the year,
simultaneously with the shipment of MathML in the latest Chrome
version.
Since we do not want to carry on PNG images in the year 2023, we are
currently removing them from the rendering pipeline.
For 2023, we intend to improve speed and accessibility for
mathematical formulae and enable popups (similar to the popups for
references) that display semantics when hovering formulae.

All the best
André and Moritz

PS: More information is available here
https://meta.wikimedia.org/wiki/Wikimedia_Community_User_Group_Math
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/3BGOKWJIZGL4TC4HJ22ICRU2SEPWGCR4/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: Open letter on negating race and ethnicity as "meaningful distinctions" in the UCoC

[Physikerwelt]

Dear Anasuya,

thank you. Even after reading your text, I still do not understand
what the meaningful difference between people (i.e., user accounts) of
different races is. Can you provide an example of how the UCoC should
take into account the race property of a person to influence a
decision?

Maybe there is a better wording that avoids this terminology entirely.
I believe for a decision on UCoC matters/violations race should not
matter, maybe this is obvious and does not need to be stated
explicitly.

Personally, I would love to have the option to not specify my race as a user.

All the best
physikerwelt



On Fri, Apr 8, 2022 at 7:39 PM Anasuya Sengupta
 wrote:
>
> Tl;dr Urgent need to address the note denying race and ethnicity as 
> “meaningful distinctions among people” in the Universal Code of Conduct 
> (UCoC). The current wording is highly problematic and can result in endorsing 
> systemic and individual discrimination and violence on the basis of race and 
> ethnicity, rather than preventing it.
>
>
> Dear Wikimedians,
>
>
> We are writing this letter as the Whose Knowledge? user group, both to 
> Wikimedia-l, as well as adding it to the talk page for the UCoC.[0] We 
> endorsed the UCoC in the community voting process because we are committed to 
> its principles and intentions (indeed, some of us have been expressly working 
> towards it within the movement for a very long time, in multiple ways).
>
>
> However, we continue to be deeply concerned about the current wording of a 
> specific note in the UCoC: under Section 3.1 about Harassment, the note under 
> Insults states that “The Wikimedia movement does not endorse "race" and 
> "ethnicity" as meaningful distinctions among people. Their inclusion here is 
> to mark that they are prohibited in use against others as the basis for 
> personal attacks." (emphasis ours)[1]
>
>
> This is both manifestly incorrect and entirely against what we believe to be 
> the principles and intentions of the UCoC. Other Wikimedians have already 
> pointed out the deeply contradictory nature of this statement, including 
> WJBScribe on the talk page in May 2021,[2] but their comments appear not to 
> have been considered yet.
>
>
>
> By stating that "The Wikimedia movement does not endorse "race" and 
> "ethnicity" as meaningful distinctions among people," those responsible for 
> this text do not seem to fully grasp that:
>
>
> Even though the concept of ‘race’ as a biological distinction has been 
> refuted, ‘race’ as a social construct has been fully accepted by modern 
> scholars.[3] Even more importantly, we know historically that the concept of 
> ‘race’ was created and developed to serve and justify European colonialism in 
> its quest to enslave, marginalize, oppress, dominate and exterminate black, 
> brown and indigenous peoples in the lands they colonized. This form of 
> “racial science” was also responsible for the genocide of Europeans who would 
> otherwise be racialized as white outside of Europe, in particular during 
> World War II. Since then the concept of ‘race’ has been used to develop and 
> create some of the most wide ranging systems of power and privilege that 
> currently marginalize and oppress the majority of the world.
>
> By denying or not ‘endorsing’ the existence of race as a “meaningful 
> distinction among people”, the Wikimedia movement is not doing non-white 
> people any favors or helping to end racism or racist demonstrations, such as 
> insults based on race. As we’ve said before, being silent about racism 
> doesn’t make it go away. It only creates the perfect environment for the 
> continued existence of the deep structural powers and privileges that created 
> it in the first place.[4]
>
> Additionally, it is equally manifestly important to acknowledge the ways in 
> which the concept of ‘ethnicity’ is used to create “meaningful” - including 
> violently discriminatory - “distinctions” amongst people, including 
> Islamophobia and anti-Semitism as two obvious examples. It is equally obvious 
> that the concepts of ‘race’ and ‘ethnicity’ are not equivalent and/or 
> interchangeable, and cannot be used so.
>
> By including such a problematic statement, the UCoC contradicts the 
> movement’s commitment to knowledge equity, clearly stated and approved as 
> part of our Wikimedia Movement Strategy for 2030. The Universal Code of 
> Conduct of a movement that doesn’t “see” race or ethnicity or acknowledge the 
> historical and current effects of our racialized and ethnically-driven world, 
> cannot and will not be able to “focus our efforts on the knowledge and 
> communities that have been left out by structures of power and privilege.”[5]
>
&

[Wikimedia-l] [Wikimedia Announcements] Wikimedia Community User Group Math Progress

[Physikerwelt]

Dear Math(ML) enthusiasts,

mathematical expressions are essential building blocks for the
representation of mathematical knowledge in Wikimedia Projects and
elsewhere.
To coordinate the maintenance and development of tools relevant to the
global mathematical community the

Wikimedia Community Group Math [1]

was established in 2019.
Ultimately, the group's mission is to decide on pragmatic steps
towards the goal of making mathematical knowledge easily accessible to
every human being.

In 2021, some implementation details of the caching mechanism of the
Math rendering pipeline had been updated to the latest software
development paradigms employed in Wikimedias codebase. In addition,
Wikimedia joined the W3C MathML working to pave the ground for native
and accessible Math rendering in browsers without workarounds like
images or special text formatting to match mimic math rendering.

For 2022, the goal is to further simplify the rendering process of
mathematical expressions and to continue the work on the MathML 4
standard [2]. Moreover, we aim to facilitate more active participation
in discussing the next steps in Math-related developments for
Wikimedia projects. Therefore, we strive to further maximize our
geographical and gender diversity.

In contrast to 2021, where most improvements remain under the hood of
the Math extension codebase [3], in 2022, there are even a few
achievements this year.

- We have a new Wikimedia hosted mailing list m...@lists.wikimedia.org
(if you were subscribed to the old mailing list, you should have been
transferred to the new mailing list)
- Math is now bundled within the default distribution of MediaWiki [4]
- The rendering of \omicron was fixed

If you receive this email but you did not sign up for any of the
mailing lists in the recipient list, you might be in the BCC field and
want to subscribe to our new mailing list [5];-)

All the best
André and Moritz

[1]: https://meta.wikimedia.org/wiki/Wikimedia_Community_User_Group_Math
[2]: https://www.w3.org/Math/Documents/Charter2021.html
[3]: https://github.com/wikimedia/mediawiki-extensions-Math/graphs/contributors
[4]: https://phabricator.wikimedia.org/T232948
[5]: https://lists.wikimedia.org/postorius/lists/math.lists.wikimedia.org/
--
https://schubotz.org | +49 1578 047 1397
___
Please note: all replies sent to this mailing list will be immediately directed 
to Wikimedia-l, the public mailing list of the Wikimedia community. For more 
information about Wikimedia-l:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
___
WikimediaAnnounce-l mailing list -- wikimediaannounc...@lists.wikimedia.org
To unsubscribe send an email to wikimediaannounce-l-le...@lists.wikimedia.org
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/T62SYUPMQE37QKSWXUYO2GB22LQEACZJ/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Report of Wikimedia Community User Group Math 2019

[Physikerwelt]

Please find the report from 2019 here:

https://meta.m.wikimedia.org/wiki/Wikimedia_Community_User_Group_Math

Note, that it is mandatory to move the section 2019 to a new page, which
will happen as soon as possible.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] new Math options: phrasing the preferences

[Physikerwelt]

Hi Peter,

On Tue, Oct 28, 2014 at 8:40 AM, Peter Krautzberger
peter.krautzber...@mathjax.org wrote:
 While I can understand that the SVG images were orginally optimized of
 inline use, I do not see any principal reason why inline SVG's are
 better.

 a) all rendering issues have been due to SVGs not being linine
That's what I do not understand. Do you need to produce different SVG
images for inline and external images? That does not sound intuitive
for me. Or are ther problems in the way browsers render svg-images.
This would indicate that there are browsers with limited MathML and
SVG support.
 b) accessibility of the SVG output: only inline SVG can be styled by
 client-side CSS. A very important accessibility use case are User Style
 Sheets since many users just need visual enhancements.
I'm convinced that content MathML is needed for good accessibility.
See the ntcir-11 challange regarding $f_xy=f_yx$ or
$\langle\frac1x\rangle\ge\frac1{\langle x \rangle}$
http://ntcir11-wmc.nii.ac.jp/index.php/NTCIR-11-Math-Wikipedia-Task#Content_Queries
.
 c) improve page performance by reducing http requests. A math page seems to
 easily gather 100 and more equations, all of which cause separate http
 requests. @physikerwelt do you have data on how much equations are actually
 used across pages? In particular, beyond simple math \mathbb{N} \math
 situations.
I see your point. However this is a general problem with images. So we
need a general solution, if the number of requests is a problem. I had
the impression that squid could handle quite a few requests per second
http://wiki.squid-cache.org/KnowledgeBase/Benchmarks#Squid_trunk_revno_13251
I'm not sure which cachig system is currently used in production but I
guess the number of requests is not an issue at the moment.
Yes, I have numbers about the cross page use of formulae. I'll send an
updated report on enwiki in the following weeks. (Latests on 15'th of
Jan.)

Best
Moritz

 As I said, I did not mean to open up that debate -- that's simply not my
 call.

 P.

 On Mon, Oct 27, 2014 at 5:05 PM, Physikerwelt w...@physikerwelt.de wrote:

 Hi,

 On Mon, Oct 27, 2014 at 4:52 PM, Gabriel Wicke gwi...@wikimedia.org
 wrote:
  Peter,
 
  On 10/27/2014 03:08 AM, Peter Krautzberger wrote:
  Gabriel wrote:
 
  It would also be nice to reduce the size of the SVG fall-back images,
  which are
  currently about 50% larger than the (low-resolution) PNGs.
 
  I think this only holds for smaller equations. For more complex
  equations it
  seem to me that minified+zip'ed SVGs are the same size (or smaller)
  than the
  PNG.
 
  @physikerwelt do you have data on that by any chance?
 Yes. I'm currenty in the process of summarizing the data. Recently
 LaTeXML added SVG output. This provides even a better basis for
 comparision.
 
  we aren't minifying yet. I did some tests last night (see
  https://bugzilla.wikimedia.org/show_bug.cgi?id=72547), which suggest
  that we
  can reduce the size of small SVG formulas by about 25-30% with
  minification.
  This looks pretty straightforward to add to mathoid.
 Yes we should defintly do that. I do not see any reason for not doing
 that.
 
  As for further optimizations, you could drop the paths entirely and
  point
  the use elements to external files, i.e., use global svg data like
  webfonts. This then raises a different question of balancing: is it
  worth
  loading such fonts/spritemaps when there's only a few equations in
  the page?
 
  For most page views this would likely increase the size, unless those
  maps
  only had the glyphs needed in a certain page. Which would then reduce
  the
  caching between pages.

 I would like to keep it simple. I think this would additional
 complexity and make debugging much harder.
 
  Just for the record since we've rejected it for other reasons, inline
  SVGs
  would also reduce the number of http requests and would resolve the
  clipping
  and baseline problems we've seen in the past.
 
  It's a trade-off between making everybody download both MathML *and* SVG
  (which is larger), or only doing so where MathML is not supported. There
  is
  also a complexity trade-off between simple stand-alone fall-back images,
  and
  the maintenance of a global per-page glyph table. Overall, the size of
  math
  fallbacks is moderate compared to a page with photos, and it looks like
  we
  can get the size close to that of low-resolution PNG images with
  minification. To me, this seems to be a good compromise for now, and we
  can
  always re-evaluate later.
 
  Gabriel
 
 We could benchmark a solution that replaces MathML with inline SVG via
 Javascript as well. However, this would not reduce the number of HTTP
 requests and would not help people without javascript.
 While I can understand that the SVG images were orginally optimized of
 inline use, I do not see any principal reason why inline SVG's are
 better.
 Peter, can you explain that?

 Best
 Moritz