changes in dbootstrap i18n (was Re: Hard newlines in dbootstrap messages)
On Fri, Mar 19, 1999 at 12:32:49AM -0500, Ben Pfaff wrote:
> Some of the messages that dbootstrap prints are hard-wrapped to some
> number of columns. I believe that libnewt will auto-wrap to window
> width (correct me if this is wrong)? Since my graphical boot floppies
> use proportional fonts, hard newlines screw it up. Would it be okay
> to check in modified messages (lang_C.h) that do not have hard
> newlines?
You may remove the "formatting" ones (like in "Running LILO to make the kernel
able to boot from the \n hard disk without a boot floppy..."), but please
leave the "end of paragraph" ones ("... and initialize a swap
partition.\nPlease use the main menu to ..."). Also, some messages are
not being showed using newt, but directly printed to the console
("You are running \"ash\", a Bourne-shell clone...").
OTOH, this weekend I will try to check in a few changes:
- dbootstrap now uses a "gettext-alike" method for i18n. That means the
sources are "gettextized" and the message catalogs are PO files that
can be automatically updated/checked using simple "make" targets. I
think that'll make our tasks as programmers/translators easier.
OTOH, it may some Adam's macros for the documentation. Adam, I may
build a trimmed-down "lang_<lang>.h" (or whatever.ent) at compile time
if you still need it. Just tell me.
- (If I can finish and test it before the weekend) "alpha-quality"
support for building all the translated boot-floppies in one
dpkg-buildpackage run.
- No more references to dinstall, it's now dbootstrap everywhere. Even
the directory has been renamed.
I may check those changes directly in the main trunk, or create a branch
if you see the need. Any suggestions?
Just a final comment, I haven't found a "decent" aic7xxxx driver version
(in fact, I've been told there's no such a thing) so I don't know which
one should Herbert use for a new kernel version. In the mean time, any
"the installation hangs after detecting my Adaptec card"-like bug should
be reassigned to kernel-image-2.0.36 (and merged to the few that are
already there). Let's hope this stuff is fixed in 2.2.3.
Thanks,
--
Enrique Zanardi ezanardi@ull.es
Reply to: