This page is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Is it acceptable in all mathematical notation to use U+03B8 θ GREEK SMALL LETTER THETA instead of the cursive variant U+03D1 ϑ GREEK THETA SYMBOL? They are visually distinct, but presumably the actual Greek letter is easier to type because it is on the Greek pulldown for desktop editors, it's on some people's physical keyboards, and it's on my phone's keyboard because I enabled the Greek language for when I'm editing technical articles. The fewer variants we have the easier it is for readers and editors to search articles and for search engines to index them. I've never run across the cursive variant outside of Wikipedia, but I'm an engineer and not a reader of mathematical papers. For some math articles just talking about angles, I've converted the cursive form to the better-known form, for consistency and clarity. For a general audience, I'd say the non-cursive theta is clearer since it's familiar from trigonometry and is less likely to be confused for a cursive d or something.
There are only a few math articles that use ϑ in HTML markup, namely:
and a bunch not listed above use only \vartheta in <math>...</math>
markup:
Something like Bicycle and motorcycle geometry definitely seems like it should be using a regular theta for clarity, but I'm not sure about the more obscure branches of math represented here.
Thanks! -- Beland ( talk) 18:21, 7 February 2022 (UTC)
{{mvar|θ}}
(θ) or {{mvar|θ}}
(θ). Note that the "mvar" version of the character is more ledgible than the (usual) sans-serif font's "θ".ϑ
(which also renders as "ϑ") and clearly and succinctly explain that it was to enable successful searches for "theta", then I can see no thoughtful justification for an objection: The rendered character, after all, is identical, and the motivation to enhance searchability is legitimate, although not overwhelming.ϑ
, which also call the attention of the editor inspecting the change to the slightly less brief explanation already inserted in each article's Talk page a while back.\theta
and \vartheta
alone. I'm not certain, but I think that searches on the character U+03B8 (θ) will miss anything in HTML symbolic form (θ
), it might also miss all of the LaTeX \vartheta
and \theta
symbols. However, will a search on "theta" pick all of them up (except the Unicode charachters)?ctrl
+F
), to see if making the changes is worth your effort.Many guidelines on mathematical writing say that equations should be treated as any other part of the sentence they belong to ( When writing in math, do you use a comma or colon preceding an equation?). Thus, the rules for when to use colons in front of equations should be similar to when to use colons in general English writing. The general rule in English is that colons can only be used after what would constitute a full sentence (see the Wikipedia article about colon that confirms this). So for example in
The definition of f is:
the colon shouldn't be used because it separates the verb from the object of the sentence. So my suggestion is to add a guideline that a colon can't be used in front of an equation if what precedes the colon is not a full sentence. Morgr2 ( talk) 19:48, 20 May 2022 (UTC)
MOS:MATH#PUNC currently says: "Similarly...". Note the lack of an independent clause. In fact, the second sentence of the colon (punctuation) article that you link so approvingly says "A colon often precedes an explanation, a list, or a quoted sentence." I think the use of a colon to precede a mathematical formula is very similar in nature. — David Eppstein ( talk) 20:43, 20 May 2022 (UTC)
Hello, everyone! After the previous discussion and a lot of thinking and looking at how these characters are used, I'd like to propose dropping the sentence in Wikipedia:Manual of Style/Mathematics#Special symbols which currently says: "As a rule of thumb, specific mathematical symbols shall be used, not similar-looking ASCII or punctuation symbols, even if corresponding glyphs are indistinguishable." It often seems in practice and sometimes explicitly because of this MOS, we actually do the opposite. The easiest replacement would I think be to simply give specific guidance for all the affected characters. There aren't that many, it clarifies the decisions a lot, and there are a lot of exceptions no matter what the default rule is.
Screenreaders tend to mangle the non-ASCII variants, reading e.g. "letter 223C" instead of "tilde", so the above preferences should further WP:ACCESS.
For almost all mathematical characters that have two Unicode representations, we already avoid using the special character. Namely:
Likewise, MOS:STRAIGHT prefers the ASCII characters over more-attractive curved quotes, though these are general punctuation not specific to math. ASCII encoding also keeps markup simple, which is a goal of MOS:MARKUP.
Using the ASCII and alphabetic characters would make it easier for readers and editors to find the text in question when using "find in page", the Wikipedia search engine, and external search engines. The ASCII characters are much easier to type, so that's what people would intuitively try first (and many don't know how to type something not on their keyboard). It's difficult or impossible to tell these character pairs apart visually, and many people don't know there are math-specific variants in Unicode, leading to a lot of potential frustration trying to get things to match up.
I propose adding the following specific guidance:
References
Existing guidance on specific characters would remain in place, including the non-ASCII minus sign at Wikipedia:Manual of Style/Mathematics#Minus sign.
More specifics:
According to Micro-, the Unicode standard itself prefers U+03BC, and the other seems to be only intended for compatibility with legacy character encodings. It seems logical to me to prefer sigma and pi over other characters because these characters are actually on keyboards, and so are easier for readers and editors to input and to search. Some browsers will not find one character by searching for the Greek alphabet equivalent, and users would not necessarily know that there are two Unicode characters that look identical, and wouldn't even know they might need to input a character in a different way, much less how.
I'll invite Comp.arch to comment on mu vs. micro; they raised objections ( here). I'm not sure if the above is persuasive or if some editors wish to argue for specific exceptions?
The summation and product characters are unused in articles, except where the characters themselves are being discussed.
MOS:FRAC already requires use of the ASCII slash for fractions-as-inline-division. I went through and changed all existing uses (fewer than 100 articles) of the division slash, many of which were inappropriate as they did not actually involve divisions, and so far I've gotten no objections.
It's hard to tell which uses of the colon character are for time or Bible verses vs. ratio, but I'd estimate tens of thousands of articles already use the colon to express a ratio. Fewer than 100 articles used the ratio character, so I changed them all. Once again, many were used incorrectly, and so far no objections.
Proportionality (mathematics), Tilde, and Approximation all used the ASCII ~, and this is by far more common. It's a bit unclear, but it's possible the tilde operator U+223C is supposed to mean "varies proportionally" and not "approximately" which is for the ASCII tilde? Or are they completely interchangeable? I changed hundreds of "approximately" usages from U+223C to U+007E, and so far have gotten no objections.
Fewer than 100 articles use the set minus character, some of which only do so to discuss the character itself. I had intended to have this discussion before changing these, because I was less certain about them, but forgot to do so before they came up on my list. (Apologies!) Jacobolus objected, and I'm curious if my rationale is persuasive, and also what other editors think about the pros and cons of maintaining this symbol as distinct from an ASCII backslash.
-- Beland ( talk) 21:50, 14 July 2023 (UTC)
Based on what do you determine what "correct" typography is?– Absent some strong reason with clear site-wide consensus, "correct" means whatever the local consensus is on each article, with a bias toward preserving existing conventions and stylistic preferences, see MOS:STYLEVAR. To quote directly: "enforcing optional style in a bot-like fashion without prior consensus, is never acceptable"– jacobolus (t) 02:50, 15 July 2023 (UTC)
does indeed hurt people using screenreaders– This argument would be much more convincing if we had some mathematically savvy visually impaired readers here saying "specific article X was nicely accessible and I could make complete sense of it except for these particular unicode glyphs which rendered as gibberish". But I haven't actually seen any such testimonies. – jacobolus (t) 23:26, 15 July 2023 (UTC)
<math>...</math>
content, the article is almost entirely inaccessible to a college math major. What I don't want is to have a standard of proof so high that we never address any accessibility problems that we can and should have predicted. Nor do I think visually impaired people are the only legitimate users of screen readers, even though it's most important to fix screenreader problems for the people who can't use their eyes as a workaround. We are gathering evidence in the section below on what problems screen readers actually encounter, and in practice we seem to mostly agree on the solutions that should be used for specific characters (and that we need to improve how screen readers handle LaTeX-like markup), so I'm not going to attempt to reach agreement on our philosophical reasons. --
Beland (
talk)
17:47, 16 July 2023 (UTC)I would expect a professionally-typeset math textbook to use exactly the same characters when they mean exactly the same thing.– This is an argument toward using LaTeX consistently and avoiding raw text or {{ math}} templates wherever possible, not an argument for substituting the nearest available ASCII character any time we hit a technical symbol. – jacobolus (t) 23:32, 15 July 2023 (UTC)
most of which are not on mathematical topics– Authors on non-technical pages should do whatever seems best to them.
1. This camera has a 3:4 aspect ratio. (ASCII)
2. This camera has a 3∶4 aspect ratio. (non-ASCII)
3. This camera has a aspect ratio. (LaTeX-like)
4. 1/2 the class is on the blue team. (ASCII)
5. 1∕2 the class is on the blue team. (non-ASCII)
6. the class is on the blue team. (LaTeX-like)
7. Add ~1 cup of water (ASCII)
8. Add ∼1 cup of water (non-ASCII)
8B. Add ≈1 cup of water (double tilde)
9. Add cup of water (LaTeX-like)
10. Define on V \ 0 the binary relation v ~ w to hold when there exists a nonzero real number t such that v = tw. (ASCII)
11. Define on V ∖ 0 the binary relation v ∼ w to hold when there exists a nonzero real number t such that v = tw. (non-ASCII)
12. Define on the binary relation to hold when there exists a nonzero real number such that (LaTeX-like)
I frequently listen to Wikipedia articles using the Voice Aloud Reader for Android, so I can do other things at the same time, like gardening. I had that app speak the above section. The LaTeX-like markup is completely ignored, just skipped over. (1) reads "three four aspect ratio" which is intelligible, (2) reads "three to four aspect ratio" which is perfect, (4) reads "one half the class" which is perfect, (5) reads "one division slash two the class" which is intelligible but distracting, (7) reads "approximately one cup" which is perfect, and (8) reads "tilde operator one cup", which is momentarily confusing and only intelligible to people who know what "tilde" means. -- Beland ( talk) 03:18, 16 July 2023 (UTC)
<math>...</math>
markup is once again completely dropped. Some of the {{
math}} markup reads fine, like "t ≥ 0" but "F(s)" is pronounced like a word. Often it's not possible to make sense because punctuation is ignored in expressions like "[0, ∞)". --
Beland (
talk)
03:25, 16 July 2023 (UTC)
Here are my results in the latest release versions of the two most common Windows screen readers:
Both these screen readers can have wildly varying configurations about which speech engine is used, which can produce different results. I've heard that the markup within math tags is also ignored by VoiceOver on the iPhone as well as Siri. Therefore we should minimise their use in non-mathematical articles. Graham 87 04:33, 16 July 2023 (UTC)
<math>...</math>
parts, but it says weird things, e.g. "one dollar per two dollars" when it sees "$ 1/2 $". Visually, instead of properly typeset formulas I see dollar signs and LaTeX source code, so this is not a setting I can leave turned on. So what happens if math comes up in an article is that I either pull out my phone and read it visually, or just give up on the article and listen to something else. --
Beland (
talk)
07:51, 16 July 2023 (UTC)
<math>...</math>
. Apparently,
not anymore. I also found
Wikipedia:Rendering math to be a helpful overview for researching technical options, BTW. Adding the CSS at
mw:Extension:Math/advancedSettings#CSS for the MathML with SVG fallback mode gets me copy-paste-able MathML output in all browsers;
this extension does the same for Firefox only. However, even with the "load in browser" trick, this does not transfer to Voice Aloud, which continues to skip the <math>...</math>
parts entirely. Going back to the default setting, it appears this app simply skips images instead of reading the "alt" text (which I do see in the rendered HTML), which is what I would expect it to do, and I can't find any setting that would change that behavior. I can press on an image to see the LaTeX source visually because that's the alt text, but Android "select to speak" (in Accessibility settings) and "read aloud" (after highlighting) don't read that. Instead they read some of the ASCII characters but leave out punctuation and items like "integral" and "infinity". --
Beland (
talk)
09:25, 16 July 2023 (UTC)
I just added a version with "alt" set on the LaTeX elements, but it doesn't seem to actually work. That is, the alt attribute inside is not set to what I suggested, but is instead still set to the LaTeX source. (Also, Mac VoiceOver at least doesn't seem to pay any attention to it.) Perhaps Help:Displaying a formula should be altered to indicate that trying to explicitly set 'alt' doesn't do anything. – jacobolus (t) 09:05, 16 July 2023 (UTC)
It sounds like in some of the listed cases, ASCII is preferred, and in others full <math>...</math>
markup (with the presumption of lobbying for better screen reader support)? No one has complained about the guidance on prime and asterisk, so that all together, how do people feel about the below?
Other
Outside of <math>...</math>
markup:
<math>...</math>
markup instead of U+2216 ∖ SET MINUS or U+005C \ REVERSE SOLIDUS for set substraction.I introduced "≈" here...it's read for me as "approximately equal" by Voice Aloud; the built-in Android Select to Speak skips both "~" and "≈". -- Beland ( talk) 18:08, 18 July 2023 (UTC)
<math>... \setminus ...</math>
or <math>... \smallsetminus ...</math>
(the choice of which should be left to author preference / local consensus), and then recommend that ∖ 'set minus' is fine in places where LaTeX is technically infeasible. –
jacobolus
(t)
18:25, 18 July 2023 (UTC)<math>...</math>
markup.I added the following:
<math>...</math>
markup cannot be used in image captions; use regular bold throughout the article instead.35.139.154.158 reverted with the edit summary:
I'm not sure that IP editors can receive pings, but here goes anyway...
It's not possible to put these characters in captions without them showing up in the image viewer for mobile readers, so I consider those to be equivalent. I'm open to an alternative phrasing if you wish. A previous paragraph reads "each article should be consistent with itself", so if we must use regular bold in image captions, then that implies we must use it consistently throughout the article? -- Beland ( talk) 03:14, 13 July 2023 (UTC)
<math>...</math>
markup cannot be used in image captions
is too restrictive, imo. Apparently, you just mean blackboard bold inside <math>...</math>
, don't you? -
Jochen Burghardt (
talk)
07:48, 6 August 2023 (UTC)
This page is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Is it acceptable in all mathematical notation to use U+03B8 θ GREEK SMALL LETTER THETA instead of the cursive variant U+03D1 ϑ GREEK THETA SYMBOL? They are visually distinct, but presumably the actual Greek letter is easier to type because it is on the Greek pulldown for desktop editors, it's on some people's physical keyboards, and it's on my phone's keyboard because I enabled the Greek language for when I'm editing technical articles. The fewer variants we have the easier it is for readers and editors to search articles and for search engines to index them. I've never run across the cursive variant outside of Wikipedia, but I'm an engineer and not a reader of mathematical papers. For some math articles just talking about angles, I've converted the cursive form to the better-known form, for consistency and clarity. For a general audience, I'd say the non-cursive theta is clearer since it's familiar from trigonometry and is less likely to be confused for a cursive d or something.
There are only a few math articles that use ϑ in HTML markup, namely:
and a bunch not listed above use only \vartheta in <math>...</math>
markup:
Something like Bicycle and motorcycle geometry definitely seems like it should be using a regular theta for clarity, but I'm not sure about the more obscure branches of math represented here.
Thanks! -- Beland ( talk) 18:21, 7 February 2022 (UTC)
{{mvar|θ}}
(θ) or {{mvar|θ}}
(θ). Note that the "mvar" version of the character is more ledgible than the (usual) sans-serif font's "θ".ϑ
(which also renders as "ϑ") and clearly and succinctly explain that it was to enable successful searches for "theta", then I can see no thoughtful justification for an objection: The rendered character, after all, is identical, and the motivation to enhance searchability is legitimate, although not overwhelming.ϑ
, which also call the attention of the editor inspecting the change to the slightly less brief explanation already inserted in each article's Talk page a while back.\theta
and \vartheta
alone. I'm not certain, but I think that searches on the character U+03B8 (θ) will miss anything in HTML symbolic form (θ
), it might also miss all of the LaTeX \vartheta
and \theta
symbols. However, will a search on "theta" pick all of them up (except the Unicode charachters)?ctrl
+F
), to see if making the changes is worth your effort.Many guidelines on mathematical writing say that equations should be treated as any other part of the sentence they belong to ( When writing in math, do you use a comma or colon preceding an equation?). Thus, the rules for when to use colons in front of equations should be similar to when to use colons in general English writing. The general rule in English is that colons can only be used after what would constitute a full sentence (see the Wikipedia article about colon that confirms this). So for example in
The definition of f is:
the colon shouldn't be used because it separates the verb from the object of the sentence. So my suggestion is to add a guideline that a colon can't be used in front of an equation if what precedes the colon is not a full sentence. Morgr2 ( talk) 19:48, 20 May 2022 (UTC)
MOS:MATH#PUNC currently says: "Similarly...". Note the lack of an independent clause. In fact, the second sentence of the colon (punctuation) article that you link so approvingly says "A colon often precedes an explanation, a list, or a quoted sentence." I think the use of a colon to precede a mathematical formula is very similar in nature. — David Eppstein ( talk) 20:43, 20 May 2022 (UTC)
Hello, everyone! After the previous discussion and a lot of thinking and looking at how these characters are used, I'd like to propose dropping the sentence in Wikipedia:Manual of Style/Mathematics#Special symbols which currently says: "As a rule of thumb, specific mathematical symbols shall be used, not similar-looking ASCII or punctuation symbols, even if corresponding glyphs are indistinguishable." It often seems in practice and sometimes explicitly because of this MOS, we actually do the opposite. The easiest replacement would I think be to simply give specific guidance for all the affected characters. There aren't that many, it clarifies the decisions a lot, and there are a lot of exceptions no matter what the default rule is.
Screenreaders tend to mangle the non-ASCII variants, reading e.g. "letter 223C" instead of "tilde", so the above preferences should further WP:ACCESS.
For almost all mathematical characters that have two Unicode representations, we already avoid using the special character. Namely:
Likewise, MOS:STRAIGHT prefers the ASCII characters over more-attractive curved quotes, though these are general punctuation not specific to math. ASCII encoding also keeps markup simple, which is a goal of MOS:MARKUP.
Using the ASCII and alphabetic characters would make it easier for readers and editors to find the text in question when using "find in page", the Wikipedia search engine, and external search engines. The ASCII characters are much easier to type, so that's what people would intuitively try first (and many don't know how to type something not on their keyboard). It's difficult or impossible to tell these character pairs apart visually, and many people don't know there are math-specific variants in Unicode, leading to a lot of potential frustration trying to get things to match up.
I propose adding the following specific guidance:
References
Existing guidance on specific characters would remain in place, including the non-ASCII minus sign at Wikipedia:Manual of Style/Mathematics#Minus sign.
More specifics:
According to Micro-, the Unicode standard itself prefers U+03BC, and the other seems to be only intended for compatibility with legacy character encodings. It seems logical to me to prefer sigma and pi over other characters because these characters are actually on keyboards, and so are easier for readers and editors to input and to search. Some browsers will not find one character by searching for the Greek alphabet equivalent, and users would not necessarily know that there are two Unicode characters that look identical, and wouldn't even know they might need to input a character in a different way, much less how.
I'll invite Comp.arch to comment on mu vs. micro; they raised objections ( here). I'm not sure if the above is persuasive or if some editors wish to argue for specific exceptions?
The summation and product characters are unused in articles, except where the characters themselves are being discussed.
MOS:FRAC already requires use of the ASCII slash for fractions-as-inline-division. I went through and changed all existing uses (fewer than 100 articles) of the division slash, many of which were inappropriate as they did not actually involve divisions, and so far I've gotten no objections.
It's hard to tell which uses of the colon character are for time or Bible verses vs. ratio, but I'd estimate tens of thousands of articles already use the colon to express a ratio. Fewer than 100 articles used the ratio character, so I changed them all. Once again, many were used incorrectly, and so far no objections.
Proportionality (mathematics), Tilde, and Approximation all used the ASCII ~, and this is by far more common. It's a bit unclear, but it's possible the tilde operator U+223C is supposed to mean "varies proportionally" and not "approximately" which is for the ASCII tilde? Or are they completely interchangeable? I changed hundreds of "approximately" usages from U+223C to U+007E, and so far have gotten no objections.
Fewer than 100 articles use the set minus character, some of which only do so to discuss the character itself. I had intended to have this discussion before changing these, because I was less certain about them, but forgot to do so before they came up on my list. (Apologies!) Jacobolus objected, and I'm curious if my rationale is persuasive, and also what other editors think about the pros and cons of maintaining this symbol as distinct from an ASCII backslash.
-- Beland ( talk) 21:50, 14 July 2023 (UTC)
Based on what do you determine what "correct" typography is?– Absent some strong reason with clear site-wide consensus, "correct" means whatever the local consensus is on each article, with a bias toward preserving existing conventions and stylistic preferences, see MOS:STYLEVAR. To quote directly: "enforcing optional style in a bot-like fashion without prior consensus, is never acceptable"– jacobolus (t) 02:50, 15 July 2023 (UTC)
does indeed hurt people using screenreaders– This argument would be much more convincing if we had some mathematically savvy visually impaired readers here saying "specific article X was nicely accessible and I could make complete sense of it except for these particular unicode glyphs which rendered as gibberish". But I haven't actually seen any such testimonies. – jacobolus (t) 23:26, 15 July 2023 (UTC)
<math>...</math>
content, the article is almost entirely inaccessible to a college math major. What I don't want is to have a standard of proof so high that we never address any accessibility problems that we can and should have predicted. Nor do I think visually impaired people are the only legitimate users of screen readers, even though it's most important to fix screenreader problems for the people who can't use their eyes as a workaround. We are gathering evidence in the section below on what problems screen readers actually encounter, and in practice we seem to mostly agree on the solutions that should be used for specific characters (and that we need to improve how screen readers handle LaTeX-like markup), so I'm not going to attempt to reach agreement on our philosophical reasons. --
Beland (
talk)
17:47, 16 July 2023 (UTC)I would expect a professionally-typeset math textbook to use exactly the same characters when they mean exactly the same thing.– This is an argument toward using LaTeX consistently and avoiding raw text or {{ math}} templates wherever possible, not an argument for substituting the nearest available ASCII character any time we hit a technical symbol. – jacobolus (t) 23:32, 15 July 2023 (UTC)
most of which are not on mathematical topics– Authors on non-technical pages should do whatever seems best to them.
1. This camera has a 3:4 aspect ratio. (ASCII)
2. This camera has a 3∶4 aspect ratio. (non-ASCII)
3. This camera has a aspect ratio. (LaTeX-like)
4. 1/2 the class is on the blue team. (ASCII)
5. 1∕2 the class is on the blue team. (non-ASCII)
6. the class is on the blue team. (LaTeX-like)
7. Add ~1 cup of water (ASCII)
8. Add ∼1 cup of water (non-ASCII)
8B. Add ≈1 cup of water (double tilde)
9. Add cup of water (LaTeX-like)
10. Define on V \ 0 the binary relation v ~ w to hold when there exists a nonzero real number t such that v = tw. (ASCII)
11. Define on V ∖ 0 the binary relation v ∼ w to hold when there exists a nonzero real number t such that v = tw. (non-ASCII)
12. Define on the binary relation to hold when there exists a nonzero real number such that (LaTeX-like)
I frequently listen to Wikipedia articles using the Voice Aloud Reader for Android, so I can do other things at the same time, like gardening. I had that app speak the above section. The LaTeX-like markup is completely ignored, just skipped over. (1) reads "three four aspect ratio" which is intelligible, (2) reads "three to four aspect ratio" which is perfect, (4) reads "one half the class" which is perfect, (5) reads "one division slash two the class" which is intelligible but distracting, (7) reads "approximately one cup" which is perfect, and (8) reads "tilde operator one cup", which is momentarily confusing and only intelligible to people who know what "tilde" means. -- Beland ( talk) 03:18, 16 July 2023 (UTC)
<math>...</math>
markup is once again completely dropped. Some of the {{
math}} markup reads fine, like "t ≥ 0" but "F(s)" is pronounced like a word. Often it's not possible to make sense because punctuation is ignored in expressions like "[0, ∞)". --
Beland (
talk)
03:25, 16 July 2023 (UTC)
Here are my results in the latest release versions of the two most common Windows screen readers:
Both these screen readers can have wildly varying configurations about which speech engine is used, which can produce different results. I've heard that the markup within math tags is also ignored by VoiceOver on the iPhone as well as Siri. Therefore we should minimise their use in non-mathematical articles. Graham 87 04:33, 16 July 2023 (UTC)
<math>...</math>
parts, but it says weird things, e.g. "one dollar per two dollars" when it sees "$ 1/2 $". Visually, instead of properly typeset formulas I see dollar signs and LaTeX source code, so this is not a setting I can leave turned on. So what happens if math comes up in an article is that I either pull out my phone and read it visually, or just give up on the article and listen to something else. --
Beland (
talk)
07:51, 16 July 2023 (UTC)
<math>...</math>
. Apparently,
not anymore. I also found
Wikipedia:Rendering math to be a helpful overview for researching technical options, BTW. Adding the CSS at
mw:Extension:Math/advancedSettings#CSS for the MathML with SVG fallback mode gets me copy-paste-able MathML output in all browsers;
this extension does the same for Firefox only. However, even with the "load in browser" trick, this does not transfer to Voice Aloud, which continues to skip the <math>...</math>
parts entirely. Going back to the default setting, it appears this app simply skips images instead of reading the "alt" text (which I do see in the rendered HTML), which is what I would expect it to do, and I can't find any setting that would change that behavior. I can press on an image to see the LaTeX source visually because that's the alt text, but Android "select to speak" (in Accessibility settings) and "read aloud" (after highlighting) don't read that. Instead they read some of the ASCII characters but leave out punctuation and items like "integral" and "infinity". --
Beland (
talk)
09:25, 16 July 2023 (UTC)
I just added a version with "alt" set on the LaTeX elements, but it doesn't seem to actually work. That is, the alt attribute inside is not set to what I suggested, but is instead still set to the LaTeX source. (Also, Mac VoiceOver at least doesn't seem to pay any attention to it.) Perhaps Help:Displaying a formula should be altered to indicate that trying to explicitly set 'alt' doesn't do anything. – jacobolus (t) 09:05, 16 July 2023 (UTC)
It sounds like in some of the listed cases, ASCII is preferred, and in others full <math>...</math>
markup (with the presumption of lobbying for better screen reader support)? No one has complained about the guidance on prime and asterisk, so that all together, how do people feel about the below?
Other
Outside of <math>...</math>
markup:
<math>...</math>
markup instead of U+2216 ∖ SET MINUS or U+005C \ REVERSE SOLIDUS for set substraction.I introduced "≈" here...it's read for me as "approximately equal" by Voice Aloud; the built-in Android Select to Speak skips both "~" and "≈". -- Beland ( talk) 18:08, 18 July 2023 (UTC)
<math>... \setminus ...</math>
or <math>... \smallsetminus ...</math>
(the choice of which should be left to author preference / local consensus), and then recommend that ∖ 'set minus' is fine in places where LaTeX is technically infeasible. –
jacobolus
(t)
18:25, 18 July 2023 (UTC)<math>...</math>
markup.I added the following:
<math>...</math>
markup cannot be used in image captions; use regular bold throughout the article instead.35.139.154.158 reverted with the edit summary:
I'm not sure that IP editors can receive pings, but here goes anyway...
It's not possible to put these characters in captions without them showing up in the image viewer for mobile readers, so I consider those to be equivalent. I'm open to an alternative phrasing if you wish. A previous paragraph reads "each article should be consistent with itself", so if we must use regular bold in image captions, then that implies we must use it consistently throughout the article? -- Beland ( talk) 03:14, 13 July 2023 (UTC)
<math>...</math>
markup cannot be used in image captions
is too restrictive, imo. Apparently, you just mean blackboard bold inside <math>...</math>
, don't you? -
Jochen Burghardt (
talk)
07:48, 6 August 2023 (UTC)