FlavorText documentation is incorrect

[heathercallear]

The documentation for the FlavorText type does not match its schema.

All referenced schema are from PokeAPI / api-data in the data/schema/v2 folder.
I have checked that the referenced schemas match the API results (for at least an id of 1).
The examples given in the documentation do match the schemas, so would not need changing.

Issue details

FlavorText is specified as having a version field, when most references to it do not have one.

The FlavorText type is documented as having three fields:

• flavor_text
• language
• version

FlavorText is used in three endpoints (all under the field flavor_text_entries) in the documentation:

• ContestEffect
• SuperContestEffect
• PokemonSpecies

In the contest-effect and super-contest-effect endpoints, the value under flavor_text_entries does not have a version field (ie. it only has flavor_text and language fields).

In the pokemon-species endpoint, the value under flavor_text_entries does have a version field, so matches the online documentation.

Suggestion

Making a new VersionFlavorText type for use in the PokemonSpecies endpoint, and changing the FlavorText type to not have the version field.

The naming of this type would match the pattern of VersionGroupFlavorText type (which has the fields text, language, and version_group).

VersionGroupFlavorText is also only used once (in the item endpoint), so it seems reasonable to add VersionFlavorText in the utility section along with it. Alternatively, it could be added in the Pokemon group under the PokemonSpecies endpoint.

This would affect:

• /src/docs/utility.json
  • Remove version field from the FlavorText type response model (link to line)
  • Add a VersionFlavorText type identical to the current FlavorText type (with flavor_text, language, and version fields) (link to line)
• /src/docs/contests.json
  • Change type of flavor_text_entries field in the PokemonSpecies response model from list of FlavorText to list of VersionFlavorText (link to line)

[heathercallear]

As a relevant note, I think VersionGroupFlavorText type may only be used once because the almost identical MoveFlavorText type is used for the flavor_text_entries field of the Move endpoint.

They are different, but only because the text field is used in the VersionGroupFlavorText type, whereas the flavor_text field is used in the MoveFlavorText type. Both types have the same documentation (except for a "that" instead of a "which") and appear to have the same usage.

So a new VersionFlavorText type would possibly belong under the PokemonSpecies endpoint (link to line), with the name PokemonSpeciesFlavorText (to match the naming pattern of MoveFlavorText).

Adding a PokemonSpeciesFlavorText type under the PokemonSpecies endpoint would match any type that is only used once (and does not have its own schema file) going underneath the relevant endpoint (as suggested by the existence of the MoveFlavorText type and the new type not being in the schema).

However, adding a VersionFlavorText type under the Utility group (as originally suggested) would match a non-specific type going underneath the Utility group (as suggested by the existence of the VersionGroupFlavorText type).

I'm not sure which is the preferred way, but it seems relevant for deciding which option is most consistent with the rest of the documentation.