Page MenuHomePhabricator

Consider replacing mkdocs-material theme translations with our own data
Open, Needs TriagePublic

Description

In T309113: Static pages fail to build when the active locale is not also supported by mkdocs-material theme we found out that the l10n system that the mkdocs-material theme has invented for itself raises unhandled exceptions when the theme's language setting is set to a language which does not have an existing data file in the partials/languages/ directory. We have worked around this in a way that is avoiding fatal errors, but we will still be rendering pages in languages where we are forced to use the English default messages rather than localized versions.

One potential fix for this would be to add a second message catalog for the theme to our data at translatewiki.net so that we could crowdsource translations for the theme's strings from the same community that is providing us with translations for the content message catalog.

Inside the theme, a t( msg ) macro implements their translation system. This macro is defined in partials/language.html and could be replaced with any implementation we needed. Calls to the macro look like {{ lang.t('header.title') }}. banana-i18n would be a very reasonable technology to use in a replacement.

Event Timeline

A few questions about this:

What happens now if we get translations from translatewiki in an unsupported language? If my understanding is correct, we still display them in the Dev Portal but with English for interface text? (Example: T309087)

If we did replace theme translations with our own data, would this mean not using any translation from the theme or just using our own data for languages missing from the theme?

What happens now if we get translations from translatewiki in an unsupported language? If my understanding is correct, we still display them in the Dev Portal but with English for interface text? (Example: T309087)

Yes, your understanding is correct. The active fix is to use English messages (which are the fallback in any case) if the content language is not found in the current list of known theme locales.

If we did replace theme translations with our own data, would this mean not using any translation from the theme or just using our own data for languages missing from the theme?

I think the most likely implementation would be to only use our own translations and ignore any provided by the theme. To clarify a bit more, this would only be for the 31 translatable strings documented at https://github.com/squidfunk/mkdocs-material/blob/master/.github/ISSUE_TEMPLATE/translate.yml.

So is T309087 currently possible? Or it requires the change proposed by this task?

So is T309087 currently possible? Or it requires the change proposed by this task?

Content translations to en-gb are possible now that we have done T309113. The UI strings discussed in T309144#7958124 would remain in the "en" locale (which is likely en-us in reality).

(As an aside, I feel that an en-gb variant for the developer portal is unlikley to be actually needed by anyone, but this may be American cultural imperialism speaking. I'm not generally opposed to en-gb localization, but in the case of a static site where 99.9% of word spellings are going to be identical to the en-us default it seems like a waste of everyone's energy.)