... and in the modern age, we have Perl and regexps :-)
Nobody is going to maintain all the translations of "his" component,
so you might as well let the translators try to play catch-up, and
track changes in their regexp database.
For the kernel, we don't have the mechanisms of big companies or
monolithic projects to just funnel all changes of a specific kind
through a single channel, where somebody slaps a unique message-id
on them.
Granted, you can have multi-level messages (like the VMS-style
%facility-severity-ident), but that only buys some time. And you
still either need a message catalog or include the plain text in
the message as well.
The message catalog only approach wouldn't work well for the kernel,
yielding either too many files or patch congestion on central
message files. Think of Documentation/Configure.help and the
relative frequency of changes.
And if you have the (English) plain text, you almost always also
have your unique message key. At least unique enough for
translation. So perhaps it's time to forget the traditional
solutions, and think of a more distributed approach.
- Werner
-- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/