[website] translations

One thing I like about the template of https://taler.netis 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.

ng0 transcribed 0.4K bytes:

"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.

ng0 transcribed 0.7K bytes:

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:

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/

ng0 transcribed 1.4K bytes:

This

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/

Hi,

ng0 <contact.ng0@cryptolab.net> skribis:

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’.

Ludovic Courtès transcribed 1.1K bytes:

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.orghttps://krosos.org

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

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

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

From fa96d7ec0a71dfea4b5c2cae8bdfb2a8f27f678d Mon Sep 17 00:00:00 2001

---

website/posts/back-from-seagl-2018.sxml | 3 ++-

website/posts/guix-at-libreplanet-2016.sxml | 3 ++-

2 files changed, 4 insertions(+), 2 deletions(-)

From afd68ec639494320b5248b75315174d2dc1f7adb Mon Sep 17 00:00:00 2001

Add missing word.

---

website/apps/base/templates/contribute.scm | 2 +-

1 file changed, 1 insertion(+), 1 deletion(-)

From 3bd446c4242f278123a113bd65ef2bf302a29afd Mon Sep 17 00:00:00 2001

---

website/apps/base/templates/security.scm | 2 +-

1 file changed, 1 insertion(+), 1 deletion(-)

The 6th patch wrongly updated guix-website.pot. I will not resend.

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.

---

On Fri, Sep 06, 2019 at 01:17:10PM -0500, sirgazil via Bug reports for GNU Guix wrote:

:)

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 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 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.

I agree.

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

Hi Florian,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

Cool, thanks for opening this issue!

Spaces are good (easily pastable in the REPL), the whole Guix code base

is meant to use spaces only.

Good.

Yeah, let’s keep that for later.

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

Sounds good.

Yeah, we can always adjust later.

Thanks!

Ludo’.

On Sun, Sep 08, 2019 at 09:44:44PM +0200, Ludovic Courtès wrote:

Thank you! (Well, it was ng0’s old issue and people on the list

started talking about its topic again.)

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

---- On Sun, 08 Sep 2019 12:16:38 -0500 pelzflorian (Florian Pelz) <pelzflorian@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.

On Mon, Sep 09, 2019 at 07:49:33PM -0500, sirgazil wrote:

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

to Guix so it can be used on berlin.scm. It seems to offer all that

is required for redirecting existing URLs.

Regards,

Florian

From fa96d7ec0a71dfea4b5c2cae8bdfb2a8f27f678d Mon Sep 17 00:00:00 2001

---

website/posts/back-from-seagl-2018.sxml | 3 ++-

website/posts/guix-at-libreplanet-2016.sxml | 3 ++-

2 files changed, 4 insertions(+), 2 deletions(-)

From afd68ec639494320b5248b75315174d2dc1f7adb Mon Sep 17 00:00:00 2001

Add missing word.

---

website/apps/base/templates/contribute.scm | 2 +-

1 file changed, 1 insertion(+), 1 deletion(-)

From 3bd446c4242f278123a113bd65ef2bf302a29afd Mon Sep 17 00:00:00 2001

---

website/apps/base/templates/security.scm | 2 +-

1 file changed, 1 insertion(+), 1 deletion(-)

From 88e8c06927411a814809be8126491144653e86b3 Mon Sep 17 00:00:00 2001

(horizontal-skip): New procedure.

Increase size at which website switches to mobile mode.

---

website/apps/base/templates/components.scm | 30 +++++++++++++++++++---

website/static/base/css/navbar.css | 6 ++++-

2 files changed, 32 insertions(+), 4 deletions(-)

On Sun, Sep 15, 2019 at 10:18:20PM +0200, pelzflorian (Florian Pelz) wrote:

Help is welcome. If berlin.scm uses the above module, a package like

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

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@pelzflorian.de> skribis:

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

:-)

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?

I don’t understand this: are these the only plural numbers in all

languages, or…?

Thanks!

Ludo’.

On Wed, Sep 18, 2019 at 03:57:47PM +0200, Ludovic Courtès wrote:

