Fix tag issues/indentation, axe most of Beeware plugin, update edit links

[HalfWhitt]

As far as I'm aware, none of this changes any of how the site actually looks.

I cleaned up a few places where tags were interacting oddly with Markdown. Markdown fields generate their own <p> tags, so using them for titles was generating <h3><p>...</p></h3>. And putting a Markdown field inside of a paragraph tag creates <p><p>...</p></p>, which isn't syntactically valid. Technically, the first <p> is implicitly closed by the second one, so the final </p> dangles.

Other than that, I escaped the bare > in the breadcrumbs to >, and tried to make some of the indention of the generated source a little saner. (I've been reading up a bit on ways to manage whitespace more consistently with Jinja, but it's still dauntingly fiddly.)

EDIT: Also fixes #641.

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[github-actions]

Visit the preview URL for this PR (updated for commit 8fedb26):

https://beeware-org--pr663-tags-cleanup-8rykgzzt.web.app

_{(expires Sun, 22 Jun 2025 23:53:31 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: b0da44bc067e7d9a4255c77cb2c5fce572218cec}

[freakboy3742]

These changes all make sense; my only comment is that they might not go far enough (regarding #641; details inline).

[HalfWhitt]

Okay. The edit link now goes to the correct file on Github, when clicked on an English version of a page. Our Weblate site's knowledge of what page its strings are from seems to be fuzzy at best, so I'm not sure if/how to link specifically, but I've set it up so it at least links to the correct language's dashboard.

I also changed "Update translation on Github" to "Edit translation on Weblate". I search-and-replaced Github to Weblate, but at least as of this commit, all those translated strings still say "update".

[HalfWhitt]

(That last commit was just source indentation; shouldn't change the rendered appearance any.)

[freakboy3742]

Awesome cleanup; I only noticed 2 problems:

1. The text "Edit translation on Weblate" is fairly long in English... "Mettre à jour la traduction sur Weblate" is getting really unwieldy. I wonder if it might be better to just use "Translate" there? I'm open to other suggestions though.
2. The preview of the Home and News pages aren't rendering any upcoming events. It looks like the Beeware plugin was providing 1 feature that we were using: a value for today. The actual events page isn't affected by this because it renders all events, and "today" is provided by Javascript; but home and news use the value in Python.

[johnzhou721]

• The text "Edit translation on Weblate" is fairly long in English... "Mettre à jour la traduction sur Weblate" is getting really unwieldy. I wonder if it might be better to just use "Translate" there? I'm open to other suggestions though.

"Translate on Weblate" or just "Weblate" (which 1) can be used a noun in the link and 2) the upper right-hand corner of https://weblate.org/en/ uses Weblate jokingly as a verb like "Google")

[freakboy3742]

"Translate on Weblate" or just "Weblate" (which 1) can be used a noun in the link and 2) the upper right-hand corner of https://weblate.org/en/ uses Weblate jokingly as a verb like "Google")

You get to make that joke when you're a brand everyone knows. Weblate is hardly that.

[johnzhou721]

"Translate on Weblate" or just "Weblate" (which 1) can be used a noun in the link and 2) the upper right-hand corner of https://weblate.org/en/ uses Weblate jokingly as a verb like "Google")

You get to make that joke when you're a brand everyone knows. Weblate is hardly that.

“Translate on Weblate” is still a bit shorter than “edit translation on Weblate” which is the main suggestion in my message.

[HalfWhitt]

1. I like "Translate on Weblate".
   1a. I'm a bit fuzzy on the source of truth for Weblate translation stuff... when I change a string like this in English, should I attempt to alter the equivalent translated string in the .ini file? Or does that even matter, if those are pulled from Weblate?
2. Ah, missed that was where today was coming from. Before next committing, I think I'll make a blank local Git repo and copy the before-and-after generated files into it to double-check what is and isn't changing. I wonder if there'd be a way to automate that as part of CI...

[freakboy3742]

1. I like "Translate on Weblate".
   1a. I'm a bit fuzzy on the source of truth for Weblate translation stuff... when I change a string like this in English, should I attempt to alter the equivalent translated string in the .ini file? Or does that even matter, if those are pulled from Weblate?

The .ini files aren't pulled into Weblate. That's a known gap in our translation tooling at present; they have to be fixed by PR. I'm happy with a Google Translate (or equivalent - the main translation is done with DeepL) as a first pass translation.

2. Ah, missed that was where today was coming from. Before next committing, I think I'll make a blank local Git repo and copy the before-and-after generated files into it to double-check what is and isn't changing. I wonder if there'd be a way to automate that as part of CI...

I'm sure it could be... the question for me is whether the squeeze is worth the juice.

[HalfWhitt]

