Internationalization Comments on Widgets 1.0 Packaging and Configuration

The simple example in Section 7.2 still contains an error. The language tag for Spanish is "es", not "sp". It is shown correctly in the graphic but not the title of the section or elsewhere in the text.

Section 8.3 (Attribute Types) contains a subsection called "URI Attribute" which is relevant to our comment above. It says:

[[An attribute defined as containing a valid URI. A valid URI is one that matches the URI token of the [URI] specification or the IRI token of the [RFC3987] specification. The value of this kind of attribute is retrieved using the rule for getting a single attribute value.]]

This is problematic, since all URIs are IRIs, but not the converse. We think this should favor IRI and note the relationship to URI.

The <widget> metadata does successfully incorporate our comments that multiple languages should be allowed on those attributes that make sense with them.

its:dir appears in this document and is a good illustration of its proper use, as does xml:lang. See, for example, section 8.8.

The 'charset' attribute appears in the element <content> and appears to be properly specified

The <its:span> element appears in the document and appears to be properly specified.

In Step 5 of section 9.1, we find an arbitrary limit on locale identifiers (BCP 47 language tags):

Each item in the unprocessed locales must be a string shorter than eight characters, in lowercase form, that conforms to the production of a Language-Tag, as defined in the [BCP47] specification.

This limit is too short for even some simple language tags. Consider "zh-Hant-CN", which is given as an example in the document: it has 10 characters. This limit really should be removed. The eight character limit is on subtags.

its:dir appears in this document and is a good illustration of its proper use, as does xml:lang. See, for example, section 8.8.is limit really should be removed. The eight character limit is on subtags.

In this same step, substep 4 is unnecessary. It does save processing time, but it is not required for proper operation. Performing the specific change suggested also has the negative side-effect of altering the user's preferences ahead of the local configuration. The rightmost occurrence would be a better choice for elimination.

[1] There may be cases where span is also used to support xml:lang (not just dir).

[2] I think the example could be improved by having something inside the span with punctuation (eg. exclamation mark) or such, and maybe the description should be in English - otherwise you'd probably want to put the dir on the widget tag and have English in the span. Should I try to find another example ?

[3] "it allows authors to override the Unicode bidirectional algorithm by explicitly specifying a direction override, as specified in [BIDI]."

There is no link on [BIDI], and there is no [BIDI] reference at the bottom of the page.

[4] "it allows authors to override the Unicode bidirectional algorithm by explicitly specifying a direction override, as specified in [BIDI]."

=>

"it allows authors to set the base direction for the Unicode bidirectional algorithm, as specified in [BIDI]."

I propose this change because the dir attribute as you define it doesn't have the rlo and lro values that would mean 'override', it has only ltr and rtl, which define the base direction. I don't know if the 'as specified in...' bit is still relevant, since I don't know what that refers to.

[5] Any reason that you don't specify rlo and lro values recommend in the ITS spec? (They aren't use much, but I was wondering whether there was a particular reason that they aren't included.)

[6] "An empty value of dir is used on an element B to override a specification of dir on an enclosing element A, without specifying another direction. Within B, it is considered that there is no directional information available, just as if dir had not been specified on B or any of its ancestors (see fourth example below)."

We discussed this during the i18n telecon. We think having an empty value is a little odd, given that the direction has to be either ltr or rtl. (For instance, it has no real effect or meaning in the final example below this text that we can detect.) We also think that is may cause some unintended problems for embedded text by creating inappropriate embeddings. We suspect that what you really need is something that we are about to propose for HTML5 (in a working draft that should hopefully be published as FPWD today), ie. a bdi attribute (bidi isolate). It will be a little while before that is a stable document, however.

In the meantime, our suggestion is that you drop the empty value for dir, and revisit this in a later version of the spec.

[7] The first example looks a little out of kilter wrt markup. (if you need help to sort it out just shout)

Who provided the Persian translations? (I'd like to suggest some alternative examples, but I can't translate into Persian.)

The characters in <name xml:lang="ko">??? ???</name> have become corrupted.

I propose:

"which is what ITS did" => "which is how ITS tags were formerly specified"

The ITS specification doesn't require use of a namespace, and it would be good to change this wording so that that idea is not incorrectly reinforced.

The last example shows an empty value for the dir attribute which is not specified elsewhere. I believe this example is a hark-back to an earlier draft that wasn't removed when we decided to remove dir="".

The Chinese characters in <name xml:lang="zh-cn">?????</name> have become corrupted.

Note: I am marking this as closed straight away, since I believe it was not spotted early enough to be corrected. I am recording it here, however, in case it is useful for a future discussion.

xml:lang should really only be used to indicate the language of content in an element. If you need to indicate something else, such as the locale for that content for localization purposes, you should use a different attribute. See <a href="http://www.w3.org/International/questions/qa-when-xmllang">xml:lang in XML document schemas</a>. Here not only is xml:lang used incorrectly for that reason, but xml:lang="" is defined to mean that this is the default locale, whereas the XML spec says that that should mean that the language of the content of that element is undetermined (see Tagging text with no language [http://www.w3.org/International/questions/qa-no-language]).

It would have been better to use an attribute such as locale='en', locale='fr', or locale=''. This would be used alongside xml:lang. The former would indicate how to process the document, the latter would be useful for things like spell-checking, voice browsers, etc that need to understand the language of the text they are processing.

This would simplify the code in the example in section 7.16.1. Instead of:

<name xml:lang="" dir="ltr"><span xml:lang="en">GPS Weather!</span></name>

you could simply use

<name locale="" xml:lang="en" dir="ltr">GPS Weather!</name>

Language tags are presented as lowercase. While case has no meaning in language tags, they are typically canonicalized (and are recommended to use) the case conventions in BCP 47. See http://tools.ietf.org/html/bcp47#section-2.1.1

There is an example of the empty language tag with the comment "The user agents will treat this as unlocalized content." This should be "user agent" singular. More importantly, there should be a distinction between "unlocalized" and "non-linguistic" or "undetermined" or at least "default content" (which is what you mean). Note that the tag "und" represents text whose language cannot be determined. I would suggest "default content" here (and elsewhere).

There is a term "i18n string". We typically do not like the term "i18n" to be used for anything (my car's license/number plate and my .sig are exceptions to this rule ;-)), and, in this case, it doesn't convey any meaning. I would prefer the term "localizable string", "localizable", or "language string".