(I follow up in the original proposal instead of the following thread, which I read, though) Quoting Frans Pop (elendil@planet.nl): > win32-loader was included in the repository in packages/arch/i386, but IMO > that is not correct. Reason I feel it is not correct is that, although it > is definitely related to D-I, it is not a D-I component (does not produce > udebs). > > 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. Frankly, I don't really remember whether the package was put there with the idea of integrating it in the translation infrastructure or not. I don't really think so because just like you: > 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. This is also my feeling. I agree that we had a brief exchange, Robert and I, two days ago, about possibly integrating it in master files (after all, it could go in one of the sublevels...). But, thinking deeper, this is not really a good idea, for the reasons you mentioned. > > I therefore propose to move win32-loader (and any tags) from its current > location to directly under trunk, as is suitable for a basically > independent package. > This would also make it more clear that translations need to be committed > separately and makes it easier for translators to do a separate checkout of > just win32-loader if they like. For translation statistics win32-loader > could be included in level2, together with other packages that are > important for installations. Actually, when the package was introduced, I *briefly* added it as part of level 2. However, there's a problem: some languages are not supported in NSIS. So, as the comments in the win32-loader say: one has first to translate NSIS before working on win3é-loader. As NSIS is something we don't have control over, I thought it would be unfair for translators of those languages to include the language in level 2 while they practically *can't* really translate for their language. For this reason, adding win32-loader to level 2, which we try to get complete when we release, is IMHO too much. I would welcome any idea as this situation is indeed something that I don't really like. About the package move, I support Frans suggestion: keep the package in D-I SVN, but in a tree that would be parallel to packages. By the way, it could be interesting to talk about moving tasksel there as well. Having it separated is mostly historical but the package is D-I team maintained for ages and is closely related to D-I anyway.
Attachment:
signature.asc
Description: Digital signature