On Thu, Jan 26, 2006 at 07:26:07AM -0500, Jeff Johnson wrote:
> Essentially, the specspo package is a "separate database" with
> dgettext() as the retrieval method.
Yep, I'm just staring at FC specspo.rpm.
> Or if you mean different groupings based on locale, that's a whole
> different problem than l10n for the Group: tag values.
No, that's what I want to avoid. Grouping should be the same in all
languages. Using specspo nearly guarantees it, but, well, I see this in
FC's it.po:
msgid "Development/Libraries"
msgstr "Sviluppo/Librerie"
which gives me a feeling that nothing prevents me from translating
"Development/Libraries" to "A/B" and "Development/Tools" to "C/D". This is
fine if Groups are free-text, but not so good if Groups are composed of
slash-separated hierarchical components. In the latter case it would be
better to split at slashes, translate the components separately and rejoin
them.
But this whole story if groups is not too important for me. So far our only
audience was Hungarian people, and we had only Hungarian summaries for our
packages. However, groups ("section" as dpkg calls it) were in English and
no-one complained about that. So it's really fine to stay at English only.
Summary/Description is more important, here I'd like to use a real i18n
engine which is capable to accept any languages, and create this fields in
English and Hungarian. Most likely we won't support other languages for a
long time.
> dgettext is not the best choice for "separate database" retrieval
> method but definitely has the
> advantage of as little maintenance as possible merging and otherwise
> managing translator's PO files.
Right. However, we won't have translators, we'll write the summaries in two
languages ourselves.
> No problem for you -- yet. At some point, rebuilding to change i18n
> text is too costly. My experience anyways, YMMV.
ccache rulez. Being able to rebuild kdebase in less than 30 minutes is
beautiful. We have over 1000 source packages, and buinding all of them on
five not-so-expensive table PCs, all within their own chroot containing
exactly those packages that are mentioned to be there (i.e. the
corresponding of BuildRequires in rpm) and no more packages installed there
takes approx. 4 or 5 hours. Okay, we only have one architecture, and do not
yet build OOo (use prebuilt binaries). We do regular full rebuilds, about
every 1 or 2 weeks, to see if changes to some of our packages breaks the
build of some other packages. If we do some non-important change, sometimes
we do not even rebuild this package, just let the next full rebuild do it.
In this system, the cost of having to rebuild a package just because its
summary changes is negligible.
On the other hand, I do not like packages that contain information about
other packages. I don't like the whole concept of specspo. I think the right
place for the translations is the binary rpm itself. (Well, Group is a
tougher question...)
So I guess I'll stick to using "Summary" and "Summary(hu)".
The problem that bothers me is that meta-files created by yum only contain
the summaries in one language. In which language should we put it on our FTP
server, on our install CD etc...?
My favourite solution would be if these meta-files contained the
translations in all available languages (no matter if they're in separate
files) and yum could select the version according to its current locale. I
don't know if there's anything rpm could do to make it easier to create such
meta-files. I'll try to contact the developers of createrepo and yum.
thx,
Egmont
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