Done. My username is pelzflorian.

As per the above docstring, I already have a definition

(define-syntax G_ sgettext)

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

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.

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

Hi Florian,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

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’.

Hi,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

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))

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.

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’.

The branch wip-i18n is pushed now.

On Thu, Sep 19, 2019 at 01:50:10PM +0200, Ludovic Courtès wrote:

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

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.

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.

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

I’ll leave this to you. :)

Regards,

Florian

On Sun, Sep 15, 2019 at 10:18:20PM +0200, pelzflorian (Florian Pelz) wrote:

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:

I see you @Ludo added such a service, but I cannot reach it. Perhaps

I am using the wrong URL.

Regards,

Florian

From 7747a416feae7139c2b2661ffeb37f2eb03eb2f9 Mon Sep 17 00:00:00 2001

nginx.

(nginx-configuration-load-modules): New field accessor.

(emit-load-module): New procedure.

(default-nginx-config): Add support for the load-modules field.

---

doc/guix.texi | 4 ++++

gnu/services/web.scm | 8 ++++++++

2 files changed, 12 insertions(+)

From ea5edd15586722b3557912e81171e69f7be339fa Mon Sep 17 00:00:00 2001

Accept-Language header.

(%nginx-configuration): Load required nginx dynamic module.

---

hydra/nginx/berlin.scm | 19 ++++++++++++++++++-

1 file changed, 18 insertions(+), 1 deletion(-)

On Mon, Oct 07, 2019 at 10:15:03AM +0200, pelzflorian (Florian Pelz) wrote:

I changed the patch and while nginx loads, redirects for files without

html suffix still fail. I will stop and wait for smarter people with

more nginx experience. Attached is the current patch and changes I

make to berlin for testing in a local VM using

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

Regards,

Florian

From ef1d268cd75219c18ef098389a8ea5ef460ee542 Mon Sep 17 00:00:00 2001

Accept-Language header.

(%nginx-configuration): Load required nginx dynamic module.

---

hydra/nginx/berlin.scm | 19 ++++++++++++++++++-

1 file changed, 18 insertions(+), 1 deletion(-)

Hello Florian and all!

(Cc: sirgazil + Julien.)

Ludovic Courtès <ludo@gnu.org> skribis:

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’.

On Tue, Oct 22, 2019 at 02:10:59PM +0200, Ludovic Courtès wrote:

Thank you. :)

I will rebase wip-i18n later this week and when the documentation

videos are decided.

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

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

After that I also sent maintenance patches, but redirection only works

for URLs ending in .html right now…

Regards,

Florian

On Tue, Oct 22, 2019 at 02:28:40PM +0200, pelzflorian (Florian Pelz) wrote:

I suppose your fix at

would address it had I rebased.

Regards,

Florian

On Tue, Oct 22, 2019 at 02:28:40PM +0200, pelzflorian (Florian Pelz) wrote:

Also it appears I broke URLs to the manual.

Hi,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

I rebased some time ago and I think this fix is included (I added it

specifically for this purpose).

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’.

On Wed, Oct 23, 2019 at 04:16:30PM +0200, Ludovic Courtès wrote:

Only the hyperlinks to the manual in .i18n. Sorry for being

imprecise. Nothing outside is broken.

Will do tomorrow. Then I will check why the stylesheet URLs are

wrong. Thank you for this setup.

Regards,

Florian

On Tue, Oct 22, 2019 at 02:10:59PM +0200, Ludovic Courtès wrote:

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:

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

Hi Florian

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

[...]

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

is yours.

Is there no upstream version? If that’s the case, that’s fine, but

please add a comment explaining it.

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

upstream repo?

I’d suggest doing it in a phase.

To avoid circular dependencies in top-level references, I suggest

copying the license of ‘nginx’ instead of writing (package-license

nginx).

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.

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

web site.

Thanks!

Ludo’.

Hi,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

Neat!

Reviewed! Regarding the build system of nginx modules, we’ll see when

we have more than one module packaged. :-)

Thanks,

Ludo’.

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:

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.

I believe this is no longer an issue now that

