[PATCH] website: Add publications page

  • Done
  • quality assurance status badge
Details
4 participants
  • Julien Lepiller
  • Ludovic Courtès
  • Luis Felipe
  • pelzflorian (Florian Pelz)
Owner
unassigned
Submitted by
Luis Felipe
Severity
normal
L
P
P
pelzflorian (Florian Pelz) wrote on 25 May 2021 15:44
(name . Luis Felipe)(address . luis.felipe.la@protonmail.com)(address . 48637@debbugs.gnu.org)
20210525134405.hmevensj5m42iluo@pelzflorian.localdomain
On Mon, May 24, 2021 at 11:35:24PM +0000, Luis Felipe via Guix-patches via wrote:
Toggle quote (4 lines)
> Hi,
>
> This patch adds a new Publications page to the website.

Nice!

I could not test yet, but maybe make the date string in

Toggle quote (19 lines)
> +(define (publication->shtml publication)
> + "Return an SHTML representation of the given publication object.
> +
> + PUBLICATION (<publication>)
> + A publication object as defined in (apps media types)."
> + `(a
> + (@ (class "publication-preview")
> + (href ,(publication-url publication)))
> +
> + (h3
> + (@ (lang ,(publication-language publication))
> + (class "publication-title"))
> + ,(publication-title publication))
> +
> + (p
> + (@ (class "publication-info"))
> + ,(G_ `("Published "
> + ,(date->string (publication-date publication) "~b ~d, ~Y")

translatable like website/apps/blog/templates/components.scm line 33.


Toggle quote (14 lines)
> +(define (publication-list-t publications)
> + "Return the Publication list page in SHTML.
> +
> + PUBLICATIONS (list of <publication>)
> + See the (apps media types) module for information on the
> + <publication> type."
> + (theme
> + #:title (C_ "webpage title" '("Publications"))
> + #:description
> + (G_ "A list of written publications about GNU Guix.")
> + #:keywords
> + ;; TRANSLATORS: |-separated list of webpage keywords.
> + (string-split (G_ "Publications|Papers") #\|)

I don’t know, but should there really be only none of the other pages’
SEO keywords? All other occurrences of #:keywords begin with

GNU|Linux|Unix|Free software


Regards,
Florian
L
L
Luis Felipe wrote on 25 May 2021 16:37
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)(name . 48637@debbugs.gnu.org)(address . 48637@debbugs.gnu.org)
3mZyc8pra0TLSyJS6RlWIrQGBnje7dT_EMRBeOdFC_Z2wsZGoaI1rVNVtoiI57KEOvolEiahl6j7M4UBsoO0NsuieAfDPIkZQ-MR8C5UhAE=@protonmail.com
??????? Original Message ???????
On Tuesday, May 25, 2021 1:44 PM, pelzflorian (Florian Pelz) <pelzflorian@pelzflorian.de> wrote:

Toggle quote (47 lines)
> On Mon, May 24, 2021 at 11:35:24PM +0000, Luis Felipe via Guix-patches via wrote:
>
> > Hi,
> > This patch adds a new Publications page to the website.
>
> Nice!
>
> I could not test yet, but maybe make the date string in
>
> > +(define (publication->shtml publication)
> >
> > - "Return an SHTML representation of the given publication object.
> > -
> > - PUBLICATION (<publication>)
> > - A publication object as defined in (apps media types)."
> >
> >
> > - `(a
> > - (@ (class "publication-preview")
> > - (href ,(publication-url publication)))
> >
> >
> > -
> > - (h3
> > - (@ (lang ,(publication-language publication))
> >
> >
> > - (class "publication-title"))
> >
> >
> > - ,(publication-title publication))
> >
> >
> > -
> > - (p
> > - (@ (class "publication-info"))
> >
> >
> > - ,(G_ `("Published "
> >
> >
> > - ,(date->string (publication-date publication) "~b ~d, ~Y")
> >
> >
>
> translatable like website/apps/blog/templates/components.scm line 33.

Yeah. Would it as follows? (I still struggle with i18n):

(p
(@ (class "publication-info"))
,(G_ `("Published "
,(date->string (publication-date publication)
(C_ "SRFI-19 date->string format" "~b ~d, ~Y"))
" by "
,(string-join (publication-authors publication) ", "))))

Also, I think the delimiter for "string-join" in the list of authors should be translated because that comma is not used in Japanese, for example. So would it be ok like this:

(p
(@ (class "publication-info"))
,(G_ `("Published "
,(date->string (publication-date publication)
(C_ "SRFI-19 date->string format" "~b ~d, ~Y"))
" by "
,(string-join (publication-authors publication)
(C_ "Separator of items in a list" ", ")))))


I'm still unsure about when I should use a context and when a TRANSLATORS comment...


Toggle quote (24 lines)
> > +(define (publication-list-t publications)
> >
> > - "Return the Publication list page in SHTML.
> > -
> > - PUBLICATIONS (list of <publication>)
> > - See the (apps media types) module for information on the
> >
> >
> > - <publication> type."
> >
> >
> > - (theme
> > - #:title (C_ "webpage title" '("Publications"))
> > - #:description
> > - (G_ "A list of written publications about GNU Guix.")
> > - #:keywords
> > - ;; TRANSLATORS: |-separated list of webpage keywords.
> > - (string-split (G_ "Publications|Papers") #\|)
>
> I don’t know, but should there really be only none of the other pages’
> SEO keywords? All other occurrences of #:keywords begin with
>
> GNU|Linux|Unix|Free software

Hmm, I don't know... Last time I checked, I think I saw that search engines care more about the page content than meta keywords. So I don't think it would make a difference.

Also, if it turns out to be important to repeat these keywords in all pages, maybe it would be better to add these by default in (apps base templates theme).
P
P
pelzflorian (Florian Pelz) wrote on 25 May 2021 20:21
(name . Luis Felipe)(address . luis.felipe.la@protonmail.com)(name . 48637@debbugs.gnu.org)(address . 48637@debbugs.gnu.org)
20210525182123.a5l4d6t3xt3qn437@pelzflorian.localdomain
On Tue, May 25, 2021 at 02:37:03PM +0000, Luis Felipe wrote:
Toggle quote (10 lines)
> Yeah. Would it as follows? (I still struggle with i18n):
>
> (p
> (@ (class "publication-info"))
> ,(G_ `("Published "
> ,(date->string (publication-date publication)
> (C_ "SRFI-19 date->string format" "~b ~d, ~Y"))
> " by "
> ,(string-join (publication-authors publication) ", "))))

It would need to be

(p
(@ (class "publication-info"))
,(let ((format (C_ "SRFI-19 date->string format" "~b ~d, ~Y")))
(G_ `("Published "
,(date->string (publication-date publication) format)
" by "
,(string-join (publication-authors publication) ", ")
""))))

The let is needed because C_ cannot be nested inside G_ because the
sexp-xgettext script parses Scheme files in only one pass currently.
(And I’m not motivated enough to make it go back to parse the nested
C_ because nesting is seldom needed.)

The "" at the end is needed so (string-join …) gets its own XML
element that can be moved by translators.

Without "":

msgid "Published <1/> by "

With "":

msgid "Published <1/> by <2/>"



Toggle quote (7 lines)
> Also, I think the delimiter for "string-join" in the list of authors
> should be translated because that comma is not used in Japanese, for
> example. So would it be ok like this:
> […]
> ,(string-join (publication-authors publication)
> (C_ "Separator of items in a list" ", ")))))

Yes, you are very right, although as above please move it to the let.
Then it can become ? or ? or whatever; I don’t know what is common
in Japan.


Toggle quote (3 lines)
> I'm still unsure about when I should use a context and when a
> TRANSLATORS comment...

A msgctxt should be used if another ", " string with different
translations might be added. I would use a context, I think, but
maybe it is an abundance of caution.

Regards,
Florian
P
P
pelzflorian (Florian Pelz) wrote on 25 May 2021 20:35
(name . Luis Felipe)(address . luis.felipe.la@protonmail.com)
20210525183552.fq3t454p32exu6bf@pelzflorian.localdomain
On Tue, May 25, 2021 at 02:37:03PM +0000, Luis Felipe wrote:
Toggle quote (23 lines)
> On Tuesday, May 25, 2021 1:44 PM, pelzflorian (Florian Pelz) <pelzflorian@pelzflorian.de> wrote:
> > On Mon, May 24, 2021 at 11:35:24PM +0000, Luis Felipe via Guix-patches via wrote:
> > > - (theme
> > > - #:title (C_ "webpage title" '("Publications"))
> > > - #:description
> > > - (G_ "A list of written publications about GNU Guix.")
> > > - #:keywords
> > > - ;; TRANSLATORS: |-separated list of webpage keywords.
> > > - (string-split (G_ "Publications|Papers") #\|)
> >
> > I don’t know, but should there really be only none of the other pages’
> > SEO keywords? All other occurrences of #:keywords begin with
> >
> > GNU|Linux|Unix|Free software
>
> Hmm, I don't know... Last time I checked, I think I saw that search
> engines care more about the page content than meta keywords. So I
> don't think it would make a difference.
>
> Also, if it turns out to be important to repeat these keywords in
> all pages, maybe it would be better to add these by default in (apps
> base templates theme).

I did not know and just thought we should cargo-cult it. Does it
matter? Maybe @sirgazil has an opinion?

Regards,
Florian
L
L
Luis Felipe wrote on 25 May 2021 21:14
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
4yUVgzJQNMVwC11b6b1_p_81svvu4pEZJV2bMzJwb2nmoduNNmYQVuEGRQbJf4WUWnIs0dbV1lONF-SdpZz-NaR6rUqUGyoX80m9K0Per40=@protonmail.com
On Tuesday, May 25, 2021 6:35 PM, pelzflorian (Florian Pelz) <pelzflorian@pelzflorian.de> wrote:

Toggle quote (28 lines)
> On Tue, May 25, 2021 at 02:37:03PM +0000, Luis Felipe wrote:
>
> > On Tuesday, May 25, 2021 1:44 PM, pelzflorian (Florian Pelz) pelzflorian@pelzflorian.de wrote:
> >
> > > On Mon, May 24, 2021 at 11:35:24PM +0000, Luis Felipe via Guix-patches via wrote:
> > >
> > > > - (theme
> > > > - #:title (C_ "webpage title" '("Publications"))
> > > > - #:description
> > > > - (G_ "A list of written publications about GNU Guix.")
> > > > - #:keywords
> > > > - ;; TRANSLATORS: |-separated list of webpage keywords.
> > > > - (string-split (G_ "Publications|Papers") #\|)
> > >
> > > I don’t know, but should there really be only none of the other pages’
> > > SEO keywords? All other occurrences of #:keywords begin with
> > > GNU|Linux|Unix|Free software
> >
> > Hmm, I don't know... Last time I checked, I think I saw that search
> > engines care more about the page content than meta keywords. So I
> > don't think it would make a difference.
> > Also, if it turns out to be important to repeat these keywords in
> > all pages, maybe it would be better to add these by default in (apps
> > base templates theme).
>
> I did not know and just thought we should cargo-cult it. Does it
> matter? Maybe @sirgazil has an opinion?

He, he, I'm sirgazil :)
L
L
Luis Felipe wrote on 25 May 2021 21:46
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)(name . 48637@debbugs.gnu.org)(address . 48637@debbugs.gnu.org)
0aOCO-8AZ9biZ9iIxwrbB509xigLvoEfiOHOXiC_hfm1YqdAKMuCftahFz-8Ix2Ikdlt8akHkyoRsH6OvV0gOzlFrcw3xdyeE2IPF5TchB0=@protonmail.com
On Tuesday, May 25, 2021 6:21 PM, pelzflorian (Florian Pelz) <pelzflorian@pelzflorian.de> wrote:

Toggle quote (41 lines)
> On Tue, May 25, 2021 at 02:37:03PM +0000, Luis Felipe wrote:
>
> > Yeah. Would it as follows? (I still struggle with i18n):
> > (p
> > (@ (class "publication-info"))
> > ,(G_ `("Published "
> > ,(date->string (publication-date publication)
> > (C_ "SRFI-19 date->string format" "~b ~d, ~Y"))
> > " by "
> > ,(string-join (publication-authors publication) ", "))))
>
> It would need to be
>
> (p
> (@ (class "publication-info"))
> ,(let ((format (C_ "SRFI-19 date->string format" "~b ~d, ~Y")))
>
> (G_ `("Published "
> ,(date->string (publication-date publication) format)
>
> " by "
> ,(string-join (publication-authors publication) ", ")
> ""))))
>
>
> The let is needed because C_ cannot be nested inside G_ because the
> sexp-xgettext script parses Scheme files in only one pass currently.
> (And I’m not motivated enough to make it go back to parse the nested
> C_ because nesting is seldom needed.)
>
> The "" at the end is needed so (string-join …) gets its own XML
> element that can be moved by translators.
>
> Without "":
>
> msgid "Published <1/> by "
>
> With "":
>
> msgid "Published <1/> by <2/>"

You told me that before but I forgot :P


Toggle quote (18 lines)
> > Also, I think the delimiter for "string-join" in the list of authors
> > should be translated because that comma is not used in Japanese, for
> > example. So would it be ok like this:
> > […]
> > ,(string-join (publication-authors publication)
> > (C_ "Separator of items in a list" ", ")))))
>
> Yes, you are very right, although as above please move it to the let.
> Then it can become ? or ? or whatever; I don’t know what is common
> in Japan.
>
> > I'm still unsure about when I should use a context and when a
> > TRANSLATORS comment...
>
> A msgctxt should be used if another ", " string with different
> translations might be added. I would use a context, I think, but
> maybe it is an abundance of caution.

Ok, so I moved both the date and the list authors to the definitions part of a let:

(define (publication->shtml publication)
"Return an SHTML representation of the given publication object.

PUBLICATION (<publication>)
A publication object as defined in (apps media types)."
(let ((date
(date->string (publication-date publication)
(C_ "SRFI-19 date->string format" "~b ~d, ~Y")))
(authors
(string-join (publication-authors publication)
(C_ "Separator for authors in a list" ", "))))

`(a
(@ (class "publication-preview")
(href ,(publication-url publication)))

(h3
(@ (lang ,(publication-language publication))
(class "publication-title"))
,(publication-title publication))

(p
(@ (class "publication-info"))
,(G_ `("Published " ,date " by " ,authors ""))))))

Does it look right?
J
J
Julien Lepiller wrote on 25 May 2021 21:58
(name . 48637@debbugs.gnu.org)(address . 48637@debbugs.gnu.org)
02EED264-0509-453A-A016-2AD05353370B@lepiller.eu
Do we need to have a list for authors? Couldn't we have a single translatable string with all the authors, so it's easier to translate than having to translate a separator? I mean you could have weird rujes on separators. Even in English, you'd need an "and" for the last element, unless there's one author. Giving the full list of authors to translate gives the most freedom to translators.

Also, please give context/comment to the last one, because it's not easy to guess what <1> in "Published <1> by <2>" would be :)

Le 25 mai 2021 15:46:17 GMT-04:00, Luis Felipe via Guix-patches via <guix-patches@gnu.org> a écrit :
Toggle quote (96 lines)
>On Tuesday, May 25, 2021 6:21 PM, pelzflorian (Florian Pelz)
><pelzflorian@pelzflorian.de> wrote:
>
>> On Tue, May 25, 2021 at 02:37:03PM +0000, Luis Felipe wrote:
>>
>> > Yeah. Would it as follows? (I still struggle with i18n):
>> > (p
>> > (@ (class "publication-info"))
>> > ,(G_ `("Published "
>> > ,(date->string (publication-date publication)
>> > (C_ "SRFI-19 date->string format" "~b ~d, ~Y"))
>> > " by "
>> > ,(string-join (publication-authors publication) ", "))))
>>
>> It would need to be
>>
>> (p
>> (@ (class "publication-info"))
>> ,(let ((format (C_ "SRFI-19 date->string format" "~b ~d, ~Y")))
>>
>> (G_ `("Published "
>> ,(date->string (publication-date publication) format)
>>
>> " by "
>> ,(string-join (publication-authors publication) ", ")
>> ""))))
>>
>>
>> The let is needed because C_ cannot be nested inside G_ because the
>> sexp-xgettext script parses Scheme files in only one pass currently.
>> (And I’m not motivated enough to make it go back to parse the nested
>> C_ because nesting is seldom needed.)
>>
>> The "" at the end is needed so (string-join …) gets its own XML
>> element that can be moved by translators.
>>
>> Without "":
>>
>> msgid "Published <1/> by "
>>
>> With "":
>>
>> msgid "Published <1/> by <2/>"
>
>You told me that before but I forgot :P
>
>
>> > Also, I think the delimiter for "string-join" in the list of
>authors
>> > should be translated because that comma is not used in Japanese,
>for
>> > example. So would it be ok like this:
>> > […]
>> > ,(string-join (publication-authors publication)
>> > (C_ "Separator of items in a list" ", ")))))
>>
>> Yes, you are very right, although as above please move it to the let.
>> Then it can become ? or ? or whatever; I don’t know what is common
>> in Japan.
>>
>> > I'm still unsure about when I should use a context and when a
>> > TRANSLATORS comment...
>>
>> A msgctxt should be used if another ", " string with different
>> translations might be added. I would use a context, I think, but
>> maybe it is an abundance of caution.
>
>Ok, so I moved both the date and the list authors to the definitions
>part of a let:
>
>(define (publication->shtml publication)
> "Return an SHTML representation of the given publication object.
>
> PUBLICATION (<publication>)
> A publication object as defined in (apps media types)."
> (let ((date
> (date->string (publication-date publication)
> (C_ "SRFI-19 date->string format" "~b ~d, ~Y")))
> (authors
> (string-join (publication-authors publication)
> (C_ "Separator for authors in a list" ", "))))
>
> `(a
> (@ (class "publication-preview")
> (href ,(publication-url publication)))
>
> (h3
> (@ (lang ,(publication-language publication))
> (class "publication-title"))
> ,(publication-title publication))
>
> (p
> (@ (class "publication-info"))
> ,(G_ `("Published " ,date " by " ,authors ""))))))
>
>Does it look right?
Attachment: file
L
L
Luis Felipe wrote on 25 May 2021 22:16
(name . Julien Lepiller)(address . julien@lepiller.eu)
qLtMwHaPXECfOCj1zlI0g1huvNAzuigr3DJR2CC6Km2D4io5febFQIGj_ML57qkxEwl84I7CGgo-QjJg7Nw4zq7p8DeAue9c2xLD1N4ydxQ=@protonmail.com
On Tuesday, May 25, 2021 7:58 PM, Julien Lepiller <julien@lepiller.eu> wrote:

