The current push notification token entity does not contain a language code, but needs it.

At first, I was trying to implement this using a "language" base field. This field brings a lot of nice validations (e.g. valid language when creating token through REST), but also wants to translate tokens, which is not applicable to this module.

So instead, I'm going with a basic string field and add a custom validation plugin that validates the language code.

CommentFileSizeAuthor
#2 token_langcode_validation.patch5.54 KBhaagendazs
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

haagendazs created an issue. See original summary.

haagendazs’s picture

haagendazs CreditAttribution: haagendazs as a volunteer commented
FileSize
token_langcode_validation.patch5.54 KB

Made some good progress on this, but then my dev environment blew up. Here's a patch of the current state. Will finish soon.

  • haagendazs committed 1a571a6 on 8.x-1.x 
    Issue #2790063 by haagendazs: Add language code to token entity
haagendazs’s picture

haagendazs CreditAttribution: haagendazs as a volunteer commented
Status: Active » Needs review

This is ready for review:

  • Add a field "langcode" to the token entity
  • When adding a token and no langcode is provided, use the current site's default language code
  • When adding a token and a langcode is provided, validate that it's a valid language code
mihai7221’s picture

mihai7221 CreditAttribution: mihai7221 commented

Can you please explain what is the logic behind translating the token entities? Why they need to be translated ?

I was thinking that since we already translate the push notifications, on sending, the language for the users is taken from the preferred account's language or the default site language if the content translation hasn't been enabled.

haagendazs’s picture

haagendazs CreditAttribution: haagendazs as a volunteer commented

@canutza: I have two reasons, and the first one is probably a pretty weak one.

  1. The push token is really the identifier for an application on a mobile device, so one could argue that the language should be linked to the user's preferences on the app, and not the user's preferences on the website
  2. Anonymous users: The module wouldn't be able to handle tokens for anonymous users, since we wouldn't be able to get the language from the user's account

What do you think?

mihai7221’s picture

mihai7221 CreditAttribution: mihai7221 commented
Status: Needs review » Needs work

Ok, I see your point, you are right.

Everything seems to work with your patch, however, the error messages are not well formatted in the watchdog because it doesn't interpret HTML, it displays plain text.
Also, the rest call throws a 422 "Unprocessable Entity" with the message "The website encountered an unexpected error. Please try again later." so this is something that we should work on I suppose.