Any interest in localization for MathJax's menus?

[Brion Vibber]

Something which came up for Wikipedia/MediaWiki's use: we provide service in many languages, and try to have our user interfaces localized. MathJax's menus and status messages currently seem to be hardcoded for English.

When we take a tool like MathJax and integrate it, we like to help with localization if it's not already done... would there be any interest in making the menus and status messages localizable? If we can work out a clean way to store the strings, we could probably get you guys set up with TranslateWiki.net to maintain the translations.

-- brion vibber (brion @ pobox.com / brion @ wikimedia.org)

[Thomas Leathrum]

Count me in as someone interested in helping.  I took a quick look at the code in MathMenu.js where the menu strings are coded (you're right, they're hard-coded), and I'm thinking that it shouldn't be too hard to pull those strings out into a JSON file -- is that a resource format with which you can work comfortably?  We could even set it up to default to English if the JSON isn't there....  I'm not sure that the changes could go onto the CDN any time soon, but we could make a special MathMenu.js for Wikipedia purposes.

[Paul Topping]

I agree that localization is an important thing. Now that 2.0 is (mostly) behind us, we should start making a list of things to tackle for the next version. UI localization should be on the list.

 

Since there are a lot of languages and customers have a habit of wanting to customize UI anyway, we should make it something that can start small and grow. We would want to make it easy for MathJax users to localize it in new languages and contribute them back to the MathJax Consortium.

 

Paul

[Thomas Leathrum]