Toggle quote (2 lines)
> Do we need to have a list for authors? Couldn't we have a single translatable string with all the authors, so it's easier to translate than having to translate a separator? I mean you could have weird rujes on separators. Even in English, you'd need an "and" for the last element, unless there's one author. Giving the full list of authors to translate gives the most freedom to translators.

Hmm... As a scripter I'd prefer to use the list, but as a translator, I'd like to have complete control of the string... For the benefit of the latter, I think it's ok to use the string instead. So, when instancing a Publication record, the authors field would be simply like this?

#:authors (G_ "Jane Roe, Eva Lua and Luis Felipe")


Toggle quote (2 lines)
> Also, please give context/comment to the last one, because it's not easy to guess what <1> in "Published <1> by <2>" would be :)

That's what I thought, and I was about to ask if it was possible to have <date> and <authors> instead of <1> and <2>. I guess not...

I need a course on the i18n system :)
J
J
Julien Lepiller wrote on 26 May 2021 04:03
(name . Luis Felipe)(address . luis.felipe.la@protonmail.com)
68748170-9C48-45F1-98D7-6152572D6D61@lepiller.eu
Le 25 mai 2021 16:16:42 GMT-04:00, Luis Felipe <luis.felipe.la@protonmail.com> a écrit :
Toggle quote (18 lines)
>On Tuesday, May 25, 2021 7:58 PM, Julien Lepiller <julien@lepiller.eu>
>wrote:
>
>> Do we need to have a list for authors? Couldn't we have a single
>translatable string with all the authors, so it's easier to translate
>than having to translate a separator? I mean you could have weird rujes
>on separators. Even in English, you'd need an "and" for the last
>element, unless there's one author. Giving the full list of authors to
>translate gives the most freedom to translators.
>
>Hmm... As a scripter I'd prefer to use the list, but as a translator,
>I'd like to have complete control of the string... For the benefit of
>the latter, I think it's ok to use the string instead. So, when
>instancing a Publication record, the authors field would be simply like
>this?
>
>#:authors (G_ "Jane Roe, Eva Lua and Luis Felipe")

