Date: Thu, 02 Dec 2004 09:01:09 +0100 From: "Devon H. O'Dell" <dodell@sitetronics.com> To: Ryan Sommers <ryans@gamersimpact.com> Cc: "current@freebsd.org" <current@freebsd.org> Subject: Re: My project wish-list for the next 12 months Message-ID: <41AECBC5.2060608@sitetronics.com> In-Reply-To: <19549.128.101.36.205.1101942657.squirrel@128.101.36.205> References: <41AE3F80.1000506@freebsd.org> <19549.128.101.36.205.1101942657.squirrel@128.101.36.205>
next in thread | previous in thread | raw e-mail | index | archive | help
Ryan Sommers wrote: > Scott Long said: > >>2. New installer. I know some people still consider this a joke, but >>the reality is that sysinstall is no longer state of the art. It's >>fairly good at the simple task that it does, but it's becoming harder >>and harder to fix bugs and extend functionality in it. It's also >>fairly unfriendly to those of us who haven't been using it since 1995. >>The DFly folks have some very interesting work in this area >>(www.bsdinstaller.com) and it would be very good to see if we can >>collaborate with them on it. > > > I've spent a good deal of time taking notes and diagrams of what I wanted > from a new installer. However, time constraints have kept me from actually > putting any of it to code yet. > > I've looked at the DFly installed quite a bit and I like what it offers, > however, I have a few complaints with it. Quite honestly I wasn't > impressed with the code. > > Another issue I had with the dfly installer was one point I believe needs > to be central to any next-gen installer. Internationalisation. My idea of > an installer front-end would use a dynamically loadable language library. > All resources of the front-end (ie strings, images, etc) would be packaged > into a seperate language-pack. These language-packs can then be grouped > together into a language library. A few basic packs would be distributed > with the default library but other libraries could easily be substituted > to make localized distribution sets with little trouble. > > The benefit of this is that instead of translating the code you would only > need to translate the language-(pack|library). I think this would greatly > simplify translation and make a seperation between language and the > front-end code. > > This is where my complaint with Dfly comes in, upon reading the source, > there are string constants everywhere. Perhaps I am missing something, but > this means that in order to supply localization support much work would > need to be done to find some scheme that doesn't mean translating the > source. > > I have quite a bit of notes on seperation and even down to specific > methods and sub-libraries necessary for the back-end. Perhaps if I have > some time soon I'll put it into a PDF somewhere. > > Has anyone else put much thought into this? Yes, we have. I18n is something that we're actively working on implementing, and is something that we take quite seriously. I know that not very many FreeBSD developers use IRC, but we are all available in #dfinstaller on EFNet. We're using gettext for this at the moment. Kind regards, Devon H. O'Dell
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41AECBC5.2060608>