Let's elaborate on point 3 while I'm trying to work this out. I'm trying to work out how you could get strings out of SQL without having to go through a separate DB call (i.e. the module asks for a list of objects already localized, not with pointers that need to be resolved first in order to get the strings). My fear is that we would need to pass the whole locale chain to SQL:
User's language: System.Threading.Thread.CurrentThread.CurrentCulture.ToString.ToLower
Fallback language: DotNetNuke.Services.Localization.Localization.GetSupportedLocales(userLanguage).Fallback.ToLower
Generic Language: System.Threading.Thread.CurrentThread.CurrentCulture.TwoLetterISOLanguageName.ToLower
Portal Language: PortalSettings.DefaultLanguage.ToLower
If you'd need to pass all these as parameters into SQL that would lead to huge procedure signatures. However, considering you can define FUNCTIONS in SQL you might do some of this within the database and cut back on parameters. Let me explain.
Let's assume that the locale field is NULL for default portal locale. Then we could try to find the right string as follows:
1. Is there a string for the current context locale (e.g. es-ES)?
2. Is there a string for the generic locale (i.e. es)?
3. Is there a string for a good alternative (e.g. es-MX)?
4. Finally: get the default locale (i.e. locale = NULL)
This could be implemented in SQL by passing just 1 parameter: the context locale. Then you would call your SPROC as GetMyObjects(ModuleId, Locale) and your SQL would use a function GetString(ModuleId, 'Obj'+ObjectId, Locale) and get the string.
Peter