Comments migrated from the slides

Slides comment, Mihai Nita (@mihnita), 11:51 AM Apr 21

Are the escapes identical in literals identical to the ones inside placeholders?

If yes, why? Saying "yes" can drag in unnecessary implications.

Slides comment, Eemeli Aro (@eemeli), 12:37 PM Apr 21

Could you clarify what you mean by "unnecessary implications"?

Slides comment, Mihai Nita (@mihnita), 12:30 PM Apr 23

Makes escaping more complex.
Not so much in parsing, but for the regular user writing the message.

If the escape rules depend on the current state it means they don't "leak" and create noise outside that state.

Take for example the MF1.
...{exp,date,"MMM d 'at' h:mm a"} ...

The pattern inside the placeholder is passed to MessageFormat. Which requires the ' around 'at' (otherwise "a" is interpreted as an am/pm field)
And then there are rules on how to escape the ' for DateFormat.

That requirement to escape the ' inside the placeholder "leaked" outside, requiring doubling the ' in the plain text part.
Which was a continuous PITA.

===

In HTML there is no good reason to escape " and ' in plain text, and there is no good reason to escape < and > in the values of the attributes.

So most browsers will even ignore those rules and to the right and intuitive thing:

<p> Don't "escape" things, <img src="..." alt="No need to escape < or > in here">!</p>

Even escaping & is often unnecessary.

===

It it easier to read / write a message (as a human, not a machine) if the escape rules are limited by scope (in text, in a literal, values of the options, maybe selector keys, etc).

Take a literal:
This {"OK to use { here", ...}...
There is no need to escape { in the literal.

And a {lst, listFormat, start="{" end="}" sep=", "} items.

There is no need to escape { } in the values of the options.

Or maybe in the future a custom function:

{count :ranges
"=1" {a single egg}
"[1, 20)" {a bunch of eggs}
"[20, 100)" {a lot of eggs}
_ {countless eggs}
}

There is no good reason to escape "[" inside the key.

===

"Global" escaping rules produce unnecessary "noise escapes"

Slides comment, Eemeli Aro (@eemeli), 2:25 AM Apr 24

Thank you for the clarification. I agree that e.g. our need to escape \" inside a "quoted literal" should by no means force all " to be escaped outside quotes literals.

Conversely, do you see harm in allowing \" escapes outside quoted literals? Meaning that in the text part of a message, " and \" would both be recognised as representations of the same character.

Slides comment, Mihai Nita (@mihnita), 4:09 PM Apr 24

Accepting both \" and " seems sloppy.
Yes, a parser can be tolerant and accept both.
But I don't think it is not good design to have that in the syntax.

Slides comment, Mihai Nita (@mihnita), 4:32 PM Apr 24

... Removed first part of the comment, talking about escaping [ ]

...

That's also the reason you don't want to mix escaping conventions, and try (as much as possible) to leave that to the storage.

Imagine a properties file where some strings require 䔳 escape, some support é some require \u4533, and some \u{4533}.

Depending on what API is used on that string after loading.

Uh oh!

Escaping: escaping when a message is stored in a general purpose container #236

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions