On Sun, Mar 23, 2008 at 07:45:40AM +0100, Christian Perrier wrote: > > > > 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.
Sounds like a fair point (as for udebs, I still don't really see how they relate to the equation, but that is moot now). I'm not familiar with what each level means, though. Is there a less-priority level for which it would be suitable? My interest in integration is due to other things not related to how much priority is assigned to translating win32-loader. For example, new translators often use the BTS to send win32-loader translations, but it would be more convenient if they use the same channels used to add stuff to packages/po/ (sometimes this even meant that translator coordinators sent bug reports instead of committing the translation directly). So, is there any solution that would allow this, without imposing win32-loader translations as a prioritary requirement? -- Robert Millan <GPLv2> I know my rights; I want my phone call! <DRM> What use is a phone call… if you are unable to speak? (as seen on /.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
