Wherever human-readable strings exist, they need to be localisable

No argument

Machine-readable terms which are part of a schema like OnOffSwitch do not need to be localised.

Agreed. An example in the Web Thing Description draft includes Light and OnOffSwitch schemas. It contains these human readable strings which would require localization:

On/Off
Whether the lamp is turned on
Brightness
The level of light from 0-100
Fade
Fade the lamp to a given level
A web connected lamp
Overheated
The lamp has exceeded its safe operating temperature

The question I have in mind is whether there should many, if any, human-readable strings in the Thing Description. That stems from an understanding that the focus is machine-to-machine communication. Obliging the Thing to provide all user interface labels is a broader scope increases the skills and effort require to deploy a Thing.

Should the vendor of a lightbulb be required to provide localized strings in the firmware for every possible language where that bulb will be deployed? There are very real costs associated with the requirement:

Generating those correctly is non-trivial. Most companies building such products will be obliged to outsource that at some expense.
The localization data increases the size of the firmware. Often in an embedded device the ROM / flash storage does not have much free space, as that would be an unnecessary expense.
If the entire localization table is to be provided (e.g. MultiLanguage), the transfer time of the thing description is increased. If content negotiation is used, it adds implementation complexity fo the device.
Updating the firmware of a Thing is possible but difficult, and consequently expensive. Updates may now be required to correct localization errors and two add new language support.
For machine-to-machine scenarios (e.g. a light bulb and light switch communicating directly) there is no need for the human-readable strings. They only add overhead to resource constrained devices.

The W3C Thing Description does not appear to support schemas, unlike Mozilla WebThings (forgive me if I have gotten the precise names wrong here). In the absence of schemas, some human readable strings are necessary to build a human interface. Schemas, such as OnOffSwitch encapsulate a well defined, common functionality. The absence of a schema in the Thing Description is expedient for prototyping, but ultimately commercial products are likely fall into one or more schemas for their core functions.

The presence of human readable strings in the Thing description pulls in a large number of issues that increase the complexity of deploying compatible device and implementing compatible clients for those devices. The schema mechanism, in principle, allows these human readable strings which require localization to be largely, perhaps entirely, eliminated. This is because the client can take sole responsibility for providing localized strings for the well known device schemas it supports. As defined now, there is extra work for both devices and clients and, complex problems remain even after that work is done.

Consider a mobile app which wants to provide a remote user interface for the OnOffSwitch devices in the home. This app has a focused purpose, in contrast to the Mozilla gateway which is designed to support all Things, whether or not they conform to a schema. The app will be localized to the set of languages its author selects. Is the app required to use the localized strings from the device? If yes, does that mean a switch with only French strings cannot work with an app that has only English support. If no, does the manufacturer of the switch expect this? If the app has its own terminology for On/Off, is it acceptable to override the values from the switch? Further, in a home with lights from several vendors, the labels for identical operations may be different.

Apologies for the length of this comment. Perhaps I have misunderstood the scope, and that a design goal of the Thing Description is to facilitate the building of general purpose user interfaces to interact with unknown devices. If that's the case, it might be made more clear by the specifications, which only minimally address how these strings will be used in a client user interface. Of more concern to me, it seems to raise the bar on the hardware and organizations which can successfully deploy devices using this proposed standard.

Localisation (l10n) #127

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions