Discussion:
Translating to Chinese, Spanish and Japanese (and more)
Pjotr Prins
2018-02-05 09:07:16 UTC
Permalink
We would like have the website translated to Chinese and some other
languages that represent a large group of non-native English speakers,
such as Spanish, Bengali and Japanese. For this we need to add support
for i8n to haunt, which is a technical issue, but we also would like
to invite native speakers to come forward and perhaps introduce some
helpers who are interested in spreading free software in places that
need it!

It is not meant to be a lot of work, one day per language would probably
do. But it needs to be someone who understands free software to get
the lingo right. How do you translate 'rolling software deployment'.
You don't want it to be 'fuming dragon on carpet', though that may
actually be the better representation ;)

We can start simply translating the front page and perhaps one or two
blogs. I think that once we bootstrap there will be more people
pitching in. But you need to get the attention first.

Just a small sacrifice of your time with tremendous potential impact!
julien lepiller
2018-02-05 09:28:20 UTC
Permalink
Post by Pjotr Prins
We would like have the website translated to Chinese and some other
languages that represent a large group of non-native English speakers,
such as Spanish, Bengali and Japanese. For this we need to add support
for i8n to haunt, which is a technical issue, but we also would like
to invite native speakers to come forward and perhaps introduce some
helpers who are interested in spreading free software in places that
need it!
It is not meant to be a lot of work, one day per language would probably
do. But it needs to be someone who understands free software to get
the lingo right. How do you translate 'rolling software deployment'.
You don't want it to be 'fuming dragon on carpet', though that may
actually be the better representation ;)
We can start simply translating the front page and perhaps one or two
blogs. I think that once we bootstrap there will be more people
pitching in. But you need to get the attention first.
Just a small sacrifice of your time with tremendous potential impact!
Hi,

as I said during FOSDEM, I'm willing to translate the website, blog
posts, and manual into French. My only concern is that the translations
may fall out of sync without anyone noticing. With gettext, it's easy
to know when strings are not translated, but what about the solution
that would be used by haunt?
pelzflorian (Florian Pelz)
2018-02-05 09:41:29 UTC
Permalink
Post by julien lepiller
Post by Pjotr Prins
We would like have the website translated to Chinese and some other
languages that represent a large group of non-native English speakers,
such as Spanish, Bengali and Japanese. For this we need to add support
for i8n to haunt, which is a technical issue, but we also would like
to invite native speakers to come forward and perhaps introduce some
helpers who are interested in spreading free software in places that
need it!
It is not meant to be a lot of work, one day per language would probably
do. But it needs to be someone who understands free software to get
the lingo right. How do you translate 'rolling software deployment'.
You don't want it to be 'fuming dragon on carpet', though that may
actually be the better representation ;)
We can start simply translating the front page and perhaps one or two
blogs. I think that once we bootstrap there will be more people
pitching in. But you need to get the attention first.
Just a small sacrifice of your time with tremendous potential impact!
Hi,
as I said during FOSDEM, I'm willing to translate the website, blog
posts, and manual into French. My only concern is that the translations
may fall out of sync without anyone noticing. With gettext, it's easy
to know when strings are not translated, but what about the solution
that would be used by haunt?
How do you plan to do the translation with Haunt?

I thought about making page translations possible by allowing page
bodies to be lambdas taking a page variant as an argument, e.g. a
string containing an ietf language code, and returning the body
S-expression.

Then the page variants could be specified per site and each page would
be generated once per variant.

A site’s post-template and collection-template could then also
optionally be lambdas returning SHTML instead of SHTML.

It should also be possible to specify a procedure to transform a base
page name and a language variant to a new page name.

I still did not have time to send a patch though

pelzflorian (Florian Pelz)
2018-02-05 14:47:50 UTC
Permalink
Simple XML might be a better candidate for a DSL. Translators would get
a string like “<link>Installation instructions</link>.” and give us back
a translated string such as “<link>安装诎明</link>。” On the haunt side
we would have a procedure that parses the XML to SXML and we could
Ah, that is what you mean by XML. I used "link|Installation
instructions" for that, but yes, maybe XML is easier to understand /
more familiar for translators.

