Of course, globalization isn't just language, as Jon points out acs-references contains data necessary for other globalization issues.
Timezone, for instance. The current acs-datetime package has hooks for timezones but makes no use of them. Whatever is done on the language front, OpenACS 4 should become timezone-aware. Given that the core stuff's centralized in acs-datetime (thought clients like Calendar need to know how to display them and allow for selection, too) it shouldn't be too difficult.
That would be a nice, isolated, reasonably-sized task for someone.
Of course OF's been making changes to Calendar for dotLRN and has mumbled about it and acs-datetime having an overly complex datamodel and calendar itself being rather poorly implemented.
Perhaps Yon can summarize the changes OF has made? Did OF tackle incorporating timezone stuff?
Then there's currency ... the form builder has some minimal support for currency. You can build anything that can be represented with a leading symbol (blank allowed), whole part, separator, fractional part, and trailing symbol (blank allowed). There are tools to cast from sql_number to the form builder's list format. The currency form builder datatype was broken in ACS 4.2 but I've fixed it in OpenACS 4.5, though it's still very minimal in capability.
So ... we do have some of the building blocks for non-language globalization issues, too ...
