Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nGh0r-0002zN-Cp for pgsql-www@arkaria.postgresql.org; Sun, 06 Feb 2022 12:51:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nGh0o-0005KS-7m for pgsql-www@arkaria.postgresql.org; Sun, 06 Feb 2022 12:51:26 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nGh0o-0005KJ-0d for pgsql-www@lists.postgresql.org; Sun, 06 Feb 2022 12:51:26 +0000 Received: from mail-lf1-x135.google.com ([2a00:1450:4864:20::135]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nGh0j-00053g-Oz for pgsql-www@lists.postgresql.org; Sun, 06 Feb 2022 12:51:24 +0000 Received: by mail-lf1-x135.google.com with SMTP id k13so21777527lfg.9 for ; Sun, 06 Feb 2022 04:51:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hagander-net.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CGFu0+7DHIOkBRUH5mwFAbQgSS5M8+EMqYM37Ry5DHM=; b=jUMswXSKdK8o2nQpyE6dtydOQ0+gVd6KWhJrUJrqp2abLPXgME4Oo4ZrYXPH14Yk5N HxItiwBwzTVVcM4QzF3VomB5teOR5hZ3W6y5JzaBBV2/8Dyiq9NThSGgEZ21dsIZWxDZ mC7SyVO5F+m0alcLAUNsw/5j/BcIXMjiHX0gvq1QyVyejEWFjXmcAyPMfqbsUdF98ikZ NZzcwwtk1h9NepubJMJF3/IqyztjptPTipeDUnkMBIoNpHrU5CRKwsu79S6LvwMnq6yR +/eZzId7LcT+E7wqbNzJIpeoX/D9zu0r9Iyyr7031NPDevl1rTlxPokM0apiDbU0NRFB EcTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CGFu0+7DHIOkBRUH5mwFAbQgSS5M8+EMqYM37Ry5DHM=; b=kMc4zHgJkUUQlDph74KZT371nspgTfZFRJf52RtGyHYU7pbcPBzHxMVQjkC4s3ZyBT ZemWK/G3ice1Kr5b2wOw3Drt3Tdl1fxFRKdIzjdLmtW+2BuLCSoPq043b2lfAOEqiX06 Umx8t1XixX0sCnaMEh4GcnnRJ9THVP/e88UxQ9EusCFYsDMISyRyHk6Qyvz+s2ED9pKA jxXoS4386NuVvdITM11nquK+y9w5EcitMuWWNEb69O/fqfpJmR8DYc9fYTZphj0ygc0F pYObw1YQRTb+Y0I0Id8vM4C1iRBvRMfIcmO3NWANR3bWG3JPY1cdBO6QQAQINIS8g94U A+mw== X-Gm-Message-State: AOAM530X3QUbfRy7FtYa3SnhUG9E+wrdWsmLMruqfxT3XHLnbJBdwoAB dlerBnnT1svR4wsIVqn49FbgbDaqv5l3jf7LKAiLPg== X-Google-Smtp-Source: ABdhPJzUQgI21pYZVIPSTGz4aZcc62fZbv4VWb2h3n/pxUcK4L1jJS1/bt/GcqMSuvprZrIOF+xfiwKVBirmDWo+CkU= X-Received: by 2002:a19:3850:: with SMTP id d16mr5315723lfj.633.1644151880230; Sun, 06 Feb 2022 04:51:20 -0800 (PST) MIME-Version: 1.0 References: <20211107163140.rnqihhpwrc5vwt2l@nixos> <53D92024-85B0-4226-82A4-3A27CFA7880B@yesql.se> <31a6c019-83ef-2d12-b9c7-3829ee7977bf@postgresql.org> <835f0d02-cc23-d333-fb16-ef370ca2e68b@postgresql.org> <721b1b7d-873f-509b-7300-297cc65123bd@postgresql.org> In-Reply-To: <721b1b7d-873f-509b-7300-297cc65123bd@postgresql.org> From: Magnus Hagander Date: Sun, 6 Feb 2022 13:51:09 +0100 Message-ID: Subject: Re: [PATCH] Change text direction of documentation pages To: "Jonathan S. Katz" Cc: Daniel Gustafsson , Nils , pgsql-www@lists.postgresql.org, Peter Eisentraut Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Jan 18, 2022 at 5:28 PM Jonathan S. Katz wrote: > > On 1/17/22 11:01 AM, Magnus Hagander wrote: > > On Sun, Jan 2, 2022 at 11:03 PM Jonathan S. Katz wrote: > >> > >> On 11/29/21 4:16 AM, Daniel Gustafsson wrote: > >> > >>>> Overall OK with the approach, but would like to see how it renders. > >>> > >>> I don't have a local pgweb setup for now, so feel free to pick it up and play > >>> with it if you have time. > >> > >> Fast forward to the future, I went and played around with the suggested > >> patch, i.e.: > >> > >> - PostgreSQL: Documentation: {{page.display_version}}: > >> {{page.title}} > >> + {{page.title}} — PostgreSQL {{page.display_version}} > >> Documentation > >> > >> It looks OK...but I question having the chapter/section prefix in the > >> title, i.e.: > >> > >> "7.2 Table Expressions -- PostgreSQL 10 Documentation" > >> > >> (yes, I need to update my local copy of the docs). > >> > >> I think: > >> > >> "Table Expressions -- PostgreSQL 10 Documentation" > >> > >> would be better, esp. from the SEO perspective. This would also mean > >> adjusting our Open Graph tags to account for it from a display > >> perspective as well. And writing a function to strip out the prefix. > > > > You're talking about changing just the here right, and keeping > > it in the <hx> tags? > > Yes, just the title. Then that works for me. I think it's important to keep the <hx> heading be the same as it is in the source documents that we work from, but I'm perfectly OK changing the <title> part. > >> However, this opens up a few things: > >> > >> 1. On the main doc page, it now reads something like "PostgreSQL 13.5 > >> Documentation - PostgreSQL 13 Documentation." That should be simple > >> enough to adjust though. > >> > >> 2. On this page: > >> > >> https://www.postgresql.org/docs/10/typeconv-overview.html > >> > >> the title would then read "Overview -- PostgreSQL 10 Documentation", > >> which also seems off. So perhaps the general algorithm becomes: > >> > >> "Page Title -- Chapter Name -- PostgreSQL NN Documentation" > >> > >> which would make that: > >> > >> "Overview -- Type Conversation -- PostgreSQL 10 Documentation" > >> > >> So, I think this is a little more work. I would propose this: > >> > >> - In the doc loader script, extract the "chapter" name out of the > >> provided information and store it in DocPage OR dynamically extract it > >> while rendering a documentation page. I'm thinking the latter for this. > >> > >> - Have a "page title" in the documentation available without the > >> chapter/section prefix > >> > >> - Set the page title to be something like "Title w/o Prefix — > >> Chapter — PostgreSQL NN Documentation", with title/chapter dropped > >> if they're not present. > >> > >> Thoughts? > > > > Is this perhaps something that should be implemented in the docs > > builder step for all HTML rather than do it one way there and then > > try to change it for the website? > > > > I do like the idea in general. But that might be a better place? (Note > > that I have no idea how to actually do that, but I assume it can be > > done) > > Agreed that docs would likely be the better place to start. I can make a > vain attempt at this and see if I can come up with anything interesting. Yeah, unfortunately I don't know too much about that side of things to be able to help. Maybe Peter can? -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/