A Japanese-unfriendy error message contruction

2018-05-22 6:20 GMT-03:00 Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>:

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.

+1.

--
Euler Taveira Timbira -
http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento

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

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@sss.pgh.pa.us> wrote in <13575.1527013649@sss.pgh.pa.us>

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.

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

Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> writes:

At Tue, 22 May 2018 14:27:29 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in <13575.1527013649@sss.pgh.pa.us>

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

After thinking about this some more, I'd like to propose that we change
the English output to be "column COLNAME of <relation>", using code
similar to what you suggested for O_POLICY etc. I know that I've been
momentarily confused more than once by looking at obj_description output
and thinking "what, the whole relation depends on this? ... oh, no, it's
just the one column". It would be better if the head-word were "column".
If that leads to better translations in other languages, fine, but in
any case this'd be an improvement for English.

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

OK, I'll await your patch before doing more here.

regards, tom lane

Hello. Here is the patch set.

At Wed, 23 May 2018 11:20:24 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in <4979.1527088824@sss.pgh.pa.us>

After thinking about this some more, I'd like to propose that we change
the English output to be "column COLNAME of <relation>", using code
similar to what you suggested for O_POLICY etc. I know that I've been
momentarily confused more than once by looking at obj_description output
and thinking "what, the whole relation depends on this? ... oh, no, it's
just the one column". It would be better if the head-word were "column".
If that leads to better translations in other languages, fine, but in
any case this'd be an improvement for English.

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

OK, I'll await your patch before doing more here.

Constraints also have namespace but I understand it is just a
decoration so I left it alone.

1. Remove tranlation obstracles.
2. Show qualified names for all possible object types.
3. Changes "relation R column C" to "column C of relation R".

Extended statistics's name qualification is not excercised in the
current regression test.

I found that the last one you sugeested makes error messages far
cleaner, easy to grasp the meaning at a glance.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> writes:

Hello. Here is the patch set.

Thanks! I pushed all this plus fixes for the OCLASS_PUBLICATION_REL
code.

The only non-cosmetic change I made was that I didn't much like what
you'd done with the OCLASS_DEFACL code: it seemed quite confusing to
be renaming buffers like that, plus it was still assuming more than
I thought it should about how the message would go together in the end.
I took the advice of the manual instead, and just made pairs of
near-duplicate messages to be translated separately.

I'm still not sure whether the OCLASS_DEFAULT case is satisfactorily
translatable. It would not take a lot more code to expand its message to
"default value for column %s of %s", where the second %s is the result of
getRelationDescription. However, I have no idea whether there are any
translations where that would really work noticeably better.

regards, tom lane

At Thu, 24 May 2018 14:20:21 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in <24988.1527186021@sss.pgh.pa.us>

Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> writes:

Hello. Here is the patch set.

Thanks! I pushed all this plus fixes for the OCLASS_PUBLICATION_REL
code.

Thanks.

The only non-cosmetic change I made was that I didn't much like what
you'd done with the OCLASS_DEFACL code: it seemed quite confusing to
be renaming buffers like that, plus it was still assuming more than
I thought it should about how the message would go together in the end.
I took the advice of the manual instead, and just made pairs of
near-duplicate messages to be translated separately.

I wasn't sure that which way is better. This doubles the
msgids. But I can live with it since it would be scaecely
changed.

I'm still not sure whether the OCLASS_DEFAULT case is satisfactorily
translatable. It would not take a lot more code to expand its message to
"default value for column %s of %s", where the second %s is the result of
getRelationDescription. However, I have no idea whether there are any
translations where that would really work noticeably better.

True. I think we don't have difficulties as for Japanese
translation.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center