Comment 22 for bug 637227

To answer the 2 questions from comment #16:

1) The "default" encoding for non-i18n tags (summary/description/group) is
essentially 8bit octets since there is no enforcement of any encoding.

2) For i18n tags (summary/description/group), one can spcify any locale one
wishes, e.g.
    Summary(pl.utf8):
    Summary(pl.wtfencoding)
are perfectly permissible, and the associative array used for retrieval of the
tags will attemp to key from "pl.utf8" and "pl.wtfencoding" for appropriate
strings to be returned.

That being said, the real world is far more complicated, and there is no current attempt to
translate strings into a different encoding, the current packaging pragma is to assume a 2 letter
country code implies an encoding, and the whole mess was obsoleted in RHL 6.2, at least for
RH packaging, in favor of specspo (the implementation has not been tested since RHL 6.2, at least
by me) which at least *has* an explicit and well specified encoding.

Nor are summary/description/group the only data that should hav i18n representations. Unfortunately,
rpm has no "array of i18n strings" data type, only "string array" and "i18n string" (i.e. an associative
array. Adding a new data type to rpm is a very very painful experience, using specspo-like to
associate strings *WITH* a package rather than *IN* a package is far easier to achieve than
actually adding a new data type.

I seriously question whether i18n encodings for strings has anything whatsoever to do with package
management. Use a a key, like Pkgid/Hdrid/NEVRA or whatever to attach glop to the package for
display purposes instead.