The arguments above also apply to formatting: we need formatting in the backend, including support for localization (and even personalization, in the case of date/time format).

As for parsing, it may be ok to only support the parsing of canonical formats in the backend, and let the frontend deal with handling the quirks of human input.

Rough proposal:

• create wbsnakvalueparser for parsing snak values based on property ID and/or data type ID. This should have an option to apply validation, too.
• create wbsnakvalueformatter for parsing snak values based on property ID and/or data type ID. This needs to support different kinds of desired output, too (plain text, html, etc).

Note that the modules parsevalue and formatvalue provides by DataValuesCommon are not sufficient, since they can not handle DataType specific formatting or constraints, nor do they support different output formats like html.

• Geo is using backend parsing;
• Quantity is using backend parsing;
• Time is still parsed in the frontend;

Sorry, accidentally closed this one..

Current status is that formatters are done, parsers are wip and validation is not even started.