nginx-accept-language-module is in the same Guile module as nginx, is

it?

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.

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:

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

difficult now.

Regards,

Florian

From b6da504736866bae655e2b4025729345e1ea19b7 Mon Sep 17 00:00:00 2001

linking statically.

---

doc/guix.texi | 6 ++++++

1 file changed, 6 insertions(+)

From 250ae2011ac1c976508136e9f50cb04e6ab5f23c Mon Sep 17 00:00:00 2001

nginx.

(nginx-configuration-modules): New field accessor.

(emit-load-module): New procedure.

(default-nginx-config): Add support for the modules field.

---

doc/guix.texi | 4 ++++

gnu/services/web.scm | 8 ++++++++

2 files changed, 12 insertions(+)

Hi,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

Good!

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

Agreed.

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

Naming").

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?

LGTM!

Thanks for taking the time to rewrite the snippet as a build phase.

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’.

On Mon, Nov 04, 2019 at 06:19:32PM +0100, Ludovic Courtès wrote:

Makes sense. I agree the general rule is appropriate here.

I guess the meaning of `guix build -S` is not clear enough. Let me

make an alternative proposal (attached).

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

From 3bbdd2dc4c983ca8bbf31cd348b64f1d60a51ee5 Mon Sep 17 00:00:00 2001

build option.

---

doc/guix.texi | 7 +++++++

1 file changed, 7 insertions(+)

From 04df1e5ee3fd542776b13eb3a59872e1647eb5f8 Mon Sep 17 00:00:00 2001

in nginx.

(nginx-configuration-modules): New field accessor.

(emit-load-module): New procedure.

(default-nginx-config): Add support for the modules field.

---

doc/guix.texi | 11 +++++++++++

gnu/services/web.scm | 8 ++++++++

2 files changed, 19 insertions(+)

On Tue, Nov 05, 2019 at 08:31:30AM +0100, pelzflorian (Florian Pelz) wrote:

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

Regards,

Florian

From a5d9180d960d244053bea0d59d6092060fe4c6dd Mon Sep 17 00:00:00 2001

build option.

---

doc/guix.texi | 7 +++++++

1 file changed, 7 insertions(+)

Hi!

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

[…]

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’.

Hi,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

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’.

On Wed, Nov 06, 2019 at 03:49:46PM +0100, Ludovic Courtès wrote:

I agree. Thank you! I copied your wording verbatim and will push

the nginx patches tomorrow.

Regards,

Florian

On Wed, Nov 06, 2019 at 03:56:48PM +0100, Ludovic Courtès wrote:

Well said. You convinced me not to make a recommendation. Thank you.

I still was surprised about `guix build -S` so I attach a new

proposal.

Regards,

Florian

From c9f7b2739392e0d8cf2afa6b2179b2e138c49bc7 Mon Sep 17 00:00:00 2001

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

reproducing the packages.

---

doc/guix.texi | 5 +++++

1 file changed, 5 insertions(+)

Hello Florian,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

Alrighty, LGTM!

Thank you,

Ludo’.

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:

Hi, Florian :)

---- On Fri, 08 Nov 2019 04:02:16 -0500 pelzflorian (Florian Pelz) <pelzflorian@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.

On Fri, Nov 08, 2019 at 09:01:17AM -0500, sirgazil wrote:

I changed it now, also for the dropdowns. The change is online now

that the website was rebuilt.

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

On Fri, Nov 08, 2019 at 05:18:29PM +0100, pelzflorian (Florian Pelz) wrote:

Oops, dropdowns are not quite right yet.

On Fri, Nov 08, 2019 at 05:18:28PM +0100, pelzflorian (Florian Pelz) wrote:

Dropdowns are fixed for real now.

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

---- On Fri, 08 Nov 2019 12:13:56 -0500 pelzflorian (Florian Pelz) <pelzflorian@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 :)

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.

On Sun, Nov 17, 2019 at 05:17:02PM +0100, pelzflorian (Florian Pelz) wrote:

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

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@pelzflorian.de> skribis:

