Langpacks for Puppy

I have been thinking how the output from MoManager can be improved. So far, MoManager creates individual tarballs of translations for each application, that can be sent to package authors or to me if they are Woof translations.

However, I have been rethinking that. Instead, MoManager can accumulate all the translations for a particular language and automatically create a "langpack" PET. That way, the translator won't just send off translations to app authors and hope they get put into the packages. The translator can still do that, but now will keep them all together as a PET also.

I have worked out a basic design for such a PET, in the case of Russian translation, as rodin.s has provided a lot of translations. The PET is uploaded (189KB):
http://distro.ibiblio.org/quirky/pet_packages-noarch/langpack_ru-20120213.pet

This PET can be used in two ways:
1. When a Puppy is built in Woof, so you would have a Russian Puppy out-of-the-box.
2. Installed after first boot and the user chooses a locale.

In the latter case, I have not yet automated that step, just putting up an advice window to run the Puppy Package Manager to install the langpack for a more complete translation.

The example Russian langpack has some interesting features, that translators will want to examine -- other translators can use it an a guide to what their own PET should look like, although I intend that MoManager will generate the PET automatically.

The langpacks will be in the 'noarch' repository, so must not have any binary executables.

It is possible that rodin.s will look inside the ru PET and might want to put more stuff into it. Which he is free to do as the maintainer of the ru langpack.

Anyway, I will do a Racy build tonight to do some sanity testing of the langpack. If it looks good, I will do some more work on MoManager to generate the PET, then upload a test Racy build.

A note to everybody reading this. The ru langpack PET is designed to work with very latest Woof-built Puppy. It will not work fully on older puppies. It really needs the Racy build that I will upload soon.


Posted on 13 Feb 2012, 16:00


Comments:

Posted on 13 Feb 2012, 16:08 by BarryK
L18L initrd
L18L,
A quick note while I think of it. I have not forgotten your work on internationalising the initrd.

This is important stuff, especially if we are going to build a language-specific Puppy in Woof.

This was the blog thread I think?
http://www.murga-linux.com/puppy/viewtopic.php?t=72321



Posted on 14 Feb 2012, 3:36 by L18L
re initrd
Yes it is.
Now using t12s:
http://www.murga-linux.com/puppy/viewtopic.php?t=72321&start=32


Posted on 14 Feb 2012, 17:35 by BarryK
initrd setfont
L18L,
I am just starting to study your work on initrd. Regarding your comment that busybox in initrd supports loadfont but not setfont, yes it does, Busybox 1.20.0 that we are now using, supports all of these:

Currently defined functions:

[, [[, ash, basename, bbconfig, beep, blkid, blockdev, bunzip2, bzcat,
cat, chgrp, chmod, chown, chroot, clear, cp, cut, dc, dd, depmod,
devmem, df, dirname, dmesg, du, echo, egrep, eject, expr, false, fdisk,
fgrep, find, findfs, free, freeramdisk, fsync, grep, gunzip, halt, hd,
head, hexdump, hwclock, init, insmod, kill, killall, klogd, ln,
loadfont, loadkmap, logger, login, logread, losetup, ls, lsmod, lspci,
lsusb, mdev, mkdir, mkdosfs, mke2fs, mkfs.ext2, mkfs.reiser, mkfs.vfat,
mknod, mkswap, modinfo, modprobe, more, mount, mv, passwd, pidof,
pipe_progress, pivot_root, poweroff, printf, ps, pstree, pwd, pwdx,
rdev, readlink, reboot, renice, rev, rm, rmdir, rmmod, sed, seq,
setfont, setkeycodes, setlogcons, setserial, sh, showkey, sleep, sort,
stat, swapoff, swapon, switch_root, sync, syslogd, tail, tee, test,
timeout, touch, tr, true, tune2fs, umount, uname, unxz, usleep,
volname, wc, xargs, xz, xzcat, zcat




Posted on 14 Feb 2012, 17:41 by BarryK
initrd busybox
Busybox in initrd was compiled without unicode support:

# CONFIG_LOCALE_SUPPORT is not set

# CONFIG_UNICODE_SUPPORT is not set
# CONFIG_UNICODE_USING_LOCALE is not set
# CONFIG_FEATURE_CHECK_UNICODE_IN_ENV is not set
CONFIG_SUBST_WCHAR=0
CONFIG_LAST_SUPPORTED_WCHAR=0
# CONFIG_UNICODE_COMBINING_WCHARS is not set
# CONFIG_UNICODE_WIDE_WCHARS is not set
# CONFIG_UNICODE_BIDI_SUPPORT is not set
# CONFIG_UNICODE_NEUTRAL_TABLE is not set
# CONFIG_UNICODE_PRESERVE_BROKEN is not set




Posted on 14 Feb 2012, 17:55 by BarryK
LOCALES in initrd
L18L,
Something in the init script that I don't understand, you have this early in the script:

[ -f $LOCALES ] && . $LOCALES

So why do you have that line again inside a function?



Posted on 14 Feb 2012, 18:00 by BarryK
Re: LOCALES in initrd
I mean, it is repeated inside the fsckme_func, as well as several other places in the script.



Posted on 14 Feb 2012, 18:30 by L18L
re .$LOCALES
It is repeated before a message containing variables. The variable could have been set or changed before so the file has to be reloaded.

Hope that was what you mean 8985745


Posted on 14 Feb 2012, 18:36 by L18L
re: initrd setfont
Thanks, I will give it a try.
If it works Arab and Hebrew could be localized too.


Posted on 14 Feb 2012, 20:50 by L18L
Re busybox
>Busybox in initrd was compiled without unicode support
Anyhow it is working fine.

I am thinking it is just the font that matters.
I have tested successfully setfont with Arabic

init line about 174:

# change font for Arabic or Hebrew

case $plang in
ar|iw) setfont /lib/consolefonts/LatArCyrHeb-16.psfu.gz -C /dev/tty1 ;; # no Greek
esac





Posted on 14 Feb 2012, 21:04 by BarryK
Busybox unicode support
I have recompiled Busybox, snapshot from git, with unicode support:

# CONFIG_LOCALE_SUPPORT is not set

CONFIG_UNICODE_SUPPORT=y
# CONFIG_UNICODE_USING_LOCALE is not set
# CONFIG_FEATURE_CHECK_UNICODE_IN_ENV is not set
CONFIG_SUBST_WCHAR=63
CONFIG_LAST_SUPPORTED_WCHAR=12799
# CONFIG_UNICODE_COMBINING_WCHARS is not set
# CONFIG_UNICODE_WIDE_WCHARS is not set
# CONFIG_UNICODE_BIDI_SUPPORT is not set
# CONFIG_UNICODE_NEUTRAL_TABLE is not set
# CONFIG_UNICODE_PRESERVE_BROKEN is not set


I will put this into the initrd.

I think that the unicode support might affect some things, like "cut -c 2" which means cut the 2nd character. if the string was unicode characters, then a non-unicode-aware cut utility would not work correctly.



Posted on 14 Feb 2012, 21:13 by BarryK
re LOCALE
It is repeated before a message containing variables. The variable could have been set or changed before so the file has to be reloaded.

Hmmm, I see. I count it happens 19 places in the script. That would seem to be the achilles heel of the t12s technique.



Posted on 15 Feb 2012, 3:01 by L18L
re re LOCALE
I donīt think so.
It is all about speed of execution. We have to compare it with eval_gettext

# FILE1=init

# time echo $(eval_gettext "The script $FILE1 has changed")
The script init has changed

real 0m0.103s
user 0m0.033s
sys 0m0.010s
#
# _M_1="The script $FILE1 has changed"
# time echo ${_M_1:-The script $FILE1 has changed}
The script init has changed

real 0m0.000s
user 0m0.000s
sys 0m0.000s
#


That is up to 499 or up to 999 micro seconds if we can trust the time command.

Of course we could hide the repeated loading of the translation file in a function but every function call needs additional time for execution.
Sourcing a file needs 0.000s.

The only Achilles heel I think about is the display of the messages in yad which is a miracle for me sometimes.