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" these days.
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 description/summary/group.
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