On one hand, the first iteration of localization would be just setting up the JSON (or whatever format Wikipedia needs) and letting translators replace the JSON with their own version in a local install.  I think this much can be done quickly without disrupting the current CDN.  A really clever implementation would be to allow multiple JSON files, perhaps with the locale included in the filename (e.g. "MenuStrings_en_US.json") and provide a submenu that lets the user select a locale (defaulting to the browser's locale, if that is defined and the corresponding JSON is available, otherwise English).  This is the sort of thing that would be nice in a future version on the CDN.  I have done localizations before on my Java applets (using Java .resource files), so I do have some idea what this will require.

On Wednesday, March 7, 2012 4:17:12 PM UTC-6, Paul Topping wrote:

I agree that localization is an important thing. Now that 2.0 is (mostly) behind us, we should start making a list of things to tackle for the next version. UI localization should be on the list.

 

Since there are a lot of languages and customers have a habit of wanting to customize UI anyway, we should make it something that can start small and grow. We would want to make it easy for MathJax users to localize it in new languages and contribute them back to the MathJax Consortium.

 

Paul

 

Sent: Wednesday, March 07, 2012 2:11 PM

Subject: [mathjax-users] Re: Any interest in localization for MathJax's menus?

[Frédéric WANG]

Yes, lack of I18N possibility was one thing that surprised me when I started to get involved in the MathJax project. But I think the strings to localize are not only for the MathJax menus but that there are various places in the code where messages are hardcoded. Also we should not only make our own javascript files localizable but maybe add something in the MathJax API to help creating and using localizable strings and suggest authors of MathJax extensions to use this API.

-- 
Frédéric Wang
maths-informatique-jeux.com/blog/frederic

[Paul Topping]

This is really a mathjax-dev issue but …

 

I would like to see us gather our requirements together for new features like this one before diving headfirst into solutions and coding. Now that MathJax is relatively mature, a lot of what we need to do going forward will be driven by outside requirements. Localization is a perfect example of this. We understand the issue of course but we need to know specifically what our solution needs to do for the customers. If we are doing something less than an ultimate solution, knowing how it needs to enhanced in future can help us make wise choices now.

 

Paul

[Thomas Leathrum]

Paul --

I agree, of course, which is why I was suggesting that initial versions of internationalization happen outside the development trunk destined for the CDN, at least for a while.  A similar recent example was the request from the SAGE group that the contextual menu be launched by a double-click.  In some cases, it might be possible to add new features through an extension, and for that purpose I have stared maintaining the contributed extensions repository, but realistically I don't expect many of those special features to make it into the CDN version even in the future because the use cases are so specialized.  However, in a case like this internationalization, I don't think it could be managed with an extension like the other contributed extensions, so instead I think a specialized version of MathMenu.js for the Wikipedia integration is the fastest way to get them what they want with the current MJ version.  We can consider integrating this feature into a future version of MJ when we see how the feature develops and matures itself.  I suppose what I am suggesting for situations like this is some sort of a separate "incubator" for developing and testing features, then deciding whether it is worth pulling them into future CDN versions.  This way, the feature set (and documentation, client expectations, etc.) for the CDN version can stay stable while ideas are being developed on a parallel track.  I don't think it makes sense to try to develop a whole new set of features for the next CDN version without having somewhere to conduct some coding experiments to see how a new feature will work out.

[Paul Topping]

Tom,

 

While you say you agree, what you say here seems to be almost the opposite of what I am advocating. I believe the incubation process you are talking about makes sense when we are unsure of what is needed and whether the software will do the job or it is somehow deemed experimental. What I am talking about is figuring out what the community needs and then implementing it.

 

I don’t believe localization is that hard and it is evident that we have several people that know about it. MathJax is also already in use by publishers that are probably care about localization. In fact, this is how this thread got started. All that is needed is to gather requirements in a slightly more formal way than in an email thread with a random set of participants and then implementing it. Since the people that contribute the requirements are also interested in the resulting code, they will help make sure our solution is what is needed and this may result in adjustments before its official release.

 

Paul

 

From: mathja...@googlegroups.com [mailto:mathja...@googlegroups.com] On Behalf Of Thomas Leathrum
Sent: Thursday, March 08, 2012 8:21 AM
To: mathja...@googlegroups.com
Subject: Re: [mathjax-users] Re: Any interest in localization for MathJax's menus?

 

Paul --

[Thomas Leathrum]

Paul --

No, all I am suggesting is that there be more to the "and then implementing it" stage than you imply.  I am suggesting a kind of feedback loop with users and clients.  When we hear a feature suggestion such as this, there is necessarily an experimental stage while the feature is implemented and tested -- the question is how public that process is.  I think we do ourselves and everyone else a disservice if we don't let feedback from users and clients guide the development of a new feature, even before beta testing stage.  This is why I asked at the beginning of this thread what format the Wikipedia people would find comfortable for internationalization resources -- I don't think it makes sense to even begin coding until we know basic stuff like that.  On the other hand, once we have the basic information, we can't dump a fully-implemented final form feature on them and expect them to be happy with it -- we need to build a basic implementation, get feedback, and modify as needed (lather, rinse, repeat).  Some sort of "incubator" would be a place where these experiments and feedback can happen in isolation from the CDN.  As with the contributed extensions repository, I don't expect every experiment to lead to a feature in the next version -- quite the contrary, many of the experiments would lead down blind alleys, which is another reason to keep the CDN separate from this.  In the meantime, if the experiment leads to a custom version of MJ2.0 for Wikipedia that satisfies their needs now and we look at implementing the feature for MJ3.0, the Wikipedia people may be more likely to adopt MJ3.0 when it comes out because they already know about the new feature they asked for.  Do we really want to tell Wikipedia "sorry, MJ2.0 doesn't do this, but we will put it on the list for MJ3.0 -- ask again in about a year"?  I don't think the Wikipedia people would be happy with such a response from us.  Yes, we need to talk to the community and see what features are important, but we can't just put the suggestions on a list and say we will do them in the next version.

[Paul Topping]

Tom,

 

Let’s restrict this discussion to localization in order to make it more concrete.

 

We certainly should talk to Wikipedia about their localization needs and, as far as I know, the suggested solutions might well be good ones. However, we should not assume that Wikipedia’s needs for localization are the same as everyone else’s and just implement them with the hope that other’s needs can be folded in as they are discovered. That is just too inefficient and unnecessarily so.

 

We know that many organizations are interested in localization so we should gather requirements from all of them. Wikipedia might be first to have the conversation with and, after it is all over, they may even be the most helpful. That is neither here nor there. I am advocating a process that is more democratic and avoids implementing the first solution that comes to mind based on a design discussion had with a single customer in an email thread.

 

No one would dispute that, in general, there will be a wash-rinse-repeat cycle once a feature is added. That process always happens. The fact that an implemented solution will be always be subject to later criticism and revision is never an excuse not to do a proper job of requirements gathering and design up front.

 

This discussion reminds me of ones I have had many times over the years with people who come into software development from another field where they started writing code as a side project. In such projects it often makes sense to implement something and see how others like it and adjust accordingly. As the software operation grows larger and has more customers that have a substantial investment in the product, this becomes less and less viable.

 

I am not arguing to make a federal case out of this project, just advocating a little more gathering of input, making a list of explicit requirements, all before implementing something. Sometimes experimental implementation can be part of this but only to find out feasibility of some technology. I don’t think localization needs such experimentation. It is mostly just a matter of deciding what a localization feature needs to do.

 

Paul

 

From: mathja...@googlegroups.com [mailto:mathja...@googlegroups.com] On Behalf Of Thomas Leathrum
Sent: Thursday, March 08, 2012 11:08 AM
To: mathja...@googlegroups.com
Subject: Re: [mathjax-users] Re: Any interest in localization for MathJax's menus?

 

Paul --

[Thomas Leathrum]

I have written an extension and placed it on the contributed extensions repository which implements a string-substitution scheme for the labels in the MathJax contextual menu -- the point being to allow for easily-configured internationalization of the menu.  Since this thread is a few weeks old and wandered a bit at the end, I am going to start a new thread with the link and more information about the extension.