support multi-lingual

[bridgetkromhout]

We have events that are already written in non-English languages. It would be super rad to be able to allow organizers, sponsors, etc in those countries to toggle some selected pages like https://www.devopsdays.org/sponsor/ and https://www.devopsdays.org/organizing/ into other languages if available.

See http://gohugo.io/content/multilingual/ for details.

[bridgetkromhout]

The name of welcome.md needs localization (right now that exact word is expected). Also, {{< event_location >}} expects to go to location.md.

[bridgetkromhout]

Looks like all the event_ shortcodes behave this way.

[bridgetkromhout]

In the preview, it appears that this doesn't exist:

https://deploy-preview-1494--devopsdays-web.netlify.com/events/2017-sao-paulo/welcome/

I noticed this because I have /welcome/ hardcoded into the partials for future/past/etc.

(it worked locally with an alias, and worked post-merge. I seem to recall something about this being expected, but just in case it wasn't...)

[mattstratton]

Changing filenames isn't exactly how the hugo multi-lingual works. They have the same logical filename; they just append the language.

That is to say, we can change the content, but changing filenames of some pretty essential navigation elements (welcome.md is a huge one) is a lot harder/not really possible.

[mattstratton]

The welcome page thing works for sao-paulo because on their bemvindo.md page they added this:

aliases = ["/events/2017-sao-paulo", "/events/2017-sao-paulo/welcome"]

Something like that is going to break hardcore in the new theme, because I do some checking to see if you're on the welcome page to display certain content.

One way around that, if we have to, is to have an optional override in the YYYY-CITY.yml file to specify the file for the "homepage", and the check can first see if that is set, and if not, it will check on welcome.

Relevant code is at https://github.com/devopsdays/devopsdays-theme/blob/0.2.6/layouts/event/single.html#L41-L43

Another option is to make the "welcome" page a different type from event. That seems a little messy, but not the end of the world. It's also possible that we set a frontmatter flag on whatever page is the "home page" for an event, like homepage = "true" and use that as the check.

That actually will possibly help with backwards compatibility for the events that pre-date the new theme, so I am kinda into it.

[fike]

Maybe too late for contribute. :)

I think could be more easy to maintain if you can keep name files and just add a suffix in the filename. Debian Documentation, for example, they just put ".pt" in the filename and keep links and references in english.

https://www.debian.org/releases/stable/amd64/apbs01.html.**en**#preseed-methods
https://www.debian.org/releases/stable/amd64/apbs01.html.**pt**#preseed-methods

[mattstratton]

@fike not too late! This is going to not be solved quickly :)

That said, what you described is basically the end result of Hugo's multi-lingual feature, which totally accounts for translated CONTENT, but it won't handle the lower level code type objects like "welcome" and "location" as terms in the data files :)

But I think the translated content is where we should start.

[mattstratton]

If folks don't want to click through, here's the gist:

Translating your content

Translated articles are identified by the name of the content file.

Example of translated articles:

/content/about.en.md
/content/about.fr.md
You can also have:

/content/about.md
/content/about.fr.md
In which case the config variable DefaultContentLanguage will be used to affect the default language about.md. This way, you can slowly start to translate your current content without having to rename everything.

If left unspecified, the value for DefaultContentLanguage defaults to en.

By having the same base file name, the content pieces are linked together as translated pieces.

[mattstratton]

OK, so the way this ends up working isn't "automagic", in terms of, it won't figure out the users language and automatically translate stuff. It basically creates a new "site" structure, say devopsdays.org/es for spanish, devopsdays.org/fr for the french content, etc.

So what I was thinking, is that we could add little flags to the top nav for all the languages we support, and then when you click on them, you're in the site of that language, so to speak.

[MikeRosTX]

Instead of adding little flags to the top nav for all the languages we support, this site http://bittersmann.de/articles/no-flags/ gives some good examples of handling multilingual site. We could try using the simples IMO that Gunnar mentions, which is Language Negotiation.

[mattstratton]

I suggest leaving off bikeshedding on the details of the implementation until we take this one on, which is likely months from now. Given the major impact of this type of effort to the rest of the site and my intent to not make major changes when events are happening, this is probably around 2017Q4.

[mattstratton]

This issue is already tracked in prodpad so the GH issue artifact won't be needed until we are ready to work on this large project.

[mattstratton]

Re-opening

[mattstratton]

I'm concerned we are going to get bit by this bug: gohugoio/hugo#2699

The issue seems to be that when there are files with identical names, they start to mess with each other's translations. Since we duplicate file names A LOT, this is probably going to be a problem. This seems to be on an upcoming milestone for Hugo though, so I'm not too worried about it.

[mattstratton]

Actually, it doesn't seem to be a problem (the aforementioned bug), at least not so far.

I started a bit of a POC on the global nav, at least...this might not be too terrible. The biggest issue is that the manner in which we generate the event-level nav (driven by content in the yaml file) might have to be re-visited.

[fike]

Maybe a simple solution is create more masks/variable, I can translated almost all in the Sao Paulo 2018 event. Just keep in English dates and Sponsor types.

• https://www.devopsdays.org/events/2018-sao-paulo/

Devopsdays São Paulo 2018

devopsdays São Paulo 2018

[mattstratton]

There have been a few releases of Hugo since this thread was opened, specifically around adding even more multilingual features. I highly suggest we don’t create our own implementation but use the features the framework provides.

[fike]

We can wait. :)

[MikeRosTX]

I'm not even sure if this is even possible or not, or would add too much complexity. But I've seen some sites that have implemented this feature and at first glance from a usability stand point seems painless. But not sure with the theme we have is even a viable solution. Just throwing it out there for discussion.

https://stackoverflow.com/questions/12243818/adding-google-translate-to-a-web-site?answertab=votes#tab-top

[mattstratton]

Bringing this one back up as I have a minor spike i've been hacking on this morning; multi-language support in Hugo is a LOT easier these days, and I think we can enable the framework for this with relative ease.

It'll be the responsibility of each event to make the different language versions for their pages as they want to, but what we can do is make sure that:

1. the foundational elements exist to make this relatively easy to do for an event (short of having to do the translations)
2. make sure the overal/global parts of the site support the multiple languages, and also any of the global components as well (menus, for example)

[somatorio]

How may I help on this? :)

[mattstratton]

@somatorio I'll have a working branch up shortly with some of the efforts I'm doing! Definitely will need help with some translations.

[mattstratton]

okay so this is fun...there's some stuff in our code that is going to make this harder than you would think.

So, to give context, the way multi-lingual works, it ends up rewriting the path/url of the page. So let's say that there's a french version of the code of conduct for 2023- Chicago, instead of
/events/2023-chicago/conduct/
the url is
/fr/events/2023-chicago/conduct/

Why is this an issue?

because the way that the "look up info about an event" code works, the way it figures out which city/year is being referred, is from the url, ie:

{{ $slug := (index (split ($.Page.Permalink | relURL) "/") 2) }}

So with translated content, the value of $slug is "fr" not "2023-chicago".

going to have to think this one through

[mattstratton]

doesn't look like the url structure in multi-lang hugo is configureable, so we will need to come up with a larger solution
https://discourse.gohugo.io/t/customize-multilang-url-putting-the-lang-code-last/37622/4

Really, the fix has to be that we somehow don't use the URL in that way to detect the slug.

I'm wondering if we can do something like "take the key that comes after you find "events" but that's...sloppy

HUGO

Customize multilang url - putting the lang code last

Oki, then I understood it correct. IMHO it would it make easier to create nicer urls for hugo. Example: /learn/more/gr/ would certainly look nicer than currentl /learn/gr/more But it is what it is. Are there any ongoing work/plans for more configurable URL-handling, or should I add a feature request issue?

[mattstratton]

okay good news. that wasn't terribly hard to do.

It's a little sloppy but it's working.

I now check for the event slug this way:

{{ $slug := "" }}
{{ if eq "events" (index (split ($.Page.Permalink | relURL) "/") 1)}}
  {{ $slug = (index (split ($.Page.Permalink | relURL) "/") 2) }}
{{ else }}
  {{ $slug = (index (split ($.Page.Permalink | relURL) "/") 3) }}
  {{ warnf "The slug is %s" $slug }}
  {{ warnf "The permalink is %s" $.Page.Permalink }}
{{ end }}

I also had to fix something elsewhere that uses the url to figure out if it should show the event navbar etc!

[mattstratton]

Take a look at #13724 to see the WIP

Check it out in real time on this page https://deploy-preview-13724--devopsdays-web.netlify.app/events/2023-chicago/conduct

note! the only thing that actually works is on that particular page, notice it shows the translated options toward the top (it only displays that on pages that have translations)

note that the "languages" menu in the main navbar doesn't actually work, don't get excited :)

Conduct

Code of conduct for devopsdays Chicago 2023