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