RFC: i18n proposal

[Göran Uddeborg]

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.

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.

I fail to see why descriptions and summaries are so very different
from other documentation in the package.

> > 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.