Closed funkenstrahlen closed 3 years ago
Thanks for suggesting.
The reason why the user object is currently provided is because it is available as part of the request without any additional query. If the same is true for the installation object (not just the installation ID), then I agree that the installation as a basic building block could be provided too. If not, then I suggest to not add it (or only the installation ID?) because we want to avoid queries that are potentially unnecessary for certain use cases.
I have not checked if it's provided and therefore available without any further effort.
However I think it's a good idea and we should discuss if it's possible. M
Sure, feel free to check, I'll gladly stand corrected if the installation object was provided and I think it would be good to add it.
I'm closing this due to inactvity.
New Feature / Enhancement Checklist
Current Limitation
Localization can only be decided by properties of user object but parse automatically stores user localization data in Parse Installation.
Feature / Enhancement Description
Allow access to Parse Installation in localization callback of a template
Example Use Case
Parse Installation already comes with a valid locale identifier in the database. Parse User does not and it requires extra effort to store the localization preferences there.
Alternatives / Workarounds
Parse Installation Post Save Hook to store localization preferences in Parse User too.