Languages displayed incorrectly on book page

[seabelis]

Problem

Languages are not displayed correctly on book pages.

Reproducing the bug

1. Go to ...https://openlibrary.org/books/OL53538705M/GCSE_Mathematics
2. Do ...see the language displayed as /languages/eng

• Expected behavior: Language should use label, such as English
• Actual behavior: path displayed instead of label

Context

• Browser (Chrome, Safari, Firefox, etc):
• OS (Windows, Mac, etc):
• Logged in (Y/N):
• Environment (prod, dev, local): prod

Breakdown

Implementation Details (for maintainers)

Requirements Checklist

• [ ]

Related files

Stakeholders

---

Instructions for Contributors

• Please run these commands to ensure your repository is up to date before creating a new branch to work on this issue and each time after pushing code to Github, because the pre-commit bot may add commits to your PRs upstream.

[Saad259]

Hey @seabelis I just traced this to templates/type/edition/view.html where line 279 renders the language using thingrepr, which seems to output the raw database path instead of the human-readable name. Line 330 in the same file already handles languages correctly though, using get_language_name. So the fix would be replacing thingrepr on that line with ', '.join(get_language_name(lang.key) for lang in edition.languages). Would be happy to open a PR for this!

[bhardwajparth51]

I cant reproduce this locally and on the testing server as well
local:

test server:

[Saad259]

Same here locally, but the bug is confirmed on prod at the URL in the issue. The root cause still seems evident from the code, although I'll be happy to be corrected on that. Keen to get feedback on my approach before the PR goes up :)

[bhardwajparth51]

Local dev always has web.ctx.site properly available, so the bug gets masked there — it only surfaces in production, which is why I couldn't reproduce it locally.

After digging into this more, I think the root cause traces back to PR #11455. That PR made two changes to utils.py:

1. get_languages() was migrated from web.ctx.site to async_utils.site.get() — a ContextVar that isn't guaranteed to be set in all production code paths
2. user_lang was moved out of get_language_name() into a parameter

worksearch/code.py was updated in the same PR to explicitly pass web.ctx.lang or 'en', but type/language/repr.html wasn't touched. So when a book page renders its language field, repr.html still calls get_language_name(page.key) — passing a string — which then has to go through get_languages() → async_utils.site.get(). If that ContextVar isn't set in that code path, the lookup fails and falls back to the raw key.

The fix is a one-liner in repr.html — pass the already-loaded page Thing directly instead of page.key. Since page already has .name available, it skips the get_languages() lookup entirely and the ContextVar issue doesn't come up.

One broader thing worth flagging: get_languages() uses @functools.cache (permanent, process-level) alongside async_utils.site.get() (per-request ContextVar). If an empty result gets cached, it'll persist for the life of the process. Might be worth a follow-up issue — noticed this pattern while working on the FastAPI endpoint migrations.

Happy to open a PR if this approach sounds reasonable. cc @RayBB — since this traces back to #11455, figured you'd know if there was a reason repr.html was left out of that update.

[tfmorris]

Local dev always has web.ctx.site properly available, so the bug gets masked there — it only surfaces in production, which is why I couldn't reproduce it locally.

That sounds like a fatal flaw in dev environment setup, causing untested code (e.g. FastAPI) to get pushed to prod.

So the fix would be replacing thingrepr on that line with ', '.join(get_language_name(lang.key) for lang in edition.languages)

Hardcoded string concatenation is not localizable. This should be done in a way that supports I18N.

[cdrini]

Hello, we were experiencing a slurry of debilitating performance issues yesterday, some of which seemed to be database related. And briefly the get_language_name method showed up as a performance bottle neck. So we intentionally temporarily disabled the database request necessary for that method in order to restore service. We're still investigating what could have happened, but no code change is necessary here just yet unless we make the change permanent.

See #12077 , which I will be filling out today.

This is also why this bug isn't reproducible locally. Also, all fastapi changes have undergone extensive testing before going to production. Although note that it is a complex rewrite, especially the one that went out last week, so there will be some bugs that make it through.