10:08 a.m.
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
--
martin.langhoff(a)gmail.com
martin(a)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
12:08 p.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
12:58 p.m.
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.
--
// Bernie Innocenti - http://codewiz.org/
\X/ Sugar Labs - http://sugarlabs.org/
10:35 p.m.
On Sat, Oct 9, 2010 at 1:58 PM, Bernie Innocenti <bernie(a)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
--
martin.langhoff(a)gmail.com
martin(a)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
10:54 p.m.
On Sat, Oct 9, 2010 at 8:35 PM, Martin Langhoff
<martin.langhoff(a)gmail.com> wrote:
On Sat, Oct 9, 2010 at 1:58 PM, Bernie Innocenti
<bernie(a)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
10:55 p.m.
On Sat, Oct 9, 2010 at 11:35 PM, Martin Langhoff
<martin.langhoff(a)gmail.com> wrote:
On Sat, Oct 9, 2010 at 1:58 PM, Bernie Innocenti
<bernie(a)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(a)gmail.com
martin(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/olpc
--
Sayamindu Dasgupta
[http://sayamindu.randomink.org/ramblings]
7:23 a.m.
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.
--
// Bernie Innocenti - http://codewiz.org/
\X/ Sugar Labs - http://sugarlabs.org/
6:49 p.m.
On Sun, Oct 10, 2010 at 8:23 AM, Bernie Innocenti <bernie(a)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-
--
Sayamindu Dasgupta
[http://sayamindu.randomink.org/ramblings]
12:06 p.m.
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 - http://codewiz.org/
\X/ Sugar Labs - http://sugarlabs.org/
4955
days inactive
4963
days old
8 comments
5 participants
participants (5)
-
Bernie Innocenti -
Jerry Vonau -
Jon Nettleton -
Martin Langhoff -
Sayamindu Dasgupta