Issue 596: Language Resolution

[bergos]

Adds the language resolution logic to the UI specification.

Closes #596

• See this document rendered online here

[robert-david]

, from left to right.

[TallTed]

I'm not sure this is necessary, as the lead in to the ordered list states earlier entries are preferred over later ones. But if it is...

Suggested change

	<code>sh:languageIn</code> values.
	<code>sh:languageIn</code> values, from left to right and top to bottom.

But this seems to assume one serialization (which seems likely to be Turtle), which I don't think is required anywhere.

[robert-david]

Preferred default should be a literal with no language?

[smessie]

Looks good to me content-wise. I just included some suggestions below to improve the wording to my feeling.

[smessie]

Suggested change

	UI literals — such as labels, descriptions, and other human-readable strings required for
	rendering a user interface — are selected based on language tags. This section defines how
	an application determines which language to use when multiple language-tagged literals are
	available for a given property.
	UI literals, such as labels, descriptions, and other human-readable strings used for
	rendering a user interface, are selected based on language tags. This section defines how
	an application determines which language to use when multiple language-tagged literals are
	available for a given property.

[TallTed]

Using commas to offset this sub-sentence makes it more difficult to parse, especially but not only for people for whom English is a second or later language. The em-dashes offset the sub-sentence more clearly, such that readers can ignore that section when reading for comprehension, and then return to parse the "such as" details.

[smessie]

Suggested change

	The values of <code>sh:languageIn</code>, when present in the applicable <a>shapes graph</a> context. This
	specification extends the semantics of <code>sh:languageIn</code> giving the order of language tags in the
	list a meaning. Implementations MUST prefer literals according to the order of the
	<code>sh:languageIn</code> values.
	The values of <code>sh:languageIn</code>, when present in the applicable <a>shapes graph</a> context. The use
	of `sh:languageIn` in this document extends its semantics, providing a meaningful order to the language tags
	in the list. Implementations MUST prefer literals according to the order of the
	<code>sh:languageIn</code> values.

[TallTed]

This rephrasing results in an inaccurate statement.

[smessie]

Suggested change

	ex:PersonShape
	a sh:NodeShape ;
	sh:property [
	sh:path foaf:name ;
	sh:name "Name"@en ;
	sh:name "Nom"@fr ;
	sh:languageIn ( "fr" "en" ) ;
	] .
	ex:PersonShape
	a sh:NodeShape ;
	sh:property [
	sh:path foaf:name ;
	sh:name "Name"@en ;
	sh:name "Nom"@fr ;
	sh:languageIn ( "fr" "en" ) ;
	] .

[smessie]

Suggested change

	ex:alice a ex:Person ;
	foaf:name "Alice"@en ;
	foaf:name "Alice"@fr .
	ex:alice a ex:Person ;
	foaf:name "Alice"@en ;
	foaf:name "Alice"@fr .

[TallTed]

Starting from @robert-david's suggestion (which only commented on line 1090)

Suggested change

	If no literal matching the preferred language is available, implementations MAY fall back to a literal in
	another available language or apply the <a>label resolution</a> fallback strategy as defined for the relevant
	context.
	If no literal matching the preferred language is available, implementations MAY fall back to a literal in
	another available language (or without a declared language) or apply the <a>label resolution</a>
	fallback strategy as defined for the relevant context.