Closed Bug 1308590 Opened 6 years ago Closed 6 years ago

Link to references in the Push encryption error strings

Categories

(Core :: DOM: Push Notifications, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla52
Tracking Status
firefox52 --- fixed

People

(Reporter: lina, Assigned: lina)

References

Details

Attachments

(1 file)

The padding error has technical jargon, and flod suggested a link would be easier for localizers and developers.
Comment on attachment 8798987 [details]
Bug 1308590 - Link to references in the Push encryption error strings.

https://reviewboard.mozilla.org/r/84302/#review82904

::: dom/locales/en-US/chrome/dom/dom.properties:253
(Diff revision 1)
>  # LOCALIZATION NOTE: Do not translate 'YouTube'. %S values are origins, like https://domain.com:port
>  RewriteYouTubeEmbedPathParams=Rewriting old-style YouTube Flash embed (%S) to iframe embed (%S). Params were unsupported by iframe embeds and converted. Please update page to use iframe instead of embed/object, if possible.
>  # LOCALIZATION NOTE: This error is reported when the "Encryption" header for an
>  # incoming push message is missing or invalid. Do not translate "ServiceWorker",
>  # "Encryption", and "salt". %1$S is the ServiceWorker scope URL.
> -PushMessageBadEncryptionHeader=The ServiceWorker for scope ‘%1$S’ failed to decrypt a push message. The ‘Encryption’ header must include a unique ‘salt‘ parameter for each message.
> +PushMessageBadEncryptionHeader=The ServiceWorker for scope ‘%1$S’ failed to decrypt a push message. The ‘Encryption’ header must include a unique ‘salt‘ parameter for each message. See https://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding-02#section-3.1 for more information.

Do I need to bump the string IDs, even though these just landed this morning?
Comment on attachment 8798987 [details]
Bug 1308590 - Link to references in the Push encryption error strings.

https://reviewboard.mozilla.org/r/84302/#review82906

::: dom/locales/en-US/chrome/dom/dom.properties:293
(Diff revision 1)
>  # (1 for aesgcm128, 2 for aesgcm).
> -PushMessageBadPaddingError=The ServiceWorker for scope ‘%1$S’ failed to decrypt a push message. Each record in the encrypted message must be padded with a %2$S byte big-endian unsigned integer, followed by that number of zero-valued bytes.
> +PushMessageBadPaddingError=The ServiceWorker for scope ‘%1$S’ failed to decrypt a push message. A record in the encrypted message was not padded correctly. See https://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding-02#section-2 for more information.
>  # LOCALIZATION NOTE: This error is reported when push message decryption fails
>  # and no specific error info is available. Do not translate "ServiceWorker".
>  # %1$S is the ServiceWorker scope URL.
>  PushMessageBadCryptoError=The ServiceWorker for scope ‘%1$S’ failed to decrypt a push message. For help with encryption, please see https://developer.mozilla.org/en-US/docs/Web/API/Push_API/Using_the_Push_API#Encryption

Since we're touching strings, can you remove en-US from this link?
Normally I would ask to change string IDs, but given that this just landed (and I'm the only one who translated it so far) I'm going to skip it.

CCing other localizers working on mozilla-central so they're aware of this.
Comment on attachment 8798987 [details]
Bug 1308590 - Link to references in the Push encryption error strings.

https://reviewboard.mozilla.org/r/84302/#review82910

Thanks
Attachment #8798987 - Flags: review?(francesco.lodolo) → review+
Pushed by kcambridge@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/71df0ebe349d
Link to references in the Push encryption error strings. r=flod
https://hg.mozilla.org/mozilla-central/rev/71df0ebe349d
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
(In reply to Ryan VanderMeulen [:RyanVM] from comment #8)
> https://hg.mozilla.org/mozilla-central/rev/71df0ebe349d
> 
> The ‘salt‘ parameter in the ‘Encryption‘ ...

Lots of ‘ instances in this changeset where ’ was intended. Can this be fixed in any next revision?
You need to log in before you can comment on or make changes to this bug.