-
-
Notifications
You must be signed in to change notification settings - Fork 634
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added some mathematical symbols #11467
Conversation
source/locale/en/symbols.dic
Outdated
≍ Equivalent to none | ||
≭ Not equivalent to none | ||
≎ Geometrically equivalent to | ||
≑ Geometrically equal tonone |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a tab character missing here I think.
Oops, yes thanks for the review. It should be ok now. :) |
@Adriani90 Many thanks for your work on this! Could I please have a try build or be directed to a relevant Master snapshot to test this out? I mainly want to make sure that no important Math symbols have been left out. For context, the few very basic symbols I came across and weren't read by Espeak-NG are as follows: |
@bhavyashah You can use the automatically created PR build for testing this, I don't think a try build is necessary in this case. You can always get to it by selecting "show all checks" next to "All checks have passed", then after "AppVeyor build succeeded" following the "Details" link, then finding the "Artifacts" tab, finally you will find a link to the installer. Here is a direct link for the latest build of this PR: https://ci.appveyor.com/api/buildjobs/9kp2iwapkhtlbpx4/artifacts/output%2Fnvda_snapshot_pr11467-20720%2C12322f65.exe |
@bhavyashah your suggested symbols will be definitely read with the try build which will be generated in some minutes. But note that you have to set the pronounciation level by yourself in the interpunctuations dialog. For morst mathematical symbols I have set the level to none. |
@Adriani90 I have come across the list mentioned in the file attached, those are the symbols still not recognized by NVDA, I have the latest build of this PR, still, the symbols are being read as symbol 2135, etc. |
In the most current try build which will be enerated in a few minutes the mathematical symbols from the document added by @poonamdeokar137 have been added. Note that not all those symbols hhave been added since some of them are not related to mathematics. @poonamdeokar137 in your document, symols 7, 15 and 22 were already announced by that try build. Maybe you had to adjust the symbol level manually in the symbols dialog in NVDA menu. Symbols related to other categories such as chemistry, physics etc. will be added in a subsequent pull request probably. This one should concentrate only on mathematical content first. |
source/locale/en/symbols.dic
Outdated
❖ black diamond minus white X some | ||
♣ black club some | ||
♦ black diamond some | ||
◆ black diamond some | ||
◆ black diamond some |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like this introduces a white space error (extra tab on the end of the line).
@@ -112,22 +112,18 @@ _ line most | |||
◾ black square some | |||
□ white square some | |||
◦ white bullet some | |||
⇒ right double arrow some |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changing this to "implies" might be controversial. It makes sense in the domain of mathematics but arrows like this can be used in other locations. The intent may not be clear anymore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you give an example? according to my research this is mostly used in formulas, mostly in mathematics but also in physics or other natural science fields, but I didn't see any other use case for this out there. In any formula this is interpreted as "implies".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another way to solve such problems could be a new checkbox in the interpunctuation dialog in NVDA which allows you to use synthesizer's pronounciation or not. If disabled, NVDA would pronounce the symbol as it is in the symols.dic, and if it is enabled NVDA would pronounce it as it comes from the synthesizer, ignoring the patern in the symbols.dic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have to agree with @feerrenrut here. Two particular examples which comes to my mint are various posts where this arrows shows the fact that the event to the left is connected to the event to the right and formal grammars where this arrow is used to point from shorter form of the grammar to the longer one. Intent of this symbol was certainly cleaner as an arrow.
⇨ right white arrow some | ||
➔ right-pointing arrow some | ||
➢ right arrowhead some | ||
⮚ right arrowhead some |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
was this removed intentionally?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the entry was duplicate, see line above.
Could you summarize the changes here and the justification for them. Where things have moved around it is difficult / time consuming to keep track. Please keep the scope of this PR stable from here, addressing more symbols should be done in subsequent PR's, otherwise we go back to square one with the review process. |
The cahnges in this PR are really meant to improve mathematical reading and writing, so some symbols have been moved from standard punctuation / symbols or from "other characters" to coresponding mathematical categories because they are explicitely used only in these categories, i.e. ⁻). Otherwise there are many new symbold in there which are specifically used in mathematics. To keep an structured overview of symbols, I have restructured the file according to different categories. This might make it easier for the future when considering to add new inter punctuation levels (i.e. some including mathematics, or some including musical symbols). |
… cause issues in many lating languages. Those ordinal symbols should be controlled by the synthesizers.
So far I think the work is now complete, these symbols should really cover most use cases out there. Other mathematical use cases can be added later, if there is a clear justification for it. |
hello,
for symbols, which are pronounced differently about genders, I used
neutral description - no masculine, no feminine but neutral; in
slovenian we have "middle" grammar gender and I used it; also for
ordinal symbols. so I'm against to remove them.
and as I know other language, they also have middle grammar gender
(en-it, de-es etc) and coresponding words to cover ordinal and other
symbols.
best regards,
Jožef
2020-08-17 22:54 GMT+02.00, Adriani90 <[email protected]>:
… So far I think the work is now complete, these symbols should really cover
most use cases out there. Other mathematical use cases can be added later,
if there is a clear justification for it.
If this PR come into Alpha, this would be great because we need thorough
testing with different languages. But my first tests with romanian, german
and english did not show pronounciation problems. However, there might be
cases where we should decide wether to remove some symbols if NVDA cannot
provide a understandable or confortable translation for every language. Then
this should be handled by the synthesizers themselves. However, in most
cases I found the pronounciations from the synthesizers very bad and
actually not really correct, so I decided to take them in the NVDA's
dictionary to give people the chance to work more professionally when
reading or writing mathematical content.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#11467 (comment)
|
source/locale/en/symbols.dic
Outdated
≐ Approaches the limit none | ||
∘ Ring Operator none | ||
∙ Bullet Operator none | ||
∣ Devides none |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Devides -> divides
source/locale/en/symbols.dic
Outdated
∘ Ring Operator none | ||
∙ Bullet Operator none | ||
∣ Devides none | ||
∤ Does not devide none |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
again devide -> divide
source/locale/en/symbols.dic
Outdated
≯ Not greater than none | ||
|
||
#Mathematical constants | ||
π Pi some |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one cannot be added until #5194 is fixed, otherwise we would break normal reading for Greek speaking people. Please remove!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My intention is to add greek letters to the symbols-dic after having this merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please read #5194 carefully. It is not enough to just add them to the symbols file - modifications of the Python code which handles symbols are also required.
source/locale/en/symbols.dic
Outdated
|
||
#Mathematical constants | ||
π Pi some | ||
φ Golden ratio some |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above.
source/locale/en/symbols.dic
Outdated
∂ partial derivative none | ||
∇ gradient of none | ||
∆ Delta none |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unicode defines this as increment, not as delta. Also calling this symbol delta makes it impossible to distinguish it from the Greek letter. I'd personally remove it not to create confusion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, in most cases people use the greek letter Delta to indicate the change between two elements and not the increment symbol.
@@ -112,22 +112,18 @@ _ line most | |||
◾ black square some | |||
□ white square some | |||
◦ white bullet some | |||
⇒ right double arrow some |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have to agree with @feerrenrut here. Two particular examples which comes to my mint are various posts where this arrows shows the fact that the event to the left is connected to the event to the right and formal grammars where this arrow is used to point from shorter form of the grammar to the longer one. Intent of this symbol was certainly cleaner as an arrow.
Another way to solve such problems could be a new checkbox in the
interpunctuation dialog in NVDA which allows you to use synthesizer's
pronounciation or not. If disabled, NVDA would pronounce the symbol as
it is in the symols.dic, and if it is enabled NVDA would pronounce it
as it comes from the synthesizer, ignoring the patern in the
symbols.dic.
it has already been implemented. see section speech in preferences of
NVDA and option Trust voice's language when processing characters and
symbols
according to userguide:
Trust voice's language when processing characters and symbols
On by default, this option tells NVDA if the current voice's language
can be trusted when processing symbols and characters. If you find
that NVDA is reading punctuation in the wrong language for a
particular synthesizer or voice, you may wish to turn this off to
force NVDA to use its global language setting instead.
2020-08-17 23:08 GMT+02.00, J.G <[email protected]>:
… hello,
for symbols, which are pronounced differently about genders, I used
neutral description - no masculine, no feminine but neutral; in
slovenian we have "middle" grammar gender and I used it; also for
ordinal symbols. so I'm against to remove them.
and as I know other language, they also have middle grammar gender
(en-it, de-es etc) and coresponding words to cover ordinal and other
symbols.
best regards,
Jožef
2020-08-17 22:54 GMT+02.00, Adriani90 ***@***.***>:
> So far I think the work is now complete, these symbols should really
> cover
> most use cases out there. Other mathematical use cases can be added
> later,
> if there is a clear justification for it.
> If this PR come into Alpha, this would be great because we need thorough
> testing with different languages. But my first tests with romanian,
> german
> and english did not show pronounciation problems. However, there might be
> cases where we should decide wether to remove some symbols if NVDA cannot
> provide a understandable or confortable translation for every language.
> Then
> this should be handled by the synthesizers themselves. However, in most
> cases I found the pronounciations from the synthesizers very bad and
> actually not really correct, so I decided to take them in the NVDA's
> dictionary to give people the chance to work more professionally when
> reading or writing mathematical content.
>
> --
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly or view it on GitHub:
> #11467 (comment)
|
@gregjozk wrote:
They had to be removed in order not to break ordinal numbers for Portuguese, Spanish and probably other languages. |
Hello again,
sorry for spamming.
first of all, thanks for your good work.
I just suggest for consistency and historic reasons, that all symbols
were written with lowercase as first letter. as I see there are math
symbols, which are uppercased.
best regards,
Jožef
2020-08-17 23:16 GMT+02.00, J.G <[email protected]>:
… Another way to solve such problems could be a new checkbox in the
interpunctuation dialog in NVDA which allows you to use synthesizer's
pronounciation or not. If disabled, NVDA would pronounce the symbol as
it is in the symols.dic, and if it is enabled NVDA would pronounce it
as it comes from the synthesizer, ignoring the patern in the
symbols.dic.
it has already been implemented. see section speech in preferences of
NVDA and option Trust voice's language when processing characters and
symbols
according to userguide:
Trust voice's language when processing characters and symbols
On by default, this option tells NVDA if the current voice's language
can be trusted when processing symbols and characters. If you find
that NVDA is reading punctuation in the wrong language for a
particular synthesizer or voice, you may wish to turn this off to
force NVDA to use its global language setting instead.
2020-08-17 23:08 GMT+02.00, J.G ***@***.***>:
> hello,
>
> for symbols, which are pronounced differently about genders, I used
> neutral description - no masculine, no feminine but neutral; in
> slovenian we have "middle" grammar gender and I used it; also for
> ordinal symbols. so I'm against to remove them.
> and as I know other language, they also have middle grammar gender
> (en-it, de-es etc) and coresponding words to cover ordinal and other
> symbols.
>
> best regards,
> Jožef
>
> 2020-08-17 22:54 GMT+02.00, Adriani90 ***@***.***>:
>> So far I think the work is now complete, these symbols should really
>> cover
>> most use cases out there. Other mathematical use cases can be added
>> later,
>> if there is a clear justification for it.
>> If this PR come into Alpha, this would be great because we need thorough
>> testing with different languages. But my first tests with romanian,
>> german
>> and english did not show pronounciation problems. However, there might
>> be
>> cases where we should decide wether to remove some symbols if NVDA
>> cannot
>> provide a understandable or confortable translation for every language.
>> Then
>> this should be handled by the synthesizers themselves. However, in most
>> cases I found the pronounciations from the synthesizers very bad and
>> actually not really correct, so I decided to take them in the NVDA's
>> dictionary to give people the chance to work more professionally when
>> reading or writing mathematical content.
>>
>> --
>> You are receiving this because you are subscribed to this thread.
>> Reply to this email directly or view it on GitHub:
>> #11467 (comment)
>
|
@gregjozk wrote:
This option enforces symbols to be announced with the language of NVDA rather than the voice language, but it does not solve the issue of symbols being inherited from English even if not defined in the file for the given language. |
This option enforces symbols to be announced with the language of NVDA
rather than the voice language, but it does not solve the issue of
symbols being inherited from English even if not defined in the file
for the given language.
ah ok. thanks. Obviously I was on a wrong road, but, when I used this
option, slovenian voyces and synths has not been problematic, so I
heard description from symols.dic.
regards,
Jožef
2020-08-17 23:27 GMT+02.00, Łukasz Golonka <[email protected]>:
… @gregjozk wrote:
> Another way to solve such problems could be a new checkbox in the
> interpunctuation dialog in NVDA which allows you to use synthesizer's
> pronounciation or not. If disabled, NVDA would pronounce the symbol as it
> is in the symols.dic, and if it is enabled NVDA would pronounce it as it
> comes from the synthesizer, ignoring the patern in the symbols.dic. it has
> already been implemented. see section speech in preferences of NVDA and
> option Trust voice's language when processing characters and symbols
> according to userguide:
This option enforces symbols to be announced with the language of NVDA
rather than the voice language, but it does not solve the issue of symbols
being inherited from English even if not defined in the file for the given
language.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#11467 (comment)
|
If your NVDA language matches language of the voice in use there is no change in behaviour regardless if this option is checked or not. |
If your NVDA language matches language of the voice in use there is no
change in behaviour regardless if this option is checked or not.
I apologise, you are correct.
I made a mistake, when testing it with non-slovenian synth.
again, I'm very sorry.
2020-08-17 23:37 GMT+02.00, Łukasz Golonka <[email protected]>:
…>
> This option enforces symbols to be announced with the language of NVDA
> rather than the voice language, but it does not solve the issue of symbols
> being inherited from English even if not defined in the file for the given
> language. ah ok. thanks. Obviously I was on a wrong road, but, when I used
> this option, slovenian voyces and synths has not been problematic, so I
> heard description from symols.dic.
If your NVDA language matches language of the voice in use there is no
change in behaviour regardless if this option is checked or not.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#11467 (comment)
|
…incremental symbol to avoid confusions and improved consistency in ortographics)
source/locale/en/symbols.dic
Outdated
# Miscellaneous Technical | ||
⌘ Mac Command key none | ||
⌘ mac Command key none |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this has been changed?
Some synths pronounce it very strange if the first letter is a capital letter, so I changed it to small m. This is consistent with all lines above
Von meinem iPhone gesendet
… Am 18.08.2020 um 08:16 schrieb Łukasz Golonka ***@***.***>:
@lukaszgo1 commented on this pull request.
In source/locale/en/symbols.dic:
> # Miscellaneous Technical
-⌘ Mac Command key none
+⌘ mac Command key none
Why this has been changed?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
@Adriani90 wrote:
None of the symbols above starts with a brand name, therefore I believe this one should be an exception and start with a capital m. |
There are also symbols like Beth number, Aleph number or Wreath product which are also always written with capital letter, I still think we should maintain small letters here to make sure that no synthesizer is pronouncing things in a wrong way. We can change that back to capital letters if someone has a justification that it would improve pronounciation, but I don't think this will be the case. |
@feerrenrut I think all the feedback has been addressed so far. |
@feerrenrut maybe this is worthy to look to again, conflicts are solved. Basically it restructures the symbols.dic in a more convenient way and adds most coomon math symbols. |
- delete extra tab - remove duplicate symbol definition
- deleted extra tab - removed duplicate symbol definition
Uh! I just realize looking at translators e-mails and comments that the diff takes the whole symbol file, even taking lines that have not been modified (file header, last line with mac key symbol, etc.). @feerrenrut, @michaelDCurran, @seanbudd: |
I've just translated this file to one of my languages.
|
@CyrilleB79 I don't think there is anything we can do at this stage. Reverting or restoring the line endings would just result in another full file diff, right? It would be helpful if you could share advice to translators on how to manually diff ignoring whitespace. |
I have just sent a message to the translator mailing list and have attached the diff ignoring line ending if it may help translators. |
Link to issue number:
none
Summary of the issue:
Many mathematical symbols are not included in NVDA and thus are not pronounced by NVDA. And most mathematical signs had only the positive but not the negative part of it (i.e. equal and not equal to, etc.).
Description of how this pull request fixes the issue:
Added many very usual mathematical symbols which might help users who are involved in mathematical operations in their day to day work or studies.
However, the symbols list is not complete yet but it should cover already most practical use cases.
Testing performed:
Tested with eSpeak that the coresponding symbols are recognized.
Known issues with pull request:
None
Change log entry:
Changes: