Re: A Japanese-unfriendy error message contruction

Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> writes:
> The "policy %s" and "<objname> %s" are transposed in Japaese
> syntax.  Specifically "<objname> %s NO <policy> %s" is the
> natural translation of "policy %s on <objname> %s". But currently
> we cannot get the natural error message in Japanese.

> For the reason, I'd like to propose to refactor
> getObjectDescription:OPCLASS_POLICY as the attached patch. The
> same structure is seen for OPCLASS_AMOP.

Taking a quick look through objectaddress.c, I see quite a lot of
deficiencies:

* Is it OK for the OCLASS_CLASS-with-subId case to assume that it can
tack on "column COLNAME" after the description of the relation containing
the column?  Perhaps this is tolerable but I'm not sure.  In English it'd
be at least as plausible to write "column COLNAME of <relation>", and
maybe there are other languages where there's no good way to deal with
the current message structure.

* Column default values are written as "default for %s" where %s is what
you get from the above.  This seems likely to be even more awkward; do we
need to flatten that into one translatable string instead of recursing?
(At the very least I wish it was "default value for %s".)

* Collations have namespaces, but the OCLASS_COLLATION code doesn't
account for that.  Likewise for conversions, extended statistics
objects, and all four types of text search objects.

* OCLASS_PUBLICATION_REL likewise neglects schema-qualification of the
relation name.  I wonder why it's not using getRelationDescription, too.

* Both OCLASS_AMOP and OCLASS_AMPROC have the problem that they plug
the translation of "operator family %s for access method %s" into
"<something> of %s".  I'm not sure how big a problem this is, or whether
it's worth the code-duplication needed to expose the whole thing as
one translatable message.  Opfamily members are pretty advanced things,
so maybe we shouldn't expend too much work on them.  (But if we do,
we should also take a look at the no-such-member error strings in
get_object_address_opf_member, which do the same thing.)

* The DEFACL code appends " in schema %s" after an otherwise
translatable message.  Do we need to fix that?

* OCLASS_RULE and OCLASS_TRIGGER use the same untranslatable style
as you complain of for OCLASS_POLICY.

The missing-schema-qualification issues seem like must-fix problems to me.
But not being a translator, I'm not sure how much of a problem each of the
other issues is.  I think that there was a deliberate decision at some
point that we'd accept some translation awkwardness in this code.  How
far do we want to go to clean it up?

            regards, tom lane