monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Thomas Keller
Subject: Re: [Monotone-devel] Re: Workspace commands and automate/stdio
Date: Sat, 14 Jul 2007 19:53:35 +0200
User-agent: Thunderbird 2.0.0.4 (Macintosh/20070604)

Thomas Keller schrieb:
>>> Monotone uses a couple of global macros which error out well-defined if
>>> something went wrong and this even works for the stdio ostream. However,
>>> what you get as error message is still the same one a normal user would
>>> get. You could start stdio or any other mtn subprocess with LANG=en,
>>> still, if one of those english messages would change (spelling, etc.),
>>> any automate command wouldn't take notice of it and you wouldn't see it
>>> through the interface_version number either.
>> Hrm.  This is more of an issue...
>>
>> Is it possible to subvert the translation system with a LANG=MTN_AUTO when
>> we're running a command in automate mode?  We could then provide an
>> "automate" translation which could be kept consistent.
>>
>> I don't know enough about the translation system to know how this would
>> actually work.

After having thought about this a bit longer, I think we should do it
the other way around. Here is why: If we provide a "stable string"
translation, the translator who cares about this particular translation
has to notice himself somehow f.e. when strings are deleted.
Furthermore, if the translation is not up-to-date, the original strings
are used for everything effectively makeing the whole thing useless.

So, what we should do instead IMHO is provide an en-US translation of
the strings, which right from the start can be as incomplete as
possible, since we won't change anything string-wise. _If_ strings have
to be changed for presentation reasons, one could do that in the en-US
translation. On the other hand all developers should then be aware that
string changes in the sources should bump the interface version in
automate (since we don't know exactly what errors can come through
there, we should just say "any string change"):

* a string was added / deleted:
        minor version bump (f.e. 5.1 to 5.2)
* a string was changed / got different parsable arguments:
        major version bump (f.e. 5.1 to 6.0)

Now what I don't know if most people with english operating systems have
locale=c set or en-US / en-GB, so this might be a problem since they
wouldn't then see "presentational" string changes.

Opinions anyone?

Thomas.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]