Human-readable "name" has i18n problem - rely on "title"/"titles" in Thing instead?

[mmccool]

If the default language is changed, for example as part of HTTP negotiation returning text for title and description using an alternative language, then the interpretation (and potentially display, eg in a web dashboard) of "name" and "support" (in case the value of "support" is a person's name, for example) will get broken if "name" and "support" are written using a language with a text direction opposite to that of the (new) default language.

I think we need an alternative mechanism for specifying a language explicitly for "name" and "support" that overrides the default language, since the idea is that these strings are immutable and should always be displayed the same way, including language and text direction.

I suggest adding an optional "supportLanguage" name/value to the Thing object. This would would have a BCP47 language tag as a value (potentially with a script subtag, as needed to specify the direction unambiguously) to specify the language for "name" and "support". This would override any default language specified by any other means for those two strings only, whether the default language was specified using @language or through protocol negotiation.

It would be optional, however, and if not present the values of "name" and "support" would be interpreted according to the default language.

In the interest of time, I will prepare a PR based on top of my text direction PR, then we can discuss.

[mmccool]

Other ways to deal with this:

1. Allow a nested context for "name" and "support". This is more JSON-LD-ish. However this is tricky since there is no convenient object scope to add it to. It's also a bit obnoxious and verbose.
2. Allow the values of "name" and "support" to be either strings OR MultiLanguage objects with explicit language tags, eg. "name": { "en": "My Thing" }. However, this has the problem that MultiLanguage implies there could be more than one entry, so technically, we would really want a new class like SingleLanguage (perhaps called StringWithLanguage) that is like MultiLanguage but with a cardinality of exactly 1).
3. Always interpret "name" and "support" using the first-strong rule, ignoring the default language. This is fragile and has the problem that it's not optional.

I'll create a PR for now based on adding "supportLanguage" but we can discuss these other options here.

[mmccool]

PR available: mmccool#8.
This is currently set up as a modification of PR #620.

[sebastiankb]

name should be kind of identifier and there should be no language variations.
I understand the purpose to provide language information for the support term. We should rethink to type the support term as anyURL again and use scheme like mailto. What do you think?

[mkovatsc]

This feels like classic overengineering to me.

I would define the "name" field as a (non-unique) identifier in the default language.
Restricting supprot to anyURI is also good, as people can still be given as mailto URI.

[mmccool]

Yes, but the point is the default language can change due to content negotiation, which will screw up rendering. Anyhow, I've just prepared a PR and we can decide to use it or not. But it's a potential problem that could easily arise in multilanguage contexts. And we can fix it. Or not.

[mkovatsc]

Oh darn, got it! When dynamically generating a TD for a certain language, that language might be different from the name chosen...

[sebastiankb]

we should drop name and introduce title (mandatory) and titles

I know it is big change

[mkovatsc]

we should drop name and introduce title (mandatory) and titles

Yes, a big chance at this point, but I also think we need to, as it is basically an i18n issue.

We stuck to name because we thought it is just a "simple string" that can be used as informal identifier. Yet we also have the strong expectation, that this name will be used in UIs. This has a clear i18n requirement. title and titles address this this requirement.

Introducing names does not make sense to me, as name loses its informal identifier aspect (there being only one string). Hence lets use title/titles.

Making title mandatory solves the issue that there must always be a string for the Thing to use in UIs.

Having titles enables dynamic TD generators to serialize a correct title string for the negotiated default language.

[mkovatsc]

@mmccool , can we agree on dropping the supportLanguage feature and rename this issue to reflect the issue with a non-internationalized name?

[mmccool]

Sure, can drop supportLanguage; using title/titles seems like a good solution to me, as well as making "support" an anyURI. I can include both those changes in my PR, but I'll have to do it tomorrow (it's very late in the evening here and I'll screw it up if I do it now).

I will update the title of this issue.

[mmccool]

Title changed. Sorry it's so long, I'm out of brain cells right now.

[mmccool]

Created this, too: #633. This makes support an anyURI.

[mkovatsc]

Can we collect +1s for going for title (mandatory) and titles (optional) in Thing?

I am in favor (see #630 (comment))

[mmccool]

Re title/titles in Thing: +1, in favor. Also, to repeat myself, +1 for support being an anyURI.

[egekorkan]

title/titles in Thing: +1

[takuki]

+1 regarding renaming "name" to "title" plus "titles", and also +1 for changing type of "support" to anyURI.

[mkovatsc]

FYI: We are not renaming, we are kicking name with its identifier definition and allow title and titles as they exist already now also in Thing.

[takuki]

I just made changes so that "titles" is now optional while "title" stays mandatory.
Please take a look at here.

[mkovatsc]

We had this one open as long as possible for the group to review and comment. Since no concerns were raised, I am closing this issue now.

Note that this is not an issue opened by the I18N WG.