Re: A Japanese-unfriendy error message contruction

Thank you for the suggestion.

Is there anyone using another language who is having difficulties
in translating some messages?

At Tue, 22 May 2018 14:27:29 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in <13575(dot)1527013649(at)sss(dot)pgh(dot)pa(dot)us>
> Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)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.

In Japanese it is written as "<reltype> RELNAME 'NO' <column> COLNAME"
the or just "<reltype> RELNAME <column> COLNAME" is no problem.

> * 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".)

I see this is constructed in the following structure.

| (default for ((table t) (column a))) depends on (sequence seq1)

In Japanese, a difference in this sentense is the order of the
outermost blocks so there's no problem here.

The topmost structure is "%s depends on %s" so it doesn't seem
modifiable into plnainer shape without adding duplications..

I agree that "values" make the sentense neater.

> * 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.

I'm not sure it is necessarily required. getObjectDescription
cares only for OPCLASS (and DEFACL), but we could do so for all
possible places with no difficulties.

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

The function takes ObjectAddresss which we don't have there.
It makes the code as the following, the format string looks
somewhat confusing..

| reladdr.classId = RelationRelationId;
| reladdr.objectId = prform->prrelid;
| reladdr.objectSubId = 0;
| appendStringInfo(&buffer, _("publication %s in publication %s"),
| getObjectDescription(&reladdr), pubname)

> * 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.)

Regarding Japanese, it is not a problem. It is specifically the
following

| (operator %d.... of (operator family %s for access method %s))

It is translated into Japanese as:

| ((<access method> %s <for="NO"> <operator family> %s) <of="NO"> operator %d....)

# Japanese suffers here from less variation of the syntactical
# element (postpossitional particle, "NO" in the above)
# corresnponding to preposition (for and of), but it is a
# different matter.

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

Ugg! You're right. It should be moved toward the beginning of the
sentence. Looking this, I noticed that some strings that should
be translatable are forgot to be enclosed with "_()".

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

# OCLASS_RULE would be OCLASS_REWRITE

Mmm. I don't remember that I saw such phrases in ja.po files but
it is surely that.

> 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?

I'll clean-up the two thinkgs and post the result later.

Thanks!

--
Kyotaro Horiguchi
NTT Open Source Software Center