Multilingual workshop template in one repo

[jduckles]

@rgaiacs has created a new repo, see #337 for a Portuguese translation of the workshop template. Longterm I'd really rather these all go in one repository with directories or branches for each language and some template logic to pick the language. There isn't really a good reason to have a new repo for each language and it creates a headache in the future if we make changes they have to be applied to multiple repos.

Any technical solutions you can think of that don't require backbreaking Jekyll gymnastics and would support multiple languages for the workshop page content?

[rgaiacs]

Longterm I'd really rather these all go in one repository with directories or branches for each language and some template logic to pick the language.

History shows that a new repo for each language will avoid spam lots of people with pull request covering translations.

Also, branches will not work with GitHub Importer that we are using. And from my experience, people never remember to look on what branches exists in a GitHub repo.

[jduckles]

@rgaiacs How do you propose to keep template logic changes and install instructions versioned and consistent across translations?

[abbycabs]

Hey all,

We ran into this before with Mozilla Study Groups (@rgaiacs will remember this 😄 ) - mozillascience/studyGroup#36 < the discussion might be helpful here.

From a user perspective, having separate repos (or separate directories on the same gh-pages branch) that followed this convention would be helpful:

• http://swcarpentry.github.io/en/workshop-template/
• http://swcarpentry.github.io/pt-br/workshop-template/

[gvwilson]

I think the biggest problem will be maintenance: regardless of where we store material, how are we going to keep it all in sync as we make changes?

[rgaiacs]

how are we going to keep it all in sync as we make changes?

I'm more worry about saving lead instructors time (not translate the page from scratch) and less worry about keep it all in sync all times.

In the past what I always did was git fetch upstream && git merge upstream and after that update the translation and the information for the next workshop. But I only did it when I have a new workshop schedule. In some cases the translation was out of date for months.

[k8hertweck]

Would it be possible to have a "translation maintainer" for each language, not to be solely responsible for translations, but to help keep tabs on when changes occur and to delegate to folks who can help with translations? This could add a nice community development component, of someone who can help introduce folks from other countries to making PRs, etc.

[k8hertweck]

It appears we're reaching critical mass of opinions on how to handle additional languages in the workshop template, so I would like to make a proposal. We don't want to be biased toward any particular language or locale, but on the other hand, the great majority of our workshops are still in English, and I'd like us to have more experience handling translations before we do anything major. I therefore propose that:

1. We create a sub-directory in workshop-template for each new language that someone volunteers to support. This means that (for example) the URL for the Portuguese version of a workshop's home page would be http://somebody.github.io/year-month-day-location/pt/ (note the /pt/ on the end, indicating Portuguese).
2. We keep the English-language version in the root directory for now.
3. We don't do anything about translations of lessons until we have more experience with this.

This plan keeps everything in one repository without disrupting anything that people are already doing. It is biased towards English, but if it works, we can think about moving the English home page into /en/ in the next big round of work.

If you like or dislike this plan, please vote with a thumbs-up or thumbs-down on this post. Please add any new comments here by Wednesday, Sept 7.

[rgaiacs]

@k8hertweck This will not work for lessons because of all the hard code strings that we have at https://github.com/swcarpentry/styles/tree/gh-pages/_includes, such as https://github.com/swcarpentry/styles/blob/gh-pages/_includes/episode_keypoints.html. I would like to avoid a solution like

<h2>
{% if lang == "en" %}
Key Points
{% elseif lang == "pt" %}
Pontos chaves
{% elseif lang == "es" %}
Puentos clave
{% endif %}
</h2>

[k8hertweck]

I agree that this is harder with lessons, but does this work with the workshop template?

[rgaiacs]

I agree that this is harder with lessons, but does this work with the workshop template?

Nope. We need to translate the navigation bar, https://github.com/swcarpentry/workshop-template/blob/gh-pages/_includes/navbar.html.

[iglpdc]

I think we are setting the wrong goals with the translations. The workshop template is only used once the workshop is organized and, in this sense, is not going to open up SWC to another languages or countries.

To me, the approach for the workshop template should be what @rgaiacs did: once a workshop is scheduled, the instructor traslates the workshop index.html page. I don't think this is a big deal, in the sense that most people will get the information in some other form and what is really important about the workshop template is the automation that offers for us. Therefore, we don't need to shoot for a complete or perfect traslation. I wouldn't care about maintaince much either: simply when we organize the next workshop in that language, we patch everything up again.

I would rather focus our efforts in traslating the lessons, which requires different tweakings. Having the lessons in other languages (or at least a mechanism to traslate lessons) is what will allow us to reach out to people who don't have the chance to attend a workshop and have no good command of English.

[daisieh]

For the lesson content: I suggest that we maintain these lessons as separate branches based in the fork of the original translator. That fork/branch would then become the main repo for that particular translation. It would be pretty clear from the git network which lesson that translation was based on, and if the owner or other contributors wanted to bring it up to date to the current version, they could merge changes along as they go. Also, then issues/PRs from other contributors to that translation could be directed at that fork/branch instead of at the main English repo.

We should then have a master list on, perhaps, the instructor notes with a list of the languages available and the fork/branch that has them.

[rgaiacs]

As stated by @twitwi on #376

When we use the github importer to copy a repo, it copies all branches too.

Maybe we don't want it.

[fmichonneau]

We're thinking about translations and using a different approach.