Jan Trejbal wrote: > Hello Karen, > thank you for reviewing my proposal and valuable suggestions. See my > comments in-line. > > Karen Tung wrote: >> Hi Jan, >> >> Here are my comments. >> >> - You propose to a module called G11nInstall. The name makes it >> sound like it is only useful for install related components. Looking >> at the list of functionalities, it is very general, it can actually >> be use by any application that needs information about locales/language. >> You might consider to use a different name. > > You are correct, G11nInstall is a bit misleading for general > locales/languages information module. > What about I18nServices module? I18n = Internationalization which is > more used term than G11n. > > >> - The proposal indicates that the module will provide C interfaces. >> Considering that most of the known customers to the G11nInstall module >> will not be using C, it would make more sense to provide a CLI interface >> to access the functionality provided by the G11nInstall module. >> I see that you have added a "test driver" interface to the proposal >> as suggested by Jan Damborsky, which is a good starting point. Please >> consider >> calling it a command line interface, not a test driver. When I see >> "test driver", I assume it as an unstable private interface used by >> testing, not for general use. >> Also, please make sure that the command line interface provides >> exactly the same functionality as the C interfaces. > > Not sure if most of the consumers will be non-C, but I agree that > command-line interface is better name than test driver. > I updated the proposal document. > > >> - 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. Dave