I believe this Gettext support should be separate from Haunt so it can
be reused e.g. for Web servers written in Guile.
Ricardo Wurmus
2018-02-05 17:21:18 UTC
Permalink
Post by pelzflorian (Florian Pelz)
Simple XML might be a better candidate for a DSL. Translators would get
a string like “<link>Installation instructions</link>.” and give us back
a translated string such as “<link>安装说明</link>。” On the haunt side
we would have a procedure that parses the XML to SXML and we could
Ah, that is what you mean by XML. I used "link|Installation
instructions" for that, but yes, maybe XML is easier to understand /
more familiar for translators.
What’s good about using XML is that we already have parser and tooling
support for it. It can even be nested (though you shouldn’t go
overboard with it), which may sometimes be necessary, and we can easily
and programmatically access individual parts of the XML tree with sxpath
and the like.
Post by pelzflorian (Florian Pelz)
I believe this Gettext support should be separate from Haunt so it can
be reused e.g. for Web servers written in Guile.
Yes, I agree. After playing with it for a while on the train it looks
like it could be implemented without modifying Haunt at all.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
https://elephly.net
pelzflorian (Florian Pelz)
2018-02-05 14:44:30 UTC
Permalink
Post by pelzflorian (Florian Pelz)
I thought about making page translations possible by allowing page
bodies to be lambdas taking a page variant as an argument, e.g. a
string containing an ietf language code, and returning the body
S-expression.
Then the page variants could be specified per site and each page would
be generated once per variant.
A site’s post-template and collection-template could then also
optionally be lambdas returning SHTML instead of SHTML.
It should also be possible to specify a procedure to transform a base
page name and a language variant to a new page name.
I still did not have time to send a patch though

Basically what I mean is to generate multiple variants of each Haunt
page, e.g. one for each locale. See the attached patches. I did not
try them yet neither document nor test them. Will do so later.
pelzflorian (Florian Pelz)
2018-02-06 10:17:50 UTC
Permalink
Post by pelzflorian (Florian Pelz)
Post by pelzflorian (Florian Pelz)
I thought about making page translations possible by allowing page
bodies to be lambdas taking a page variant as an argument, e.g. a
string containing an ietf language code, and returning the body
S-expression.
Then the page variants could be specified per site and each page would
be generated once per variant.
A site’s post-template and collection-template could then also
optionally be lambdas returning SHTML instead of SHTML.
It should also be possible to specify a procedure to transform a base
page name and a language variant to a new page name.
I still did not have time to send a patch though

Basically what I mean is to generate multiple variants of each Haunt
page, e.g. one for each locale. See the attached patches. I did not
try them yet neither document nor test them. Will do so later.
I am currently in the process of reworking my website to use page
variants. It is not done and not public yet. This change in Haunt
would mean:

Sites now have two more keys: VARIANTS and VARIANT-NAMER.

VARIANTS may be a list of page variants. For me, it is a list of
languages (“linguas”), i.e. '("de" "en"), but variants could be
anything and also used for web pages that differ not in language but
something else. If VARIANTS is not a list but the empty list '() or
#f, everything works as before without page variants. By default it
is '().

VARIANT-NAMER is a lambda that given a variant from VARIANTS and a
page’s file name returns the “real” file name for the variant. The
default puts the page’s variant before the extension separated by a
period, i.e. jabberwocky.html becomes jabberwocky.en.html.

Each page’s contents may be a procedure that given a variant from
VARIANTS returns the “real” contents. The variant can be used in a
gettext macro _ (or __ for inserting code into the translation) in the
body to look up translations, but to do so is up to the Haunt user and
is not part of Haunt. If the procedure returns #f this variant is not
generated. If the page body is not a procedure the page is generated
once as if there were no page variants.

Blog builder layouts return page contents and thus may return a
procedure that given a variant from VARIANTS return the “real” SHTML.
It is up to the Haunt user how to interpret e.g. post titles in the
layout. I plan to consider titles a procedure and call them with the
variant of the page to get the translated title.

I hope all of this works. When I’ve tried it on my website, I will
send a patch to David Thompson. What I currently have is attached.

Regards,
Florian
pelzflorian (Florian Pelz)
2018-02-06 10:19:07 UTC
Permalink
Forgot attachment.
julien lepiller
2018-03-29 10:22:43 UTC
Permalink
Post by pelzflorian (Florian Pelz)
Forgot attachment.
Hi, what's the status of that?

