Languages with hyphenated names can't be retrieved by name

[desophos]

Languages with a name key whose value contains a hyphen return a 404 Not Found response. This can be observed with language 1, ja-Hrkt, for example. I've checked other languages as well and tried variations on the name with no success.

Current behavior: the URL https://pokeapi.co/api/v2/language/ja-Hrkt returns a payload of "Not Found", status 404

Expected behavior: the response is the same as https://pokeapi.co/api/v2/language/1

Steps to Reproduce:

Navigate to https://pokeapi.co/api/v2/language/ja-Hrkt.

[jonbarrow]

@Naramsim I started to look into this, but found that I cannot replicate the issue locally with the current master branch? Are the latest changes not deployed?

When setting things up locally (using the non-Docker instructions at least), navigating to http://127.0.0.1:8000/api/v2/language/ja-Hrkt/ seems to produce the expected result?

{"id":1,"name":"ja-Hrkt","official":true,"iso639":"ja","iso3166":"jp","names":[{"name":"日本語","language":{"name":"ja-Hrkt","url":"http://127.0.0.1:8000/api/v2/language/1/"}},{"name":"일본어","language":{"name":"ko","url":"http://127.0.0.1:8000/api/v2/language/3/"}},{"name":"Japonais","language":{"name":"fr","url":"http://127.0.0.1:8000/api/v2/language/5/"}},{"name":"Japanisch","language":{"name":"de","url":"http://127.0.0.1:8000/api/v2/language/6/"}},{"name":"Japonés","language":{"name":"es","url":"http://127.0.0.1:8000/api/v2/language/7/"}},{"name":"Japanese","language":{"name":"en","url":"http://127.0.0.1:8000/api/v2/language/9/"}}]}

[Naramsim]

We don't use the Django server in production, we convert the entire API to static JSONs and serve them through a GCP function. Maybe the issue is somewhere else.

[jonbarrow]

I see. Is that process public or documented anywhere? I'm poking around this repo atm and can't seem to find where that happens. Production not matching what's in the repo definitely makes finding these sorts of issues harder

[Naramsim]

Everything is public and open source. You can read the website to find out how we deploy. On the 'about' page. There are other repos. The ones you need are api-data and deploy

[PraaneshSelvaraj]

Hi @Naramsim,

I’ve been tracing this through pokeapi, api-data, and deploy, and I think I have a partial understanding of the architecture, but I may still be missing something.

From what I can tell, in production some name-based language endpoints (for example /api/v2/language/cs/) appear to work only when a corresponding static path exists in the generated _gen output. The deploy repo looks like a pure proxy, and api-data seems to contain only ID-based folders, so my assumption is that any name-based paths are introduced during the static build step that produces _gen.

I tried to trace this further by running Ditto locally to reproduce the static build output, but I wasn’t able to get a clean end-to-end run (it kept failing). Because of that, I may be missing where this alias set is actually defined or generated.

What I could observe is that the alias set also seems to be partial (for example, cs works, while ja-Hrkt, and pt-BR do not). Locally, the Django API resolves these names correctly, which made me think this behavior is specific to the static pipeline rather than the backend itself.

Could you clarify where (and how) language name aliases are generated in production, or whether this partial behavior is intentional? I’m mainly trying to understand whether this is expected or something that could potentially be made more consistent.

[Naramsim]

Give me some days to recover from an illness and I'll try to give you all the necessary pieces of information

[PraaneshSelvaraj]

No worries at all, take care of your health 🙂

[Naramsim]

Hi! I tried to dig in. So, this CircleCI step generates an _gen.tar.gz file that contains both ids and names: https://github.com/PokeAPI/api-data/blob/7f6b2c2b5dc6a82b8cee71c0c184ad566d9b7c31/.circleci/config.yml#L32

I add the generated GZ here

And I think this below is the code that takes the ID and duplicates it as a name:

https://github.com/PokeAPI/ditto/blob/1df397a8e214d8e27a6204acde69a417a34dc33b/pokeapi_ditto/commands/transform.py#L52

Anyways, in the GZ file I see the names well-formatted though, so I think the error stems after this GZ generation.

This GZ then later is downloaded and uploaded to a GCP function here:

https://github.com/PokeAPI/deploy/blob/71cf4cb8d17331527683fce032cdd7dbc254c8ad/scripts/deploy.sh#L41

Could it be a capitalization issue? Instead of a - issue? We could try with just one entry (let's say converting ja-Hrkt to ja-hrkt)

[Naramsim]

I say this because we serve corrrectly other resources having dashes in their name, such as https://pokeapi.co/api/v2/pokemon/mr-mime

[Naramsim]

Well I defenitely think it's a case issue.

https://github.com/PokeAPI/deploy/blob/71cf4cb8d17331527683fce032cdd7dbc254c8ad/functions_v1/src/index.js#L14C38-L14C57

https://github.com/PokeAPI/deploy/blob/71cf4cb8d17331527683fce032cdd7dbc254c8ad/functions_v1/src/index.js#L32

Here we always lowercase so this is the culprit. Now, we have two choices: 1 don't lower the case in the function or 2 lower the case in the data.

I'm more inclined toward lowering the case of the data.

[PraaneshSelvaraj]

I think lowercasing the data itself feels like the right fix.

Could you give me viewer access to the GDrive file you shared so I can take a look?

[PraaneshSelvaraj]

Hey @Naramsim,

If we’re going ahead with lowercasing the data, I’d be happy to open a PR for it.

[Naramsim]

I already tried: #1378

[PraaneshSelvaraj]

@Naramsim Hey, I think this issue needs to be closed.

[Naramsim]

Yep, it seems they are accessible now: https://pokeapi.co/api/v2/language/ja-hrkt