On 16.07.2011 03:14, Tom Lane wrote:
> "Kevin Grittner"<Kevin.Grittner@wicourts.gov> writes:
>> OK, after getting distracted by test failures caused by an unrelated
>> commit, I've confirmed that this passes my usual tests. I don't
>> know anything about the tools used for extracting the text for the
>> translators, so if that needs any corresponding adjustment, someone
>> will need to point me in the right direction or cover that part
>> separately.
>
> Well, the point is that this function *isn't* going to be known to the
> NLS code, so AFAICS no adjustments should be needed there. You did miss
> some places that ought to be updated (mumble sources.sgml mumble) but
> unless I hear objections to the whole idea, I'll fix and apply this
> tomorrow.
I find it strange to simply leave those strings untranslated. It's going
to look wrong, like someone just forgot to translate them. However, I
agree it's perhaps a bit too much detail to translate all of those
messages, and the translations would probably sound weird because there
isn't established terms for these things yet.
I think I would prefer something like this:
ERROR: could not serialize access due to read/write dependencies among
transactions
DETAIL: Reason code: %s
HINT: The transaction might succeed if retried.
Where %s gets the current detail field, untranslated, like:
Canceled on commit attempt with conflict in from prepared pivot.
Or perhaps shorten that to just "conflict in from prepared pivot", as
the fact that it happened on commit attempt should be clear from the
context - the error happened at a COMMIT statement.
That would be similar to what we do with OS error messages, with %m. It
would be more obvious that the untranslated message is some internal
information that the user is not expect to understand, and that it is
untranslated on purpose.
That's my 2c, anyway. I see you committed this already, I don't
violently object to that either...
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
