You create a group. The group has the name "Malte's Friends". You have an international site. The spanish person should see the group as "Malte's Amigos" and the German one as "Maltes Freunde". This is impossible as of now.
You create a dynamic attribute. It is called "customer". In an international site it is impossible to have the Attribute named "Customer" if you deal with German "Kunden".
In general there are a *LOT* of places where we store a "pretty_name" or a "label" in the database. As the name suggests (pretty_name) this is something that is displayed to the user. Anything that is displayed to the user needs to be I18N, otherwise OpenACS will not be a really international piece of software.
My method (which, due to the fact that the TIP got two yes and no no's within one week is already implemented on HEAD with some packages depending on it) allows you to use the lang::util::convert_to_i18n function to store an internationalized version of the string instead of the string itself. This way you can translate the string. It is smart enought to not I18N a string that is already I18N ready.
The acs-translation package is only a placeholder for the translations, we could store it anywhere. And yes, this package acts as a way to internationlize *content*, though the content it is trying to I18N are short "pretty_names" or "labels", and the TIP only proposes to add the dependency from acs-lang to acs-translations so that lang::util::convert_to_i18n actually works and packages like contacts or acs-subsite can make good use of it.