I think so, but I think we'll have to test, because I don't really know the i18n process either for the website ^^'

Toggle quote (9 lines)
>
>
>> Also, please give context/comment to the last one, because it's not
>easy to guess what <1> in "Published <1> by <2>" would be :)
>
>That's what I thought, and I was about to ask if it was possible to
>have <date> and <authors> instead of <1> and <2>. I guess not...
>
>I need a course on the i18n system :)
P
P
pelzflorian (Florian Pelz) wrote on 26 May 2021 12:00
(name . Julien Lepiller)(address . julien@lepiller.eu)
20210526095955.obtu772oolv4lkrb@pelzflorian.localdomain
On Tue, May 25, 2021 at 10:03:01PM -0400, Julien Lepiller wrote:
Toggle quote (5 lines)
> Le 25 mai 2021 16:16:42 GMT-04:00, Luis Felipe <luis.felipe.la@protonmail.com> a écrit :
> >#:authors (G_ "Jane Roe, Eva Lua and Luis Felipe")
>
> I think so, but I think we'll have to test, because I don't really know the i18n process either for the website ^^'

Yes, it is correct and the best way, but testing by running the
sexp-xgettext script is good too.


Toggle quote (5 lines)
> >That's what I thought, and I was about to ask if it was possible to
> >have <date> and <authors> instead of <1> and <2>. I guess not...
> >
> >I need a course on the i18n system :)

