Fix: Using translated language name on language page titles

[Saad259]

Closes #12005

Technical

The language page template (openlibrary/templates/type/language/view.html) was using name = page.name which always fetches the English name, ignoring the name_translated field.

The fix replaces this with name = get_language_name(page, get_lang() or 'en'), using the existing get_language_name utility in utils.py which looks up the correct translation from name_translated based on the user's current UI language, with a fallback to English if no translation is available.

Testing

1. A unit test for get_language_name has been added to openlibrary/plugins/upstream/tests/test_utils.py covering three cases:
   • No name_translated field at all (falls back to name)
   • Translation found for requested language
   • Translation missing for requested language (falls back to name)
2. To verify manually, switch OL UI to a non-English language and visit any language page e.g. /languages/fre and the title and name should appear in the selected language.

Screenshot

N/A - Unable to verify visually locally as dev data set does not seem to have name_translated populated on language records.

Stakeholders

@cdrini

[tfmorris]

Thanks for tackling this! You should be able to update your dev instance's language data for testing purposes by going to e.g. languages/fre.yml?m=edit and adding

name_translated:
    fr:
    - français

and similarly for languages/ger.yml?m=edit

I didn't test it, but, by inspection, there are a few other places on the page where the translated version of the language are needed instead of page.name.

Also, the adding of the Deprecated tag can't use string concatenation to allow for internationalization.

[Saad259]

@tfmorris Thanks for the feedback! I've addressed all the suggestions:

• Fixed the remaining page.name usages
• Updated the deprecated string to use a proper i18n format string and ran i18n-messages extract to add "%(language)s deprecated" to messages.pot.

In relation to the test assertion, I kept 'French' for the fre case intentionally since that test is specifically covering the 'no name_translated field at all' fallback path. Changing it to français would require adding name_translated to the fre fixture, which would make it test the same path as the ger case. Happy to reconsider if you think that is the wrong approach though :)

[tfmorris]

In relation to the test assertion, I kept 'French' for the fre case intentionally since that test is specifically covering the 'no name_translated field at all' fallback path.

Understood. That sounds fine. The production label is "French / français" but it looks like that has drifted from what's in languages.page (which I just discovered the existence of). If that gets updated, it'll also solve your dev data issue with the missing translations.

It looks good from my point of view, but you'll still need to get someone with commit privileges to review and merge.

[cdrini]

Tested here and works: https://testing.openlibrary.org/languages/fre?lang=de

[tfmorris]

Tested here and works: https://testing.openlibrary.org/languages/fre?lang=de

That returns 401 Authorization Required. Ditto for the home page.

[cdrini]

The testing server is now behind an access key in response to excessive crawling of it. Just emailed you the key.

[tfmorris]

I missed that the last mention on the page had been overlooked when I did my previous review. Sorry!

[tfmorris]

Suggested change

	<span class="tag">$name</span>

This needs to be either $name or $page_title

[tfmorris]

Oops, looks like the suggestion markup is broken. That replaces the $page.name, if it's not obvious.