Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Working with language strings #23

Closed
glenrobson opened this issue Jan 14, 2022 · 6 comments · Fixed by #164
Closed

Working with language strings #23

glenrobson opened this issue Jan 14, 2022 · 6 comments · Fixed by #164
Labels
upstream Issues caused by problems with upstream libraries

Comments

@glenrobson
Copy link
Contributor

I've been looking at language strings particularly with labels e.g.:

manifest = Manifest(id='http://iiif.example.org/prezi/Manifest/0', type='Manifest', label={'en': 'label'})

print (manifest.label)

The problem is the label is empty. This is due to the LngString class in the skeleton only containing pass.

The relevant part of the schema is:

"lngString": {
      "title": "Language string, must have a language and value must be an array.",
      "type": "object",
      "patternProperties": {
                "^[a-zA-Z-][a-zA-Z-]*$": {
               "type": "array",
               "items": { "type": "string"}
            },
            "^none$": {
                "type": "array",
                "items": { "type": "string"}
            }
      },
     "additionalProperties": false
},

from IIIF Schema#L11 and it seems pydantic is struggling with patternProperties and how to convert them into python.

Relevant discussions on pydantics:

Example lngStrings include:

# single language:
{
   'en': 'label'
}

# multiple languages: 
{
   'en': 'label',
   'cy': 'Welsh Label'
}
@glenrobson
Copy link
Contributor Author

We think this should work with pydantic:

{
    “type”: “object”
    "propertyNames": {
            "pattern": "^[a-zA-Z-][a-zA-Z-]*$"
      }
    “additionalProperties”: {
        “Type”: “array”,
        “Items”: {  “type”:”string” }    
     }
}

We are going create a small example and create an issue with pydantic.

@giacomomarchioro
Copy link
Contributor

It seems that replacing LngString with:

class LngString(Base):
    __root__: Dict[str, List[str]]

It works as expected.

I have opened an issue in koxudaxi/datamodel-code-generator#696.

@digitaldogsbody
Copy link
Member

I will see if it's viable to monkeypatch this fix

@digitaldogsbody
Copy link
Member

So far attempts at monkeypatching this have failed because of class inheritance - as we are patching in the helper classes as parents of the schema objects, anything they set (in this case __root__) is overridden by the value set in the schema object class.

@glenrobson
Copy link
Contributor Author

Decided on the call to edit the skeleton document until this is fixed in pydantic.

@digitaldogsbody
Copy link
Member

Skeleton edited - I will leave this issue open because it would still be better to find a sustainable fix that doesn't involve editing the skeleton file every time

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
upstream Issues caused by problems with upstream libraries
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants