RFC: i18n proposal
jbj at redhat.com
Mon Aug 4 18:08:32 UTC 2003
On Fri, Aug 01, 2003 at 12:22:47AM +0200, Göran Uddeborg wrote:
> Jeff Johnson writes:
> > Unlike, say, error messages with xgettext *.c, summary/description/group
> > are much softer, so text divergence is acceptable.
> > Yes, that's a feature, at least for the docs team editors, because text
> > can be updated in the field without having to wait for "make world"
> > \of the next distro release.
> I'm not sure about your argumentation here. WHY are these particular
> messages "softer" than others, and divergence more acceptable for
> them. And WHY is it important to be able to update these particular
> messages in the field and not others.
description/summary/group are "softer" in the sense that the usage context
of the output text is not quite as stringent as, say, strerror(3).
There are many ways to convey the information accurately, I'm quite sure
that you as a translator have taken some liberties in the interest of
accurately conveying semantic content, the alternative is babelfish, ick.
OTOH, the information in description/summary/group *MUST* be translated
accurately, and it's quite possible to obliterate meaning with overly
complicated mechanism. Fuzzies come to mind, often accurate, sometimes
hilarious. Specspo has (potentially) the same problem as fuzzies, and
the solution comes from solid process i.e. acceptance criteria for translation
is "No fuzzies".
The equivalent for specspo and package header contents is "Must match",
the devil is in trying to make this happen becuase of rpm's design
goal, binary rpm's must be built. Red Hat has tried 3 or 4 solutions,
none were adequate, specspo has been the "best" so far.
Updating msgid's seperately is a requirement imposed by the docs team
on the implementor, me. I have no control over the constraint, you will
need to explore WHY with the docs team (although you can probably guess
the answers just as well).
> It could very well be that we simply have different opinions; that
> your feature is my bug. But I feel I don't understand your reasoning.
> I don't understand your motivation for the statements above. So I'm
> not sure.
> If a package needs to be updated, being because of a bug fix in the
> code, a changed description, or an corrected dependecy, the natural
> thing would be to issue an errata for that particular package, it
> seems to me.
Sure, but I question whether adding, "Buffer overflow #5642 fixed in
version 4-5." is really a satisfactory solution. I'd rather see
the bugs tracked through other means than description.
> I fail to see why descriptions and summaries are so very different
> from other documentation in the package.
description/summary are different because the values are located in
the package header, not the package payload, and must be accessible
to anaconda before the package is installed. In fact, the info
must be accessible in an empty chroot, although anaconda is "cheating"
Demanding that rpm be able to extract text from payload before install
breaks every known current use of rpm, and adds intolerable overhead
as well, fishing the text out of payload. Far, far easier to have
solely in metatdata, but that also means that traditional solutions,
like gettext(3) and dgettext(3) are not at all useful for
> > > But maybe I misunderstood this comment. If so, I guess one could try
> > > to extend the current "%description -l ...".
> > And, yes, the old means of adding text to spec files still exists,
> > will probably exist forever. [...]
> > OTOH, it does mostly
> > solve the 3rd party single package i18n problem, the only thing that
> > breaks is when there are package name collisions, specspo is preferred to
> > header content.
> Rather than name collisions I'm more concerned about the lack of
> coding information. And, AFAIK, the lack of tools to automatically
> pick up contributed translations.
All I meant is that, say, "name(Description)", if found in specspo, will
be used before any header resident text. Quite easy to change lookup order.
Lack of tools is a problem, yes.
Lack of priority to write the tools is a problem for me as well.
73 de Jeff
Jeff Johnson ARS N3NPQ
jbj at redhat.com (jbj at jbj.org)
Chapel Hill, NC
More information about the devel