Internationalization of WeBWorK -- A Call for Help

First  a short news item:  Those not in the US have long remarked on the confusion caused by due dates such as:   06/07/2012   for their students.  Is that the 7th of June or the 6th of July that the homework is due?   

Danny Glin from the University of Calgary (and one of the participants at WeBWorK::Rochester::2012 code camp) has come to the rescue and created the ability to customize the format for dates for your site or for your course.

The customization takes place in the conf/ localOverrides.conf or if you want to customize only one course  the course.conf file.  The new software is available in the webwork repository at github.com/openwebwork/webwork2-dev.  


Thanks, Danny.


This fix is currently part of the 2.5.1 beta version of WeBWorK which will be issued as a stable release some time in late 2012.  It is already pretty stable and is being used successfully at many sites this summer.  Eventually we'll make it possible to choose common time formats from the course administration page, but we'll take this one step at a time.


And this brings me to the larger issue of this post.


WeBWorK is going international.  We already have much of the WeBWorK interface localized so that commands appear in any of several languages such as French, Spanish, Turkish and English.  (Localization is software-speak for presenting the user interface in the local language, with the local timezones and the local manner of expressing dates, currencies and so forth.)  


The project is far from  completed in these languages (if you switch to languages other than English on the course configuration page you will still notice that some of the buttons and links still appear in English) but there has been significant progress.  Much of this progress is thanks to the initial work by Ben Walter and his colleagues at the Middle East Technical University in Northern Cyprus. Since then Grant He with some help from me has continued to markup large parts of the current code base
so that the "strings" can be individually translated and presented in any language.  Those using old versions of WeBWorK can see the internationalization effect for themselves by using the demo courses at https://hosted2.webwork.rochester.edu/webwork2/maa101, (maa102, etc) and using profa for login and profa for the password.  


To finish this task and change the internationalization of WeBWorK from its current proof-of-concept stage to a finished and polished product  will take a focused and sustained effort.  The initial burst of progress came from massive and enthusiastic effort from a few people, but to  make sure that every phrase has been marked for translation and that every translation has been checked for colloquial accuracy will require more organization.

This is what I think will be required:  (1) We will need people to volunteer to work to translate phrases from English to their native language.  (2) We will need one or two people who are familiar (or willing to become familiar )  with the perl language who will continue to mark up old (and sometimes new code) to make sure that all strings, including commands, buttons, warning strings, directions and so forth are properly marked up so that the strings can be sent to the translators.

 (3) Most importantly we'll need an Internationalization Coordinator, one person or two people working together, who will  be the central organizers for localization.  The Internationalization Coordinator will recruit translators, see that they have up-to-date lists of strings to be translated, (bug them until they get around to translating them) and then place the translated strings into the WeBWorK releases so that new languages or upgraded translations for old languages are available for all users of WeBWorK.

 Volunteers interested in helping WeBWorK thrive and grow internationally by serving for a term as the Internationalization Coordinator should contact Mike Gage (gage@math.rochester.edu) or  Jason Aubrey (aubreyja@missouri.edu)  The Internationalization Coordinator has duties similar in many ways to that of a a journal editor, although probably not as time consuming.

