translate content to other languages

[open-traits-network]

translate content to other languages

[bmaitner]

Should we add an option in the member profiles for the "info" field in different languages? Or perhaps the easier solution is for multi-lingual folks to just have longer "info" data with things translated into other languages in the existing field?

[caterinap]

I am happy to do Italian and French if you want!

[shandongfx]

@rachaelgallagher Happy to help. Yaoqi may also be able to help us.
Given that we are considering multiple languages, we may do this in a more structurally way.

1. have a table, rows represent contents, columns represent same meaning in different languages. The contents could be words, paragraphs. And those are just a subset of things we want to show in different languages.
2. for example:
   id English Chinese
   1 hi 你好
   2 how are you 你好吗

Just a suggestion, not sure if possible to implement it here (@jhpoelen ).

[rachaelgallagher]

thanks for the offer to help out @shandongfx and @caterinap. I was envisioning that we would just have a button at the top of the screen on the site to translate the page to another language, with options for Spaniah, Chinese, French, Italian etc. @bmaitner - I am not sure what you are proposing, but perhaps we can talk through it in our skype if I can schedule it for outside your teaching hours.

[jhpoelen]

I've recently introduced translations for https://globalbioticinteractions.org using lightweight jekyll approach. See https://github.com/globalbioticinteractions/globalbioticinteractions.github.io . For simple site like ours, this seems appropriate.

Approach is:

1. default is English
2. define paths based on context language ( e.g., https://github.com/globalbioticinteractions/globalbioticinteractions.github.io/blob/master/_config.yml#L27)
3. translated words get an id and go into _config.yml (e.g., https://github.com/globalbioticinteractions/globalbioticinteractions.github.io/blob/master/_config.yml#L27)
4. translated pages go into /[language code]/ (e.g., es, jp)

Then, translated words (in dataset/ member pages), would need to be encoded using tags like {{ site.t[ word id][ language code] }} (e.g., https://github.com/globalbioticinteractions/globalbioticinteractions.github.io/blob/master/_includes/interactionTypeSelector.html)

So, yes, it is possible.

Questions are:

1. who's going to setup the infrastructure?
2. which languages are most important?
3. should we do this before manuscript gets published?

[jhpoelen]

I'd be happy to volunteer to assist / help review someone who's going to get it setup.

[bmaitner]

Rather than providing alternate language content on the basis of translating words, it seems like it might be better to have whole text blocks translated. My concern is that automatic translations might lose some of the meaning, or end up being a bit nonsensical. Of course, the trade-off would be that someone would need to translate whole text blocks, but I think its alright if those lag behind a bit.

[jhpoelen]

@bmaitner Totally agree. I found that depending on context translating entire pages (e.g., introduction/about pages), text blocks or individual words (e.g., pick lists, menus) makes sense.

For example of whole text blocks translation, see https://github.com/globalbioticinteractions/globalbioticinteractions.github.io/blob/master/_config.yml#L107

[bmaitner]

Would it be possible to modify this code so that the code for the translated blocks of text are on the corresponding .md files?

e.g. 2019-09-16-new-website.md might contain both english and spanish version of the text.

[jhpoelen]

I think it's possible. Want to give it a try?

[bmaitner]

Sure, it might take me a while to wrap my head around the coding, but I'll try to find some time to look into this.

[bmaitner]

Ok, I've played around with a few of the plugins, and I guess our first step should be to select one of these. Does anyone have a preference? The multiple-languages plugin seems to be relatively common, and seems to be updated more frequently than some of the other plugins available.

[jhpoelen]

I prefer using no plugin to keep things simple, especially given our lightweight website. Happy to walk you through the no-plugin approach I've used elsewhere.