Hi folks,
we're now including a very limited set of langs in our OS images. This can make life rather awkward for small deployments (read: no tech team) using languages not included in our build...
Is there a script to install missing locales for already-installed rpms?
Cross-posting to fedora-olpc -- maybe there's a Fedora tool to install pruned locales?
cheers,
m
Hi Martin:
On Sat, 2010-10-09 at 11:08 -0400, Martin Langhoff wrote:
Hi folks,
we're now including a very limited set of langs in our OS images. This can make life rather awkward for small deployments (read: no tech team) using languages not included in our build...
Is there a script to install missing locales for already-installed rpms?
Think the fastest would be to force the re-installation the glibc-common rpm.
Cross-posting to fedora-olpc -- maybe there's a Fedora tool to install pruned locales?
cheers,
You can spin-up your own image with olpc-os-builder, editing the languages as required.
Jerry
Jerry
On Sat, 2010-10-09 at 12:08 -0500, Jerry Vonau wrote:
Think the fastest would be to force the re-installation the glibc-common rpm.
Yes, and the sugar-* rpms too.
We probably don't need any of the catalogs for the other system tools. Activities installed from .xo bundles will already have all languages installed.
You can spin-up your own image with olpc-os-builder, editing the languages as required.
This would be cleaner, of course, but Martin was thinking of small deployments lacking a technical team.
On Sat, Oct 9, 2010 at 1:58 PM, Bernie Innocenti bernie@codewiz.org wrote:
On Sat, 2010-10-09 at 12:08 -0500, Jerry Vonau wrote:
Think the fastest would be to force the re-installation the glibc-common rpm.
Yes, and the sugar-* rpms too.
Riiight. So `yum -yt reinstall glibc sugar-*` should do the trick? Nothing else? Sounds too easy :-)
You can spin-up your own image with olpc-os-builder, editing the languages as required.
This would be cleaner, of course, but Martin was thinking of small deployments lacking a technical team.
Exacto.
m
On Sat, Oct 9, 2010 at 8:35 PM, Martin Langhoff martin.langhoff@gmail.com wrote:
On Sat, Oct 9, 2010 at 1:58 PM, Bernie Innocenti bernie@codewiz.org wrote:
On Sat, 2010-10-09 at 12:08 -0500, Jerry Vonau wrote:
Think the fastest would be to force the re-installation the glibc-common rpm.
Yes, and the sugar-* rpms too.
Riiight. So `yum -yt reinstall glibc sugar-*` should do the trick? Nothing else? Sounds too easy :-)
It is almost that easy. Hate to rain on your parade but you will also need to edit /etc/rpm/macros.dist and add the locales you wish to support to the %_install_langs macro.
After making that change re-install those packages and you should get the additional langs.
-Jon
On Sat, Oct 9, 2010 at 11:35 PM, Martin Langhoff martin.langhoff@gmail.com wrote:
On Sat, Oct 9, 2010 at 1:58 PM, Bernie Innocenti bernie@codewiz.org wrote:
On Sat, 2010-10-09 at 12:08 -0500, Jerry Vonau wrote:
Think the fastest would be to force the re-installation the glibc-common rpm.
Yes, and the sugar-* rpms too.
Riiight. So `yum -yt reinstall glibc sugar-*` should do the trick? Nothing else? Sounds too easy :-)
The build script filters out _all_ translation files, so even if glibc and sugar translations are there (and glibc contains the locale data as well), there might be other (usually low priority) translation files missing. For that, it is probably best to do a new spin.
For activities, for 0.84 based builds, there are self extracting language packs that you can run as root in the laptops: http://translate.sugarlabs.org/langpacks/0.84/
-sdg-
You can spin-up your own image with olpc-os-builder, editing the languages as required.
This would be cleaner, of course, but Martin was thinking of small deployments lacking a technical team.
Exacto.
m
martin.langhoff@gmail.com martin@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff _______________________________________________ olpc mailing list olpc@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/olpc
On Sat, 2010-10-09 at 23:55 -0400, Sayamindu Dasgupta wrote:
The build script filters out _all_ translation files, so even if glibc and sugar translations are there (and glibc contains the locale data as well), there might be other (usually low priority) translation files missing. For that, it is probably best to do a new spin.
Yes, but the messages from system packages are unlikely to appear in the Sugar UI... I can't think of anything except for ERRNO strings, which are in glibc.
BTW: I was wondering if you know why the Fedora RPMs for Sugar and Activities include message catalogs for en and even all the en_* variants:
bernie@giskard:~$ ls /usr/share/locale/en_US/LC_MESSAGES/ compiz.mo org.laptop.Log.mo gcalctool.mo org.laptop.Terminal.mo libxine1.mo org.laptop.TurtleArtActivity.mo org.laptop.AbiWordActivity.mo org.laptop.sugar.Jukebox.mo org.laptop.Calculate.mo org.laptop.sugar.ReadActivity.mo org.laptop.Chat.mo wget.mo org.laptop.ImageViewerActivity.mo yelp.mo
The "en" strings are built-in, so normally packages do not ship external catalogs for them. It smells like a bug in bundlebuilder.
On Sun, Oct 10, 2010 at 8:23 AM, Bernie Innocenti bernie@codewiz.org wrote:
On Sat, 2010-10-09 at 23:55 -0400, Sayamindu Dasgupta wrote:
The build script filters out _all_ translation files, so even if glibc and sugar translations are there (and glibc contains the locale data as well), there might be other (usually low priority) translation files missing. For that, it is probably best to do a new spin.
Yes, but the messages from system packages are unlikely to appear in the Sugar UI... I can't think of anything except for ERRNO strings, which are in glibc.
I think there are some stock GTK+ stuff, and maybe error messages from other parts of the GNOME platform.
BTW: I was wondering if you know why the Fedora RPMs for Sugar and Activities include message catalogs for en and even all the en_* variants:
It was a hack that was used at some points to fix typos in code (eg: if you had "Wopen" in the source code, you could probably just change the translation of "Wopen" to "Open" in en_US, since if you changed "Wopen" to "Open" in the code, all other translations would had to be updated as well).
-sdg-
On Sun, 2010-10-10 at 19:49 -0400, Sayamindu Dasgupta wrote:
BTW: I was wondering if you know why the Fedora RPMs for Sugar and Activities include message catalogs for en and even all the en_* variants:
It was a hack that was used at some points to fix typos in code (eg: if you had "Wopen" in the source code, you could probably just change the translation of "Wopen" to "Open" in en_US, since if you changed "Wopen" to "Open" in the code, all other translations would had to be updated as well).
Yet, do we really need a copy of the english catalog for each existing en_XX variant? It seems like a big waste of space.
-
Bernie Innocenti -
Jerry Vonau -
Jon Nettleton -
Martin Langhoff -
Sayamindu Dasgupta