GNU bug report logs -
#26302
[website] translations
Previous Next
Reported by: ng0 <contact.ng0 <at> cryptolab.net>
Date: Wed, 29 Mar 2017 15:41:01 UTC
Severity: normal
Done: Tobias Geerinckx-Rice <me <at> tobias.gr>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 26302 in the body.
You can then email your comments to 26302 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Wed, 29 Mar 2017 15:41:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
ng0 <contact.ng0 <at> cryptolab.net>:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org.
(Wed, 29 Mar 2017 15:41:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Wed, 29 Mar 2017 16:14:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 26302 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Sat, 15 Apr 2017 12:01:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 26302 <at> debbugs.gnu.org (full text, mbox):
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/
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Sat, 15 Apr 2017 12:27:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 26302 <at> debbugs.gnu.org (full text, mbox):
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/
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Mon, 31 Jul 2017 21:12:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 26302 <at> debbugs.gnu.org (full text, mbox):
Hi,
ng0 <contact.ng0 <at> cryptolab.net> 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’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Mon, 31 Jul 2017 21:56:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 26302 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Ludovic Courtès transcribed 1.1K bytes:
> Hi,
>
> ng0 <contact.ng0 <at> cryptolab.net> 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 (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Fri, 06 Sep 2019 14:26:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 26302 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello!
I think it is better to continue here with the discussion from
<https://lists.gnu.org/archive/html/guix-devel/2019-08/msg00178.html>.
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?)
I am not entirely certain in my use of macros, but believe it is
right. See my discussion with Mark H Weaver at
<https://lists.gnu.org/archive/html/guile-user/2019-09/msg00008.html>.
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.
For redirecting previous URLs based on the HTTP Accept-Language
header, there is
<https://www.nginx.com/resources/wiki/modules/accept_language/#accept-language-installation>.
It could be added to nginx.
I do not know what the new URLs should be. After reading
<https://webmasters.stackexchange.com/questions/403/how-should-i-structure-my-urls-for-both-seo-and-localization>
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
<https://lists.gnu.org/archive/html/guix-devel/2019-08/msg00164.html>,
i.e. /help.html as /es/ayuda.html, leads to questions about the
implementation such as what Jelle Licht mentioned
<https://lists.gnu.org/archive/html/guix-devel/2019-08/msg00169.html>.
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.
Also, using the language code alone will no longer suffice once we
have two /zh/help/ for mainland and traditional-character Chinese.
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.
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.
The Chinese language blurb is written in traditional Chinese
characters. I believe there never was a decision on
<https://lists.gnu.org/archive/html/guix-devel/2018-03/msg00131.html>,
so I leave the language code as “zh” for now, even though someone may
add a “zh-cn” too.
I transferred the German blurb by Andreas Enge in
<https://lists.gnu.org/archive/html/guix-devel/2018-03/msg00026.html>
to the new German PO file, but changed the spelling “auf deutsch” to
the official orthography as per the official word list 2017 because
the German Translation Project team has decided on following official
orthography instead of allowing for personal style (but thank you to
Andreas Enge for showing me belleslettres who may well be right).
Next, I will look at adding a locale selection dropdown similar to the
About dropdown that is on the website now. I would like to make both
About and locale selection be of visible size dependent on whether a
hidden <input type=radio> or an <input type=checkbox> is checked (the
latter would allow multiple dropdowns to be shown simultaneously). A
probably insufficient, too new alternative is <details> (?). I would
like to make the dropdowns keyboard-navigable (reachable using only
the tab key and no mouse/pointing device) in a way similar to what
happens when pressing tab on <https://en.wiktionary.org/wiki/geeks>.
This would be incompatible with <details>, I believe.
Regards,
Florian
[0001-website-Use-needed-modules-in-posts.patch (text/plain, attachment)]
[0002-website-Fix-typing-mistake.patch (text/plain, attachment)]
[0003-website-Fix-typo.patch (text/plain, attachment)]
[0004-website-Add-custom-xgettext-to-extract-from-nested-s.patch (text/plain, attachment)]
[0005-website-Mark-all-files-in-apps-for-translation.patch (text/plain, attachment)]
[0006-website-Add-German-translation.patch (text/plain, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Fri, 06 Sep 2019 14:43:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 26302 <at> debbugs.gnu.org (full text, mbox):
The 6th patch wrongly updated guix-website.pot. I will not resend.
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Fri, 06 Sep 2019 18:18:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 26302 <at> debbugs.gnu.org (full text, mbox):
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/
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Sun, 08 Sep 2019 17:17:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 26302 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Sun, 08 Sep 2019 19:45:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 26302 <at> debbugs.gnu.org (full text, mbox):
Hi Florian,
"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> 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
> <https://www.nginx.com/resources/wiki/modules/accept_language/#accept-language-installation>.
> It could be added to nginx.
Good.
> I do not know what the new URLs should be. After reading
> <https://webmasters.stackexchange.com/questions/403/how-should-i-structure-my-urls-for-both-seo-and-localization>
> 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
> <https://lists.gnu.org/archive/html/guix-devel/2019-08/msg00164.html>,
> i.e. /help.html as /es/ayuda.html, leads to questions about the
> implementation such as what Jelle Licht mentioned
> <https://lists.gnu.org/archive/html/guix-devel/2019-08/msg00169.html>.
> 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
> <https://lists.gnu.org/archive/html/guix-devel/2018-03/msg00131.html>,
> 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’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Sun, 08 Sep 2019 20:47:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 26302 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Tue, 10 Sep 2019 01:05:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 26302 <at> debbugs.gnu.org (full text, mbox):
---- On Sun, 08 Sep 2019 12:16:38 -0500 pelzflorian (Florian Pelz) <pelzflorian <at> pelzflorian.de> 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.
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Sun, 15 Sep 2019 20:19:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 26302 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Sep 09, 2019 at 07:49:33PM -0500, sirgazil wrote:
> I think one could start supporting only the
> language tags equivalent to the teams defined in the Translation
> Project (TP).
>
This is a good suggestion, I think. Find attached new versions of all
patches that work on a berlin.scm virtual machine (slightly modified
to use substitutes and not run some services). These include patches
for dropdown accessibility and an ugly language dropdown.
The language dropdown redirects to the homepage, because Haunt offers
no nice way to get the name of the same page.
I have used the code “en” for U.S. English because the TP team for
British English is already called en_GB, so its code would be en-GB.
What’s missing is code for adding the nginx plugin
https://www.nginx.com/resources/wiki/modules/accept_language/
to Guix so it can be used on berlin.scm. It seems to offer all that
is required for redirecting existing URLs.
Regards,
Florian
[0001-website-Use-needed-modules-in-posts.patch (text/plain, attachment)]
[0002-website-Fix-typing-mistake.patch (text/plain, attachment)]
[0003-website-Fix-typo.patch (text/plain, attachment)]
[0004-website-Add-custom-xgettext-to-extract-from-nested-s.patch (text/plain, attachment)]
[0005-website-Mark-all-files-in-apps-for-translation.patch (text/plain, attachment)]
[0006-website-Add-German-translation.patch (text/plain, attachment)]
[0007-website-Make-dropdowns-accessible-to-keyboard-and-to.patch (text/plain, attachment)]
[0008-website-Add-language-selection-dropdown-to-navbar.patch (text/plain, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Wed, 18 Sep 2019 13:01:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 26302 <at> debbugs.gnu.org (full text, mbox):
On Sun, Sep 15, 2019 at 10:18:20PM +0200, pelzflorian (Florian Pelz) wrote:
> What’s missing is code for adding the nginx plugin
>
> https://www.nginx.com/resources/wiki/modules/accept_language/
>
> to Guix so it can be used on berlin.scm. It seems to offer all that
> is required for redirecting existing URLs.
>
> Regards,
> Florian
Help is welcome. If berlin.scm uses the above module, a package like
<https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=nginx-mod-dav-ext>
but for the accept_language module and for Guix would be needed.
I would prefer someone more into nginx and its Guix service to do this
or suggest an alternative. If not, I will try making a package in a few days.
Regards,
Florian
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Wed, 18 Sep 2019 13:58:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 26302 <at> debbugs.gnu.org (full text, mbox):
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)" <pelzflorian <at> pelzflorian.de> skribis:
> I am not entirely certain in my use of macros, but believe it is
> right. See my discussion with Mark H Weaver at
> <https://lists.gnu.org/archive/html/guile-user/2019-09/msg00008.html>.
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’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Thu, 19 Sep 2019 07:49:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 26302 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Thu, 19 Sep 2019 11:43:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 26302 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Florian,
"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
> 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.
I’ve added you now. I assume you’ll be signing commits with key
CEF4CB914856BA380A20A7E2300888CB39C63817. (You may want to set an
expiration date on the key, and to periodically update the expiration
date and re-upload the key.)
Please make sure to read ‘HACKING’ regarding the conventions and rules
that apply.
Thank you for your work, and welcome aboard! :-)
Ludo’.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Thu, 19 Sep 2019 11:51:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 26302 <at> debbugs.gnu.org (full text, mbox):
Hi,
"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> 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’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Thu, 19 Sep 2019 22:09:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 26302 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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)" <pelzflorian <at> pelzflorian.de> 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 (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Mon, 07 Oct 2019 08:16:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 26302 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Sep 15, 2019 at 10:18:20PM +0200, pelzflorian (Florian Pelz) wrote:
> What’s missing is code for adding the nginx plugin
>
> https://www.nginx.com/resources/wiki/modules/accept_language/
>
> to Guix so it can be used on berlin.scm. It seems to offer all that
> is required for redirecting existing URLs.
>
Please review the attached patch to Guix that adds
nginx-mod-accept-language. (This is not the upstream name; various
nginx modules use no consistent naming scheme for nginx modules.) I
have put it in a separate module from (gnu packages web) due to an
import cycle with tar/(gnu packages base). The second patch allows
using dynamic modules with the nginx service.
Using these patches, the attached slightly wrong patch to
guix/maintenance.git is meant to make the web server default to
serving the language configured in the browser when no language code
is specified in the URL, so old URLs remain functional. (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.)
Nonetheless, href links on the website point to the localized pages on
purpose so if someone changes the language the change remains in
effect when following a link.
Some people on the internet (I forgot who) preferred having a cookie
store the preferred language. That would make it possible to continue
using the old URLs in href links on the website. However, I am not
sure how it would affect SEO.
On Thu, Sep 19, 2019 at 01:50:10PM +0200, Ludovic Courtès wrote:
> 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.
>
I see you @Ludo added such a service, but I cannot reach it. Perhaps
I am using the wrong URL.
Regards,
Florian
[0001-wip-gnu-Add-ngx_http_accept_language_module.patch (text/plain, attachment)]
[0002-services-Make-it-possible-to-include-dynamic-modules.patch (text/plain, attachment)]
[0001-berlin-Redirect-to-localized-website-depending-on-Ac.patch (text/plain, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Tue, 08 Oct 2019 09:38:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 26302 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
[0001-berlin-Redirect-to-localized-website-depending-on-Ac.patch (text/plain, attachment)]
[test-berlin-vm.patch (text/plain, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Tue, 22 Oct 2019 12:12:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 26302 <at> debbugs.gnu.org (full text, mbox):
Hello Florian and all!
(Cc: sirgazil + Julien.)
Ludovic Courtès <ludo <at> gnu.org> 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’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Tue, 22 Oct 2019 12:29:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 26302 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Tue, 22 Oct 2019 12:42:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 26302 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Tue, 22 Oct 2019 13:02:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 26302 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Wed, 23 Oct 2019 14:17:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 26302 <at> debbugs.gnu.org (full text, mbox):
Hi,
"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> 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’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Wed, 23 Oct 2019 14:42:03 GMT)
Full text and
rfc822 format available.
Message #86 received at 26302 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Thu, 31 Oct 2019 20:20:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 26302 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Fri, 01 Nov 2019 14:55:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 26302 <at> debbugs.gnu.org (full text, mbox):
Hi Florian
"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
>>From 9ec69c888b978cb870a5873af8e327541fe4ef7a Mon Sep 17 00:00:00 2001
> From: Florian Pelz <pelzflorian <at> pelzflorian.de>
> 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 <mhw <at> netris.org>
> +;;; Copyright © 2016 Tobias Geerinckx-Rice <me <at> tobias.gr>
> +;;; Copyright © 2017, 2018 Marius Bakke <mbakke <at> fastmail.com>
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 <pelzflorian <at> pelzflorian.de>
> 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’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Fri, 01 Nov 2019 14:59:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 26302 <at> debbugs.gnu.org (full text, mbox):
Hi,
"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
> 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.
Neat!
> 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.
Reviewed! Regarding the build system of nginx modules, we’ll see when
we have more than one module packaged. :-)
Thanks,
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Sat, 02 Nov 2019 13:16:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 26302 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <mhw <at> netris.org>
> > +;;; Copyright © 2016 Tobias Geerinckx-Rice <me <at> tobias.gr>
> > +;;; Copyright © 2017, 2018 Marius Bakke <mbakke <at> fastmail.com>
>
> 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
[0001-doc-Add-warning-on-the-source-build-option-when-link.patch (text/plain, attachment)]
[0002-gnu-Add-Nginx-Accept-Language-module.patch (text/plain, attachment)]
[0003-services-Make-it-possible-to-include-dynamic-modules.patch (text/plain, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Mon, 04 Nov 2019 17:20:03 GMT)
Full text and
rfc822 format available.
Message #101 received at 26302 <at> debbugs.gnu.org (full text, mbox):
Hi,
"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> 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 <mhw <at> netris.org>
>> > +;;; Copyright © 2016 Tobias Geerinckx-Rice <me <at> tobias.gr>
>> > +;;; Copyright © 2017, 2018 Marius Bakke <mbakke <at> fastmail.com>
>>
>> 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 <pelzflorian <at> pelzflorian.de>
> 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 <pelzflorian <at> pelzflorian.de>
> 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 public variable.
LGTM!
Thanks for taking the time to rewrite the snippet as a build phase.
> From 250ae2011ac1c976508136e9f50cb04e6ab5f23c Mon Sep 17 00:00:00 2001
> From: Florian Pelz <pelzflorian <at> pelzflorian.de>
> Date: Sat, 2 Nov 2019 14:05:30 +0100
> Subject: [PATCH 3/3] services: Make it possible to include dynamic modules in
> nginx.
>
> * gnu/services/web.scm (<nginx-configuration>): 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.
> ---
> doc/guix.texi | 4 ++++
> gnu/services/web.scm | 8 ++++++++
> 2 files changed, 12 insertions(+)
>
> diff --git a/doc/guix.texi b/doc/guix.texi
> index 30b69d8869..898123da2b 100644
> --- a/doc/guix.texi
> +++ b/doc/guix.texi
> @@ -19770,6 +19770,10 @@ use the size of the processors cache line.
> @item @code{server-names-hash-bucket-max-size} (default: @code{#f})
> Maximum bucket size for the server names hash tables.
>
> +@item @code{modules} (default: @code{'()})
> +List of nginx dynamic modules to load. Should be a list of strings or
> +string valued G-expressions.
Then… how does nginx find the module in question, specifically the
‘nginx-accept-language-module’ package? One has to specify
‘nginx-accept-language-module’ as the nginx package to use, is that
right? (I had overlooked that before.)
What about adding an example with the ‘accept-language’ module?
Thank you!
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Tue, 05 Nov 2019 07:32:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 26302 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Nov 04, 2019 at 06:19:32PM +0100, Ludovic Courtès wrote:
> "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
> > On Fri, Nov 01, 2019 at 03:54:42PM +0100, Ludovic Courtès wrote:
> >> […]
> >> 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").
>
Makes sense. I agree the general rule is appropriate here.
> > From: Florian Pelz <pelzflorian <at> pelzflorian.de>
> > 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.
> > […]
> > +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?
>
I guess the meaning of `guix build -S` is not clear enough. Let me
make an alternative proposal (attached).
> > From: Florian Pelz <pelzflorian <at> pelzflorian.de>
> > Date: Sat, 2 Nov 2019 14:05:30 +0100
> > Subject: [PATCH 3/3] services: Make it possible to include dynamic modules in
> > nginx.
> >
> > * gnu/services/web.scm (<nginx-configuration>): 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.
>
> Then… how does nginx find the module in question, specifically the
> ‘nginx-accept-language-module’ package? One has to specify
> ‘nginx-accept-language-module’ as the nginx package to use, is that
> right? (I had overlooked that before.)
>
> What about adding an example with the ‘accept-language’ module?
>
Of course you are right. I attach a patch with only a changed
doc/guix.texi. I do not attach again the
nginx-accept-language-module.
Are these proposals OK? Shall I push the three patches?
Regards,
Florian
[0001-doc-Explain-more-licensing-aspects-of-the-source-bui.patch (text/plain, attachment)]
[0003-services-Make-it-possible-to-include-dynamic-modules.patch (text/plain, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Tue, 05 Nov 2019 11:12:01 GMT)
Full text and
rfc822 format available.
Message #107 received at 26302 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
[0001-doc-Explain-more-licensing-aspects-of-the-source-bui.patch (text/plain, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Wed, 06 Nov 2019 14:50:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 26302 <at> debbugs.gnu.org (full text, mbox):
Hi!
"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
> From 04df1e5ee3fd542776b13eb3a59872e1647eb5f8 Mon Sep 17 00:00:00 2001
> From: Florian Pelz <pelzflorian <at> pelzflorian.de>
> 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 (<nginx-configuration>): 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’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Wed, 06 Nov 2019 14:58:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 26302 <at> debbugs.gnu.org (full text, mbox):
Hi,
"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
> From a5d9180d960d244053bea0d59d6092060fe4c6dd Mon Sep 17 00:00:00 2001
> From: Florian Pelz <pelzflorian <at> pelzflorian.de>
> 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.
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’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Wed, 06 Nov 2019 18:22:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 26302 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Wed, 06 Nov 2019 18:31:01 GMT)
Full text and
rfc822 format available.
Message #119 received at 26302 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
[0001-doc-Add-clarification-on-the-source-build-option.patch (text/plain, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Thu, 07 Nov 2019 20:25:01 GMT)
Full text and
rfc822 format available.
Message #122 received at 26302 <at> debbugs.gnu.org (full text, mbox):
Hello Florian,
"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
> From c9f7b2739392e0d8cf2afa6b2179b2e138c49bc7 Mon Sep 17 00:00:00 2001
> From: Florian Pelz <pelzflorian <at> pelzflorian.de>
> 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’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Fri, 08 Nov 2019 09:03:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 26302 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Fri, 08 Nov 2019 14:02:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 26302 <at> debbugs.gnu.org (full text, mbox):
Hi, Florian :)
---- On Fri, 08 Nov 2019 04:02:16 -0500 pelzflorian (Florian Pelz) <pelzflorian <at> pelzflorian.de> 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.
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Fri, 08 Nov 2019 16:19:02 GMT)
Full text and
rfc822 format available.
Message #131 received at 26302 <at> debbugs.gnu.org (full text, mbox):
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) <pelzflorian <at> pelzflorian.de> 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
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Fri, 08 Nov 2019 16:21:02 GMT)
Full text and
rfc822 format available.
Message #134 received at 26302 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Fri, 08 Nov 2019 17:14:01 GMT)
Full text and
rfc822 format available.
Message #137 received at 26302 <at> debbugs.gnu.org (full text, mbox):
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
<nav class="menu" style="width: 100%;">
and the ul inside could be given display:flex and justify-content
<ul style="display: flex;justify-content: space-between;">
Or not. Maybe it is good as it is.
Regards,
Florian
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Fri, 08 Nov 2019 18:41:01 GMT)
Full text and
rfc822 format available.
Message #140 received at 26302 <at> debbugs.gnu.org (full text, mbox):
---- On Fri, 08 Nov 2019 12:13:56 -0500 pelzflorian (Florian Pelz) <pelzflorian <at> pelzflorian.de> 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
>
> <nav class="menu" style="width: 100%;">
>
> and the ul inside could be given display:flex and justify-content
>
> <ul style="display: flex;justify-content: space-between;">
>
> 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 :)
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Sun, 17 Nov 2019 16:18:01 GMT)
Full text and
rfc822 format available.
Message #143 received at 26302 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
[0001-various-changes-for-local-testing.patch (text/plain, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Mon, 02 Dec 2019 08:58:02 GMT)
Full text and
rfc822 format available.
Message #146 received at 26302 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Wed, 25 Mar 2020 17:34:01 GMT)
Full text and
rfc822 format available.
Message #149 received at 26302 <at> debbugs.gnu.org (full text, mbox):
Hi Florian,
We dropped the ball on this, but it looks like we were close to the
finish line.
What would it take to complete the i18n’d web site deployment? It would
be great to get that done by the time of the next release.
Thanks!
Ludo’.
"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
> 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
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Wed, 25 Mar 2020 23:22:01 GMT)
Full text and
rfc822 format available.
Message #152 received at 26302 <at> debbugs.gnu.org (full text, mbox):
On Wed, Mar 25, 2020 at 06:33:46PM +0100, Ludovic Courtès wrote:
> Hi Florian,
>
> We dropped the ball on this, but it looks like we were close to the
> finish line.
>
> What would it take to complete the i18n’d web site deployment? It would
> be great to get that done by the time of the next release.
>
set_from_accept_language $lang en de;
would better be a global directive. en comes first so it is the
default.
Otherwise it’s the changes you quoted. Testing is difficult though.
I tested without https and with some modifications to make berlin.scm
work in a virtual machine.
I will try rebasing wip-i18n to current master now.
Regards,
Florian
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Thu, 26 Mar 2020 01:26:01 GMT)
Full text and
rfc822 format available.
Message #155 received at 26302 <at> debbugs.gnu.org (full text, mbox):
On Thu, Mar 26, 2020 at 12:21:00AM +0100, pelzflorian (Florian Pelz) wrote:
> I will try rebasing wip-i18n to current master now.
Done.
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Tue, 07 Apr 2020 21:20:01 GMT)
Full text and
rfc822 format available.
Message #158 received at 26302 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Florian,
"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
>> What would it take to complete the i18n’d web site deployment? It would
>> be great to get that done by the time of the next release.
>>
>
> set_from_accept_language $lang en de;
>
> would better be a global directive. en comes first so it is the
> default.
>
> Otherwise it’s the changes you quoted. Testing is difficult though.
> I tested without https and with some modifications to make berlin.scm
> work in a virtual machine.
I had to slightly adjust your changes, leading to the patch below.
I haven’t tested it though. I’m a bit concerned about the rewrite rule,
because there are bits that should not be rewritten, like:
/manual (must not be: /LANG/manual, at least for now)
/guix-refcard.pdf
…
Will there be rewritten with the config below?
I know you’re already busy with the installer, Florian, so maybe we can
postpone that after the release, unless someone else champions to test it!
Thanks,
Ludo’.
[Message part 2 (text/x-patch, inline)]
diff --git a/hydra/nginx/berlin.scm b/hydra/nginx/berlin.scm
index 303fd35..7e329fc 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;")))))
@@ -514,6 +518,8 @@ PUBLISH-URL."
(locations guix.gnu.org-locations)
(raw-content
(list
+ "rewrite (.*)/$ $1/index.html;"
+ "set_from_accept_language $lang en de;"
"access_log /var/log/nginx/guix-info.access.log;")))
(nginx-server-configuration
@@ -525,6 +531,8 @@ PUBLISH-URL."
(append
%tls-settings
(list
+ "rewrite (.*)/$ $1/index.html;"
+ "set_from_accept_language $lang en de;"
"access_log /var/log/nginx/guix-info.https.access.log;"))))
(nginx-server-configuration
@@ -621,6 +629,8 @@ PUBLISH-URL."
(append
%tls-settings
(list
+ "rewrite (.*)/$ $1/index.html;"
+ "set_from_accept_language $lang en de;"
"access_log /var/log/nginx/guix-info.https.access.log;"))))
(nginx-server-configuration
@@ -634,6 +644,8 @@ PUBLISH-URL."
(append
%tls-settings
(list
+ "rewrite (.*)/$ $1/index.html;"
+ "set_from_accept_language $lang en de;"
"access_log /var/log/nginx/guix-gnu-org.https.access.log;"))))
(nginx-server-configuration
@@ -775,6 +787,11 @@ PUBLISH-URL."
(define %nginx-configuration
(nginx-configuration
(server-blocks %berlin-servers)
+ (modules
+ (list
+ ;; Module to redirect users to the localized pages of their choice.
+ (file-append nginx-accept-language-module
+ "/etc/nginx/modules/ngx_http_accept_language_module.so")))
(global-directives
;; This is a 72-core machine, but let's not use all of them for nginx.
'((worker_processes . 16)
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Tue, 07 Apr 2020 22:03:01 GMT)
Full text and
rfc822 format available.
Message #161 received at 26302 <at> debbugs.gnu.org (full text, mbox):
On Tue, Apr 07, 2020 at 11:18:56PM +0200, Ludovic Courtès wrote:
> I haven’t tested it though. I’m a bit concerned about the rewrite rule,
> because there are bits that should not be rewritten, like:
>
> /manual (must not be: /LANG/manual, at least for now)
> /guix-refcard.pdf
> …
>
> Will there be rewritten with the config below?
These should be OK. Because it uses try_files, both /en/manual and
/manual should be checked. guix-refcard.pdf does not end in .html and
therefore is not rewritten.
set_from_accept_language should better be a global directive I think.
> I know you’re already busy with the installer, Florian, so maybe we can
> postpone that after the release, unless someone else champions to test it!
>
> Thanks,
> Ludo’.
>
I will test, but I cannot test if certbot and tls work. But of course
the translated website can wait.
Regards,
Florian
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Thu, 09 Apr 2020 03:22:01 GMT)
Full text and
rfc822 format available.
Message #164 received at 26302 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Apr 08, 2020 at 12:02:25AM +0200, pelzflorian (Florian Pelz) wrote:
> set_from_accept_language should better be a global directive I think.
>
No, I was wrong. set_from_accept_language must only appear once, but
not in a global directive. I put it in %extra-content for the
nginx-configuration now. It seems the attached patch works (after
removing the rottlog service), but I could not yet test building the
website i.e. if the redirects really work correctly. It is so slow.
Then again, better break the website before the release than after (if
it does not work). I cannot test tls and certbot anyway.
Regards,
Florian
[deploy-i18n.patch (text/plain, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Thu, 09 Apr 2020 07:46:02 GMT)
Full text and
rfc822 format available.
Message #167 received at 26302 <at> debbugs.gnu.org (full text, mbox):
On Thu, Apr 09, 2020 at 05:21:46AM +0200, pelzflorian (Florian Pelz) wrote:
> but I could not yet test building the
> website i.e. if the redirects really work correctly.
It seems redirects broke like
http://guix.gnu.org/news/gnu-dmd-01-released.html
on my test VM. :/
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Thu, 09 Apr 2020 14:58:02 GMT)
Full text and
rfc822 format available.
Message #170 received at 26302 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, Apr 09, 2020 at 09:45:50AM +0200, pelzflorian (Florian Pelz) wrote:
> It seems redirects broke like
>
> http://guix.gnu.org/news/gnu-dmd-01-released.html
>
> on my test VM. :/
This seems to be fixed by using the attached patch instead.
I have not recreated the berlin test VM yet though, only edited
nginx.conf.
Regards,
Florian
[deploy-i18n-with-redirects.patch (text/plain, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Thu, 09 Apr 2020 15:28:01 GMT)
Full text and
rfc822 format available.
Message #173 received at 26302 <at> debbugs.gnu.org (full text, mbox):
Hi Florian,
"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
> + (redirect "/news/porting-guix-and-guixsd.html" "/$lang/blog/2015/porting-guix-and-guixsd")
Does that mean that /blog/2015/porting-guix-and-guixsd (without /LANG)
will _not_ redirect to /LANG/blog/2015/porting-guix-and-guixsd?
It’s important that all the current URL, without /LANG, remain valid.
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Thu, 09 Apr 2020 17:32:01 GMT)
Full text and
rfc822 format available.
Message #176 received at 26302 <at> debbugs.gnu.org (full text, mbox):
On Thu, Apr 09, 2020 at 05:27:05PM +0200, Ludovic Courtès wrote:
> Hi Florian,
>
> "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
>
> > + (redirect "/news/porting-guix-and-guixsd.html" "/$lang/blog/2015/porting-guix-and-guixsd")
>
> Does that mean that /blog/2015/porting-guix-and-guixsd (without /LANG)
> will _not_ redirect to /LANG/blog/2015/porting-guix-and-guixsd?
>
> It’s important that all the current URL, without /LANG, remain valid.
With the new test VM, not all is working.
/news/porting-guix-and-guixsd.html fails (code 404).
/blog/2015/porting-guix-and-guixsd fails (code 404).
/blog/2015/porting-guix-and-guixsd fails (404).
But /blog/2015/porting-guix-and-guixsd/ works fine.
Well this is difficult to figure out.
Regards,
Florian
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Thu, 09 Apr 2020 18:59:01 GMT)
Full text and
rfc822 format available.
Message #179 received at 26302 <at> debbugs.gnu.org (full text, mbox):
Hi Florian,
On +2020-04-09 19:31:02 +0200, pelzflorian (Florian Pelz) wrote:
> On Thu, Apr 09, 2020 at 05:27:05PM +0200, Ludovic Courtès wrote:
> > Hi Florian,
> >
> > "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
> >
> > > + (redirect "/news/porting-guix-and-guixsd.html" "/$lang/blog/2015/porting-guix-and-guixsd")
> >
> > Does that mean that /blog/2015/porting-guix-and-guixsd (without /LANG)
> > will _not_ redirect to /LANG/blog/2015/porting-guix-and-guixsd?
> >
> > It’s important that all the current URL, without /LANG, remain valid.
>
> With the new test VM, not all is working.
>
> /news/porting-guix-and-guixsd.html fails (code 404).
>
> /blog/2015/porting-guix-and-guixsd fails (code 404).
>
> /blog/2015/porting-guix-and-guixsd fails (404).
>
> But /blog/2015/porting-guix-and-guixsd/ works fine.
>
> Well this is difficult to figure out.
>
Wondering, could dnsmasq help?
> Regards,
> Florian
>
>
>
--
Regards,
Bengt Richter
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Thu, 09 Apr 2020 19:18:01 GMT)
Full text and
rfc822 format available.
Message #182 received at 26302 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, Apr 09, 2020 at 08:58:14PM +0200, Bengt Richter wrote:
> Wondering, could dnsmasq help?
I am already using dnsmasq to access a virtual machine of the machine
hosting the Guix website so <guix.gnu.org/.i18n/de/> can replace the
Guix website while old URLs keep working.
https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/berlin.scm.
I configured dnsmasq with NetworkManager.
(network-manager-service-type config =>
(network-manager-configuration
(inherit config)
(dns "dnsmasq")
(vpn-plugins (list network-manager-openconnect)))))))
Also I made the network manager configuration as described in the Guix
manual.
I made the attached modifications to berlin.scm so I can test without
the VM starting to build the world.
Then I changed my /etc/hosts
127.0.0.1 localhost florianmacbook
::1 localhost florianmacbook
172.28.112.244 guix.gnu.org guix.gnu.org
Then I made the changes from my previous patch, except those
nginx-server-configuration that I removed because I cannot test TLS.
I compile the VM using
~/git/maintenance$ GUILE_LOAD_PATH=$GUILE_LOAD_PATH:$(pwd)/modules guix system vm-image --image-size=5G --fallback /home/florian/git/maintenance/hydra/berlin.scm
(More than --image-size=5G to be safe.) I copy the resulting image
and name it berlin1.img, make it writable and run it via
qemu-system-x86_64 -enable-kvm berlin1.img -m 2048 -nic tap,ifname=tap0,script=no,downscript=no
When running the virtual machine, I log in as root and do “herd stop
mcron” so the VM does not get overloaded building all kinds of things
I do not need. I run the command from “herd schedule mcron” to build
the guix.gnu.org website manually once.
I am confused by all the ways to rewrite, redirect and try_files in
nginx. I would be happy if others with more knowledge could help.
Regards,
Florian
[0001-various-changes-for-local-testing.patch (text/plain, attachment)]
[0002-remove-rottlog.patch (text/plain, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Wed, 01 Jul 2020 20:12:01 GMT)
Full text and
rfc822 format available.
Message #185 received at 26302 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
pelzflorian (Florian Pelz) <pelzflorian <at> pelzflorian.de> writes:
> On Thu, Apr 09, 2020 at 08:58:14PM +0200, Bengt Richter wrote:
>> Wondering, could dnsmasq help?
>
> I am already using dnsmasq to access a virtual machine of the machine
> hosting the Guix website so <guix.gnu.org/.i18n/de/> can replace the
> Guix website while old URLs keep working.
...
> I am confused by all the ways to rewrite, redirect and try_files in
> nginx. I would be happy if others with more knowledge could help.
Hey Florian,
I'm wondering what the current state of the Guix website translation
work is?
I can see the translated website is available at [1], but maybe not with
the full NGinx configuration needed. I also managed to use haunt
locally, but I noticed there were some merge conflicts between the
wip-i18n and master branch.
1: http://guix.gnu.org/.i18n/en/
I can try and help with the NGinx stuff, I've muddled through
configuring NGinx in the past. I think it might be useful to test
without the /.i18n prefix, maybe berlin can be changed to serve the site
at wip-i18n.guix.gnu.org. I also have a server where I might try
deploying the translated website for testing.
Thanks,
Chris
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Sun, 05 Jul 2020 09:09:01 GMT)
Full text and
rfc822 format available.
Message #188 received at 26302 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Sorry, I forgot to address the patch tracker. I wrote some hours ago:
On Thu, Apr 09, 2020 at 07:31:04PM +0200, pelzflorian (Florian Pelz) wrote:
> On Thu, Apr 09, 2020 at 05:27:05PM +0200, Ludovic Courtès wrote:
> > Hi Florian,
> >
> > "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
> >
> > > + (redirect "/news/porting-guix-and-guixsd.html" "/$lang/blog/2015/porting-guix-and-guixsd")
> >
> > Does that mean that /blog/2015/porting-guix-and-guixsd (without /LANG)
> > will _not_ redirect to /LANG/blog/2015/porting-guix-and-guixsd?
> >
> > It’s important that all the current URL, without /LANG, remain valid.
>
> With the new test VM, not all is working.
>
> /news/porting-guix-and-guixsd.html fails (code 404).
>
> /blog/2015/porting-guix-and-guixsd fails (code 404).
>
> /blog/2015/porting-guix-and-guixsd fails (404).
>
> But /blog/2015/porting-guix-and-guixsd/ works fine.
>
> Well this is difficult to figure out.
>
> Regards,
> Florian
An update:
The attached patch for berlin serves more but not all URLs
properly when testing on a VM.
I found one problem; the nginx locations for redirecting old URLs can
be given a higher priority via specifying = before the location path.
I am sorry for neglecting this for so long until
Christopher Baines offered to help a few days ago. Now I too started
investigating myself again.
I cleared the browser cache, restarted nscd and tested these URLs
(with a changed /etc/hosts file pointing guix.gnu.org to the VM):
Still failing:
http://guix.gnu.org/graphics
http://guix.gnu.org/blog/2013/back-from-the-european-lisp-symposium
worked before wip-i18n but stopped working. Hrm.
These seem to fail but I could not properly build the manual yet:
http://guix.gnu.org/manual/en/html_node/Miscellaneous-Services.html
http://guix.gnu.org/manual/html_node/Power-management-Services.html
The rest looks good:
http://guix.gnu.org/news/timely-delivery-of-security-updates.html
http://guix.gnu.org/security/
http://guix.gnu.org/blog/2016/back-from-the-gnu-hackers-meeting-2016/
http://guix.gnu.org/en/blog/2017/back-from-fosdem-2017
http://guix.gnu.org/de/blog/2016/back-from-gbcuw-2016/
works.
http://guix.gnu.org/news/coming-events
http://guix.gnu.org/news
never worked, so it’s OK that these URLs don’t work.
http://guix.gnu.org/news/
This redirect now works but did not work before wip-i18n (??).
I will continue to investigate.
Regards,
Florian
[0001-berlin-Redirect-to-localized-website-by-browser-lang.patch (text/plain, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Thu, 09 Jul 2020 13:11:02 GMT)
Full text and
rfc822 format available.
Message #191 received at 26302 <at> debbugs.gnu.org (full text, mbox):
Hi Florian,
"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
> The attached patch for berlin serves more but not all URLs
> properly when testing on a VM.
>
> I found one problem; the nginx locations for redirecting old URLs can
> be given a higher priority via specifying = before the location path.
One thing that bit me in the past is that regex locations have higher
precedence that other locations, IIRC.
> I am sorry for neglecting this for so long until
> Christopher Baines offered to help a few days ago. Now I too started
> investigating myself again.
>
> I cleared the browser cache, restarted nscd and tested these URLs
> (with a changed /etc/hosts file pointing guix.gnu.org to the VM):
I guess you could check with “wget -v -O /dev/null” or similar, so you
can be sure there’s no client cache interfering.
> Still failing:
>
> http://guix.gnu.org/graphics
>
> http://guix.gnu.org/blog/2013/back-from-the-european-lisp-symposium
>
> worked before wip-i18n but stopped working. Hrm.
What does nginx’s error.log file say?
> These seem to fail but I could not properly build the manual yet:
>
> http://guix.gnu.org/manual/en/html_node/Miscellaneous-Services.html
>
> http://guix.gnu.org/manual/html_node/Power-management-Services.html
If you don’t have the manual at hand, you can just make sure you’re
getting the expected redirect, even if the end result is 404.
> The rest looks good:
>
> http://guix.gnu.org/news/timely-delivery-of-security-updates.html
>
> http://guix.gnu.org/security/
>
> http://guix.gnu.org/blog/2016/back-from-the-gnu-hackers-meeting-2016/
>
> http://guix.gnu.org/en/blog/2017/back-from-fosdem-2017
>
> http://guix.gnu.org/de/blog/2016/back-from-gbcuw-2016/
>
> works.
>
> http://guix.gnu.org/news/coming-events
>
> http://guix.gnu.org/news
>
> never worked, so it’s OK that these URLs don’t work.
Sounds good.
> http://guix.gnu.org/news/
>
> This redirect now works but did not work before wip-i18n (??).
Nice.
I’d be happy to go ahead and deploy this so maybe let’s see and hammer
down those remaining issues and then we can profit! Let us know how we
can help!
Thanks,
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Thu, 09 Jul 2020 14:49:01 GMT)
Full text and
rfc822 format available.
Message #194 received at 26302 <at> debbugs.gnu.org (full text, mbox):
The trouble is that I do not have an understanding in what order nginx
tries which redirections/rewrites. An understanding is needed instead
of investigating dead ends and 3rd party nginx modules.
What I have done a while ago (the berlin patch for guix-maintenance
from my last e-mail contains this):
To redirect accesses only to HTML files I had added
(nginx-location-configuration
(uri "~ (.html|.htm)$")
(body (list "try_files $uri /$lang/$uri /$lang/$uri/index.html =404;")))
However, this does not match when nginx redirects URLs like
http://guix.gnu.org/graphics/
to the index file
http://guix.gnu.org/graphics/index.html
For this reason I had added
rewrite (.*)/$ $1/index.html;
Then it matched. But:
> > Still failing:
> >
> > http://guix.gnu.org/graphics
> >
> > http://guix.gnu.org/blog/2013/back-from-the-european-lisp-symposium
> >
> > worked before wip-i18n but stopped working. Hrm.
Previously when visiting
http://guix.gnu.org/graphics
then nginx too looked up the index file
http://guix.gnu.org/graphics/index.html
This broke. “rewrite (.*)/$ $1/index.html;” had not fixed it.
!! I do not know what to do about it.
My last change addressed this:
On Thu, Jul 09, 2020 at 03:09:57PM +0200, Ludovic Courtès wrote:
> "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
> > I found one problem; the nginx locations for redirecting old URLs can
> > be given a higher priority via specifying = before the location path.
>
> One thing that bit me in the past is that regex locations have higher
> precedence that other locations, IIRC.
Yes, I think this is what happened, the
(nginx-location-configuration
(uri "~ (.html|.htm)$")
(body (list "try_files $uri /$lang/$uri /$lang/$uri/index.html =404;")))
was run before the
location /news/gnu-dmd-01-released.html {
return 301 /blog/2013/gnu-dmd-01-released;
}
and therefore no return was performed.
Changing it to
location = /news/gnu-dmd-01-released.html {
return 301 /$lang/blog/2013/gnu-dmd-01-released;
}
with = in my last described attempt fixed this. Because the location
uri does not end in a slash, using = does not make a difference when
matching, but gives higher priority.
> > I cleared the browser cache, restarted nscd and tested these URLs
> > (with a changed /etc/hosts file pointing guix.gnu.org to the VM):
>
> I guess you could check with “wget -v -O /dev/null” or similar, so you
> can be sure there’s no client cache interfering.
This is a good idea. In the past I had thought things work when in
reality all was broken and it was just cached.
> If you don’t have the manual at hand, you can just make sure you’re
> getting the expected redirect, even if the end result is 404.
You are right, trying to build the manual was pointless.
> > Still failing:
> >
> > http://guix.gnu.org/graphics
> >
> > http://guix.gnu.org/blog/2013/back-from-the-european-lisp-symposium
> >
> > worked before wip-i18n but stopped working. Hrm.
> What does nginx’s error.log file say?
I can only check later, I have deleted my VM because texinfo for
building the manual consumed too much disk space.
> > http://guix.gnu.org/manual/html_node/Power-management-Services.html
>
The URL should have been
http://guix.gnu.org/manual/html_node/Power-Management-Services.html
with capital M. But the old config has the wrong URL as well I think.
I have made some wrong changes since my last mail. Will go back and
rebuild the VM from my last mail now. With what I currently have
redirection explodes
http://guix.gnu.org/manual/html_node/en/en/en/en/en/en/en/en/en/en/en/en/en/en/en/en/en/en/en/en/html_node
!! I think this happened too back then. I have not investigated this yet.
> I’d be happy to go ahead and deploy this so maybe let’s see and hammer
> down those remaining issues and then we can profit! Let us know how we
> can help!
>
> Thanks,
> Ludo’.
A solution for the two problems I marked with !! might be important.
Other than that, I would be very happy if first the berlin patch to
guix-maintenance and then after that the wip-i18n branch finally would
go to master.
Regards,
Florian
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Thu, 09 Jul 2020 16:57:02 GMT)
Full text and
rfc822 format available.
Message #197 received at 26302 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
pelzflorian (Florian Pelz) <pelzflorian <at> pelzflorian.de> writes:
> Sorry, I forgot to address the patch tracker. I wrote some hours ago:
>
> On Thu, Apr 09, 2020 at 07:31:04PM +0200, pelzflorian (Florian Pelz) wrote:
>> On Thu, Apr 09, 2020 at 05:27:05PM +0200, Ludovic Courtès wrote:
>> > Hi Florian,
>> >
>> > "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
>> >
>> > > + (redirect "/news/porting-guix-and-guixsd.html" "/$lang/blog/2015/porting-guix-and-guixsd")
>> >
>> > Does that mean that /blog/2015/porting-guix-and-guixsd (without /LANG)
>> > will _not_ redirect to /LANG/blog/2015/porting-guix-and-guixsd?
>> >
>> > It’s important that all the current URL, without /LANG, remain valid.
>>
>> With the new test VM, not all is working.
>>
>> /news/porting-guix-and-guixsd.html fails (code 404).
>>
>> /blog/2015/porting-guix-and-guixsd fails (code 404).
>>
>> /blog/2015/porting-guix-and-guixsd fails (404).
>>
>> But /blog/2015/porting-guix-and-guixsd/ works fine.
>>
>> Well this is difficult to figure out.
>>
>> Regards,
>> Florian
>
> An update:
>
> The attached patch for berlin serves more but not all URLs
> properly when testing on a VM.
>
> I found one problem; the nginx locations for redirecting old URLs can
> be given a higher priority via specifying = before the location path.
>
> I am sorry for neglecting this for so long until Christopher Baines
> offered to help a few days ago. Now I too started investigating
> myself again.
Thanks for your continued time working on this Florian. I've made a
little bit of progress now, I've taken the wip-i18n branch, applied the
patch attached to this email and deployed that at [1].
1: http://guix-website-test.cbaines.net/
This isn't a close test of the configuration for berlin, but might come
in useful when testing the NGinx configuration.
Thanks,
Chris
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Fri, 10 Jul 2020 17:29:01 GMT)
Full text and
rfc822 format available.
Message #200 received at 26302 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Find attached a desperate patch for guix-maintenance that works around
all listed issues, perhaps not in a nice way.
On Thu, Jul 09, 2020 at 04:48:43PM +0200, pelzflorian (Florian Pelz) wrote:
> With what I currently have
> redirection explodes
>
> http://guix.gnu.org/manual/html_node/en/en/en/en/en/en/en/en/en/en/en/en/en/en/en/en/en/en/en/en/html_node
>
> !! I think this happened too back then. I have not investigated this yet.
>
This is fixed by redirecting not to relative paths,
(redirect "/manual/html_node/Substitutes.html" "../en/html_node/Substitutes.html")
but to absolute paths
(redirect "/manual/html_node/Substitutes.html" "/manual/en/html_node/Substitutes.html")
I think this issue existed before any of my i18n changes.
> Previously when visiting
>
> http://guix.gnu.org/graphics
>
> then nginx too looked up the index file
>
> http://guix.gnu.org/graphics/index.html
>
> This broke. “rewrite (.*)/$ $1/index.html;” had not fixed it.
>
> !! I do not know what to do about it.
The patch introduces a long list of explicit redirects for all URLs
not ending in a slash (except for <http://guix.gnu.org/packages/…>
URLs, they are too many). This is an unmaintainable solution if we
want to keep using URLs not ending in a slash. If we don’t want that,
then if you agree all is ready, please deploy the i18n’d site by
applying this patch to guix-maintenance and shortly thereafter
merge/rebase the guix-artworks wip-i18n branch (shortly because
redirects won’t work in the meantime).
Regards,
Florian
[0001-berlin-Redirect-to-localized-website-by-browser-lang.patch (text/plain, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Fri, 10 Jul 2020 17:32:01 GMT)
Full text and
rfc822 format available.
Message #203 received at 26302 <at> debbugs.gnu.org (full text, mbox):
On Thu, Jul 09, 2020 at 05:56:43PM +0100, Christopher Baines wrote:
> Thanks for your continued time working on this Florian. I've made a
> little bit of progress now, I've taken the wip-i18n branch, applied the
> patch attached to this email and deployed that at [1].
>
> 1: http://guix-website-test.cbaines.net/
>
> This isn't a close test of the configuration for berlin, but might come
> in useful when testing the NGinx configuration.
>
> Thanks,
>
> Chris
This is a nice replica but with all the same issues. Have you made
improvements that should be added to my last patch for
guix-maintenance before it is deployed?
Regards,
Florian
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Sun, 12 Jul 2020 06:27:02 GMT)
Full text and
rfc822 format available.
Message #206 received at 26302 <at> debbugs.gnu.org (full text, mbox):
On Thu, Jul 09, 2020 at 03:09:57PM +0200, Ludovic Courtès wrote:
> "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
> > Still failing:
> >
> > http://guix.gnu.org/graphics
> >
> > http://guix.gnu.org/blog/2013/back-from-the-european-lisp-symposium
> >
> > worked before wip-i18n but stopped working. Hrm.
>
> What does nginx’s error.log file say?
I forgot to try. error.log contains a 404 message:
2020/07/12 08:09:14 [error] 321#0: *1 open() "/srv/guix.gnu.org/graphics" failed (2: No such file or directory), client: 172.28.112.1, server: guix.gnu.org, request: "GET /graphics HTTP/1.1", host: "guix.gnu.org"
2020/07/12 08:09:14 [error] 321#0: *1 open() "/srv/guix.gnu.org/favicon.ico" failed (2: No such file or directory), client: 172.28.112.1, server: guix.gnu.org, request: "GET /favicon.ico HTTP/1.1", host: "guix.gnu.org"
Note that only directories /srv/guix.gnu.org/de/graphics and
/srv/guix.gnu.org/en/graphics exist and no longer
/srv/guix.gnu.org/graphics.
I don’t have ideas for rewriting, because URLs like
<http://guix.gnu.org/index.html> should not become
<http://guix.gnu.org/index.html/>. One could make /en/ go to the
/srv/guix.gnu.org directory, but then <http://guix.gnu.org/graphics>
would always be in English. Or for old URLs use my last proposed patch:
On Fri, Jul 10, 2020 at 07:28:08PM +0200, pelzflorian (Florian Pelz) wrote:
> The patch introduces a long list of explicit redirects for all URLs
> not ending in a slash (except for <http://guix.gnu.org/packages/…>
> URLs, they are too many).
And for new URLs never use <http://guix.gnu.org/new> without a slash
at the end but only <http://guix.gnu.org/new/>.
Regards,
Florian
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Mon, 13 Jul 2020 13:23:01 GMT)
Full text and
rfc822 format available.
Message #209 received at 26302 <at> debbugs.gnu.org (full text, mbox):
Hey!
"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
> On Thu, Jul 09, 2020 at 05:56:43PM +0100, Christopher Baines wrote:
>> Thanks for your continued time working on this Florian. I've made a
>> little bit of progress now, I've taken the wip-i18n branch, applied the
>> patch attached to this email and deployed that at [1].
>>
>> 1: http://guix-website-test.cbaines.net/
>>
>> This isn't a close test of the configuration for berlin, but might come
>> in useful when testing the NGinx configuration.
>>
>> Thanks,
>>
>> Chris
>
> This is a nice replica but with all the same issues. Have you made
> improvements that should be added to my last patch for
> guix-maintenance before it is deployed?
Looks like we’re pretty much ready, no?
I’m happy to press the red button on berlin when we feel ready. Perhaps
we can synchronize on IRC in case things go wrong.
Thanks,
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Mon, 13 Jul 2020 14:49:02 GMT)
Full text and
rfc822 format available.
Message #212 received at 26302 <at> debbugs.gnu.org (full text, mbox):
On Mon, Jul 13, 2020 at 03:22:36PM +0200, Ludovic Courtès wrote:
> Looks like we’re pretty much ready, no?
I think we are.
> I’m happy to press the red button on berlin when we feel ready. Perhaps
> we can synchronize on IRC in case things go wrong.
>
> Thanks,
> Ludo’.
I am currently at my grandma’s and unable to be on IRC most of the time.
I will try to watch IRC now.
I believe the berlin last patch works and suggest reverting otherwise.
Regards,
Florian
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Mon, 13 Jul 2020 16:34:02 GMT)
Full text and
rfc822 format available.
Message #215 received at 26302 <at> debbugs.gnu.org (full text, mbox):
On Mon, Jul 13, 2020 at 04:48:00PM +0200, pelzflorian (Florian Pelz) wrote:
> On Mon, Jul 13, 2020 at 03:22:36PM +0200, Ludovic Courtès wrote:
> > I’m happy to press the red button on berlin when we feel ready. Perhaps
> > we can synchronize on IRC in case things go wrong.
> >
> > Thanks,
> > Ludo’.
>
> I am currently at my grandma’s and unable to be on IRC most of the time.
> I will try to watch IRC now.
> I believe the berlin last patch works and suggest reverting otherwise.
>
> Regards,
> Florian
No sorry, I would prefer not to do synchronous communication in the near future.
I am confident in my latest patch with explicit redirects though.
Regards,
Florian
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Sun, 26 Jul 2020 17:48:01 GMT)
Full text and
rfc822 format available.
Message #218 received at 26302 <at> debbugs.gnu.org (full text, mbox):
Hi Florian & all!
I’m happy to say that I’ve finally taken the time to apply your
maintenance.git patch, reconfigure berlin, merge your ‘wip-i18n’ branch
in guix-artwork.git, and… tadaam!
https://guix.gnu.org/
At first sight, everything seems to be working fine, but please do take
a look and report any issues!
Thank you for all the work, Florian, you rock! … and sorry it took so
long; I guess hitting the red button felt too frightening. :-)
Should we publicize a process to contribute translations? It could be a
page on the web site linked from the bottom of each page or something.
Thoughts?
It would also be nice to have a blog post mentioning this, perhaps
explaining the tools behind it, and why we think it matters. I could
contribute a paragraph on linguistic diversity. :-)
Thanks!
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Sun, 26 Jul 2020 17:53:01 GMT)
Full text and
rfc822 format available.
Message #221 received at 26302 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Sun, 26 Jul 2020 18:59:02 GMT)
Full text and
rfc822 format available.
Message #224 received at 26302 <at> debbugs.gnu.org (full text, mbox):
On Sun, Jul 26, 2020 at 07:46:55PM +0200, Ludovic Courtès wrote:
> Hi Florian & all!
>
> I’m happy to say that I’ve finally taken the time to apply your
> maintenance.git patch, reconfigure berlin, merge your ‘wip-i18n’ branch
> in guix-artwork.git, and… tadaam!
>
> https://guix.gnu.org/
Thank you! I am so happy. Although …
>
> At first sight, everything seems to be working fine, but please do take
> a look and report any issues!
Ohh sorry, the manual disappeared. I suppose it is built in /srv/…/manual/?
:(
> Should we publicize a process to contribute translations? It could be a
> page on the web site linked from the bottom of each page or something.
> Thoughts?
One way would be to tar up the website and send it to the Translation
Project. I don’t know about the status of the Weblate plans.
> It would also be nice to have a blog post mentioning this, perhaps
> explaining the tools behind it, and why we think it matters. I could
> contribute a paragraph on linguistic diversity. :-)
>
> Thanks!
>
> Ludo’.
So far I think Guix always needs more users and translations help.
Also Scheme’s homoiconicity makes it easy to write translation macros.
I will think some more what I could say about this tomorrow.
Regards,
Florian
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Mon, 27 Jul 2020 01:56:01 GMT)
Full text and
rfc822 format available.
Message #227 received at 26302 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Ludovic Courtès <ludo <at> gnu.org> wrote:
> https://guix.gnu.org/
>
> report any issues!
The obvious:
| <!DOCTYPE html><html lang="lang-tag">
^~~~~~~~
;-)
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Mon, 27 Jul 2020 11:22:01 GMT)
Full text and
rfc822 format available.
Message #230 received at 26302 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Mon, 27 Jul 2020 11:30:01 GMT)
Full text and
rfc822 format available.
Message #233 received at 26302 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Jul 27, 2020 at 04:54:55AM +0300, Dmitry Alexandrov wrote:
> Ludovic Courtès <ludo <at> gnu.org> wrote:
> > https://guix.gnu.org/
> >
> > report any issues!
>
> The obvious:
>
> | <!DOCTYPE html><html lang="lang-tag">
> ^~~~~~~~
>
> ;-)
Thank you! Clearly testing is necessary.
I will push the attached patch this evening.
Regards,
Florian
[0001-Fix-value-of-html-lang-attribute.patch (text/plain, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Mon, 27 Jul 2020 16:02:02 GMT)
Full text and
rfc822 format available.
Message #236 received at 26302 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Jul 26, 2020 at 08:58:11PM +0200, pelzflorian (Florian Pelz) wrote:
> Ohh sorry, the manual disappeared. I suppose it is built in /srv/…/manual/?
Thank you Ludo for fixing this!
> > Should we publicize a process to contribute translations? It could be a
> > page on the web site linked from the bottom of each page or something.
> > Thoughts?
>
> One way would be to tar up the website and send it to the Translation
> Project. I don’t know about the status of the Weblate plans.
I would suggest sending a tar archive with the website directory of
guix-artwork to the TP once more (ideally along with a current tarball
of Guix proper). Also I think even if once we use different
technology like Weblate instead of the TP, the TP should remain the
go-to place for our translators, because it is where many other
projects’ translators gather.
> > It would also be nice to have a blog post mentioning this, perhaps
> > explaining the tools behind it, and why we think it matters. I could
> > contribute a paragraph on linguistic diversity. :-)
> >
> > Thanks!
> >
> > Ludo’.
>
> So far I think Guix always needs more users and translations help.
> Also Scheme’s homoiconicity makes it easy to write translation macros.
> I will think some more what I could say about this tomorrow.
Please find attached a first draft blog post.
Regards,
Florian
[1st-draft-blog-post-translatable-website.md (text/markdown, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Mon, 27 Jul 2020 20:21:02 GMT)
Full text and
rfc822 format available.
Message #239 received at 26302 <at> debbugs.gnu.org (full text, mbox):
On Mon, Jul 27, 2020 at 01:28:48PM +0200, pelzflorian (Florian Pelz) wrote:
> Subject: [PATCH] Fix value of html lang attribute.
>
> Reported by Dmitry Alexandrov <dag <at> gnui.org>.
>
> * website/apps/base/templates/theme.scm (theme): Add missing unquote.
> ---
Pushed as 4ab8ab5c2f04dbb584a76d842a7864454013bba1. Good catch.
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Tue, 28 Jul 2020 09:45:02 GMT)
Full text and
rfc822 format available.
Message #242 received at 26302 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I just noticed simon and I forgot to reply to the bug.
Here is our conversation on the English (US) display name.
----- Forwarded message from zimoun <zimon.toutoune <at> gmail.com> -----
Date: Mon, 27 Jul 2020 21:25:06 +0200
From: zimoun <zimon.toutoune <at> gmail.com>
To: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
Subject: website translation English (US)?
Hi Florian,
Thank you for the work! Really nice.
Aside, why is it "English (US)" and not simply "English". Well, I am
not sure that the translation to "English (UK)" would be really
different.
Back to holidays (on September) I will try to do the French one if
roptat does not beat me. ;-)
All the best,
simon
----- End forwarded message -----
----- Forwarded message from zimoun <zimon.toutoune <at> gmail.com> -----
Date: Tue, 28 Jul 2020 00:40:43 +0200
From: zimoun <zimon.toutoune <at> gmail.com>
To: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
Subject: Re: website translation English (US)?
On Mon, 27 Jul 2020 at 22:49, "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> wrote:
> The differences would be few and far between (some
> “have”s might become “have got”s, publicized becomes publicised) and
> there currently is no UK English translation.
>
> Hmm. I am hesitant to remove the (US) from English (US). I agree
> that if we do not have a separate English (UK) translation (Guix
> proper does not), then it would look better without the country code.
> However if we ever do get a separate UK/AU/… variant, then a rename to
> English (US) would break all older PO files.
Well, I have never checked but I do not know if the manual fully
respects US English. I understand the PO files issue but currently the
trasnlationproject.org has en_GB and en_ZA registered, only.
From my point of view, it looks weird to have French (FR), French (CA),
French (BE), etc.. And even it is not exactly the same French, as
French native, I can read and understand all kind of French (which is
not the case about listen) even if some sentence or vocabulary could
sound awkward. Whatever!
I have not checked in the code (just pulled now :-)), but is it not
possible to add a comment in guix-website.pot about the variant and in
the same time having just “English” as msgid i.e. change to (G_
"English") in utils.scm. Or something like that.
The English variant would be still possible and it would require an
update by all the translator – which appears to me fine.
WDYT?
All the best,
simon
ps:
Thank you again for all this tough work.
----- End forwarded message -----
----- Forwarded message from "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> -----
Date: Tue, 28 Jul 2020 11:23:56 +0200
From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: zimoun <zimon.toutoune <at> gmail.com>
Subject: Re: website translation English (US)?
Since the only reason I have for wanting to keep English (US) is a
minor, technical one, you are of course right, simon. Better now
than later.
On Tue, Jul 28, 2020 at 12:40:43AM +0200, zimoun wrote:
> Well, I have never checked but I do not know if the manual fully
> respects US English.
I think it only contains U.S. English.
> I understand the PO files issue but currently the
> trasnlationproject.org has en_GB and en_ZA registered, only.
AFAIK most variants of English are similar to en_GB, so IIRC some
projects have an en.po for en_GB and an en_US.po for U.S. English.
This makes en.po the default for other Englishes, which is usually
enough.
> From my point of view, it looks weird to have French (FR), French (CA),
> French (BE), etc.. And even it is not exactly the same French, as
> French native, I can read and understand all kind of French (which is
> not the case about listen) even if some sentence or vocabulary could
> sound awkward. Whatever!
Yes, I concur.
> I have not checked in the code (just pulled now :-)), but is it not
> possible to add a comment in guix-website.pot about the variant and in
> the same time having just “English” as msgid i.e. change to (G_
> "English") in utils.scm. Or something like that.
>
> The English variant would be still possible and it would require an
> update by all the translator – which appears to me fine.
In the attached patch I added a comment *maybe* not to change the
(G_ "English"). I do not know how many out-of-date translations will exist,
Regards,
Florian
----- End forwarded message -----
I will push the patch this evening.
Regards,
Florian
[0001-website-Change-display-name-of-default-locale-from-E.patch (text/plain, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Tue, 28 Jul 2020 10:04:02 GMT)
Full text and
rfc822 format available.
Message #245 received at 26302 <at> debbugs.gnu.org (full text, mbox):
Hi Florian,
> I will push the patch this evening.
Cool! Thank you.
All the best,
simon
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Tue, 28 Jul 2020 16:03:02 GMT)
Full text and
rfc822 format available.
Message #248 received at 26302 <at> debbugs.gnu.org (full text, mbox):
On Tue, Jul 28, 2020 at 11:44:25AM +0200, pelzflorian (Florian Pelz) wrote:
> I will push the patch this evening.
Pushed as 68410f28e374c6b322fa69e1fbc5775e1bb0c8a4 (with minor changes
to the commit message and a smaller diff of the PO file).
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Tue, 28 Jul 2020 21:51:02 GMT)
Full text and
rfc822 format available.
Message #251 received at 26302 <at> debbugs.gnu.org (full text, mbox):
Hello Florian,
(+Cc: Julien.)
"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
> On Sun, Jul 26, 2020 at 08:58:11PM +0200, pelzflorian (Florian Pelz) wrote:
>> Ohh sorry, the manual disappeared. I suppose it is built in /srv/…/manual/?
>
> Thank you Ludo for fixing this!
That’s my modest contribution. :-)
>> > Should we publicize a process to contribute translations? It could be a
>> > page on the web site linked from the bottom of each page or something.
>> > Thoughts?
>>
>> One way would be to tar up the website and send it to the Translation
>> Project. I don’t know about the status of the Weblate plans.
>
> I would suggest sending a tar archive with the website directory of
> guix-artwork to the TP once more (ideally along with a current tarball
> of Guix proper). Also I think even if once we use different
> technology like Weblate instead of the TP, the TP should remain the
> go-to place for our translators, because it is where many other
> projects’ translators gather.
I’m not as enthusiastic as you are about the TP but why not.
Julien, what are your thoughts?
>> > It would also be nice to have a blog post mentioning this, perhaps
>> > explaining the tools behind it, and why we think it matters. I could
>> > contribute a paragraph on linguistic diversity. :-)
>> >
>> > Thanks!
>> >
>> > Ludo’.
>>
>> So far I think Guix always needs more users and translations help.
>> Also Scheme’s homoiconicity makes it easy to write translation macros.
>> I will think some more what I could say about this tomorrow.
>
> Please find attached a first draft blog post.
Woow, that was fast!
> title: Adding translations to Guix’ website
> date: 2020-07-28 15:00
> author: Florian Pelz
> tags: Community
> ---
> As part of [GNU](https://www.gnu.org/), Guix aims to bring freedom to
> computer users all over the world, no matter the languages they
> (prefer to) speak. For example, Guix users asking for [help](/help)
^
You should use absolute URLs to get valid links on, say,
<https://planet.gnu.org>.
> Guix’ website is written in
> [SHTML](https://www.nongnu.org/guile-lib/doc/ref/htmlprag/), which is
> a variant of HTML (in which web pages are usually written) that
I think it’s technically SXHTML, no?
https://www.gnu.org/software/guile/manual/html_node/SXML.html
> However, this mixing makes it more difficult to extract the strings to
> be translated. We therefore cannot take the same approach as
> [gnu.org](https://www.gnu.org/), which uses a software called
s/a software/a software package/
> With ideas for and by a more diverse community, we can look forward to
> a bright multi-lingual future. Please get in touch with [the
> Translation Project](https://translationproject.org/team/) or [us Guix
> developers](/contact) if you want to help make Guix’ website available
> in your language as well!
I wonder if we should link to more practical step-by-step instructions
on how to get started translating, to lower the barrier for those who
want to get started without engaging in possibly open-ended discussions
with the fabulous Guix team. :-)
Anyway the post looks great to me! Perhaps you should publish it once
the TP (or Weblate?) is set up? When you publish, make sure to adjust
the date at the top and add the “About” footer at the bottom (which you
can take from the latest post).
I’ll be mostly away from keyboard in the coming weeks so you don’t need
to wait for me.
Thank you!
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Wed, 29 Jul 2020 01:22:01 GMT)
Full text and
rfc822 format available.
Message #254 received at 26302 <at> debbugs.gnu.org (full text, mbox):
Le Tue, 28 Jul 2020 23:50:13 +0200,
Ludovic Courtès <ludo <at> gnu.org> a écrit :
>
> I’m not as enthusiastic as you are about the TP but why not.
> Julien, what are your thoughts?
Not sure we're going to do the switch soon, so we can send it to the TP.
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Wed, 29 Jul 2020 13:57:02 GMT)
Full text and
rfc822 format available.
Message #257 received at 26302 <at> debbugs.gnu.org (full text, mbox):
On Wed, Jul 29, 2020 at 03:21:09AM +0200, Julien Lepiller wrote:
> Le Tue, 28 Jul 2020 23:50:13 +0200,
> Ludovic Courtès <ludo <at> gnu.org> a écrit :
> >
> > I’m not as enthusiastic as you are about the TP but why not.
> > Julien, what are your thoughts?
>
> Not sure we're going to do the switch soon, so we can send it to the TP.
Since there is no Makefile, I suppose it is enough to put the website
directory of the guix-artwork repo in a tar file.
What version number should we give it? That of Guix, or a YYYYMMDD?
I suppose the version number should be part of the POT file’s
Project-Id-Version field and the tar filename, but I don’t know.
Should we at the same time send a tarball of Guix’ prospective new
release?
Could you Julien or someone else send the tarball(s) off to the TP
coordinator?
Regards,
Florian
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Wed, 29 Jul 2020 19:22:02 GMT)
Full text and
rfc822 format available.
Message #260 received at 26302 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Jul 28, 2020 at 11:50:13PM +0200, Ludovic Courtès wrote:
> "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
> > Guix’ website is written in
> > [SHTML](https://www.nongnu.org/guile-lib/doc/ref/htmlprag/), which is
> > a variant of HTML (in which web pages are usually written) that
>
> I think it’s technically SXHTML, no?
> https://www.gnu.org/software/guile/manual/html_node/SXML.html
The result is not valid XHTML. I will just call it SXML now, which is
what the Haunt info manual calls it.
> I wonder if we should link to more practical step-by-step instructions
> on how to get started translating, to lower the barrier for those who
> want to get started without engaging in possibly open-ended discussions
> with the fabulous Guix team. :-)
I don’t know how best to integrate step-by-step instructions. While
the TP has instructions
<https://translationproject.org/html/translators.html>, they seem more
intimidating to me than, as a first step, talking to the helpful
people at the TP. A few steps also describe how to disclaim
copyright, which Guix does not ask for anyway.
I propose the attached blog post draft if noone objects, taking into
account Ludo’s helpful suggestions. Is it missing anything
interesting about the i18n system?
Should I add it to the website as a draft? I suppose no, I suppose I
should just publish it as-is once guix-website.pot is at the TP.
Regards,
Florian
[2nd-draft-blog-post-translatable-website.md (text/markdown, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Fri, 31 Jul 2020 14:46:02 GMT)
Full text and
rfc822 format available.
Message #263 received at 26302 <at> debbugs.gnu.org (full text, mbox):
Hi!
"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
> On Tue, Jul 28, 2020 at 11:50:13PM +0200, Ludovic Courtès wrote:
>> "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
>> > Guix’ website is written in
>> > [SHTML](https://www.nongnu.org/guile-lib/doc/ref/htmlprag/), which is
>> > a variant of HTML (in which web pages are usually written) that
>>
>> I think it’s technically SXHTML, no?
>> https://www.gnu.org/software/guile/manual/html_node/SXML.html
>
> The result is not valid XHTML. I will just call it SXML now, which is
> what the Haunt info manual calls it.
OK.
>> I wonder if we should link to more practical step-by-step instructions
>> on how to get started translating, to lower the barrier for those who
>> want to get started without engaging in possibly open-ended discussions
>> with the fabulous Guix team. :-)
>
> I don’t know how best to integrate step-by-step instructions. While
> the TP has instructions
> <https://translationproject.org/html/translators.html>, they seem more
> intimidating to me than, as a first step, talking to the helpful
> people at the TP. A few steps also describe how to disclaim
> copyright, which Guix does not ask for anyway.
Yeah, dunno. In the post you could duplicate/filter those steps just so
it’s more directly understandable what it takes to translate pages.
Your call!
> I propose the attached blog post draft if noone objects, taking into
> account Ludo’s helpful suggestions. Is it missing anything
> interesting about the i18n system?
>
> Should I add it to the website as a draft? I suppose no, I suppose I
> should just publish it as-is once guix-website.pot is at the TP.
Yes.
> title: Adding translations to Guix’ website
> date: 2020-07-29 15:00
> author: Florian Pelz
> tags: Community
LGTM! :-)
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Mon, 03 Aug 2020 14:54:02 GMT)
Full text and
rfc822 format available.
Message #266 received at 26302 <at> debbugs.gnu.org (full text, mbox):
Hi,
"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
> Since there is no Makefile, I suppose it is enough to put the website
> directory of the guix-artwork repo in a tar file.
Sounds good to me.
> What version number should we give it? That of Guix, or a YYYYMMDD?
> I suppose the version number should be part of the POT file’s
> Project-Id-Version field and the tar filename, but I don’t know.
I’d say YYYYMMDD. The coordinator might have suggestions.
> Should we at the same time send a tarball of Guix’ prospective new
> release?
It can happen separately but it’d be nice!
> Could you Julien or someone else send the tarball(s) off to the TP
> coordinator?
That’d be great. Julien, let us know if you’d rather hand over this
responsibility.
Cheers,
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Tue, 04 Aug 2020 15:38:01 GMT)
Full text and
rfc822 format available.
Message #269 received at 26302 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Jul 31, 2020 at 04:45:31PM +0200, Ludovic Courtès wrote:
> "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
> > On Tue, Jul 28, 2020 at 11:50:13PM +0200, Ludovic Courtès wrote:
> >> I wonder if we should link to more practical step-by-step instructions
> >> on how to get started translating, to lower the barrier for those who
> >> want to get started without engaging in possibly open-ended discussions
> >> with the fabulous Guix team. :-)
> > I don’t know how best to integrate step-by-step instructions. While
> > the TP has instructions
> > <https://translationproject.org/html/translators.html>, they seem more
> > intimidating to me than, as a first step, talking to the helpful
> > people at the TP. A few steps also describe how to disclaim
> > copyright, which Guix does not ask for anyway.
> Yeah, dunno. In the post you could duplicate/filter those steps just so
> it’s more directly understandable what it takes to translate pages.
> Your call!
I rewrote the part for translators that comes before the first source
code in the post and changed it again and again while a
not-yet-Guix-using friend gave helpful feedback. I attach the current
draft blog post, but currently you can also read it at:
https://pelzflorian.de/adding-translations-to-guix-website/index.html
Regards,
Florian
[3rd-draft-adding-translations-to-guix-website.md (text/markdown, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Fri, 21 Aug 2020 00:15:01 GMT)
Full text and
rfc822 format available.
Message #272 received at 26302 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Aug 03, 2020 at 04:53:48PM +0200, Ludovic Courtès wrote:
> "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
> > What version number should we give it? That of Guix, or a YYYYMMDD?
> > I suppose the version number should be part of the POT file’s
> > Project-Id-Version field and the tar filename, but I don’t know.
>
> I’d say YYYYMMDD. The coordinator might have suggestions.
I will push the attached patch if there are no objections.
> > Could you Julien or someone else send the tarball(s) off to the TP
> > coordinator?
>
> That’d be great. Julien, let us know if you’d rather hand over this
> responsibility.
Is it OK if you send it when you have time after the patch is in?
Regards,
Florian
[0001-website-nls-Include-package-version-in-the-POT-file.patch (text/plain, attachment)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Fri, 21 Aug 2020 00:42:02 GMT)
Full text and
rfc822 format available.
Message #275 received at 26302 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Sure, let me know when the patcg is pushed and I'll send a tarball to the TP.
On 2020年8月20日 20:14:20 GMT-04:00, "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> wrote:
>On Mon, Aug 03, 2020 at 04:53:48PM +0200, Ludovic Courtès wrote:
>> "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
>> > What version number should we give it? That of Guix, or a
>YYYYMMDD?
>> > I suppose the version number should be part of the POT file’s
>> > Project-Id-Version field and the tar filename, but I don’t know.
>>
>> I’d say YYYYMMDD. The coordinator might have suggestions.
>
>I will push the attached patch if there are no objections.
>
>> > Could you Julien or someone else send the tarball(s) off to the TP
>> > coordinator?
>>
>> That’d be great. Julien, let us know if you’d rather hand over this
>> responsibility.
>
>Is it OK if you send it when you have time after the patch is in?
>
>Regards,
>Florian
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Fri, 21 Aug 2020 07:52:02 GMT)
Full text and
rfc822 format available.
Message #278 received at 26302 <at> debbugs.gnu.org (full text, mbox):
On Thu, Aug 20, 2020 at 08:41:33PM -0400, Julien Lepiller wrote:
> Sure, let me know when the patcg is pushed and I'll send a tarball to the TP.
I have pushed now. I hope and believe the TP robot and coordinator
will have no complaints. Thank you for sending.
Regards,
Florian
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Sun, 23 Aug 2020 15:56:01 GMT)
Full text and
rfc822 format available.
Message #281 received at 26302 <at> debbugs.gnu.org (full text, mbox):
Hi Florian,
"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
> On Fri, Jul 31, 2020 at 04:45:31PM +0200, Ludovic Courtès wrote:
>> "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
>> > On Tue, Jul 28, 2020 at 11:50:13PM +0200, Ludovic Courtès wrote:
>> >> I wonder if we should link to more practical step-by-step instructions
>> >> on how to get started translating, to lower the barrier for those who
>> >> want to get started without engaging in possibly open-ended discussions
>> >> with the fabulous Guix team. :-)
>> > I don’t know how best to integrate step-by-step instructions. While
>> > the TP has instructions
>> > <https://translationproject.org/html/translators.html>, they seem more
>> > intimidating to me than, as a first step, talking to the helpful
>> > people at the TP. A few steps also describe how to disclaim
>> > copyright, which Guix does not ask for anyway.
>> Yeah, dunno. In the post you could duplicate/filter those steps just so
>> it’s more directly understandable what it takes to translate pages.
>> Your call!
>
> I rewrote the part for translators that comes before the first source
> code in the post and changed it again and again while a
> not-yet-Guix-using friend gave helpful feedback. I attach the current
> draft blog post, but currently you can also read it at:
>
> https://pelzflorian.de/adding-translations-to-guix-website/index.html
>
> Regards,
> Florian
>
> title: Adding translations to Guix’ website
> date: 2020-08-01 15:00
> author: Florian Pelz
> tags: Community
Sorry for the long delay—vacations… so sweet. ;-)
This version also LGTM. Perhaps you can commit it tomorrow around noon,
when it’s more likely to be noticed than on a sunny (?) Sunday.
Thanks again!
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Mon, 24 Aug 2020 12:48:02 GMT)
Full text and
rfc822 format available.
Message #284 received at 26302 <at> debbugs.gnu.org (full text, mbox):
On Sun, Aug 23, 2020 at 05:55:21PM +0200, Ludovic Courtès wrote:
> Sorry for the long delay—vacations… so sweet. ;-)
Sounds nice. I wasn’t home either and the guix-website.pot is not
online yet, but I believe the wheels are in motion already.
> This version also LGTM. Perhaps you can commit it tomorrow around noon,
> when it’s more likely to be noticed than on a sunny (?) Sunday.
I will wait for around noon on the day the TP publishes
guix-website.pot.
Regards,
Florian
Information forwarded
to
bug-guix <at> gnu.org:
bug#26302; Package
guix.
(Mon, 24 Aug 2020 14:07:02 GMT)
Full text and
rfc822 format available.
Message #287 received at 26302 <at> debbugs.gnu.org (full text, mbox):
Hallo!
"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> skribis:
> On Sun, Aug 23, 2020 at 05:55:21PM +0200, Ludovic Courtès wrote:
>> Sorry for the long delay—vacations… so sweet. ;-)
>
> Sounds nice. I wasn’t home either and the guix-website.pot is not
> online yet, but I believe the wheels are in motion already.
>
>
>> This version also LGTM. Perhaps you can commit it tomorrow around noon,
>> when it’s more likely to be noticed than on a sunny (?) Sunday.
>
> I will wait for around noon on the day the TP publishes
> guix-website.pot.
Alright, makes sense!
Ludo’.
bug closed, send any further explanations to
26302 <at> debbugs.gnu.org and ng0 <contact.ng0 <at> cryptolab.net>
Request was from
Tobias Geerinckx-Rice <me <at> tobias.gr>
to
control <at> debbugs.gnu.org.
(Wed, 30 Sep 2020 09:31:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Wed, 28 Oct 2020 11:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 181 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.