bug#26302: [website] translations

[pelzflorian (Florian Pelz)]

On Sun, Jul 26, 2020 at 10:52:10AM -0700, Vagrant Cascadian wrote:
> Congrats on the translated website!

:)


> I noticed one minor issue, and that is it displays the
> language-selection drop-down with the current language's name for
> itself.
> 
> But if someone can't read the currently selected language, it's not
> obvious what they would click on to find a language they might
> understand. in other words:
> 
> 10:43 < vagrantc> civodul: the language-switching drop-down assumes you know 
> what the current language describes itself ...
> 10:43 < vagrantc> e.g. not immediately obvious to someone who doesn't
> know german to click on "deutsch" to switch language
> 
> 
> This is a difficult user-interface challenge to solve well, not sure
> what to do better... the flag method is commonly used, but has many
> tricky political problems, though it can convey a dense amount of
> information in a small space.
> 
> 
> live well,
>   vagrant

Perhaps there should be a stylized image of characters from various
languages.  I cannot draw well though.  sirgazil, WDYT?

Regards,
Florian

bug#26302: [website] translations

[Vagrant Cascadian]

Congrats on the translated website!

I noticed one minor issue, and that is it displays the
language-selection drop-down with the current language's name for
itself.

But if someone can't read the currently selected language, it's not
obvious what they would click on to find a language they might
understand. in other words:

10:43 < vagrantc> civodul: the language-switching drop-down assumes you know 
what the current language describes itself ...
10:43 < vagrantc> e.g. not immediately obvious to someone who doesn't
know german to click on "deutsch" to switch language


This is a difficult user-interface challenge to solve well, not sure
what to do better... the flag method is commonly used, but has many
tricky political problems, though it can convey a dense amount of
information in a small space.


live well,
  vagrant


signature.asc
Description: PGP signature

bug#26302: [website] translations

[pelzflorian (Florian Pelz)]

On Sun, Nov 17, 2019 at 05:17:02PM +0100, pelzflorian (Florian Pelz) wrote:
> I also noticed that Microsoft Internet Explorer 11 cannot display the
> new accessible dropdowns on https://guix.gnu.org/.i18n/en.

The issue was IE11 does not support the CSS value “initial”.  I pushed
a new version.  I tested IE11 and it works now.

I believe doing the changes I described in my past email (which I am
responding to) both for the HTTP and HTTPS location will give us a
working translatable website and preserve all URLs.  The
set_from_accept_language line probably need not and cannot be
specified for both locations though, once is enough, I think (perhaps
in extra-content).

Regards,
Florian

bug#26302: [website] translations

[pelzflorian (Florian Pelz)]

First on serving the internationalized website:

The following changes to maintenance:berlin redirect requests for old
URLs properly *only for non-HTTPS* in local testing on a vm-image.  I
assume the same will work when added for the HTTPS location, though
perhaps the line "set_from_accept_language $lang en de;" cannot or
need not be duplicated for both non-HTTPS and HTTPS.  I hope the
changes are compatible with the manual and cookbook URLs.  The changes
would better be tested more but I do not know how.


diff --git a/hydra/nginx/berlin.scm b/hydra/nginx/berlin.scm
index 2947759..8b66ba7 100644
--- a/hydra/nginx/berlin.scm
+++ b/hydra/nginx/berlin.scm
@@ -468,6 +468,10 @@ PUBLISH-URL."
 (uri "/guix")
 (body (list "root /var/www;")))
 
