Page MenuHomePhabricator

Allow to store multiple form representations using the same language code
Closed, DeclinedPublic13 Estimated Story Points

Description

TODO: define the behaviour in the UI @Lydia_Pintscher, otherwise this would be only about the internal data strcture, and the data structure exposed to users (API or special pages).

Note that as of 2018-03-19, the data structure used for internal storage of the lexeme data is assuming there only a single form representation for a given language code.

The possible data structure used could look like below:

"L560": {
      ...
       "forms": [
           {
                "id": "L560-F1",
                "representations": [
                    {
                        "language": "en",
                         "value": "colour"
                    },
                    {
                        "language": "en",
                         "value": "color"
                    }
                ],
                ...
            }
            ...
       ]
    ...
}

For the existing data stored in the database of the demo system, and possible other development instances, the conversion of the data could be provided by adding the needed functionality to LexemeSerializationUpdater (if found necessary).

Pointers:

  • FormSerializer is the service generating the structure stored in the database, and also used e.g. by get entities API action

Event Timeline

RazShuty set the point value for this task to 13.Mar 21 2018, 12:40 PM

T190906 duplicates the problem mentioned here in that the structure exposed to / expected from the users in wbeditentity (a, no doubt, public end point) will thereafter also not "Allow to store multiple form representations using the same language code", and cement it in a way not resolvable in a backwards-compatible fashion.

Having thought about it again, I've changed my mind again and I recommend to not change any of data structure. In other words, to use a "map" in both "internal" and "external" data structure.

Some notes:

  • if willing to assure extensibility of the external data structure, it could use a list of "serialized representations"/"serialized terms" instead of language-code-indexed map. As for now there is only a single representation per language code allowed, for the time being there would need to be a validator in place disallowing storing objects with duplicate language keys. If change in the data model would happen, the validator would be dropped, and there would be no need for changing other code as the data structure would not change.
  • only changing the internal structure, no matter whether from map to list, or from list to the map, would always involve adding B/C code for reading the data in the wrong format. While meaning the extra code to maintain, it does not seem to be too much of a burden to maintain. Still, the general hygiene would suggest to not change the internal data structure too often.
  • the limitation of the representation list to only allow one entry per language code is based on the assumption, that in general (tm) there will be the obvious distinctive criterion between two variants, and it would be reflected in the language code. It could be there are case where such distinctive factor is difficult to recognize, or name. In such cases modeler might end up using the arbitrary language code just for the sake of making the distinction. My gut feeling is that such cases might happen to be more often then in cases of labels of items or properties, where they're rare if not close to non existing. But this being only gut feeling, and me failing to come up with any "real" counter examples to the map approach, that seems to be overly cautious/conservative thinking. Therefore, I decided to not pursue change to any of the data structures discussed here.
  • Following the above point, it seems that sticking to the TermSerializer/Deserializer as a service for reading/writing the data structure is a reasonable choice. Introducing custom serializers seems to be an effort not justified by the value it would bring (given there are no objective reasons to assume the data structure is going to be changed to less restrictive).

The decision documented here is to be remember as mine, made with my free will, on April, 11th 2018.

ooops, I indeed wanted to closed this as declined, same with the other one.

@WMDE-leszek If there _can_ be only one representation per language, do we have a story to explain that to the user in the front end? There seems to be some client-side validation going on (grayed out save button) to ensure that pairs of value-and-language are unique, but a unique language is not enforced...

Not to my knowledge. @Lydia_Pintscher should chime in here.

Good point. Not yet. Will create one.