bug#26302: [website] translations

[pelzflorian (Florian Pelz)]

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
Description: Text document

0002-website-Fix-typing-mistake.patch
Description: Text document

0003-website-Fix-typo.patch
Description: Text document

0004-website-Add-custom-xgettext-to-extract-from-nested-s.patch
Description: Text document

0005-website-Mark-all-files-in-apps-for-translation.patch
Description: Text document

0006-website-Add-German-translation.patch
Description: Text document