PLEASE do NOT CC me on list mail! On Saturday 22 March 2008, Robert Millan wrote: > > I thought that the location was chosen so that translating it could be > > integrated, and I thought that was already the case. Yesterday I > > learned that this is not so. > > I expected that translation would be integrated eventually. Christian > mentioned there are technical problems with that. I'm willing to help on > those if I can, but we haven't got around to discussing it yet (it wasn't > a big priority for me either). As win32-loader does not follow the usual structure of D-I components there will always be exceptions. I see no reason to force our translation infrastructure into supporting that when translations can easily be handled outside D-I, just as is already done for some other packages that are related to D-I, but not part of it in a strict sense (such as aptitude or tasksel). > > I also personally feel that translation of win32-loader should not be > > integrated in the level 1 infrastructure _because_ it isn't a D-I > > component. > > You mean that because win32-loader doesn't produce udebs, it can't be > considered a D-I component, and therefore its translations can't be > integrated? No, you are twisting my argument. > Is this based on the assumption that only udebs provide programs that > interact with the user during the install process? Besides the fact that that statement is already completely untrue (even if you don't consider win32-loader), that has nothing to do with it and nothing I said could have given you that impression. win32-loader is IMO not part of the installer _in a strict sense_. Of course it _is_ very closely related to it and therefore I have no problem with having it in the D-I repository. I just feel that _given_ that it is not really part of D-I itself, _given_ that it does not produce udebs, _given_ that translations are not currently part of level 1 (which confused at least me as a translator!) and exceptions would have to be coded to make it part of it and _given_ that we already have excellent alternative ways to deal with such packages, my conclusion is that it should not be in its current location in the repository, but rather at the top level.
Attachment:
signature.asc
Description: This is a digitally signed message part.