Re: multilang questions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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

[Index of Archives]     [RPM Ecosystem]     [Linux Kernel]     [Red Hat Install]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Red Hat]     [Gimp]     [Yosemite News]     [IETF Discussion]

  Powered by Linux