The .ini files aren't pulled into Weblate. That's a known gap in our translation tooling at present; they have to be fixed by PR. I'm happy with a Google Translate (or equivalent - the main translation is done with DeepL) as a first pass translation.

So I go and put them in via Weblate?

I'm sure it could be... the question for me is whether the squeeze is worth the juice.

Depends on how complicated it'd be, I guess. I've found myself wishing for it pretty often during the last few PRs. I might see about just whipping up a script to automate it locally.

[HalfWhitt]

So — if I understood correctly, databags/translate.ini is the source of truth for the English strings, but everything else is only copied there from Weblate; as such, I've reverted all changes to other languages in that file file in this PR. Let me know if that's not correct.

[freakboy3742]

No objection to having this if there's no other option - but is there no pre-existing plugin that will give "today's date" as a context variable? It seems like one of those things that is so common it must exist...

[HalfWhitt]

It may very well... That said, I've also been working, in parallel, on a plugin to provide a more convenient filter replacing our current translation macro. Might as well feed two birds with one scone.

[freakboy3742]

Why are we wasting perfectly good scones on the birds? 🤣

Did you want to roll that new plugin into this, or land this version of a vastly-minimised plugin, and replace it in the next pass?

[HalfWhitt]

Well it's much nicer than stones : )

I think it would be a much simpler PR to review (and verify nothing is out of order) if done separately.

[freakboy3742]

The .ini files aren't pulled into Weblate. That's a known gap in our translation tooling at present; they have to be fixed by PR. I'm happy with a Google Translate (or equivalent - the main translation is done with DeepL) as a first pass translation.

So I go and put them in via Weblate?

No - they need to be done as part of the ini file. Weblate only works with .po files AFAIK, and the database translation thin is mostly a workaround for translation.

There might be a way to get the databag content into Weblate... but that's definitely a bigger project. For now, it's manual translation by way of PR.

[HalfWhitt]

Oh, I see now. I misconstrued.

[freakboy3742]

So — if I understood correctly, databags/translate.ini is the source of truth for the English strings, but everything else is only copied there from Weblate; as such, I've reverted all changes to other languages in that file file in this PR. Let me know if that's not correct.

Yes and no. There's essentially 2 sources of truth - "content", which is what comes from contents.lr, and is passed through PO files and weblate; and databag stuff, which is explicitly translated as "alternate content" in the .ini file. Ideally, every English string in the .ini file would be covered by a translated string in the ini file, but that clearly isn't happening, even for languages that have historically had good translations (like German).

So - it's not required to add translations for new English strings in the database .ini file, but it certainly doesn't hurt. There's probably space for someone to do a full audit of the current databag strings to make sure there's a base machine translation for everything - but that can be a separate PR.

[freakboy3742]

Ok - this is enough of an improvement that it's worth landing. There's still plenty that could be done to fill out databag translations, and potentially do the plugin additions you mentioned - but I'm happy for those changes to happen in a follow up.

[HalfWhitt]

Ah man, I just pushed the translation commit. I'll just put it in the next PR.

[freakboy3742]

Ah man, I just pushed the translation commit. I'll just put it in the next PR.

Gah - sorry!

[johnzhou721]

I'm sure it could be... the question for me is whether the squeeze is worth the juice.

Depends on how complicated it'd be, I guess. I've found myself wishing for it pretty often during the last few PRs. I might see about just whipping up a script to automate it locally.

Hi! Did you whip up this script? I think I'm in huge need of it.

[HalfWhitt]

Hi! Did you whip up this script? I think I'm in huge need of it.

I'm afraid I didn't. I kind of hacked it — I built the code from base (or whatever I was starting from) and committed the generated site files to a brand new, empty Git repo. Then I built with my changes, replaced what was in the repo with the new results, and committed again. Then I could view the changes between them.

[johnzhou721]

Hi! Did you whip up this script? I think I'm in huge need of it.

I'm afraid I didn't. I kind of hacked it — I built the code from base (or whatever I was starting from) and committed the generated site files to a brand new, empty Git repo. Then I built with my changes, replaced what was in the repo with the new results, and committed again. Then I could view the changes between them.

Ack.

Also quoting Dr. Keith-Magee:

So - it's not required to add translations for new English strings in the database .ini file, but it certainly doesn't hurt. There's probably space for someone to do a full audit of the current databag strings to make sure there's a base machine translation for everything - but that can be a separate PR.

Since this is mentioned here, #684 will eliminate the need for this -- it copy+pastes the databags and marks anything that need editing (explained there) with fuzzy (all done by hand), and shows that there's some mismatch between the different files, to the point where we're mixing languages like 黃金 Member at https://beeware.org/zh_TW/community/members/anaconda/.

After that PR completes, progress would be shown in Weblate, along with content translations.