+   (nginx-location-configuration
+(uri "~ (.html|.htm)$")
+(body (list "try_files /$lang/$uri $uri =404;")))
+
(nginx-location-configuration  ;certbot
 (uri "/.well-known")
 (body (list "root /var/www;")
@@ -505,6 +509,9 @@ PUBLISH-URL."
 (root "/home/rekado/bootstrappable.org")
 (raw-content
  (list
+  "rewrite (.*)/$ $1/index.html;"
+  ;; put en first so it is the default:
+  "set_from_accept_language $lang en de;"
   "access_log /var/log/nginx/bootstrappable.access.log;")))
 
(nginx-server-configuration
@@ -767,5 +774,11 @@ PUBLISH-URL."
 (define %nginx-configuration
   (nginx-configuration
(server-blocks %berlin-servers)
+   (modules
+(list
+ ;; We need this module for redirecting users to the localized
+ ;; website of their choice.
+ (file-append nginx-accept-language-module "\
+/etc/nginx/modules/ngx_http_accept_language_module.so")))
(extra-content
 (string-join %extra-content "\n"



I attach a complete patch that can only be used for testing on a local
VM.  For testing, I perform the following steps:

cd ~/git/maintenance/hydra/
GUILE_LOAD_PATH=$(readlink -f ~/git/maintenance/hydra/modules):$GUILE_LOAD_PATH 
guix system vm-image --image-size=14G berlin.scm --fallback
cp /gnu/store/mm000wdzkzrvalg09jxk0y6nhi9c4iai-qemu-image berlin1.img
guix gc -D /gnu/store/mm000wdzkzrvalg09jxk0y6nhi9c4iai-qemu-image
chmod +w berlin1.img
qemu-system-x86_64 -enable-kvm berlin1.img -m 2048 -nic 
tap,ifname=tap0,script=no,downscript=no

Note that I use NetworkManager with dnsmasq for a tap0 host-to-guest
network connection as specified in the Guix manual.

---

Second, unrelated to serving the website:

I also noticed that Microsoft Internet Explorer 11 cannot display the
new accessible dropdowns on https://guix.gnu.org/.i18n/en.  Do we
care?  Perhaps the use of CSS z-index causes the problems.  The
previous dropdowns used display: none; which made the dropdowns
not-keyboard navigable.

Regards,
Florian
>From 3cfdd06a5f29b664666a002e4b49ecc82b157b5a Mon Sep 17 00:00:00 2001
From: Florian Pelz 
Date: Sun, 17 Nov 2019 17:12:11 +0100
Subject: [PATCH] [various changes for local testing]

---
 hydra/berlin.scm| 140 +---
 hydra/modules/sysadmin/services.scm |  66 
 hydra/nginx/berlin.scm  | 238 +---
 3 files changed, 41 insertions(+), 403 deletions(-)

diff --git a/hydra/berlin.scm b/hydra/berlin.scm
index fddf597..b34cf34 100644
--- a/hydra/berlin.scm
+++ b/hydra/berlin.scm
@@ -90,29 +90,9 @@ Happy hacking!\n"))
  ;; The root file system resides on just a single
  ;; disk, no RAID :-/
  (file-system
-   (device (file-system-label "my-root"))
+   (device "/dev/sda")
(mount-point "/")
(type "ext4"))
- ;; This is a large external storage array
- ;; connected via 2 HBA cards.  We only mount it
- ;; through one of the HBA cards.  We would need
- ;; to use multipathd otherwise.
- (file-system
-   (device (uuid "a6455b66-59d2-40bd-bddb-0c572bb62a2f"))
-   (mount-point "/gnu")
-   (type "ext4"))
- ;; Bind mount cache to large external storage.
- (file-system
-   (device "/gnu/cache")
-   (mount-point "/var/cache")
-   (flags '(bind-mount))
-   (type "none"))
- ;; Access root file system without bind mounts.
- (file-system
-   (device "/")
-   (mount-point "/mnt/root-fs")
-   (flags '(bind-mount))
-   (type "none"))
  %base-file-systems))
 
   ;; Local admin account for MDC maintenance.
@@ -132,69 +112,13 @@ Happy hacking!\n"))
%base-packages))
 
   (services (cons*
- ;; Connection to the DMZ for public access
- ;; This is a 1G port only
- (static-networking-service "eno1"
- 

bug#26302: [website] translations

[sirgazil via Bug reports for GNU Guix]

 On Fri, 08 Nov 2019 12:13:56 -0500 pelzflorian (Florian Pelz) 
 wrote 

 > > German is slightly wider than English and Chinese will be slightly 
 > > smaller.  Hopefully it won’t matter, otherwise the navbar could be put 
 > > in a div container with display: flex; or something for spacing 
 > > between elements. 
 > > 
 >  
 > For example, the navbar could be given a width 
 >  
 >  
 >  
 > and the ul inside could be given display:flex and justify-content 
 >  
 >  
 >  
 > Or not.  Maybe it is good as it is. 


Or we could wait until there is a visible problem :)

Eventually, it would be good to update the layout-related CSS of the website to 
use flex  and grid when appropriate. Maybe for another iteration :)

bug#26302: [website] translations

[pelzflorian (Florian Pelz)]

On Fri, Nov 08, 2019 at 05:18:28PM +0100, pelzflorian (Florian Pelz) wrote:
> I changed it now, also for the dropdowns.  The change is online now
> that the website was rebuilt.
> 
>

Dropdowns are fixed for real now.


> > But now that the width of the menu will vary depending on each
> > language, the whole menu bar will probably have to be redesigned.
> > 
> 
> German is slightly wider than English and Chinese will be slightly
> smaller.  Hopefully it won’t matter, otherwise the navbar could be put
> in a div container with display: flex; or something for spacing
> between elements.
> 

For example, the navbar could be given a width



and the ul inside could be given display:flex and justify-content



Or not.  Maybe it is good as it is.

Regards,
Florian

bug#26302: [website] translations

[pelzflorian (Florian Pelz)]

On Fri, Nov 08, 2019 at 05:18:29PM +0100, pelzflorian (Florian Pelz) wrote:
> I changed it now, also for the dropdowns.

Oops, dropdowns are not quite right yet.

bug#26302: [website] translations

[pelzflorian (Florian Pelz)]

On Fri, Nov 08, 2019 at 09:01:17AM -0500, sirgazil wrote:
> Hi, Florian :)
> 
>  On Fri, 08 Nov 2019 04:02:16 -0500 pelzflorian (Florian Pelz) 
>  wrote 
> 
>  > Another thing is that perhaps the CSS margin of the .menu-item:link 
>  > elements in the navbar should be reduced.  What do you think: 
>  >  
>  > https://guix.gnu.org/.i18n/de/ 
>  > https://guix.gnu.org/.i18n/en/ 
> 
> Yes. For now, I think "margin: 0px 2px" would be ok. 
> […]

I changed it now, also for the dropdowns.  The change is online now
that the website was rebuilt.


> But now that the width of the menu will vary depending on each
> language, the whole menu bar will probably have to be redesigned.
> 

German is slightly wider than English and Chinese will be slightly
smaller.  Hopefully it won’t matter, otherwise the navbar could be put
in a div container with display: flex; or something for spacing
between elements.

Regards,
Florian

bug#26302: [website] translations

[sirgazil via Bug reports for GNU Guix]

Hi, Florian :)

 On Fri, 08 Nov 2019 04:02:16 -0500 pelzflorian (Florian Pelz) 
 wrote 

 > Another thing is that perhaps the CSS margin of the .menu-item:link 
 > elements in the navbar should be reduced.  What do you think: 
 >  
 > https://guix.gnu.org/.i18n/de/ 
 > https://guix.gnu.org/.i18n/en/ 

Yes. For now, I think "margin: 0px 2px" would be ok. 

However, I noticed that the items with dropdown menus in 
https://guix.gnu.org/.i18n/de/ don't seem to have horizontal margin, while the 
rest of the items do. So the space between items is different, which also 
results in the items with subitems not aligning well with the other menu items 
in the narrow screen presentation.

But now that the width of the menu will vary depending on each language, the 
whole menu bar will probably have to be redesigned.

bug#26302: [website] translations

[pelzflorian (Florian Pelz)]

After Ludo’s reviews I’ve pushed and rebased everything again.  What
is missing is making nginx redirect accesses only to html files to
their localized version if one exists.  This would mean the
non-localized URLs remain valid and their use could be continued.

I would prefer if someone familiar with nginx could help here.

I have not researched enough to know how to redirect index files in
nginx, i.e. https://guix.gnu.org/contribute/ should serve
de/contribute/index.html.

The nginx accept language module can determine if it should redirect
to de or en like this:

diff --git a/hydra/nginx/berlin.scm b/hydra/nginx/berlin.scm
index 2947759..8b83d1e 100644
--- a/hydra/nginx/berlin.scm
+++ b/hydra/nginx/berlin.scm
@@ -468,6 +468,13 @@ PUBLISH-URL."
 (uri "/guix")
 (body (list "root /var/www;")))
 
+   (nginx-location-configuration
+(uri "~ (.html|.htm)$")
+(body (list
+   ;; put en first so it is the default:
+   "set_from_accept_language $lang en de;"
+   "try_files /$lang/$uri $uri =404;")))
+
(nginx-location-configuration  ;certbot
 (uri "/.well-known")
 (body (list "root /var/www;")
@@ -767,5 +774,11 @@ PUBLISH-URL."
 (define %nginx-configuration
   (nginx-configuration
(server-blocks %berlin-servers)
+   (load-modules
+(list
+ ;; We need this module for redirecting users to the localized
+ ;; website of their choice.
+ (file-append nginx-mod-accept-language "\
+/etc/nginx/modules/ngx_http_accept_language_module.so")))
(extra-content
 (string-join %extra-content "\n"


Another thing is that perhaps the CSS margin of the .menu-item:link
elements in the navbar should be reduced.  What do you think:

https://guix.gnu.org/.i18n/de/
https://guix.gnu.org/.i18n/en/

Regards,
Florian

bug#26302: [website] translations

[Ludovic Courtès]

Hello Florian,

"pelzflorian (Florian Pelz)"  skribis:

> From c9f7b2739392e0d8cf2afa6b2179b2e138c49bc7 Mon Sep 17 00:00:00 2001
> From: Florian Pelz 
> Date: Wed, 6 Nov 2019 19:28:57 +0100
> Subject: [PATCH] doc: Add clarification on the '--source' build option.
>
> Emphasize that what the '--source' build option downloads is insufficient for
> reproducing the packages.
>
> * doc/guix.texi (Additional Build Options): Explain more.

Alrighty, LGTM!

Thank you,
Ludo’.

bug#26302: [website] translations

[pelzflorian (Florian Pelz)]

On Wed, Nov 06, 2019 at 03:56:48PM +0100, Ludovic Courtès wrote:
> I don’t feel strongly about it, but to me, this is a discussion and thus
> not quite in line with the style of this section as a reference of ‘guix
> build’ options.
> 
> As far as the discussion goes :-), I’d argue that the Corresponding
> Source in the spirit of the GPL is the derivation rather than what
> ‘--sources’ returns, since the Corresponding Source should include
> “build scripts”.  I would argue that only functional package managers
> are able to support such a strong notion of Corresponding Source.
> 
> Long story short: the discussion is not clear-cut and I’m not sure it
> belongs here.  :-)
> 
> Thoughts?
> 
> Thanks,
> Ludo’.

Well said.  You convinced me not to make a recommendation.  Thank you.
I still was surprised about `guix build -S` so I attach a new
proposal.

Regards,
Florian
>From c9f7b2739392e0d8cf2afa6b2179b2e138c49bc7 Mon Sep 17 00:00:00 2001
From: Florian Pelz 
Date: Wed, 6 Nov 2019 19:28:57 +0100
Subject: [PATCH] doc: Add clarification on the '--source' build option.

Emphasize that what the '--source' build option downloads is insufficient for
reproducing the packages.

* doc/guix.texi (Additional Build Options): Explain more.
---
 doc/guix.texi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/doc/guix.texi b/doc/guix.texi
index 30706d9ddd..58b8e41ab4 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -8336,6 +8336,11 @@ The returned source tarball is the result of applying 
any patches and
 code snippets specified in the package @code{origin} (@pxref{Defining
 Packages}).
 
+Note that @command{guix build -S} compiles the sources only of the
+specified packages.  They do not include the sources of statically
+linked dependencies and by themselves are insufficient for reproducing
+the packages.
+
 @item --sources
 Fetch and return the source of @var{package-or-derivation} and all their
 dependencies, recursively.  This is a handy way to obtain a local copy
-- 
2.23.0

bug#26302: [website] translations

[pelzflorian (Florian Pelz)]

On Wed, Nov 06, 2019 at 03:49:46PM +0100, Ludovic Courtès wrote:
> Nitpick: I’d replace “Should be […] For example:” by “This should be a
> list of file names of loadable modules, as in this example:”.
> 
> Otherwise LGTM!
> 
> Ludo’.

I agree.  Thank you!  I copied your wording verbatim and will push
the nginx patches tomorrow.

Regards,
Florian

bug#26302: [website] translations

[Ludovic Courtès]

Hi!

"pelzflorian (Florian Pelz)"  skribis:

> From 04df1e5ee3fd542776b13eb3a59872e1647eb5f8 Mon Sep 17 00:00:00 2001
> From: Florian Pelz 
> Date: Tue, 5 Nov 2019 08:08:20 +0100
> Subject: [PATCH 03/13] services: Make it possible to include dynamic modules
>  in nginx.
>
> * gnu/services/web.scm (): Add modules field.
> (nginx-configuration-modules): New field accessor.
> (emit-load-module): New procedure.
> (default-nginx-config): Add support for the modules field.
> * doc/guix.texi (NGINX): Document it.

[…]

> +@item @code{modules} (default: @code{'()})
> +List of nginx dynamic modules to load.  Should be a list of strings or
> +string valued G-expressions.  For example:

Nitpick: I’d replace “Should be […] For example:” by “This should be a
list of file names of loadable modules, as in this example:”.

Otherwise LGTM!

Ludo’.

bug#26302: [website] translations

[pelzflorian (Florian Pelz)]

On Tue, Nov 05, 2019 at 08:31:30AM +0100, pelzflorian (Florian Pelz) wrote:
> +Note that @command{guix build -S} compiles the sources only of the
> +specified package.

Another try, I changed s/package/packages/ (attached).

Regards,
Florian
>From a5d9180d960d244053bea0d59d6092060fe4c6dd Mon Sep 17 00:00:00 2001
From: Florian Pelz 
Date: Tue, 5 Nov 2019 12:08:54 +0100
Subject: [PATCH 01/13] doc: Explain more licensing aspects of the '--source'
 build option.

* doc/guix.texi (Additional Build Options): Explain more.
---
 doc/guix.texi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/doc/guix.texi b/doc/guix.texi
index da2423b422..d8886fa494 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -8328,6 +8328,13 @@ The returned source tarball is the result of applying 
any patches and
 code snippets specified in the package @code{origin} (@pxref{Defining
 Packages}).
 
+Note that @command{guix build -S} compiles the sources only of the
+specified packages.  They do not include the sources of statically
+linked dependencies, dynamically linked dependencies, or any other
+dependencies.  When distributing complete corresponding sources for
+license compliance, you may want to play it safe and use the following
+@code{--sources} option instead.
+
 @item --sources
 Fetch and return the source of @var{package-or-derivation} and all their
 dependencies, recursively.  This is a handy way to obtain a local copy
-- 
2.23.0

bug#26302: [website] translations

[Ludovic Courtès]

Hi,

"pelzflorian (Florian Pelz)"  skribis:

> On Fri, Nov 01, 2019 at 03:54:42PM +0100, Ludovic Courtès wrote:
>> > + (modules '((guix build utils)
>> > +(ice-9 popen)))
>> > + (snippet
>> > +  #~(begin
>> > +  ;; the nginx source code is part of the module’s source
>> > +  (format #t "decompressing nginx source code~%")
>> > +  (call-with-output-file "nginx.tar"
>> > +(lambda (out)
>> > +  (let ((pipe (open-pipe* OPEN_READ
>> > +  #+(file-append gzip 
>> > "/bin/gzip") "-cd"
>> > +  #$(package-source nginx
>> > +(dump-port pipe out)
>> > +(unless (= (status:exit-val (close-pipe pipe)) 0)
>> > +  (error "gzip decompress failed")
>> > +  (invoke #+(file-append tar "/bin/tar") "xvf" "nginx.tar"
>> > +  "--strip-components=1")
>> > +  (delete-file "nginx.tar")
>> 
>> I’d suggest doing it in a phase.
>
> This changes many things. :)
>
> With a phase, `guix build -S` would only return the source files of
> nginx-accept-language-module directly but not of statically linked
> nginx.  I have added a further patch to doc/guix.texi warning of `guix
> build -S` not always returning complete and corresponding sources, see
> attachment.
>
> The good thing is that with a phase I no longer get an import cycle
> because I no longer need a reference to the tar package.  So I put
> nginx-accept-language-module inside web.scm now and there is no need
> for a separate module.

Good!

>> > +  (license (delete-duplicates
>> > +(cons license:bsd-2 ;license of nginx-mod-accept-language
>> > +  (package-license nginx))) ;the module’s code is 
>> > linked
>> 
>> To avoid circular dependencies in top-level references, I suggest
>> copying the license of ‘nginx’ instead of writing (package-license
>> nginx).
>> 
>
> I believe this is no longer an issue now that
> nginx-accept-language-module is in the same Guile module as nginx, is
> it?

You’re right: it’s no longer an issue.

>> > +++ b/gnu/packages/web-xyz.scm
>> > @@ -0,0 +1,175 @@
>> > +;;; GNU Guix --- Functional package management for GNU
>> > + TODO should I really add copyright lines for people I copied from??
>> > +;;; Copyright © 2014, 2015 Mark H Weaver 
>> > +;;; Copyright © 2016 Tobias Geerinckx-Rice 
>> > +;;; Copyright © 2017, 2018 Marius Bakke 
>> 
>> I don’t think you need to add these 3 lines here; the package definition
>> is yours.
>> 
>
> This does not matter anymore after putting
> nginx-accept-language-module in the same Guile module file as nginx.
>
> In general though: IANAL but I have largely copied nginx’ configure
> phase, so at least Mark would surely have copyright on parts of it.
> However I believe copyright lines have limited legal significance
> anyway and adding these authorship lines in a file not added by Mark
> seems unreasonable.

Agreed.

>> […]
>> Perhaps “nginx-accept-language-module”, to match the name of the
>> upstream repo?
>> 
>
> I agree.  Arch (who have no package for nginx-accept-language-module)
> change their various nginx module package names to be more consistent,
> I think, but this is not necessary in Guix, I think.

For Guix the general rule is to follow upstream (info "(guix) Package
Naming").

> From b6da504736866bae655e2b4025729345e1ea19b7 Mon Sep 17 00:00:00 2001
> From: Florian Pelz 
> Date: Sat, 2 Nov 2019 13:13:01 +0100
> Subject: [PATCH 1/3] doc: Add warning on the '--source' build option when
>  linking statically.
>
> * doc/guix.texi (Additional Build Options): Add warning.
> ---
>  doc/guix.texi | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/doc/guix.texi b/doc/guix.texi
> index da2423b422..30b69d8869 100644
> --- a/doc/guix.texi
> +++ b/doc/guix.texi
> @@ -8328,6 +8328,12 @@ The returned source tarball is the result of applying 
> any patches and
>  code snippets specified in the package @code{origin} (@pxref{Defining
>  Packages}).
>  
> +Note that for statically linked packages, @command{guix build -S} will
> +@emph{not} return the complete and corresponding sources since these
> +would include the sources of statically linked dependencies.  In this
> +case, when distributing sources for license compliance, you may want to
> +play it safe and use the following @code{--sources} option instead.

I don’t think this bit is necessary: ‘-S’ is documented to return “the
source of the package” and that’s exactly what it does; static
vs. dynamic linking is not a concern at this level, as I see it.

WDYT?

> From 21e6064f42defad1e2d35bbf95a4825fec9e4615 Mon Sep 17 00:00:00 2001
> From: Florian Pelz 
> Date: Sat, 2 Nov 2019 12:43:47 +0100
> Subject: [PATCH 2/3] gnu: Add Nginx Accept Language module.
>
> * gnu/packages/web.scm (nginx-accept-language-module): New 

bug#26302: [website] translations

[pelzflorian (Florian Pelz)]

Thank you for your review!  I have attached updated patches.

I have some questions.  I’d like to answer but not in order.  First of
all,

On Fri, Nov 01, 2019 at 03:54:42PM +0100, Ludovic Courtès wrote:
> > + (modules '((guix build utils)
> > +(ice-9 popen)))
> > + (snippet
> > +  #~(begin
> > +  ;; the nginx source code is part of the module’s source
> > +  (format #t "decompressing nginx source code~%")
> > +  (call-with-output-file "nginx.tar"
> > +(lambda (out)
> > +  (let ((pipe (open-pipe* OPEN_READ
> > +  #+(file-append gzip "/bin/gzip") 
> > "-cd"
> > +  #$(package-source nginx
> > +(dump-port pipe out)
> > +(unless (= (status:exit-val (close-pipe pipe)) 0)
> > +  (error "gzip decompress failed")
> > +  (invoke #+(file-append tar "/bin/tar") "xvf" "nginx.tar"
> > +  "--strip-components=1")
> > +  (delete-file "nginx.tar")
> 
> I’d suggest doing it in a phase.

This changes many things. :)

With a phase, `guix build -S` would only return the source files of
nginx-accept-language-module directly but not of statically linked
nginx.  I have added a further patch to doc/guix.texi warning of `guix
build -S` not always returning complete and corresponding sources, see
attachment.

The good thing is that with a phase I no longer get an import cycle
because I no longer need a reference to the tar package.  So I put
nginx-accept-language-module inside web.scm now and there is no need
for a separate module.


> > +  (license (delete-duplicates
> > +(cons license:bsd-2 ;license of nginx-mod-accept-language
> > +  (package-license nginx))) ;the module’s code is 
> > linked
> 
> To avoid circular dependencies in top-level references, I suggest
> copying the license of ‘nginx’ instead of writing (package-license
> nginx).
> 

I believe this is no longer an issue now that
nginx-accept-language-module is in the same Guile module as nginx, is
it?


> > +++ b/gnu/packages/web-xyz.scm
> > @@ -0,0 +1,175 @@
> > +;;; GNU Guix --- Functional package management for GNU
> > + TODO should I really add copyright lines for people I copied from??
> > +;;; Copyright © 2014, 2015 Mark H Weaver 
> > +;;; Copyright © 2016 Tobias Geerinckx-Rice 
> > +;;; Copyright © 2017, 2018 Marius Bakke 
> 
> I don’t think you need to add these 3 lines here; the package definition
> is yours.
> 

This does not matter anymore after putting
nginx-accept-language-module in the same Guile module file as nginx.

In general though: IANAL but I have largely copied nginx’ configure
phase, so at least Mark would surely have copyright on parts of it.
However I believe copyright lines have limited legal significance
anyway and adding these authorship lines in a file not added by Mark
seems unreasonable.


> […]
> Perhaps “nginx-accept-language-module”, to match the name of the
> upstream repo?
> 

I agree.  Arch (who have no package for nginx-accept-language-module)
change their various nginx module package names to be more consistent,
I think, but this is not necessary in Guix, I think.


On Fri, Nov 01, 2019 at 03:58:43PM +0100, Ludovic Courtès wrote:
> Regarding the build system of nginx modules, we’ll see when
> we have more than one module packaged.  :-)
> 

Good. This module is not typical and writing a build system would be
difficult now.

Regards,
Florian
>From b6da504736866bae655e2b4025729345e1ea19b7 Mon Sep 17 00:00:00 2001
From: Florian Pelz 
Date: Sat, 2 Nov 2019 13:13:01 +0100
Subject: [PATCH 1/3] doc: Add warning on the '--source' build option when
 linking statically.

* doc/guix.texi (Additional Build Options): Add warning.
---
 doc/guix.texi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/doc/guix.texi b/doc/guix.texi
index da2423b422..30b69d8869 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -8328,6 +8328,12 @@ The returned source tarball is the result of applying 
any patches and
 code snippets specified in the package @code{origin} (@pxref{Defining
 Packages}).
 
+Note that for statically linked packages, @command{guix build -S} will
+@emph{not} return the complete and corresponding sources since these
+would include the sources of statically linked dependencies.  In this
+case, when distributing sources for license compliance, you may want to
+play it safe and use the following @code{--sources} option instead.
+
 @item --sources
 Fetch and return the source of @var{package-or-derivation} and all their
 dependencies, recursively.  This is a handy way to obtain a local copy
-- 
2.23.0

>From 21e6064f42defad1e2d35bbf95a4825fec9e4615 Mon Sep 17 00:00:00 2001
From: Florian Pelz 
Date: Sat, 2 Nov 2019 12:43:47 +0100
Subject: [PATCH 2/3] gnu: Add Nginx Accept Language module.

* 

bug#26302: [website] translations

[Ludovic Courtès]

Hi Florian

"pelzflorian (Florian Pelz)"  skribis:

>>From 9ec69c888b978cb870a5873af8e327541fe4ef7a Mon Sep 17 00:00:00 2001
> From: Florian Pelz 
> Date: Sun, 6 Oct 2019 20:45:34 +0200
> Subject: [PATCH 1/2] [wip] gnu: Add ngx_http_accept_language_module.
>
> * gnu/packages/web-xyz.scm: New file.
> * gnu/local.mk (GNU_SYSTEM_MODULES): Add package.

[...]

> +++ b/gnu/packages/web-xyz.scm
> @@ -0,0 +1,175 @@
> +;;; GNU Guix --- Functional package management for GNU
> + TODO should I really add copyright lines for people I copied from??
> +;;; Copyright © 2014, 2015 Mark H Weaver 
> +;;; Copyright © 2016 Tobias Geerinckx-Rice 
> +;;; Copyright © 2017, 2018 Marius Bakke 

I don’t think you need to add these 3 lines here; the package definition
is yours.

> +(define-public nginx-mod-accept-language
> +  (let ((commit "2f69842f83dac77f7d98b41a2b31b13b87aeaba7")
> +(revision "1"))

Is there no upstream version?  If that’s the case, that’s fine, but
please add a comment explaining it.

> +(package
> +  (name "nginx-mod-accept-language")

Perhaps “nginx-accept-language-module”, to match the name of the
upstream repo?

> + (modules '((guix build utils)
> +(ice-9 popen)))
> + (snippet
> +  #~(begin
> +  ;; the nginx source code is part of the module’s source
> +  (format #t "decompressing nginx source code~%")
> +  (call-with-output-file "nginx.tar"
> +(lambda (out)
> +  (let ((pipe (open-pipe* OPEN_READ
> +  #+(file-append gzip "/bin/gzip") 
> "-cd"
> +  #$(package-source nginx
> +(dump-port pipe out)
> +(unless (= (status:exit-val (close-pipe pipe)) 0)
> +  (error "gzip decompress failed")
> +  (invoke #+(file-append tar "/bin/tar") "xvf" "nginx.tar"
> +  "--strip-components=1")
> +  (delete-file "nginx.tar")

I’d suggest doing it in a phase.

> +  (license (delete-duplicates
> +(cons license:bsd-2 ;license of nginx-mod-accept-language
> +  (package-license nginx))) ;the module’s code is 
> linked

To avoid circular dependencies in top-level references, I suggest
copying the license of ‘nginx’ instead of writing (package-license
nginx).

> +nginx-configuration-load-modules
>  nginx-configuration-extra-content
>  nginx-configuration-file
>  
> @@ -522,6 +524,7 @@
>   (default #f))
>(server-names-hash-bucket-max-size 
> nginx-configuration-server-names-hash-bucket-max-size
>   (default #f))
> +  (load-modules nginx-configuration-load-modules (default '()))

What about “loaded-modules”, “loadable-modules”, or simply “modules”?
“load-modules” sounds imperative whereas the rest of the config is
declarative.

Apart from that it LGTM.

>>From ea5edd15586722b3557912e81171e69f7be339fa Mon Sep 17 00:00:00 2001
> From: Florian Pelz 
> Date: Mon, 7 Oct 2019 07:58:30 +0200
> Subject: [PATCH] berlin: Redirect to localized website depending on
>  Accept-Language header.
>
> * hydra/nginx/berlin.scm (guix.gnu.org-locations): Redirect html URLs.
> (%nginx-configuration): Load required nginx dynamic module.

LGTM, but I guess we’ll commit it when we’re ready to switch to the new
web site.

Thanks!

Ludo’.

bug#26302: [website] translations

[pelzflorian (Florian Pelz)]

On Tue, Oct 22, 2019 at 02:10:59PM +0200, Ludovic Courtès wrote:
> Sorry that it’s taken this long, but I’m happy to say that the
> ‘wip-i18n’ branch of the manual is now visible at:
> 
>   https://guix.gnu.org/.i18n/de/
>   https://guix.gnu.org/.i18n/en/
> 

I have finally rebased wip-i18n, so these URLs display properly now.
I would like to squash some of my further commits there though.


On Tue, Oct 22, 2019 at 02:28:40PM +0200, pelzflorian (Florian Pelz) wrote:
> On Tue, Oct 22, 2019 at 02:10:59PM +0200, Ludovic Courtès wrote:
> > We’ll need the nginx magic to honor ‘Accept-Language’ and such; I think
> > you submitted something that I may have overlooked, don’t hesitate to
> > refresh my mind.  :-)
> >
> > Anyway, we have a good starting point, and perhaps we’ll be able to
> > switch quickly; what else do we need?
> > 
> > 
> 
> 
> I would be happy if you could review my Guix patches at
> 
> https://lists.gnu.org/archive/html/bug-guix/2019-10/msg00068.html
> 
> After that I also sent maintenance patches, but redirection only works
> for URLs ending in .html right now…
> 

IMHO the next step could be my above patch which packages
ngx_http_accept_language_module.  I do not yet know how to redirect
index files in nginx though.  Long-term, nginx modules should get
their own build system though, I suppose.

Regards,
Florian

bug#26302: [website] translations

[pelzflorian (Florian Pelz)]

On Wed, Oct 23, 2019 at 04:16:30PM +0200, Ludovic Courtès wrote:
> > Also it appears I broke URLs to the manual.
> 
> Which URLs specifically?
> 

Only the hyperlinks to the manual in .i18n.  Sorry for being
imprecise.  Nothing outside is broken.

> BTW, feel free to rebase ‘wip-i18n’ and to fix issues you stumble upon
> in that branch.  With this setup we should be able to see the changes
> on-line automatically, so it’s a great way to get the ball rolling!
> 

Will do tomorrow.  Then I will check why the stylesheet URLs are
wrong.  Thank you for this setup.

Regards,
Florian

bug#26302: [website] translations

[Ludovic Courtès]

Hi,

"pelzflorian (Florian Pelz)"  skribis:

> On Tue, Oct 22, 2019 at 02:28:40PM +0200, pelzflorian (Florian Pelz) wrote:
>> The CSS is not loaded from the .i18n subdirectory, it seems.
>> 
>
> I suppose your fix at
>
> https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/commit/?id=0d627303680ef21efd63fba0728e39afc08d67eb
>
> would address it had I rebased.

I rebased some time ago and I think this fix is included (I added it
specifically for this purpose).

> Also it appears I broke URLs to the manual.

Which URLs specifically?

BTW, feel free to rebase ‘wip-i18n’ and to fix issues you stumble upon
in that branch.  With this setup we should be able to see the changes
on-line automatically, so it’s a great way to get the ball rolling!

Thanks,
Ludo’.

bug#26302: [website] translations

[pelzflorian (Florian Pelz)]

On Tue, Oct 22, 2019 at 02:28:40PM +0200, pelzflorian (Florian Pelz) wrote:
> > Whenever you push to that branch, the web site should be automatically
> > updated within an hour.
> > 
> 
> I will rebase wip-i18n later this week and when the documentation
> videos are decided.
> 

Also it appears I broke URLs to the manual.

bug#26302: [website] translations

[pelzflorian (Florian Pelz)]

On Tue, Oct 22, 2019 at 02:28:40PM +0200, pelzflorian (Florian Pelz) wrote:
> The CSS is not loaded from the .i18n subdirectory, it seems.
> 

I suppose your fix at

https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/commit/?id=0d627303680ef21efd63fba0728e39afc08d67eb

would address it had I rebased.

Regards,
Florian

bug#26302: [website] translations

[pelzflorian (Florian Pelz)]

On Tue, Oct 22, 2019 at 02:10:59PM +0200, Ludovic Courtès wrote:
> Sorry that it’s taken this long, but I’m happy to say that the
> ‘wip-i18n’ branch of the manual is now visible at:
> 
>   https://guix.gnu.org/.i18n/de/
>   https://guix.gnu.org/.i18n/en/
> 

Thank you. :)


> Whenever you push to that branch, the web site should be automatically
> updated within an hour.
> 

I will rebase wip-i18n later this week and when the documentation
videos are decided.



> In IceCat the navigation bar at the top with “radio buttons” gets
> incorrectly displayed for some reason.
>

The CSS is not loaded from the .i18n subdirectory, it seems.


> We’ll need the nginx magic to honor ‘Accept-Language’ and such; I think
> you submitted something that I may have overlooked, don’t hesitate to
> refresh my mind.  :-)
>
> Anyway, we have a good starting point, and perhaps we’ll be able to
> switch quickly; what else do we need?
> 
> 


I would be happy if you could review my Guix patches at

https://lists.gnu.org/archive/html/bug-guix/2019-10/msg00068.html

After that I also sent maintenance patches, but redirection only works
for URLs ending in .html right now…


Regards,
Florian

bug#26302: [website] translations

[Ludovic Courtès]

Hello Florian and all!

(Cc: sirgazil + Julien.)

Ludovic Courtès  skribis:

> I think you can go ahead and push this series to a branch, say
> ‘wip-i18n’ (the ‘wip-’ prefix meaning that you reserve the right to
> rebase the branch as you will.)
>
> We can then maybe set up a ‘static-web-site’ service on berlin, with
> appropriate nginx rules, to build and publish the manual at a separate
> URL so we can all test it.  See hydra/berlin.scm in maintenance.git.

Sorry that it’s taken this long, but I’m happy to say that the
‘wip-i18n’ branch of the manual is now visible at:

  https://guix.gnu.org/.i18n/de/
  https://guix.gnu.org/.i18n/en/

Whenever you push to that branch, the web site should be automatically
updated within an hour.

In IceCat the navigation bar at the top with “radio buttons” gets
incorrectly displayed for some reason.

We’ll need the nginx magic to honor ‘Accept-Language’ and such; I think
you submitted something that I may have overlooked, don’t hesitate to
refresh my mind.  :-)

Anyway, we have a good starting point, and perhaps we’ll be able to
switch quickly; what else do we need?


For the record, the changes to the config of berlin.guix.gnu.org to make
it possible were:

  
https://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=e86c686b607a0f772ae004db021181607ba805ee

Thanks,
Ludo’.

bug#26302: [website] translations

[pelzflorian (Florian Pelz)]

On Mon, Oct 07, 2019 at 10:15:03AM +0200, pelzflorian (Florian Pelz) wrote:
> (Redirects of
> non-html URLs are wrong and nginx does not run with this config,
> perhaps I should use rewrite instead of try_files.  I can try later
> today.)
>

I changed the patch and while nginx loads, redirects for files without
html suffix still fail.  I will stop and wait for smarter people with
more nginx experience.  Attached is the current patch and changes I
make to berlin for testing in a local VM using

GUILE_LOAD_PATH=$(readlink -f ~/git/maintenance/hydra/modules):$GUILE_LOAD_PATH 
guix system vm-image --image-size=14G berlin.scm --fallback

Regards,
Florian
>From ef1d268cd75219c18ef098389a8ea5ef460ee542 Mon Sep 17 00:00:00 2001
From: Florian Pelz 
Date: Tue, 8 Oct 2019 08:30:59 +0200
Subject: [PATCH] berlin: Redirect to localized website depending on
 Accept-Language header.

* hydra/nginx/berlin.scm (guix.gnu.org-locations): Redirect html URLs.
(%nginx-configuration): Load required nginx dynamic module.
---
 hydra/nginx/berlin.scm | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/hydra/nginx/berlin.scm b/hydra/nginx/berlin.scm
index df90873..c716103 100644
--- a/hydra/nginx/berlin.scm
+++ b/hydra/nginx/berlin.scm
@@ -1,6 +1,7 @@
 ;; Nginx configuration for ci.guix.info
 
-(use-modules (gnu services web))
+(use-modules (gnu packages web-xyz)
+ (gnu services web))
 
 ;; TODO: these settings cannot currently expressed with Guix:
 
@@ -462,6 +463,16 @@ PUBLISH-URL."
(nginx-location-configuration
 (uri "~ \\.pdf$") ;*.pdf at the top level
 (body (list "root /srv/guix-pdfs;")))
+   (nginx-location-configuration
+(uri "~ (.*)/$")
+(body (list
+   "try_files $1/index.html =404;")))
+   (nginx-location-configuration
+(uri "~ (.html|.htm)$")
+(body (list
+   ;; put en first so it is the default:
+   "set_from_accept_language $lang en de;"
+   "try_files /$lang/$uri $uri =404;")))
 
(nginx-location-configuration  ;certbot
 (uri "/.well-known")
@@ -758,5 +769,11 @@ PUBLISH-URL."
 (define %nginx-configuration
   (nginx-configuration
(server-blocks %berlin-servers)
+   (load-modules
+(list
+ ;; We need this module for redirecting users to the localized
+ ;; website of their choice.
+ (file-append nginx-mod-accept-language "\
+/etc/nginx/modules/ngx_http_accept_language_module.so")))
(extra-content
 (string-join %extra-content "\n"
-- 
2.23.0

diff --git a/hydra/berlin.scm b/hydra/berlin.scm
index 172c9cd..d965770 100644
--- a/hydra/berlin.scm
+++ b/hydra/berlin.scm
@@ -90,29 +90,29 @@ Happy hacking!\n"))
  ;; The root file system resides on just a single
  ;; disk, no RAID :-/
  (file-system
-   (device (file-system-label "my-root"))
+   (device "/dev/sda");(file-system-label "my-root"))
(mount-point "/")
(type "ext4"))
- ;; This is a large external storage array
- ;; connected via 2 HBA cards.  We only mount it
- ;; through one of the HBA cards.  We would need
- ;; to use multipathd otherwise.
- (file-system
-   (device (uuid "a6455b66-59d2-40bd-bddb-0c572bb62a2f"))
-   (mount-point "/gnu")
-   (type "ext4"))
- ;; Bind mount cache to large external storage.
- (file-system
-   (device "/gnu/cache")
-   (mount-point "/var/cache")
-   (flags '(bind-mount))
-   (type "none"))
- ;; Access root file system without bind mounts.
- (file-system
-   (device "/")
-   (mount-point "/mnt/root-fs")
-   (flags '(bind-mount))
-   (type "none"))
+ ;; ;; This is a large external storage array
+ ;; ;; connected via 2 HBA cards.  We only mount it
+ ;; ;; through one of the HBA cards.  We would need
+ ;; ;; to use multipathd otherwise.
+ ;; (file-system
+ ;;   (device (uuid "a6455b66-59d2-40bd-bddb-0c572bb62a2f"))
+ ;;   (mount-point "/gnu")
+ ;;   (type "ext4"))
+ ;; ;; Bind mount cache to large external storage.
+ ;; (file-system
+ ;;   (device "/gnu/cache")
+ ;;   (mount-point "/var/cache")
+ ;;   (flags '(bind-mount))
+ ;;   (type "none"))
+ ;; ;; Access root file system without bind mounts.
+ ;; (file-system
+ ;;   (device "/")
+ ;;   (mount-point "/mnt/root-fs")
+ ;;   (flags '(bind-mount))
+ ;;   (type 

bug#26302: [website] translations

[pelzflorian (Florian Pelz)]

The branch wip-i18n is pushed now.

On Thu, Sep 19, 2019 at 01:50:10PM +0200, Ludovic Courtès wrote:
> Hi,
> 
> "pelzflorian (Florian Pelz)"  skribis:
> 
> >> > +(define (sgettext x)
> >> > +  "After choosing an identifier for marking s-expressions for
> >> > +translation, make it usable by defining a macro with it calling
> >> > +sgettext.  If for example the chosen identifier is G_,
> >> > +use (define-syntax G_ sgettext)."
> >> > +  (syntax-case x ()
> >> > +((id exp)
> >> > + (let* ((msgid (sexp->msgid (syntax->datum #'exp)))
> >> > +(new-exp (deconstruct (syntax->datum #'exp)
> >> > +  (gettext msgid
> >> > +   (datum->syntax #'id new-exp)
> >> 
> >> For this and other similar macros you must use ‘define-syntax’, not
> >> ‘define’, so that they are defined at expansion time, not at run time.
> >
> > As per the above docstring, I already have a definition
> >
> >   (define-syntax G_ sgettext)
> >
> > in (apps i18n).  Possibly I should just move it here.
> 
> Hmmm right.  It works, but it’s surprising and “borderline”.
> 
> If all you want is an alias,

Yes, an alias is what I wanted, like gettext.


> I’d recommend writing, say:
> 
>   (define-syntax sgettext …)
>   (define-syntax G_
> (identifier-syntax sgettext))
> 

This breaks the code, I think because the sgettext result gets
evaluated in a clean environment which lacks surrounding variables.
For example,

(let ((i 5) (G_ `("There are " ,i " apples"

fails to resolve i.

I have left this borderline code as it is.


> >> (It doesn’t make any difference when you’re evaluating code since both
> >> phases run in the same module, but it does make a difference when these
> >> phases happen at different times, in different processes.)
> >> 
> >> Consequently, you must arrange for ‘sexp->msgid’ and ‘deconstruct’ to be
> >> available at expansion time too.  This can be done by wrapping their
> >> definition in ‘eval-when’:
> >> 
> >>   (eval-when (load expand eval)
> >> (define (sexp->msgid …) …)
> >> (define (deconstruct …) …))
> >> 
> >> But actually it’s not clear to me why these are macros.  I think they
> >> could be regular procedures and it’d work just fine, no?
> >> 
> >
> > I do not understand.  sexp->msgid and deconstruct are procedures, not
> > syntax transformers.  I can add eval-when, but the current code runs
> > as expected for me.
> 
> I tried to explain above but you can check the Guile manual on
> ‘eval-when’ (info "(guile) Eval When").  The example there hopefully
> clarifies what the problem is.
>

I had read that Guile manual section, but it is hard to understand
when eval-when is needed and when it is not needed, because the
manual’s negative example for wrong code runs just as fine for me as
the eval-when version, even when saved to a separate module.

I have not used eval-when for now.

> >> > +(define %plural-numbers
> >> > +  ;; Hard-coded list of input numbers such that for each language’s
> >> > +  ;; plural formula, for each possible output grammatical number,
> >> > +  ;; there is an n among %plural-numbers that yields this output
> >> > +  ;; (cf. section Plural forms in the gettext manual), except 1 is
> >> > +  ;; omitted from this list because it is a special case for
> >> > +  ;; sngettext.  That is, calling ngettext with each number from
> >> > +  ;; %plural-numbers and with 1 in any locale is guaranteed to return
> >> > +  ;; each plural form at least once.  It would be more resilient
> >> > +  ;; towards new languages if instead of hard-coding we computed this
> >> > +  ;; from the Plural-Forms in the MO file header entry, but that is
> >> > +  ;; not worth the incurred code complexity.
> >> > +  '(0 2 3 11 100))
> >> 
> >> I don’t understand this: are these the only plural numbers in all
> >> languages, or…?
> >> 
> >
> > Yes, in all languages for which a plural= formula is documented in the
> > gettext manual.
> >
> > For example, Arabic has
> >
> >   Plural-Forms: nplurals=6; \
> >   plural=n==0 ? 0 : n==1 ? 1 : n==2 ? 2 : n%100>=3 && n%100<=10 
> > ? 3 \
> >   : n%100>=11 ? 4 : 5;
> >
> > with input plural numbers 0, 1, 2, 3, 11, 100 mapping to all outputs
> > 0, 1, 2, 3, 4, 5.
> >
> > Maybe I should add this example to the code comment.
> 
> Oh I see.  Maybe just link to the relevant section of the manual ("info
> (gettext) Plural forms").
>

I made the reference more clear in the %plural-forms comment now.

> […]
> We can then maybe set up a ‘static-web-site’ service on berlin, with
> appropriate nginx rules, to build and publish the manual at a separate
> URL so we can all test it.  See hydra/berlin.scm in maintenance.git.
> 
> Thoughts?
> 

I’ll leave this to you. :)

Regards,
Florian


signature.asc
Description: PGP signature

bug#26302: [website] translations

[Ludovic Courtès]

Hi,

"pelzflorian (Florian Pelz)"  skribis:

>> > +(define (sgettext x)
>> > +  "After choosing an identifier for marking s-expressions for
>> > +translation, make it usable by defining a macro with it calling
>> > +sgettext.  If for example the chosen identifier is G_,
>> > +use (define-syntax G_ sgettext)."
>> > +  (syntax-case x ()
>> > +((id exp)
>> > + (let* ((msgid (sexp->msgid (syntax->datum #'exp)))
>> > +(new-exp (deconstruct (syntax->datum #'exp)
>> > +  (gettext msgid
>> > +   (datum->syntax #'id new-exp)
>> 
>> For this and other similar macros you must use ‘define-syntax’, not
>> ‘define’, so that they are defined at expansion time, not at run time.
>
> As per the above docstring, I already have a definition
>
>   (define-syntax G_ sgettext)
>
> in (apps i18n).  Possibly I should just move it here.

Hmmm right.  It works, but it’s surprising and “borderline”.

If all you want is an alias, I’d recommend writing, say:

  (define-syntax sgettext …)
  (define-syntax G_
(identifier-syntax sgettext))

>> (It doesn’t make any difference when you’re evaluating code since both
>> phases run in the same module, but it does make a difference when these
>> phases happen at different times, in different processes.)
>> 
>> Consequently, you must arrange for ‘sexp->msgid’ and ‘deconstruct’ to be
>> available at expansion time too.  This can be done by wrapping their
>> definition in ‘eval-when’:
>> 
>>   (eval-when (load expand eval)
>> (define (sexp->msgid …) …)
>> (define (deconstruct …) …))
>> 
>> But actually it’s not clear to me why these are macros.  I think they
>> could be regular procedures and it’d work just fine, no?
>> 
>
> I do not understand.  sexp->msgid and deconstruct are procedures, not
> syntax transformers.  I can add eval-when, but the current code runs
> as expected for me.

I tried to explain above but you can check the Guile manual on
‘eval-when’ (info "(guile) Eval When").  The example there hopefully
clarifies what the problem is.

>> > +(define %plural-numbers
>> > +  ;; Hard-coded list of input numbers such that for each language’s
>> > +  ;; plural formula, for each possible output grammatical number,
>> > +  ;; there is an n among %plural-numbers that yields this output
>> > +  ;; (cf. section Plural forms in the gettext manual), except 1 is
>> > +  ;; omitted from this list because it is a special case for
>> > +  ;; sngettext.  That is, calling ngettext with each number from
>> > +  ;; %plural-numbers and with 1 in any locale is guaranteed to return
>> > +  ;; each plural form at least once.  It would be more resilient
>> > +  ;; towards new languages if instead of hard-coding we computed this
>> > +  ;; from the Plural-Forms in the MO file header entry, but that is
>> > +  ;; not worth the incurred code complexity.
>> > +  '(0 2 3 11 100))
>> 
>> I don’t understand this: are these the only plural numbers in all
>> languages, or…?
>> 
>
> Yes, in all languages for which a plural= formula is documented in the
> gettext manual.
>
> For example, Arabic has
>
>   Plural-Forms: nplurals=6; \
>   plural=n==0 ? 0 : n==1 ? 1 : n==2 ? 2 : n%100>=3 && n%100<=10 ? 
> 3 \
>   : n%100>=11 ? 4 : 5;
>
> with input plural numbers 0, 1, 2, 3, 11, 100 mapping to all outputs
> 0, 1, 2, 3, 4, 5.
>
> Maybe I should add this example to the code comment.

Oh I see.  Maybe just link to the relevant section of the manual ("info
(gettext) Plural forms").

I think you can go ahead and push this series to a branch, say
‘wip-i18n’ (the ‘wip-’ prefix meaning that you reserve the right to
rebase the branch as you will.)

We can then maybe set up a ‘static-web-site’ service on berlin, with
appropriate nginx rules, to build and publish the manual at a separate
URL so we can all test it.  See hydra/berlin.scm in maintenance.git.

Thoughts?

Thank you!

Ludo’.

bug#26302: [website] translations

[pelzflorian (Florian Pelz)]

On Wed, Sep 18, 2019 at 03:57:47PM +0200, Ludovic Courtès wrote:
> Hi Florian,
> 
> Could you create an account on Savannah so we can give you commit
> access?
> 

Done.  My username is pelzflorian.


> > +(define (sgettext x)
> > +  "After choosing an identifier for marking s-expressions for
> > +translation, make it usable by defining a macro with it calling
> > +sgettext.  If for example the chosen identifier is G_,
> > +use (define-syntax G_ sgettext)."
> > +  (syntax-case x ()
> > +((id exp)
> > + (let* ((msgid (sexp->msgid (syntax->datum #'exp)))
> > +(new-exp (deconstruct (syntax->datum #'exp)
> > +  (gettext msgid
> > +   (datum->syntax #'id new-exp)
> 
> For this and other similar macros you must use ‘define-syntax’, not
> ‘define’, so that they are defined at expansion time, not at run time.

As per the above docstring, I already have a definition

  (define-syntax G_ sgettext)

in (apps i18n).  Possibly I should just move it here.



> (It doesn’t make any difference when you’re evaluating code since both
> phases run in the same module, but it does make a difference when these
> phases happen at different times, in different processes.)
> 
> Consequently, you must arrange for ‘sexp->msgid’ and ‘deconstruct’ to be
> available at expansion time too.  This can be done by wrapping their
> definition in ‘eval-when’:
> 
>   (eval-when (load expand eval)
> (define (sexp->msgid …) …)
> (define (deconstruct …) …))
> 
> But actually it’s not clear to me why these are macros.  I think they
> could be regular procedures and it’d work just fine, no?
> 

I do not understand.  sexp->msgid and deconstruct are procedures, not
syntax transformers.  I can add eval-when, but the current code runs
as expected for me.




> > +(define %plural-numbers
> > +  ;; Hard-coded list of input numbers such that for each language’s
> > +  ;; plural formula, for each possible output grammatical number,
> > +  ;; there is an n among %plural-numbers that yields this output
> > +  ;; (cf. section Plural forms in the gettext manual), except 1 is
> > +  ;; omitted from this list because it is a special case for
> > +  ;; sngettext.  That is, calling ngettext with each number from
> > +  ;; %plural-numbers and with 1 in any locale is guaranteed to return
> > +  ;; each plural form at least once.  It would be more resilient
> > +  ;; towards new languages if instead of hard-coding we computed this
> > +  ;; from the Plural-Forms in the MO file header entry, but that is
> > +  ;; not worth the incurred code complexity.
> > +  '(0 2 3 11 100))
> 
> I don’t understand this: are these the only plural numbers in all
> languages, or…?
> 

Yes, in all languages for which a plural= formula is documented in the
gettext manual.

For example, Arabic has

  Plural-Forms: nplurals=6; \
  plural=n==0 ? 0 : n==1 ? 1 : n==2 ? 2 : n%100>=3 && n%100<=10 ? 3 
\
  : n%100>=11 ? 4 : 5;

with input plural numbers 0, 1, 2, 3, 11, 100 mapping to all outputs
0, 1, 2, 3, 4, 5.

Maybe I should add this example to the code comment.

Regards,
Florian

signature.asc
Description: PGP signature

bug#26302: [website] translations

[Ludovic Courtès]

Hi Florian,

Could you create an account on Savannah so we can give you commit
access?

That’d allow you for you to push these patches first in a branch so we
can test, and it should make it easier for you.

Once you’ve created an account, please make sure to add the OpenPGP key
you’ll use to sign commits on Savannah and on key servers, and reply to
this message signed with that key.

"pelzflorian (Florian Pelz)"  skribis:

> I am not entirely certain in my use of macros, but believe it is
> right.  See my discussion with Mark H Weaver at
> .

I have a couple of comments on this specific issue below.

> +;; NOTE: The sgettext macros have no hygiene because they use
> +;; datum->syntax and do not preserve the semantics of anything looking
> +;; like an sgettext macro.  This is an exceptional use case; do not
> +;; try this at home.

:-)

> +(define (sgettext x)
> +  "After choosing an identifier for marking s-expressions for
> +translation, make it usable by defining a macro with it calling
> +sgettext.  If for example the chosen identifier is G_,
> +use (define-syntax G_ sgettext)."
> +  (syntax-case x ()
> +((id exp)
> + (let* ((msgid (sexp->msgid (syntax->datum #'exp)))
> +(new-exp (deconstruct (syntax->datum #'exp)
> +  (gettext msgid
> +   (datum->syntax #'id new-exp)

For this and other similar macros you must use ‘define-syntax’, not
‘define’, so that they are defined at expansion time, not at run time.
(It doesn’t make any difference when you’re evaluating code since both
phases run in the same module, but it does make a difference when these
phases happen at different times, in different processes.)

Consequently, you must arrange for ‘sexp->msgid’ and ‘deconstruct’ to be
available at expansion time too.  This can be done by wrapping their
definition in ‘eval-when’:

  (eval-when (load expand eval)
(define (sexp->msgid …) …)
(define (deconstruct …) …))

But actually it’s not clear to me why these are macros.  I think they
could be regular procedures and it’d work just fine, no?

> +(define %plural-numbers
> +  ;; Hard-coded list of input numbers such that for each language’s
> +  ;; plural formula, for each possible output grammatical number,
> +  ;; there is an n among %plural-numbers that yields this output
> +  ;; (cf. section Plural forms in the gettext manual), except 1 is
> +  ;; omitted from this list because it is a special case for
> +  ;; sngettext.  That is, calling ngettext with each number from
> +  ;; %plural-numbers and with 1 in any locale is guaranteed to return
> +  ;; each plural form at least once.  It would be more resilient
> +  ;; towards new languages if instead of hard-coding we computed this
> +  ;; from the Plural-Forms in the MO file header entry, but that is
> +  ;; not worth the incurred code complexity.
> +  '(0 2 3 11 100))

I don’t understand this: are these the only plural numbers in all
languages, or…?

Thanks!

Ludo’.

bug#26302: [website] translations

[sirgazil via Bug reports for GNU Guix]

 On Sun, 08 Sep 2019 12:16:38 -0500 pelzflorian (Florian Pelz) 
 wrote 

 > > Regarding URLs, I would prefer using IRIs, like follows: 
 > > 
 > > /IETF-LANGUAGE-TAG/path/to/resource/ 
 > > 
 > > So: 
 > > 
 > > /es-ES/vídeos/ 
 > > /es-CO/videos/ 
 > > 
 >  
 > As I understand it, es and es-ES and es-Latn-ES would all be language 
 > tags (or just subtags??) for Spanish from Spain.  Do we use the full 
 > tag es-Latn-ES?  Probably es-ES makes more sense than es-Latn-ES for 
 > many languages (but not all).  The Translation Project will generally 
 > only provide one script, it seems.  Maybe often es is enough.  I 
 > suppose we could write an associative list mapping locales for which 
 > translations exist to language tags. 

I'm not suggesting any particular IETF language tags for Spanish variants, 
though. I think one could start supporting only the language tags equivalent to 
the teams defined in the Translation Project (TP). 

In the case of Spanish, many libre projects start focusing only on "es" (which 
is the case for the TP), and that's ok, but it's good to support variants. As 
far as I understand, the TP allows creating teams for language variants (there 
is a pt_BR team). For example, I'd like to have an "es-CO" catalog to override 
some translations of the "es" catalog that are only common in Spain.

bug#26302: [website] translations

[pelzflorian (Florian Pelz)]

On Sun, Sep 08, 2019 at 09:44:44PM +0200, Ludovic Courtès wrote:
> Cool, thanks for opening this issue!
> 

Thank you!  (Well, it was ng0’s old issue and people on the list
started talking about its topic again.)


> > One of the attached patches adds a PO file with a German translation
> > that was needed for testing purposes; of course translations should
> > normally be submitted via the Translation Project.  The patch need not
> > be applied; do as you see fit.
> 
> I wonder if we should use the TP for this.  Thoughts?
> 

We can, because it’s an ordinary POT file like guix-manual (but easier
because no Texinfo knowledge is required).  With the TP, there would
be many more translations, although often incomplete and in a few
cases wrong, but the readers will notice.  All the translators can do
is reorder existing SHTML, at worst misrepresenting GNU, redirecting
translatable links wrongly or preventing the website from building.

Regards,
Florian

bug#26302: [website] translations

[Ludovic Courtès]

Hi Florian,

"pelzflorian (Florian Pelz)"  skribis:

> Find attached preliminary patches that add a working website
> translation system to guix-artwork.  Of course, the patches should
> *not* be pushed before there is a working nginx configuration with
> appropriate redirects.  (Except the first three patches; I do not
> understand how you could even build the website without my first
> patch?)

Cool, thanks for opening this issue!

> In my patches, I have used spaces for indentation.  Most previous
> website code used a mix of tabs and spaces, like in emacs’ strange
> default setting.  If you want, I can tabify my patches.  I cannot see
> any reason for using mixed tabs+spaces with emacs-style Lisp
> indentation though.

Spaces are good (easily pastable in the REPL), the whole Guix code base
is meant to use spaces only.

> For redirecting previous URLs based on the HTTP Accept-Language
> header, there is
> .
> It could be added to nginx.

Good.

> I do not know what the new URLs should be.  After reading
> 
> I now understand that there indeed should be separate URLs for each
> language and Accept-Language headers are not sufficient.  However,
> Ludo’s idea of translating URLs including the basename
> ,
> i.e. /help.html as /es/ayuda.html, leads to questions about the
> implementation such as what Jelle Licht mentioned
> .
> We can do whatever we want, so let’s do what is best.  What do you
> think, /es/ayuda/ or /es/help/ or something else?
>
> For ayuda, we would then need to make `guix build -f .guix.scm` build
> with the static website also some kind of association list for
> redirects that is readable by nginx lua code or whatever (could there
> be guile plugins for nginx??).
>
> We can do /es/help/ now and make /es/ayuda/ later.

Yeah, let’s keep that for later.

> One of the attached patches adds a PO file with a German translation
> that was needed for testing purposes; of course translations should
> normally be submitted via the Translation Project.  The patch need not
> be applied; do as you see fit.

I wonder if we should use the TP for this.  Thoughts?

> With respect to the help mailing list blurbs on the website, my code
> gives priority to the PO file translation of the blurb and uses the
> previous hard-coded translations as a fall-back.  I would keep the
> blurbs this way until all are part of a PO file at the Translation
> Project.

Sounds good.

> The Chinese language blurb is written in traditional Chinese
> characters.  I believe there never was a decision on
> ,
> so I leave the language code as “zh” for now, even though someone may
> add a “zh-cn” too.

Yeah, we can always adjust later.

Thanks!

Ludo’.

bug#26302: [website] translations

[pelzflorian (Florian Pelz)]

On Fri, Sep 06, 2019 at 01:17:10PM -0500, sirgazil via Bug reports for GNU Guix 
wrote:
> Hi, Florian :)
> 
> I haven't had the time to work on the website again, so I haven't
> tried your code yet. But I'm glad you're working on this.
> 

:)


> Regarding URLs, I would prefer using IRIs, like follows:
> 
> /IETF-LANGUAGE-TAG/path/to/resource/
> 
> So:
> 
> /es-ES/vídeos/
> /es-CO/videos/
> 

As I understand it, es and es-ES and es-Latn-ES would all be language
tags (or just subtags??) for Spanish from Spain.  Do we use the full
tag es-Latn-ES?  Probably es-ES makes more sense than es-Latn-ES for
many languages (but not all).  The Translation Project will generally
only provide one script, it seems.  Maybe often es is enough.  I
suppose we could write an associative list mapping locales for which
translations exist to language tags.



> Currently, I do this for document-like resources, but I haven't
> thought if the same should be done for other resources like images,
> videos, etc., that may need localization as well.
>

I would prefer if nginx responded with /es/help/index.html only if
/help/index.html does not exist, the same for other file extensions.



> I have to say that I'm always afraid that something will break if
> you don't feed English to current systems, though. See for example
> the URLs that result when you export texinfo documentation written
> in other languages to HTML:
>
>   
> https://guix.gnu.org/manual/es/html_node/Instalacion-del-sistema.html#Instalaci_00f3n-del-sistema
> 
> In this example, the accented "ó" of "Instalación" is changed in two
> different ways that make the URL less readable for a Spanish
> speaker.
> 
> Still, I think it's good to internationalize whatever is supposed to
> be "localizable" (in theory) to push systems to handle other
> languages better.
>

I believe Texinfo performs this rather complex mapping (especially for
Chinese manuals!) because domain registrars forbid Unicode characters
that do not match the Top Level Domain for security reasons.  I am
unsure if we can translate anything to non-Latin filenames.



> Speaking of the manual, I would also think about changing its URL
> path to the /IETF-LANGUAGE-TAG/manual/ form to make everything
> uniform if possible.
>

I agree.



> As for the website dropdowns, that could be reported as a separate
> issue (yes, they are not really accessible at the moment). I didn't
> know how to implement the tab navigation for them at that time, but
> I think it is possible using only CSS.
> 
> 

I think a language selection dropdown is required for a multilingual
website.

I realize my code in patch 4 is insufficient when not run manually
because the Guix’ maintenance repository’s hydra/berlin.scm does not
run .guix.scm from the website directory.  I will resend patch 4 when
I have a working dropdown and berlin virtual machine.

Regards,
Florian

bug#26302: [website] translations

[sirgazil via Bug reports for GNU Guix]

Hi, Florian :)

I haven't had the time to work on the website again, so I haven't tried your 
code yet. But I'm glad you're working on this.

Regarding URLs, I would prefer using IRIs, like follows:

/IETF-LANGUAGE-TAG/path/to/resource/

So:

/es-ES/vídeos/
/es-CO/videos/

Currently, I do this for document-like resources, but I haven't thought if the 
same should be done for other resources like images, videos, etc., that may 
need localization as well.

I have to say that I'm always afraid that something will break if you don't 
feed English to current systems, though. See for example the URLs that result 
when you export texinfo documentation written in other languages to HTML:

  
https://guix.gnu.org/manual/es/html_node/Instalacion-del-sistema.html#Instalaci_00f3n-del-sistema

In this example, the accented "ó" of "Instalación" is changed in two different 
ways that make the URL less readable for a Spanish speaker.

Still, I think it's good to internationalize whatever is supposed to be 
"localizable" (in theory) to push systems to handle other languages better.

Speaking of the manual, I would also think about changing its URL path to the 
/IETF-LANGUAGE-TAG/manual/ form to make everything uniform if possible.

As for the website dropdowns, that could be reported as a separate issue (yes, 
they are not really accessible at the moment). I didn't know how to implement 
the tab navigation for them at that time, but I think it is possible using only 
CSS.



---
https://sirgazil.bitbucket.io/

bug#26302: [website] translations

[ng0]

Ludovic Courtès transcribed 1.1K bytes:
> Hi,
> 
> ng0  skribis:
> 
> > One thing I like about the template of https://taler.net is the usage of
> > javascript free translations of text (jinja2 is used), easy to select
> > and write.
> > I think translations of web sites are useful, necessary and important.  
> > 
> >
> > We must provide this in the long run on the Guix web site aswell.
> 
> FWIW I agree.
> 
> I wouldn’t want to use JS for that, though.
> 
> It may be that the simplest solution would be to use Gettext since,
> after all, the web site is a regular Scheme program.
> 
> I would welcome work in this direction!
> 
> Ludo’.

I made some progress here, but only in theory and discussion.
It might take some time until I can write it down, and my approach
to websites and their translations might not be what we as Guix would want.

I'll update this with more info, I'll basically intend to use my own
project website as a testing ground for this with the version after
the current work in progress version.
-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://n0is.noblogs.org/my-keys
https://www.infotropique.org https://krosos.org


signature.asc
Description: PGP signature

bug#26302: [website] translations

[Ludovic Courtès]

Hi,

ng0  skribis:

> One thing I like about the template of https://taler.net is the usage of
> javascript free translations of text (jinja2 is used), easy to select
> and write.
> I think translations of web sites are useful, necessary and important.
>   
>
> We must provide this in the long run on the Guix web site aswell.

FWIW I agree.

I wouldn’t want to use JS for that, though.

It may be that the simplest solution would be to use Gettext since,
after all, the web site is a regular Scheme program.

I would welcome work in this direction!

Ludo’.

bug#26302: [website] translations

[ng0]

ng0 transcribed 1.4K bytes:
> ng0 transcribed 0.7K bytes:
> > ng0 transcribed 0.4K bytes:
> > > One thing I like about the template of https://taler.net is the usage of
> > > javascript free translations of text (jinja2 is used), easy to select
> > > and write.
> > > I think translations of web sites are useful, necessary and important.
> > >   
> > >   
> > >  
> > > We must provide this in the long run on the Guix web site aswell.
> > > 
> > 
> > "Must" sounds very strong, but I think we should do this for the all
> > parts possible of the website, starting with the basic website.
> > 
> > Whoever has an idea how to approach this using Guile should pick this
> > task up.
> > 
> 
> Update on this bug, as I just had some insights in an OStatus Federation
> thread with Rafał Piątkowski.
> 
> We make use of SXML.
> XML has native support for translations, but it's not "user friendly".
> The goal here would be to simply the way translations are done.
> Here is one way how you can achieve native xml translations:
> https://www.xml.com/pub/a/2004/01/07/xmltm.html
> 
> Our newsposts are in Markdown.
> Does Commonmark (what we use as far as I understand Haunt) support
> extensions?
> Otherwise we can write one new "post" per translation and have a
> dialogue / menu to switch the language.
> 
> 
> -- 
> PGP and more: https://people.pragmatique.xyz/ng0/
> 
> 
> 

This
https://stackoverflow.com/questions/22824132/multiple-translations-in-a-single-restructuredtext-file
suggstest that at least with ReStructuredText (and Sphinx) we could
achieve something, so in case Commonmark doesn't work out,
ReStructuredText is an option.

-- 
PGP and more: https://people.pragmatique.xyz/ng0/

bug#26302: [website] translations

[ng0]

ng0 transcribed 0.7K bytes:
> ng0 transcribed 0.4K bytes:
> > One thing I like about the template of https://taler.net is the usage of
> > javascript free translations of text (jinja2 is used), easy to select
> > and write.
> > I think translations of web sites are useful, necessary and important.  
> > 
> >
> > We must provide this in the long run on the Guix web site aswell.
> > 
> 
> "Must" sounds very strong, but I think we should do this for the all
> parts possible of the website, starting with the basic website.
> 
> Whoever has an idea how to approach this using Guile should pick this
> task up.
> 

Update on this bug, as I just had some insights in an OStatus Federation
thread with Rafał Piątkowski.

We make use of SXML.
XML has native support for translations, but it's not "user friendly".
The goal here would be to simply the way translations are done.
Here is one way how you can achieve native xml translations:
https://www.xml.com/pub/a/2004/01/07/xmltm.html

Our newsposts are in Markdown.
Does Commonmark (what we use as far as I understand Haunt) support
extensions?
Otherwise we can write one new "post" per translation and have a
dialogue / menu to switch the language.


-- 
PGP and more: https://people.pragmatique.xyz/ng0/

bug#26302: [website] translations

[ng0]

ng0 transcribed 0.4K bytes:
> One thing I like about the template of https://taler.net is the usage of
> javascript free translations of text (jinja2 is used), easy to select
> and write.
> I think translations of web sites are useful, necessary and important.
>   
>
> We must provide this in the long run on the Guix web site aswell.
> 

"Must" sounds very strong, but I think we should do this for the all
parts possible of the website, starting with the basic website.

Whoever has an idea how to approach this using Guile should pick this
task up.

bug#26302: [website] translations

[ng0]

One thing I like about the template of https://taler.net is the usage of
javascript free translations of text (jinja2 is used), easy to select
and write.
I think translations of web sites are useful, necessary and important.  

   
We must provide this in the long run on the Guix web site aswell.