[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposal: move win32-loader in SVN repository

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 

> > 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.

Reply to: