as_items as a table has 5 attributes that need to be internationlized. If I understand you correctly in our case you'd suggest to add 5 columns with procedures for each of the attributes ?
Don't get me wrong, I do like your solution of storing a procedure. Just some understanding problems. So acs_name would hold a list of all the names (or a list of list, with the name and the locale). Or how does the procedure in name_presentation know which list item to choose.
Are you planning on executing the procedure for each acs_object.name display? (assuming you have a list of lists for the name this might be pretty time consuming or am I mistaken)?
as_items will be queried on every single question that is displayed in the system. I'd like to limit the joins done on this table as much as possible. Same goes for as_item_attributes (dynamic attributes added to the item depending on the item_type). We might have to internationlize these attributes as well. Which would be another (expensive ?) join.
I don't think a full-table scan will be executed, but even without a full table scan I think we should try to avoid joins as much as possible.
Last but not least, why can't we store an adp-snippet in the localized content, which allows you to call a procedure if necessary.
One more thing I don't understand. The name of an object contains dynamic data (as your example suggests), is this possible? Or is the name of your object "Listening to MP3s while drinking beer".
As you can see I'm utterly confused what you want to do and how you want to do it. Maybe you can give an example of what you would store in acs_objects.name and acs_object.name_presentation for your example, using a Germany tranlation of "Listening to MP3s while drinking beer".
If you are mainly concerned with presentation, I think we might tackle this using adp-snippets? Or, if we assume we have a presentation of the name (e.g. for the quick categories display), we could have a procedure registered for storing a presentation name dependent on locale *on insert*. This would make sure the language of the locale and the presentation type match (because you only get the german presentation if you have a german locale content for it). For obvious reasons this should go in a seperate column for name_presentation (as the name might be different from the name_presentation string which you want to present as per your example).
Sorry for thinking out loud here:
What do you think of generating an acs_objects_locale table (as described for as_items, including overlaying), add the locale and a name_presentation to acs_objects (and the locale table :)) and insert the name presentation on creation of the object, handled by the package. This way the calendar package would store the name "Listening to MP3s while drinking beer" in acs_objects.name, "Listening to MP3s while drinking beer on 18-March-2004 21:00 - 23:00" in acs_objects.name_presentation, "en_GB" in acs_objects.locale and "18. März 2004, von 21:00 bis 23:00: MP3 Musik hören und Bier trinken" in acs_object_locales.name_presentation and "de_DE" in acs_object_locales.locale. For sure it would insert the german locale *only* if someone translated the the calendar entry name.
As I said, my reasoning behind this is that I don't think it is a good idea to switch the format of a presentation depending on the locale, while keeping the content of the presentation in the original language. But this is just my thinking, please proove me wrong.
I'm really keen on getting more ideas on how to I18N content and I have to admit that I never thought (til reading Dirk's comment) about I18n the *presentation* of the content. That's what happens if you are not dealing with calendar :).
Last but not least, if we could come up with a solution to internationalize names and attributes of objects in a consistent manner that would be useable by all packages, this would be great.
