On Wed, 02 Oct 2024 14:52:58 +0900 (JST) Tatsuo Ishii <is...@postgresql.org> wrote:
> >> Currently the manual explains create subscription's "failover" > >> parameter as follows: > >> > >> <para> > >> Since no connection is made when this option is > >> <literal>false</literal>, no tables are subscribed. To initiate > >> replication, you must manually create the replication slot, > >> enable > >> the failover if required, enable the subscription, and refresh > >> the > >> subscription. See > >> <xref > >> linkend="logical-replication-subscription-examples-deferred-slot"/> > >> for examples. > >> </para> > >> > >> While translating it into Japanese, we were little confused what "the > >> failover" actually means because we thought it might refer to the > >> failover operation or the failover parameter in the command. After a > >> discussion in the translation team, we concluded that it must refer to > >> the failover parameter. If we were correct, it would be nice to add > >> <literal> tag to "failover" to make it clear that it refers to a > >> failover parameter. Attached is the patch to do that. > > > > I agreed with adding <literal> tag to "failover" since it is done in the > > description on "slot_name" parameter. > > > > How about also rewrite it to "enable the failover option" rather than simply > > "enable the failover" to clarify that the parameter is refereed to. > > > > We could also use "enable the failover parameter". I think both make sense, > > but > > it seems that "failover option" is preferred in the slot_name description. > > But a few lines above we have: > > <para> > This clause specifies optional parameters for a subscription. > </para> > > <para> > The following parameters control what happens during subscription > creation: > > So it seems "paramter" is more consistent than "option" here. For consistency, using "parameter" seems better. If we consider this, should we rewrite other places using "option" to use "parameter"? For example, I can find uses of "option" in the "connect", "slot_name", and "binary" descriptions in the CREATE SUBSCRIPTION document. Also, the "public" parameter in CREATE PUBLICATION doc, "vacuum_index_cleanup" and "vacuum_truncate" storage parameters in CREATE TABLE doc might be also targets to be rewritten. I am not sure if this covers all, though. Regards, Yugo Nagata > > Best reagards, > -- > Tatsuo Ishii > SRA OSS K.K. > English: http://www.sraoss.co.jp/index_en/ > Japanese:http://www.sraoss.co.jp -- Yugo NAGATA <nag...@sraoss.co.jp>