On Wed, Mar 25, 2020 at 06:33:46PM +0100, Ludovic Courtès wrote:

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

On Thu, Mar 26, 2020 at 12:21:00AM +0100, pelzflorian (Florian Pelz) wrote:

Done.

Hi Florian,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

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’.

On Tue, Apr 07, 2020 at 11:18:56PM +0200, Ludovic Courtès wrote:

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 will test, but I cannot test if certbot and tls work. But of course

the translated website can wait.

Regards,

Florian

On Wed, Apr 08, 2020 at 12:02:25AM +0200, pelzflorian (Florian Pelz) wrote:

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

On Thu, Apr 09, 2020 at 05:21:46AM +0200, pelzflorian (Florian Pelz) wrote:

It seems redirects broke like

on my test VM. :/

On Thu, Apr 09, 2020 at 09:45:50AM +0200, pelzflorian (Florian Pelz) wrote:

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

Hi Florian,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

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’.

On Thu, Apr 09, 2020 at 05:27:05PM +0200, Ludovic Courtès wrote:

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

Hi Florian,

On +2020-04-09 19:31:02 +0200, pelzflorian (Florian Pelz) wrote:

Wondering, could dnsmasq help?

--

Regards,

Bengt Richter

On Thu, Apr 09, 2020 at 08:58:14PM +0200, Bengt Richter wrote:

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 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

From 8b8f7a404b29ab3341b7dd19dcd1c5415723c1a0 Mon Sep 17 00:00:00 2001

---

hydra/modules/sysadmin/services.scm | 3 +--

1 file changed, 1 insertion(+), 2 deletions(-)

pelzflorian (Florian Pelz) <pelzflorian@pelzflorian.de> writes:

...

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

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:

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:

worked before wip-i18n but stopped working. Hrm.

These seem to fail but I could not properly build the manual yet:

The rest looks good:

works.

never worked, so it’s OK that these URLs don’t work.

This redirect now works but did not work before wip-i18n (??).

I will continue to investigate.

Regards,

Florian

Hi Florian,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

One thing that bit me in the past is that regex locations have higher

precedence that other locations, IIRC.

I guess you could check with “wget -v -O /dev/null” or similar, so you

can be sure there’s no client cache interfering.

What does nginx’s error.log file say?

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.

Sounds good.

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’.

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

to the index file

For this reason I had added

rewrite (.*)/$ $1/index.html;

Then it matched. But:

Previously when visiting

then nginx too looked up the index file

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:

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.

This is a good idea. In the past I had thought things work when in

reality all was broken and it was just cached.

You are right, trying to build the manual was pointless.

I can only check later, I have deleted my VM because texinfo for

building the manual consumed too much disk space.

The URL should have been

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

!! I think this happened too back then. I have not investigated this yet.

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

pelzflorian (Florian Pelz) <pelzflorian@pelzflorian.de> writes:

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

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:

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.

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

On Thu, Jul 09, 2020 at 05:56:43PM +0100, Christopher Baines wrote:

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

On Thu, Jul 09, 2020 at 03:09:57PM +0200, Ludovic Courtès wrote:

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:

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

Hey!

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

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’.

On Mon, Jul 13, 2020 at 03:22:36PM +0200, Ludovic Courtès wrote:

I think we are.

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

On Mon, Jul 13, 2020 at 04:48:00PM +0200, pelzflorian (Florian Pelz) wrote:

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

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’.

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

On Sun, Jul 26, 2020 at 07:46:55PM +0200, Ludovic Courtès wrote:

Thank you! I am so happy. Although …

Ohh sorry, the manual disappeared. I suppose it is built in /srv/…/manual/?

:(

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.

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

Ludovic Courtès <ludo@gnu.org> wrote:

The obvious:

| <!DOCTYPE html><html lang="lang-tag">

^~~~~~~~

;-)

On Sun, Jul 26, 2020 at 10:52:10AM -0700, Vagrant Cascadian wrote:

:)

Perhaps there should be a stylized image of characters from various

languages. I cannot draw well though. sirgazil, WDYT?

Regards,

Florian