Canonical way of language‐tagging strings

[marrus-sh]

I think that the type annotation mechanism for KDL would be very good for language‐tagging, so one might have

book {
  title (@en-US)"My Favorite Color"
  title (@en-GB)"My Favourite Colour"
}

@ followed by a language tag is an existing syntax for language‐tagging strings in Turtle, and I think it is a reasonable syntax. It would be nice to reserve type annotations beginning with @ for this mechanism, so that tools could exchange language‐tagged KDL data in an interchangeable manner.

[marrus-sh]

(Language‐tagging is not necessarily solely useful for strings; for example, in XML the xml:lang attribute is applied to elements and language‐tags all descendant nodes. Having a similar inheritance model for KDL nodes would be appreciated, but require more specification work.)

[zkat]

What do you see as the benefits for standardizing this? How would individual parsers look at these and react differently? In your example, how would a parser's behavior change based on each title?

The current type reservations are currently intended to actually allow parsers to parse into different types, especially in dynamically-typed languages. I don't see the same benefit for @, although I really do like the idea of language hints overall.

[marrus-sh]

What I would like is to receive { value: "foo", language: "en", type: null } from a KDL processor instead of { value: "foo", type: "@en" }. This would make it much easier to support application logic which depends on language information, and matches the existing value model of technologies like RDF and JSON‐LD.

For example, any application which displays a string to users will need to know the language of the string in order to annotate it correctly (e·g with the lang attribute of HTML). This is easy if you can just do term.language and much harder if you need to do term.type[0] == "@" ? term.type.substring(1) : null. It is a relatively trivial thing for parsers to support, but cumbersome to deal with in application logic, which is why it feels like it should be a core language feature to me.

The benefit of standardization is simply that it ensures that a KDL file produced by application A can be read by application B without losing language information, which is the same benefit provided by type annotations generally.

[zkat]

To reasonably achieve what you're showing in the example here, you could just do:

book {
  title lang="en-US" "My Favorite Color"
  title lang="en-GB" "My Favourite Colour"
}

Granted, it doesn't apply it directly to the string object, but I think this is a more flexible alternative than overloading types.

[tabatkins]

Note that tags aren't arbitrarily extensible - a value can have zero or one tag, that's it. If we used a tag for language, we couldn't also have a tag for anything else. (Unless we modified the spec to specifically allow a normal tag and a lang tag, of course.)

But then a "language" isn't particularly specific to human-readable strings, either; reading a string as a date, or as a Decimal10, is similarly "metadata about how to interpret the value", which can be similarly vital to understanding and proper usage of the string value.

Human-readable text, also, isn't best represented as a string literal; human text requires markup structure to properly capture (at minimum, bidi markup for mixed-directional text, but there's a lot more). (Note that all the places in HTML where human-readable text is stored as an attribute value are from older versions of the language; we've learned to stop doing that.) So as soon as you get past the basic stages of "here's some short text" and start actually wanting to do internationalization, you want to store it as a node structure, which'll be use-case specific, and you can lang-tag it with a property as Kat showed in their example, using whatever syntax your textual structure defines for this purpose.