• The widget must support "custom" values, similar to what currently happens with the globe coordinate precision. If there is an URI the widget does not know, it displays and returns the URI as it is.
• The widget must (otherwise it's pointless to have it in the first place) allow searching for units by name, e.g. typing "km" should work. This means it's either a "dumb" item selector or a pre-defined list.
  • Where should this list live? Should the community be able to maintain it (e.g. via a message)?
  • How are these pre-defined units localized?
• Should we restrict the list of allowed units in the API? This may be a good starting point. It's much, much easier to drop such a restriction later than to install one (and clean up data).
• Is it possible to support localization for all (local) Wikidata URIs?
• Do localization with labels (probably easier and "the right thing to do") or with the unit symbol property (P558)?
• Where is the stuff required for unit conversion stored and how does the widget know about it?

In T77982#1189316, @thiemowmde wrote:

• The widget must support "custom" values, similar to what currently happens with the globe coordinate precision. If there is an URI the widget does not know, it displays and returns the URI as it is.

Yes

• The widget must (otherwise it's pointless to have it in the first place) allow searching for units by name, e.g. typing "km" should work. This means it's either a "dumb" item selector or a pre-defined list.

It would be an item selector. That also searches over aliases, and "km" would most likely be an alias.

• Where should this list live? Should the community be able to maintain it (e.g. via a message)?
• How are these pre-defined units localized?

I would like to avoid a pre-defined list for the baseline implementation. This is actually harder to implement, as far as I can tell.

• Should we restrict the list of allowed units in the API? This may be a good starting point. It's much, much easier to drop such a restriction later than to install one (and clean up data).

We do not have such a restrictions for calendars or globes. I don't think we should introduce it here. We could, of course, but that would make the selector more complex.-

• Is it possible to support localization for all (local) Wikidata URIs?

Sure, why not? Just use their label (with fallback).

• Do localization with labels (probably easier and "the right thing to do") or with the unit symbol property (P558)?

Just the labels for the baseline. "Symbols" support should be added later (P558 would need to be migrated to multilingual text).

• Where is the stuff required for unit conversion stored and how does the widget know about it?

In the baseline, the widget doesn't know about it. In fact, for now, there is no conversion.

Later, we'd have an internal service for unit conversion, and an API module for accessing it. The widget could then tell the user whether the unit they entered is a well known base unit, a convertible unit, or somethign unknown (which means the value can not be indexed/normalized/compared/queried).

@thiemowmde. The list will be very long: we have to think a way to avoid scrolling dozen of units to find the correct one. One possibility will be to have for each contributor a personal list which can be uploaded from a personal page like user:User/common.js. The widget compares then the selected value with the official and complete list of units maintained by the dev team (or somebody else) and if there is a match, proceeds to the next step.

We have to find a better way than having each user maintain a list of their preferred units. This is already causing a lot of headaches for the babel box config.

I agree that having such a widget is necessary as fall-back for entering units--using an entityselector derivative for that purpose probably is a sensible solution.
However, using two inputs results in some awkward interaction--especially when entering multiple values. The software should be capable of making a proper best guess on a string that contains value and unit. Such a best guess can be displayed as preview with an option for the user to adjust the unit (using something like the enhanced entityselector described).

Shall allow suggestions based on correlation ("which units are typically used with this property?")

These could really be constraints defined by Statements on Properties specifying sets of allowed units. Consequently, the number of units that may be assigned to a value of a Property would be a small set anyhow and there is no need for something like user preferred units or intelligent unit suggestions.

The widget must support "custom" values, similar to what currently happens with the globe coordinate precision. If there is an URI the widget does not know, it displays and returns the URI as it is.

Agree, but, in the user interface, displaying the Label instead of the URI probably would probably be more sensible.

Where is the stuff required for unit conversion stored and how does the widget know about it?

Could that not be stored using Statements on Properties?

In T77982#1202894, @Snaterlicious wrote:

I agree that having such a widget is necessary as fall-back for entering units--using an entityselector derivative for that purpose probably is a sensible solution.
However, using two inputs results in some awkward interaction--especially when entering multiple values.

The same as picking a globe or calendar model.

The software should be capable of making a proper best guess on a string that contains value and unit. Such a best guess can be displayed as preview with an option for the user to adjust the unit (using something like the enhanced entityselector described).

That would be nice, but would block us on a mechanism for (localizable?) "unit symbols". It would be good if we could move forward without being blocked on that.

Shall allow suggestions based on correlation ("which units are typically used with this property?")

These could really be constraints defined by Statements on Properties specifying sets of allowed units. Consequently, the number of units that may be assigned to a value of a Property would be a small set anyhow and there is no need for something like user preferred units or intelligent unit suggestions.

That would prevent us from using obscure or historical units. We said that we want to support these, so we can stay true to the source. The number of units you'd have to list for something like "length" or "height" would go into the hundreds.

The widget must support "custom" values, similar to what currently happens with the globe coordinate precision. If there is an URI the widget does not know, it displays and returns the URI as it is.

Agree, but, in the user interface, displaying the Label instead of the URI probably would probably be more sensible.

If it's a wikidat (or local wikibase) URI, the label should be shown. But internally we support any URI, and the UI must be able to copy with any URI. If it doesn't know how to get the label, it should just show the URI in full.

Where is the stuff required for unit conversion stored and how does the widget know about it?

Could that not be stored using Statements on Properties?

That would be hell to keep consistent, and every change to a conversion factor would require us to rebuild the query index. Not a good idea, I think.

I am not perfectly sure what is expected on that from my side.

1. I am pretty sure there is a need for some kind of dedicated unit selector (although I am pretty sure it should not be a default interaction element).
2. The decision on whether to implement basic functionality fast without solving interaction concerns or whether to iterate an interaction vision first and then implement accordingly is up to PM.

Personal comment:
I totally understand the temptation to implement the functionality right away and such has been common practice ever since the Wikidata project started. However, in my opinion, most of the time, this led to unforeseen consequences, strange interaction behaviour, user complaints when changing the interaction later or simply deferring proper interaction implementation to "when there is time" (never) and/or so on. Consequently, I will decline the decision to do both in parallel since an interaction concept will not be installed later on (at least not in the near future) as it has been in the past. Decision is up to PM.

@Snaterlicious: Can you please clarify where you see interaction issues with a unit selector?

• No proper copy-pasting which is a big disadvantage for things like such.
• It is quite natural to type a string that contains value and unit. Two input elements instead of where one would be natural is irritating. Placeholders would ease the situation a bit, but the need to tab between inputs for something that is normally typed in one go is kind of awkward.
• Being aware about form/page navigation using the TAB button involves a certain degree of expertise.
• Contradicting to natural position of some units, e.g. $10 vs. 10$.

In my opinion, it is such disadvantages and awkward interaction that repels potential contributors right from the start. Deciding on implementing an interface exclusively based on an unit selector would support giving such an impression once again by adding to the pile.

Two questions about P558, unit symbol property:

1. When this is made multilingual, is it possible and desirable to mark it as "all languages", which is the case for symbols (but not names) that are included in the International System of Units?

2. What about symbols that include a superscript, such as the symbol for square meter, which I cannot write here.

@Snaterlicious. If you take account of the uncertainty, the copy-paste is not more so important: value + uncertainty + unit, I don't know
if any copy-paste will respect the same interval between the different elements, if the symbol for uncertainty will be recognized, do we need to handle the scientific notation,....

@Jc3s5h

1. Unit symbols are not "all languages". While many countries/languages use the standard km/h, America uses KPH, and Russia uses км/ч. But I agree that an "other languages" fallback would be nice, using English for that (as MediaWiki does) isn't really great.
2. For the common subscripts and superscripts, there are unicode characters that can be used, see https://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts. For units we'll mostly need U+00B2 (superscript 2) and U+00B3 (superscript 3). Square meter would be written as m².

In T77982#1524501, @daniel wrote in part:

2. For the common subscripts and superscripts, there are unicode characters that can be used, see https://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts. For units we'll mostly need U+00B2 (superscript 2) and U+00B3 (superscript 3). Square meter would be written as m².

I see no mention in the Wikipedia article of an ability to provide a negative superscript. This is highly desirable for writing units.

In T77982#1524580, @Jc3s5h wrote:

I see no mention in the Wikipedia article of an ability to provide a negative superscript. This is highly desirable for writing units.

SUPERSCRIPT MINUS (U+207B)?

In T77982#1524674, @Ricordisamoa wrote:

In T77982#1524580, @Jc3s5h wrote:

I see no mention in the Wikipedia article of an ability to provide a negative superscript. This is highly desirable for writing units.

SUPERSCRIPT MINUS (U+207B)?

I have no success entering any of these superscript numbers on my Windows 8.1 computer with Firefox. Also, using the Microsoft Charmap program, I am unable to find any font that includes the superscript minus.