Re: RFC: shorten translatable messages, eliminate fuzzy, and more
Previously Alexey Mahotkin wrote:
> I would like to discuss the proposal of splitting gettextable messages
> in dpkg in lesser chunks, probably of string or couple of strings in
> length.
This comes up on occasion and I always refuse for a simple reason:
it means that when I change something in the code you will suddenly
end up with messages that are partially English, partially another
language. That is is extremely confusing for users, so to prevent that
from happening we use large messages.
> Strings of such a "length" are extremely hard to update in .po-files.
> There is mostly no way to see what exactly changed: you will have to
> keep somewhere an exact copy of dpkg sources that were used for last
> update of .po-file, and look at the diffs between two sources.
You should be able to tell that easily from the CVS diffs.
> While it is not resolved, I would recommend Wichert _not_ to update
> .po-file, unless it is sent by a respective translator.
I don't tend to update those files actually, maybe once every few
months I run an update.sh to get some new translations statistics.
> As for the downsizing of .po-files, I think that we could actually
> _not_ mark _every_ string as translatable. There is a lot of messages
> that are actually "should never happen"-style. E.g., I really think
> that "unable to ignore signal %d before running %.250s" should always
> be in English. That way, the innocent user can simply cut-and-paste
> the error message, and file a bug report, without re-running the
> failed operation with LC_MESSAGES=C (and you will have to explain that
> operation to him first! and the failure could be not reproducible!).
Internal errors are not translated, ones that can be caused by outside
factors are useful information for users and definitely should be
translated.
> I do not propose scanning all the sources and un-gettextizing the
> debugging-only messages.
I did that a while ago, debug messages are not translated.
> Another, related issue, is that as far as I know GNU-style string
> continuations
>
> "foo \
> bar"
>
> are disallowed by C99 and are going to be deprecated (and then
> unsupported) in some near gcc. Splitting of gettextable lines is
> going to help that too.
Already done in CVS, gcc 3.0 prints warnings for those.
Wichert.
--
_________________________________________________________________
/ Nothing is fool-proof to a sufficiently talented fool \
| wichert@wiggy.net http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Reply to: