Mathjax v2.2 feature discussion

For the broader document see Mathjax v2.x potential features discussion

Localization

fredw: A priority for MathJax v2.2, since it is blocker in Wikimedia

For the full requirements and discussion, see MathJax v2.x potential feature: localization

Let's try to boil down how far we can address the requirements in v2.2

• How does MathJax decide which language to use?
  • How much control should the author have?
  • How much control should the visitor have?
  • Can MathJax automatically decide the language?
  • Can other software communicate preferences to MathJax (e.g., AT software, dynamic l11n code)?
  • What happens when the required language is not available?

MathJax will have additional configuration options as well as cookie information on user preferences for locales. Storage and loading of locales will follow the model already in place for configuration files.

The configuration options allows authors to specify a) what language is the default for a page b) if they want to activate a submenu so users switch languages (they can specify a subset of languages) c) if they want to forcibly override user preferences stored in the MathJax cookie.

We will not attempt to auto-detect locales as this is currently not reliably possible with javascript.

Since we want to allow authors to allow users to switch locales, an API will be needed to allow third parties to switch these as well (e.g., in a dynamic "change locale" situation of webcontent).

English will be the fallback language.

• How do we guarantee availability of international characters?
  • How do we deal with non-roman languages?
  • How do we deal with non-Arabic numerals?
  • How do we deal with vertical writing?
  • Do we allow style changes in translations (cf. HTML snippets)? (different language, different need)

Eventually, we will add font-checking features, but for the initial implementation we will rely on system fonts with a wide unicode coverage.

We will need to investigate non-Arabic numerals.

Vertical writing will not be supported for now since vertical writing systems often have horizontal alternatives, e.g., Asian scripts.

• Who makes the translation?
  • Do we have enough complexity to need professional translations?
  • how do we communicate to translators what needs to be translate?

Internally, json seems to be the natural way to deal with the locale information.

Externally (for contributors), we will make sure to offer a file format that is compatible with crowd-sourced platforms such as Transifex or Translate Wiki. The natural candidate is XLIFF; alternative could be PO (common in php projects). For more inspiration see this StackOverflow thread.

• What languages should we deliver out of the box?

We will provide an initial set of translations as large as possible. French and German will be easy via the MathJax Team. The interest of the community (in particular, assuming help from Wikipedia and TranslateWiki) will help us provide a wide range of translations as soon as we've created the format and during the beta cycle.

• How should MathJax extensions be localized?

While an API for extensions will be part of a future release (and hence influence the defensive implementation for v2.2), this is outside the scope of v2.2.

• Can we add translations without making a new release?
  • Where can you find translations?
  • Can you provide private translations?
  • How do we encourage giving translation back?
  • Do we allow alternative or additional translations? (say, redirect to tech support)
  • Do we force CDN users to give their translations back?

The implementation should allow adding translations on the fly. From a practical point of view, we can easily add translations to the latest branch and the CDN, following the vN.Ma release schema.

Locale files will be part of the main MathJax repository but just like configuration files can be loaded from arbitrary locations.

We will encourage contributions by using webservices such as TranslateWiki.

Technical considerations:

• 1 file per language vs multiple files per language

As with the idea of an API for extensions and their locales, MathJax will have to deal with multiple files eventually. The MathJax core locale should be small enough (<100 stringes) to fit in a single file without performance issues.

• defensive programming aspects Apply to
  • MathJax UI strings added in the future
  • API for extensions and their locales
  • security concerns with 3rd party translations

Fonts & Characters

fredw: We will only consider STIX (and perhaps Asana) support in the list below.

• Add STIX and Asana support
  • Create fontdata and webfonts
  • investigate potential for crowdsourcing fontdata generation
• Investigate font mixing/switching, using document font for alpha-numeric characters.
• Investigate Deja Vu fonts (planned "MathML 2.0" support).

TeX input enhancements

• incorporate Davide's amscd code. See issue 420

• investigate a LaTeX2e extra symbols extension.

• offer instiki syntax as input -> not a priority (instiki never exposes its TeX syntax but converts to MathML).

  fred: actually instiki just uses itex2MML and I think has an option to use blahtex. Both tools are open source so the syntax is known. peter: true but we should probably open up another section for "input processors"? fred: it's probably overkill to implement input processors for itex2MML or blahtex. They basically rely on the same LaTeX-like syntax as MathJax TeX input processor. Extensions to add LaTeX commands that are specific to these languages and not included in the default TeX input Jax sound more appropriate. peter: good point. I was also thinking about possibly different syntax, say maple, but that's out of the scope anyway. fred: OK, I was really only talking about instiki here (I guess it does not support maple), but opening a section for other input processor too is fine. I haven't seen requests from users for other input processors, though.

  fredw: So as I read it on the Instiki documentation, the only supported syntax for equations are itex2MML and blahtex and as I said they are Open Source. So the work to do would be to verify if all their LaTeX commands are available in MathJax and add extensions if necessary.

MathML support

Missing features (from the documentation)

• elementary math tags: mstack, mlongdiv, msgroup, msrow, mscarries, and mscarry.
• alignment groups in tables
• right-to-left rendering
• annotation-xml (to include non-mathml content, e.g., svg , (in particular in epub?)) fred: it is already supported, but we could improve the access to the data from the menu. See Usage-of-the-semantics-element and issue 357
• complete table attributes (e.g., columnspan and rowspan)

Other topics

• Improve line-breaking
• Investigate Davide Carlisle's Content to Presentation xslt/javascript solution. See issue 404
  • fred: Perhaps we could do the conversion Content MathML => Presentation MathML in the MathML input Jax processor (maybe making this optional) and not necessarily using the XSLT (not sure whether it is available to all browsers).
  • peter: sure, I don't know where it fits best. From what I can google, all our supported browsers do xslt 1.0 but I have no idea how performance is anyway.
  • fred: if they all support XSLT 1.0 then I think it would be very easy to add a configuration option in the MathML input Jax to call David Carlisle's stylesheet before processing them. Given that content MathML is not a top priority, that would just give a convenient option for authors that need it on their pages without impacting other users. And we don't have to worry too much about performance or imperfect content to presentation mapping, I guess. The idea would be to modify the DOM to have: <math><semantics>[presentation MathML ouput]<annotation-xml encoding="application/mathml-content+xml">[content MathML input]</annotation-xml></semantics></math> (no need to create a new semantics if it already exists).
• Encourage use of <mrow>+<mo> construction instead of <mfenced>. See https://groups.google.com/forum/#!topic/mathjax-dev/GIvpWSNJrgA/discussion and issue 359
  • needs to be fleshed out after dev meeting: focus is on native MathML support. Switching will make NativeMML on Opera worse, but Opera is not on our target list and nativeMML is not suggested on Opera anyway.
  • We can also do this conversion in the NativeMML output for all browsers but Opera.