I wanted the sexp-xgettext i18n system so developers would not have to
add a tag name to every element … Well, we can use regexp helper
function find-empty-element like website/sexp-xgettext.scm uses at the
beginning of the deconstruct procedure:

(define (find-empty-element msgstr name)
"Return the regex match structure for the empty tag for XML
element of type NAME inside MSGSTR. If the element does not exist or
is more than the empty tag, #f is returned."
(string-match (string-append "<" (regexp-quote name) "/>") msgstr))

and call it on a translation with G_, but I would prefer not to
increase code complexity in the website.

Regards,
Florian
L
L
Luis Felipe wrote on 26 May 2021 16:06
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
rvOMdPKRHNINHsvhy8aneQ-XeN8CAbV_3HNdrYNCGNvsUZwp7pzSfusn3eH4q1H3CH45XVYjnSkSLkVdX1TZUlIUPRgVtx4oe7cco70mXE4=@protonmail.com
On Wednesday, May 26, 2021 10:00 AM, pelzflorian (Florian Pelz) <pelzflorian@pelzflorian.de> wrote:

Toggle quote (29 lines)
> On Tue, May 25, 2021 at 10:03:01PM -0400, Julien Lepiller wrote:
>
> > Le 25 mai 2021 16:16:42 GMT-04:00, Luis Felipe luis.felipe.la@protonmail.com a écrit :
> >
> > > #:authors (G_ "Jane Roe, Eva Lua and Luis Felipe")
> >
> > I think so, but I think we'll have to test, because I don't really know the i18n process either for the website ^^'
>
> Yes, it is correct and the best way, but testing by running the
> sexp-xgettext script is good too.
>
> > > That's what I thought, and I was about to ask if it was possible to
> > > have <date> and <authors> instead of <1> and <2>. I guess not...
> > > I need a course on the i18n system :)
>
> I wanted the sexp-xgettext i18n system so developers would not have to
> add a tag name to every element … Well, we can use regexp helper
> function find-empty-element like website/sexp-xgettext.scm uses at the
> beginning of the deconstruct procedure:
>
> (define (find-empty-element msgstr name)
> "Return the regex match structure for the empty tag for XML
> element of type NAME inside MSGSTR. If the element does not exist or
> is more than the empty tag, #f is returned."
> (string-match (string-append "<" (regexp-quote name) "/>") msgstr))
>
> and call it on a translation with G_, but I would prefer not to
> increase code complexity in the website.

