Is test pkg-lang_but_not_content checking package document language?

[mattgarrish]

There is no language declared in the HTML file in this test, so the reading system/webview is going to apply some language to it to resolve the q tags.

How do you determine the language applied comes from the package document and not from a default language for the reading system/webview?

Wouldn't a French tester possibly get French quotes because that's what their app defaults to?

[iherman]

In fact, the HTML spec is silent on this, and there may be browsers that do not put any quote marks around the content. The MDN page says "Most modern browsers implement this by surrounding the text in quotation marks."

So, indeed, the test is a bit shaky... But I did not find any other way to visually check the language setting. Should we add something into the content of the test warning to that effect for French readers?

[mattgarrish]

Why do we care what a reading system does when the language isn't specified in the content? Isn't it perfectly acceptable in that case to use whatever information it can glean either from the publication or the app environment, assuming it doesn't have a built-in default?

The issue, to me, is that the language in the package document not be used in place of language specifications in the content. So the requirement/test should only check that an explicit language declaration is not overridden, no?

Setting language in the content is already a key consideration for accessibility, so I'm not sure we even need to worry so much about this. It was more a concern in 2010 when everything was new and we didn't want people getting confused about what the language settings were for. It's probably enough to note to authors that the language in the package document is not a realiable or accessible way of handling the language of content documents.

[iherman]

Now you are talking about changing (in a minor way) the spec:-) Do not forget that, per the language tag spec, the value of "unknown" is perfectly fine and that is what the browser is supposed to have (e.g., in the case of the tests) even if, in practice, that does not make too much sense...

I am open to change the spec text, b.t.w., by only specifying that content document's language setting has precedence over the package's, and that if there is no language setting in the content document the RS does what it wants. My only question is, though: is it worth the trouble changing this?

[mattgarrish]

I don't want to rewrite it, but isn't it weird that we're straying into handling unknown scenarios in this one case? It's okay to assume information that's possibly less relevant, like from the device, but not to assume any information tied directly to the publication?

I'd expected the rule would be more like:

Reading systems MUST NOT override the language or the base direction of a resource with information expressed in the package document (i.e., in xml:lang and dir attributes, in hreflang attributes on link elements, or from dc:language elements [epub-33]). Refer to a resource's formal specification for more information about how to handle the absence of explicit language or direction information.

[iherman]

Technically what you write is fine. I am not sure that a cursory reader would realize that, say, the language value is always "set" for an HTML content, let that be to the value of "unknown" in case no explicit declaration is provided. Maybe this could be made explicit here because, after all, that is the situation that is really non-obvious.

As for the test, ie, the original issue: I think what I would do is to leave everything in place but put a warning into the test result description that there may be a discrepancy if the locale of the RS is set to French, because a RS may use that as a default, ie, the test should be run with a non-french locale. WDYT?

[iherman]

Closed by virtue of the (merged) PR #223.