Internationalization/localization of a vocab

[acka47]

@sroertgen asked for this via Slack:

weisst Du zufällig, ob es einfach möglich ist, die Sprache in skohub-vocabs auf “de” zu setzen, wenn sie da ist

We should think about how to adress this. There are different options:

• Let publishers configure the default language to be shown.
• Choose language based on language header sent by browser

@sroertgen, what do you have in mind?

[sroertgen]

I would actually prefer the latter, but in terms of usability, it would also be nice to have an option to switch languages.

[sroertgen]

so we figured out how to get it all in german ^^
as long as every file has a german title and the german title comes before the english title, we get german. I guess it has something to do with row 5-7 in src/common.js, but I am not able to fix this.

[literarymachine]

I guess it has something to do with row 5-7 in src/common.js, but I am not able to fix this.

It indeed has! Currently we simply use the first language found, which is why your approach above works, all other languages are currently ignored. I was thinking about building all languages in the future and then using Apache MultiViews to negotiate the language to be delivered.

[acka47]

Regarding a functional review of #102:

It looks very good all around but I am not sure whether this requirement is met:

Choose language based on language header sent by browse

When I test this locally using the HCRT vocab as test data, start the development server and load something like http://localhost:8000/w3id.org/kim/hcrt/assessment in my browser I won't be redirected to http://localhost:8000/w3id.org/kim/hcrt/assessment.de.html or http://localhost:8000/w3id.org/kim/hcrt/assessment.en.html.

[literarymachine]

As described in #79 (comment), the build relies on Apache MultiViews to negotiate the language to be delivered.

[literarymachine]

As described in #79 (comment), the build relies on Apache MultiViews to negotiate the language to be delivered.

It just came to my mind that this might not play well with GitHub pages. Could you check, @sroertgen?

[acka47]

Thanks, @literarymachine, for working on this. I now have tested it a bit. There is one problem with the language links:

1. The language links (en/de) are broken, see https://test.skohub.io/acka47/hcrt/heads/master/w3id.org/kim/hcrt/scheme.de.html. Adjusting the URL manually does work, though. (I remember them working in the beginning, though.)

Otherwise it looks good and works well if you have all strings covered with multilingual labels but it does not look good as soon as you don't have all the strings covered.

2. When I have different vocabs in a repo where not all have dct:title in the selected language, the vocab title is not shown at all see e.g. https://test.skohub.io/hbz/vocabs-edu/heads/master/index.de.html (solution: if the chosen language is not given for a shown label, another language should be shown as fallback).
3. Similar with single concept labels. When some of the concepts don't have prefLabel in the selected language they are not shown in the list, see e.g. https://test.skohub.io/acka47/hcrt/heads/some-labels-missing/w3id.org/kim/hcrt/scheme.en.html
4. When I tried to build with a concept that a) only has a German label but b) has a German and English label for skos:scopeNote it would not build at all. See https://github.com/acka47/hcrt/blob/bbda67174303eb4c92337d1c36976fff54e43181/hcrt.ttl#L121-L122

[literarymachine]

The language links (en/de) are broken, see https://test.skohub.io/acka47/hcrt/heads/master/w3id.org/kim/hcrt/scheme.de.html. Adjusting the URL manually does work, though. (I remember them working in the beginning, though.)

Fixed in 2584e9b

Otherwise it looks good and works well if you have all strings covered with multilingual labels but it does not look good as soon as you don't have all the strings covered.

I would argue that it is simply best practice to fully cover any languages you wish to support. From experience e.g. with OER World Map I can say it tends to quickly get confusing if you automagically fall back to other languages.

When I tried to build with a concept that a) only has a German label but b) has a German and English label for skos:scopeNote it would not build at all.

I can't reproduce this, can you try building that version of the vocab locally?

[acka47]

I can't reproduce this, can you try building that version of the vocab locally?

I can't reproduce it as well. The reason for not building must have been something else. Sorry.

[acka47]

@dr0i, can you please redeploy this (PR) to test with the fix @literarymachine provided (2584e9b)?

[dr0i]

@acka47 redeployed with the fix.

[acka47]

There seems to be something broken now. Redelivering the payload of the last webhook request, I now get an error (although it did build on 2020-11-04: https://test.skohub.io/build/?id=e5f8472a-ceda-44d8-945c-65383f0ef4e9

[acka47]

Looks good now, there is only one minor thing: Clicking on "SkoHub-Vocabs" one should get back to the vocabulary overviewand the link behind actually points at https://test.skohub.io/acka47/hcrt/heads/master/ which works when resolving it from scratch. But when clicking "SkoHub-Vocabs" it gives an error message:

[literarymachine]

Clicking on "SkoHub-Vocabs" one should get back to the vocabulary overview and the link behind actually points at https://test.skohub.io/acka47/hcrt/heads/master/ which works when resolving it from scratch. But when clicking "SkoHub-Vocabs" it gives an error message

This is fixed in adb1928. When using the Gatsby link component, it has to point at the actual file. /acka47/hcrt/heads/master/ only works when initially requesting from Apache with Multiviews enabled.

Speaking of Apache and Multiviews, these are currently a requirement for the i18n to work! @sroertgen might want to look into this from the GitHub pages perspective.

[sroertgen]

Hey @literarymachine,
thanks for your work!
So, to get this work from a GitHub Pages perspective I need a index.html. My "hacky" workaround would be this:

// gatsby-node.js
createPage({
    path: `/index.html`,
    component: path.resolve(`./src/components/indexRedirect.js`),
    context: {
      languages: Array.from(languages)
    }
  })
}

and create a indexRedirect.js-component:

// indexRedirect.js
import React from "react"

const IndexRedirect = ({pageContext: {languages}}) => (
  <div>
    <meta http-equiv="refresh" content={`0; url=/public/index.${languages[0]}.html`} />
  </div>
)

export default IndexRedirect

This way a index.html gets build which just directly redirects to the first language of languages.

I don't know if this is too hacky for you or would somehow interfer with Multiviews. If so, I would just add it to the docker branch, which should also be fine. Otherwise I could add it if wanted.

[literarymachine]

I don't know if this is too hacky for you or would somehow interfer with Multiviews.

Not to hacky for me, this is the type of client-side redirect I would also consider. But we would need it for every single concept URL, right? This would should result in something like the following file structure:

/ex.org/concept/scheme.de.html
/ex.org/concept/scheme.en.html
/ex.org/concept/scheme/index.html (redirect to ../scheme.de.html or ../scheme.en.html as you describe above)
/ex.org/concept/foo.de.html
/ex.org/concept/foo.en.html
/ex.org/concept/foo/index.html (redirect to ../foo.de.html or ../foo.en.html as you describe above)

I just figured out that this will indeed mess with MultiViews though, so perhaps it is best to add it to the docker branch for now and think about how to make it configurable when we think about things like #75 (comment).