In the meantime, I've found ITS (Internationalization Tag Set) and
itstool: http://itstool.org/

What do you think?
pelzflorian (Florian Pelz)
2018-04-21 15:41:53 UTC
Permalink
Hello,


I am very sorry for the late reply. I got behind on my e-mail.
Post by julien lepiller
Post by pelzflorian (Florian Pelz)
Forgot attachment.
Hi, what's the status of that?
The current status has not changed since this discussion.

http://lists.gnu.org/archive/html/guix-devel/2018-02/msg00172.html

It has links to patches that I plan to work on in the coming week. I
still need to document the Haunt changes and propose them to David
Thompson again.
Post by julien lepiller
http://itstool.org/
What do you think?
This could be useful for translating blog posts that consist of just
data, but for the main Haunt source code I want more control and less
automation. When translating blog posts, I do not intend to use PO
files, instead I just make a new file with the translated blog post
for the other language’s blog. But maybe Guix would prefer PO for its
blog posts.

See my source code here:

https://pelzflorian.de/git/pelzfloriande-website/tree/

See my po file here:

https://pelzflorian.de/git/pelzfloriande-website/tree/po/de.po

(Search for the “<” character to find examples of how it uses XML,
using what Ricardo Wurmus proposed.)

Regards,
Florian

Ludovic Courtès
2018-02-05 10:19:59 UTC
Permalink
Heya!

For those who where not at FOSDEM: this is a topic we discussed, and the
main stumbling block currently is that it’s not clear how to add i18n
support in Haunt and/or the web site itself.
Post by julien lepiller
as I said during FOSDEM, I'm willing to translate the website, blog
posts, and manual into French. My only concern is that the translations
may fall out of sync without anyone noticing. With gettext, it's easy
to know when strings are not translated, but what about the solution
that would be used by haunt?
The latest discussions I’m aware of on this topic are at:

https://lists.gnu.org/archive/html/guile-user/2017-12/msg00024.html

Florian proposed introducing a “stringly-typed” markup language to allow
the translation of strings that contain markup (which sxml would
prevent):

https://lists.gnu.org/archive/html/guile-user/2017-12/msg00040.html

At FOSDEM I thought we could maybe use XML-in-strings directly and have
a macro that does ‘xml->sxml’ at expansion time, pretty much like what
Florian wrote above.

Anyway there are ideas floating around, so I’m sure you and Florian and
others will find out! :-)

Ludo’.
pelzflorian (Florian Pelz)
2018-02-05 10:49:44 UTC
Permalink
Post by Ludovic Courtès
Heya!
For those who where not at FOSDEM: this is a topic we discussed, and the
main stumbling block currently is that it’s not clear how to add i18n
support in Haunt and/or the web site itself.
Post by julien lepiller
as I said during FOSDEM, I'm willing to translate the website, blog
posts, and manual into French. My only concern is that the translations
may fall out of sync without anyone noticing. With gettext, it's easy
to know when strings are not translated, but what about the solution
that would be used by haunt?
https://lists.gnu.org/archive/html/guile-user/2017-12/msg00024.html
Florian proposed introducing a “stringly-typed” markup language to allow
the translation of strings that contain markup (which sxml would
https://lists.gnu.org/archive/html/guile-user/2017-12/msg00040.html
At FOSDEM I thought we could maybe use XML-in-strings directly and have
a macro that does ‘xml->sxml’ at expansion time, pretty much like what
Florian wrote above.
Anyway there are ideas floating around, so I’m sure you and Florian and
others will find out! :-)
Ludo’.
I don’t think translators should need to know XML or anything beside
common sense and human languages. Either way, I’m happy with __ and _
functions I have at
https://pelzflorian.de/git/pelzfloriande-website/tree/haunt.scm

Of course other solutions are possible.

I’m not happy with my using ffi-help for calling libgettext. Simply
calling setlocale for each piece of SHTML is better because it is
easier to understand. Using a custom Guile MO file reader would
likely be faster but is not strictly necessary.

So far I did not prioritize sending a patch for Haunt because I do not
need it urgently. I would be thankful if others took a look.
Otherwise I’ll try to implement what I described in this here e-mail
thread.
Loading...