phetsims / calculus-grapher

"Calculus Grapher" is an educational simulation in HTML5, by PhET Interactive Simulations.
GNU General Public License v3.0
4 stars 4 forks source link

Translation of integral and derivative notation #24

Closed amanda-phet closed 2 years ago

amanda-phet commented 4 years ago

I asked Isam for his opinion over slack, and he went above and beyond to also get responses from some colleagues. I also followed up with Isham, our translator (or perhaps just a contact) from KSU in Saudi Arabia. Here are the responses:


[Oman]: Many, if not most, of Arabic-speaking countries use the Arabic version of these symbols (by the way, in the Arabic version the integral sign is a a mirror reflection of the English version, see https://en.wikipedia.org/wiki/Modern_Arabic_mathematical_notation, go to “Calculus” section). Some countries (like mine) have opted to use mostly the same English math symbols but with explanations remaining in Arabic (it looks in some places they kept using the Arabic notation).

[Algeria]: In Algeria, a national policy of arabisation started in the 80s and 90s made science subjects (prior to University) in the Arabic language (it was exclusively in French before that) but the symbols have not been arabised. They still use x,y, log, sin, etc..

[Urdu (Pakistan)]: In Pakistan, up to secondary level we have two systems: i) Urdu medium; ii) English medium. After secondary level all join English medium. Up to secondary level (I studied in urdu medium), we studied Mathematics and Geometry exactly like students study in Arabic. We write urdu from right to left (Like Arabic), both languages have identical alphabets. So up to secondary level we used arabic alphabets to express unknowns instead of x, y, z, ....and same symbols for addition, subtraction, multiplication and division. As regards to symbols of integration, differentiation, sigma ..... are concerned we adopt from English.

[Morocco]: Regarding your question about mathematical notation, there are three periods: Long time back, science, including math, was in French (similar notation than in english). In the second period, the education changed to Arabic. The text was written in Arabic but the notations were in French. Last year, they came back to French again because they found that there are not many arabic books/references at the University level.

[Saudi Arabia]: Although it seems that some countries are moving to let the symbols and letters in Math to be in English, especially in school textbooks, it makes sense to allow letters and symbols to be translated, such as x, d, f,and yes the layout needs to be mirrored as well.


So, while there is not consensus, I think this confirms that we should try to allow not just the symbols to be translated, but also allow the option to mirror the integral and derivative notation. I suppose we would need some kind of option for the translator to select the mirroring option when they are also allowing the letters and symbols to be translated.

brandonLi8 commented 4 years ago

My initial thinking is that we might need to "flip" (scaleX(-1)) certain parts of the string and not other parts (since symbols will be translated to rtl and we don't want to flip the flipped string).

I also don't think that mirroring the integral/derivative notation necessarily matches the Arabic math notation described in https://en.wikipedia.org/wiki/Modern_Arabic_mathematical_notation. Specifically derivatives and second derivatives (not the partial derivative): image

I'm wondering if:

  1. translators had access to the entire LaTeX-style string. For instance, integrals are expressed as \int_{0}^x f(x) dx, and the translator would be able to format for rtl languages in the formula.
    1. There was even a way to express a reverse integrals within LaTeX-style strings (for FormulaNode) without having to mirror the Node.
pixelzoom commented 2 years ago

@amanda-phet @kathy-phet We're running into problem with this right now in https://github.com/phetsims/calculus-grapher/issues/70#issuecomment-1271712729, so need a relatively high-priority reply.

PhET does not currently have the tools to address this issue, and it's not something that we've addressed in any PhET math sim. We don't even have a way for a sim to know that it's local is LTR vs RTL. In a recent Slack conversation with @arouinfar, we even confirmed that we only translate symbols, not operators, order, etc.

9/26 in Slack#design-sims:

Brett Fiedler We're currently using ABCD as labels for the vertices in Quadrilateral and are trying to determine if the labels should be translatable or if they are symbolic enough in nature. This would be relevant for non-Latin alphabets. I know that there isn't a direct translation for e.g., A into every other alphabet. Have we handled this before in another sim? Is it best to leave it as symbolic and untranslatable or make them translatable and let the translators make the call?

Amy Rouinfar There is precedent for allowing translation these sorts of labels. For example, the A, B, C atom labels in Molecule Polarity. It’s up to the translator whether or not to localize these labels, but it seems like many choose to keep A, B, C. (Including locales with non-Latin alphabets.) (edited)

Chris Malley All of the math sims that I’ve worked on support translation of symbols that could serve as operands in an equation: x, y, etc. Symbols for operators (=,+,-,…) are generally not translatable.

There have been experiments with various 3rd-party packages in other sims, but those didn't get the resource they need to become a general solution, and we have previously decided not to apply those experiments in other sims. KaText is one such package, but while it renders math notation, it does not address dynamic strings, or LTR/RTL (see https://github.com/KaTeX/KaTeX/issues/343).

So... Implementing what is requested in this issue is one piece of a much large "math notation" project. With all of the other prioirties that PhET currently has, my guess is that doing that will not be a priority. So my recomendation is :

@amanda-phet @kathy-phet how would you like to proceed? @arouinfar would love to hear your input too.

kathy-phet commented 2 years ago

@pixelzoom - I agree with your recommendations above.

For this sim, do what we've done in other PhET sims. Make specific symbols translatable, but not the ordering of math notation. Create an epic issue to (longterm) address the lack of support for math notation in PhET sims.

The math notation epic would require explicit funding, and I would say less priority than the epic to deal with internationalization of number in general.

amanda-phet commented 2 years ago

I'm curious why we can't support LTR ordering for math font? How is it different from PhET font, which can be LTR?

I'm fine with your recommendation, I am just curious why "df" couldn't be a string that is handled like other strings that can be mirrored.

veillette commented 2 years ago

The approach @amanda-phet suggests would have work if the simulation was limited to the first derivative.

However, with the second derivative the superscript 2 need to be inserted in. The superscript itself must be located at a different position for RTL and LTR language. Similarly, the integral sign must also have a different orders, be reversed and the upper and lower bounds are positioned differently.

As stated by Brandon in https://github.com/phetsims/calculus-grapher/issues/24#issuecomment-656239171, we cannot merely mirrored the node.

We dont have a general approach for treating LTR math, so all the expressions must be treated one at a time.

pixelzoom commented 2 years ago

@amanda-phet asked:

I'm curious why we can't support LTR ordering for math font? How is it different from PhET font, which can be LTR?

Fonts are not LTR/RTL. Strings are LTR/RTL, and their directionality is handled automatically.

PhET currently does not have a solution that allows us to describe math notation exclusively as a string. We have to assemble the notation using a collection of Nodes, then handle layout using a combination of scenery and manual layout. And there's typically a significant amount of manual layout required in order to make it look satisfactory. If you want to support LTR vs RTL in such cases, then we need to (a) know whether the language is LTR or RTL, implement a layout that is specific for LTR, implement a layout that is specific for RTL, test and maintain both layouts, etc.

veillette commented 2 years ago

We have enough information about how to proceed with Calculus-Grapher.
We will make specific symbols translatable, but not the ordering of math notation.

Closing this issue.