Localizable structure

[iherman]

I am not sure what the Localizable structure is for. Shouldn't there be an extra value for the text itself? Or is it LocalizableMetadata on a text somewhere else?

[aphillips]

The structure is a WebIDL dictionary. cf. https://heycam.github.io/webidl/#idl-dictionaries

Effectively what our document says is: if you define a natural language string field, you can use Localizable in your WebIDL definition. The effect is that your object "someStringValue" (if it is "Localizable") has a text attribute, such as a USVString, plus at least two fields language and dir. Probably needs more explanation??

[iherman]

The structure is a WebIDL dictionary. cf. https://heycam.github.io/webidl/#idl-dictionaries

I understand that. But I think it is way cleaner to say something like

dictionary Localizable {
    DOMSgring value;
    DOMString lang;
    TextDirection dir = "auto";
};

i.e., to produce an interface with the value and the respective attributes. I do not see how you would you would, otherwise "assign" these attributes to a text in a clean way.

It may be a matter of taste, of course. Maybe both approaches should be proposed, and it then depends on the specific API/JSON structure which is better.

[aphillips]

I think we're talking past one another. But I take you point. Adding value as a field in the dictionary would make the structure completely consistent and specs could just define items as Localizable rather than dinking around with joining Localizable to local definitions. Note that the text has been handwaving about what the WebIDL is for and above commit is me starting to tidy that up.

[marcoscaceres]

There are two use cases for Localizable, however. Consider, one might want to have:

dictionary MyThing extends Localizable {
   DOMString message;
   unsigned long someNumber;
}

Which, in JS would be:

const thing = {
   someNumber : 5,
   message: "hello",
   lang: "en",
}

Having the value member predefined denies the MyObject from having a better named dictionary member message.

As opposed to:

dictionary MyThing {
   Localizable message;
}

Which results in the somewhat more verbose:

const thing = {
   someNumber : 5
   message: { value: "hello", lang: "en" },
   lang: "en",
}

So, it's nice to have the generic Localizable to utilize when there is a generic value member, but it's also nicer to the flatter structured resulting form extending Localizable. The tradeoff being clarity to what dir, lang apply to, which is unambiguous in the case of the current Localizable.

An alternative I guess is:

typedef (Localizable or DOMString) BidiText;

dictionary MyThing {
    BidiText message;
}

Which provides flexibility to use either.