parse-community / parse-community/parse-server-api-mail-adapter
localeCallback add access to request
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 27
- Forks
- 21
- Avg merge
- 56m
- Merged PRs (30d)
- 1
Description
New Feature / Enhancement Checklist
- I am not disclosing a vulnerability.
- I am not just asking a question.
- I have searched through existing issues.
Current Limitation
Currently choosing localization template requires writing user's locale to the user table and then querying it before sending the email. This is done in the localeCallback. However, this requires 1 read operation each time the email is dispatched. In addition, this doesn't allow for automatic locale detection. And if user changes browser language, they will still be getting their emails in their old language.
Feature / Enhancement Description
Would it be possible to provide access to request object inside the localeCallback? The request object of cloud functions usually contains the Allow-Language header, or cf-ipcountry header for the sites behind cloudflare.
These can be conveniently used for dynamic localization without any need to write or read anything from db.
Example Use Case
localeCallback: async (req) => {
const locale = req?.headers["accept-language"]?.split(",")?.[0]?.split("-")?.[0]; // en or tr or es
return locale;
},
Alternatives / Workarounds
3rd Party References
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by locating the localeCallback entry point and tracing how the adapter invokes it during email dispatch. Confirm what request data is available there, then make the callback receive the request so the shown Accept-Language example can select a locale without a database read; verify existing localization behavior remains intact.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- backend, localization
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100