Ok, here is the new patch with the suggested changes.

I updated the POT to check the translation strings and I think they are well formed. For example:

#. TRANSLATORS: <1/> is a date, and <2/> a list of authors.
#: apps/media/templates/components.scm:50
#, xml-text
msgid "Published <1/> by <2/>"
msgstr ""

I didn't include the POT update in the patch though. Maybe for future patches I'll do the whole i18n process.
Attachment: 0001-website-Add-publications-page.patch
J
J
Julien Lepiller wrote on 26 May 2021 19:41
(name . 48637@debbugs.gnu.org)(address . 48637@debbugs.gnu.org)
D1E65740-848D-4530-804F-655CD51BCE5F@lepiller.eu
Since last time we calked, I changed che script that updates weblate, so it now ignores the checked out pot file and regenerates it for weblate. Maybe we should now drop it entirely?

Le 26 mai 2021 10:06:43 GMT-04:00, Luis Felipe <luis.felipe.la@protonmail.com> a écrit :
Toggle quote (50 lines)
>On Wednesday, May 26, 2021 10:00 AM, pelzflorian (Florian Pelz)
><pelzflorian@pelzflorian.de> wrote:
>
>> On Tue, May 25, 2021 at 10:03:01PM -0400, Julien Lepiller wrote:
>>
>> > Le 25 mai 2021 16:16:42 GMT-04:00, Luis Felipe
>luis.felipe.la@protonmail.com a écrit :
>> >
>> > > #:authors (G_ "Jane Roe, Eva Lua and Luis Felipe")
>> >
>> > I think so, but I think we'll have to test, because I don't really
>know the i18n process either for the website ^^'
>>
>> Yes, it is correct and the best way, but testing by running the
>> sexp-xgettext script is good too.
>>
>> > > That's what I thought, and I was about to ask if it was possible
>to
>> > > have <date> and <authors> instead of <1> and <2>. I guess not...
>> > > I need a course on the i18n system :)
>>
>> I wanted the sexp-xgettext i18n system so developers would not have
>to
>> add a tag name to every element … Well, we can use regexp helper
>> function find-empty-element like website/sexp-xgettext.scm uses at
>the
>> beginning of the deconstruct procedure:
>>
>> (define (find-empty-element msgstr name)
>> "Return the regex match structure for the empty tag for XML
>> element of type NAME inside MSGSTR. If the element does not exist or
>> is more than the empty tag, #f is returned."
>> (string-match (string-append "<" (regexp-quote name) "/>") msgstr))
>>
>> and call it on a translation with G_, but I would prefer not to
>> increase code complexity in the website.
>
>Ok, here is the new patch with the suggested changes.
>
>I updated the POT to check the translation strings and I think they are
>well formed. For example:
>
>#. TRANSLATORS: <1/> is a date, and <2/> a list of authors.
>#: apps/media/templates/components.scm:50
>#, xml-text
>msgid "Published <1/> by <2/>"
>msgstr ""
>
>I didn't include the POT update in the patch though. Maybe for future
>patches I'll do the whole i18n process.
Attachment: file
L
L
Luis Felipe wrote on 26 May 2021 20:25
(name . Julien Lepiller)(address . julien@lepiller.eu)
HcGISC2zIGVxeg_Hafs_b_H3LEi9QfwPxJumsUq5EsE5e8oKy-JH0UB53r3U0JLVS-42bGq8D6xE0MdENpdQKTHT2w3yEnTlUhbMiHoCR0w=@protonmail.com
On Wednesday, May 26, 2021 5:41 PM, Julien Lepiller <julien@lepiller.eu> wrote:

Toggle quote (2 lines)
> Since last time we calked, I changed che script that updates weblate, so it now ignores the checked out pot file and regenerates it for weblate. Maybe we should now drop it entirely?

Ah, right. But it would be better to do that in a separate patch, right? To decide what can be removed. Because the sexp-xgettext script would still be useful to check that new translation strings are well formed.
Attachment: file
J
J
Julien Lepiller wrote on 26 May 2021 20:42
(name . Luis Felipe)(address . luis.felipe.la@protonmail.com)
96A1F1AB-15C9-46E9-B2F3-47C9C292224A@lepiller.eu
Absolutely, let's take care of that later, in a separate patch. I think your patch is in a very good shape now. Do you have commit access?

Le 26 mai 2021 14:25:48 GMT-04:00, Luis Felipe <luis.felipe.la@protonmail.com> a écrit :
Toggle quote (11 lines)
>On Wednesday, May 26, 2021 5:41 PM, Julien Lepiller
><julien@lepiller.eu> wrote:
>
>> Since last time we calked, I changed che script that updates weblate,
>so it now ignores the checked out pot file and regenerates it for
>weblate. Maybe we should now drop it entirely?
>
>Ah, right. But it would be better to do that in a separate patch,
>right? To decide what can be removed. Because the sexp-xgettext script
>would still be useful to check that new translation strings are well
>formed.
Attachment: file
L
L
Luis Felipe wrote on 26 May 2021 21:05
(name . Julien Lepiller)(address . julien@lepiller.eu)
1R2YMjqLmNPxG8f_Fi4aAAqtwwiE2-R_Bdya0WArw4wUjt-umtVBvbH_ot39pCWqr3_HwvMKrU6zAYH4n3D75FcI73WrGfw56BclR_a6y8w=@protonmail.com
On Wednesday, May 26, 2021 6:42 PM, Julien Lepiller <julien@lepiller.eu> wrote:

Toggle quote (2 lines)
> Absolutely, let's take care of that later, in a separate patch. I think your patch is in a very good shape now. Do you have commit access?

I don't :)
Attachment: file
L
L
Ludovic Courtès wrote on 28 May 2021 13:06
Re: bug#48637: [PATCH] website: Add publications page
(name . Luis Felipe)(address . luis.felipe.la@protonmail.com)(address . 48637@debbugs.gnu.org)
87bl8vi0d8.fsf@gnu.org
Hi Luis,

Nice work! It’s now on-line:


I see that you want to keep it open to non-academic publications, which
is a good idea. I wonder if there should be a visual distinction
between peer-reviewed scientific articles, journal articles, and other
types of publications?

I started adding historical LWN articles (patch below; the titles look
funny in hindsight :-)), and wondered whether this was a good idea since
they would come first in the list.

Thoughts?

We should call for contributions because I’m sure there are quite a few
articles that would be worth adding.

Thanks,
Ludo’.
Toggle diff (31 lines)
diff --git a/website/apps/media/data.scm b/website/apps/media/data.scm
index 8dbb035..fde5918 100644
--- a/website/apps/media/data.scm
+++ b/website/apps/media/data.scm
@@ -106,11 +106,26 @@ distribution."))
#:url "https://arxiv.org/abs/1305.4584"
#:authors "Ludovic Courtès"
#:date (string->date "2013-05-20" "~Y-~m-~d"))
+ (publication
+ #:title "GNU Guix sports functional package management"
+ #:authors "Nathan Willis"
+ #:url "https://lwn.net/Articles/560857/"
+ #:date (string->date "2013-07-31" "~Y-~m-~d"))
(publication
#:title "Reproducible and User-Controlled Software Environments in HPC with Guix"
#:url "https://hal.inria.fr/hal-01161771/en"
#:authors (G_ "Ludovic Courtès, Ricardo Wurmus")
#:date (string->date "2015-07-25" "~Y-~m-~d"))
+ (publication
+ #:title "Reproducible builds and standalone GNU systems with Guix 0.9"
+ #:url "https://lwn.net/Articles/663954/"
+ #:authors "Nathan Willis"
+ #:date (string->date "2015-11-18" "~Y-~m-~d"))
+ (publication
+ #:title "Security and reproducible-build progress in Guix 0.11"
+ #:url "https://lwn.net/Articles/696890/"
+ #:authors "Nathan Willis"
+ #:date (string->date "2016-08-10" "~Y-~m-~d"))
(publication
#:title "Code Staging in GNU Guix"
#:url "https://arxiv.org/abs/1709.00833"
L
L
Luis Felipe wrote on 28 May 2021 17:20
(name . Ludovic Courtès)(address . ludo@gnu.org)(name . 48637@debbugs.gnu.org)(address . 48637@debbugs.gnu.org)
RVdFQRr_D0g-yMkGUU3QWLJdQbXRDZvFwDg2p5R-D10BHHYx546xvmiK-hAOhAujsPN6ENu2TJNw6O94aKjabxB-QNE8v6esnRQY3wwVQok=@protonmail.com
Hi Ludovic,

On Friday, May 28, 2021 11:06 AM, Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (6 lines)
> Hi Luis,
>
> Nice work! It’s now on-line:
>
> https://guix.gnu.org/en/publications/

Thanks.


Toggle quote (3 lines)
> I see that you want to keep it open to non-academic publications, which
> is a good idea.

Yeah, I went with Julien's idea.


Toggle quote (4 lines)
> I wonder if there should be a visual distinction
> between peer-reviewed scientific articles, journal articles, and other
> types of publications?

Yeah, now that you mention it, I think that would be good.


Toggle quote (9 lines)
> I started adding historical LWN articles (patch below; the titles look
> funny in hindsight :-)), and wondered whether this was a good idea since
> they would come first in the list.
>
> Thoughts?
>
> We should call for contributions because I’m sure there are quite a few
> articles that would be worth adding.

Did you forget the patch? :)
L
L
Ludovic Courtès wrote on 29 May 2021 12:25
(name . Luis Felipe)(address . luis.felipe.la@protonmail.com)(name . 48637@debbugs.gnu.org)(address . 48637@debbugs.gnu.org)
874kelet0s.fsf@gnu.org
Hi,

Luis Felipe <luis.felipe.la@protonmail.com> skribis:

Toggle quote (11 lines)
>> I started adding historical LWN articles (patch below; the titles look
>> funny in hindsight :-)), and wondered whether this was a good idea since
>> they would come first in the list.
>>
>> Thoughts?
>>
>> We should call for contributions because I’m sure there are quite a few
>> articles that would be worth adding.
>
> Did you forget the patch? :)

Oops, here we go!

Ludo’.
Toggle diff (31 lines)
diff --git a/website/apps/media/data.scm b/website/apps/media/data.scm
index 8dbb035..fde5918 100644
--- a/website/apps/media/data.scm
+++ b/website/apps/media/data.scm
@@ -106,11 +106,26 @@ distribution."))
#:url "https://arxiv.org/abs/1305.4584"
#:authors "Ludovic Courtès"
#:date (string->date "2013-05-20" "~Y-~m-~d"))
+ (publication
+ #:title "GNU Guix sports functional package management"
+ #:authors "Nathan Willis"
+ #:url "https://lwn.net/Articles/560857/"
+ #:date (string->date "2013-07-31" "~Y-~m-~d"))
(publication
#:title "Reproducible and User-Controlled Software Environments in HPC with Guix"
#:url "https://hal.inria.fr/hal-01161771/en"
#:authors (G_ "Ludovic Courtès, Ricardo Wurmus")
#:date (string->date "2015-07-25" "~Y-~m-~d"))
+ (publication
+ #:title "Reproducible builds and standalone GNU systems with Guix 0.9"
+ #:url "https://lwn.net/Articles/663954/"
+ #:authors "Nathan Willis"
+ #:date (string->date "2015-11-18" "~Y-~m-~d"))
+ (publication
+ #:title "Security and reproducible-build progress in Guix 0.11"
+ #:url "https://lwn.net/Articles/696890/"
+ #:authors "Nathan Willis"
+ #:date (string->date "2016-08-10" "~Y-~m-~d"))
(publication
#:title "Code Staging in GNU Guix"
#:url "https://arxiv.org/abs/1709.00833"
L
L
Luis Felipe wrote on 2 Jun 2021 21:31
(name . Ludovic Courtès)(address . ludo@gnu.org)(name . 48637@debbugs.gnu.org)(address . 48637@debbugs.gnu.org)
4jhiBWvAzsdTXmZFj_GgZTPWkIZncoQeId2pbbzXXMRNFk0FPGJXxIrp8ysGXNwuZk54pS5l5Ba2jkRcqE8omsfVgItw1gMcDJW1tqMPn-M=@protonmail.com
Hey,

On Friday, May 28, 2021 11:06 AM, Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (12 lines)
> I see that you want to keep it open to non-academic publications, which
> is a good idea. I wonder if there should be a visual distinction
> between peer-reviewed scientific articles, journal articles, and other
> types of publications?
>
> I started adding historical LWN articles (patch below; the titles look
> funny in hindsight :-)), and wondered whether this was a good idea since
> they would come first in the list.
>
> Thoughts?


Here is a patch that adds publication types.
Attachment: 0001-website-publications-Add-publication-type.patch
J
J
Julien Lepiller wrote on 2 Jun 2021 22:28
Re: [bug#48637] [PATCH] website: Add publications page
(name . 48637@debbugs.gnu.org)(address . 48637@debbugs.gnu.org)
731A5D86-9FBB-4F0F-B139-7AA29B3A6109@lepiller.eu
The patch looks good, but how would people out of science understand what's a conference paper, or the difference between an article and a journal article? Are there better terms?

Le 2 juin 2021 15:31:50 GMT-04:00, Luis Felipe via Guix-patches via <guix-patches@gnu.org> a écrit :
Toggle quote (21 lines)
>Hey,
>
>On Friday, May 28, 2021 11:06 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>
>> I see that you want to keep it open to non-academic publications,
>which
>> is a good idea. I wonder if there should be a visual distinction
>> between peer-reviewed scientific articles, journal articles, and
>other
>> types of publications?
>>
>> I started adding historical LWN articles (patch below; the titles
>look
>> funny in hindsight :-)), and wondered whether this was a good idea
>since
>> they would come first in the list.
>>
>> Thoughts?
>
>
>Here is a patch that adds publication types.
Attachment: file
L
L
Luis Felipe wrote on 2 Jun 2021 23:52
(name . Julien Lepiller)(address . julien@lepiller.eu)
Xw5LRNAHDUHf81RGfLjFzilQ1YrrTs63NLLT3S4JWIoTSfe4VlfREBO_OarMDQkWxOzGxpLano779cTttO8d0Fvhi5p0zZaTdhuD8c1wtkY=@protonmail.com
On Wednesday, June 2, 2021 8:28 PM, Julien Lepiller <julien@lepiller.eu> wrote:

Toggle quote (2 lines)
> The patch looks good, but how would people out of science understand what's a conference paper, or the difference between an article and a journal article? Are there better terms?

I don't know. As an outsider those terms sound alright to me :) And maybe when people click on the links the difference becomes clearer. But yeah, I don't know :)
Attachment: file
J
J
Julien Lepiller wrote on 3 Jun 2021 01:28
(name . Luis Felipe)(address . luis.felipe.la@protonmail.com)
2886E70A-6977-461B-BCF9-89B882DBED34@lepiller.eu
Ah, it's fine, I don't mean to delay applying the patch if the terms are good enough :)

Le 2 juin 2021 17:52:13 GMT-04:00, Luis Felipe <luis.felipe.la@protonmail.com> a écrit :
Toggle quote (10 lines)
>On Wednesday, June 2, 2021 8:28 PM, Julien Lepiller
><julien@lepiller.eu> wrote:
>
>> The patch looks good, but how would people out of science understand
>what's a conference paper, or the difference between an article and a
>journal article? Are there better terms?
>
>I don't know. As an outsider those terms sound alright to me :) And
>maybe when people click on the links the difference becomes clearer.
>But yeah, I don't know :)
Attachment: file
L
L
Ludovic Courtès wrote on 3 Jun 2021 11:40
Re: bug#48637: [PATCH] website: Add publications page
(name . Luis Felipe)(address . luis.felipe.la@protonmail.com)(name . 48637@debbugs.gnu.org)(address . 48637@debbugs.gnu.org)
87fsxzwaji.fsf@gnu.org
Hello!

Luis Felipe <luis.felipe.la@protonmail.com> skribis:

Toggle quote (7 lines)
> On Friday, May 28, 2021 11:06 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>
>> I see that you want to keep it open to non-academic publications, which
>> is a good idea. I wonder if there should be a visual distinction
>> between peer-reviewed scientific articles, journal articles, and other
>> types of publications?

[...]

Toggle quote (10 lines)
> From ef4e97ec9a49e65d70c9ba8d4c1926b2eeec2cba Mon Sep 17 00:00:00 2001
> From: Luis Felipe <luis.felipe.la@protonmail.com>
> Date: Wed, 2 Jun 2021 14:17:03 -0500
> Subject: [PATCH] website: publications: Add publication type.
>
> * website/apps/media/types.scm (<publication>): Add "type" field.
> * website/apps/media/data.scm (publications): Specify publication types.
> * website/apps/media/templates/components.scm (publication->shtml): Show
> publication type.

Pushed, thanks!

Julien Lepiller <julien@lepiller.eu> skribis:

Toggle quote (2 lines)
> The patch looks good, but how would people out of science understand what's a conference paper, or the difference between an article and a journal article? Are there better terms?

I was wondering whether we should just distinguish between “scientific
papers” (peer-reviewed, be it conference papers, journals, or book
chapters) and other publications.

Perhaps a visual cue for scientific publications, such as an English
graduate cap, would be enough?

Ludo’.
J
J
Julien Lepiller wrote on 3 Jun 2021 12:37
Re: [bug#48637] [PATCH] website: Add publications page
(name . 48637@debbugs.gnu.org)(address . 48637@debbugs.gnu.org)
853F24B0-F5DE-461C-8163-71FCD8581FD7@lepiller.eu
Yeah, good idea, though we need to make it accessible (alt="scientific" or something).

Le 3 juin 2021 05:40:49 GMT-04:00, "Ludovic Courtès" <ludo@gnu.org> a écrit :
Toggle quote (45 lines)
>Hello!
>
>Luis Felipe <luis.felipe.la@protonmail.com> skribis:
>
>> On Friday, May 28, 2021 11:06 AM, Ludovic Courtès <ludo@gnu.org>
>wrote:
>>
>>> I see that you want to keep it open to non-academic publications,
>which
>>> is a good idea. I wonder if there should be a visual distinction
>>> between peer-reviewed scientific articles, journal articles, and
>other
>>> types of publications?
>
>[...]
>
>> From ef4e97ec9a49e65d70c9ba8d4c1926b2eeec2cba Mon Sep 17 00:00:00
>2001
>> From: Luis Felipe <luis.felipe.la@protonmail.com>
>> Date: Wed, 2 Jun 2021 14:17:03 -0500
>> Subject: [PATCH] website: publications: Add publication type.
>>
>> * website/apps/media/types.scm (<publication>): Add "type" field.
>> * website/apps/media/data.scm (publications): Specify publication
>types.
>> * website/apps/media/templates/components.scm (publication->shtml):
>Show
>> publication type.
>
>Pushed, thanks!
>
>Julien Lepiller <julien@lepiller.eu> skribis:
>
>> The patch looks good, but how would people out of science understand
>what's a conference paper, or the difference between an article and a
>journal article? Are there better terms?
>
>I was wondering whether we should just distinguish between “scientific
>papers” (peer-reviewed, be it conference papers, journals, or book
>chapters) and other publications.
>
>Perhaps a visual cue for scientific publications, such as an English
>graduate cap, would be enough?
>
>Ludo’.
Attachment: file
L
L
Luis Felipe wrote on 3 Jun 2021 15:39
(name . Julien Lepiller)(address . julien@lepiller.eu)
tcpFPZykUUzH6TZmkMLimPbErOfXnQ8LnBRCBDHvnM-Wiv8G6rLki80tC0H50BvaSSCoqhD9l0YwirxgyFaX7tBo6xDEfqZn0QCkemOkd0E=@protonmail.com
On Thursday, June 3, 2021 10:37 AM, Julien Lepiller <julien@lepiller.eu> wrote:

Toggle quote (2 lines)
> Yeah, good idea, though we need to make it accessible (alt="scientific" or something).

So, a publication is either scientific or not, right? So just add "publication-scientific?", right?
Attachment: file
L
L
Luis Felipe wrote on 3 Jun 2021 21:50
(name . Julien Lepiller)(address . julien@lepiller.eu)
XxPCIGHqE4M3nFDpiuYNKY_7dy7pWeeZWdT1FXnlJbWQkgNt0HxbPAWJuAKU3aGmHkOGYl2ec7QEjDaO0tSDP3P5I6r6ZAPMNzG3Et8Nz1c=@protonmail.com
On Thursday, June 3, 2021 1:39 PM, Luis Felipe <luis.felipe.la@protonmail.com> wrote:

Toggle quote (6 lines)
> On Thursday, June 3, 2021 10:37 AM, Julien Lepiller <julien@lepiller.eu> wrote:
>
>> Yeah, good idea, though we need to make it accessible (alt="scientific" or something).
>
> So, a publication is either scientific or not, right? So just add "publication-scientific?", right?

I went ahead and added that "publication-scientific?" field and the suggested cap to scientific publications (patch attached). Let me know what you think.
Attachment: file
Attachment: 0001-website-publications-Add-scientific-publication-mark.patch
L
L
Ludovic Courtès wrote on 3 Jun 2021 22:37
(name . Luis Felipe)(address . luis.felipe.la@protonmail.com)
87czt2u1lb.fsf@gnu.org
Luis Felipe <luis.felipe.la@protonmail.com> skribis:

Toggle quote (6 lines)
> On Thursday, June 3, 2021 10:37 AM, Julien Lepiller <julien@lepiller.eu> wrote:
>
>> Yeah, good idea, though we need to make it accessible (alt="scientific" or something).
>
> So, a publication is either scientific or not, right? So just add "publication-scientific?", right?

We can keep the categories you added, but I suppose only scientists care
about the difference between “conference article” and “journal article”.
:-) For the rest of us, “academic” vs. “non-academic” is probably what
matters, and this is where a visual cue could help.

WDYT?

Ludo’.
L
L
Luis Felipe wrote on 3 Jun 2021 23:50
(name . Ludovic Courtès)(address . ludo@gnu.org)
m0kcO6cODXUBz6QdjzneAxhbGnwKu9igNsQMa3W9jtFZAvEA-aFafIDsC_M7Doi-HKLwOAYOlGIdN6mPS6ifFn67EDbYJsznUCJfxecLYdQ=@protonmail.com
On Thursday, June 3, 2021 8:37 PM, Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (15 lines)
> Luis Felipe luis.felipe.la@protonmail.com skribis:
>
> > On Thursday, June 3, 2021 10:37 AM, Julien Lepiller julien@lepiller.eu wrote:
> >
> > > Yeah, good idea, though we need to make it accessible (alt="scientific" or something).
> >
> > So, a publication is either scientific or not, right? So just add "publication-scientific?", right?
>
> We can keep the categories you added, but I suppose only scientists care
> about the difference between “conference article” and “journal article”.
> :-) For the rest of us, “academic” vs. “non-academic” is probably what
> matters, and this is where a visual cue could help.
>
> WDYT?

So, you mean something like the following would suffice?


Personally, I'm fine with or without any of these distinctions because once you click on an article you can see how formal the article is. But I can provide a patch to make things look like in the image.
L
L
Ludovic Courtès wrote on 4 Jun 2021 17:38
(name . Luis Felipe)(address . luis.felipe.la@protonmail.com)
87eedhprmd.fsf@gnu.org
Hi,

Luis Felipe <luis.felipe.la@protonmail.com> skribis:

Toggle quote (4 lines)
> So, you mean something like the following would suffice?
>
> https://luis-felipe.gitlab.io/media/2021/06/guix-academic-publications-2021-06-03%2016-39-11.png

Yes.

Toggle quote (2 lines)
> I went ahead and added that "publication-scientific?" field and the suggested cap to scientific publications (patch attached). Let me know what you think.

Awesome, pushed!

Thanks for the quick reply and pleasant result!

Ludo’.
L
L
Ludovic Courtès wrote on 5 Jun 2021 22:34
control message for bug #48637
(address . control@debbugs.gnu.org)
87o8ckm4ot.fsf@gnu.org
close 48637
quit
?
Your comment

This issue is archived.

To comment on this conversation send an email to 48637@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 48637
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch