Support i18n

[matthieu-fesselier]

Is internationalization currently supported? If yes, how are we able to get language-specific data from a node?

[RubenVerborgh]

Current support is as follows: when you (for) await an LDflex path, then you get back an RDF/JS term corresponding to the RDF/JS specification. If the term is a literal, then it will have a .language property indicating the locale.

What you can do now is loop over all the literals and filter those you need.

In the future, I’d want to add:

• a built-in filter mechanism so you can pick
• a preference for languages (based on the user profile) such that the applicable one is filtered automatically

-- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged, confidential and/or proprietary information. If you are not the intended recipient of this e-mail (or the person responsible for delivering this document to the intended recipient), please do not disseminate, distribute, print or copy this e-mail, or any attachment thereto. If you have received this e-mail in error, please respond to the individual sending the message, and permanently delete the email.

[danielbeeke]

I would like to learn how to fix this issue. The first thing I would like to do is support the following:

selecting: fruit.label.en

I have been spending 4 hours on it.

The LDFlex library seems complex.

• So far I understand I should create a resolver because languages are dynamic path parts.
• [unsure] Inside the resolver I should add something to the pathData so I can later pick that up in the SparqlHandler.
• I think I should modify SparqlHandler to add a conditional FILTER(langMatches(lang(?t), "EN")) but ofcourse with the correct replacements.
• A test should be created, containing triples that have translations "Lorem ipsum"@en
• The createQueryEngine mock should be changed to return the language specific variant of the label.

Are these steps correct?

[danielbeeke]

If I understand it correctly it will be hard to detect what languages are possible. It would be interesting to have pluginType (like handlerss and resolvers) that may run after the query results. Maybe I don't understand the full thing at this moment. But it would be interesting to only let the supports() method return true when the language is available in the result.

[danielbeeke]

I have a proof of concept with one big pitfall. The languages are hardcoded. So it would not be possible to merge it. What would be a good way to solve this?

[rubensworks]

Just wondering if it might be interesting to use JSON-LD's @language keywork on properties to define the language of property values. This could possibly be an additional way of requesting a certain language.

[danielbeeke]

Do you mean something like: fruit.['label@en']

[rubensworks]

Do you mean something like: fruit.['label@en']

Something more like this:

Context:

{
  "label": { "@id": "rdfs:label", "@language": "en" }
}

LDflex expression:

fruit.label

[danielbeeke]

Ah nice! that is great. Is it possible to use @language in the root of context? To define the default?

So also:

{
  "@language": "en",
  "dutchLabel": { "@id": "rdfs:label", "@language": "nl" }
}

[rubensworks]

Is it possible to use @language in the root of context? To define the default?

Yep, JSON-LD defines that behaviour, so it would make sense if LDflex would inherit that.

[danielbeeke]

I have the following working:

fruit.label['@nl'] fruit.label.$nl

In the current state, the languages are not hard-coded. They are prefixed and with that it is possible. How ever it could be argued that fruit.label.nl is better than fruit.label['@nl'].

What do you think?

[danielbeeke]

It is now also possible to set the default language via the context with:

{
  "@language": "en",
}

However I am struggling with these proxies. I created 'getFirstOrDefaultItem' and can not figure out why I can not get the settings out of a pathData there.