Hi all. Sorry to be absent for a while. I don't think that we should count on that source forge project. Jan has moved on to other things and I doubt very much if he will be taking time to work on that effort. I can talk about Jan's design if you are keen on rolling the I18N work in. But that will be a lot of work. It touches a huge number of files. If you want to reap the DLM 2.0 efforts I'd suggest using resource bundles like Andrew said for nearly all of the effort. The one problem is with dynamic content like fragment, channel, and tab names. For those you could fall back on just using the names as found on those elements. Ideally, you would choose the API that will be used in the future for all localization/configuration work (like an sup'd up PropertiesManager) and then provide an implementation that just does the element names for now and add in full support for other locales later.
Mark On 7/15/07, Andrew Petro <[EMAIL PROTECTED]> wrote: > > Susan, > > [ > But the sourceforge project does not seem to have any code or downloads or > anything else associated with it. Can anyone shed any light on this? > ] > > I can shed little light. My understanding is that SunGard HE intended to > open source a poweful and ambitious i18n engine that allows > internationalizing and localizing all sorts of text in the portal, and that > the next-gen DLM code specifically makes use of this utility. My > understanding is that this was something Jan was working on when he > transitioned out of he uPortal community. And my understanding is that that > open-sourcing process was almost completed but for the critical step where > the code is committed to SourceForge. > > Obviously (I hope), I cannot speak for SunGard. But I suspect that > someone stepping up to volunteer to take that > body-of-code-to-be-open-sourced and commit it into > open-source-source-control would be welcome and would be effective in > bringing about the "quick win" of getting the DLM 2.0 dependencies out > there. > > As an immediate-term solution, I suspect that the missing dependency could > be replaced with some quick code that resolves keys through resource > bundles. This wouldn't go after the more ambitious use cases addressed by > the real dependency, but it might remove an impediment to progress if > there's interest in other aspects of the sandbox code. > > Andrew > -- You are currently subscribed to [email protected] as: > [EMAIL PROTECTED] To unsubscribe, change settings or access > archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev > -- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
