On 12/19/08 21:56, Dave Miner wrote: <snip> >>> - In the examples of module consumers list, you mentioned the transfer >>> module. >>> I don't think that should be in this list. The transfer module will not be >>> calling the G11nInstall module APIs directly. Some callers of the >>> transfer module, >>> eg: AI, DC or liborchestrator will call the G11nInstall APIs, figure out >>> what >>> languages/locales are needed, and then, pass that information into the >>> transfer module. >> Right, but then transfer module will need to know what packages or files >> should be installed for given list of languages/locales. That's why I >> think the transfer module will need to call the API. >> >> Maybe this is part of AI project, is it? >> If yes, then I should remove transfer module from the proposal. >> > > I think it would be more accurate to expect that IPS will provide this > using the facets/variants work that Bart is doing. The transfer module > might be required to configure those for IPS to operate correctly, of > course, but I suspect that's as deep as the transfer module should get > into this problem. >
Thank you for pointing me out the work being done at facets and variants. Bart came with very interesting concept. I (and my team) need to help with facet.locale precise definition. For G11nInstall module (as well as transfer module) this means we can rely on IPS to provide locale/language to packages/files information. Therefore, I will remove following functionality/requirement from G11nInstall module, unless someone asks for it. It would anyway be a transient implementation before facets and variants will be available. 4) Get a list of packages which must be installed/removed on the system, in order to support given language(s) or locale(s). Jan
