Make templates translatable

[ojh]

Closes #5984

[nlhkabu]

Thanks @ojh! For me to do:

• Resolve conflicts
• Ensure recent content changes also have translatable content
• Test manage roles form
• Translate new content on warehouse/templates/manage/settings.html

Test emails

• Account deleted
• Added as collaborator
• Collaborator added
• Password change
• Password compromised
• Password compromised HIBP (not sure how to test this, but double checked the templates are correct)
• Password reset
• Primary email change
• Verify email

[nlhkabu]

@woodruffw you mentioned that we should be using IDs here? Can you please let me know what that would involve? Thanks

[woodruffw]

Can you please let me know what that would involve?

I believe it'll involve switching from {% trans %} ... {% endtrans %} blocks to _(-style markers with explicit IDs, e.g. from

{% trans %}Access Denied / Forbidden (403){% endtrans %}

to:

{{ _("access-denied-forbidden-403", default="Access Denied / Forbidden (403)") }}

where access-denied-forbidden-403 becomes the translation ID for lookup purposes.

[nlhkabu]

@ewdurbin @woodruffw @yeraydiazdiaz I wanted to get some feedback on the question of adding string IDs to this PR.

My understanding is that by adding IDs to each of the strings, it means that when we change the English source, the legacy translation can still stay in place, which should make managing translations easier.

However, I'm concerned that it will mean that we provide a sub-optimal experience for users on other languages, in that translations will become stale over time.

My understanding is that without IDs, updated strings will revert back to English, until a community member makes a new translation PR.

Is this correct?

On my side, I think the best approach will largely depend on whether or not we can:

1. Recruit community members to maintain translations
2. Notify language maintainers when new strings are pushed to the codebase

@ewjoachim as someone who has suggested helping with the initial French translations, what do you think is a reasonable approach here from a contributor point of view?

Thanks

[woodruffw]

Is this correct?

Yep, this is correct -- if we use the English copy as IDs, then changes to the copy will cause translations to disappear and foreign-language users will see the English version of the string. If we use custom IDs, translations will degrade over time as they de-sync with the latest English copy.

[ewjoachim]

Hi there !
First WOW ! The amount of work put in this PR is phenomenal. Did you use a script or something, extracted the template AST and somehow auto added all these {% trans %} blocks or is it pure manual work ? Either way it's very impressive and humbling. (if it's a script though, I'd be interested in reading it :D )

I would have agreed that IDs were nice, but reading @nlhkabu's comment again, I'm thinking about a few things:

• Using IDs is mainly a way to avoid re-translating if the English wording changes without changing the meaning. As far as I understand, there's no other advantage to using IDs. Please correct me if I'm wrong. Now, when the English copy changes, how often is it a cosmetic wording change and not a meaning change? You probably have more experience than me in this, regarding Warehouse. If you're using IDs, it probably means you'll need to remember to change the key (to prompt retranslation) everytime the meaning changes.
• Modern translation tools usually offer "translation memory", allowing you to access previous translations of a similar sentences, even if they have disappeared since. This means if you change the wording of a string, yes, all languages translators will have to retranslate it but chances are this translation will be done in a single click.
• If at some point, you really change a lot of text (like for example enabling "trimming" everywhere), chances are you can work on the PO files directly to port your changes to the languages without retranslation.

So... The main use-case I see for IDs is actually not the most frequent thing that will happen (I guess, please correct me if I'm wrong) and IDs will add a bit of complexity (you'll need to ensure ID unicity, and need to remember to change them everytime the corresponding sentence changes in a way that requires retranslation)

I'm 👍 with @nlhkabu on preferably not using IDs (even if it feels super counter-intuitive to my programmer brain)

[ewdurbin]

Seems we have consensus that "English as ID" is the preferred method. As such, this PR should be good to merge? @woodruffw we'll need to update #6535 to go back to this method.