On Jan 26, 2006, at 7:15 AM, Egmont Koblinger wrote:
On Thu, Jan 26, 2006 at 06:09:42AM -0500, Jeff Johnson wrote:
Changing Url: to be locale specific makes little sense to me, mostly
Okay, it's really not an important thing.
Only Summary/Description/Group are of type RPM_I18N_STRING.
Group really surprises me :-) I'd expect group names to be
translated in a
separate database to guarantee that no matter what the packages are
from,
those that belong to the same group in English should also belong
to the
same group in Italian and vice versa... So it seems this is not
necessarily
the case, right?
Essentially, the specspo package is a "separate database" with
dgettext() as the retrieval method.
Or if you mean different groupings based on locale, that's a whole
different problem than l10n for the Group: tag values.
One locale per query.
Okay.
Is it possible to query the list of languages for which a
particular field
is translated, or to query all these translations themselves?
Not possible in general for Summary/Description/Group because the
text that is presented
is often outside of packages.
Okay, I accept and can easily live with the fact that it's not
possible,
however, I can't really understand the reason. If rpm can find the
translation for one particular language, no matter where this info
comes
from, then why can't it find it for more languages? Or maybe rpm
itself
cannot find the translation if it is in specspo format?
rpm finds not only the msgstr, but also the msgid, using dgettext twice.
The first lookup (in en_US locale iirc, I fergit, been years since I
implemented) has
msgid: tag(N)
msgstr: The tag's msgid.
The first msgstr is then used to retrieve the msgstr for the
appropriate locale.
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.
This will show what languages have been included inside the package:
rpm -qp --qf '[%{headeri18ntable}\n]' foo*.rpm
In the mean time I also found it, but thanks anyway :-))
The specspo mechanism is far more flexible than RPM_I18N_STRING
because
the text can be updated and corrected months and years later without
rebuilding the package.
This specspo is a whole new thing to me, I've never heard of it,
but I'll
take a look at it to see if it is what we need. However, it's
absolutely no
problem for us to rebuild a package whenever it's summary/description
changes for any language, so we can perfectly stick to
RPM_I18N_STRING.
No problem for you -- yet. At some point, rebuilding to change i18n
text is
too costly. My experience anyways, YMMV.
73 de Jeff
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