While the central organizing job does not involve a lot of time (it's mostly about making it possible for others to do work) it does need to be done on a steady and sustained basis.  For example when new translations come in they need to be promptly placed where they can be downloaded to update active sites. This is both for the sake of WeBWorK students and to encourage the translator to review their work and make corrections by giving them rapid feedback.   I've been fulfilling this role to some extent, but while a lot might get done over one  short period other WeBWorK issues will distract me, submissions will pile up and the whole translation process slows down. This job needs a person who can take it on as their mission, make it the focus of their attention for a year or so and then pass it on to someone else.


Preliminary instructions for the translator job are at http://webwork.maa.org/wiki/Instructions_for_translators.  Translating is a task that many people can contribute to in their spare time with the Internationalization Coordinator keeping track of what is
left to be done.  The best software I've found so far for this job is the open source Poedit java applet described on the wiki page above.

Marking up the code using the CPAN  Localization::Maketext::Simple package is a slightly more technical job that can be done well by undergraduates with some supervision.  Preliminary instructions about using the CPAN module can be found linked to http://webwork.maa.org/wiki/Localization. Those writing new interface code for WeBWorK should also look at this page and include the "maketext()" markups as they write the new code in order to ease the work load of the code mark up crew.


There is general information on the localization process on the wiki at http://webwork.maa.org/wiki/Localization.




Writing or translating homework problems into other languages is a separate project which is  closely tied to the new Open Problem Library project.  We currently know of collections of problems in French, Spanish and Turkish that we hope to include in the OPL.  As the number of problems, and the number of languages increases this project will undoubtedly require its own coordinator.  Some have already remarked that it will be interesting to compare calculus homework problems across countries since even calculus problems will probably have cultural differences as well as linguistic ones.




-- Mike
 

WeBWorK Open Problem Library 3.0

As Djun Kim mentions in his post the National Problem Library, having grown beyond one language and one country, is now the WeBWorK Open Problem Library (or OPL for short).

Adding problems in new languages,  allowing publishers to include their problems in the library and improving the search facilities so that you can find the type of problem you want faster than you can write it yourself are going to required a dedicated effort.

Schemes need to be devised for attaching metadata to the problems (automatically when possible) and software for weeding out near duplicates needs to be developed.  In addition we need procedures for new submissions that both makes it easier to submit your favorite problem or your fix of a problem with errors but also allow for a system of checks and balances that guarantees that the submitted problems meet certain standards.

Since we will probably never all agree on what makes a "high quality" problem we also need some kind of rating mechanism that will help instructors find the problems that fit their course and teaching style.

It's a tall order.

Fortunately a few members of the WeBWorK community have volunteered to take the lead in devising OPL 3.0 which will meet all of these criteria.  They are Djun Kim at University of British Columbia; John Jones, who was involved in creating the original NPL, at Arizona State University; Dick Lane at University of Montana, George Jennings at California State University at Domincan Hills and Tyler Dzuba, a science librarian at the University of Rochester with experience in metadata and digital library design.  Anyone else interested in working on the project should contact one of these leaders.

Some of the early discussion is already taking place on the webwork-devel mailing list
( http://webwork.maa.org/mailman/listinfo/webwork-devel ).  As consensus emerges summaries will be posted on the wiki in the section for developers for further comments.  (A search of OPL should bring up most of the relevant information.)

Thanks very much Djun, John, Dick, George and Tyler for taking the lead in this important project.
Improving the usefulness of the OPL is one of the most requested features that has come up in our surveys of WeBWorK users.

The library group is just the first team arising from our intent to bring focus to the various active projects being developed within the WeBWorK community:

My next post will concern our attempt to bring focus
to the "internationalization" or as it's called in software speak "localization" effort for WeBWorK.  This involves making the WeBWorK application itself work in a many languages in a convenient and sustainable way and the solicitation of WeBWorK problems written in many languages.

-- Mike

Summary for WeBWorK::Rochester::2012

Summary for WeBWorK::Rochester::2012   

The WeBWorK::Rochester code camp, focused on user interface improvements, was held at Rochester from June 6th through June 9th, 2012.  It was a great success.  This was the first working gathering of WeBWorK developers since our summer 2007 meeting at AIM (American Institute of Mathematics); we hope it will kick start a spate of development over the summer on the look and feel of WeBWorK.  In conjunction with PREP courses last summer and two additional code camps this summer, we hope to flatten the learning curve significantly for new users of WeBWorK and to improve the overall usability of the system.

We have a lot to report, including significant progress in WeBWorK interface design, new and developing infrastructure procedures for supporting WeBWorK users and developers, discussion about the social structure of the openWeBWorK development community, and a report on our collaboration with the Teaching Open Source organization through their POSSE workshop at RIT.  

Oh yes -- and since WeBWorK now has contributions in more than one language and from several countries -- we changed the name of the National Problem Library to the WeBWorK Open Problem Library (WOPL) or Open Problem Library for short.  More on that later -- it was quite a discussion!

If you are really impatient, you can stop reading and go explore the new stuff, bugs and all, at https://hosted2.webwork.rochester.edu/webwork2/maa101 (or maa102, etc). Sign in as profa and use profa as the password.  Use your iPad!!!! -- it’s not pretty yet but it works!!!

Below we’ll first describe the daily progression of the code camp for those who weren’t there, and especially for those who haven’t participated in previous code camps.  They are intense experiences.  A lot can get done; it’s hard work, but it’s also fun and satisfying.  

We’d like to encourage others to plan and hold local code camps to work on aspects of WeBWorK that they would like to develop.  No permission is needed from any central WeBWorK authorities, but those of us who have been doing this for a while will be glad to help out in any way we can.  Let us know.

At the end of this note we’ll list specific accomplishments (deliverables :-) ) for the week.

As a last item before describing our meeting, here is the list of WeBWorK events scheduled to  take place this summer and fall.  We hope to see you at one or more of them. Keep track of the events section in the wiki (http://webwork.maa.org/wiki) for new additions.

• WeBWorK::Clinton - June 20-22, 2012 (John Travis)
• WeBWorK Consultants Workshop - August 1, 2012 (Arnie Pizer)
• Mathfest Exhibit Presentations - August 2-4, 2012 (John Travis and Jason Aubrey)
• WeBWorK::Winona - August 5-8, 2012 (Jason Aubrey and John Travis)
• MAA JMM Mini Course - January 8-10, 2013 (Joint Math Meeting in San Diego ) (Jason Aubrey and John Travis)

First post from the POSSE 2012 meeting at RIT

WebWork events - 2012-2013

WebWork::Rochester - June 6-10, 2012 (Mike Gage)
WebWork::Clinton - June 20-22, 2012 (John Travis)
Mathfest Exhibit Presentations - August 2-4, 2012 (John Travis and Jason Aubrey)
WebWork Consutant’s Workshop - August 1, 2012 (Arnie Pizer)
WebWork::Winona - August 5-8, 2012 (Jason Aubrey and John Travis)
MAA JMM Mini Course - January 8-10, 2013 (Jason Aubrey and John Travis)


We will be starting the WeBWorK::Rochester code camp on Wednesday.
We will be cooperating on some projects with the POSSE workshop.


The IRC channel is #webwork on freenode.irc.net
The homepage/wiki for WeBWorK is https://webwork.maa.org/wiki
The stable source for WeBWorK is at github.com/openwebwork (projects webwork2 and pg)
Bleeding edge code will be hosted at github.com/mgage (projects webwork2 and pg) and at other developers sites on github.


Stay tuned for more information as the WeBWorK::Rochester code camp progresses.


For those interested in seeing the latest version of WeBWorK in action you can view the courses
at


https://hosted2.webwork.rochester.edu/webwork2/maa101, maa102, maa103, etc.


Use profa for login and profa for password to see the instructor view.


Use jsmith/jsmith for the student view.


check out the new "game badges" designed by Geoff Goehle. (see the Achievements and AchievementsEditor links)

For a recent history of WeBWorK development go to
http://zmoazeni.github.com/gitspective/ and type in mgage

Questions on using open source in classrooms:

1. How does "the open source way" apply to your course work?

Developing open source software doesn't seem to apply directly to mathematics
courses, however at U. of Rochester math department we use WeBWorK extensively for homework.
I will be teaching numerical analysis (really numerical
methods for mathematical engineering)  next semester and will probably use Sage for
at least a few exercises.  There are a few other professors using Sage in their research in number
theory so contributing to this open source project might spread sideways in
the math department.

2. How will you incorporate what you have learned here in your course?

What I've learned about building packages will be used in the near future to make the server component
of WeBWorK much easier to setup.  This has been a barrier to using WeBWorK
and some universities and is likely to be a bigger barrier when encouraging its use
in high schools.

Much of WeBWorK has been developed with the aid of undergraduate programmers and that
will continue.  This won't involve class work per se but it will be part of a few undergraduates' experience.

3. Any feedback/comments on POSSE itself you would like to add?

As one of the creators of the open source on line homework system WeBWorK

I was interested in finding how other open source communities work.  This POSSE

has been very useful in that regard.  I think the CommArch exercise is very useful and enlightening 

and will probably try to work through it for other math open source projects -- moodle, sage,

geogebra.

Being able to meet people involved in other open source projects at this POSSE and at the

sagedays31 earlier this summer has been a very valuable experience.  It's very interesting

to see the diversity in open source communities.

Michael Gage
Professor of Mathematics
Department of Mathematics
University of Rochester

Succeeded in creating a build tree for a WeBWorK rpm package on fedora.  The build tree compiles now  and produces an rpm package.  Testing the package to insure that it does what it's supposed to will have to wait until week after next.  The package is also not yet feature complete.  Adding a configuration script to the .spec file should not be that hard however since it is essentially a .bash script.

Thanks to the rest of the guys helping out with webwork and to Chris Tyler in particular for guiding us through the build sequence.

Creating an RPM for WeBWorK

Chris Tyler gave us the outline of the procedure for creating an RPM for fedora (and relatives). Similar procedures can probably be followed for ubunutu.  How does the creation of .dmg files for MacOS compare?

Here is the outline:

(1) run rpmdev-setuptree to create ~/rpmbuild and subdirectories

(2) place the source code in ~/rpmbuild/SOURCES

(3) cd ~/rpmbuild/SPECS

(4) create a skeleton spec file: rpmdev-newspec NAMEOFPACKAGE

(5) edit the spec file as appropriate

(6) build the package: rpmbuild -ba *.spec
followed by links to some tutorials:

http://fedoraproject.org/wiki/How_to_create_an_RPM_package

http://fedoraproject.org/wiki/A_Short_RPM_Tutorial

------------------------------------------------

Since we have tarballs on sourceforge  grabbing the WeBWorK files is fairly straightforward.  Because we have been training the WeBWorK community to use svn in order to obtain just-in-time bug fixes, the tarballs have fallen a bit behind the current code base and our rpm will be a bit out of date.  This should not be too bad however since using svn after installing the package will update the code. (It will not however load any new CPAN modules that are required.)

The biggest problem was finding corresponding names for the CPAN modules that are required by WeBWorK.  There is a reasonably up-to-date list in webwork2/bin/check_modules.pl which is used to troubleshoot new webwork installations. 

Replacing :: by -  and  prepending   perl- to the cpan package name worked in most cases to find the fedora package.  Documentation is at http://fedoraproject.org/wiki/Packaging:NamingGuidelines#AddonPerl
The naming scheme will be different in other distros.  Is there a tool for translating package names from one distro to another?

We'll try building this later today on the england.proximity machine.  Preliminary attempts were blocked with errors which we'll try to work through.  One downside to this current procedure seems to be that you'll need half a dozen computers and operating systems to create packages for distribution.  Presumably this could be done on a virtual machine.