Support Translation of Module Descriptions

Pasting here some things in wrote in Slack about this...

In core itself, we intentionally do not translate module names, which are considered proper nouns (and therefore, capitalized). E.g. "Views" must always be "Views", the world over, or there's way too much potential for confusion and trouble. It's not "views", it's the one-and-only "Views"(:tm:). 😉 We don't even want to open the mess of "Brazil" vs. "Brasil" or worse, "Germany" vs. "Deutschland", since that could lead to horrible UX in the admin UI on places like the Extend page, etc. Tutorials wouldn't make sense, etc.

If the project descriptions are going to be translated:

1. How would that even work? If the content is fed by the actual project pages on d.o in a feed, every time that feed is re-generated, we'd need to re-sync that with l.d.o or something.
2. wow, that's going to be a ton of work for translators to try to stay up on. It's already extremely difficult for maintain a language that covers "all" of core. Adding all those strings would be really tough. Ideally, we could have them in a separate bucket on l.d.o so everyone's %-translated stats don't immediately plummet. 😅

E.g. maybe we handle the project description translations via the contrib project_browser namespace, so language maintainers can opt-in to that hellish world or not as they have capacity for... (edited)

I don't think it'd work for PB to have to fully load the entire pathauto.po for the top 100 projects. We can't put the translations directly into the same l.d.o contrib projects. We really do want something like project_browser itself that has the N project descriptions and whatever else we "need" to translate for the PB UI...

Maybe if we can somehow extract translatable strings from README.md, we can have the translations on l.d.o already with mostly existing plumbing. But we're already going to either have to extract a subset of README.md, or go ahead and introduce a whole new file that projects can create, e.g. SUMMARY.md that just has the short PB-compliant blurbs. We could automatically say the whole contents of that file is a translatable string.

Unless the canonical source of truth for the PB description text is on d.o itself. In that case, we just have to have a regular syncing between this field on d.o and l.d.o, and we don't care about parsing files from Git at all.

Can anyone confirm if the canonical source of truth for the PB description text is supposed to be on d.o itself? In that case, we'll need a regular sync between the d.o values in this field and l.d.o, and we don't care about parsing files from Git at all.

Slack continued:

fjgarlin: the d.o database values directly. d.o live endpoint will just expose the projects on the DB

dww: We're going to need the #multilingual world of l.d.o for this, so something will have to sync those summary values over to l.d.o. E.g. we write something that consumes the d.o feed and imports them into the l.d.o project_browser project namespace.

dww: Could be a drush command or whatever.

fjgarlin: was thinking the same or cron job

dww: Then, the PB UI can know what languages it needs to be able to handle, and can query l.d.o for the project_browser.xyz.po file for each language, and render the localized UI.

The source data for the default plugin comes from www.drupal.org itself, so the values stored in the database will be exposed using a jsonapi endpoint.