You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The most basic functionality would be adding a new formatter. Meantime ICU
48
-
added other formatters: time intervals, measurement, lists. But MessageFormat
49
-
did not keep up. And adding support for any of these new formats risks to break
50
-
existing tools.
53
+
The most basic functionality would be adding a new formatting function.
54
+
MessageFormat 1.0 only supported a small number of basic formatting functions,
55
+
while over the years ICU added many new capabilities: date and time intervals,
56
+
measurement units, lists, person names, and many more.
57
+
Developers also sometimes want to define their own formatting functions.
58
+
Supporting additional formats risks breaking interoperability or compatibility
59
+
with existing tools.
51
60
52
61
### 1.2. Can't deprecate anything, even if now we know better
53
62
54
63
ICU is old, but also very popular (right now it is the core i18n library
55
-
for all major operating systems, and many products).
64
+
for all major operating systems, browsers, and many other products).
56
65
57
-
This is how he have both numeric and named parameters, partial strings in
58
-
plural / select (technically concatenation, which is bad i18n), date / time
59
-
patterns (bad i18n, when skeletons are the better way), nesting selectors,
60
-
unfriendly escaping (think doubling the apostrophe `''` ), `#` in plurals.
66
+
As a result of its age and design,
67
+
MessageFormat 1.0 has both numeric (positional) and named parameters.
68
+
It still provides date and time patterns (picture strings), when skeletons or option
69
+
bags provide far superior results.
70
+
It allows selectors (such as plural and select) around only part of the overall message,
71
+
which is a form of non-internationalized string concatenation.
61
72
62
73
Most of it can't be “blamed” directly on a bad decision, it is just time
63
74
teaching us what works (for instance skeletons did not exist when the
@@ -68,34 +79,45 @@ But the stability requirements prevent any major cleanup.
68
79
### 2. Some existing problems
69
80
70
81
- ICU added new formatters, but MessageFormat does not support them
71
-
-Combined selectors (select + plural) results in unreadable and error
72
-
prone nesting
73
-
-Select and plurals inside the message are difficult to translate because of
74
-
grammatical agreement requires words outside select / plural to change.
82
+
-Messages with selectors (`select` and/or `plural`) are difficult to create
83
+
and edit because of the complex nesting requirements of the syntax.
84
+
-`select` and `plural` placeholders inside a message are difficult to translate as
85
+
grammatical agreement may require words _outside_ the `select`/`plural` to change.
75
86
See https://en.wikipedia.org/wiki/Agreement_(linguistics)
76
-
- Patterns in the date / time / number placeholders are bad i18n, should use skeletons
77
-
- No official support for gender. It can be done with `select`, but it
78
-
is not the same thing (same as the difference between an `enum` and integer/strings). Developers can use masculine/feminine, masc/fem, male/female, etc.
79
-
- Formatting for “parameters” known at compile time
87
+
- Placeholders for `date`, `time`, and `number` can include picture strings
88
+
that require translators to alter the "code" portion of a message
89
+
and to understand arcane software-developer oriented syntaxes.
90
+
While more-modern solutions such as skeletons have been added,
91
+
there are no guardrails to keep people from using these poorly
92
+
internationalized features.
93
+
- Unable to support grammatical or personal gender selection well.
94
+
Existing selectors such as `select` cannot account
95
+
for the grammatical needs of different gender categories across languages.
96
+
Tools have no way to know what modifications are needed
97
+
and developers have to understand the needs of current and future languages to succeed.
80
98
- Escaping with apostrophe is error prone. There is no reliable way to tell if
81
99
it has to be doubled or not.
82
-
- The # is used in plural format instead of {...}, but does not work for nesting unless the plural is the innermost selector. But named placeholders don't work
100
+
- The `#` is used in plural format instead of `{...}`, but does not work for nesting unless the plural is the innermost selector. But named placeholders don't work
83
101
properly for plurals with offset. So there are 2 ways to do the same thing that work in 98% of cases, but in special situations only one of the ways works.
84
102
- Does not support inflections, and it would be hard to add without breaking existing tools.
85
103
86
104
### 3. Hard to map to the existing localization core structures
87
105
88
-
The format is not well supported by any major localization system. \
106
+
While MessageFormat 1.0 and its syntax are widely supported by runtime environments,
107
+
the same cannot be said for localization tooling.
89
108
The root cause of that is not it is difficult to parse.
90
109
Because it is not. And ICU4J has public API for parsing.
91
110
92
111
Most translation tools take a string (with placeholders) in a source language
93
-
and gives back a translated string, usually with the same placeholders
112
+
and give back a translated string, usually with the same placeholders
94
113
(with some degree of flexibility).
95
114
96
-
It makes it very difficult to translate things like plurals, where the input
0 commit comments