Open iherman opened 5 years ago
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??
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.
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.
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.
I am not sure what the
Localizable
structure is for. Shouldn't there be an extravalue
for the text itself? Or is itLocalizableMetadata
on a text somewhere else?