After bug fixes a translation server must be upgraded. How can we make this easier? What steps are needed?

What happens when five thousand, ten thousand or twenty thousand people use an internationalized OpenACS system?

The new versions of AOLServer have seen some internationalization work. What is needed to make the standard AOLServer run with an internationalized OpenACS? When collaborating using the internet, timezones can play an important role. This work has been started but needs to be finished.

This data needs to be moved into the message catalog so that they can be set by translators, and shared between installations just like other translation data, without having to edit a software library file.

We need to be able to choose adp:s based on locale (i.e. index.en_US.adp and index.de_DE.adp) Internationalization of email send/receive (NEED HELP)

Translation UI enhancements and fixes as asked for by translators Usability testing with professional translators made the following needs clear:

A better way to find the context of terms and phrases that are difficult to find in the WYSIWYG translation mode. (NEED HELP) Additional translation UI enhancements

Permissions per locale (NEED HELP)

Managment of language packs (NEED HELP)

Separation between a translation and a production system (NEED HELP)

UI for i18n of dotLRN prettynames (NEED HELP)

This requires changing the way package parameters are handled. Internationalize forms and form widgets in acs-templating (NEED HELP)