Sandro, Thanks for taking the time to follow this thread. I'm interested to hear how your company handles this kind of thing.
It does sound similar to my experiences, but while I have seen different methods in different places, there has never been common solution. However, localization has never been a primary activity for me, rather something to consider when designing and implementing solutions. If there is a current localization solution in place, then that pretty much means we have to adapt and use it. Chris On 12 July 2011 05:12, Sandro Martini <sandro.mart...@gmail.com> wrote: > Hi all and sorry for the delay. > I'm writing from a mobile device so I'll be short for now ... at work we > have a "localization" server containing all localized resources (and related > app to handle them, and to let translators, IT and QA people to play with > those resources). Some app download resources and use them in a static > (release oriented) way, while others use them dynamically (without having to > deploy something new). Maybe this could be a use case like the idea proposed > by Chris ... I'll be happy to discuss this better with all devs, but maybe a > jira ticket could help. I have to go now. > Bye to all, > Sandro > Il giorno 11/lug/2011 23:51, "Chris Bartlett" <cbartlet...@gmail.com> ha > scritto: >> I don't have a background in Swing dev, so that doesn't really help. >> (I can continue this tomorrow - my morning alarm will go off in about 90 > mins) >> >> On 12 July 2011 04:45, Greg Brown <gk_br...@verizon.net> wrote: >>>> The primary objective is simply to be able to *choose* where the data >>>> comes from and not be limited to a single option, especially if it >>>> means avoiding an otherwise unnecessary build step and duplication of >>>> data. >>> >>> Let me ask the question a different way. If you were building a Swing > app, which primarily uses properties files for localization, how would you > solve this problem? >>> >>> >
