Emily Shaffer <emilyshaffer@xxxxxxxxxx> writes:
> Hm. I guess I got the opposite impression from you way back in v1. I do
> wish it had been communicated a little more clearly; it's frustrating to
> perceive a reversal after seven months of review. But that's probably on
> my own reading comprehension :)
Well, seven months is a long time for anybody to learn from repeated
reading and gained experience to form an opinion and get affected by
others' opinions. In any case, this is one of the reasons why I try
to discourage people to have too many topics in flight before moving
on to a new and different topic---the risk of ending up with fliping
and flopping is just too high when you give people chance to forget.
Rather, I'd prefer to see something simple to land first and then
later refined.
On this particular issue, I actually do not have a preference. As
long as the topic has a coherent position/stance, any one of
(a) we do as much i18n as possible to help end-users, or
(b) we stay away from i18n to ensure the reports are machine
readable, or
(c) somewhere in between with a clear criterion where you are
drawing the line (e.g. "the introductory text is what we want
the end-user to read, so it is i18ned, but the report about
their environment are primarily for our use and we avoid
localizing so that we can process mechanically"),
is fine. The important point is that we choose what we do with a
solid guiding principle behind the decision.
In practice, every string in bugreport.c you have control over the
use (or non-use) of _() around it, but codepaths that you call from
existing parts of the system are likely to have their messages
localized if they are meant for Porcelain use. So from that point
of view, (a) would be easier to arrange than (b), I suspect.
Thanks.
