W3C   W3C Internationalization (I18n) Activity: Making the World Wide Web truly world wide!

Related links

Other reviews

Review radar

Core WG home page

Manage page

Internationalization Comments on Widgets 1.0 Packaging and Configuration

Date of latest comments: Jul 2009

The WG column indicates whether these are comments on behalf of the Internationalization Core WG. The "Owner" column indicates who has taken the responsibility of tracking discussions on a given comment. Orange shading signifies that the comment is unresolved.

We recommend that responses to the comments in this table use a separate email for each point. This makes it far easier to track threads. Click on the icons in the right-most column to see email discussions.

You can edit this page by clicking on Edit Table (right), then using the buttons that appear in the right-most column and the forms below the table. It doesn't actually change the text on the server. For that, hit the Create Source Code button near the bottom of the page and use the resulting text to edit the page or send to someone for editing.

ID Location Subject Comment Owner WG Ed. /
17.2Wrong language tag

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.

APYE Link to mail thread
2Section 8.3Clarify IRI/URI

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.

APYE Link to mail thread
3Section 8.3Widget metadata

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

APYE Link to mail thread
4Section 8.3Various positive observations

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.

APYE Link to mail thread
5Section 9.1, step 5Too small arbitrary limit on locale id

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.

APYS Link to mail thread
6Section 9.1, step 5Use of its:dir

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.

APYE Link to mail thread
7Section 9.1, step 4Step not necessary?

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.

APYE Link to mail thread
87.16. The span ElementSpan also supports xml:lang

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

RI-E Link to mail thread
97.16. The span ElementSpan example

[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 ?

RI-E Link to mail thread Link to mail thread
107.16. The span ElementBIDI reference missing

[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.

RI-E Link to mail thread
117.16. The span ElementNot overriding the UBA

[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.

RI-E Link to mail thread
127.5.2. The dir AttributeNo RLO or LRO

[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.)

RI-E Link to mail thread
147.5.2. The dir AttributeDir empty value

[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.

RI-S Link to mail thread
157.5.3. Examples of UsagePersian dir examples

[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.)

RI-S Link to mail thread
168.5.2Korean text corrupted

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

RI-E Link to mail thread
17Changes since last pubnWhat ITS did

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.

RI-E Link to mail thread
187.5.3Empty dir value

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="".

RI-E Link to mail thread
197.12.4Corrupted Chinese text

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

RI-E Link to mail thread
207.16.1Misuse of xml:lang for localization flag

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>

RI-S Link to mail thread
21undefinedLanguage tag case

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

AP-E Link to mail thread Link to mail thread
228.4Default content

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).

AP-E Link to mail thread
239.1i18n string

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".

AP-E Link to mail thread

Edit/create a comment

New comment?    ID:     Status:

Location in document:    URI:


Comments: Inline markup ok. Always escape < and >.

Owner: Working Group approved?    Editorial/Substantive?

Links: Prefix: Subject: List:

Source dump

Page template by Richard Ishida (ishida@w3.org).