feat(i18n): externalize email templates + lang-aware send chain (#221)#5
Closed
an9xyz wants to merge 1 commit into
Closed
feat(i18n): externalize email templates + lang-aware send chain (#221)#5an9xyz wants to merge 1 commit into
an9xyz wants to merge 1 commit into
Conversation
…nglamp-OSS#221) Add modules/base/common/emailtmpl: per-language (zh-CN/en-US) subject/HTML/ plaintext email templates embedded via go:embed and rendered through a text/template + html/template split, so Subject headers are not HTML-escaped while bodies keep XSS-safe escaping of user-controlled fields. Thread a lang parameter through the email send chain: - SendVerifyCode takes a lang arg, renders from emailtmpl, and is upgraded to SendTransactionalHTML (plaintext fallback + transactional headers reduce silent spam-filter drops). - Space owner/member invite emails render via emailtmpl; the role label and the anonymous-inviter fallback are localized in-template instead of hardcoded in Go, and invite links now carry &lang=<recipient language>. - Add i18n.OutboundLanguage(ctx): negotiated language with OCTO_DEFAULT_LANGUAGE fallback. Per Mininglamp-OSS#221 it resolves to the default for now (verify-code requester == recipient; invites are async with no recipient uid); the lang param is threaded end-to-end so a future per-recipient resolver plugs in without touching the send or template layers. Client-visible verify-code/login API errors are already localized via ResponseErrorL (Mininglamp-OSS#188/Mininglamp-OSS#197); this only English-cleans the now-invisible service-layer error sentinels.
Collaborator
Author
|
Superseded by upstream PR Mininglamp-OSS#224 (same branch). Closing this fork-internal PR to avoid duplication. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Implements issue Mininglamp-OSS#221 (Part of Mininglamp-OSS#170, backend i18n): externalize the hardcoded
Chinese email templates into per-language assets and thread a
langthrough theemail send chain.
modules/base/common/emailtmpl— per-language (zh-CN/en-US)subject/html/texttemplates embedded viago:embed, rendered through atext/template+html/templatesplit: Subject headers are not HTML-escaped,while bodies keep XSS-safe escaping of user-controlled fields (inviter name,
space name, …). Templates are precompiled once; an incomplete set fails loud
at startup.
SendVerifyCodegains alangarg, renders fromemailtmpl, and is upgraded toSendTransactionalHTML(plaintext fallback +transactional headers reduce silent spam-filter drops).
emailtmpl; therole label and the anonymous-inviter fallback are localized in-template
instead of hardcoded in Go. Invite links now carry
&lang=<recipient language>.i18n.OutboundLanguage(ctx)— negotiated language withOCTO_DEFAULT_LANGUAGEfallback. Per feat(i18n): email templates + lang-aware send chain (Part of #170) Mininglamp-OSS/octo-server#221 the value resolves to the defaultfor now (verify-code requester == recipient; invites are async with no
recipient uid); the
langparam is threaded end-to-end so a futureper-recipient resolver plugs in without touching the send or template layers.
Client-visible verify-code/login API errors are already localized via
ResponseErrorL; this change only English-cleans the now-invisibleservice-layer error sentinels.
Test plan
go build ./.../go vet ./...emailtmpl+pkg/i18nunit tests, incl.-race(render, languagefallback, XSS escaping boundary, URL not mangled, localized role label,
template completeness)
modules/base/common,modules/commonmake i18n-extract-check+make i18n-lintgreengofmtcleanAcceptance (Mininglamp-OSS#221)
OCTO_DEFAULT_LANGUAGEmake i18n-extract-check+make i18n-lintgreen