Re: [Monotone-devel] Re: Workspace commands and automate/stdio

[Thomas Keller]

Lapo Luchini schrieb:
> Thomas Keller wrote:
>>> It may (?) be a faster "intermediate" solution, but seems a
>>> little too brittle to be the "real" solution, to me.
>> What would be a non-intermediate solution for you?

> ... At the moment, I know pretty much *nothing* about basic_io, so
> I'm not in the position to actually suggest anything, but if strings
> must be, I'd use *fixed* strings, more in the realm of
> "FILE_NOT_FOUND[%s]" than "The file '%s' was not found or is not
> readable".

It has nothing to do with basic_io (or stdio, what you probably meant),
which are just content encodings. The issue is more that whether we go
the original route of providing an MTN_AUTO "translation" or we're doing
my proposal of fixating the original strings, both solutions include the
aspect of having "minimal impact" on other people's work. I think this
is because most people are just ok with "the way it is handled now" and
whatever "huge" we would do would just annoy them too much in their
daily work. (Is this correct? If not, speak up anonymous crowd!)

Of course I'm with you, I'd love to have really fixated strings, but
this would mean major work for all the translators, since they'd
basically have to redo their whole translation again (all source strings
would change). I can't even think of the changes code-wise so I guess a
lot of people would start screaming around if we would start wiping out
all english texts from the monotone sources...

> And using gettext for strings that must be both easily parsable and 
> consistent over time, mhh.... just feels wrong. gettext is a
> wonderful library for translation of human-oriented strings, but I
> wouldn't use it for computer-oriented strings. Mhh, no, that's not
> exact: I wouldn't use strings at all, if not oriented to humans; I'd
> use something closer to a (int error_id, string reason) or a (string
> exception_name, string message).

Error IDs would be great, indeed, but thinking a bit longer on this
problem leads us to the fact that monotone is developed distributed, so
picking unique error IDs would sooner or later lead to clashes. So _if_
we use an ID value _at all_ for identifying errors, it should be
something smarter.... *whistles* .... what? Have I heard something of
hash-based error IDs?

Thomas.

-- 
only dead fish swim with the stream: http://thomaskeller.biz/blog
Am Anfang war das Wort: http://www.schäuble-muss-weg.de

signature.asc
Description: OpenPGP digital signature